[Denzel]

The headline feels deliberately clickbait-y and disingenuous. I love and support the idea. Aspirationally, the founders may want to compete with Datadog, but OpsTrace overlaps some small percentage of Datadog’s feature set.

I’m surprised the mods haven’t edited this title.

Source: I’m an engineer that’s used, operated and hacked on a medium-sized prom+grafana; and used Datadog at a large, multi-region, global scale.

[jgehrcke]

I'd love to chime in, too, and say thank you for sharing this perspective. It's totally understandable, and this HN thread wouldn't be complete and genuine w/o this talking point. Based on your experience, we'd certainly appreciate for you to keep an eye on how our product evolves! Super interested in your expertise and opinions. Thanks again for not being afraid of being 'that guy'.

[dang]

Sorry about that! I didn't see anything wrong with the title but I'm not familiar with Datadog's feature set. If you take the title as aspirational, it may make more sense.

[Denzel]

No need to be sorry, you do a great job moderating HN dang!

I just felt let down because the promise of the title (which I was excited by) doesn’t match reality in that it’s quite impossible to deliver Datadog’s feature set for metrics, traces, and logs — and tie all three together — on top of prometheus+grafana because the underlying TSDB doesn’t even support the notion of user-customizable indexing. Prometheus indexes all labels, which is why most Prometheus users even have to worry about high cardinality and time series explosion. This is one point highlighting how OpsTrace’s current architecture can not satisfy their positioning; there are many more. I’m sure they’re aware of them.

As an aspiration, the title makes sense. As someone in their target market, I was a bit turned off by the embellishment.

[fat-apple]

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 it’s all in one place (S3/GCS) other technologies can be leveraged to create a higher level query language across everything, such as PrestoDB (one would have to build backends for it), or even a new dedicated open source columnar store.

[Denzel]

> 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!

[spahl]

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

[spahl]

It's definitely aspirational. With time and work the features gap (for the important ones) will narrow:-)

What we want to emphasize is that it is possible to build this and have the advantages of a Datadog without the drawbacks.

[fat-apple]

Thanks for your support! We’re still early in our journey when compared to the featureset Datadog has built over time, but we definitely aspire to bridge the best of Datadog and open source. Based on your experience, what sorts of features would you prioritize to get there?