Live data from Hacker News

Launch HN: Opstrace (YC S19) – open-source Datadog

news.ycombinator.com

111–120 of 120 posts

Re: Launch HN: Opstrace (YC S19) – open-source Datadog

#111

Earlier quoted context omitted.

Jan-Philip from Opstrace here. This is lovely feedback! > is a royal pain in the neck. It's fun to see how different people put the same unpleasant experience into words in this thread. Thanks for adding your personal touch. Every time we hear something like that, we're re-assured that we're on the right track. > Even if `opstrace create` spawns them easily, the problem is running/maintaining them Yes. You're right.…

Will definitely keep an eye on your service. Again, don't underestimate users willingness to pay for a PaaS product you make, even if you also do a dual PaaS/self-hosted option like Gitlab or MongoDB does, for example. We'd definitely prefer the PaaS, and that's where the big $$$ is made these days. By the way, we are requiring that any vendor we choose in this area support OpenTelemetry as we've already instrumented…

Makes sense! Thanks for the feedback.

And yeah OpenTelemetry is where lots of the industry is going and so are we. You can already do cool things with us and the collector but we plan on automating a lot and expand on that.

A little bit about that in this commment: https://news.ycombinator.com/item?id=25995424

Re: Launch HN: Opstrace (YC S19) – open-source Datadog

#112
post #110

Earlier quoted context omitted.

We’re truly sorry that you felt let down! You raise a great point that is worth clarifying though. All logs, metrics and future traces are stored in S3/GCS (and yes metrics are stored in TSDB format). While this does not allow a single query language to ask questions across all these sources in one query (yet), it is absolutely possible to build what Datadog is with a new user interface. To go even further, now that…

> other technologies can be leveraged That’s my point: your software architecture must evolve to deliver on your promises (open-source Datadog) because it’s impossible to satisfy your promises with the architecture as it exists today. Nonetheless, I appreciate all the responses. Good luck to OpsTrace!

Totally fair. It's a fine line we have to walk.

Re: Launch HN: Opstrace (YC S19) – open-source Datadog

#113
post #54

> We will always be open source, and we make money by charging a per-user subscription for our commercial version which will contain fine-grained authz, bring-your-own OIDC and custom domains. Seems to me that these are at odds. If you're open source, why does anyone have to pay for these things? If you're open core, I think it's mighty misleading to say things like "We will always be open source" because then not on…

Thanks for your feedback! As with many in the industry, we are trying our best to figure this out. Our intention is to be really transparent with how we build and price software, which is why our commercial features will also be public in our repo, but commercially licensed. Transparency is critical in our opinion. This is the model we’ve seen work for other highly impactful software projects. We’ve created a ticket…

Ahh. The commonly used "open source" term is a synonym in practice for "free software", so if you are a proprietary software vendor that is source-available but calling it "open source" (when really, it's not) is a different type of misleading.

Don't call source-available proprietary software "open source", or say that you'll "always be open source" if you're just going to be source-available for parts.

Re: Launch HN: Opstrace (YC S19) – open-source Datadog

#114
post #54

> We will always be open source, and we make money by charging a per-user subscription for our commercial version which will contain fine-grained authz, bring-your-own OIDC and custom domains. Seems to me that these are at odds. If you're open source, why does anyone have to pay for these things? If you're open core, I think it's mighty misleading to say things like "We will always be open source" because then not on…

SaaS is a common way for open source companies to create revenue, look no further than WordPress, GitLab, Databricks, DataStax, and many others. Kudos to the opstrace team for taking this path. There’s nothing inherently dishonest when a company emphasizes their open source strategy. Open source community building is as much about shipping code as it is leading people, and that requires you to be transparent about yo…

Open source and proprietary with source publicly available are not the same thing at all.

Re: Launch HN: Opstrace (YC S19) – open-source Datadog

#115
post #109
post #42

Earlier quoted context omitted.

We are still experimenting with pricing and what can be open and closed. To be completely transparent we chose custom domains because we know companies care a lot. When we have more features on the commercial side we can start to chat about supporting it in the open version. Still early in our journey, happy to discuss anything, like a small plan with just custom domains. Would you pay for that?

Yeah. That’s kind of what I mean. I have no problem paying some money to support you guys and not have to host it on my own. I generally prefer my monitoring etc to not be done by myself anyway cause I take myself offline way too often Only point was of there was going to be a smaller plan for homelabs or the like that doesn’t have the raw amount of Traffic or features as the enterprise plans do.

> cause I take myself offline way too often

Haha, the "ouch, what have I done again?" moment... :-).

