Optimice su ingesta de datos

Una cuenta está ingiriendo aproximadamente un 20% más de lo que tenía presupuestado. Un gerente les pidió que encuentren alguna forma de reducir el consumo. Su factor de valor más importante es el tiempo de actividad, el rendimiento y la confiabilidad.

Su patrimonio incluye:

• APM(dev, de prueba, prod)

• rastreo distribuido

• Browser

• Monitoreo de infraestructura de 100 hosts

• Monitoreo K8s (dev, de prueba, prod)

• Log (dev, de prueba, prod - incluyendo depuración)

  Plan de optimización

  • Omitir el log de depuración (sabiendo que se pueden activar si hay un problema) (ahorra un 5%)
  • Omitir varios K8 de estado métrico que no son necesarios para mostrar el explorador del clúster de Kubernetes (ahorra un 10%)
  • Suelte algún evento browser personalizado que estaban recopilando cuando hacían muchas pruebas A/B de una nueva característica (ahorra 10%)

  Después de ejecutar esos cambios, el equipo está un 5 % por debajo de su presupuesto y ha liberado algo de espacio para realizar un piloto de NPM. Su gerente está satisfecho de que no están perdiendo ningún tiempo de actividad significativo ni observabilidad de confiabilidad.

  Resultado final

  • 5% por debajo de su presupuesto original
  • Espacio libre creado para un piloto de NPM que cumple objetivos de tiempo de actividad, rendimiento y confiabilidad
  • Pérdida mínima de tiempo de actividad y observabilidad de confiabilidad

Un equipo responsable de una nueva plataforma orientada al usuario con énfasis en monitoreo de celulares y monitoreo de browser está funcionando con un 50% por encima de la cotización. Tendrán que ajustar el tamaño de su ingesta, pero están decididos a no sacrificar la observabilidad de la experiencia del cliente .

Su patrimonio incluye:

• Móvil

• Browser

• APM

• rastreo distribuido

• Infraestructura en 30 hosts, incluyendo muestras de procesos

• Monitoreo sin servidor para algunos procesos asincrónicos backend

• Logs desde su función serverless

• Varias integraciones en la nube.

  Plan de optimización

  • Omita el log sin servidor (básicamente son redundantes con respecto a lo que obtienen de su integración Lambda)
  • Reducir la frecuencia de muestreo del proceso en sus hosts a cada minuto.
  • Eliminar datos de muestra de procesos en entornos DEV
  • Desactive la integración de EC2, que es altamente redundante con otros monitoreos de infraestructura proporcionados por el agente de infraestructura New Relic.

  Resultado final

  • 5% sobre su presupuesto original
  • Suficiente para pasar la temporada alta.
  • Observabilidad de la experiencia sin pérdida de clientes

  Después de ejecutar los cambios, ahora están solo un 5% por encima de su presupuesto original, pero concluyen que esto será suficiente para aguantar la temporada alta.

Un equipo está en el proceso de refactorizar un gran monolito de Python en cuatro microservicios. El monolito comparte gran parte de la infraestructura con la nueva arquitectura, incluida una base de datos de clientes y una capa de caché. Están un 70% por encima del presupuesto y les quedan dos meses antes de poder desmantelar oficialmente el monolito.

Su patrimonio incluye:

• Monitoreo K8s (microservicios)

• Monitoreo del host New Relic (monolito)

• APM (microservicios y monitoreo de host)

• Rastreo distribuido (microservicios y monitorización de host)

• Postgresql (compartido)

• Redis (compartido)

• MSSQL (futura base de datos para la arquitectura de microservicios)

• Logging del balanceador de carga (microservicios y monitoreo de host)

  Plan de optimización

  • Configure el logging del balanceador de carga para monitor solo los códigos de respuesta 5xx (monolito)
  • Frecuencia de muestreo personalizada en ProcessSample, StorageSample y NetworkSample a 60 s para los hosts que ejecutan el monolito
  • Deshabilite el monitoreo de MSSQL ya que actualmente la nueva arquitectura no lo utiliza.
  • Deshabilite rastreo distribuido para el monolito ya que es mucho menos útil que para la arquitectura de microservicios.

  Resultado final

  • 1% por debajo de su presupuesto original
  • Sin pérdida de innovación y observabilidad del crecimiento

El volumen de datos generado por el agente APM vendrá determinado por varios factores:

• La cantidad de tráfico orgánico generado por la aplicación (por ejemplo, en igualdad de condiciones, una aplicación que se llama un millón de veces al día generará más datos que una que se llama mil veces al día)

• Algunas de las características de los datos de la transacción subyacentes (longitud y complejidad de las URL)

• Si la solicitud informa consulta de la base de datos

• Si la aplicación tiene transacción con muchos (o cualquier) atributo personalizado

• El volumen de errores de la aplicación.

• Si el agente de aplicación está configurado para rastreo distribuido

  Gestionar el volumen

  Si bien puede suponer que todas las llamadas a una aplicación son necesarias para respaldar el negocio, es posible que pueda ser más ahorrativo en su arquitectura general. En un caso extremo puede tener un perfil de usuario de microservicios al que llaman cada 10 segundos sus clientes. Esto ayuda a reducir la latencia si otros clientes actualizan alguna información del usuario. Sin embargo, una palanca que tenemos es reducir la frecuencia de las llamadas a este servicio a, por ejemplo, cada minuto.

  Atributo personalizado

  Cualquier atributo personalizado agregado mediante una llamada a una API de APM addCustomParameter agregará un atributo adicional a la carga útil de la transacción. Suelen ser útiles, pero a medida que la lógica de la aplicación y las prioridades cambian, los datos pueden volverse menos valiosos o incluso obsoletos.

  El agente de Java captura el siguiente request.headers de forma predeterminada:

• request.headers.referer

• request.headers.accept

• request.headers.contentLength

• request.headers.host

• request.headers.userAgent

  Los desarrolladores también pueden utilizar addCustomParameter para capturar información adicional (encabezados potencialmente más detallados).

  Para ver un ejemplo de la configuración enriquecida que está disponible en relación con APM, consulte nuestra documentación de agente de Java.

  Evento de error

  Es posible determinar cómo APM manejará los errores. Esto puede reducir el volumen de datos en algunos casos. Por ejemplo, puede haber un error de gran volumen pero inofensivo que no se puede eliminar en este momento.

  Tenemos la capacidad de collect, ignore o mark as expected. Para obtener más información, consulte Administrar errores de APM.

  Consulta de la base de datos

  Un aspecto muy variable de la instancia de APM es la cantidad de llamadas a la base de datos y la configuración que hemos establecido. Tenemos bastante control sobre cuán detallada es la monitorización de la consulta de la base de datos. Estas consultas aparecerán en la página de traza de la transacción.

  Los cambios comunes en la configuración de la consulta de la base de datos incluyen:

• Recopilar datos de consultas sin procesar en lugar de ofuscarlos o desactivar la recopilación de consultas

• Cambiando el umbral del rastreo del stack

• Activar consulta para explicar la recopilación del plan

  Para obtener más detalles, consulte la página de traza de la transacción consulta de la base de datos.

  Establecer límites de eventos

  Nuestro APM y nuestro agente móvil tienen límites sobre cuántos eventos se pueden informar por ciclo de recolección. Si no hubiera límite, una gran cantidad de eventos enviados podrían afectar el rendimiento de su aplicación o de New Relic. Cuando se alcanza el límite, el agente comienza a muestrear el evento para dar una muestra representativa de evento a lo largo del ciclo de recolección. Diferentes agentes tienen diferentes límites.

  Los eventos que están limitados y sujetos a muestreo incluyen:

