Application vs. Service vs. Component-Level Telemetry

Learn the importance of telemetry in monitoring and troubleshooting applications at different levels.

We'll cover the following

As covered in the Microservice Observability chapter, we can collect simple telemetry by installing the Application Insights library as a dependency and configuring it to point to an existing Application Insights instance in Azure. This covers us at the code level for any immediate metrics, logging, or tracing that Application Insights can provide out of the box. While this is useful, we might need to break that down further and capture some specific baselines at various levels.

Levels of capturing telemetry

For our sample application, we expect to capture telemetry at three different levels:

  1. Application: Telemetry at the application level would include the overall health of the application, as well as any critical failures and the ability to troubleshoot distributed services. This can also include infrastructure or cloud-platform-related status indicators.

  2. Service: Telemetry at the service level would include measurements related to performance, faults, exceptions, or domain-specific telemetry where appropriate.

  3. Component: Telemetry at the component level would be captured by the integration with Application Insights at the source code level or through custom code using the Application Insights SDK.

Another area in which things can become complicated is that of Azure Monitor and, specifically, Container Insights. Container Insights does offer a great deal of information at the cluster, namespace, deployment, service, and pod levels. It also collects a lot of information and can cause ingestion and data storage costs to increase considerably if proper retention periods are not set. When creating a new Kubernetes cluster in Azure, we can now specify whether we wish to install Container Insights or leave it turned off.

This is where frameworks such as OpenTelemetry can come in handy because it’s purposefully built to be service- and platform-agnostic but offers a common way to expose the application telemetry to external systems. Let’s dig into OpenTelemetry a bit further through an example illustrating how to easily set up and use telemetry capture within a standard API project.

Get hands-on with 1400+ tech skills courses.