One of the most interesting lessons from making mistakes is to appreciate the fact that we make mistakes even when we try so hard not to.

Re: Launch HN: Opstrace (YC S19) – open-source Datadog

#116

One pain point with Prometheus is that is has relatively weak support for quantiles, histograms, and sets[1]: - Histograms require manually specifying the distribution of your data, which is time-consuming, lossy, and can introduce significant error bands around your quantile estimates. - Quantiles calculated via the Prometheus "summary" feature are specific to a given host, and not aggregatable, which is almost neve…

Thanks for bringing this topic to this thread. I'm a physicist by heart and education myself and observe that in the software/observability industry we like to collect data much more than we're interested in properly processing and interpreting it.

> Understanding the distribution of your data (rather than just averages) is arguably the most important feature you want from a monitoring dashboard, so the weak support for quantiles is very limiting.

So much yes! It's a relief to see that we have people here in this thread (and industry) who understand this :-).

People that have a deep background and experience in experimentation, measurement, and quantification rightfully have to see the nature of the data distribution first before they feel in any way OK about proceeding with aggregates.

Parent commenter knows this, but for people reading along: using aggregates (such as mean, standard deviation, standard error, quantiles, ...) implies dropping information. Going from the full distribution to a simplified representation naturally implies that what we talk about is a lossy transformation of data. Of course, one wants to be smart about _which_ information to drop. It should be intuitive that one can only be smart about this choice when having knowledge about the underlying distribution. Often, data is not normally distributed, not Poisson-distributed, but instead somewhat uniquely distributed based on the use case -- in a way that deserves brief characterization (a quick look is often enough!); which then allows for making informed decisions about which aggregate parameters to look at -- and which pieces of information are fine to drop.

> Histograms require manually specifying the distribution of your data, which is time-consuming, lossy, and can introduce significant error bands around your quantile estimates.

Yes! Great point. Honestly, I was a little bit shocked when I saw how this works in the Prometheus ecosystem. I happen to have an example for this I think: we (Opstrace) have contributed a tiny patch to Cortex where we changed the parameterization of a specific histogram metric, because the upper band was super broad, leading to a blind spot (a lack of resolution) in the range of values that was most interesting to us -- see https://github.com/cortexproject/cortex/issues/2530 and https://github.com/cortexproject/cortex/pull/2540.

I feel like in our industry when people do the readout and perform some basic dashboarding they're often OK with using aggregates that have not been sanity-checked. That might sometimes be a fair approach. If a readout is not useful, after all one will learn about that very fact through incidents :).

> Veneur[2] addresses these use-cases for applications that use DogStatsD[3] by using clever data structures for approximate histograms[4] and approximate sets[5]

This is extremely interesting, thanks for sharing. We'll have a look!

Having performed many different kinds of data analyses in my science career, I'm rather convinced of the idea that there should be an easy way to perform advanced (yet standard) data analyses for irregular distributions in multi-dimensional data, such as clustering (hierarchical, k-means, DBSCAN, you name it), Principal Component Analysis (PCA), and the likes. I have ideas in this regime -- let's see what makes sense and how far we get with Opstrace!

Again, thanks for the links and for sharing your perspective.

Re: Launch HN: Opstrace (YC S19) – open-source Datadog

#117
post #109

Earlier quoted context omitted.

Yeah. That’s kind of what I mean. I have no problem paying some money to support you guys and not have to host it on my own. I generally prefer my monitoring etc to not be done by myself anyway cause I take myself offline way too often Only point was of there was going to be a smaller plan for homelabs or the like that doesn’t have the raw amount of Traffic or features as the enterprise plans do.

> cause I take myself offline way too often Haha, the "ouch, what have I done again?" moment... :-). One of the most interesting lessons from making mistakes is to appreciate the fact that we make mistakes even when we try so hard not to.

No doubt.

I (generally) like taking myself offline. Thats how I learned everything I know (by fucking up). But thats also why I like to have my mail/monitoring outside my own selfhosted infrastructure. Cause those two things are something that should be running 100% of the time. And if I dont feel like fixing whatever I broke right this moment, I like to feel like I dont have to.

Sometimes I just go to bed whenever I broke something and fix it tomorrow. If I have to flick my light switches by hand until then, so be it, I can live with that. But mail and monitoring cant wait that long :P

Re: Launch HN: Opstrace (YC S19) – open-source Datadog

#118

> opstrace create -c CONFIG_FILE_PATH PROVIDER CLUSTER_NAME > opstrace destroy PROVIDER CLUSTER_NAME > opstrace list PROVIDER I want to keep cluster config in source control, track deployment changes in code reviews, and automate deployments. Do you have any plans to add an 'apply' command to support this? $ opstrace apply -c CONFIG_FILE_PATH [--dry-run] PROVIDER CLUSTER_NAME

Hey! JP from Opstrace here. Thanks for reading through things and for sharing your thoughts. The quick reply is that we still have to introduce a proper cluster config diff and mutation design. An `apply` command might look innocent on the surface. But. Upgrades (including config changes) are hard. Super hard. If it's helping a bit: the entire current Opstrace team has dealt with super challenging platform upgrade sc…

Yes, `apply` is hard. It's just as hard as deploying, maintaining, and turning down a service. When adding an `apply` command to a devops tool, the tool authors must think through the entire lifecycle of their service in the user's workflow and make it work well.

The tool creators are the ones with the knowledge to figure these things out. If they don't provide `apply`, then users must research and experiment and learn by making mistakes. This is a colossal waste of effort. Users end up with brittle poorly-documented scripts to do all the things that `apply` would do. These scripts cause ongoing waste of engineering effort, customer frustration from downtime, and lost business growth and revenue.

I spent several weeks making `apply` commands for InfluxDB [0] and Grafana. This proved extremely difficult for Grafana because of deficiencies in its API. Both InfluxDB and Grafana need some work to make them fit into a modern infrastructure-as-code ops environment. Grafana's cofounder and product lead were not interested in my feedback [1] [2].

[0] https://github.com/cozydate/influxdb-apply

[1] https://news.ycombinator.com/item?id=23136582

[2] https://news.ycombinator.com/item?id=23233468

Re: Launch HN: Opstrace (YC S19) – open-source Datadog

#119

We use [insert very large application performance monitoring tool here] for workloads running in [insert very, very large cloud provider here] and after examining our deployments, concluded that we were spending nearly $13k/mo for data transfer out expenditures because the monitoring agents have crazy aggressive defaults. Seems like running our own (which may be worthwhile) would alleviate anything like that.

Can hurt yourself that way too -- happened to us, but with not a lot of data, and all down to Thanos aggregating/reducing/whatever-ing meeeeeeeeeelions of metrics inside a s3 bucket to the tune of about 7k a month :/

Probably you need monitoring solution that stores data on plain old EBS disks (or GCE persistent disks) such as VictoriaMetrics? Then you don't need to pay for IO operations. And such disks usually have an order of magnitude lower latencies for IO operations than S3, so they may return results faster.

Re: Launch HN: Opstrace (YC S19) – open-source Datadog

#120

One pain point with Prometheus is that is has relatively weak support for quantiles, histograms, and sets[1]: - Histograms require manually specifying the distribution of your data, which is time-consuming, lossy, and can introduce significant error bands around your quantile estimates. - Quantiles calculated via the Prometheus "summary" feature are specific to a given host, and not aggregatable, which is almost neve…

There are log-linear histograms in Prometheus ecosystem. They solve the issue with buckets' selection by using pre-defined buckets that cover the whole value range - https://valyala.medium.com/improving-histogram-usability-for...
Post reply on HN