Why observability data for cloud native developers needs to be just right

BRAINBLOG FOR CHRONOSPHERE BY JASON BLOOMBERG

Empowering developers

Developers have always needed insight into how their code behaves in production. In the past, gaining such visibility was a simple matter of turning to an APM overview dashboard and analyzing the available data.

Cloud native systems, however, complicate this simplistic approach.

In the past, a single application might run on a single server and generate a single log file. In the cloud native world, an application consists of multiple instances of microservices. Each of which, in turn, generates voluminous observability telemetry – not just log files, but metrics and traces as well.

Suddenly, the massive quantity of observability data becomes a logistical nightmare, overwhelming both operators and developers, running up the cloud bill.

Compounding these challenges is the fact that in the cloud native world, multiple development teams work in parallel, building interdependent microservices that are subject to frequent changes. With every deployment, new build IDs are generated, significantly increasing the telemetry cardinality, while the volume of telemetry data scales according. This further exacerbates the challenges of tracking and analyzing application behavior across a sprawling microservices environment.

Empowering developers to instrument, control, and leverage the right level of observability data they need to do their job – no more and no less – is a critical capability for any cloud native development effort that seeks to deliver quality software without unnecessarily running up the cloud bill.

Click here to read the entire article.

SHARE THIS: