Guía de transición para OpenTelemetry suma métrica acumulativa

año constante de exportación = 2023; export const gaDate = '4 de abril'; export const eolDate = '22 de octubre'; exportar const gaDateAndYear = gaDate + ', ' + año; export const eolDateAndYear = eolDate + ', ' + año;

Nuestra cartera de OTLP métrica se está actualizando para respaldar mejor la forma en que manejamos la métrica acumulativa. Como parte de esta actualización, estamos realizando la transición del tipo de datos de métrica subyacente para sumas acumulativas monótonas de un tipo gauge al tipo cumulativeCount . El tipo cumulativeCount le permite consultar tanto el valor acumulado como el delta asociado con los datos reportados.

A partir de gaDateAndYear, ingeriremos métrica monótona acumulativa de acuerdo con el siguiente cronograma de fin de vida útil (EoL):

• gaDateAndYear:

  • Se publica la ingesta de sumas monótonas acumulativas como tipo de métrica cumulativeCount (las sumas acumulativas no monótonas no se ven afectadas). La experiencia anterior de ingestar estas métricas como del tipo gauge métrica está obsoleta.
  • Las cuentas que enviaban activamente sumas monótonas acumuladas antes de esta fecha pueden seguir usando la ingesta de tipo gauge .
  • Todas las demás cuentas tendrán sumas monótonas acumulativas ingeridas como cumulativeCount tipos métricos.

• gaDate a través de eolDate:

  • Las cuentas que utilizan la ingesta de tipo gauge obsoleta pueden optar por la ingesta de tipo cumulativeCount .

    Early opt-in is the best way to ensure affected queries and alerts are not disrupted by the EoL

    .

• eolDateAndYear: todas las cuentas se migrarán al tipo de ingesta cumulativeCount para sumas monótonas acumulativas.

Si estaba ingiriendo sumas monótonas acumuladas antes de gaDate, este período de 180 días le da tiempo para actualizar la consulta y alertasque utilizan la métrica afectada.

Las siguientes secciones le enseñarán:

• Cómo saber si estás afectado
• Cómo prepararse para el EoL
• Cómo suscribirse a la funcionalidad cumulativeCount antes de la fecha EoL

Comprobar el impacto

Si su cuenta enviaba suma métrica acumulada de OTLP a New Relic antes de gaDateAndYear, entonces se verá afectado por el EoL en eolDateAndYear.

Para ver si se ha visto afectado, ejecute la siguiente consulta NRQL para la cuenta correspondiente:

FROM NrIntegrationError SELECT count(*)
WHERE newRelicFeature = 'cumulativeSumAsGaugeEoL'
SINCE 24 hours ago

La consulta arrojará resultados si ha informado métricas afectadas por este EoL en las últimas 24 horas.

Para investigar más, puedes ver el mensaje del evento para ver qué métricas están afectadas:

FROM NrIntegrationError SELECT uniques(metricName)
WHERE newRelicFeature = 'cumulativeSumAsGaugeEoL'
LIMIT MAX SINCE 24 hours ago

Cualquier seguimiento o alerta que involucre estas métricas deberá revisarse y actualizarse antes de la fecha EoL. La siguiente sección contiene acciones sugeridas para métricas impactadas.

Qué hacer si estás afectado

En eolDate, los informes de métricas de suma acumulativa monótonas de OTLP pasarán del tipo gauge al cumulativeCount tipo métrica. Si estás usando esas métricas, querrás prepararte para eso. Por ejemplo, es posible que quieras crear una condición de alerta duplicada con el nuevo tipo de métrica para que, cuando ocurra el cambio, no tengas ninguna interrupción (y explicamos cómo hacerlo a continuación).

Nuestras mejores prácticas de OpenTelemetry describen las diferencias en las consultas entre un tipo de métrica gauge y cumulativeCount . Es decir, podrá apuntar al valor delta (de forma predeterminada) o al valor acumulativo seleccionando el campo acumulativo.

Tomemos una consulta de ejemplo de una métrica de suma monótona acumulativa metricName. Hasta el EoL, una consulta como:

FROM Metric SELECT latest(<metricName>)

