Live data from Hacker News

Chronosphere launches with $11M Series A to build scalable monitoring tool

techcrunch.com

31–39 of 39 posts

Re: Chronosphere launches with $11M Series A to build scalable monitoring tool

#31
post #23

Splunk kool-aid drinker here; pardon my ignorant question, but why not just use Splunk? Actually I think my real question is, why are there such a proliferation of these monitoring/logging/visualization -AAS startups? Who are the target customers, in terms of spends?

The most obvious answer is most of the new alternatives are open source and “free” while Splunk isn’t.

Re: Chronosphere launches with $11M Series A to build scalable monitoring tool

#32
Is the name inspired by the building in C&C Red Alert by any chance?

https://cnc.fandom.com/wiki/Chronosphere_(Red_Alert_3)

That’s my personal reference to the word, but searching around a bit, it seems that it was registered as a trademark by a medical company already in 1991, 5 years before Red Alert.

https://trademark.trademarkia.com/chronosphere-74147725.html

Re: Chronosphere launches with $11M Series A to build scalable monitoring tool

#33
post #26
post #25

Earlier quoted context omitted.

New Relic touts collecting trillions of data points per day.

According to https://eng.uber.com/m3/ > Released in 2015, M3 now houses over 6.6 billion time series. M3 aggregates 500 million metrics per second and persists 20 million resulting metrics-per-second to storage globally (with M3DB), using a quorum write to persist each metric to three replicas in a region. So, if that's accurate, they're collecting one trillion data points every two seconds .

No, they're collecting one BILLION (with a b) data points every two seconds. Gotta go to 2000 seconds (a little over half an hour) for the TRILLION.

With a 25:1 reduction/summarization before writing. If they're smart, they do that summarization on the way in, rather than at the back-end layer. That's a billion data points written per minute, or a trillion and a half written per day!

Re: Chronosphere launches with $11M Series A to build scalable monitoring tool

#34
post #26
post #25

Earlier quoted context omitted.

New Relic touts collecting trillions of data points per day.

According to https://eng.uber.com/m3/ > Released in 2015, M3 now houses over 6.6 billion time series. M3 aggregates 500 million metrics per second and persists 20 million resulting metrics-per-second to storage globally (with M3DB), using a quorum write to persist each metric to three replicas in a region. So, if that's accurate, they're collecting one trillion data points every two seconds .

So we collected and aggregated more than 1 billion samples of metrics per second, which resulted in writing more than 30-40 million unique metric datapoints per second to storage. This resulted in more than 10 billion unique time series being stored (each with a very large number of distinct datapoints each).

This was 3.6 trillion metric samples per hour or 2.5 trillion metric datapoints stored a day (after aggregating samples).

Re: Chronosphere launches with $11M Series A to build scalable monitoring tool

#35
One thing that I often miss when reading about this stuff is benchmarks. So it's faster than Prometheus? Prove it. So it's faster than Postgres, or TimescaleDB? Prove it.

It should be trivial, and the fact that it's not there and what you find instead is terms like "Uber-scale" is slightly worrying.

I'm not trying to take anything away from the achievements made here by the guys at Uber, but anyone seriously considering using this in production would probably need a better contrastive comparison between alternatives.

Re: Chronosphere launches with $11M Series A to build scalable monitoring tool

#37
post #33
post #26

Earlier quoted context omitted.

According to https://eng.uber.com/m3/ > Released in 2015, M3 now houses over 6.6 billion time series. M3 aggregates 500 million metrics per second and persists 20 million resulting metrics-per-second to storage globally (with M3DB), using a quorum write to persist each metric to three replicas in a region. So, if that's accurate, they're collecting one trillion data points every two seconds .

No, they're collecting one BILLION (with a b) data points every two seconds. Gotta go to 2000 seconds (a little over half an hour) for the TRILLION. With a 25:1 reduction/summarization before writing. If they're smart, they do that summarization on the way in, rather than at the back-end layer. That's a billion data points written per minute, or a trillion and a half written per day!

Oops, don't know how I misread that! Thanks for the correction!

Re: Chronosphere launches with $11M Series A to build scalable monitoring tool

#38
post #27

The technical details of their software are described in https://eng.uber.com/m3/ This looks like a competitor to Cortex ( https://www.cncf.io/blog/2018/12/18/cortex-a-multi-tenant-ho... ).

They took a different path on the ”never build your own database” question.

Another viable player that took the path similar to M3DB is VictoriaMetrics [1]. This allowed implementing various features [2] and optimizations [3] without the need to negotiate their integration into upstream Prometheus. Such negotiations can stuck forever. [4]

[1] https://github.com/VictoriaMetrics/VictoriaMetrics/

[2] https://github.com/VictoriaMetrics/VictoriaMetrics/wiki/Exte...

[3] https://medium.com/@valyala/measuring-vertical-scalability-f...

[4] https://github.com/prometheus/prometheus/issues/3746

Re: Chronosphere launches with $11M Series A to build scalable monitoring tool

#39
post #35

One thing that I often miss when reading about this stuff is benchmarks. So it's faster than Prometheus? Prove it. So it's faster than Postgres, or TimescaleDB? Prove it. It should be trivial, and the fact that it's not there and what you find instead is terms like "Uber-scale" is slightly worrying. I'm not trying to take anything away from the achievements made here by the guys at Uber, but anyone seriously consider…

It's not raw speed or raw performance on a single node that M3DB is optimized for, it's for a reliable scale out story when you have a considerable number of instances required to collect the raw data you operate on (organizations of certain size/complexity run into this, not just a handful of organizations/companies).

Benchmarks tend to favor the authors and are frequently game-ified, look at GPU benchmarks like 3DMark that frequently had manufacturers release optimizations that were really only utilized in specific benchmarks.

Post reply on HN