Compartir a través de

Observabilidad de .NET con OpenTelemetry

  • Artículo

Cuando ejecute una aplicación, querrá saber su rendimiento y detectar posibles problemas antes de que se agraven. Puede hacerlo emitiendo datos de telemetría como registros o métricas de la aplicación y, a continuación, supervisando y analizando esos datos.

¿Qué es la observabilidad?

La observabilidad en el contexto de un sistema distribuido es la capacidad de supervisar y analizar la telemetría sobre el estado de cada componente, para poder observar los cambios en el rendimiento y diagnosticar por qué se producen esos cambios. A diferencia de la depuración, que es invasiva y puede afectar al funcionamiento de la aplicación, la observabilidad pretende ser transparente para el funcionamiento principal y tener un impacto en el rendimiento lo suficientemente pequeño como para que pueda utilizarse de forma continua.

La observabilidad se realiza normalmente mediante una combinación de:

  • Registros, que registran operaciones individuales, como una solicitud entrante, un error en un componente específico o un pedido que se realiza.
  • Métricas, que miden contadores y medidores, como el número de solicitudes completadas, solicitudes activas, widgets que se han vendido; o un histograma de la latencia de solicitud.
  • Seguimiento distribuido, que realiza un seguimiento de las solicitudes y actividades entre componentes de un sistema distribuido para que pueda ver dónde se invierte el tiempo y realizar un seguimiento de errores específicos.

Juntos, los registros, las métricas y el seguimiento distribuido se conocen a veces como los tres pilares de observabilidad.

Cada pilar puede incluir datos de telemetría de:

  • El entorno de ejecución de .NET, como el recolector de elementos no utilizados o el compilador JIT.
  • Bibliotecas, como desde Kestrel (el servidor web de ASP.NET) y HttpClient.
  • Telemetría específica de la aplicación emitida por el código.

Enfoques de observabilidad en .NET

Hay varias maneras diferentes de lograr la observabilidad en las aplicaciones de .NET:

  • Explícitamente en el código, consultando y utilizando una biblioteca como OpenTelemetry. Si tiene acceso al código fuente y puede recompilar la aplicación, este es el mecanismo más eficaz y configurable.
  • Fuera de proceso mediante EventPipe. Las herramientas como dotnet-monitor pueden escuchar registros y métricas y, a continuación, procesarlos sin afectar al código.
  • Usando un gancho de inicio, se pueden inyectar montajes en el proceso que luego pueden recopilar instrumentación. Un ejemplo de este enfoque es la Instrumentación automática de OpenTelemetry .NET.

¿Qué es OpenTelemetry?

OpenTelemetry (OTel) es un estándar multiplataforma abierto para recopilar y emitir datos de telemetría. OpenTelemetry incluye:

  • API para bibliotecas que se pueden utilizar para registrar datos de telemetría mientras se ejecuta el código.
  • APIs que los desarrolladores de aplicaciones utilizan para configurar qué parte de los datos registrados se enviarán a través de la red, a dónde se enviarán y cómo pueden filtrarse, almacenarse en búfer, enriquecerse y transformarse.
  • Las convenciones semánticas proporcionan orientación sobre la denominación y el contenido de los datos telemétricos. Es importante que las aplicaciones que producen datos telemétricos y las herramientas que reciben los datos se pongan de acuerdo sobre lo que significan los distintos tipos de datos y qué clase de datos son útiles para que las herramientas puedan proporcionar un análisis eficaz.
  • Una interfaz para exportadores. Los exportadores son complementos que permiten transmitir datos de telemetría en formatos específicos a diferentes back-end de telemetría.
  • El protocolo de conexión OTLP es una opción de protocolo de red neutral del proveedor para transmitir datos de telemetría. Algunas herramientas y proveedores admiten este protocolo además de los protocolos propietarios preexistentes que pueden tener.

El uso de OTel permite el uso de una amplia variedad de sistemas APM, incluidos sistemas de código abierto como Prometheus y Grafana, Azure Monitor: producto de APM de Microsoft en Azure o de muchos proveedores de APM que se asocian con OpenTelemetry.

Hay implementaciones de OpenTelemetry para la mayoría de lenguajes y plataformas, incluido .NET.

Implementación de .NET de OpenTelemetry

La implementación de OpenTelemetry de .NET es un poco diferente de otras plataformas, ya que .NET proporciona las API de registro, métricas y actividad en el marco. Eso significa que OTel no necesita proporcionar API para que las utilicen los autores de bibliotecas. La implementación de OTel de .NET usa estas API de plataforma para la instrumentación:

Arquitectura OTel de .NET

Donde OTel entra en juego es que recoge telemetría de esas API y otras fuentes (a través de bibliotecas de instrumentación) y luego las exporta a un sistema de monitorización del rendimiento de las aplicaciones (APM) para su almacenamiento y análisis. La ventaja que OTel aporta como estándar del sector es un mecanismo común para la recopilación, los esquemas comunes y la semántica de los datos de telemetría, y una API para cómo se pueden integrar las API con OTel. El uso de OTel significa que las aplicaciones no necesitan usar API o estructuras de datos específicas de APM; funcionan con el estándar OTel. Las API pueden implementar un componente de exportador específico de APM o usar OTLP, que es un nuevo estándar de conexión para exportar datos de telemetría a los sistemas APM.

