How to monitor applications by using OpenTelemetry on Azure Container Apps by info.odysseyx@gmail.com September 9, 2024 written by info.odysseyx@gmail.com September 9, 2024 0 comment 3 views 3 ~ 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. 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 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. “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 Share 0 FacebookTwitterPinterestEmail info.odysseyx@gmail.com previous post Most widely used SharePoint Framework ISVs from the Store – August 2024 next post AMD, Copilot+ set the stage for Xbox AI You may also like Insights from MVPs at the Power Platform Community Conference October 10, 2024 Restoring an MS SQL 2022 DB from a ANF SnapShot October 10, 2024 Your guide to Intune at Microsoft Ignite 2024 October 10, 2024 Partner Blog | Build your team’s AI expertise with upcoming Microsoft partner skilling opportunities October 10, 2024 Attend Microsoft Ignite from anywhere in the world! October 10, 2024 Get tailored support with the new Partner Center AI assistant (preview) October 10, 2024 Leave a Comment Cancel Reply Save my name, email, and website in this browser for the next time I comment.