Collector Processor

Documentación

Sobre el processor, son las acciones que podemos ejecutar cuando recibimos un dato de telemetría. Son opcionales, pero algunos son recomendados. Aquí tenemos una lista de lo que podemos hacer.

En la misma idea de mejorar el rendimiento, aquí tenemos el batch para procesamiento en lote. La configuración por defecto es suficiente para empezar y, si es necesario, hacer ajustes.

Vamos a utilizar el resource processor que se aplica solamente al pipeline de traces para incluir, modificar o eliminar un atributo de recurso en cada uno de los spans recibidos.

Ya hicimos la inclusión de tags en el SDK en esta parte del código.

  const resource = new Resource({
    "team.ownner": "devsecops-team",
    repository: "https://gitlab.com/davidpuziol/opentelemetry-project",
    site: "https://gitlab.com/davidpuziol/opentelemetry-project",
  });

No necesitamos eliminar, solo podríamos haber hecho esto también en el collector o mantener ambos si es necesario. Para nuestro ejemplo, vamos a mantener lo que el SDK hizo, pero incluir uno y eliminar otro creado por el SDK.

#Código...

processors:
  batch: # cuando no ajustamos las opciones estamos utilizando los valores por defecto.
  resource:
    attributes:
    - key: testcollectorstudy
      value: collector_is_good
      action: insert
    - key: repository
      action: delete

#Código...

# Y vamos a usar este processor
# Configuraciones de services
service:
  extensions:
  - health_check
  pipelines:
    traces:
      receivers:
      - otlp
      processors:
      - batch # necesita ser el primero
      - resource # Vamos a incluir aquel atributo
      exporters:
      - otlphttp
    metrics:
      receivers:
      - otlp
      processors:
      - batch # Aquí voy a usar solamente el batch
      exporters:
      - prometheus

Comprobando el Jaeger después de un curl para localhost:8081/todos, podemos ver la inclusión de este atributo.

La tag repository fue eliminada, pero olvidé marcarlo. Hice esto porque tenía valores duplicados.

---

En la misma idea, tenemos el sampler para tomar decisión de lo que debemos o no mantener, pero ahora tenemos más poder si comparado a cuando utilizamos el SDK. Al contrario del SDK, ahora vamos a tomar la decisión de mantener o no la muestra al final del proceso y no al comienzo de él, por eso lo llamamos Tail Sampling.

Vamos a aplicar a nuestro código y eliminar el Head Sampler de nuestro código.

// import { ParentBasedSampler, TraceIdRatioBasedSampler } from "@opentelemetry/sdk-trace-node";
// import { CustomSampler } from './customSampler'

//código..

function start(serviceName: string) {

//código..

 // const sampler = new ParentBasedSampler({
  //   root: new CustomSampler(),
  // });

  const sdk = new NodeSDK({
    resource,
    traceExporter,
    instrumentations,
    // sampler,
  });
}

Solo vamos a mantener la muestra si satisface alguna de las reglas.

# Código...

processors:
  batch:
  resource:
    attributes:
    - key: testcollectorstudy
      value: collector_is_good
      action: insert
  tail_sampling:
    # Tiempo de espera para recibir todos los spans de un trace antes de tomar una decisión de muestreo
    decision_wait: 10s
    # Número máximo de traces que pueden estar en proceso de decisión
    num_traces: 100
    # Indica la expectativa de cuántos nuevos traces llegan por segundo. Esto ayuda al collector a prepararse en recursos. Si no se pasa es 0, lo que significa que no hay expectativa.
    expected_new_traces_per_sec: 10
    decision_cache:
      sampled_cache_size: 100_000 # 100 mil traces
      non_sampled_cache_size: 100_000
    policies:
      [
          {
            name: high_latence,
            type: latency,
            latency: {threshold_ms: 500}
          },
          {
            name: http_error_only,
            type: numeric_attribute,
            numeric_attribute: {http_status_code: key1, min_value: 500, max_value: 599}
          },
      ]
# Código...

service:
  extensions:
  - health_check
  pipelines:
    traces:
      receivers:
      - otlp
      processors:
      # ¡Si olvidas utilizar el proceso nada va a pasar!
      - tail_sampling # Vamos a añadir antes del batch
      - batch
      - resource
    # Código...
# Código...

Vamos entonces a aprovechar los endpoints que tenemos.

curl http://localhost:8081/todos
{"todos":[{"name":"Implementar tracing"},{"name":"Configurar OpenTelemetry"},{"name":"Configurar exporters"},{"name":"Añadir métricas"}],"user":{"username":"David Prata","userId":12345}}%

curl http://localhost:8081/todos\?fail\=1
Internal Server Error

curl http://localhost:8081/todos\?slow\=1
{"todos":[{"name":"Implementar tracing"},{"name":"Configurar OpenTelemetry"},{"name":"Configurar exporters"},{"name":"Añadir métricas"}],"user":{"username":"David Prata","userId":12345}}%

Podemos observar que solamente tenemos en Jaeger las peticiones arriba de 500ms y con error.