Paquetes de OpenTelemetry

OpenTelemetry en .NET se implementa como una serie de paquetes NuGet que forman un par de categorías:

  • Core API
  • Instrumentación: estos paquetes recopilan instrumentación de las bibliotecas comunes y en tiempo de ejecución.
  • Exportadores: estas interfaces con sistemas APM como Prometheus, Jaeger y OTLP.

La siguiente tabla describe los principales paquetes.

Nombre del paquete Descripción
OpenTelemetry Biblioteca principal que proporciona la funcionalidad principal de OTEL
OpenTelemetry.Instrumentation.AspNetCore Instrumentación para ASP.NET Core y Kestrel
OpenTelemetry.Instrumentation.GrpcNetClient Instrumentación para el cliente gRPC para realizar un seguimiento de las llamadas gRPC salientes
OpenTelemetry.Instrumentation.Http Instrumentación para HttpClient y HttpWebRequest para el seguimiento de las llamadas HTTP salientes
OpenTelemetry.Instrumentation.SqlClient Instrumentación para SqlClient utilizada para rastrear las operaciones de la base de datos
OpenTelemetry.Exporter.Console Exportador de la consola, que se usa normalmente para diagnosticar qué telemetría se está exportando
OpenTelemetry.Exporter.OpenTelemetryProtocol Exportador que usa el protocolo OTLP
OpenTelemetry.Exporter.Prometheus.AspNetCore Exportador de Prometheus implementado mediante un punto de conexión de ASP.NET Core
OpenTelemetry.Exporter.Zipkin Exportador para el seguimiento de Zipkin

Ejemplos

Este tema continúa con un par de tutoriales de ejemplo para usar OpenTelemetry en .NET:

OpenTelemetry en .NET Aspire

.NET Aspire es un conjunto de extensiones en .NET para facilitar la creación y el trabajo con aplicaciones distribuidas. Una de las ventajas de usar .NET Aspire es que la telemetría está integrada mediante las bibliotecas de OpenTelemetry para .NET. Las plantillas de proyecto predeterminadas para .NET Aspire contienen un ServiceDefaults proyecto, parte de la cual consiste en configurar y configurar OTel. Se hace referencia al proyecto Service Defaults e inicializa cada servicio en una solución de .NET Aspire.

La plantilla de proyecto Service Defaults incluye el SDK de OTel, ASP.NET, HttpClient y los paquetes de instrumentación en tiempo de ejecución, y se configuran en el Extensions.cs archivo . Para exportar telemetría .NET Aspire incluye el exportador de OTLP de forma predeterminada para que pueda proporcionar visualización de telemetría mediante el panel Aspire.

El panel aspire está diseñado para llevar la observación de telemetría al ciclo de depuración local, lo que permite a los desarrolladores no solo asegurarse de que las aplicaciones producen telemetría, sino que también usan esa telemetría para diagnosticar esas aplicaciones localmente. La posibilidad de observar las llamadas entre servicios resulta ser tan útil en tiempo de depuración como en producción. El panel de .NET Aspire se inicia automáticamente al F5 el AppHost proyecto desde Visual Studio o dotnet run el AppHost proyecto.

Panel de Aspire

Para obtener más información sobre .NET Aspire, consulte:

Reutilización del proyecto de valores predeterminados del servicio sin orquestación aspire de .NET

Probablemente la manera más fácil de configurar OTel para proyectos de ASP.NET es usar el proyecto Aspire Service Defaults, incluso si no usa el resto de .NET Aspire, como AppHost para orquestación. El proyecto Service Defaults está disponible como plantilla de proyecto a través de Visual Studio o dotnet new. Configura OTel y configura el exportador de OTLP. A continuación, puede usar las variables de entorno de OTel para configurar el punto de conexión de OTLP para enviar telemetría y proporcionar las propiedades de recursos para la aplicación.

Los pasos para usar ServiceDefaults fuera de .NET Aspire son:

  • Agregue el proyecto ServiceDefaults a la solución mediante Agregar nuevo proyecto en Visual Studio o use dotnet new aspire-servicedefaults --output ServiceDefaults
  • Haga referencia al proyecto ServiceDefaults desde la aplicación de ASP.NET. En Visual Studio, use "Agregar -> Referencia del proyecto" y seleccione el proyecto ServiceDefaults .
  • Llame a su función de configuración openTelemetry como parte de la inicialización del generador de aplicaciones.
var builder = WebApplication.CreateBuilder(args);
builder.ConfigureOpenTelemetry();

var app = builder.Build();

app.MapGet("/", () => "Hello World!");

app.Run();

Los valores predeterminados del servicio pueden configurar la siguiente funcionalidad adicional si es necesario a través AddServiceDefaults() de o las funciones específicas:

  • Comprobaciones de estado con /health puntos de conexión y /alive
  • Detección de servicios que será una operación no operativa sin el resto de .NET Aspire
  • Configuración de la resistencia para HttpClient que reintentará la solicitud en caso de errores