Shipping complex applications at high velocity lead to increased failures. Longer pipelines, scattered microservices, and more code inherently lead to bigger complexity where small mistakes may cost you big time.

Elastic Security’s developer support team has recently seen a surge in reports from customers about sluggish performance in our UI. Our initial inspection of logs for troubleshooting provided some insights, but not enough for a true fix. Luckily, we have Elastic Observability and its APM capabilities to dive in deeper and look under the hood at what was really happening within Elastic Security. And, more importantly, how we could improve its performance for customers.

At Cisco and AppDynamics, we believe that OpenTelemetry™ is the future of observability. To that end, we’re working hard alongside the open source community to ensure the telemetry you collect can be leveraged to deliver the world-class business insights you need.

Monitoring is no longer simply measuring whether your systems are running or are down. Rather, modern monitoring is an ongoing effort of collecting and analyzing data to identify and resolve issues quickly, prevent major disruptions, and ensure performance requirements are always met.

We’ve made some big changes under the hood at Honeycomb to give you better control over how you put your apps data to work—we’ve expanded our core data model with formal Environments and Services! In short, the best observability (o11y) platform in town just got better! Before we dig in, an important note. Existing Honeycomb teams are not impacted by this update. If you’re already a Honeycomb user, congratulations! Your team is now a Honeycomb Classic team.

Last week, Cribl launched the latest component of its observability architecture: Cribl Edge. ICYMI, Cribl Edge is a next generation observability data collector that greatly simplifies gathering your metrics, events, and logs. Edge incorporates all of the capabilities of Cribl Stream’s workers, allowing you to route, redact, filter, and enrich data directly from the source. Why is this important?

A multicloud strategy is a necessity for modern businesses, as the recent AWS outages made clear, but managing this infrastructure remains a huge challenge. Infrastructure management teams have long struggled to juggle diverse technology solutions, policies and services to get access to a point-in-time view of their resources. The result is either waste through overprovisioning or huge overheads for nitpicking manual management and repetitive tasks.

Observability came out of microservices and cloud-native, right? If you have a simpler architecture, does o11y matter?” — this question came up during recent office hours Yeah, sort of. On both counts—yeah, it sorta came out of microservices and cloud native, and yeah sorta, you need it with a simpler architecture (though perhaps not as desperately as you otherwise might).

The most basic component of automated software development is a CI/CD pipeline. While the term "pipeline" has been used to describe a wide range of computer science concepts, we use it at CircleCI and throughout the DevOps industry to refer to the vast range of behaviors and activities that are involved in continuous integration (CI).

Today, the Honeycomb OpenTelemetry Distribution for Java reaches a major milestone with a 1.0 release. This is the first Honeycomb OTel Distro to come out of beta and go into the general release category, and you can expect more to come!

Manufacturers accelerating Industry 4.0 are facing challenges associated with complex cloud-based systems and highly interconnected things. Full-stack observability provides the insights needed to ease transitions and deliver organizational agility required for growth.

Observability is a new term that’s slowly entered the mainstream over the last two years. Today it’s used in the context of monitoring, but it’s much more than that. And it also goes way beyond visibility. So, in this blog, we set out to explore observability vs visibility and find out, what’s the difference? In a recent podcast, our friends at Riverbed neatly explained that seeing and observing are two different things, and can be compared to hearing vs listening.

To supervise the behavior of distributed applications and track the origin of service failures and downtime, developers often use traditional monitoring technologies and tools. However, this approach can fall short in its ability to measure the overall health of modern cloud-native architectures, which can span multiple hosting environments and encompass hundreds of microservices.

Grafana Labs recently announced that they are relicensing their core projects from Apache 2.0 to Affero General Public License (AGPL) version 3. This is great news for the open source community, since the new license is still Open Source Initiative–approved and adheres to an additional clause in which network access of any AGPL-licensed software counts as a type of distribution.

In preparation for the upcoming Developer Observability Masterclass we’re hosting at Lightrun with Thoughtworks and RedMonk, I sat down for a brief interview with Tom Granot – the Director of Developer Relations at Lightrun. Tom will MC the event as he did for the Developer Productivity Masterclass we ran back in December.

Discover what 1,200 global IT leaders have to say about the future of full-stack observability — and learn how early adopters are already reaping the benefits that enhanced visibility across the entire IT environment can bring.

TL;DR: startSpan is easier and measures a duration. Use it if your work won’t create any subspans. startActiveSpan requires that you pass a callback for the work in the span, and then any spans created during that work will be children of this active span. I’m instrumenting a Node.js app with OpenTelemetry, and adding some custom instrumentation. For this important activity that I’m doing (let’s call it “retrieve number”), I’m creating a custom span.

Those of us of a certain age know well the saying “Nobody got fired for buying IBM.” In the log analysis and security world, we’ve become lucky to get to the point where people are saying “Nobody gets fired for buying Splunk.” Our success in these areas has definitely created a perception for what products Splunk has and what we can offer to our customers. The problem is that most of these perceptions don’t capture the full power of Splunk.

Software developments take place quickly as per the client’s requirements. The developments need to take place with safety and precautions. DevOps engineers can help into this matter; however, it is not possible without Observability.

We’re well into 2022, and it’s full steam ahead addressing challenges and moving IT and SRE projects to completion. Are you ready for the challenges ahead of you? Do you feel prepared to handle the work you know about…and the work that’s sure to come your way? Are you ready for the end-of-the-year budget planning process that will be here before you know it? To help, I’d like to share my learnings from 20+ years in IT.