• Evento personalizado reportado a través de la API del agente (por ejemplo, el RecordCustomEvent del agente .NET)

• Mobile

• MobileCrash

• MobileHandledException

• MobileRequest

• Span (ver muestreo rastreo distribuido)

• Transaction

• TransactionError

  La mayoría de los agentes tienen opciones de configuración para cambiar el límite de eventos en la transacción muestreada. Por ejemplo, el agente de Java usa max_samples_stored. El valor predeterminado para max_samples_stored es 2000 y el máximo es 10000. Este valor rige cuántos eventos muestreados se pueden informar cada 60 segundos desde una instancia de agente.

  Para obtener una explicación completa de los límites de muestreo de eventos, consulte límites de eventos.

  Puede compensar el evento muestreado mediante el operador NRQLEXTRAPOLATE .

  Antes de intentar cambiar la forma en que se realiza el muestreo, lea estas advertencias y recomendaciones:

• Cuanto más eventos reportes, más memoria utilizará tu agente.

• Por lo general, puede obtener los datos que necesita sin aumentar el límite de informes de eventos de un agente.

• El límite de tamaño de carga útil es 1 MB (10^6 bytes) (comprimido), por lo que el número de eventos aún puede verse afectado por ese límite. Para determinar si el evento se está eliminando, consulte el log del agente para ver un mensaje de estado 413 HTTP.

  Tasa de muestreo log

  Las versiones más recientes del agente de lenguaje New Relic APM pueden reenviar el log directamente a New Relic. En algunos casos, es posible que desee controlar algunos límites de cuán grandes pueden ser los picos de logging de cada instancia del agente APM.

  Para obtener detalles sobre el muestreo de logs del agente APM, consulte reenviador de logs.

  Traza de la transaccion

  Controladores de crecimiento

  • Número de servicios conectados
  • Número de llamadas al método de monitoreo por servicios conectados

  En APM, la traza de la transacción registra detalles detallados sobre la transacción de su aplicación y las llamadas a la base de datos. Puede editar la configuración predeterminada para la traza de la transacción.

  Esto también es altamente configurable a través de transacción trade configuración. El nivel y el modo de configurabilidad serán específicos del idioma en muchos casos.

  Las configuraciones de traza de la transacción disponibles usando la configuración del lado del servidor diferirán según el agente de New Relic que utilice. La UI incluye descripciones de cada uno. Las configuraciones en la UI pueden incluir:

• Seguimiento y umbral de transacciones.

• Grabar SQL, incluido el nivel de grabación y los campos de entrada

• Log SQL y rastreo del umbral de pila

• Planes de consulta SQL y umbral

• Colección de errores, incluido el código HTTP y la clase de error

• Consulta lenta rastreo

• Hilo generador de perfiles

  rastreo distribuido

  La configuración de rastreo distribuido tiene algunas diferencias específicas del idioma.

  Rastreo distribuido se puede desactivar según sea necesario. Este es un ejemplo para el agente de Java newrelic.yml:

  distributed_tracing:
      enabled: false

  Copia

  Este es un ejemplo de node.js para newrelic.js

  distributed_tracing: {
    enabled: false
  }

  Copia

  El volumen de datos también variará según si está utilizando Infinite Tracing.

  El rastreo distribuido estándar para el agente APM (arriba) captura hasta el 10% de su traza, pero si desea que analicemos todos sus datos y encontremos la traza más relevante, puede configurar Infinite Tracing. Esta alternativa al rastreo distribuido estándar está disponible para todos los agentes de lenguaje APM.

  Los principales parámetros que podrían impulsar un pequeño aumento en la ingesta mensual son:

• Configurar monitoreo de observador de trazas

• Configurar filtro de traza de atributo span

• Configurar filtro de traza aleatorio

Para la versión 1211 o superior del agente del navegador , todas las solicitudes de red realizadas por una página se registran como AjaxRequest evento. Puede utilizar las opciones de configuración de la lista de denegación en la página de configuración UI de la aplicación para filtrar qué eventos de registro de solicitudes. Independientemente de este filtro, todas las solicitudes de red se capturan como métricas y están disponibles en la página AJAX.

Usando la lista de denegación

Las solicitudes se pueden bloquear de tres formas:

• Para bloquear la grabación de todos los eventos AjaxRequest , agregue un asterisco * como comodín.

• Para bloquear la grabación del evento AjaxRequest en un dominio, ingrese solo el nombre del dominio. Ejemplo: example.com

• Para bloquear la grabación del evento AjaxRequest en un dominio y ruta específicos, ingrese el dominio y la ruta. Ejemplo: example.com/path

• La lista de denegación ignora el protocolo, el puerto, la búsqueda y el hash de una URL.

  Para validar si los filtros que ha agregado funcionan como se esperaba, ejecute una consulta NRQL para AjaxRequest evento que coincida con su filtro.

  Accediendo a la lista de denegados

  Para actualizar la lista de URL denegadas que su aplicación filtrará para la creación de eventos, vaya a la página de configuración UI de la aplicación:

1. Vaya a one.newrelic.com, y haga clic en Browser.

2. Seleccione una aplicación.

3. En la navegación izquierda, haga clic en App settings [Configuración de la aplicación].

4. En Ajax request deny list [la lista de solicitudes rechazadas de Ajax], agregue los filtros que desea aplicar.

5. Seleccione Save application settings [Almacenar configuración de la aplicación] para actualizar la configuración del agente.

6. Vuelva a implementar el agente del navegador (ya sea reiniciando el agente APM asociado o actualizando la instalación de copiar y pegar browser ).

   Validando

   FROM AjaxRequest SELECT * WHERE requestUrl LIKE `%example.com%`

   Copia

Android

Todas las configuraciones, incluida la llamada para invocar al agente, se llaman en el método onCreate de la clase MainActivity . Para cambiar la configuración, llame a la configuración de una de dos maneras (si la configuración lo admite):

NewRelic.disableFeature(FeatureFlag.DefaultInteractions);
NewRelic.enableFeature(FeatureFlag.CrashReporting);
NewRelic.withApplicationToken(NEW_RELIC_TOKEN).start(this.getApplication());

La configuración de análisis habilita o deshabilita la recopilación de datos de eventos. Estos eventos se informan a New Relic y se emplean en la página de Crash analysis .

También es posible configurar el logging del agente para que sea más o menos detallado.

iOS

Al igual que ocurre con Android, la configuración de iOS de New Relic permite habilitar y deshabilitar banderas de características.

Se pueden configurar los siguientes indicadores de características:

Informes de fallos y errores

• NRFeatureFlag_CrashReporting
• NRFeatureFlag_HandleExceptionEvents
• NRFeatureFlag_CrashReporting

rastreo distribuido

• NRFeatureFlag_DistributedTracing

Interacción

• NRFeatureFlag_DefaultInteractions
• NRFeatureFlag_InteractionTracing
• NRFeatureFlag_SwiftInteractionTracing

Banderas características de red

