[HN Gopher] Show HN: ClickStack - Open-source Datadog alternativ...
___________________________________________________________________
Show HN: ClickStack - Open-source Datadog alternative by ClickHouse
and HyperDX
Hey HN! Mike & Warren here from HyperDX (now part of ClickHouse)!
We've been building ClickStack, an open source observability stack
that helps you collect, centralize, search/viz/alert on your
telemetry (logs, metrics, traces) in just a few minutes - all
powered by ClickHouse (Apache2) for storage, HyperDX (MIT) for
visualization and OpenTelemetry (Apache2) for ingestion. You can
check out the quick start for spinning things up in the repo here:
https://github.com/hyperdxio/hyperdx ClickStack makes it really
easy to instrument your application so you can go from bug reports
of "my checkout didn't go through" to a session replay of the user,
backend API calls, to DB queries and infrastructure metrics related
to that specific request in a single view. For those that might be
migrating from Very Expensive Observability Vendor (TM) to
something open source, more performant, and doesn't require
extensive culling of retention limits and sampling rates -
ClickStack gives a batteries-included way of starting that
migration journey. For those that aren't familiar with ClickHouse,
it's a high performance database that has already been used by
companies such as Anthropic, Cloudflare, and DoorDash to power
their core observability at scale due to its flexibility, ease of
use, and cost effectiveness. However, this required teams to
dedicate engineers to building a custom observability stack, where
it's difficult to not only get their telemetry data easily into
ClickHouse but also struggling without a native UI experience.
That's why we're building ClickStack - we wanted to bundle an easy
way to get started ingesting your telemetry data whether it's logs
& traces from Node.js or Ruby to metrics from Kubernetes or your
bare metal infrastructure. Just as important we wanted our users to
enjoy a visualization experience that allowed users to quickly
search using a familiar lucene-like search syntax (similar to what
you'd use in Google!). We recognise though, that a SQL mode is
needed for the most complex of queries. We've also added high
cardinality outlier analysis by charting the delta between outlier
and inlier events - which we've found really helpful in narrowing
down causes of regressions/anomalies in our traces as well as log
patterns to condense down clusters of similar logs. We're really
excited about the roadmap ahead in terms of improving ClickStack as
a product and the ClickHouse core database to improve
observability. Would love to hear everyone's feedback and what they
think! Spinning up a container is pretty simple: `docker run -p
8080:8080 -p 4317:4317 -p 4318:4318
docker.hyperdx.io/hyperdx/hyperdx-all-in-one` In browser live demo
(no sign ups or anything silly, it runs fully in your browser!):
https://play.hyperdx.io/ Landing Page: https://clickhouse.com/o11y
Github Repo: https://github.com/hyperdxio/hyperdx Discord
community: https://hyperdx.io/discord Docs:
https://clickhouse.com/docs/use-cases/observability/clicksta...
Author : mikeshi42
Score : 135 points
Date : 2025-06-05 18:01 UTC (4 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| readdit wrote:
| I like and use HyperDX in production and like it a lot. So kudos
| to the team for building and merging with Clickhouse. I found a
| lot of monetary value switching over to HyperDX considering it's
| significantly more cost efficient for our needs.
|
| Should we be starting to prepare for the original HyperDX product
| to be deprecated and potentially move over to ClickStack?
| mikeshi42 wrote:
| First off, always really excited to hear from our production
| users - glad to hear you're getting good value out of the
| platform!
|
| HyperDX isn't being deprecated, you can probably see on the
| marketing page it's still really prominently featured as an
| integral part of the stack - so nothing changing there.
|
| We do of course want to get users onto HyperDX v2 and the
| overall ClickStack pattern. This doesn't mean HyperDX is going
| away by any means - just that HyperDX is focused a lot more on
| the end-user experience, and we get to leverage the
| flexibility, learnings and performance of a more exposed
| ClickHouse-powered core which is the intent of ClickStack. On
| the engineering side, we're working on making sure it's a
| smooth path for both open source and cloud.
|
| side note: weird I thought I replied to this one already but
| I've been dealing with spotty wifi today :)
| codegeek wrote:
| How are you different than Signoz, another YC company that also
| does Observability using clickhouse ?
| oatsandsugar wrote:
| "You" here is ClickHouse
| ksec wrote:
| It would have even much better if the link was pointing to
| https://github.com/hyperdxio/hyperdx the actual source code.
|
| Because right now without the message on HN here, I wouldn't know
| what "open source observability stack" meant when the webpage
| does not explain what HyperDX is, nor does it provide a link to
| it or its code. I was expecting the whole thing "Open Source
| Datadog" to be ClickStack Repo inside Clickhouse Github. Which is
| not found anywhere.
|
| But other than that congrats!. I have long wondered why no one
| has built anything on top of Clickhouse for Datadog / New Relic
| competition.
|
| The Clickhouse DB opened up the ocean of open source "Scalable"
| Web Analytics that wont previously available or possible. I am
| hoping we see this change again to observability platform as
| well.
| mikeshi42 wrote:
| Hey that's a good point on the link! Not something I can change
| now unfortunately, I was hoping having it near the top of the
| text post would help too for those that wanted to dig in more
| :)
|
| That being said - as you've mentioned so many different "store
| tons of data" apps have been enabled from ClickHouse.
| Observability is at a point where it's in the same category of:
| ClickHouse can store a ton of data, OTel can help you
| collect/process it, and now we just need that analytics user
| experience layer to present it to the engineers that need an
| intuitive way to dive in to it all.
| sirfz wrote:
| SigNoz is a dd/nr alternative built on clickhouse that I know
| of
| cbhl wrote:
| Looks like it is pointing there now; old link was
| https://clickhouse.com/use-cases/observability for posterity
| hosh wrote:
| I liked Otel for traces and maybe logging -- but I think the Otel
| metrics is over-engineered.
|
| Does ClickStack have a way to ingest statsd data, preferably with
| Datadog extensions (which adds tagging)?
|
| Does ClickStack offer correlations across traces, logging, and
| metrics via unified service tagging? Does the UI offer the
| ability to link to related traces, logging, and metrics?
|
| Why does the Elixir sdk use the hyperdx library instead of the
| otel library?
|
| Are Notebooks in the roadmap?
| phillipcarter wrote:
| > but I think the Otel metrics is over-engineered.
|
| What about OTel metrics is difficult?
|
| You can set up receivers for other metrics sources like stasd
| or even the DD agent, so there's no need to immediately replace
| your metrics stack.
| carefulfungi wrote:
| My foray into otel with aws lambda was not a success (about 6
| months ago). Many of my issues were with the prom remote
| writer that I had to use. The extension was not reliable.
| Queue errors were common in the remote writer. Interop with
| Prometheus labels was bad. And the various config around
| delta and non-delta metrics was a bit of a mess. The stack I
| was using at least didn't support exponential histograms. Got
| it to work mostly after days of fiddling but never reliably.
| Ripped it out and was happier. Maybe a pure OTEL stack would
| have been a much better experience than needing the prom
| remote writer - which I'd like to try in the future.
|
| I'd certainly appreciate hearing success stories of OTEL +
| serverless.
| mikeshi42 wrote:
| Great questions!
|
| OTel Metrics: I get it, it's specified as almost a superset of
| everyone's favorite metric standards with config for push/pull,
| monotonic vs delta, exponential/"native" histograms, etc. I
| have my preferences as well which would be a subset of the
| standard but I get why a unifying standard needed to be
| flexible.
|
| Statsd: The great thing about the OTel collector is that it
| allows ingesting a variety of different data formats, so you
| can take in statsd and output OTel or write directly to
| ClickHouse: https://github.com/open-telemetry/opentelemetry-
| collector-co...
|
| We correlate across trace/span id as well as resource
| attributes. The correlation across logs/traces with span/trace
| id is a pretty well worn path across our product. Metrics to
| the rest is natively done via resource attributes and we
| primarily expose correlation for K8s-based workloads with more
| to come. We don't do exemplars _yet_ to solve the more generic
| correlation case for metrics (though I don't think statsd can
| transmit exemplars)
|
| Elixir: We try to do our best to support wherever our users
| are, the OTel SDK and ours have continued to change in parallel
| over time - we'll want to likely re-evaluate if we should start
| pointing towards the base OTel SDK for Elixir. We've been
| pretty early on the OTel SDK side across the board so things
| continue to evolve, for example our Deno OTel integration came
| out I think over a year before Deno officially launched one
| with native HyperDX documentation <3
|
| Notebooks: Yes, it should land in an experimental state
| shortly, stay tuned :) There's a lot of exciting workflows
| we're looking to unlock with notebooks as well. If you have any
| thoughts in this direction, please let me know. I'd love to get
| more user input ahead of the first release.
| user3939382 wrote:
| There's so many of these log aggregators I've completely lost
| track. I used Datadog extensively and found it overpriced and a
| very confusing UI.
| RhodesianHunter wrote:
| That's what happens when there's a need for something.
|
| You see an explosion in offerings, and then eventually it's
| whittled down to a handful of survivors.
| secondcoming wrote:
| _Everyone_ has found Datadog to be overpriced!
|
| So they switch to Prometheus and Grafana and now have to manage
| a Prometheus cluster. Far cheaper, but far more annoying.
| Immortalin wrote:
| I remember back in the day Mike was building Huggingface before
| Huggingface was a thing. He was ahead of his time. It's a pity
| model depot is no longer around.
| mikeshi42 wrote:
| Wow this is an incredible throwback! Can't believe your memory
| is this good. It's quite funny and I totally agree - I met the
| Gradio founders in an accelerator (when they were just getting
| started) after we shut down ModelDepot - and they of course
| ended up getting acquired into Hugging Face. It's funny how
| things end up sometimes :)
| bilalq wrote:
| This is really interesting.
|
| Is Clickhouse the only stateful part of this stack? Would love to
| see compatbility with Rotel[0], a Rust implementation of the OTEL
| collector, so that this becomes usable for serverless runtime
| environments.
|
| One key thing Datadog has is their own proprietary alternative to
| the OTEL collector that is much more performant.
|
| [0]: https://github.com/streamfold/rotel
| mikeshi42 wrote:
| I agree - rotel seems like a really good fit for a lightweight
| lambda integration for OTel, it of course should work already
| since we stand up an OTel ingest endpoint so it should be
| seamless to send data over! (Kind of the beauty of OTel of
| course)
|
| I've also been in touch with Mike & Ray for a bit, who've told
| me they've added ClickHouse support recently which makes the
| story even better :)
| mike_heffner wrote:
| Hi all -- one of the authors of Rotel here. Thanks for the
| kind words, Bilal and Michael.
|
| We're excited to test our Clickhouse integration with
| Clickstack, as we believe OTel and Clickhouse make for a
| powerful observability stack. Our open-source Rust
| OpenTelemetry collector is designed for high-performance,
| resource-constrained environments. We'd love for you to check
| it out!
| buserror wrote:
| I am absolutely _amazed_ at the amount of garbage being
| "logged", enough that it is not just a huge business, but also
| one of the primary task for some devops guys. It's like a goal in
| itself, you have a look at the output and it is absolutely scary,
| HUGE messages being "logged" for purpose unknown.
|
| I've seen single traces over 100KB of absolute pure randomness
| encoded as base64... Because! Oh and also, we have to pay for the
| service, so it looks important.
|
| Sure they tell you it is super helpful for debugging issues, but
| in a VERY large proportion of cases, it is 1) WAY too much, and
| 2) never used anyway. And most of the time what's interesting is
| the last 10 minutes of the debug version, you don't need a
| "service" for that.
|
| /me gets down his horse :-)
| SOLAR_FIELDS wrote:
| Comparison to the other player in this space, Signoz? Also uses
| clickhouse as backend
___________________________________________________________________
(page generated 2025-06-05 23:00 UTC)