Operations | Monitoring | ITSM | DevOps | Cloud

In the observability toolchain, all of our efforts go into data storage and analysis, and the usability of our system becomes a second-class citizen. Autocomplete is a crucial usability feature that significantly improves the developer experience. It is ubiquitous amongst engineering tools from IDEs to CLIs. Autocomplete has long been a feature of many observability tools, but they all miss a crucial detail – optimizing for developer productivity.

Have you ever tried to find a bug in a multi-layered architecture? Although this might sound like a simple enough task, it can quickly become a nightmare if the system doesn’t have proper monitoring. And the more distributed your system is, the more complex it becomes to analyze the root cause of a problem. That’s precisely why observability is key in distributed systems. Observability can be thought of as the advanced version of application monitoring.

Akka’s license change has surprised many of us, but it didn’t come out of nowhere. Lightbend recently announced that Akka will be transitioning from an “Open Source” license to a “Source available” license called BSL 1.1. Let’s unpack this to understand what it all means.

Stateful, commonly monolithic, and absolutely fundamental to system design, the quality of your database administration and operation is a key determinant of your overall success. Databases are the cornerstone of modern architecture, requiring constant effort, investigation, and iteration to get the most out of a database. This makes it all the more terrifying when an outage occurs.

The way organizations process logs have changed over the past decade. From random files, scattered amongst a handful of virtual machines, to JSON documents effortlessly streamed into platforms. Metrics, too, have seen great strides, as providers expose detailed measurements of every aspect of their system. Traces, too, have become increasingly sophisticated and can now highlight even the most precise details about interactions between our services. But alerts have remained stationary.

Alerting has been a fundamental part of operations strategy for the past decade. An entire industry is built around delivering valuable, actionable alerts to engineers and customers as quickly as possible. We will explore what’s missing from your alerts and how Coralogix Flow Alerts solve a fundamental problem in the observability industry.

Cloud services were born at the beginning of 2000 with companies such as Salesforce and Amazon paving the way. Simple Queuing Service (SQS) was the first service to be launched by Amazon Web Services in November 2004. It was offered as a distributed queuing service and it is still one of the most popular services in AWS. By 2006 more and more services were added to the offering list.

Observable and secure platforms use three connected data sets: logs, metrics, and traces. Platforms can link these data to alerting systems to notify system administrators when an event requires intervention. There are nuances to setting up these alerts so the system is kept healthy and the system administrators are not chasing false positive alerts.

Tracing is often the last thought in any observability strategy. While engineers prioritize logs and metrics, tracing is truly the hallmark of a mature observability platform, but it is also the most difficult to implement. Once tracing is in place, engineers typically discover something else – many tracing solutions aren’t particularly feature-rich.

Like cloud-native and DevOps, full-stack observability is one of those software development terms that can sound like an empty buzzword. Look past the jargon, and you’ll find considerable value to be unlocked from building observability into each layer of your software stack. Before we get into the details of observability, let’s take a moment to discuss the context.