Cuando OpenTelemetry se encuentra con Alibaba Cloud Prometheus

01 fondo

A medida que la observabilidad nativa de la nube está en auge, todos deben estar familiarizados con OpenTelemetry y Prometheus. OpenTelemetry es un proyecto de código abierto de CNCF (Cloud Native Computing Foundation). Su objetivo es convertirse en el estándar de facto en el campo del monitoreo del rendimiento de aplicaciones en la era nativa de la nube. Proporciona una API y un SDK unificados para generar, recopilar y procesar. Distribución de datos de telemetría del sistema. En resumen, OpenTelemetry es un conjunto de estándares de observación que son independientes del lenguaje, admiten una variedad de marcos y lenguajes de programación y pueden integrarse con una variedad de plataformas de observación.

Prometheus es actualmente el sistema de monitoreo de código abierto más popular y ha sido adoptado por proyectos nativos de la nube ampliamente utilizados, como Kubernetes y Envoy. Aunque el lenguaje de consulta de Prometheus es muy poderoso, su formato de datos todavía lo define el propio Prometheus. Por tanto, sólo se puede integrar con el servidor Prometheus y no con otros sistemas.

OpenTelemetry promete crear un estándar unificado entre Trace, Log y Metric, por lo que su formato de datos está unificado, tiene suficiente flexibilidad e interactividad y es totalmente compatible con Prometheus, por lo que atrae cada vez más desarrollo y mantenimiento operativo. La gente usa OpenTelemetry para llevar Trace & Regístrelo y utilícelo para estadísticas métricas, integrándolo con el ecosistema de Prometheus para lograr una mejor observación y monitoreo.

Este artículo toma como punto de partida la construcción de la observabilidad del sistema (centrándose en el sistema de monitoreo de indicadores), compara las similitudes y diferencias entre OpenTelemetry y Prometheus, habla brevemente sobre algunos puntos de vista y opiniones sobre la elección personal y luego se centra en cómo conectarse. Los indicadores OpenTelemetry de la aplicación para Prometheus y los principios detrás de esto, y finalmente presenta la versión de Prometheus de monitoreo observable de Alibaba Cloud que abarca OpenTelemetry y casos de implementación relacionados, con la esperanza de ayudar mejor a los lectores a comprender mejor OpenTelemetry y la integración ecológica con Prometheus.

02 En la encrucijada de OpenTelemetry y Prometheus

Si usted, como personal de I + D y de operación y mantenimiento, está realizando observaciones del sistema, especialmente al construir un sistema de monitoreo de indicadores, tendrá mucha confusión sobre si elegir OpenTelemetry o Prometheus. Antes de responder a esta pregunta, primero debemos comprender claramente las similitudes y diferencias entre OpenTelemetry y Prometheus.

Antes de comparar, todavía necesitamos dar una introducción en profundidad al modelo de indicador de OpenTelemetry.

2.1 Introducción al modelo de indicador OpenTelemetry

OpenTelemetry descompone los indicadores en tres modelos de interacción: modelo de eventos, modelo de serie temporal y modelo de flujo métrico. El modelo de evento representa cómo el instrumento reporta los datos del indicador; el modelo Timeserie representa cómo el backend almacena los datos del indicador; el modelo de flujo métrico define el Protocolo OpenTelemetry (OTLP), que representa cómo operar y transmitir el flujo de datos del indicador entre el modelo de evento y almacenamiento de series temporales.

2.1.1 Modelo de evento

El modelo de eventos es donde ocurre el registro de datos y su base consiste en Instrumentos [1] , que se utilizan para registrar datos observables a través de eventos. Estos eventos sin procesar luego se transforman de alguna manera antes de enviarse a otros sistemas. Las métricas de OpenTelemetry están diseñadas para utilizar los mismos instrumentos y eventos de diferentes maneras para generar flujos de métricas.

Aunque los eventos de observación se pueden informar directamente al backend, en la práctica esto no es factible debido a la enorme cantidad de datos utilizados en el sistema observable y los recursos limitados de red/CPU disponibles para fines de recopilación de telemetría; el mejor ejemplo son los histogramas. Los eventos se registran en un formato comprimido en lugar de como una única serie de tiempo.

Nota: La figura anterior muestra cómo un instrumento convierte eventos en múltiples tipos de flujos de indicadores.

2.1.2 Modelo de series de tiempo

En el modelo de datos de indicadores de bajo nivel, las series temporales son definiciones de entidades compuestas por múltiples atributos de metadatos:

Nombre del indicador
Propiedades (dimensiones)
El tipo de valor del punto (entero, punto flotante, etc.)
Unidades de medida

Los datos sin procesar de cada serie temporal están ordenados (marca de tiempo, valor) en puntos con los siguientes tipos de valores:

Encimera
Indicador
histograma
Histograma exponencial

2.1.3 Modelo de datos del protocolo OpenTelemetry

El modelo de datos del OpenTelemetry Protocol (OTLP) consta de flujos de datos métricos, que a su vez se componen de puntos de datos métricos. Los flujos de datos métricos se pueden convertir directamente en series de tiempo. Los flujos de métricas se agrupan en objetos de métricas separados, identificados por:

Propiedad de recurso original
Alcance de la instrumentación (como el nombre de la biblioteca de instrumentación y la versión)
El nombre del flujo de indicadores.