• NRFeatureFlag_ExperimentalNetworkInstrumentation
• NRFeatureFlag_NSURLSessionInstrumentation
• NRFeatureFlag_NetworkRequestEvents
• NRFeatureFlag_RequestErrorEvents
• NRFeatureFlag_HttpResponseBodyCapture

Para obtener más detalles, consulte banderas de características.

El archivo de configuración del agente de infraestructura de New Relic contiene un par de formas poderosas de controlar el volumen de ingesta. El control de ingesta más importante es la configuración de las tasas de muestreo. Hay varias configuraciones de frecuencia de muestreo distintas que se pueden ajustar. Además, es posible crear expresiones regulares para controlar lo que se recopila de determinados recopiladores, como ProcessSample y NetworkSample.

Tasas de muestreo configurables

Hay varias frecuencias de muestreo que se pueden configurar en la infraestructura, pero estas son las más utilizadas.

| parámetro | Predeterminado | Desactivar | | --------------------------- | ------- | ------- | | metrics_storage_sample_rate | 5 | -1 | | metrics_process_sample_rate | 20 | -1 | | metrics_network_sample_rate | 10 | -1 | | metrics_system_sample_rate | 5 | -1 | | metrics_nfs_sample_rate | 5 | -1 |

Muestras de proceso

Las muestras de procesos pueden ser la fuente de datos de mayor volumen del agente de infraestructura. Esto se debe a que enviará información sobre cualquier proceso en ejecución en un host. Están deshabilitados de forma predeterminada, pero se pueden habilitar de la siguiente manera:

enable_process_metrics: true

Esto tiene el mismo efecto que configurar metrics_process_sample_rate en -1.

De forma predeterminada, los procesos que utilizan poca memoria están excluidos del muestreo. Para obtener más información, consulte disable-zero-mem-process-filter.

Puedes controlar la cantidad de datos que se envían a New Relic configurando include_matching_metrics, lo que te permite restringir la transmisión de datos métricos en función de los valores del atributo métrico.

Puedes incluir datos métricos definiendo valores literales o parciales para cualquiera de los atributos de la métrica. Por ejemplo, puede optar por enviar el host.process.cpuPercent de todos los procesos cuyo process.name coincida con la expresión regular ^java .

En este ejemplo, incluimos el proceso métrica usando archivos ejecutables y nombres:

include_matching_metrics:             # You can combine attributes from different metrics
    process.name:
      - regex "^java"                   # Include all processes starting with "java"
    process.executable:
      - "/usr/bin/python2"              # Include the Python 2.x executable
      - regex "\\System32\\svchost"     # Include all svchost executables

También puedes utilizar este filtro para la integración de Kubernetes:

env:
    - name: NRIA_INCLUDE_MATCHING_METRICS
      value: |
        process.name:
          - regex "^java"
        process.executable:
          - "/usr/bin/python2"
          - regex "\\System32\\svchost"

Hay un exclude_matching_metrics disponible que funciona de manera similar para excluir datos métricos.

Filtro de interfaz de red

La configuración utiliza un mecanismo simple de coincidencia de patrones que puede buscar interfaces que comiencen con una secuencia específica de letras o números siguiendo cualquiera de los patrones:

• {name}[other characters]
• [number]{name}[other characters], donde especificas el nombre usando la opción index-1

network_interface_filters:
  prefix:
    - dummy
    - lo
  index-1:
    - tun

Filtros de interfaz de red predeterminados para Linux:

• Interfaces de red que comienzan con dummy, lo, vmnet, sit, tun, tap o veth
• Interfaces de red que contienen tun o tap

Filtros de interfaz de red predeterminados para Windows:

• Interfaces de red que comienzan con Loop, isatap o Local

Para anular los valores predeterminados, incluya su propio filtro en el archivo de configuración:

network_interface_filters:
  prefix:
    - dummy
    - lo
  index-1:
    - tun

Atributo personalizado

Los atributos personalizados son pares de valores principales (similares a la etiqueta en otras herramientas) empleados para anotar los datos del agente de infraestructura. Puede emplear estos metadatos para crear conjuntos de filtros, agrupar sus resultados y anotar sus datos. Por ejemplo, puede indicar el entorno de una máquina (de prueba o de producción), el servicio que aloja una máquina (servicio de inicio de sesión, por ejemplo) o el equipo responsable de esa máquina.

Ejemplo de atributo personalizado de newrelic.yml

custom_attributes:
  environment: production
  service: billing
  team: alpha-team

Son potentes y útiles, pero si los datos no están bien organizados o se han vuelto obsoletos de alguna manera, debería considerar optimizarlos.

No sorprende que un sistema complejo y descentralizado como Kubernetes tenga el potencial de generar mucha telemetría rápidamente. Existen algunos buenos enfoques para gestionar la ingesta de datos en Kubernetes. Estos serán muy sencillos si utilizas la observabilidad como código en el despliegue de tu K8. Le recomendamos encarecidamente que instale este dashboard de análisis de ingesta de datos de Kubernetes antes de tomar cualquier decisión sobre la reducción de la ingesta de K8. Para obtener este dashboard, consulte el inicio rápido de integración de infraestructura.

Intervalo de raspado

Dependiendo de sus objetivos de observabilidad, puede considerar ajustar el intervalo de raspado. El valor predeterminado es 15 segundos. Ahora el explorador del clúster de Kubernetes solo se actualiza cada 45 segundos. Si su uso principal de los datos de K8 es respaldar las visualizaciones de KCE, puede considerar cambiar su intervalo de raspado a 20 segundos. Ese cambio de 15 a 20 años puede tener un impacto sustancial. Para obtener más detalles sobre cómo administrar esto, consulte nuestros documentos sobre el intervalo de raspado de integración de Helm.

Filtrado de espacio de nombres

La integración de Kubernetes v3 y superior permite filtrar qué espacios de nombres se eliminan etiquetándolos. De forma predeterminada, se eliminan todos los espacios de nombres.

Usamos namespaceSelector de la misma manera que lo hace Kubernetes. Para incluir solo el espacio de nombres que coincida con una etiqueta, cambie el namespaceSelector agregando lo siguiente a su values-newrelic.yaml, en la sección newrelic-infrastructure :

common:
  config:
    namespaceSelector:
      matchLabels:
        key1 : "value1"

En este ejemplo, solo se eliminará el espacio de nombres con la etiqueta newrelic.com/scrape establecida en true :

global:
  licenseKey: _YOUR_NEW_RELIC_LICENSE_KEY_
  cluster: _K8S_CLUSTER_NAME_

# ... Other settings as shown above

# Configuration for newrelic-infrastructure
newrelic-infrastructure:
  # ... Other settings as shown above
  common:
    config:
      namespaceSelector:
        matchLabels:
          newrelic.com/scrape: "true"

También puede utilizar expresiones de coincidencia de Kubernetes para incluir o excluir espacios de nombres. Los operadores válidos son:

• En
• No en
• Existe
• No existe

La estructura general de la sección matchExpressions es una o más de las siguientes líneas:

{key: VALUE, operator: OPERATOR, values: LIST_OF_VALUES}

Aquí tienes un ejemplo completo:

common:
  config:
    namespaceSelector:
      matchExpressions:
      - {key: newrelic.com/scrape, operator: NotIn, values: ["false"]}

En este ejemplo, se excluirá el espacio de nombres con la etiqueta newrelic.com/scrape establecida en false :

