Procesador de muestreo

El procesador de muestreo implementa un muestreo probabilístico para reducir el volumen de datos mientras preserva la señal. Utilícelo para conservar todos los errores y las solicitudes lentas, mientras muestrea agresivamente los casos de éxito rutinarios, reduciendo costos sin perder valor de diagnóstico.

Cuándo usar el procesador de muestreo

El procesador de muestreo admite diferentes capacidades según el tipo de datos de telemetría:

Para logs y eventos

Logs y Eventos admiten muestreo condicional con reglas personalizables basadas en la gravedad, los atributos y otros criterios:

Conserve el 100% de los errores mientras muestrea los casos de éxito: Preserve todos los datos de diagnóstico, descarte el tráfico de rutina
Muestree los servicios de alto volumen más agresivamente: Diferentes tasas de muestreo por nivel de servicio o importancia
Conserve las solicitudes lentas mientras muestrea las rápidas: Mantenga los valores atípicos de rendimiento para su análisis
Aplique diferentes tasas de muestreo por entorno o servicio: Producción al 10%, staging al 50%, pruebas al 100%

Para trazas

Las trazas admiten solo muestreo global basado en tasas. Reduzca el volumen general de trazas con una tasa de muestreo uniforme.

Para métricas

El muestreo de métricas actualmente no es compatible con el procesador de muestreo. En su lugar, utilice el procesador de filtros para descartar métricas no deseadas.

Cómo funciona el muestreo

El procesador de muestreo utiliza muestreo probabilístico con reglas condicionales:

Porcentaje de muestreo predeterminado: Tasa predeterminada aplicada a todos los datos que no coinciden con las reglas condicionales.
Reglas: Sobrescribe la tasa predeterminada cuando se cumplen condiciones específicas.
Fuente de aleatoriedad: un campo consistente (como trace_id) garantiza que los datos relacionados se muestreen juntos.

Orden de evaluación: Las reglas se evalúan en el orden definido. La primera regla de coincidencia determina la tasa de muestreo. Si ninguna regla coincide, se aplica el porcentaje de muestreo predeterminado.

Configuración

Agregue un procesador de muestreo a su pipeline:

probabilistic_sampler/Logs:
        description: Probabilistic sampling for all logs
        config:
          default_sampling_percentage: 100
          rules:
            - 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
              conditions:
                - resource.attributes["service.name"] == "ruby-test-service"

Campos de configuración:

default_sampling_percentage: Tasa de muestreo predeterminada (0-100) para datos que no coinciden con las reglas.
rules: Matriz de reglas (evaluadas en orden) - solo admitida para logs y eventos.
- name: Identificador de regla.
- description: Descripción legible por humanos.
- sampling_percentage: Tasa de muestreo para datos coincidentes (0-100).
- source_of_randomness: Campo que se usará para la decisión de muestreo (típicamente trace_id).
- conditions: Lista de expresiones OTTL para coincidir con la telemetría.

Estrategias de muestreo

Conserve los datos valiosos, descarte el tráfico de rutina

El patrón más común para logs y eventos: conservar todos los datos de diagnóstico (errores, solicitudes lentas), muestrear agresivamente los casos de éxito rutinarios.

probabilistic_sampler/Logs:
  description: "Intelligent log sampling"
  config:
    default_sampling_percentage: 5  # Sample 5% of everything else
    rules:
      - name: "preserve-errors"
        description: "Keep all errors and fatals"
        sampling_percentage: 100
        source_of_randomness: "trace.id"
        conditions: 
          - 'severity_text == "ERROR" or severity_text == "FATAL"'

      - name: "preserve-warnings"
        description: "Keep most warnings"
        sampling_percentage: 50
        source_of_randomness: "trace.id"
        conditions: 
          - 'severity_text == "WARN"'

Resultado: 100% de los errores + 50% de las advertencias + 5% de todo lo demás

Muestra por nivel de servicio

Diferentes tasas de muestreo para distinta importancia del servicio:

probabilistic_sampler/Logs:
  description: "Service tier sampling"
  config:
    default_sampling_percentage: 10
    rules:
      - name: "critical-services"
        description: "Keep most traces from critical services"
        sampling_percentage: 80
        source_of_randomness: "trace.id"
        conditions: 
          - 'resource.attributes["service.name"] == "checkout" or resource.attributes["service.name"] == "payment"'

      - name: "standard-services"
        description: "Medium sampling for standard services"
        sampling_percentage: 30
        source_of_randomness: "trace.id"
        conditions: 
          - 'resource.attributes["service.tier"] == "standard"'

Muestra por ambiente

Mayor muestreo en entornos de prueba, menor en producción:

probabilistic_sampler/Logs:
  description: "Environment-based sampling"
  config:
    default_sampling_percentage: 10  # Production default
    rules:
      - name: "test-environment"
        description: "Keep all test data"
        sampling_percentage: 100
        source_of_randomness: "trace.id"
        conditions: 
          - 'resource.attributes["environment"] == "test"'

      - name: "staging-environment"
        description: "Keep half of staging data"
        sampling_percentage: 50
        source_of_randomness: "trace.id"
        conditions: 
          - 'resource.attributes["environment"] == "staging"'

Conservar solicitudes lentas

Conserve los valores atípicos de rendimiento para su análisis:

probabilistic_sampler/Logs:
  description: "Preserve important logs"
  config:
    default_sampling_percentage: 1  # Sample 1% of routine logs
    rules:
      - name: "critical-logs"
        description: "Keep all error and fatal logs"
        sampling_percentage: 100
        source_of_randomness: "trace.id"
        conditions: 
          - 'severity_text == "ERROR" or severity_text == "FATAL"'

      - name: "warning-logs"
        description: "Keep half of warning logs"
        sampling_percentage: 50
        source_of_randomness: "trace.id"
        conditions: 
          - 'severity_text == "WARN"'
      
      - name: "traced-logs"
        description: "Keep logs with trace context"
        sampling_percentage: 50
        source_of_randomness: "trace.id"
        conditions: 
          - 'trace_id != nil and trace_id.string != "00000000000000000000000000000000"'

Nota: La duración es en nanosegundos (1 segundo = 1,000,000,000 ns).

Ejemplos completos

Ejemplo 1: Muestreo inteligente de trazas para rastreo distribuido

Para las trazas, solo puede configurar el porcentaje de muestreo predeterminado. Este porcentaje se aplica a todas las trazas uniformemente, incluidas las trazas de error y las trazas lentas:

probabilistic_sampler/Traces:
  description: Probabilistic sampling for traces
  config:
    default_sampling_percentage: 55

Ejemplo 2: Reducción del volumen de logs

Reduzca drásticamente el volumen de logs mientras conserva los datos de diagnóstico:

probabilistic_sampler/Logs:
  description: "Aggressive log sampling, preserve errors"
  config:
    default_sampling_percentage: 2  # Keep 2% of routine logs
    rules:
      - name: "keep-errors-fatals"
        description: "Keep all errors and fatals"
        sampling_percentage: 100
        source_of_randomness: "trace.id"
        conditions: 
          - 'severity_number >= 17'  # ERROR and above

      - name: "keep-some-warnings"
        description: "Keep 25% of warnings"
        sampling_percentage: 25
        source_of_randomness: "trace.id"
        conditions: 
          - 'severity_number >= 13 and severity_number < 17'  # WARN

Ejemplo 3: Muestra por código de estado HTTP

Muestrear todas las fallas (100%) y una fracción de los éxitos (5%):

probabilistic_sampler/Logs:
  description: "Sample by HTTP response status"
  config:
    default_sampling_percentage: 5  # 5% of successes
    rules:
      - name: "keep-server-errors"
        description: "Keep all 5xx errors"
        sampling_percentage: 100
        source_of_randomness: "trace.id"
        conditions: 
          - 'attributes["http.status_code"] >= 500'

      - name: "keep-client-errors"
        description: "Keep all 4xx errors"
        sampling_percentage: 100
        source_of_randomness: "trace.id"
        conditions: 
          - 'attributes["http.status_code"] >= 400 and attributes["http.status_code"] < 500'

Ejemplo 4: Muestreo de servicios multinivel

Diferentes tasas para diferentes niveles de importancia:

probabilistic_sampler/Logs:
  description: "Business criticality sampling"
  config:
    default_sampling_percentage: 1
    rules:
      # Critical business services: keep 80%
      - name: "critical-services"
        description: "High sampling for critical services"
        sampling_percentage: 80
        source_of_randomness: "trace.id"
        conditions: 
          - 'attributes["business_criticality"] == "critical"'

      # Important services: keep 40%
      - name: "important-services"
        description: "Medium sampling for important services"
        sampling_percentage: 40
        source_of_randomness: "trace.id"
        conditions: 
          - 'attributes["business_criticality"] == "important"'

      # Standard services: keep 10%
      - name: "standard-services"
        description: "Low sampling for standard services"
        sampling_percentage: 10
        source_of_randomness: "trace.id"
        conditions: 
          - 'attributes["business_criticality"] == "standard"'

Ejemplo 5: Muestreo basado en tiempo (reducción fuera de horas pico)

Mayor muestreo durante el horario laboral (requiere etiquetado de atributos externos):

