Gateway de control de pipelines

Pipeline Control gateway es un pipeline de procesamiento de datos basado en OpenTelemetry que se ejecuta en su infraestructura. Procesa datos de telemetría antes de enviarlos a New Relic, lo que le brinda control sobre los costos de datos, la calidad de la señal y la gestión de datos.

¿Qué problemas resuelve el gateway de Pipeline Control?

Las organizaciones están abrumadas por datos de telemetría ruidosos e irrelevantes debido a la falta de visibilidad y control granular sobre cómo se procesan los datos. Esto dificulta encontrar información valiosa, gestionar los datos de manera eficaz, y conduce a mayores costos y una observabilidad menos eficiente.

Filtrar datos ruidosos

Problema: Los logs de depuración, los datos del entorno de prueba y las verificaciones de estado inundan su sistema con información irrelevante, lo que dificulta encontrar problemas críticos.

Solución con gateway:

• Filtra todos los logs de DEBUG de los entornos de producción
• Descarte toda la telemetría de los entornos de prueba antes de que salga de su red
• Elimine los logs de comprobación de estado que generan millones de entradas diarias
• Filtrar por nivel de log, entorno, nombre del servicio o cualquier atributo

Resultado: La relación señal-ruido mejorada facilita la identificación de anomalías críticas y tendencias.

Reduzca los costos de ingesta de datos

Problema: Su factura de observabilidad es de $80,000/mes, con un 70% proveniente de la ingesta de logs de rutina. Los datos de alto volumen y bajo valor aumentan los costos sin aportar información útil.

Solución con gateway:

• Muestrea el 95% de los logs INFO mientras conservas el 100% de los logs ERROR y WARN
• Descarte las métricas específicas de usuario para los usuarios que no pagan (80% de su base de usuarios)
• Filtre la telemetría redundante o innecesaria en el origen
• Gestione los datos a un nivel granular basado en el valor del negocio

Resultado: Reduzca el volumen de datos en un 85%, reduciendo su factura mensual de $80,000 a $12,000, al tiempo que conserva todos los datos críticos.

Agregar contexto y enriquecer datos

Problema: Sus microservicios utilizan diferentes marcos de logging. Logs del Servicio A level=ERROR, logs del Servicio B severity=error, logs del Servicio C log_level=3. No puede crear dashboards unificados ni alertas.

Solución con gateway:

• Normalizar nombres de atributos: Transformar todas las variantes a severity.text=ERROR
• Agregar metadatos organizacionales: team, cost_center, region a toda la telemetría
• Enriquecer con contexto de negocio: Agregar business_criticality=HIGH para los endpoints de checkout
• Estandarizar nombres de entorno: env, environment, deploy_env → deployment.environment

Resultado: Una consulta funciona en todos los servicios. Los dashboards unificados muestran métricas precisas entre servicios sin requerir cambios en el código de la aplicación.

¿Quién debería usar esto?

Encontrará útil el gateway de Pipeline Control si:

• Están abrumados por datos de telemetría ruidosos e irrelevantes
• Necesita reducir los costos de ingesta de datos
• Desea mejorar la relación señal-ruido para encontrar problemas críticos más rápido
• Necesita agregar contexto organizacional a los datos de telemetría
• Desea estructurar datos de logs no estructurados para mejorar las consultas
• Necesita cumplir con las regulaciones de privacidad de datos
• ¿Desea tener control sobre qué datos salen de su red?

Conceptos básicos

Tipos de telemetría

Gateway procesa cuatro tipos de telemetría de forma independiente:

• Métricas: Mediciones numéricas (uso de CPU, tasa de solicitudes, consumo de memoria)
• Eventos: Ocurrencias discretas (despliegues, registros de usuarios, errores)
• Logs: Registros basados en texto de la actividad de la aplicación
• Trazas: Flujos de solicitudes distribuidas a través de microservicios (spans individuales)

Cada tipo fluye a través de su propio pipeline con sus propios procesadores.

Procesadores

Los procesadores son los componentes básicos de su pipeline. Cada tipo de procesador tiene un propósito específico:

Procesadores de transformación modifican datos usando OTTL:

• Agregar, actualizar o eliminar atributos
• Analizar cadenas con patrones regex
• Derive nuevos campos a partir de datos existentes
• Aplicar hash a atributos de alta cardinalidad
• Funciones de ejemplo: set(), replace_pattern(), delete_key(), Hash()

Los procesadores de filtro descartan datos mediante expresiones booleanas OTTL:

• Descartar registros completos que coincidan con las condiciones
• Filtrar según múltiples condiciones combinadas
• Expresiones de ejemplo: attributes["http.url"] matches ".*health.*", duration < 100000000

Los procesadores de muestreo reducen el volumen de datos de forma inteligente:

• Configurar el porcentaje de muestreo predeterminado (por ejemplo, muestrear el 10% de todos los datos)
• Defina reglas condicionales (por ejemplo, conservar el 100% de los errores, muestrear el 5% de los éxitos)
• Controle el muestreo mediante valores de atributos o patrones

Configuración basada en YAML

La configuración del Gateway utiliza archivos YAML con una estructura declarativa:

version: 2.0.0
autoscaling:
  minReplicas: 6
  maxReplicas: 10
  targetCPUUtilizationPercentage: 60
configuration:
  simplified/v1:
    troubleshooting:
      proxy: false
      requestTraceLogs: false
    steps:
      receivelogs:
        description: Receive logs from OTLP and New Relic proprietary sources
        output:
          - probabilistic_sampler/Logs
      receivemetrics:
        description: Receive metrics from OTLP and New Relic proprietary sources
        output:
          - filter/Metrics
      receivetraces:
        description: Receive traces from OTLP and New Relic proprietary sources
        output:
          - probabilistic_sampler/Traces
      probabilistic_sampler/Logs:
        description: Probabilistic sampling for all logs
        output:
          - filter/Logs
        config:
          global_sampling_percentage: 100
          conditionalSamplingRules:
            - name: sample the log records for ruby test service
              description: sample the log records for ruby test service with 70%
              sampling_percentage: 70
              source_of_randomness: trace.id
              condition: resource.attributes["service.name"] == "ruby-test-service"
      probabilistic_sampler/Traces:
        description: Probabilistic sampling for traces
        output:
          - filter/Traces
        config:
          global_sampling_percentage: 80
      filter/Logs:
        description: Apply drop rules and data processing for logs
        output:
          - transform/Logs
        config:
          error_mode: ignore
          logs:
            rules:
              - name: drop the log records
                description: drop all records which has severity text INFO
                value: log.severity_text == "INFO"
      filter/Metrics:
        description: Apply drop rules and data processing for metrics
        output:
          - transform/Metrics
        config:
          error_mode: ignore
          metric:
            rules:
              - name: drop entire metrics
                description: delete the metric on basis of humidity_level_metric
                value: (name == "humidity_level_metric" and IsMatch(resource.attributes["process_group_id"], "pcg_.*"))
          datapoint:
            rules:
              - name: drop datapoint
                description: drop datapoint on the basis of unit
                value: (attributes["unit"] == "Fahrenheit" and (IsMatch(attributes["process_group_id"], "pcg_.*") or IsMatch(resource.attributes["process_group_id"], "pcg_.*")))
      filter/Traces:
        description: Apply drop rules and data processing for traces
        output:
          - transform/Traces
        config:
          error_mode: ignore
          span:
            rules:
              - name: delete spans
                description: deleting the span for a specified host
                value: (attributes["host"] == "host123.example.com" and (IsMatch(attributes["control_group_id"], "pcg_.*") or IsMatch(resource.attributes["control_group_id"], "pcg_.*")))
          span_event:
            rules:
              - name: Drop all the traces span event
                description: Drop all the traces span event with name debug event
                value: name == "debug_event"
      transform/Logs:
        description: Transform and process logs
        output:
          - nrexporter/newrelic
        config:
          log_statements:
            - context: log
              name: add new field to attribute
              description: for otlp-test-service application add newrelic source type field
              conditions:
                - resource.attributes["service.name"] == "otlp-java-test-service"
              statements:
                - set(resource.attributes["source.type"],"otlp")
      transform/Metrics:
        description: Transform and process metrics
        output:
          - nrexporter/newrelic
        config:
          metric_statements:
            - context: metric
              name: adding a new attributes
              description: 'adding a new field into a attributes '
              conditions:
                - resource.attributes["service.name"] == "payments-api"
              statements:
                - set(resource.attributes["application.name"], "compute-application")
      transform/Traces:
        description: Transform and process traces
        output:
          - nrexporter/newrelic
        config:
          trace_statements:
            - context: span
              name: remove the attribute
              description: remove the attribute when service name is payment-service
              conditions:
                - resource.attributes["service.name"] == "payment-service"
              statements:
                - delete_key(resource.attributes, "service.version")
      nrexporter/newrelic:
        description: Export to New Relic

Características clave:

