Home NewsX How to monitor applications by using OpenTelemetry on Azure Container Apps

How to monitor applications by using OpenTelemetry on Azure Container Apps

by info.odysseyx@gmail.com
0 comment 3 views


~ inside method #1 and #2The front-end application (app1) calls the REST API sequentially for each secondary operation. In contrast, in the method involving Dapr, each REST API call appears to be isolated. This happens because Dapr handles the communication between container apps, which cannot see the internal processing of the application.

image-3.png

You can forward both system and console logs to Log Analytics within your container app environment. Only console logs are collected (no events or metrics), but this is the simplest way to output platform logs without changing your application’s code or container app configuration.

The following article details the steps to enable logging to Log Analytics in your container app. Log storage and monitoring options for Azure Container Apps

image-10.png

As you can see, without that ID, it becomes difficult to track application transactions based on logs generated by Log Analytics.

Application Monitoring with Application Insights and OpenTelemetry

For those of you who are new to Application Insights and OpenTelemetry, here’s a quick introduction. If you’re already familiar with these topics, feel free to skip ahead. conclusion.

What Application Insights Can Do

Application Insights is an Azure native service designed for application monitoring. It lets you collect logs, metrics, and traces from your applications and visualize the data.

reference Application Insights Overview Click to view the Application Insights summary.

Application Insights is an Azure service that is compatible with OpenTelemetry, an open standard for monitoring. It supports various language SDKs and receives data from OpenTelemetry, enabling application monitoring without code changes. The service conveniently handles traces, logs, and metrics all in one place.

A brief guide on how to monitor Java applications using Application Insights. There are two ways to leverage Application Insights in Java.

  • Specifying Azure Monitor OpenTelemetry Distro as a Java Agent
  • Integrate directly into your source code

The agent method requires replacing the OpenTelemetry agent with the Azure Monitor OpenTelemetry Distro. Before starting a Java application with the Java agent, you must set the connection string in the environment variables or configuration file as described below.

export APPLICATIONINSIGHTS_CONNECTION_STRING=<Your Connection String>
  java -javaagent:"path/to/applicationinsights-agent-3.5.3.jar" -jar myapp.jar

For implementation details, see the “Activating Using Code” section of this document.

Using Azure Monitor Application Insights with Spring Boot

The Java agent for Application Insights acts as a wrapper around the OpenTelemetry component and provides similar functionality. It also includes an extended implementation that leverages features available in Application Insights. For more information, see: Why should I use “Azure Monitor OpenTelemetry Distro”?

What OpenTelemetry Can Do

OpenTelemetry can collect logs, metrics, and traces, and integrate them with a variety of compatible tools. For an overview, visit: Official site.

The key points are:

Similar to the Application Insights integration described above, there are two ways to add OpenTelemetry to your Java app.

  • Using OpenTelemetry agent as Java agent via command line arguments (codeless instrumentation)
  • Add directly to source code (code-based instrumentation)

To use the no-code instrumentation approach, simply add the Java agent as a Java command argument for seamless integration without modifying your code.

# If Application Insights is used, this OpenTelemetry Java agent can be replaced by an Application Insights agent as discussed earlier.
java -javaagent:./opentelemetry-javaagent.jar -jar myapp.jar

To send metrics and logs using the following code, you need to create an OpenTelemetry instance using the Java Agent.

    package com.example.otelsample;
  import io.opentelemetry.api.OpenTelemetry;
  import org.springframework.context.annotation.Bean;
  import org.springframework.context.annotation.Configuration;
  import io.opentelemetry.api.GlobalOpenTelemetry;
  
  @Configuration
  public class OpenTelemetryConfig {
      @Bean
      public OpenTelemetry openTelemetry() {
          return GlobalOpenTelemetry.get();
      }
  }

After these steps, you can use the code below to output logs, generate events, and generate metrics with OpenTelemetry.

    // Start an OpenTelemetry span and send an event
  Span span = tracer.spanBuilder("CalcController").startSpan();
  span.addEvent("Start calc");
  
  // Output a log
  logger.info("Dummy log message");
  
  // Create a counter
  counter = meter.counterBuilder("calc.counter")
          .setDescription("How many times the calculator has been run.")
          .setUnit("runs")
          .build();
  counter.add(1);

For code-based instrumentation implementation, see the following documentation: https://opentelemetry.io/docs/languages/java/instrumentation/#manual-instrumentation-setup

You need to collect and visualize data from OpenTelemetry. Open source tools like Jaeger and Zipkin handle traces and logs, while Prometheus collects metrics that can be visualized with Grafana.

OpenTelemetry Collector allows you to collect data without embedding the code for each tool into your application. It acts as an interface between your app and various tools. Demo Architecture The official documentation makes it easy to understand.

Tsunomuru_0-1725333487280.png

“Demo Architecture”, OpenTelemetry.io, https://opentelemetry.io/docs/demo/architecture/

The application sends data to the OpenTelemetry Collector’s endpoint (http://localhost:)./, port is 4317 or 4318) backend endpoints are specified in the OpenTelemetry Collector configuration.

For example, the configuration for the OpenTelemetry Collector would be:

receivers:
    otlp:
      protocols:
        grpc:
          endpoint: 0.0.0.0:4317
        http:
          endpoint: 0.0.0.0:4318
  
  exporters:
    debug:
      verbosity: detailed
    otlp/jaeger:
      endpoint: jaeger-all-in-one:4317
      tls:
        insecure: true
    prometheus:
      endpoint: "0.0.0.0:8889"
      const_labels:
        label1: value1
    zipkin:
      endpoint: "http://zipkin-all-in-one:9411/api/v2/spans"
      format: proto
  processors:
    batch:
  
  extensions:
    health_check:
    pprof:
      endpoint: :1888
    zpages:
      endpoint: :55679
  
  service:
    telemetry:
      logs:
        level: DEBUG
        sampling:
          enabled: false
    extensions: [pprof, zpages, health_check]
    pipelines:
      traces:
        receivers: [otlp]
        exporters: [debug, zipkin, otlp/jaeger]
      metrics:
        receivers: [otlp]
        processors: [batch]
        exporters: [debug, prometheus]
      logs:
        receivers: [otlp]
        exporters: [debug]

This configuration is based on “Configuration”, OpenTelemetry.io. https://opentelemetry.io/docs/collector/configuration/

Set up a receiving endpoint in the receiver, and configure an export target in the exporter. Configuring a service in the pipeline will allow you to receive traces from the OTLP endpoint and export them to Zipkin.

OpenTelemetry is vendor-agnostic and gives developers choice, but it requires different tools. For example, you can use Jaeger for logs and Prometheus for metrics, and each requires specific configuration.

Application Insights simplifies data collection and visualization by providing a single service, eliminating the need to train multiple services.





Source link

You may also like

Leave a Comment

Our Company

Welcome to OdysseyX, your one-stop destination for the latest news and opportunities across various domains.

Newsletter

Subscribe my Newsletter for new blog posts, tips & new photos. Let's stay updated!

Laest News

@2024 – All Right Reserved. Designed and Developed by OdysseyX