Hi HN, Mike and Warren here! We’ve been building an open source local-dev-friendly mode for HyperDX (hyperdx.io). It's a single Docker container that lets you view logs, metrics, and traces for local development in a similar way you can use them for production (live tail, filter/correlate logs & spans, build charts, flamegraph, etc.) Basically, imagine you can run Datadog in a single container for local development. We does this by spinning up an OpenTelemetry collector, Clickhouse DB and HyperDX UI all in a single container - it only takes a few seconds to start and lets you start live tailing your local logs and traces immediately (and graph metrics of course).<p>README (w/ demo gif): <a href="https://github.com/hyperdxio/hyperdx/blob/main/LOCAL.md">https://github.com/hyperdxio/hyperdx/blob/main/LOCAL.md</a><p>We started building local mode as it became one of our most loved [1] community issue after sharing HyperDX. It made sense - as we constantly use HyperDX to debug our own issues locally, and have found it to be a huge productivity boost for things like…<p>1. Tailing multiple container logs (and grepping/isolating them) without a ton of different terminal splits open at the same time.<p>2. Be able to sensibly view structured logs and correlated traces to debug local issues (because you’re using structured logging and tracing right?) instead of adding ad-hoc console statements that print out exactly what I could’ve gotten from tracing.<p>3. Testing telemetry are actually emitting/correlating as expected, before shipping it all the way out to prod and realizing I accidentally created a very expensive high-cardinality metric or a span that has the wrong properties.<p>We spent some time packaging & tuning our existing OSS stack to run in a single container with less memory/space requirements by staring at `dive` to slim down the image and applied incantations from documentation until memory usage improved. Additionally we removed a few non-local-friendly things like authentication requirements and extraneous services.<p>It still has all the goodness you’d want - so you can full text search your logs/traces, live tail all your events, view spans correlated with logs (and vice versa), create dashboards based on logs, metrics, traces, and is fully OpenTelemetry compatible - just point your Otel SDK/collector to <a href="http://localhost:4318" rel="nofollow">http://localhost:4318</a> (or 4317 for the grpc folks) and you’re already good to go.<p>I’m excited to share what we’ve been working on and would love to hear your feedback and opinions!<p>Spin up the container yourself to try it out:<p>docker run -p 8000:8000 -p 4318:4318 -p 4317:4317 -p 8080:8080 -p 8002:8002 hyperdx/hyperdx-local<p>Main Open Source Repo: <a href="https://github.com/hyperdxio/hyperdx">https://github.com/hyperdxio/hyperdx</a><p>Hosted Demo (in case you want to play around in a cloud sandbox instead): <a href="https://api.hyperdx.io/login/demo">https://api.hyperdx.io/login/demo</a><p>HyperDX Landing Page: <a href="https://hyperdx.io">https://hyperdx.io</a><p>[1]: <a href="https://github.com/hyperdxio/hyperdx/issues/7">https://github.com/hyperdxio/hyperdx/issues/7</a>
super cool. Debugging locally across multiple microservices can be a huge pain.<p>A small feature request/idea - packaging this as a helm chart to make local development on something like Minkikube easier.