Incluyendo el nombre, un objeto Métrico se define mediante las siguientes propiedades:

Tipo de punto de datos (por ejemplo, suma, indicador, histograma, histograma exponencial, resumen)
La unidad del flujo indicador (unidad)
Descripción del flujo de indicadores
Propiedades de puntos de datos internos (si corresponde): AggregationTemporality, Monotonic

Los tipos de puntos de datos, las unidades y las propiedades intrínsecas se consideran identificativos, mientras que los campos de descripción no son inherentemente identificativos. Los atributos extrínsecos de un punto en particular no se consideran identificativos; estos incluyen, entre otros:

Límites del cubo de puntos de datos del histograma
Tamaño del punto de datos del histograma exponencial o número de depósitos

Los objetos de métricas contienen diferentes flujos, identificados por Atributos. En cada flujo, los puntos se identifican mediante una o dos marcas de tiempo; los detalles varían según el tipo de punto de datos.

2.1.4 Introducción a los tipos de puntos

2.1.4.1 Suma

Sumas [2] en OTLP consta de las siguientes partes:

1. Temporalidad de Agregación Delta o acumulativa. 2. Un indicador que indica si Sum es monótono (monótono [3] ).

Para sumas monotónicas delta, esto significa que los lectores deben esperar valores no negativos
Para sumas monótonas acumulativas, esto significa que el lector debe esperar un valor no menor que el valor anterior.

Un conjunto de puntos de datos, cada punto de datos contiene:

Un conjunto de pares de nombre-valor de atributo independientes
Ventana de tiempo para calcular la suma
(opcional) un conjunto de ejemplos [4]

Cuando la temporalidad de agregación es "delta", esperamos que las ventanas de tiempo de los flujos de medición no se superpongan, como se muestra en la siguiente figura:

Y cuando la temporalidad agregada es "acumulativa", esperamos informar la suma total desde el "inicio" (donde generalmente inicio significa inicio del proceso/aplicación).

Existen varias compensaciones entre el uso delta y la agregación acumulativa en diversos casos de uso, como por ejemplo:

Se reinicia el proceso de detección
Calcular tarifa
Informes de métricas basados en push y pull

OTLP admite ambos modelos y permite que las API, los SDK y los usuarios determinen el mejor compromiso en sus respectivos escenarios.

2.1.4.2 Calibre

El indicador [5] en OTLP representa el valor muestreado en un momento dado. Un flujo de calibre consta de un conjunto de puntos de datos, cada uno de los cuales contiene:

Un conjunto de pares de nombre-valor de atributo independientes
Valor de muestra (como la temperatura actual de la CPU)
La marca de tiempo cuando se muestreó el valor (time_unix_nano)
(Opcional) Una marca de tiempo (start_time_unix_nano) que representa mejor el primer momento posible en el que se pueden registrar las mediciones; generalmente se establece en la marca de tiempo cuando se inició el sistema de recopilación de métricas.
(opcional) un conjunto de ejemplos

En OTLP, un punto en el flujo de medición representa el último evento muestreado en un período de tiempo determinado.

En este ejemplo, podemos ver que estamos muestreando la serie temporal subyacente usando Gauge y, si bien el modelo de eventos puede muestrear varias veces dentro de un intervalo de informes de métricas determinado, solo se informa el último valor en el flujo de métricas a través de OTLP.

Gauge no proporciona semántica de agregación, sino que utiliza el "último valor de muestra" al realizar operaciones como la alineación del tiempo o el ajuste de la resolución. El indicador se puede agregar convirtiéndolo a un histograma u otro tipo de métrica. Estas operaciones no se realizan de forma predeterminada y requieren una configuración directa por parte del usuario.

2.1.4.3 Histograma

Los puntos de datos métricos del histograma [6] transmiten los resultados de una gran cantidad de mediciones registradas en un formato comprimido. Un histograma divide un conjunto de eventos en grupos y proporciona un recuento general de eventos y una suma de todos los eventos.

El histograma consta de las siguientes partes:

1. Temporalidad de agregación delta o acumulativa 2. Un conjunto de puntos de datos, cada punto de datos contiene:

Un conjunto de pares de nombre-valor de atributo independientes
Ventana de tiempo para agrupar histogramas ((inicio, fin])
El recuento del número total de puntos en el histograma (recuento)
La suma de todos los valores en el histograma (suma)
(Opcional) Mínimo (min) de todos los valores en el histograma
(Opcional) Valor máximo (max) de todos los valores en el histograma
(Opcional) Un rango de depósitos: valores de límite explícitos que representan los límites inferior y superior del depósito y si una observación determinada se registra en ese depósito; un recuento del número de observaciones que pertenecen a ese depósito.
(opcional) un conjunto de ejemplos

Al igual que las sumas, los histogramas también definen la temporalidad agregada. El diagrama anterior representa la temporalidad delta, donde el recuento de eventos acumulado se restablece a cero después del informe y se produce una nueva agregación. La acumulación, por otro lado, continúa agregando eventos y se reinicia con una nueva hora de inicio. Temporalidad de agregación La temporalidad de agregación también tiene un impacto en los campos Min y Max. Min y Max son más útiles para la temporalidad delta (Delta) porque a medida que se registran más eventos, los valores representados por el Min y Max acumulativos se estabilizarán. Además, los valores mínimo y máximo se pueden convertir de Delta a Acumulado, pero no de Acumulado a Delta. Al convertir de acumulativo a delta, los valores mínimo y máximo se pueden eliminar o capturar en una representación alternativa (como un indicador).

El número de cubos es opcional. Un histograma sin depósitos transmite la población únicamente en términos de sumas y recuentos, y se puede interpretar como un histograma con cobertura de un solo depósito (-Inf, +Inf), como se muestra a continuación para datos de muestra de histograma de tipo acumulativo.

2023-11-29T13:43:45.238Z  info  ResourceMetrics #0
Resource SchemaURL: 
Resource attributes:
     -> service.name: Str(opentelemetry-metric-demo-delta-or-cumulative)
     -> service.version: Str(0.0.1)
     -> telemetry.sdk.language: Str(java)
     -> telemetry.sdk.name: Str(opentelemetry)
     -> telemetry.sdk.version: Str(1.29.0)
ScopeMetrics #0
ScopeMetrics SchemaURL: 
InstrumentationScope aliyun 
Metric #0
Descriptor:
     -> Name: cumulative_long_histogram
     -> Description: ot cumulative demo cumulative_long_histogram
     -> Unit: ms
     -> DataType: Histogram
     -> AggregationTemporality: Cumulative
HistogramDataPoints #0
StartTimestamp: 2023-11-29 13:43:15.181 +0000 UTC
Timestamp: 2023-11-29 13:43:45.182 +0000 UTC
Count: 2
Sum: 141.000000
Min: 62.000000
Max: 79.000000
ExplicitBounds #0: 0.000000
ExplicitBounds #1: 5.000000
ExplicitBounds #2: 10.000000
ExplicitBounds #3: 25.000000
ExplicitBounds #4: 50.000000
ExplicitBounds #5: 75.000000
ExplicitBounds #6: 100.000000
ExplicitBounds #7: 250.000000
ExplicitBounds #8: 500.000000
ExplicitBounds #9: 750.000000
ExplicitBounds #10: 1000.000000
ExplicitBounds #11: 2500.000000
ExplicitBounds #12: 5000.000000
ExplicitBounds #13: 7500.000000
ExplicitBounds #14: 10000.000000
Buckets #0, Count: 0
Buckets #1, Count: 0
Buckets #2, Count: 0
Buckets #3, Count: 0
Buckets #4, Count: 0
Buckets #5, Count: 1
Buckets #6, Count: 1
Buckets #7, Count: 0
Buckets #8, Count: 0
Buckets #9, Count: 0
Buckets #10, Count: 0
Buckets #11, Count: 0
Buckets #12, Count: 0
Buckets #13, Count: 0
Buckets #14, Count: 0
Buckets #15, Count: 0

2.1.4.4 Histograma exponencial

Los puntos de datos de histograma exponencial son una representación alternativa de los puntos de datos de histograma y se utilizan para transmitir un conjunto de mediciones registradas en un formato comprimido. ExponentialHistogram utiliza una fórmula exponencial para comprimir los límites del depósito, lo que lo hace adecuado para transmitir datos de alto rango dinámico con errores relativos más pequeños en comparación con representaciones alternativas de tamaño similar.

El histograma implica temporalidad de agregación, atributos y marcas de tiempo, así como campos de suma, recuento, mínimo, máximo y ejemplos. El histograma exponencial es similar al histograma. Estos campos tienen la misma interpretación que el histograma, solo que se almacenan entre estos dos tipos. La estructura del depósito es diferente. El siguiente es un formato de datos de histograma exponencial en forma delta:

2023-11-29T13:13:09.866Z  info  ResourceMetrics #0
Resource SchemaURL: 
Resource attributes:
     -> service.name: Str(opentelemetry-metric-demo-delta-or-cumulative)
     -> service.version: Str(0.0.1)
     -> telemetry.sdk.language: Str(java)
     -> telemetry.sdk.name: Str(opentelemetry)
     -> telemetry.sdk.version: Str(1.29.0)
ScopeMetrics #0
ScopeMetrics SchemaURL: 
InstrumentationScope aliyun 
Metric #0
Descriptor:
     -> Name: cumulative_long_e_histogram
     -> Description: ot cumulative demo cumulative_long_e_histogram
     -> Unit: ms
     -> DataType: ExponentialHistogram
     -> AggregationTemporality: Cumulative
