Honeycomb.io | Full-time | Remote, authorized to work in the US + Canada | Product Manager, Customer Success Eng, Product Eng, Eng Manager, Account Exec
Honeycomb is built to help engineering teams deeply explore and understand their own production systems — in real time. It's a service for the near and present future, where distributed systems are the new default, every service is a platform, and empowered generalist software engineers are the new ops. We are passionate about consumer-quality developer tools and excited to build a product that raises our industry's expectations of what our tools can do for us.
Job links (and threads by the hiring managers!) can be found here:
> I find it a huge step backwards. As far as I know, there's no full text search and the types of reports and aggregation you can do are extremely primitive.
Oof. Honeycomb is for fast, realtime analytics: starting with a high-level question in your mind ("why did our throughput drop by 50%?") and rapidly iterating on a hypothesis (examples in [0]). ELK can... be used for that, but is optimized for another (as you said, full-text search and generating static reports).
Being able to flip from a funny-looking graph directly into "raw data" mode is intended to be a bonus in Honeycomb, not the primary way you interact with your data.
While we believe that fulltext search has its place, beyond a certain point (most production systems, these days), sifting through log lines is a brute-force method of answering questions about your systems — especially if you're not sure what the proverbial needle you're searching for looks like. [1]
(But mherdeg's answer is great, go back and read theirs while you're here :))
Totally, if all you care about is just that counter/gauge -- but more and more often, you need that counter/gauge captured for a particular segment of your traffic (e.g. some app-level identifier), and TSDBs tend to struggle[0] as the number of possible segments explodes.
If all you care about is overall latency, awesome! Use a TSDB. Once you care about latency per endpoint/user agent/customer ID/client platform (or combination thereof), you need the flexibility associated with structured log data, stored in something meant for fast analytical querying.
Honeycomb is also unapologetically a SaaS. We believe that - unless your company's core competency is, in fact, managing databases and a garden of myriad open-source monitoring tools - it makes sense for most people to outsource their observability solutions.
(We also don't currently support joins, while TimescaleDB's joins sound pretty dope :))