Live data from Hacker News

Show HN: HyperDX – open-source dev-friendly Datadog alternative

github.com

71–80 of 186 posts

Re: Show HN: HyperDX – open-source dev-friendly Datadog alternative

#71

Earlier quoted context omitted.

Alternatives depend on what the goals of the person or organization who wrote the code are. There are various FOSS and source available options that can grant some freedoms while protecting others for the creator, such as if they want to let users still contribute and view the source. My main point was you should get these ducks in order first and be genuine with your intentions. Don't use FOSS as a growth hack, it n…

I'd genuinely would love to learn the OSS options we'd have available here, as we'd genuinely want to build a sustainable open source project and community, while preserving as many user freedoms as possible. I think that HyperDX is a bit different from tools like Mongo, Redis or Hashicorp in that we're a vertically integrated product from SDKs/UIs to ingestion pipeline and DBs, which is opposite kind of offering fro…

> we'd genuinely want to build a sustainable open source project and community

How do you plan on doing that while being VC-backed? Why did you choose to be VC backed in the first place? You can create a sustainable open source project and community without any VC funding.

Re: Show HN: HyperDX – open-source dev-friendly Datadog alternative

#72
post #70

This looks really cool, congrats on the launch! I haven’t had time to dig in proper, but this seems like something that would fit perfectly for “local dev” logging as well. I struggled to find a good solution for this, ending up Winston -> JSON, with a simpler “dump to terminal” script running. (The app I’m building does a ton of “in the background” work, and I wanted to present both “user interactions” and “backgrou…

Thank you! We do support Winston (docs: https://www.hyperdx.io/docs/install/javascript#winston-trans...) and use it a lot internally. Let me know if you run into any issues with it (or have suggestions on how to make it more clear)

In fact this is actually how we develop locally - because even our local stack is comparatively noisy, we enable self-logging in HyperDX so our local logs/traces go to our own dev instance, and we can quickly trace a 500 that way. (Literally was doing this last night for a PR I'm working on).

Re: Show HN: HyperDX – open-source dev-friendly Datadog alternative

#73

Wow, there is a lot here and what here is to a pretty impressive level of polish for how far along this is. The background of someone with a DX background comes through! I will be looking into this a lot more. Here are a few comments, notes, and questions: * I like the focus on DX (especially compared to other OSS solutions) in your messaging here, and I think your hero messaging tells that story, but it isn't reinfo…

Thank you, really appreciate the feedback and encouragement! > It seems like clickhouse is obviously a big piece of the tech here, which is an obvious choice, but from my experience with high data rate ingest, especially logs, you can run into issues at larger scale. Is that something you expect to give options around in open source? Scaling any system can be challenging - our experience so far is that Clickhouse is…

Thanks for the answers Mike!

One more follow-up on the scale side (which I mentioned with sibling comment), it isn't so much about clickhouse itself, but about scaling up ingest. From my own experience and from talking with quite a few APM players (I previously worked in streaming space), a Kafka / durable log storage kind of becomes a requirement, so I was curious if you think at some point you need a log to further scale ingest.

For enterprise side, I was previously in data streaming space and had quite a few conversations with APM players and companies building their own observability platforms, happy to chat and share more if that would be useful!

Re: Show HN: HyperDX – open-source dev-friendly Datadog alternative

#74
post #23

Looks very similar to what we're doing at https://highlight.io . Would love to trade notes at some point. One thing to consider with your messaging is that when you start speaking to large companies, they won't see you as a datadog alternative. They'll see you as a mix of sentry + fullstory + honeycomb. Datadog originally found its success with its metrics products, and the larger the buyer of datadog gets, the more…

You're charging for your product, this is MIT licensed. As the meme goes, "we are not the same."

As other commenters mentioned, we are both comparable (pending your opinion on the MIT license).

We both charge a cloud saas fee as well:

https://www.hyperdx.io/pricing https://www.highlight.io/pricing

Re: Show HN: HyperDX – open-source dev-friendly Datadog alternative

#75

Earlier quoted context omitted.

Thank you, really appreciate the feedback and encouragement! > It seems like clickhouse is obviously a big piece of the tech here, which is an obvious choice, but from my experience with high data rate ingest, especially logs, you can run into issues at larger scale. Is that something you expect to give options around in open source? Scaling any system can be challenging - our experience so far is that Clickhouse is…

Thanks for the answers Mike! One more follow-up on the scale side (which I mentioned with sibling comment), it isn't so much about clickhouse itself, but about scaling up ingest. From my own experience and from talking with quite a few APM players (I previously worked in streaming space), a Kafka / durable log storage kind of becomes a requirement, so I was curious if you think at some point you need a log to further…

Ah got it, yeah a queue of some sort is definitely useful when scaling up to buffer pre-inserted data. This is something on the OSS side we've kept open to implementation. However it's something that is highly coupled with infra footprint and internal SLA guarantees the user wants to preserve. It can range anywhere from just rely on client-side retries to setting up a HA Kafka cluster early in the ingestion pipeline.

Similar to Elastic - I think a lot of architectures are available to choose on that side when users want to scale.

Will reach out to connect!

Re: Show HN: HyperDX – open-source dev-friendly Datadog alternative

#76

This looks really promising, will definitely look into using this for a project i'm working on! Btw I've used both datadog and newrelic in large-scale production apps and for the costs I still am not very impressed by the dx/ux. If hyperdx can undercut price and deliver parity features/dx (or above) i can easily see this doing well in the market. Good luck!

Datadog feels like they've used a shotgun to shoot functionality all over the place. New Relic felt a bit more focused, but even then I had to go attend a New Relic seminar to properly learn how to use the bloody thing.

Re: Show HN: HyperDX – open-source dev-friendly Datadog alternative

#77

Earlier quoted context omitted.

Just clarifying, your alternative to open core is open nothing? Just proprietary it up?

Alternatives depend on what the goals of the person or organization who wrote the code are. There are various FOSS and source available options that can grant some freedoms while protecting others for the creator, such as if they want to let users still contribute and view the source. My main point was you should get these ducks in order first and be genuine with your intentions. Don't use FOSS as a growth hack, it n…

funnily enough i made a similar comment on an exact same "OS" product: https://news.ycombinator.com/item?id=36774611#36775934

Re: Show HN: HyperDX – open-source dev-friendly Datadog alternative

#78

If you want my two Datadog favourite features, they were: 1) clicking on a field and making it a custom search dimension in another click, and 2) flame graphs. Delicious flame graphs.

We should have both! If you hover over a property value, a magnify/plus icon come up to allow you to search on that property value (no manual facets required) - and our traces all come with delicious flame graphs :) Let me know if you were thinking of something different. One other thing I think you'd love if you're coming from Datadog is that you're able to full text search on structured logs as well, so even if the…