Previously announced as a community-led project, the Terraform provider for Honeycomb is now officially maintained by Honeycomb in partnership with Hashicorp. We recognize how valuable supporting configuration as code is for our customers, and this change in ownership affirms our commitment to ensuring your ability to quickly make the most of Honeycomb’s Management API.

Race conditions can occur when a multithreaded application accesses a shared resource using over one thread. Unless we have guards in place, the result might depend on which thread “got there first”. This is especially problematic when the state is changed externally. A race can cause more than just incorrect behavior. It can enable a security vulnerability when the resource in question can be corrupted in the right way. A good example of race condition vulnerabilities is mangling memory.

Companies depend on observability insights to provide reliable online services to their customers. To support their efforts, StackState is proud to announce a new version of our unique topology-powered observability software, StackState v4.6, available now. This new version brings powerful new capabilities to DevOps and SRE teams who need to maintain a deep understanding of how their stack is behaving to meet their SLOs.

Today, cloud native technologies empower a number of organizations to build and run scalable applications in public, private and hybrid cloud environments. Developer and operation teams can build and deploy applications, APIs and microservices architectures with the speed and immutability of containers. Gartner predicts that by 2024, more than 75% of large enterprises in mature economies will be using containers in production.

Customers expect seamless digital experiences. But growing complexity and lack of unified full-stack observability create challenges for the whole organization.

There are different positions on whether observability and monitoring are two sides of the same coin. We will analyze and explain what the observability of a system is, what it has to do with monitoring and why it is important to understand the differences between the two.

SaaS (software as a service) is the common model for many businesses today. Even longstanding behemoths such as Cisco and Microsoft have been strategically shifting their software products to SaaS and recurring revenue models (just think Office365 shift from licensed Office). These SaaS businesses need agility to move fast and remain competitive. This means agility in the IT stack, but also agility in the business models to support bottom-up GTM and product-led growth (PLG).

Supply chain management is a complex dance impacted by forces beyond your control. Full-stack observability can help make the process a lot less stressful.

Today marks the start of a new chapter at Catchpoint, as we launch our digital experience observability platform. In this post, I’ll share with you some of the wider contextual factors driving this launch, as well as how the continuous evolution of our platform supports a massive market need.

Dashboards are one of the most basic and popular tools software engineers use to operate their systems. In this post, I'll make the argument that their use is unfortunately too widespread, and that the reflex we have to use and rely on them tends to drown out better, more adapted approaches, particularly in the context of incidents.

Technologies such as serverless computing frameworks and CI/CD automation tools help accelerate software development lifecycles (SDLC) to give development teams a competitive edge in the marketplace. Armed with these technologies, teams can deploy and innovate faster and more frequently by automating repetitive tasks and eliminating the need to manage or provision servers.

DevOps culture revolutionized our industry. Continuous Delivery and Continuous Integration made six sigma reliability commonplace. 20 years ago we would kick the production servers and listen to the hard drive spin, that was observability. Today’s DevOps teams deploy monitoring tools that provide development teams with deep insight into the production environment. Before DevOps practices were commonplace, production used to fail. A lot.

If you’re working with microservices in a large distributed environment, you’ve probably got your monitoring and logging on lock, and you may even be lucky enough to have properly instrumented APM (distributed tracing) for consumer calls. But, did you know you’re likely still facing an observability gap? How many incidents have you worked that required hours of sleuthing only to end with a single team needing to roll back a deployment? It’s more common than you may think!

Ah, I too have wondered about this. TL;DR: The Resource says what program is sending these spans and where it’s running. You can skip it if you define OTEL_SERVICE_NAME in the environment. When I’m setting up tracing (for instance, in a Node.js app), I have to create a Resource object in order to set up the OpenTelemetry SDK: If I don’t define that resource parameter, then tracing will still work. But my spans will show up with aservice.name of unknown_service:node.

As today’s IT landscape becomes more complex, Infrastructure and Operation (I&O) leaders are forced to revisit their tools, systems, applications and teams. Why? Find out in our new infographic: "The Shift to Observability. And Why It’s Time.".

Ready to “rewind the movie” to see exactly what was going on in your stack at any moment in time? Ready to quickly go straight to the original source of the problem to solve issues faster? Check out our new infographic, Achieving True Observability With the 4Ts, to see how StackState’s unique 4T® data model correlates topology, telemetry and traces at every moment in time, to deliver real-time contextual insights into your entire IT landscape.

What fun is network observability if you can’t share what you see? That’s why we’ve added public link sharing to the Kentik platform. One of the greater missions of network observability is to break the boundaries of conventional monitoring. At Kentik, we focused our initial efforts on making complex infrastructure problems easy to visualize, understand and resolve. Now we’re tackling a follow-up mandate: to democratize network observability.

In today’s world, there’s no lack of monitoring data. In fact, the amount of data DevOps and SRE teams are dealing with on a daily basis can be confusing and overwhelming. Often, the problem is threefold.

The promise of OpenTelemetry is that it can help you avoid vendor lock-in by allowing you to instrument your applications once, then send that data to any backend of your choice. This post shows you exactly how to do that with code samples that configure your application to send telemetry data to both Honeycomb and New Relic.

While automating systems is seen as an imperative in boardrooms around the globe, automation teams — the teams on the ground — often lack the data to help them to industrialize their automation efforts and move from ad-hoc automation to strategic automation. In this automation-focused blog post, we will show how to instrument infrastructure automation with Elastic Observability.