probabilistic_sampler/Logs:
  description: "Time-based sampling (requires time attribute)"
  config:
    default_sampling_percentage: 5  # Off-peak default
    rules:
      - name: "business-hours"
        description: "Higher sampling during business hours"
        sampling_percentage: 50
        source_of_randomness: "trace.id"
        conditions: 
          - 'attributes["is_business_hours"] == true'

Ejemplo 6: Muestrear por patrón de endpoint

Conservar todos los endpoints de administración, muestrear agresivamente la API pública:

probabilistic_sampler/Logs:
  description: "Endpoint-based sampling"
  config:
    default_sampling_percentage: 10
    rules:
      - name: "admin-endpoints"
        description: "Keep all admin traffic"
        sampling_percentage: 100
        source_of_randomness: "trace.id"
        conditions: 
          - 'IsMatch(attributes["http.path"], "^/admin/.*")'

      - name: "api-endpoints"
        description: "Sample public API"
        sampling_percentage: 5
        source_of_randomness: "trace.id"
        conditions: 
          - 'IsMatch(attributes["http.path"], "^/api/.*")'

Fuente de aleatoriedad

El campo source_of_randomness determina qué atributo se utiliza para tomar decisiones de muestreo consistentes.

Valores comunes:

trace_id: Para trazas distribuidas (garantiza que todos los spans de una traza se muestreen juntos)
span_id: Para el muestreo de spans individuales (no recomendado para el rastreo distribuido)
Atributo personalizado: Cualquier atributo que proporcione aleatoriedad

Por qué es importante: Usar trace_id asegura que, al muestrear una traza, obtenga TODOS los spans de esa traza, no solo spans individuales aleatorios. Esto es fundamental para comprender las transacciones distribuidas.

Consideraciones de rendimiento

Ordene las reglas por frecuencia: Coloque primero las condiciones que coinciden con mayor frecuencia para reducir el tiempo de evaluación
Rendimiento de la fuente de aleatoriedad: Usar trace_id es muy eficiente ya que ya está disponible
El muestreo ocurre después de otros procesadores: Coloque el muestreo cerca del final de su pipeline para evitar desperdiciar CPU en datos que serán descartados

Ordenamiento eficiente de pipelines:

steps:
      # ... receive steps...
      probabilistic_sampler/Logs:
        description: Probabilistic sampling for all logs
        output:
          - filter/Logs
        config:
          rules:
            - 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
              conditions:
                - resource.attributes["service.name"] == "ruby-test-service"
          default_sampling_percentage: 100
      probabilistic_sampler/Traces:
        description: Probabilistic sampling for traces
        output:
          - filter/Traces
        config:
          default_sampling_percentage: 100
      filter/Logs:
        description: Apply drop rules and data processing for logs
        output:
          - transform/Logs
        config:
          error_mode: ignore
          rules:
            - name: drop the log records
              description: drop all records which has severity text INFO
              conditions:
                - log.severity_text == "INFO"
              context: log
      # ... filter steps ...
      # ... transdormer steps ...

Ejemplos de impacto en el costo

Ejemplo: 1TB/día → 100GB/día

Antes del muestreo:

1 TB de logs por día
El 90% son operaciones de rutina de nivel INFO
El 8% son WARN
2% son ERROR/FATAL

Con muestreo inteligente:

probabilistic_sampler/Logs:
  description: "Sample logs by severity level"
  config:
    default_sampling_percentage: 2  # Sample 2% of INFO and below
    rules:
      - name: "errors"
        description: "Keep all error logs"
        sampling_percentage: 100  # Keep 100% of errors
        source_of_randomness: "trace.id"
        conditions: 
          - 'severity_number >= 17'
      
      - name: "warnings"
        description: "Keep quarter of warning logs"
        sampling_percentage: 25  # Keep 25% of warnings
        source_of_randomness: "trace.id"
        conditions: 
          - 'severity_number >= 13 and severity_number < 17'

Después del muestreo:

INFO: 900GB × 2% = 18GB
ADVERTENCIA: 80GB × 25% = 20GB
ERROR/FATAL: 20GB × 100% = 20GB
Total: -58 GB/día (reducción del 94%)
Todos los errores conservados para la solución de problemas

Recursos de OpenTelemetry

Próximos pasos

Obtenga más información sobre el procesador de transformación para el enriquecimiento de datos antes del muestreo
Consulte Filter processor para descartar datos no deseados
Consulte la referencia de configuración YAML para la sintaxis completa

Te ofrecemos esta traducción automática para facilitar la lectura.

Cuándo usar el procesador de muestreo.css-21sua1{background:none;border:none;width:0;padding:0;}