global:
  licenseKey: _YOUR_NEW_RELIC_LICENSE_KEY_
  cluster: _K8S_CLUSTER_NAME_

# ... Other settings as shown above

# Configuration for newrelic-infrastructure
newrelic-infrastructure:
  # ... Other settings as shown above
  common:
    config:
      namespaceSelector:
        matchExpressions:
        - {key: newrelic.com/scrape, operator: NotIn, values: ["false"]}

Vea una lista completa de las configuraciones que se pueden modificar en el archivo README del gráfico.

¿Cómo puedo saber qué espacios de nombres están excluidos? [#excluded-namespaces]

Todo el espacio de nombres dentro del clúster se enumera gracias al ejemplo K8sNamespace . El atributo nrFiltered determina si los datos relacionados con el namespace se eliminarán.

Utilice esta consulta para saber qué espacio de nombres se está supervisando:

FROM K8sNamespaceSample SELECT displayName, nrFiltered
WHERE clusterName = INSERT_NAME_OF_CLUSTER SINCE
2 MINUTES AGO

¿Qué datos se descartan del espacio de nombres excluido? [#namespaces-discarded-data]

Los siguientes ejemplos no estarán disponibles para el espacio de nombres excluido:

• K8sContainerSample
• K8sDaemonsetSample
• K8sDeploymentSample
• K8sEndpointSample
• K8sHpaSample
• K8sPodSample
• K8sReplicasetSample
• K8sServiceSample
• K8sStatefulsetSample
• K8sVolumeSample

Estado de Kube métrica

El explorador del clúster de Kubernetes requiere únicamente el siguiente estado métrico de kube (KSM):

• Datos del contenedor
• Datos del clúster
• Datos de nodo
• Datos del pod
• Datos de volumen
• Datos del servidor API¹
• Datos del administrador del controlador¹
• Datos ETCD¹
• Datos del programador¹

¹ No recopilado en un entorno de Kubernetes administrado (EKS, GKE, AKS, etc.)

Puede considerar desactivar algunos de los siguientes:

• Datos del DaemonSet
• Desplegar datos
• Datos extremos
• Datos namespace
• Datos del conjunto de réplicas²
• Datos de servicio
• Datos de StatefulSet

² Usado en la alerta predeterminada: "ReplicaSet no tiene la cantidad deseada de pod"

Ejemplo de actualización de estado métrica en manifiesto (despliegue)

$
[spec]
$
  [template]
$
    [spec]
$
      [containers]
$
        [name=kube-state-metrics]
$
        [args]
$
        #- --collectors=daemonsets
$
        #- --collectors=deployments
$
        #- --collectors=endpoints
$
        #- --collectors=namespaces
$
        #- --collectors=replicasets
$
        #- --collectors=services
$
        #- --collectors=statefulsets

Ejemplo de actualización de estado métrica en manifiesto (ClusterRole)

$
[rules]
$
# - apiGroups: ["extensions", "apps"]
$
#   resources:
$
#   - daemonsets
$
#   verbs: ["list", "watch"]
$

$
# - apiGroups: ["extensions", "apps"]
$
#   resources:
$
#   - deployments
$
#   verbs: ["list", "watch"]
$

$
# - apiGroups: [""]
$
#   resources:
$
#   - endpoints
$
#   verbs: ["list", "watch"]
$

$
# - apiGroups: [""]
$
#   resources:
$
#   - namespaces
$
#   verbs: ["list", "watch"]
$

$
# - apiGroups: ["extensions", "apps"]
$
#   resources:
$
#   - replicasets
$
#   verbs: ["list", "watch"]
$

$
# - apiGroups: [""]
$
#   resources:
$
#   - services
$
#   verbs: ["list", "watch"]
$

$
# - apiGroups: ["apps"]
$
#   resources:
$
#   - statefulsets
$
#   verbs: ["list", "watch"]

Configurar lowDataMode en nri-bundle gráfico

Nuestros gráficos Helm admiten la configuración de una opción para reducir la cantidad de datos ingeridos a costa de eliminar información detallada. Para habilitarlo, establezca global.lowDataMode en true en el gráfico nri-bundle .

lowDataMode afecta a tres componentes específicos del gráfico nri-bundle :

1. Aumente el intervalo del agente de infraestructura de 15 a 30 segundos.
2. La integración de Prometheus OpenMetrics excluirá algunas métricas como se indica en el documento Helm a continuación.
3. Los detalles de las etiquetas y anotaciones se eliminarán del log.

Puede encontrar más detalles sobre esta configuración en nuestro documento Helm.

La integración de New Relic en el host representa un conjunto diverso de integración para servicios de terceros como Postgresql, MySQL, Kafka, RabbitMQ, etc. No es posible proporcionar todas las técnicas de optimización en el alcance de este documento, pero podemos proporcionar estas técnicas de aplicación general. :

• Administrar la frecuencia de muestreo

• Administre aquellas partes de la configuración que pueden aumentar o disminuir la amplitud de la colección.

• Administre aquellas partes de la configuración que permiten consultas personalizadas.

• Administre el atributo personalizado del agente de infraestructura porque se aplicarán a todos los datos de integración en el host.

  Usaremos algunos ejemplos para demostrarlo.

  Integración PostgreSQL

  Controladores de crecimiento

  • Monitor de número de mesas
  • Monitor de número de índices

  La configuración de integración en el host de PostgreSQL proporciona estas configuraciones ajustables que pueden ayudar a administrar el volumen de datos:

• interval: El valor predeterminado es 15s

• COLLECTION_LIST: lista de tablas para monitor (use TODOS para monitor TODOS)

• COLLECT_DB_LOCK_METRICS: Recoge dblock métrica

• PGBOUNCER: Recoge pgbouncer métrica

• COLLECT_BLOAT_METRICS: Recoger hinchazón métrica

• METRICS: Establezca en true para recopilar solo métrica

• INVENTORY: Establezca en true para habilitar solo la recopilación de inventario

• CUSTOM_METRICS_CONFIG: Archivo de configuración que contiene consulta de colección personalizada

  Configuración de muestra:

  integrations:
    - name: nri-postgresql
      env:
        USERNAME: postgres
        PASSWORD: pass
        HOSTNAME: psql-sample.localnet
        PORT: 6432
        DATABASE: postgres
        COLLECT_DB_LOCK_METRICS: false
        COLLECTION_LIST: '{"postgres":{"public":{"pg_table1":["pg_index1","pg_index2"],"pg_table2":[]}}}'
        TIMEOUT:  10
      interval: 15s
      labels:
        env: production
        role: postgresql
      inventory_source: config/postgresql

  Copia

  Integración de kafka

  Controladores de crecimiento

  • Número de corredores en el clúster
  • Número de temas en clúster

  La configuración de integración en el host de Kafka proporciona estas configuraciones ajustables que pueden ayudar a administrar el volumen de datos:

• interval: El valor predeterminado es 15s

• TOPIC_MODE: Determina cuántos temas recopilamos. Las opciones son all, none, list o regex.

• METRICS: Establezca en true para recopilar solo métrica

• INVENTORY: Establezca en true para habilitar solo la recopilación de inventario

• TOPIC_LIST: Matriz JSON de nombres de temas a monitor. Solo tiene efecto si topic_mode está configurado en lista.

• COLLECT_TOPIC_SIZE: recopile la métrica Tamaño del tema. Las opciones son true o false, el valor predeterminado es false.

• COLLECT_TOPIC_OFFSET:Recopila la métrica de desplazamiento del tema. Las opciones son true o false, el valor predeterminado es false.

  Cabe señalar que la recopilación de métricas a nivel de tema, especialmente las compensaciones, puede requerir muchos recursos y puede tener un impacto en el volumen de datos. Es muy posible que la ingesta de un clúster pueda aumentar en un orden de magnitud simplemente agregando nuevos temas de Kafka al clúster.

  Integración de MongoDB

  Controladores de crecimiento

  • Número de monitor de base de datos

  La integración de MongoDB proporciona estas configuraciones ajustables que pueden ayudar a administrar el volumen de datos:

• interval: El valor predeterminado es 15s

• METRICS: Establezca en true para recopilar solo métrica

• INVENTORY: Establezca en true para habilitar solo la recopilación de inventario

• FILTERS: un mapa JSON de nombres de bases de datos a una matriz de nombres de colecciones. Si está vacío, el valor predeterminado es toda la base de datos y colecciones.

  Para cualquier integración en el host que utilice, es importante tener en cuenta parámetros como FILTERS donde el valor predeterminado es recopilar métricas de toda la base de datos. Esta es un área donde puede utilizar sus prioridades de monitoreo para optimizar los datos recopilados.

  Ejemplo de configuración con diferentes intervalos para métrica e INVENTARIO:

  integrations:
    - name: nri-mongodb
      env:
        METRICS: true
        CLUSTER_NAME: my_cluster
        HOST: localhost
        PORT: 27017
        USERNAME: mongodb_user
        PASSWORD: mongodb_password
      interval: 15s
      labels:
        environment: production
  
    - name: nri-mongodb
      env:
        INVENTORY: true
        CLUSTER_NAME: my_cluster
        HOST: localhost
        PORT: 27017
        USERNAME: mongodb_user
        PASSWORD: mongodb_password
      interval: 60s
      labels:
        environment: production
      inventory_source: config/mongodb

  Copia

  Integración de búsqueda elástica

  Controladores de crecimiento

  • Número de nodos en el clúster
  • Número de índices en clúster

  La integración de Elasticsearch proporciona estas configuraciones ajustables que pueden ayudar a administrar el volumen de datos:

• interval: El valor predeterminado es 15s

• METRICS: Establezca en true para recopilar solo métrica

• INVENTORY: Establezca en true para habilitar solo la recopilación de inventario

• COLLECT_INDICES: Señala si se deben recoger índices métricos o no.

• COLLECT_PRIMARIES: Señala si se debe recoger métrica primaria o no.

• INDICES_REGEX: filtra qué índices se recopilan.

• MASTER_ONLY: Recoge el grupo métrico únicamente en el maestro elegido.

  Ejemplo de configuración con diferentes intervalos para METRICS y INVENTORY:

  integrations:
    - name: nri-elasticsearch
      env:
        METRICS: true
        HOSTNAME: localhost
        PORT: 9200
        USERNAME: elasticsearch_user
        PASSWORD: elasticsearch_password
        REMOTE_MONITORING: true
      interval: 15s
      labels:
        environment: production
  
    - name: nri-elasticsearch
      env:
        INVENTORY: true
        HOSTNAME: localhost
        PORT: 9200
        USERNAME: elasticsearch_user
        PASSWORD: elasticsearch_password
        CONFIG_PATH: /etc/elasticsearch/elasticsearch.yml
      interval: 60s
      labels:
        environment: production
      inventory_source: config/elasticsearch

  Copia

  Integración JMX

  Controladores de crecimiento

  • Métrica listada en COLLECTION_CONFIG

  La integración JMX es inherentemente genérica. Nos permite extraer métrica de cualquier instancia de JMX. Tenemos un buen control sobre lo que se recopila mediante esta integración. En algunos entornos empresariales de New Relic, JMX métrica representa una proporción relativamente alta de todos los datos recopilados.

  La integración JMX proporciona estas configuraciones ajustables que pueden ayudar a administrar el volumen de datos:

• interval: El valor predeterminado es 15s

• METRICS: Establezca en true para recopilar solo métrica

• INVENTORY: Establezca en true para habilitar solo la recopilación de inventario

• METRIC_LIMIT: Número de métricas que se pueden recolectar por entidad. Si se excede este límite la entidad no será reportada. Un límite de 0 implica que no hay límite.

• LOCAL_ENTITY: Recoge todas las métricas de la entidad local. Sólo se utiliza cuando se monitorea localhost.

• COLLECTION_FILES: una lista separada por comas de rutas de archivo completas a los archivos de definición de la colección métrica. Para la instalación en el host, el archivo de colección métrica JVM predeterminado está en /etc/newrelic-infra/integrations.d/jvm-metrics.yml.

• COLLECTION_CONFIG: configuración de la colección métrica como JSON.

  Son las COLLECTION_CONFIG entradas las que más controlan la cantidad de datos ingeridos. Comprender el modelo JMX que está extrayendo le ayudará a optimizar.

  COLLECTION_CONFIG ejemplo para JVM métrica

  COLLECTION_CONFIG='{"collect":[{"domain":"java.lang","event_type":"JVMSample","beans":[{"query":"type=GarbageCollector,name=*","attributes":["CollectionCount","CollectionTime"]},{"query":"type=Memory","attributes":["HeapMemoryUsage.Committed","HeapMemoryUsage.Init","HeapMemoryUsage.Max","HeapMemoryUsage.Used","NonHeapMemoryUsage.Committed","NonHeapMemoryUsage.Init","NonHeapMemoryUsage.Max","NonHeapMemoryUsage.Used"]},{"query":"type=Threading","attributes":["ThreadCount","TotalStartedThreadCount"]},{"query":"type=ClassLoading","attributes":["LoadedClassCount"]},{"query":"type=Compilation","attributes":["TotalCompilationTime"]}]}]}'

  Copia

  Omitir cualquier entrada de esa configuración, como NonHeapMemoryUsage.Init , tendrá un impacto tangible en el volumen general de datos recopilados.

  COLLECTION_CONFIG ejemplo para Tomcat métrica

  COLLECTION_CONFIG={"collect":[{"domain":"Catalina","event_type":"TomcatSample","beans":[{"query":"type=UtilityExecutor","attributes":["completedTaskCount"]}]}]}

  Copia

  Otra integración en el host

  Hay muchas otras integraciones en el host con opciones de configuración que te ayudarán a optimizar la recopilación. Algunos de uso común son:

• NGINX

• MySQL

• Redis

• Apache

• RabbitMQ

  Este es un buen punto de partida para aprender más.

Esta sección se centra en el monitoreo del rendimiento de la red de New Relic que depende del agente ktranslate de Kentik. Este agente es bastante sofisticado y es importante comprender completamente los documentos de configuración avanzada antes de realizar esfuerzos importantes de optimización. Las opciones de configuración incluyen:

• mibs_enabled: matriz de todas las MIB activas que sondeará la imagen docker de KTranslate. Esta lista se genera automáticamente durante el descubrimiento si el atributo discovery_add_mibs es true. Las MIB que no figuran aquí no serán sondeadas en ningún dispositivo en el archivo de configuración. Puede especificar una tabla SNMP directamente en un archivo MIB usando la sintaxis MIB-NAME.tableName . Ej: HOST-RESOURCES-MIB.hrProcessorTable.

• user_tags: valor principal atributo del par para darle más contexto al dispositivo. La etiqueta en este nivel se aplicará a todos los dispositivos en el archivo de configuración.

• devices: Sección que enumera los dispositivos que se monitorearán para determinar el flujo

• traps: configura IP y puertos para ser monitoreados con capturas SNMP (el valor predeterminado es 127.0.0.1:1162)

• discovery: configura cómo se puede descubrir el extremo. En esta sección, el siguiente parámetro hará más para aumentar o disminuir el alcance:

  • cidrs: matriz de rangos de IP objetivo en notación CIDR.
  • ports: matriz de puertos de destino para escanear durante el sondeo SNMP.
  • debug: Indica si se debe habilitar el logging de nivel de depuración durante el descubrimiento. De forma predeterminada, está configurado en false
  • default_communities: matriz de cadenas de comunidad SNMPv1/v2c para escanear durante el sondeo SNMP. Esta matriz se evalúa en orden y el descubrimiento acepta la primera comunidad que pasa.

  Para admitir el filtrado de datos que no crean valor para sus necesidades de observabilidad, puede configurar el mapa de atributos global.match_attributes.{} y/o devices.<deviceName>.match_attributes.{} .

  Esto proporcionará filtrado a nivel de KTranslate, antes de enviar datos a New Relic, brindándole un control granular sobre el monitoreo de cosas como interfaces.

  Para obtener más detalles, consulte Configuración de monitoreo del rendimiento de la red.

Log representa una de las fuentes de telemetría más flexibles, ya que normalmente enrutamos el log a través de una capa de reenvío dedicada con sus propias reglas de enrutamiento y transformación. Debido a que existe una variedad de reenviadores, nos centraremos en los más utilizados:

• APM language agente (versiones recientes)

• Fluentd

• Fluentbit

• Agente New Relic Infrastructure (Fluentbit integrado)

• Logstash

  Muestreo log del agente APM

  Las versiones recientes del agente de lenguaje de New Relic pueden reenviar logs directamente a New Relic. En algunos casos, es posible que desee controlar algunos límites de cuán grandes pueden ser los picos de logging de cada instancia del agente APM.

  Podemos habilitar el muestreo con la variable de entorno. NEW_RELIC_APPLICATION_LOGGING_FORWARDING_MAX_SAMPLES_STORED

  Se configura simplemente proporcionando la cantidad máxima de logs que se almacenarán en la cola de logging del agente APM. Opera en base a una cola de prioridad personalizada. Todos los mensajes de log tienen prioridad. Los logs que ocurren dentro de una transacción obtienen la prioridad de la transacción.

  La cola de logs se ordena según la prioridad y cuándo llega el log . La prioridad más alta gana y, si es necesario, ganará el log más nuevo (mantenemos un recuento de cada entrada en la cola). Los logs se agregan individualmente a la cola (los pares en una transacción) y cuando se alcanza el límite, el log al final de la cola se elimina a favor del log más nuevo. En la sección de recursos a continuación hay un dashboard inicio rápido que le ayuda a realizar un seguimiento del volumen log de una manera sencilla. El seguimiento del volumen log le permitirá ajustar o desactivar la frecuencia de muestreo para satisfacer sus necesidades de observabilidad.

  Configurando filtros en Fluentd o Fluentbit

  La mayoría de los reenviadores generales proporcionan un flujo de trabajo de enrutamiento bastante completo que incluye filtrado y transformación. El agente de infraestructura de New Relic proporciona algunos patrones muy simples para filtrar logs no deseados. Expresión regular para filtrar registros. Solo se admite para las fuentes tail, systemd, syslog y tcp (solo con formato ninguno). Este campo funciona de forma similar a grep -E en sistemas Unix. Por ejemplo, para un archivo determinado que se está capturando, puede filtrar los registros que contengan WARN o ERROR usando:

  - name: only-records-with-warn-and-error
      file: /var/log/logFile.log
      pattern: WARN|ERROR

  Copia

  Si tiene configuraciones de Fluentd preescritas para Fluentbit que realizan filtrado o análisis valiosos, puede importarlas a nuestra configuración de logging de New Relic. Para hacer esto, use el parámetro config_file y parsers en cualquier archivo .yaml en su carpeta logging.d :

• config_file: ruta a un archivo de configuración de Fluent Bit existente. Cualquier fuente superpuesta da como resultado mensajes duplicados en New Relic la administración de de log .

• parsers_file: ruta a un archivo de analizadores Fluent Bit existente.

  Los siguientes nombres de analizadores están reservados: rfc3164, rfc3164-local y rfc5424.

  Aprender cómo inyectar un atributo (o etiqueta) en su log en su canal de datos y realizar transformaciones puede ayudar con la eliminación de características posteriores utilizando las reglas de eliminación de New Relic. Al aumentar su log con metadatos sobre la fuente, podemos tomar decisiones centralizadas y fácilmente reversibles sobre qué colocar en el backend. Como mínimo, asegúrese de que el siguiente atributo esté presente en su log de alguna forma:

• Equipo

• Entorno (desarrollo/etapa/producción)

• Aplicación

• Centro de datos

• Nivel de Log

  A continuación se muestran algunos recursos detallados de enrutamiento y filtrado:

• Patrones comunes de filtrado y enrutamiento en Fluentd

• Tubería de datos de Fluentbit

• Reenvío de logs con el agente New Relic Infrastructure

  Ajustar el conjunto de atributos predeterminado del agente de infraestructura

  El agente de infraestructura agrega algún atributo de forma predeterminada, incluida cualquier etiqueta personalizada agregada al host. Es posible que su configuración incluya muchas más que eso, incluida una gran cantidad de etiquetas de AWS, que aparecen en New Relic con el formulario aws.[attributename]. Estos atributos son importantes para una observabilidad óptima, por lo que se recomienda encarecidamente que evalúe sus necesidades de visualización, análisis y alertas a la luz de cualquier cambio de configuración planificado. Por ejemplo, el log de un clúster de Kubernetes probablemente no será útil sin metadatos como:

• cluster_name

• pod_name

• container_name

• node_name

New Relic ofrece dos opciones principales para enviar Prometheus métrica a New Relic. Las mejores prácticas para gestionar la ingesta métrica en este documento se centrarán principalmente en la opción 2, la integración de Prometheus OpenMetrics (POMI), porque este componente fue creado por New Relic.

Opción 1: integración de escritura remota de Prometheus

Para conocer las opciones de configuración de extracción del servidor Prometheus, consulte los documentos de configuración de Prometheus. Estas configuraciones de raspado determinan qué métricas recopila el servidor Prometheus. Al configurar el parámetro remote_write , la métrica recopilada se puede escribir en la base de datos de New Relic (NRDB) a través de la API de métrica de New Relic.

Opción 2: integración de Prometheus OpenMetrics (POMI)

POMI es una integración independiente que extrae métrica del extremo Prometheus tanto dinámico como estático. Luego, POMI envía estos datos a NRDB a través de la API métrica de New Relic. Esta integración es ideal para clientes que actualmente no ejecutan Prometheus Server.

POMI: etiqueta raspada

POMI descubrirá cualquier extremo de Prometheus que contenga la etiqueta o anotación prometheus.io/scrape=true de forma predeterminada. Dependiendo de lo que se despliegue en el grupo, esto puede ser una gran cantidad de extremos y, por lo tanto, una gran cantidad de métricas ingeridas.

Se sugiere modificar el parámetro scrape_enabled_label a algo personalizado (p. ej. newrelic/scrape) y que el extremo de Prometheus se etiquete o anote selectivamente cuando la ingesta de datos sea de suma preocupación.

Para obtener la configuración de referencia más reciente, consulte nri-prometheus-latest.yaml.

Parámetros de configuración de POMI:

# Label used to identify scrapable targets. 
# Defaults to "prometheus.io/scrape"
  scrape_enabled_label: "prometheus.io/scrape"

POMI descubrirá cualquier extremo de Prometheus expuesto a nivel de nodo de forma predeterminada. Esto generalmente incluye métricas provenientes de Kubelet y cAdvisor.

Si está ejecutando New Relic Kubernetes Daemonset, es importante que configure require_scrape_enabled_label_for_nodes: true para que POMI no recopile métricas duplicadas.

Para conocer el objetivo final de New Relic Kubernetes Daemonset, consulte nuestro README de Kubernetes en GitHub.

POMI: etiqueta raspada para nodos

POMI descubrirá cualquier extremo de Prometheus expuesto a nivel de nodo de forma predeterminada. Esto generalmente incluye métricas provenientes de Kubelet y cAdvisor.

Si está ejecutando New Relic Kubernetes Daemonset, es importante que configure require_scrape_enabled_label_for_nodes: true para que POMI no recopile métricas duplicadas.

Para conocer el objetivo final de New Relic Kubernetes Daemonset, consulte nuestro README de Kubernetes en GitHub.

Parámetro de configuración POMI

# Whether k8s nodes need to be labeled to be scraped or not. 
# Defaults to false.
  require_scrape_enabled_label_for_nodes: false

POMI: coexistiendo con nri-kubernetes

La integración de Kubernetes de New Relic recopila una cantidad de métricas listas para usar. Sin embargo, no recopila todas las métricas posibles disponibles de un clúster de Kubernetes.

En la configuración de POMI, verá una sección similar a esta que deshabilitará la recopilación de métrica para un subconjunto de métrica que **la New Relic Kubernetes integración ya está recopilando de Kube State Metrics**.

También es muy importante configurar require_scrape_enabled_label_for_node: true para que Kubelet y cAdvisor métrica no se dupliquen.

Parámetros de configuración de POMI:

transformations:
    - description: "Uncomment if running New Relic Kubernetes integration"
      ignore_metrics:
        - prefixes:
          - kube_daemonset_
          - kube_deployment_
          - kube_endpoint_
          - kube_namespace_
          - kube_node_
          - kube_persistentvolume_
          - kube_persistentvolumeclaim_
          - kube_pod_
          - kube_replicaset_
          - kube_service_
          - kube_statefulset_

POMI: configuración de solicitud/límite

Al ejecutar POMI, se recomienda aplicar los siguientes límites de recursos para el clúster que genera aproximadamente 500k DPM:

• Límite de CPU: 1 núcleo (1000 m)
• Límite de memoria: 1Gb 1024 (1G)

La solicitud de recursos para CPU y memoria debe establecerse en un valor razonable para que POMI reciba suficientes recursos del clúster. Establecer esto en algo extremadamente bajo (p. ej. CPU: 50 m) puede provocar que los "vecinos ruidosos" consuman los recursos del clúster.

Parámetros de configuración de POMI:

spec:
  serviceAccountName: nri-prometheus
  containers:
  - name: nri-prometheus
    image: newrelic/nri-prometheus:2.2.0
    resources:
      requests:
        memory: 512Mi
        cpu: 500m
      limits:
        memory: 1G
        cpu: 1000m

POMI: estimación de DPM y cardinalidad

Aunque la cardinalidad no está asociada directamente con la facturación por ingesta de GB, New Relic mantiene ciertos límites de velocidad en cardinalidad y puntos de datos por minuto. Poder visualizar la cardinalidad y el DPM de un clúster de Prometheus puede ser muy importante.

Si ya está ejecutando Prometheus Server, puede ejecutar estimaciones de cardinalidad y DPM allí antes de habilitar POMI o remote_write.

Puntos de datos por minuto (DPM):

rate(prometheus_tsdb_head_samples_appended_total[10m]) * 60

Top 20 métricas (alta cardinalidad):

topk(20, count by (**name**, job)({__name__=~".+"}))

Algunas integraciones de New Relic en la nube obtienen datos de las API de los proveedores de la nube. Con esta implementación, los datos generalmente se recopilan de API de monitoreo como AWS CloudWatch, monitoreo de Azure y GCP Stackdriver, y los metadatos de inventario se recopilan de las API de servicios específicos.

Otras integraciones en la nube obtienen sus datos de streaming métrico (o métrico "empujado") que se envían a través de un servicio de streaming como AWS Kinesis.

Integración basada en API de sondeo

Si desea reportar más o menos datos de su integración en la nube, o si necesita controlar el uso de las API de los proveedores de la nube para evitar alcanzar límites de velocidad y aceleración en su cuenta de la nube, puede cambiar los ajustes de configuración para modificar la cantidad de datos que reportan. Los dos controles principales son:

• Cambiar la frecuencia de las encuestas

• Cambiar los datos que se informan

  Ejemplos de razones comerciales para querer cambiar la frecuencia de las encuestas incluyen:

• Facturación: si necesita gestionar su factura de AWS CloudWatch, es posible que desee disminuir la frecuencia de sondeo. Antes de hacer esto, cerciorar de que cualquier condición de alerta establecida para su integración en la nube no se vea afectada por esta reducción.

• Nuevos servicios: si está implementando un nuevo servicio o configuración y desea recopilar datos con más frecuencia, es posible que desee aumentar la frecuencia de sondeo temporalmente.

  Advertencia

  Cambiar los ajustes de configuración de su integración puede afectar la condición de alerta y las tendencias de los gráficos.

  Para obtener más detalles, consulte Configurar el sondeo.

  "Streaming" o "empujado" métrica

  Cada vez más integración en la nube ofrecen la opción de enviar los datos a través de un servicio de transmisión en lugar de utilizar el sondeo API. Se ha demostrado que esto reduce drásticamente la latencia. Un problema que algunos usuarios han observado es que no es tan fácil controlar el volumen porque no se puede configurar la frecuencia de muestreo.

  New Relic para eliminar datos se tratarán detalladamente en la siguiente sección. Son la forma principal de filtrar transmisiones métricas que tienen un volumen demasiado alto. Sin embargo, hay algunas cosas que se pueden hacer por parte del proveedor de la nube para limitar un poco el volumen de transmisión.

  Por ejemplo, en AWS es posible utilizar claves de condición para limitar el acceso a los espacios de nombres de CloudWatch*.

  La siguiente política limita al usuario a publicar métricas únicamente en el namespace denominado MyCustomNamespace:

  {
    "Version": "2012-10-17",
    "Statement": {
      "Effect": "Allow",
      "Resource": "*",
      "Action": "cloudwatch:PutMetricData",
      "Condition": {
        "StringEquals": {
          "cloudwatch:namespace": "MyCustomNamespace"
        }
      }
    }
  }

  Copia

  La siguiente política permite al usuario publicar métricas en cualquier namespace excepto CustomNamespace2:

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Resource": "*",
        "Action": "cloudwatch:PutMetricData"
      },
      {
        "Effect": "Deny",
        "Resource": "*",
        "Action": "cloudwatch:PutMetricData",
        "Condition": {
          "StringEquals": {
            "cloudwatch:namespace": "CustomNamespace2"
          }
        }
      }
    ]
  }

  Copia

