It's pretty hard to tell from the website what this product does, and the submitted title ("Polar Signals Cloud Is Generally Available") doesn't explain anything, so I replaced it with a phrase from https://www.polarsignals.com/blog/posts/2023/10/10/polarsign... that seems to say something.
Polar Signals Cloud: Always-on, zero-instrumentation continuous profiling
11–20 of 28 posts
Re: Polar Signals Cloud: Always-on, zero-instrumentation continuous profiling
#12Congrats on the launch! Continuous profiling is a game changer and once you use it on your production systems you can't do without it.
The first time we got differential flamegraphs working we were so mesmerised that we could finally see exactly what the difference between a low and a high point (like a CPU spike) was, that we clicked around our own code for a good hour.
Re: Polar Signals Cloud: Always-on, zero-instrumentation continuous profiling
#13Hey HN! Myself and several members of the Polar Signals team have been long time Observability ecosystem maintainers of projects such as Prometheus, Thanos, Cortex, Kubernetes and many more. In 2018 we read the "Google-Wide Profiling" paper and immediately realized we have to treat profiling just like any other Observability data, by systematically and comprehensively collecting it for our entire infrastructure and a…
Congratulations on the launch, it's been great watching your journey so far.
Re: Polar Signals Cloud: Always-on, zero-instrumentation continuous profiling
#14Hey HN! Myself and several members of the Polar Signals team have been long time Observability ecosystem maintainers of projects such as Prometheus, Thanos, Cortex, Kubernetes and many more. In 2018 we read the "Google-Wide Profiling" paper and immediately realized we have to treat profiling just like any other Observability data, by systematically and comprehensively collecting it for our entire infrastructure and a…
Re: Polar Signals Cloud: Always-on, zero-instrumentation continuous profiling
#15Hey HN! Myself and several members of the Polar Signals team have been long time Observability ecosystem maintainers of projects such as Prometheus, Thanos, Cortex, Kubernetes and many more. In 2018 we read the "Google-Wide Profiling" paper and immediately realized we have to treat profiling just like any other Observability data, by systematically and comprehensively collecting it for our entire infrastructure and a…
The pricing tiers seem a bit rough for small shops. One to 44 CPUs are the same 50 dollars per month right? I work a very small shop with just me as the developer and just one server. I'd really like something smaller.
https://calendly.com/frederic-branczyk/getting-to-know-polar...
Re: Polar Signals Cloud: Always-on, zero-instrumentation continuous profiling
#16Hey HN! Myself and several members of the Polar Signals team have been long time Observability ecosystem maintainers of projects such as Prometheus, Thanos, Cortex, Kubernetes and many more. In 2018 we read the "Google-Wide Profiling" paper and immediately realized we have to treat profiling just like any other Observability data, by systematically and comprehensively collecting it for our entire infrastructure and a…
I did some digging in your blog history and it seems that is referencing https://www.polarsignals.com/blog/posts/2022/07/22/frostdb-i... and digging into the "but why?" section https://github.com/polarsignals/frostdb#why-you-should-use-f...> seems to imply you favored the embedded feature over having something standalone, but I would enjoy hearing (or reading a blog post!) about why you felt it was a better use of your engineering to make your own columar DB versus using one of the existing columanr dbs that I have seen referenced a ton in other Show HN announcements around both logging and metrics services
Re: Polar Signals Cloud: Always-on, zero-instrumentation continuous profiling
#17Hey HN! Myself and several members of the Polar Signals team have been long time Observability ecosystem maintainers of projects such as Prometheus, Thanos, Cortex, Kubernetes and many more. In 2018 we read the "Google-Wide Profiling" paper and immediately realized we have to treat profiling just like any other Observability data, by systematically and comprehensively collecting it for our entire infrastructure and a…
> In addition to that we built a custom columnar database I did some digging in your blog history and it seems that is referencing https://www.polarsignals.com/blog/posts/2022/07/22/frostdb-i... and digging into the "but why?" section https://github.com/polarsignals/frostdb#why-you-should-use-f... > seems to imply you favored the embedded feature over having something standalone, but I would enjoy hearing (or reading…
The big one that existing columnar databases can’t do (or not well), is the ability to search and aggregate on user defined dimensions (think prometheus-style labels). Influx 3.0 is the only other columnar database that is (now) available that was engineered specifically to be able to do this. The good folks at honeycomb came to the same conclusion that this type of columnar database (wide column) is necessary to build Observability with exceptional user experience. Plus we now own our future and can do any kind of optimization while other companies (and I’ve spoken to them) constantly fear ClickHouse relicensing or otherwise destroying their business.
//edit: we call this feature dynamic columns: https://github.com/polarsignals/frostdb#dynamic-columns
Re: Polar Signals Cloud: Always-on, zero-instrumentation continuous profiling
#18Re: Polar Signals Cloud: Always-on, zero-instrumentation continuous profiling
#19I was excited to see Haskell in one of the screenshots (“difference detection”) only to realize that Haskell is not in the list of supported languages :(
Re: Polar Signals Cloud: Always-on, zero-instrumentation continuous profiling
#20Congratulations on the launch! I'm a huge proponent using eBPF for profiling and observability in general. I noticed pricing doesn't include anything about data retention. Does the data live indefinitely? How far back can I query?
Great question! At the moment it is 30 days. We've had a few requests to make that configurable, but the reality is that the most costly part is to lay it out in an optimized way in the first place which happens very early on in the ingestion path, and from there on it's only object storage cost, so if there is customer demand we can increase this.
I’ve enjoyed having 3-5 years of prom metrics retention to look at seasonal traffic trends but we spent a fair bit of CPU aggregating raw metrics down to the right granularity for that kind of long term retention. My feeling is that the observability world is moving towards small, localized installations with real-time data and separate systems with cheaper, slower, but long term retention. Curious how you see it as you’re building a product in the space.