Well - the worst thing about Datadog is the sales process :-) But I'll save that for my memoirs. I seem to remember at the time their K8s/Helm integration was a little buggy, but no other pain than that. Plugging our software in was very easy, I recall. We had Python in the backend and we just installed their software and wired it into our API services. I also remember they had a consumer for Auth0 via Auth0's log streaming feature, which we were using at the time.

Btw I haven't checked your product out yet; I was just reminiscing :-) I'll take a look soon.

Re: Show HN: HyperDX – open-source dev-friendly Datadog alternative

#79

Hey, cool product. I know that marketing success is not predicated on good grammar, nevertheless I felt moved to suggest a minor edit to your blurb: "HyperDX helps engineers figure out why production is broken, faster. HyperDX centralises and correlates logs, metrics, traces, exceptions and session replays in one place." Good luck!

Thank you! I'm assuming this is in reference to our README? (Sorry I'm a _tad_ lacking in sleep)

If so, would you like to open a PR? I'm also happy to edit it myself but of course don't want to be stealing credit if you'd like to be attributed that way.

Re: Show HN: HyperDX – open-source dev-friendly Datadog alternative

#80

Congrats on the launch. Perhaps I missed it, but what are the system requirements to run the self-hosted version? Seems decently heavy (Clickhouse, MongoDB, Redis, HyperDX services)? Is there a Helm chart to install into k8s? Look forward to the syslog integration which says coming soon. I have a hobby project which uses systemd services for each of my Python apps and the path with least resistance is just ingest sys…

The absolute bare minimum I'd say is 2GB RAM, though in the README we do say 4GB and 2 cores for testing, obviously more if you're at scale and need performance. For Syslog - it's something we're actually pretty close to because we already support Heroku's syslog based messages (though it's over HTTP), but largely need to test the otel Syslog receiver + parsing pipeline will translate as well as it should (PRs always…

Thanks for the reply and providing detailed system requirements and docker stats. Seems I missed the note in the README. :-)

Actually I am not really using syslog per say, but systemd journalctl which default behaviour on Debian (rsyslog) also duplicates to /var/log/syslog.

  StandardOutput=journal  
  StandardError=journal
Is there a better integration to pull logs from my systemd services and journalctl up to HyperDX?
Post reply on HN