A digital evolution is taking place at Carhartt. Agent of Transformation Tim Masey shares in his own words how full-stack observability plays into it.

Today, we announced that Honeycomb has raised $50M in Series C funding, in a round led by Insight Partners and joined by all existing investors from our Series B. We’re using this investment to support the growth of our customers and community, ensure the benefits of observability can be realized by all engineering teams, and expand the ways we can better serve you.

Log observability and monitoring are terms often used interchangeably, but really they describe two approaches to solving and understanding different things. Observability refers to the ability to understand the state of a complex system (or series of systems) without needing to make any changes or deploy new code.

You might already know that OpenTelemetry is the future of instrumentation. It’s an open-source and vendor-neutral instrumentation framework that frees you from the trap of using proprietary libraries simply to understand how your code is behaving. Best of all, you can instrument your applications just once and then take that instrumentation to any other backend system of your choice. This blog shows you exactly how to use OpenTelemetry to ✨break the vendor lock-in cycle.✨

I have always found data collection to be a fascinating area of work at Sumo Logic. Collecting data is a critical first step for all the solutions we develop for our customers. After all, to observe the health and performance of your applications, you must first collect all relevant data. It's also an area that has seen some significant activities by the open-source community over the years, which is completely changing the landscape of observability as we know it.

Tucker Callaway is the CEO of LogDNA. He has more than 20 years of experience in enterprise software with an emphasis on developer and DevOps tools. Tucker drives innovation, experimentation, and a culture of collaboration at LogDNA, three ingredients that are essential for the type of growth that we've experienced over the last few years.

Which data sources do DevOps teams need in order to achieve observability? At a high level, that’s an easy question to answer. Concepts like the “three pillars of observability”—logs, metrics, and traces—may come to mind. Or, you may think in terms of techniques like the RED Method or Google’s Golden Signals, which are other popular frameworks for defining which types of data teams should collect for monitoring and observability purposes.

As product developers, our responsibility continues beyond shipping code. To keep our software running, we need to notice whether it’s working in production. To make our product smoother and more reliable, we need to understand how it’s working in production. We can do this by making the software tell us what we need to know. How can we notice when the software is running smoothly? Make it tell us!

In my previous post, we explored why Honeycomb is implemented as a distributed column store. Just as interesting to consider, though, is why Honeycomb is not implemented in other ways. So in this post, we’re going to dive into the topic of time series databases (TSDBs) and why Honeycomb couldn’t be limited to a TSDB implementation. If you’ve used a traditional metrics dashboard, you’ve used a time series database.