ExponentialHistogramDataPoints #0
StartTimestamp: 2023-11-29 13:11:54.858 +0000 UTC
Timestamp: 2023-11-29 13:13:09.86 +0000 UTC
Count: 3
Sum: 191.000000
Min: 15.000000
Max: 89.000000
Bucket (14.993341, 15.321652], Count: 1
Bucket (15.321652, 15.657153], Count: 0
Bucket (15.657153, 16.000000], Count: 0
Bucket (16.000000, 16.350354], Count: 0
Bucket (16.350354, 16.708381], Count: 0
Bucket (16.708381, 17.074246], Count: 0
Bucket (17.074246, 17.448124], Count: 0
Bucket (17.448124, 17.830188], Count: 0
Bucket (17.830188, 18.220618], Count: 0
Bucket (18.220618, 18.619598], Count: 0
Bucket (18.619598, 19.027314], Count: 0
Bucket (19.027314, 19.443958], Count: 0
Bucket (19.443958, 19.869725], Count: 0
Bucket (19.869725, 20.304815], Count: 0
Bucket (20.304815, 20.749433], Count: 0
Bucket (20.749433, 21.203786], Count: 0
Bucket (21.203786, 21.668089], Count: 0
Bucket (21.668089, 22.142558], Count: 0
Bucket (22.142558, 22.627417], Count: 0
Bucket (22.627417, 23.122893], Count: 0
Bucket (23.122893, 23.629218], Count: 0
Bucket (23.629218, 24.146631], Count: 0
Bucket (24.146631, 24.675373], Count: 0
Bucket (24.675373, 25.215694], Count: 0
Bucket (25.215694, 25.767845], Count: 0
Bucket (25.767845, 26.332088], Count: 0
Bucket (26.332088, 26.908685], Count: 0
Bucket (26.908685, 27.497909], Count: 0
Bucket (27.497909, 28.100035], Count: 0
Bucket (28.100035, 28.715345], Count: 0
Bucket (28.715345, 29.344129], Count: 0
Bucket (29.344129, 29.986682], Count: 0
Bucket (29.986682, 30.643305], Count: 0
Bucket (30.643305, 31.314306], Count: 0
Bucket (31.314306, 32.000000], Count: 0
Bucket (32.000000, 32.700709], Count: 0
Bucket (32.700709, 33.416761], Count: 0
Bucket (33.416761, 34.148493], Count: 0
Bucket (34.148493, 34.896247], Count: 0
Bucket (34.896247, 35.660376], Count: 0
Bucket (35.660376, 36.441236], Count: 0
Bucket (36.441236, 37.239195], Count: 0
Bucket (37.239195, 38.054628], Count: 0
Bucket (38.054628, 38.887916], Count: 0
Bucket (38.887916, 39.739450], Count: 0
Bucket (39.739450, 40.609631], Count: 0
Bucket (40.609631, 41.498866], Count: 0
Bucket (41.498866, 42.407573], Count: 0
Bucket (42.407573, 43.336178], Count: 0
Bucket (43.336178, 44.285116], Count: 0
Bucket (44.285116, 45.254834], Count: 0
Bucket (45.254834, 46.245786], Count: 0
Bucket (46.245786, 47.258437], Count: 0
Bucket (47.258437, 48.293262], Count: 0
Bucket (48.293262, 49.350746], Count: 0
Bucket (49.350746, 50.431387], Count: 0
Bucket (50.431387, 51.535691], Count: 0
Bucket (51.535691, 52.664175], Count: 0
Bucket (52.664175, 53.817371], Count: 0
Bucket (53.817371, 54.995818], Count: 0
Bucket (54.995818, 56.200069], Count: 0
Bucket (56.200069, 57.430690], Count: 0
Bucket (57.430690, 58.688259], Count: 0
Bucket (58.688259, 59.973364], Count: 0
Bucket (59.973364, 61.286610], Count: 0
Bucket (61.286610, 62.628612], Count: 0
Bucket (62.628612, 64.000000], Count: 0
Bucket (64.000000, 65.401418], Count: 0
Bucket (65.401418, 66.833522], Count: 0
Bucket (66.833522, 68.296986], Count: 0
Bucket (68.296986, 69.792495], Count: 0
Bucket (69.792495, 71.320752], Count: 0
Bucket (71.320752, 72.882473], Count: 0
Bucket (72.882473, 74.478391], Count: 0
Bucket (74.478391, 76.109255], Count: 0
Bucket (76.109255, 77.775831], Count: 0
Bucket (77.775831, 79.478900], Count: 0
Bucket (79.478900, 81.219261], Count: 0
Bucket (81.219261, 82.997731], Count: 0
Bucket (82.997731, 84.815145], Count: 0
Bucket (84.815145, 86.672355], Count: 0
Bucket (86.672355, 88.570232], Count: 1
Bucket (88.570232, 90.509668], Count: 1

2.1.4.4.1 Escala exponencial

La resolución del histograma exponencial se caracteriza por el parámetro de escala: cuanto mayor sea el valor de la escala, mayor será la precisión. El límite del cubo del histograma exponencial se encuentra en la potencia entera de la base, también llamado "factor de crecimiento", donde:

base = 2**(2**(-scale))

El símbolo ** en estas fórmulas representa exponenciación, por lo que 2**x se lee como "2 elevado a x" y generalmente se calcula mediante expresiones como math.Pow(2.0, x). El siguiente es un ejemplo oficial de OpenTelemetry, la base de cálculo de la escala seleccionada es la siguiente:

Una propiedad importante de este diseño se describe como "subconjunto perfecto", donde los depósitos con un histograma exponencial de una escala determinada se asignan exactamente a depósitos con un histograma exponencial de una escala más pequeña, lo que permite al consumidor reducir la resolución de la tasa del histograma ( es decir, relación de reducción) sin introducir errores. Los datos delta ExponentialHistogram anteriores utilizan la agregación Base2ExponentialHistogramAggregation predeterminada, donde la escala máxima es 20.