estaría evaluando solo gauge métrica. Una vez que ocurre el EoL, el tipo de métrica subyacente asociado con metricName cambiará a cumulativeCount. Dependiendo de la alerta, este cambio podría provocar resultados falsos, ya que el valor de métrica para un tipo gauge y cumulativeCount representa valores diferentes del punto de datos.

A continuación nos centramos en actualizar la condición de alerta, porque las alertas son generalmente más importantes que los gráficos. Para sus gráficos personalizados, puede:

• Adopte el mismo enfoque general que describimos para alerta (cree un nuevo gráfico con una consulta actualizada y borre el gráfico anterior después del EoL), O
• Espere hasta después del EoL y actualice los gráficos.

Acción sugerida: crear nuevas versiones de alerta

A continuación se muestran algunos ejemplos de consulta que podrían usarse en condición de alerta. Le daremos la consulta original, luego una versión gauge de la consulta y una versión cumulativeCount de la consulta. Debe reemplazar su alerta existente con la versión gauge de la consulta y crear una condición de alerta duplicada que utilice la versión cumulativeCount . De esa manera, cuando hagamos la transición de su cuenta a cumulativeCount en eolDate, esa condición de alerta estará disponible cuando la consulta anterior ya no funcione.

Consulta acumulativa

Consulta original:

FROM Metric SELECT latest(<metricName>)

Versión medidor de la consulta:

FROM Metric SELECT latest(<metricName>)
WHERE <metricName>[type] = 'gauge'

Versión de recuento acumulativo de la consulta:

FROM Metric SELECT latest(<metricName>[cumulative])
WHERE <metricName>[type] = 'cumulativeCount'

Consulta de tasa de cambio

Consulta original:

FROM Metric SELECT derivative(<metricName>, 1 minute)

Versión del medidor de la consulta:

FROM Metric SELECT derivative(<metricName>, 1 minute)
WHERE <metricName>[type] = 'gauge'

Versión de recuento acumulativo de la consulta:

FROM Metric SELECT rate(sum(<metricName>[cumulative]), 1 minute)
WHERE <metricName>[type] = 'cumulativeCount'

Acción sugerida: vista previa del recuento acumulativo antes del EoL

Las sumas acumuladas de las cuentas afectadas seguirán almacenadas como tipos gauge hasta el EoL. Sin embargo, opcionalmente, puede probar cumulativeCount antes del EoL para validar que su consulta y alerta se estén comportando como se esperaba. Para probar cumuativeCount tipos con antelación, agregue el siguiente atributo a los datos OTLP que envíe a New Relic:

newrelic_metric_type=cumulativeCount

Biblioteca de instrumentación

Si está empleando una biblioteca de instrumentación OTLP dentro de su base de código, debe hacer referencia al SDK de idioma apropiado para su aplicación. Cualquier método para agregar el atributo newrelic_metric_type=cumulativeCount a puntos de datos métricos individuales o al nivel de atributo del recurso debería ser suficiente.

A continuación se muestra un ejemplo de cómo agregar el atributo directamente a la métrica de informes en el SDK de Java:

final var meter = openTelemetry.meterBuilder("manual-instrumentation-scope")
                .setInstrumentationVersion("1.0.0")
                .build();
final LongCounter counter = meter.counterBuilder("myCumulativeCounter")
                .build();
counter.add(1, Attributes.of(stringKey("newrelic_metric_type"), "cumulativeCount"));

Recolector

Si la fuente de su monitoreo OTLP proviene del recolector OTLP, puede usar el procesador de atributos OpenTelemetry para agregar el atributo antes de enviarlo a sus exportadores. Por ejemplo, el siguiente fragmento insertará el atributo newrelic_metric_type=cumulativeCount :

…
attributes:
  actions:
    - key: newrelic_metric_type
      action: insert
      value: cumulativeCount
…
service:
  pipelines:
    metrics:
      …
      processors: [...,attributes,...]
      …

Comprobando resultados

Después de configurar newrelic_metric_type=cumulativeCount en sus datos de métrica, puede verificar que los recibamos correctamente con esta consulta:

FROM Metric SELECT count(*) WHERE %[type] = 'cumulativeCount' TIMESERIES