KoolKits (Kubernetes toolkits) are highly-opinionated, language-specific, batteries-included debug container images for Kubernetes. In practice, they’re what you would’ve installed on your production pods if you were stuck during a tough debug session in an unfamiliar shell. To briefly give some background, note that these container images are intended for use with the new kubectl debug feature, which spins up Ephemeral containers for interactive troubleshooting.

Understanding everything that happens inside a production environment is a notoriously difficult task. Instana’s solution helps developers and DevOps become aware of problems quickly – problems that are rooted in both infrastructure-level information and application-level information. Lightrun, on the other hand, enables practitioners to drill deeper into line-by-line, debugger-grade information from your production systems – enriching the existing information Instana delivers.

Lightrun is the world’s first IDE-native observability platform. A developer-first product, Lightrun enables engineering teams to connect to their live applications and continuously identify critical issues without hotfixes, redeployments, or restarts. We are proud to announce the general availability of the Lightrun extension for Visual Studio Code, the popular IDE from Microsoft.

Ah, good question! TL;DR: store the start time of the span, and then create the span on the new page. Usually, you want to start a span, do some work, and then end the span. The whole span gets sent to your OpenTelemetry collector (and thence to Honeycomb) when you end it. But when a page load happens, that span object is lost. Honeycomb never hears about it becausespan.end()wasn’t called. How can we deal with this? Create the span only on the new page, where you can end it. But!

The rise of cloud native and containerization, along with the automation of the CI/CD pipeline, introduced fundamental changes to existing application development, deployment, and security paradigms. Because cloud native is so different from traditional architectures, both in how workloads are developed and how they need to be secured, there is a need to rethink our approach to security in these environments.

A long time ago, in a galaxy far, far away, I said a lot of inflammatory things about metrics. “Metrics are shit salad.” “Metrics are simply nerfed dimensions.” “Metrics suck,” “metrics are legacy,” “metrics and time series aggregates will fucking kneecap you.” I cannot tell a lie; Twitter will testify that I’ve spent the past six years ragging on metrics.

Recently we had the privilege of being named a Gartner Cool Vendor in the Monitoring and Observability category. The funny thing is, while this is definitely the closest Gartner category for our solution, we aren’t really used to thinking about Komodor as a monitoring and observability tool.

“What is up with the Context in OpenTelemetry? Why do I need to mess with it at all? Why, when I set a span as active, don’t subsequent spans just use it as a parent?” Oh, yikes, yeah. The Context abstraction in OpenTelemetry is hard to understand. Here are several ways it’s tricky.

In 2022, it’s hard to find places in the business and technology ecosystem where performance is not measured, where lots of data is not collected and where insights are not analyzed to improve operational and business performance and trace accountability.

Bram Vogelaar is a DevOps Cloud Engineer at The Factory, and he recently delivered an intro to observability talk during our Grafana Labs' EMEA meetup. When I talk to customers, they might tell me about how their applications are running in two data centers, but when we probe a little further, it turns out that their observability stack is only available in one of them. This revelation hit close to home last March.

OpenTelemetry is a strong standard for instrumentation because it is built of careful, well-thought-out abstractions created by experts in the space. OpenTelemetry feels painful to start using because it’s full of abstractions that make sense to experts in the space. For a developer who wants to think about their own software and not spend a month becoming an expert in telemetry, this is hard. For high-level conceptual description, there’s the OpenTelemetry specification.

In my last blog post, I talked about the cadence of product planning and delivery at Honeycomb. Tucked away in there was a mention of “demo day”—and I’m back to tell you all about that because it’s a pretty big deal around here, and I want to encourage you to give it a try as a way to see progress on new feature development and get folks excited about what’s on the horizon.

Enterprises are dealing with a deluge of observability data for both IT and security. Worldwide, data is increasing at a 23% CAGR, per IDC. In 5 years, organizations will be dealing with nearly three times the amount of data they have today. There is a fundamental tension between enterprise budgets, growing significantly less than 23% a year, and the staggering growth of data.

As businesses accelerate digital transformations and cloud adoption to better serve customers and employees in the face of the global pandemic, operational complexity has also mounted. To untangle these complexities and enable executive visibility into IT ecosystem , business leaders are increasingly looking to observability solutions as a strategic investment.

Yes! While data is data (and tools exist on a continuum, and can and often are reused or repurposed to answer questions outside their natural domain), observability and BI/data warehouses typically exist on opposite ends of the spectrum in terms of time, speed, and accuracy, among others.

Ever wonder how your teammates go about debugging? When you use Honeycomb, you’re not only getting observability into your systems; it also provides observability into how your teammates use Honeycomb! Very meta, no? You’re never alone when writing or running Honeycomb queries. Opening up the right sidebar will show you the queries your teammates have recently run on the same dataset.

Before we talk about OpenTelemetry, we should talk about telemetry. Telemetry is: And an instrument is: For the purpose of measuring running computer software and systems, our instruments are virtual instruments. That is to say, code that measures other code. It sounds simple: read a measurement and send it to a remote location. In practice, to make that telemetry data useful in today’s cloud-native and ever more complex environments, there are huge logistical and technical hurdles to overcome.

Our mission at Cribl is to unlock the value of all your observability and telemetry data, regardless of source or destination. We aim to give you choice and control over your data—because we know data has different value to different stakeholders at different times in the data lifecycle. Users are just scratching the surface in terms of the ways they are finding value from Cribl LogStream.