kirankgollu

Thanks varun! let us know what you think about surfacing agent failures automatically, happy to help with onboarding if that helps.

Good to know. Could you share your vendor and capabilities and pricing page please?

Our approach is that you need not worry about this. Oodle will be able to handle any scale including the ephemeral metrics.

Secondly, we only look at the unique time series in an hour when computing the billing. This should help us handle ephemeral metrics a lot better compared to many disk based data stores.

Finally, we do support high cardinality since the underlying datastore is columnar. Existing customers are sending on the order of few million cardinality per metric.

re: storing high cardinality metrics in disk vs in-memory index, vijay will comment shortly.

It's not a fair comparison. You can't compare the base tier pricing of Oodle offering with the high scale tier of victoria metrics. As you scale, volume benefits kick in just like the way they are for VM. It's a common wisdom that enterprise companies don't swipe credit cards beyond 50k/year. We request our customers to speak with us when they get to high scale tiers.

250k metrics - Oodle is 5x cheaper, < 5M metrics - Oodle 2-3x cheaper, beyond 5M - talk to us (our pricing will be competitive and will be better)

As suggested in earlier message, this pricing is only for single node. imo, this needs to be compared to cluster mode - any company with meaningful scale will need reliabilty and needs to run in cluster mode since you’d need your observability systems to be up and running when the rest of your systems are down.

your comment said "no magic" and the links points to "#magic-behind-oodle". May be I misread your comment or you didn't mean that.

Not a fan of bad mouthing other offerings. As @iampims is saying, alerts is a big missing piece. Clickhouse is also a general purpose database for many use cases including analytics, financial servers, ML& Gen AI, fraud, and observability.

It'd be nice to post a disclaimer if you are working on a competing offering before you post a comment. (for the benefit of everyone)

Thank you for the feedback. we will keep an eye out for more inputs from our users on this topic.

We believe there are clear benefits of open source. In fact, we believe in it so much that we made our product OSS compatible from Day 1. (btw, not every observability product is OSS compatible).

We also understand not everyone's evaluation criteria is the same. Upon speaking with number of our early users, we repeatedly found that what really matters is "is the product reliable, cost-effective?", "is the product easy to use and open source compatible?", "is the product easy to migrate in/out?". So, we tried to address those head on. We also heard some open source solutions are indeed unreliable especially at scale e.g. Prometheus has scaling challenges beyond 2M+ active time series / hour and it is not horizontally scalable. People tend to over-provision CPU/Memory, despite that queries time out at any meaningful scale high cardinality queries (this is a well understood problem).

Ability to inspect code, do patches themselves may be an evaluation criteria for some users, we found that it was not the major evaluation criteria among our users. I've led multiple evaluations at Rubrik (open source + non-open source), ability to patch software was not the most important criteria - reliability, operational overhead, cost, ease of use, and ability to switch in/out were may more important.

That's fair.

We actually started with "reduce your costs by 3-10x with infinite scalability" without talking about storing in s3 and serverless (along the lines of your thinking - only talk about benefits + what you do). But our users, engineers by their very nature, were skeptical about how Oodle works, so we ended up settling on a combination of why, what and how. This resonated better with our early customers and prospects.