Todas las reglas de caída de New Relic se implementan mediante el mismo modelo de datos de backend y API. Sin embargo, la administración de logs de New Relic proporciona una potente UI que hace que sea muy fácil crear y monitor reglas de eliminación.

En nuestra sección anterior sobre priorización de la telemetría, realizamos algunos ejercicios para mostrar formas en las que podríamos desaprobar ciertos datos. Revisemos este ejemplo:

Omit debug logs (knowing they can be turned on if there is an issue) (saves 5%)

Método 1: log UI

• Identifique el log que nos interesa mediante un filtro en la log UI: level: DEBUG.
• Asegúrese de que encuentre el log que queremos eliminar.
• Verifique alguna sintaxis alternativa como level:debug y log_level:Debug. Estas variaciones son comunes.
• En Manage data, haga clic en Drop filters y cree y habilite un filtro llamado 'Eliminar registro de depuración'.
• Verifique que la regla funcione.

Método 2: nuestra API NerdGraph

• Cree la consulta NRQL relevante:

  SELECT count(*) FROM Log WHERE `level` = 'DEBUG'

  Copia
• Asegúrese de que encuentre el log que queremos eliminar.
• Verifique las variaciones en el nombre y el valor del atributo (Debug vs DEBUG).
• Ejecute la siguiente declaración NerdGraph y asegúrese de que funcione:

mutation {
  nrqlDropRulesCreate(
    accountId: YOUR_ACCOUNT_ID
    rules: [
      {
        action: DROP_DATA
        nrql: "SELECT * FROM Log WHERE `level` = 'DEBUG'"
        description: "Drops DEBUG logs.  Disable if needed for troubleshooting."
      }
    ]
  ) {
    successes {
      id
    }
    failures {
      submitted {
        nrql
      }
      error {
        reason
        description
      }
    }
  }
}

Implementemos la recomendación: Drop process sample data in DEV environments.

• Cree la consulta relevante:

  SELECT * FROM ProcessSample WHERE `env` = 'DEV'

  Copia

• Asegúrese de que encuentre las muestras de proceso que queremos eliminar.

• Compruebe si hay otras variaciones en env como ENV y Environment

• Compruebe si hay varios de DEV como Dev y Development

• Utilice nuestra API NerdGraph para ejecutar la siguiente declaración y asegúrese de que funcione:

  mutation {
    nrqlDropRulesCreate(
      accountId: YOUR_ACCOUNT_ID
      rules: [
        {
          action: DROP_DATA
          nrql: "SELECT * FROM ProcessSample WHERE `env` = 'DEV'"
          description: "Drops ProcessSample from development environments"
        }
      ]
    ) {
      successes {
        id
      }
      failures {
        submitted {
          nrql
        }
        error {
          reason
          description
        }
      }
    }
  }

  Copia