private static final int DEFAULT_MAX_BUCKETS = 160;
    private static final int DEFAULT_MAX_SCALE = 20;
    private static final Aggregation DEFAULT = new Base2ExponentialHistogramAggregation(160, 20);
    private final int maxBuckets;
    private final int maxScale;

    private Base2ExponentialHistogramAggregation(int maxBuckets, int maxScale) {
        this.maxBuckets = maxBuckets;
        this.maxScale = maxScale;
    }

    public static Aggregation getDefault() {
        return DEFAULT;
    }

    public static Aggregation create(int maxBuckets, int maxScale) {
        Utils.checkArgument(maxBuckets >= 1, "maxBuckets must be > 0");
        Utils.checkArgument(maxScale <= 20 && maxScale >= -10, "maxScale must be -10 <= x <= 20");
        return new Base2ExponentialHistogramAggregation(maxBuckets, maxScale);
    }

2.1.4.4.2 Cubos exponenciales

Los grupos de histograma exponencial identificados por índice (entero con signo) representan valores en la población que son mayores que el índice base ** y menores o iguales que la base ** (índice + 1), representados por los rangos positivos y negativos de el histograma, respectivamente. Los valores negativos se asignan al rango negativo mediante su valor absoluto, utilizando la misma escala que el rango positivo. Tenga en cuenta que, por lo tanto, en el rango negativo, los depósitos de histograma utilizan un límite inferior. Cada rango de puntos de datos del Histograma Exponencial se representa mediante una representación densa de depósitos, donde el rango del depósito se representa como un valor de compensación único, una matriz de enteros con signo y valores de recuento, donde el elemento de matriz i representa el desplazamiento del recuento de depósitos + i del índice de cubo.

Para un rango determinado (positivo o negativo):

El índice 0 del depósito de almacenamiento cuenta las mediciones en el rango (1, base)
Un índice positivo corresponde a un valor absoluto mayor que la base
Los índices negativos corresponden a valores absolutos menores o iguales a 1
Hay 2** cubos de escala entre 2 poderes consecutivos.

Por ejemplo, cuando escala=3, hay 2**3 depósitos entre 1 y 2. Tenga en cuenta que el límite inferior del índice de depósito 4 en el histograma de escala=3 se asigna al límite inferior del índice de depósito 2 en el histograma de escala=2. .límite inferior y se asigna al límite inferior del índice de depósito 1 (es decir, la base) en el histograma escala=3. 1 Histograma: estos son ejemplos de subconjuntos perfectos.

Ps: dado que Summay ya no se recomienda en la última versión, no daré una introducción detallada aquí.

2.2 OpenTelemetry VS Prometheus

En este artículo, no presentaremos los tipos de indicadores de Prometheus en detalle. Para una introducción detallada, consulte la introducción del sitio web oficial de Prometheus [7] . Al comparar los tipos de indicadores OpenTelemetry y los tipos de indicadores Prometheus, encontraremos:

OpenTelemetry puede representar métricas como deltas en lugar de acumulativas, almacenando la diferencia entre cada punto de datos en lugar de la suma acumulativa. Sin embargo, Prometheus no está diseñado para permitir esto.
OpenTelemetry permite que los valores métricos sean números enteros, mientras que Prometheus no puede expresar números de punto flotante.
OpenTelemetry puede agregar algunos metadatos adicionales al histograma, lo que le permite realizar un seguimiento de los valores máximos y mínimos, lo que puede resultar muy útil en algunos escenarios.
OpenTelemetry tiene un tipo de agregación de histograma exponencial (que utiliza fórmulas y escalas para calcular el tamaño del depósito), que Prometheus no admite, pero es compatible.

Para resumir de la comparación de modelos anterior, OpenTelemetry permite la representación de todos los tipos de métricas de Prometheus (contadores, medidores, resúmenes e histogramas), aunque Prometheus no puede representar ciertas configuraciones de métricas de OpenTelemetry, incluidas representaciones delta e histogramas exponenciales (aunque pronto lo harán). agregarse a Prometheus) y valores enteros. En otras palabras, las métricas de Prometheus son un subconjunto estricto de las métricas de OpenTelemetry.

A pesar de esto, todavía existen algunas diferencias entre los dos, que es necesario resaltar aquí.

Prometheus proporciona recopilación, almacenamiento y consulta de métricas. Recopila indicadores agarrando objetivos. Por supuesto, también se puede utilizar en forma de puerta de enlace. Los datos de métricas relevantes finalmente se almacenan en la base de datos local de Prometheus u otras bases de datos remotas, y finalmente a través de el lenguaje de consulta de Prometheus, PromQL, lee datos, por lo que Prometheus es una solución observable completa que integra recopilación, cálculo, almacenamiento, alarmas y consultas de datos.
OpenTelemetry tiene un alcance mucho menor. Recopila métricas (así como seguimientos y registros) utilizando API integradas mediante push o pull, y las envía a otros sistemas para su almacenamiento o consulta. Por lo tanto, OpenTelemetry solo se centra en la parte de observabilidad de las interacciones de las aplicaciones, desvinculando así la creación de señales de las cuestiones operativas de almacenamiento y consulta de señales. Por lo tanto, OpenTelemetry Metric generalmente regresa a Prometheus o a un sistema compatible con Prometheus para el almacenamiento de métricas.

2.3 Cómo elegir

Es innegable que OpenTelemetry y Prometheus son muy buenos y, a veces, la elección es realmente confusa, por lo que el principio general es partir del escenario empresarial real, adaptarse a las condiciones locales y analizar el problema desde una perspectiva de desarrollo. Si hay algún problema con la siguiente breve discusión, no dude en comunicarme, criticarme y corregirme.

