Optimice sus datos de ingesta

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 se puede asumir que todas las llamadas a una aplicación son necesarias, es posible hacer que la arquitectura general sea más eficiente. Podrá tener un perfil de usuario de microservicios llamado cada 10 segundos por sus clientes. Esto ayuda a reducir la latencia si otros clientes actualizan alguna información del usuario. Sin embargo, tienes la opción de reducir la frecuencia de las llamadas a este servicio a cada minuto, por ejemplo.

  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 las cosas 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 más información mediante encabezados 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 reducir el volumen de datos descubriendo cómo APM manejará los errores. Por ejemplo, puede haber un error inofensivo pero de gran volumen que no puedes eliminar en este momento.

  Para hacer esto, puede usar collect, ignore o mark as expected para errores. 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 establecida. Para ayudar con esto, puede controlar qué tan detallada es la monitorización de la consulta de la base de datos. Estas consultas aparecerán en la página Transaction traces .

  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 la 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 pueden reportar por ciclo de cosecha. Si no hubiera límite, una cantidad suficientemente grande de eventos enviados podría afectar el rendimiento de su aplicación o de New Relic. Al alcanzar el límite, el agente comienza a muestrear el evento para brindar una representación del evento a lo largo del ciclo de recolección. Diferentes agentes tienen diferentes límites.

  Evento que con límites y sujeto a muestreo incluya:

• 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 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, tenga en cuenta lo siguiente:

• 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 saber si se están eliminando eventos, 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 logs directamente a New Relic. A veces, 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 mediante la configuración de traza de la transacción. El nivel y el modo de configurabilidad serán específicos del idioma.

  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. Puede desactivar rastreo distribuido 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 varía según si está utilizando Infinite Tracing. El rastreo estándar distribuido para el agente APM (arriba) captura hasta el 10% de su traza, pero si desea analizar todos sus datos y encontrar 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

Puede bloquear solicitudes de tres maneras:

• 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

   .

4. En

   Ajax request deny list

   , agregue los filtros que desea aplicar.

5. Seleccione

   Save application settings

   para actualizar la configuración del agente.

6. Vuelva a implementar el agente del navegador reiniciando el agente APM asociado o actualizando la instalación browser copiando y pegando.

   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 y se utilizan en la página 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.

Puede 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 contiene dos formas 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 puede ajustar. También es posible crear expresiones regulares para controlar lo que se recopila de determinado recolector, como ProcessSample y NetworkSample.

Tasas de muestreo configurables

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

Muestras de proceso

Las muestras de procesos suelen ser la fuente de datos de mayor volumen del agente de infraestructura porque envía información sobre cualquier proceso en ejecución en un host. Están deshabilitados de forma predeterminada, pero puedes habilitarlos 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 envías configurando include_matching_metrics, 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"

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

atributo personalizado son pares de valores principales similares a las etiquetas en otras herramientas utilizadas para anotar los datos del agente de infraestructura. Puede utilizar 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 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

Los sistemas complejos y descentralizados como Kubernetes tienen el potencial de generar mucha telemetría en poco tiempo. 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. 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, que tiene un tiempo predeterminado de 15 segundos. El explorador del clúster de Kubernetes solo se actualiza cada 45 segundos. Si su uso principal de los datos de Kubernetes es respaldar las visualizaciones de KCE, puede considerar cambiar su intervalo de extracción a 20 segundos. Cambiar de 15 a 20 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 versión 3 y superiores 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 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 puede realizar 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 Kubernetes 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

  1

• Datos del administrador del controlador

  1

• Datos ETCD

  1

• Datos del programador

  1

¹ 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

  2

• 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 opción de 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 en el host de New Relic representa un conjunto diverso de integración para servicios de terceros como Postgresql, MySQL, Kafka, RabbitMQ, etc. Es imposible proporcionar todas las técnicas de optimización en el alcance de este documento, pero estas técnicas generalmente se aplican:

• Administrar la frecuencia de muestreo

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

• Gestionar aquellas partes de la configuración que permiten una consulta personalizada.

• Administre el atributo personalizado del agente de infraestructura para aplicarlo 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

  Sample config:

  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.

  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. La ingesta de un clúster puede 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.

  Example configuration with different intervals for METRIC and INVENTORY:

  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.

  Example configuration with different intervals for METRICS and 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. Le permite extraer métrica de cualquier instancia de JMX. Usted tiene control sobre lo que se recopila mediante esta integración. En algunas empresas, los entornos JMX métrica de New Relic representan 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. Es posible que desee controlar algunos límites de cuán grandes pueden ser los picos de logging de cada instancia del agente APM.

  Puede habilitar el muestreo con la variable de entorno NEW_RELIC_APPLICATION_LOGGING_FORWARDING_MAX_SAMPLES_STORED y configurarlo proporcionando la cantidad máxima de logs que almacenará la cola de logging del agente APM. Opera en base a una cola de prioridad personalizada y otorga prioridad a todos los mensajes de log. Los logs que ocurren dentro de una transacción obtienen la prioridad de la transacción.

  La cola de log se ordena según la prioridad y cuándo llega el log . La prioridad más alta va primero y, si es necesario, el log más reciente tiene prioridad. Los logs se agregan individualmente a la cola (los pares en una transacción) y, al alcanzar 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 de 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. Nuestro agente de infraestructura proporciona 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 none). 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. 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

  administración de logs

  de New Relic.

