chore: add translations

src/i18n/content/es/docs/more-integrations/open-source-telemetry-integrations/opentelemetry/get-started/cumulative-metrics-transition-guide.mdx

@@ -0,0 +1,186 @@
+---
+title: Guía de transición para OpenTelemetry suma métrica acumulativa
+metaDescription: 'A transition guide about a change in how New Relic handles OpenTelemetry cumulative sum metrics, and how to update your queries and alerts for that change.'
+freshnessValidatedDate: never
+translationType: machine
+---
+
+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](/docs/data-apis/understand-data/metric-data/cumulative-metrics). Como parte de esta actualización, estamos realizando la transición del [tipo de datos de métrica](/docs/data-apis/understand-data/metric-data/metric-data-type/#metric-types) subyacente para [sumas acumulativas monótonas](https://opentelemetry.io/docs/reference/specification/metrics/data-model/#sums) 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` .
+
+    <DoNotTranslate>**Early opt-in is the best way to ensure affected queries and alerts are not disrupted by the EoL**</DoNotTranslate>
+
+    .
+
+* 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 <InlinePopover type="alerts"/>que 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
+
+<Callout variant="important">
+  Las sumas acumuladas que no sean monótonas **no** se verán afectadas.
+</Callout>
+
+## Comprobar el impacto [#impact]
+
+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 [#what-to-do]
+
+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](/docs/more-integrations/open-source-telemetry-integrations/opentelemetry/best-practices/opentelemetry-best-practices-metrics#query) 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](/docs/alerts-applied-intelligence/new-relic-alerts/alert-conditions/create-nrql-alert-conditions), 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 [#alerts]
+
+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 [#cumulative-queries]
+
+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 [#rate-of-change-queries]
+
+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 [#preview]
+
+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
+```
+
+<Callout variant="important">
+  Cuando comience a enviar `newrelic_metric_type=cumulativeCount` en sus datos, cualquier suma monótona acumulativa que recibamos se traducirá a `cumulativeCount` tipos. Esto significa que cualquier consulta o alerta existente configurada para apuntar a un tipo `gauge` recibirá resultados inesperados. Tenga esto en cuenta cuando pruebe la experiencia `cumulativeCount` . Para volver al tipo `gauge` , simplemente deje de configurar el atributo `newrelic_metric_type` .
+</Callout>
+
+### Biblioteca de instrumentación [#instrumentation-library]
+
+Si está utilizando una biblioteca de instrumentación OTLP dentro de su base de código, debe hacer referencia al [SDK del lenguaje apropiado](/docs/more-integrations/open-source-telemetry-integrations/opentelemetry/get-started/opentelemetry-set-up-your-app/#instrument) 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 [#collector]
+
+Si la fuente de su monitoreo OTLP proviene del recolector OTLP, puede usar el [procesador de atributos](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/attributesprocessor/README.md) 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 [#checking-results]
+
+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
+```

src/i18n/content/es/docs/network-performance-monitoring/troubleshooting/snmp-polling-missing-metrics.mdx

@@ -78,6 +78,13 @@ Esta consulta le dará una lista de todas las dimensiones métricas recopiladas
     La biblioteca de perfiles SNMP se actualiza constantemente y, a veces, la imagen del contenedor que estás utilizando no tiene la configuración de perfil que estás buscando. Si `mib_profile` no coincide con el perfil esperado, puede actualizar manualmente su archivo de configuración o ejecutar un nuevo descubrimiento.
 
     Siempre debe obtener la imagen más reciente para su contenedor antes de realizar cambios ejecutando `docker pull kentik/ktranslate:v2`.
+
+    Alternativamente, puedes obtener la última versión a través de apt-get:
+
+    ```shell
+    curl -s https://packagecloud.io/install/repositories/kentik/ktranslate/script.deb.sh | sudo bash && \
+    sudo apt-get install ktranslate
+    ```
   </Collapser>
 
   <Collapser