Si intenta construir un sistema observable unificado que incluya seguimiento, registro y métrica, OpenTelemetry permitirá el uso de la misma biblioteca para detectar los tres tipos de señales, lo que reducirá las dependencias de los paquetes y facilitará la gestión de operación y mantenimiento. Este es un beneficio significativo: OpenTelemetry admite tres señales idénticas que se pueden enviar al mismo backend o a diferentes backends.
Si desea que los indicadores de monitoreo de su aplicación/sistema/componente se observen mejor en escenarios nativos de la nube y en contenedores, especialmente aquellos que son de código abierto y utilizados por terceros, generalmente se recomienda utilizar Prometheus en este escenario, como el Intermedio común. Redis, MySQL, Zookeeper, etc. admiten el formulario Prometheus Exporter para exponer indicadores.
Por ejemplo, en entornos de red especiales u otras restricciones, el formulario de extracción de Prometheus no se puede utilizar, pero cuando el formulario de puerta de enlace de Prometheus tiene varias desventajas, puede intentar utilizar el formulario de inserción de OpenTelemetry.

Pero no importa cuál sea la elección, lo que es un poco vergonzoso es que incluso si el cliente elige OpenTelemetry, el almacenamiento real de OpenTelemetry Metric a menudo regresa a Prometheus. Así es como están las cosas en este momento, y la mayoría de las organizaciones probablemente utilicen una combinación de los dos estándares: Prometheus para el monitoreo de infraestructura, aprovechando un ecosistema de integración más maduro para extraer métricas de cientos de componentes, y OpenTelemetry para servicios desarrollados.

En el siguiente capítulo, nos centramos en cómo conectar indicadores OpenTelemetry a Prometheus.

03 Cómo conectar OpenTelemetryMetric a Prometheus

3.1 Introducción al principio

El elemento central de conectar los indicadores de OpenTelemetry a Prometheus es convertir los indicadores de OpenTelemetry al formato de indicador de Prometheus, por lo que ya sea en forma de OpenTelemetry Collector o directamente en forma de puente exportador de Prometheus en el cliente, es esencialmente una conversión de formato de datos.

1) Sitio web oficial de OpenTelemetry

La siguiente figura muestra la ruta de conversión de indicadores OpenTelemetry a indicadores Prometheus recomendados por la documentación del sitio web oficial de OpenTelemetry.

Documento de referencia detallado:otlp-metric-points-to-prometheus [8]

2) Implementación del recopilador OpenTelemetry

La implementación específica de OpenTelemetry Collector es ligeramente diferente de la implementación recomendada en el sitio web oficial. Para una implementación detallada, consulte prometheus-client-bridge [9] . La relación de conversión específica se muestra en la siguiente figura. Las principales diferencias con el documento oficial de OpenTelemetry son los siguientes puntos.

La documentación oficial de OpenTelemetry recomienda convertir sumas monótonas y delta en contador acumulativo de Prometheus; mientras que el puente Prometheus de OpenTelemetry Collector convierte directamente este tipo en calibre Prometheus.
La documentación oficial de OpenTelemetry recomienda convertir delta de histograma a acumulativo y, por lo tanto, a histograma de Prometheus; aunque el código de OpenTelemetry Collector no distingue entre acumulativo y delta de histograma, en realidad solo admite la conversión de histograma acumulativo a histograma de Prometheus.
La documentación oficial de OpenTelemetry recomienda convertir el histograma exponencial acumulado en histogramas Prometheus y, en OpenTelemetry Collector, el histograma exponencial acumulado y el delta del histograma exponencial se descartan.

3.2 Métodos de acceso tradicionales

Tomando las aplicaciones Java como ejemplo, actualmente existen varias formas comunes para que las aplicaciones Java (similares a otras aplicaciones multilingües) conecten indicadores OpenTelemetry a Prometheus. Por supuesto, existen otras soluciones, como el uso de un micrómetro, que no se discutirá aquí. .

Método 1: la aplicación expone los indicadores de OpenTelemetry y los informa a OpenTelemetry Collector a través de gRpc/HTTP. OpenTelemetry Collector expone los indicadores de Prometheus en forma de exportador de Prometheus. Prometheus puede recopilarlos en forma de trabajos estáticos (u otros métodos de descubrimiento de servicios).

Demostración detallada de referencia de código: https://github.com/OuyangKevin/opentelemetry-metric-java-demo/blob/main/metric-http/README.md

Método 2: la aplicación expone los indicadores de OpenTelemetry a través de gRpc/HTTP y los informa a OpenTelemetry Collector, que convierte directamente los indicadores al formato de indicador de Prometheus y luego los escribe en el Prometheus remoto en forma de escritura remota.

Demostración detallada de referencia de código: https://github.com/OuyangKevin/opentelemetry-metric-java-demo/blob/main/metric-grpc/README.md

Ps: la versión anterior de OpenTelemetry Collector no admite el formulario de escritura remota. Si necesita verificar, utilice la última versión.

Método 3: la aplicación Java presenta OpenTelemetry-exporter-prometheus lib, expone directamente los indicadores de OpenTelemetry en forma de Prometheus Exporter y Prometheus los recopila directamente en forma de extracción.

El siguiente es el código central de inicialización:

Demostración detallada de referencia de código: https://github.com/OuyangKevin/opentelemetry-metric-java-demo/blob/main/metric-prometheus/README.md

PrometheusHttpServer prometheusHttpServer = PrometheusHttpServer.builder().setPort(1000).build();
Resource resource = Resource.getDefault().toBuilder().put(SERVICE_NAME, "opentelemetry-metric-demo-http").put(SERVICE_VERSION, "0.0.1").build();
SdkMeterProvider sdkMeterProvider = SdkMeterProvider.builder()
        .registerMetricReader(prometheusHttpServer)
        .setResource(resource)
        .build();

LongCounter longCounter = sdkMeterProvider
        .get("aliyun")
        .counterBuilder("ping_long_counter")
        .setDescription("ot http demo long_counter")
        .setUnit("ms")
        .build();

04 Monitoreo observable La versión Prometheus adopta OpenTelemetry desde la distancia

En la actualidad, la versión de Prometheus de monitoreo observable de Alibaba Cloud es totalmente compatible con el acceso al indicador OpenTelemetry. Los usuarios solo necesitan modificar la dirección de informes relevante y la configuración de autenticación para acceder sin problemas a la versión de Prometheus de monitoreo observable. Bienvenido a la experiencia de la consola Prometheus [10].

Para conocer las restricciones de uso detalladas, consulte las instrucciones de uso de la dirección de informes del indicador OpenTelemetry: https://help.aliyun.com/zh/prometheus/user-guide/instructions-for-using-the-reporting-address-of-opentelemetry- indicador/

4.1 Preparación

Antes de conectarse a la versión de Prometheus de monitoreo observable, asegúrese de haber creado los siguientes tipos de instancias de Prometheus. Para operaciones específicas, consulte:

Instancia de Prometheus para servicio de contenedores [11]
Instancia de Prometheus para uso general [12]
Instancia de Prometheus para ECS [13]
Instancia de Prometheus para servicio en la nube [14]

4.2 Obtener la dirección de informes del indicador OpenTelemetry

1. Inicie sesión en la consola de Prometheus.

2. Haga clic en Lista de monitoreo en la barra de navegación izquierda para ingresar a la página de lista de instancias de la versión de monitoreo observable de Prometheus.

3. Seleccione la región donde se encuentra la instancia de Prometheus en la parte superior de la página y haga clic en Configuración en la columna de operación a la derecha de la instancia de Prometheus de destino.

4. En la pestaña Configuración, copie la dirección de informes del indicador OpenTelemetry de la red pública o intranet según sea necesario (actualmente solo se admite el formato HTTP y gRPC aún no se admite).

4.3 Transformación de aplicaciones

A continuación se utiliza el lenguaje Java como ejemplo para ocultar indicadores de OpenTelemetry en el proyecto SpringBoot.

Agregar dependencias

  <properties>
      <java.version>1.8</java.version>
      <org.springframework.boot.version>2.7.17</org.springframework.boot.version>
      <org.projectlombok.version>1.18.0</org.projectlombok.version>
      <opentelemetry.version>1.31.0</opentelemetry.version>
  </properties>

  <dependencies>
      <!-- springboot -->
      <dependency>
          <groupId>org.springframework.boot</groupId>
          <artifactId>spring-boot-starter-web</artifactId>
          <version>${org.springframework.boot.version}</version>
      </dependency>
      <dependency>
          <groupId>org.springframework.boot</groupId>
          <artifactId>spring-boot-starter-actuator</artifactId>
          <version>${org.springframework.boot.version}</version>
      </dependency>
      <dependency>
          <groupId>org.springframework.boot</groupId>
          <artifactId>spring-boot-starter-aop</artifactId>
          <version>${org.springframework.boot.version}</version>
      </dependency>


      <!-- opentelemetry -->
      <dependency>
          <groupId>io.opentelemetry</groupId>
          <artifactId>opentelemetry-api</artifactId>
          <version>${opentelemetry.version}</version>
      </dependency>
      <dependency>
          <groupId>io.opentelemetry</groupId>
          <artifactId>opentelemetry-sdk</artifactId>
          <version>${opentelemetry.version}</version>
      </dependency>

      <dependency>
          <groupId>io.opentelemetry</groupId>
          <artifactId>opentelemetry-exporter-otlp</artifactId>
          <version>${opentelemetry.version}</version>
      </dependency>
  </dependencies>

Inicializar el bean OpenTelemetry

Modifique el parámetro Endpoint en OtlpHttpMetricExporterBuilder y reemplácelo con la dirección de informes del indicador OpenTelemetry obtenida anteriormente para conectar los indicadores OpenTelemetry de la aplicación a la versión de monitoreo observable de Prometheus.

Para obtener más detalles, consulte la demostración de muestra: https://github.com/OuyangKevin/opentelemetry-metric-java-demo/blob/main/metric-http/README.md

 @Bean
  public OpenTelemetry openTelemetry() {
    String endpoint = httpMetricConfig.getOetlExporterOtlpEndpoint();//自己修改
    Resource resource = Resource.getDefault().toBuilder()
                       .put("service.name", "opentelemetry-metric-demo-http")
                       .put("service.version", "0.0.1").build();

    SdkMeterProvider defaultSdkMeterProvider = SdkMeterProvider.builder()
            .registerMetricReader(PeriodicMetricReader.builder(
                    OtlpHttpMetricExporter.builder()
                            .setEndpoint(endpoint)
                            .build())
                    .setInterval(15, TimeUnit.SECONDS).build())
            .setResource(resource)
            .build();


    OpenTelemetry openTelemetry = OpenTelemetrySdk.builder()
            .setMeterProvider(defaultSdkMeterProvider)
            .buildAndRegisterGlobal();
    return openTelemetry;
  }

