Two years ago I wrote a piece in The New Stack about the Future of Ops Careers. Towards the end, I wrote: I described the second category as “operations engineering minus the infrastructure,” dedicated to evaluating and assembling a production stack of third-party platform providers, enabling software engineers to self-serve their services and own their own code in production. I said: That second category I was describing now has a name. We call those teams "platform engineering.".

So far in our series on scaling observability for game launches, we’ve discussed ways to 1) quickly analyze large volumes of telemetry data and, 2) ensure high-quality telemetry data for more effective analysis at lower costs. The best practices in these blogs outline best practices for scaling observability during game launch day – which is necessary to ensure high performance across all infrastructure components – to ensure no lag, no glitches, and no bugs.

Organizations today are under pressure to stay ahead and maintain IT applications and infrastructure optimally. That means their IT teams are tasked to make sure that functions move along smoothly while minimizing downtime. To keep the lights on, enterprises add whatever domain-specific tools they need. However, these tools are often reactive, and not nearly robust enough to handle complex application topologies.

Modern application architectures enable technologists to innovate quickly, but building apps in a cloud native environment adds complexity. Here's how to find the right observability solution for your cloud ecosystem.

Digital transformation requires organizational evolution. Constant demand for rapid delivery of upgrades and new products forces change. Surely, the old days of managing monolithic applications housed in private servers are over. Applications consist of virtualized, containerized, and serverless code that’s networked via APIs across a hybrid infrastructure of public and private clouds.

What is an observability engineer? Is it your SIEM admin? How about your application performance monitoring admin? Neither? Both? Observability engineering is more than administering a tool. There is more to it than data onboarding, writing parsers, and getting data in. As an observability tool admin, you work with data producers and consumers to get data in a human-readable and searchable format from the source to the analytics system.

Comprehensive observability starts with good instrumentation. OpenTelemetry, aka “OTel,” sets a unified standard, enabling you to instrument your applications once, then send that data to any backend observability tool of choice. OpenTelemetry’s standard for generating and ingesting telemetry data is slated to become as ubiquitous as current container orchestration standards. Because of this, development teams are increasingly adopting OpenTelemetry to their applications.

For decades, IT operations teams have relied on monitoring for insight into the availability and performance of their systems. But the shift to more advanced IT technologies and practices is driving the need for more than monitoring – and so observability evolved. With infrastructures and applications that span multiple dynamic, distributed and modular IT environments, organizations need a deeper, more precise understanding of everything that happens within these systems.

This article is the final installment in a series that demystifies observability. The first three focused on the history of observability, dispelling myths around observability, and what observability is and what it can offer. In this last article of the series (Check out part 1), I want to offer a complete definition of observability.

Complex, distributed software systems are chatty things. Because there are many components interoperating amongst themselves and with things outside their bounds like users, those components and the systems themselves emit many information signals. It’s the goal of monitoring, logging, and observability (o11y) tools to help the systems’ “stewards,” those developers and operators tasked with maintaining and supporting them, make sense of those signals.

Kubernetes is one of the most well-known open-source systems for automating and scaling containerized applications. Usually, you declare the state of the desired environment, and the system will work to keep that state stable. To make changes “on the fly,” you must engage with the Kubernetes API.

It's not like it used to be back in the day! Before CI/CD, we were building on-premises, service-oriented products following system style architecture and we were able to map out the build system and end-to-end process in a PowerPoint or Visio document. Although time-consuming and inefficient, it was relatively straightforward and the build pipeline was unlikely to change drastically. But that's no longer the case.

It may seem like ancient history, but there was a time when telecommunications companies only had to worry about connecting customers over landlines. Today, their businesses depend on vast cellular networks to not only provide strong wireless phone coverage in countless locations, but also handle the demands of tablets, computers, and machine-to-machine communications.

Organizations are adopting cloud native and multi-cloud architectures to drive innovation, achieve faster time to market, improve yield, and deliver exceptional experiences to their customers. However, for all the business benefits of modernizing, the process does not come without challenges.

We’re adopting Honeycomb with our teams, however, we’re trying to set up Availability Checks for our services like we’ve done with previous providers. How do we do that in Honeycomb?

Level 4, Proactive Observability With AIOps, is the most advanced level of observability. At this stage, artificial intelligence for IT operations (AIOps) is added to the mix. AIOps, in the context of monitoring and observability, is about applying AI and machine learning (ML) to sort through mountains of data looking for patterns.

In Part I in our series outlining best practices for scaling observability, we reviewed the data analysis capabilities that can help engineers troubleshoot faster during high pressure situations during a game launch. Nobody wants lag time or crashes in their game launch. Similarly, no one wants terminated sessions or for your gamer customers to log off and play a competitor’s game.

September is here, and that means many retailers have already begun preparing for the upcoming holiday season. One weekend in particular tends to be the real-life stress test that companies have come to develop a love-hate relationship with: Cyber Weekend. Or more specifically, Black Friday, Cyber Monday, and the weekend in between.

Observability is one of the most critical ways to improve visibility and control over complex software systems. If you've ever wondered how observability differs from monitoring, then this guide will explain some of the key differences between these two popular concepts.

In my previous blog, I discussed how continuous observability can be used to deliver continuous reliability. We also discussed the problem of high change failure rates in most enterprises, and how teams fail to proactively address failure risk before changes go into production. This is because manual assessment of change risk is both labor intensive and time consuming, and often contributes to deployment and release delays.