• Declaración de versión: versión: 2.0.0 especifica el esquema de configuración
• Nombre del paso: El formato es processortype/TelemetryType (por ejemplo, transform/Logs, filter/Metrics)
• Encadenamiento de salida: cada paso declara sus destinos de salida, creando el pipeline de procesamiento

Flujo del pipeline

El gateway organiza los datos en tres pipelines independientes: métricas, eventos y logs, y trazas. Este aislamiento garantiza que un gran volumen de logs, por ejemplo, no interfiera con el procesamiento o la entrega de trazas de rendimiento críticas.

Cada pipeline consta de tres etapas funcionales:

1. Receptores (Ingress) Los receptores son los puntos de entrada para sus datos. La puerta de enlace escucha automáticamente la telemetría entrante de:

• OpenTelemetry (OTLP): Datos estándar de los SDKs y recolectores de OTel.

• Agentes de New Relic: Agentes de telemetría propietarios.

2. Procesadores (Lógica y transformación) Aquí es donde se aplican sus reglas personalizadas. Usted define cómo se manejan los datos utilizando tres tipos principales de procesadores:

• Muestreo: Reduzca el volumen mediante muestreo probabilístico o condicional

• Filtro: Descarte registros o atributos específicos según condiciones.

• Transformar: Utilice el Lenguaje de Transformación de OpenTelemetry (OTTL) para analizar logs, renombrar atributos o enriquecer datos con metadatos.

3. Exportadores (Salida) Una vez que los datos han sido procesados, filtrados y muestreados, el exportador transmite de forma segura la telemetría restante de alto valor a la nube de New Relic.

Al definir su pipeline en YAML, asignará sus procesadores a tipos de telemetría específicos. Para mantener su configuración organizada, utilizamos un patrón de nombres estándar: processor_type/telemetry_type.

Ejemplos:

• transformar/logs: Aplica lógica de transformación específicamente a los datos de logs.

• filtrar/métricas: Aplica reglas de descarte específicamente a las métricas.

• muestreo/trazas: Gestiona el volumen de trazas distribuidas.

Nota:

• A diferencia de las reglas de nube (que son específicas de la cuenta), las reglas de puerta de enlace se aplican a toda su organización.
• Los procesadores solo afectan el tipo de telemetría especificado en su nombre. Una regla de filtro/Logs nunca descartará accidentalmente sus métricas o trazas.

Métodos de configuración

Configuración basada en la interfaz de usuario

La interfaz de usuario de Gateway proporciona una interfaz basada en formularios para crear reglas sin escribir YAML:

• Reglas de transformación: Agregue/modifique atributos usando el constructor guiado de sentencias OTTL
• Reglas de descarte: Cree reglas de filtrado basadas en NRQL con generadores de condiciones
• Reglas de tasa de muestreo: Configure los porcentajes de muestreo globales y condicionales con controles deslizantes

La interfaz de usuario genera la configuración YAML en segundo plano y proporciona una vista previa en tiempo real. Consulte la guía de la interfaz de usuario para obtener instrucciones detalladas.

Configuración de YAML

Para usuarios avanzados o flujos de trabajo de infraestructura como código, edite los archivos de configuración YAML directamente:

• Control total sobre el orden de los procesadores y la estructura del pipeline
• Control de versiones con Git
• Despliegue automatizado mediante CI/CD
• Acceso a funciones avanzadas de OTTL no expuestas en la interfaz de usuario

Consulte la descripción general de YAML para la referencia de configuración.

Despliegue de configuración

Gateway utiliza un modelo de configuración unificado:

1. Crea un archivo de configuración YAML que define todos los pasos de procesamiento
2. Usted despliega a través de la UI (cargar YAML) en su clúster
3. Gateway aplica la configuración a todos los clústeres de gateway de su organización
4. Todos los clústeres procesan datos de forma idéntica usando las mismas reglas

Gestión de versiones:

• Cada cambio de configuración crea una nueva versión
• Ver el historial de versiones y revertir si es necesario
• La insignia "Necesita despliegue" muestra cambios pendientes

Próximos pasos

Elige tu ruta:

• Configuración visual: Use la UI de Gateway
• Configuración YAML: Aprenda la estructura YAML

O profundice en tipos de procesadores específicos:

• Procesador de transformación - modificar, enriquecer y analizar datos mediante OTTL
• Procesador de filtros - descarte datos no deseados mediante condiciones OTTL
• Procesador de muestreo - reduzca el volumen de datos con muestreo condicional basado en tasas