• 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 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, por lo que se recomienda encarecidamente que evalúe sus necesidades de visualización, análisis y alertas en relación con 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 se centran principalmente en la segunda opción, 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 scrape determinan qué métricas recopila el servidor Prometheus. Al configurar el parámetro remote_write , puede escribir la métrica recopilada 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 el servidor Prometheus.

POMI: etiqueta raspada

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

Se sugiere modificar el parámetro scrape_enabled_label a algo personalizado (p. ej. newrelic/scrape), y que etiquete selectivamente el extremo de Prometheus 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.

POMI config parameter:

# 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 recopilará disable métricas para un subconjunto de métricas que la integración de New Relic Kubernetes 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.

POMI config parameters:

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)

Debe configurar la solicitud de recursos para CPU y memoria para proporcionar a POMI 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.

POMI config parameter:

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 antes de habilitar POMI o remote_write.

Data points per minute (DPM):

rate(prometheus_tsdb_head_samples_appended_total[10m]) * 60

Top 20 metrics (highest cardinality):

topk(20, count by (<DNT>**name**</DNT>, 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 se recopilan de las API de monitoreo como AWS CloudWatch, el monitoreo de Azure y GCP Stackdriver, y los metadatos del inventario se recopilan de las API de los 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 la tasa límite y los límites de aceleración en su cuenta de la nube, puede cambiar los ajustes de configuración. 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:

• Billing

  : Si necesita administrar su factura de AWS CloudWatch, es posible que desee disminuir la frecuencia de sondeo. Antes de hacer esto, asegúrese de que cualquier condición de alerta establecida para su integración en la nube no se vea afectada por esta reducción.

• New services

  : 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 datos a través de un servicio de streaming en lugar de utilizar el sondeo API, lo que 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.

  Las reglas de New Relic para eliminar datos son la forma principal de filtrar la transmisión métrica con un volumen demasiado alto. Sin embargo, hay algunas cosas que puede hacer por parte del proveedor de la nube para ayudar a limitar 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. Nuestra administración de logs proporciona una potente UI que facilita la creación y monitor de reglas de eliminación.

Anteriormente, en esta serie de tutoriales, cubrimos la priorización de la telemetría ejecutando 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 denominado "Eliminar log 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 desea 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.

• Busque otras variaciones de env , como ENV y Environment.

• Busque 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

A menudo puedes reducir el uso de datos reduciendo los datos con 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 superposiciones. métrica.

Por ejemplo, puede ejecutar una consulta como esta:

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

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

Puedes ver en los resultados que hay un gran volumen de métrica del patrón aws.rds.cpu%. Puedes eliminarlos porque tienes 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 desea descartar.

• 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
        }
      }
    }
  }

  Copia

Una cosa importante acerca de las reglas de eliminación es que puede configurar una regla que elimine un atributo específico pero mantenga la integridad del resto de los datos. Úselo para eliminar datos privados de NRDB o para eliminar atributos excesivamente grandes, como rastreo del stack o grandes fragmentos de JSON en registros de log excesivamente 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, puede aprovechar la distribución relativa de ciertos ID de traza para aproximar el muestreo aleatorio. Puede 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%

  Después de quedarte sin dígitos, puedes usar letras, por ejemplo:

• r'.*[a0-9]' se aproxima al 68,75%

• r'.*[a-b0-9]' aproximadamente 75,0%

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

  mutation {
    nrqlDropRulesCreate(
      accountId: YOUR_ACCOUNT_ID
      rules: [
        {
          action: DROP_DATA
          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
        }
      }
    }
  }

  Copia

  Sugerencia

  Dado que los trace.idson números hexadecimales, cada carácter de trace.id es un valor de 0123456789abcdef. Cada carácter que agregue al patrón RLIKE coincidirá con 1/16 adicional de las filas en el evento de extensión, suponiendo que los caracteres finales tengan una distribución uniforme. Si agrega letras más allá de la F que no se usan en hexadecimal, los dígitos agregados no afectarán el porcentaje coincidente.

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. Recuerda: si puedes consultarlo puedes dejarlo. Comuníquese con nosotros si tiene preguntas sobre la forma precisa de estructurar una consulta para una regla de eliminación.