One of the core features of Cribl Stream is our Replay capability. We pride ourselves on giving customers choice and control over their data. The ability to archive data in cheap object storage, and then providing the ability to reach into the same object storage is one example of this. It’s safe to say that S3 and AWS have become synonymous with the term object storage. It’s like a modern day Kleenex, or Band-Aid.

After months–or potentially, years–of hard work by teams across a gaming enterprise, when the day arrives for a game launch, the last thing your enterprise needs is slowdowns, glitches, outages or poor performance. It’s the death knell for any game, because for your avid gaming customers, there’s always something else (read: a game that isn’t yours) to check out.

An organization at Level 2 in the Observability Maturity Model has built on the foundation of their monitoring capabilities and taken the first steps into observability. In recent years, two major trends have driven the need for the deeper insights that observability can provide.

Artificial Intelligence for IT Operations (or AIOps for short) continues to be a hot topic among developers, SREs, and DevOps professionals. The case for AIOps is especially crucial given the expansive nature of today’s observability efforts across hybrid and multi-cloud environments. As with most observability platforms, it all starts with your telemetry data: metrics, logs, traces, and events.

In the last half-decade, AIOps and observability have arguably been the hottest two topics in IT operations management. Gartner first mentioned AIOps—Artificial Intelligence for IT Operations—in 2016, defining it as using big data and machine learning to automate IT operations processes, such as event correlation, anomaly detection and causality determination.

Distributed denial-of-service (DDoS) attacks have been a continuous threat since the advent of the commercial internet. The struggle between security experts and DDoS protection is an asymmetrical war where $30 attacks can jeopardize millions of dollars for companies in downtime and breaches of contract. They can also be a smokescreen for something worse, such as the infiltration of malware.

In this post, we’ll look at how to host the OpenTelemetry Collector in Azure Container Apps. There are a few gotchas with how it’s deployed, so hopefully this will stop you from hitting the same issues. If you don’t care about the details and just want to run a script, I’ve created one here.

A goal of open-source observability is unifying several different signals to provide the observability everyone wants. It’s always interesting to speak to people on this journey, and how they try to provide it through open-source projects, and the challenges they can face. I was thrilled to host Pranay Prateek on the most recent episode of the OpenObservability Talks podcast.

Splunk embodies the top 5 principles of unified security and observability, and has been an expert in log management, security, and observability for years.

This series of six blogs outlines the basics of the Observability Maturity Model. Use it to identify where you are on the observability path, understand the road ahead and provide guidance to help you find your way.

Written by Andrew Puch and Brian Langbecker You use NGINX as a proxy for your application, and you want to leverage your favorite features in Honeycomb to help make sense of the traffic data. Have no fear: Honeycomb is more than capable and ready to help! Things you will need: Before you start with the instructions, let’s discuss a lightweight tool called Honeytail. This utility will tail log files, parse the various formats, and send the data to Honeycomb.

HTTP is the backbone of all API-centric, modern web apps. APIs are the place where the core business logic of an application lives. As a result, developers spend a lot of time optimizing the API business logic. This article addresses a Node.js developer’s dilemma while debugging an HTTP API request. We take a sample Node.js/Express.js-based HTTP service to demonstrate a new way of debugging Node.js applications using the Lightrun observability platform.

A logging framework is a software tool that helps developers output diagnostic information during the execution of a program. This information is used to debug the program or monitor its performance. There are many different logging frameworks available, starting with simple logging libraries to full-fledged logging and observability platforms.

Today, we’re announcing major new updates to Honeycomb’s PagerDuty integration. These updates put more of the information you need into PagerDuty notifications and allow for greater configurability. These enhancements are available to all users who leverage Honeycomb Triggers and Burn Alerts to send notifications via PagerDuty.

Classically, the space of observability lies within layers of information on a dashboard. It operates by using the fundamental trio of data — metrics, logs and traces — from each layer of the environment to assess the health of an IT infrastructure. However, a time component is critical, making the stack observable at any point in time. Gathering reliable data and insights into your IT infrastructure remains the primary role of observability tools and services.

It’s no secret that CI/CD pipelines make the lives of engineering and operations easier by accelerating the feedback loop for higher quality code and apps. They build code, run tests, and safely deploy new versions of your application. But just like any aspect of development, poor integration, invisible bottlenecks, and bugs can plague your pipelines. And debugging them? Well, it’s complicated.

A prelude to our upcoming six-part Observability Maturity Model Fundamentals blog series. By Lodewijk Bogaards At StackState, we have spent eight years in the monitoring and observability spaces. During this time, we have spoken with countless DevOps engineers, architects, SREs, heads of IT operations and CTOs, and we have heard the same struggles over and over.

Technically speaking, observability offers visibility into the data being generated by your infrastructure devices, systems, and applications — but in reality, it offers the opportunity to see what’s happening, There’s no guarantee that you’ll get what you want; you have to set things up in a way that makes it possible for you to get the insights you need.

It’s already September! Time flies by when you’re getting things done, and we’ve been a busy bunch of bees here at Honeycomb. 🐝 We’re excited that we’ve gotten to share some of those changes with you already, like our relaunched interactive sandbox and the beta release of our OpenTelemetry log support and Go distribution, but that’s just the tip of the iceberg.

We recently hosted a Twitter Space, and a question came in regarding speaking to executives about instrumenting for observability. It’s a great topic we love expanding on. Here’s the answer we provided.