Question for those in the observability space: do moment-in-time observations preserve all of the dimensions of the event, and if so, how do most observability platforms compress the high volume of (ostensibly) low-rank data?
> low-rank data? It's "low-rank" until that one day systems start shitting the bed, and you're trying to understand what is going on.
Show HN: OneUptime – open-source Datadog Alternative
31–40 of 70 posts
Re: Show HN: OneUptime – open-source Datadog Alternative
#32I may be cynical here, but I find that all open source datadog alternatives are mostly frontend focussed with an out of the box database. And it does not scale well. It's not easy to maintain, scale, shard etc. Am I wrong? P.S. I am all for OSS.
Re: Show HN: OneUptime – open-source Datadog Alternative
#33Is that all datadog is? I read the horror stories, the monthly bills of 10's of thousands for one server and just assumed there was something more substantial to the product; like they did something groundbreaking or novel. I never cared enough to actually look and see what they did. I use uptime-kuma - https://github.com/louislam/uptime-kuma - it obviously does a fraction of what these other things do but it does ev…
Oddly enough, this is why we started OneUptime in the first place. We were burned by the DataDog bill and wanted an open source observability platform ourselves.
I used to work on a growing AWS product with tons of features that no one used.
Often when we were creating a feature, our managers would have us include tags and support for making parts of the feature optional, but make sure no parts of the feature (or the feature itself) where optional to start with. We would enable the ability to toggle the feature if "A significant enough amount of customers weighted by revenue requested it".
Also got the "Build filtering, but don't expose it unless we have to".
Re: Show HN: OneUptime – open-source Datadog Alternative
#34Re: Show HN: OneUptime – open-source Datadog Alternative
#35Question for those in the observability space: do moment-in-time observations preserve all of the dimensions of the event, and if so, how do most observability platforms compress the high volume of (ostensibly) low-rank data?
Columnar databases are very good at compressing time series data which often has runs of repeating values that can be run length encoded, repeating deltas (store the delta not the full value), or common strings that can be dictionary encoded. So you can persist a lot of raw data with quite good compression and fast-scannability. Most commercial TSDBs are now backed by column stores. And several now tier with local SSDs for hot data and S3 for colder data.
If that's still too much data to store, you have to start throwing some away. Both sampling and materializing aggregates (and discarding the raw data) are popular techniques and can both be very reasonable trade offs.
Re: Show HN: OneUptime – open-source Datadog Alternative
#36Earlier quoted context omitted.
Just about every advertised Datadog alternative does maybe 10% of what Datadog can do, and likely has hundreds less pluggable integrations than Datadog. While it may be the case that it's overkill for a simple application, one of the biggest benefits to Datadog is that there's an integration for just about anything, and the product can go deep if you need it to. The "omg my bill is out of control" issue is usually ma…
Correct. Same as New Relic. I'd love an open source alternative. But there just isn't one for APM (which is our main use case). Nothing comes close. Every time I see "OpenTelemetry integration" I just close the page. Hours and hours of manual setup, code pushes, etc while New Relic installs once and works. I assume it's the same for people who use DataDog begrudgingly.
Depending on the language/environment/framework, OpenTelemetry Autoinstrumentation just works. It's the new standard, and lots of working is ongoing to make it work for everything, everywhere, and even the big observability vendors are adopting it.
Re: Show HN: OneUptime – open-source Datadog Alternative
#37I can see some commits mentioning telemetry but it's not at all mentioned on the GitHub README. Strange. It looks solid and I'd try it if the need arises.
Re: Show HN: OneUptime – open-source Datadog Alternative
#38Earlier quoted context omitted.
Just about every advertised Datadog alternative does maybe 10% of what Datadog can do, and likely has hundreds less pluggable integrations than Datadog. While it may be the case that it's overkill for a simple application, one of the biggest benefits to Datadog is that there's an integration for just about anything, and the product can go deep if you need it to. The "omg my bill is out of control" issue is usually ma…
Correct. Same as New Relic. I'd love an open source alternative. But there just isn't one for APM (which is our main use case). Nothing comes close. Every time I see "OpenTelemetry integration" I just close the page. Hours and hours of manual setup, code pushes, etc while New Relic installs once and works. I assume it's the same for people who use DataDog begrudgingly.
Re: Show HN: OneUptime – open-source Datadog Alternative
#39I may be cynical here, but I find that all open source datadog alternatives are mostly frontend focussed with an out of the box database. And it does not scale well. It's not easy to maintain, scale, shard etc. Am I wrong? P.S. I am all for OSS.
In theory, you can get away with just running a Clickhouse instance purely backed by S3 to get durability + scalability (at the cost of performance of course). It all depends on what scale you're running at and the HA/performance requirements you need.
Re: Show HN: OneUptime – open-source Datadog Alternative
#40Earlier quoted context omitted.
Just about every advertised Datadog alternative does maybe 10% of what Datadog can do, and likely has hundreds less pluggable integrations than Datadog. While it may be the case that it's overkill for a simple application, one of the biggest benefits to Datadog is that there's an integration for just about anything, and the product can go deep if you need it to. The "omg my bill is out of control" issue is usually ma…
For us it was the mismatch between AWS and Datadog billing (AWS bills by the second, Datadog bills by the hour, so you should only ever use Datadog for persistent instances, not high churn instances like dynamic background jobs, or else completely rearchitect your application for the benefit of a vendor)