En algunos casos podemos economizar datos cuando tenemos cobertura redundante. Por ejemplo: en un entorno donde tiene la integración de AWS RDS ejecutándose, así como una de las integraciones de New Relic en el host que monitor la base de datos SQL como nri-mysql o nri-postgresql, es posible que pueda descartar algunas métricas superpuestas. .

Para una exploración rápida podemos ejecutar una consulta como esta:

FROM Metric select count(*) where metricName like 'aws.rds%' facet metricName limit max

Eso nos mostrará todos los metricName valores que coinciden con el patrón.

Vemos en los resultados que hay un gran volumen de métrica del patrón aws.rds.cpu%. Dejémoslos porque tenemos otra instrumentación para ellos:

• Cree la consulta relevante:

  FROM Metric select * where metricName like 'aws.rds.cpu%' facet metricName limit max since 1 day ago

  Copia
• Asegúrese de que encuentre las muestras de proceso que queremos eliminar.
• Utilice la API NerdGraph para ejecutar la siguiente declaración y asegúrese de que funcione:

mutation {
  nrqlDropRulesCreate(
    accountId: YOUR_ACCOUNT_ID
    rules: [
      {
        action: DROP_DATA
        nrql: "FROM Metric select * where metricName like 'aws.rds.cpu%' facet metricName limit max since 1 day ago"
        description: "Drops rds cpu related metrics"
      }
    ]
  ) {
    successes {
      id
    }
    failures {
      submitted {
        nrql
      }
      error {
        reason
        description
      }
    }
  }
}

