[HYP-37] First-party support for local dev-mode observability

[MikeShi42]

Often times even locally you need access to traces, metrics, logs, or at least have the ability to preview the telemetry you may be implementing without pushing to prod.

We already do this with our own HyperDX workflow, and it seems like it's been brought up a few times in our HN launch as well for being useful for other people's workflows.

• https://news.ycombinator.com/item?id=37564644
• https://news.ycombinator.com/item?id=37561281

We should figure out what requirements should be part of making HyperDX local-friendly, a few things on the top of my mind:

1. Optimize for resource footprint over scalability (we can tune the memory usage of the otel collector, maybe remove the miner or spin it up on-demand, etc)
2. Auth-less flow, so users can just spin up a container and start sending telemetry to the Otel ports directly without any additional auth/key/team setup.

Kicking off this issue to collect any other requirements and stub out additional tickets along the way.

_HYP-37

[pksunkara]

You guys also need a single docker image that I can simply use in our docker compose file. Something similar jaeger/all-in-one

[corytheboyd]

This would make me so happy 😁

On top of other suggestions so far, some ideas:

• Log ingestion from file, works in docker compose via volume mounts. Syslog or other protocols could work the same way here, but always having file based log ingest as a fallback would be nice
• Ability to check in saved views, and load them on boot. Enables sharing common development views amongst all team members. Bonus points for an easy export flow, but I don’t mind if it’s a simple “copy/paste this json/yaml/etc” flow either
• The container supports attaching (preferably one) persistent volumes to keep some historical local development history. Would also want omitting this to have it persist nothing. Would also want to have a simple limit on the data stored, and just evict events at the tail to make room for new events. It can be nice to see yesterdays data after I stopped for the day, but go ahead and clobber it as I record new events today. If I lose data I cared about, it’s my fault, and I need to adjust the data storage limit. Personally, don’t really need a log rotation or anything fancy for the local development case.

[t1mmen]

Just adding my 👍 on this, ref Discord.

We have a wonderful "clone & 1-command to spin everything up" dev env, but HyperDX requires some manual configuration.

• The auth less flow in OP would cover this for us. We may want to seed them via ENV vars, but not critical.
• A simplified Docker Compose setup would be nice (ref @pksunkara), to avoid a) a full clone of repo, or manually copying docker-compose.yml + .env + ./docker (maybe only partially needed?)
• Edits
  • There may be an issue setting HYPERDX_APP_PORT to anything but 8080 (I tried, but HyperDX got stuck in a loading state; setting it back worked again)
  • Once an account is created, I think I may be locked out of the HyperDX instance. I made a quick test account first, without noting the password -- now, I can't access the service or create a new account. I'll figure this out, but may be worth improving this.
  • Saved views/searches would definitely be a benefit
  • I am not able to get actual logs into HyperDX in localhost mode, see Discord thread. that's probably me being dumb about something, but getting the friction of setup down to near zero would certainly help adoption :)

I'd also recommend making the use-case of excellent local logging in dev mode a featured use-case on the docs site.

Awesome project, btw, I'm loving what I see so far! 👏