Al inicializar el bean OpenTelemetry, puede establecer parámetros detallados para el cliente informado. Las instrucciones de configuración específicas son las siguientes:

1) Los clientes relacionados con OpenTelemetry no habilitan la compresión de forma predeterminada. Se recomienda configurar el parámetro Compresión en gzip para reducir el consumo de transmisión de la red.

OtlpHttpMetricExporter.builder()
 .setEndpoint("******")
 .setCompression("gzip")
 .build()

2) Después de que los indicadores de OpenTelemetry se informen a la versión de monitoreo observable de Prometheus, si necesita agregar un prefijo a todos los indicadores, puede configurar el encabezado "metricNamespace" como se muestra a continuación. Configure el metricNamespace en ot, y todos los indicadores informados tendrán un prefijo con "ot_" .

OtlpHttpMetricExporter.builder()
  .setEndpoint("******")
  .setCompression("gzip")
  .addHeader("metricNamespace","ot")
   .build()

3) Después de que los indicadores de OpenTelemetry se informen a la versión de monitoreo observable de Prometheus, todos los indicadores traerán etiquetas de alcance de OpenTelemetry de forma predeterminada. Si no desea agregar las etiquetas de alcance predeterminadas, puede configurar el encabezado skipGlobalLabel=true, como se muestra a continuación.

OtlpHttpMetricExporter.builder()
  .setEndpoint("******")
  .setCompression("gzip")
  .addHeader("skipGlobalLabel","true")
  .build()

Definir indicadores de negocio. El siguiente ejemplo configura un LongCounter y un LongHistogram.

@RestController
public class MetricController {

    @Autowired
    private OpenTelemetry openTelemetry;

    @GetMapping("/ping")
    public String ping(){
         long startTime = System.currentTimeMillis();
         Meter meter = openTelemetry.getMeter("io_opentelemetry_metric_ping");

         LongCounter longCounter = meter.counterBuilder("ping_long_counter")
                 .setDescription("ot http demo long_counter")
                 .setUnit("ms")
                 .build();

         LongHistogram longHistogram= meter.histogramBuilder("ping_long_histogram")
             .ofLongs()
             .setDescription("ot http demo histogram")
             .setUnit("ms")
             .build();

         try{
             longCounter.add(1,Attributes.of(AttributeKey.stringKey("regionId"),"cn-hangzhou"));
             TimeUnit.MILLISECONDS.sleep(new Random().nextInt(10));
         }catch (Throwable e){

         }finally {
             longHistogram.record(System.currentTimeMillis() - startTime);
         }
         return "ping success!";
    }
}

La relación de mapeo entre el modelo de indicador OpenTelemetry y la conversión del modelo de indicador de versión Prometheus de monitoreo observable de Alibaba Cloud es la siguiente. Dado que Prometheus admite el histograma delta, es necesario convertirlo en histograma acumulativo, por lo que la versión de Prometheus de monitoreo observable no admite actualmente la conversión del histograma delta de OpenTelemetry. Se recomienda utilizar el histograma acumulativo de OpenTelemetry en este escenario.

4.4 Ver datos de monitoreo en Grafana

Inicie sesión en la consola de visualización observable de la versión Grafana [15] .
Haga clic en Grafana Shared Edition en la página de administración del espacio de trabajo , luego seleccione la dirección de red pública correspondiente y haga clic en Iniciar sesión .
Haga clic en el icono en la barra de navegación izquierda y luego seleccione la fuente de datos correspondiente en el lado derecho de Explorar.

4. Configure sus propios paneles y alarmas: El siguiente es el panel configurado por los clientes mediante indicadores de OpenTelemetry.

05 Monitoreo observable de Alibaba Cloud versión Prometheus VS Prometheus de código abierto

La versión Prometheus de Alibaba Cloud Observable Monitoring está completamente integrada con el ecosistema de código abierto Prometheus, admite una amplia gama de monitoreo de componentes y cubre la mayoría de las capacidades de recopilación de indicadores del software de infraestructura de código abierto. Proporciona una variedad de paneles de monitoreo preestablecidos listos para usar, integra paneles de control preestablecidos de servicios comunes y monitoreo básico de Kubernetes enriquecidos, y proporciona servicios Prometheus totalmente administrados. Las ventajas de la versión Prometheus de monitoreo observable de Alibaba Cloud se pueden resumir en "lista para usar", "bajo costo", "compatibilidad de código abierto", "tamaño de datos ilimitado", "alto rendimiento" y "alta disponibilidad".

06 Facturación de productos

Actualmente, la versión de monitoreo observable de Prometheus ha lanzado un nuevo modelo de facturación basado en el volumen de datos escritos y proporciona una cuota gratuita de 50 GB por mes. Se informan 10 millones de indicadores diariamente y los datos de los indicadores se almacenan durante 90 días por sólo 37 yuanes. Haga clic para leer el artículo original para conocer más detalles del producto.