What developers need to know about observability

As developers, we can remember the time when Nagios was state-of-the-art technology. Ever since, the term “monitoring” has had some bad implications associated with it. Looking at dashboards loaded with different graphs and numbers didn’t help us solve issues, and yet we were still asked to look at them. Sure enough, they told us that something was wrong, but our job wasn’t running the system, was it? We ended up having metrics fatigue after only a short period of time.

Why didn’t Nagios work better for us developers? Apart from performance metrics gathered directly from counters built into the applications code flow, it was all just black box monitoring, mostly consisting of pings to hosts and connections to services - commonly accompanied with some log regex parsing. To make matters worse, in the old days of service operations, the Dev and Ops worlds were strictly separated. We had database administrators, keeping everyone else miles away from running even a select statement on their own.

The operations team, operating the system in production and handling system failures and relaying information about problems to engineering, made a career out of keeping developers away from production systems. In the best case, they let only a very limited number of developers access them. Finally there was the engineering department. It was our job to build features, get them “tested”, and … that was it. The next time we were involved was bug fixing. For us, source code was an art in and of itself. Sure enough, we kept any non-developer away from our stuff too. Operating and monitoring the system simply wasn’t part of our job.

Except for one specific part - adding monitoring bits and pieces into our beautiful source code (something akin to putting aluminum siding on the Sistine Chapel) . We hated it, for all the valid reasons! It spread like cancer. The responsibilities were split, and for a long time, software engineers wrote code, and went home. Operations took over from there and had to deal with anything that went wrong.

Times have changed though. Today, systems look different, deployments work differently, and the borders between teams are blurred, if not completely removed. That said, as developers, we are closer to operations than ever, and are an indirect part of operating the systems. With the complexity of modern systems, running microservices “meaningful monitoring” becomes an important part of our life.

To prevent the metric overload of the past we need to look into the benefits of observability. This eBook is an examination of the new world. We’ll leave all the bad feelings about monitoring behind, taking our first steps into the world of Observability and its ever-growing importance for developers.

 

Read the full article here

Source: Instana
This Observability eBook, written by Developer Advocate Chris Engelbert

 

 

THE TQ CULTURE

Information Technology, Simplified

We are a company of self-motivated individuals that share a common goal and purpose.

Each individual in the company has a high degree of autonomy and we are managed and remunerated based on outcomes.