Una ventaja de las reglas de eliminación es que podemos configurar una regla que elimine un atributo específico pero mantenga el resto de los datos intactos. Úselo para eliminar datos privados de NRDB o para eliminar un atributo excesivamente grande. Por ejemplo, el rastreo del stack o grandes fragmentos de JSON en log a veces pueden ser muy grandes.

Para establecer estas reglas de eliminación, cambie el campo action a DROP_ATTRIBUTES en lugar de DROP_DATA.

mutation {
  nrqlDropRulesCreate(
    accountId: YOUR_ACCOUNT_ID
    rules: [
      {
        action: DROP_ATTRIBUTES
        nrql: "SELECT stack_trace, json_data FROM Log where appName='myApp'"
        description: "Drops large fields from logs for myApp"
      }
    ]
  ) {
    successes {
      id
    }
    failures {
      submitted {
        nrql
      }
      error {
        reason
        description
      }
    }
  }
}

En este ejemplo aprovecharemos la distribución relativa de ciertos ID de traza para aproximar el muestreo aleatorio. Podemos utilizar el operador rlike para comprobar los valores principales del atributo trace.id de un intervalo.

El siguiente ejemplo podría reducir aproximadamente el 25 % de los intervalos:

SELECT * FROM Span WHERE trace.id rlike r'.*[0-3]' and appName = 'myApp'

Las expresiones útiles incluyen:

• r'.*0' se aproxima al 6,25%
• r'.*[0-1]' se aproxima al 12,5%
• r'.*[0-2]' se aproxima al 18,75%
• r'.*[0-3]' se aproxima al 25,0%

Aquí hay un ejemplo de una mutación completa:

mutation {
  nrqlDropRulesCreate(
    accountId: YOUR_ACCOUNT_ID
    rules: [
      {
        action: DROP_ATTRIBUTES
        nrql: "SELECT * FROM Span WHERE trace.id rlike r'.*[0-3]' and appName = 'myApp'"
        description: "Drops approximately 25% of spans for myApp"
      }
    ]
  ) {
    successes {
      id
    }
    failures {
      submitted {
        nrql
      }
      error {
        reason
        description
      }
    }
  }
}

Los ejemplos anteriores deberían mostrarle todo lo que necesita saber para utilizar estas técnicas en cualquier otro evento o métrica en NRDB. Si puedes consultarlo puedes dejarlo. Comuníquese con New Relic si tiene preguntas sobre la forma precisa de estructurar una consulta para una regla de eliminación.