Las aplicaciones que usan un SDK de OpenTelemetry envían su propia telemetría, pero gran parte de lo que necesitas observar no lo hace: archivos de log, recursos del host, el kubelet y servicios que ya exponen métricas de Prometheus. El Collector los incorpora mediante receivers. Esta guía muestra los más útiles, todos como configuración. Los nombres de las opciones de los componentes cambian entre versiones, así que consulta el README de cada receiver para la versión que ejecutes. Todos están en las distribuciones contrib y Kubernetes.

Archivos de log con filelog

El receiver filelog sigue archivos y convierte las líneas en registros de log.

receivers:
  filelog:
    include:
      - /var/log/myapp/*.log
    exclude:
      - /var/log/myapp/*.gz
    start_at: end            # o "beginning" para leer el contenido existente
    include_file_path: true
    operators:
      - type: json_parser
        timestamp:
          parse_from: attributes.time
          layout: '%Y-%m-%dT%H:%M:%S.%LZ'
        severity:
          parse_from: attributes.level

Los operators forman un pequeño pipeline de análisis que se ejecuta sobre cada entrada. Los comunes son json_parser, regex_parser, move, add, remove y recombine (para volver a unir en un solo registro los stack traces de varias líneas). Un ejemplo multilínea:

    operators:
      - type: recombine
        combine_field: body
        is_first_entry: body matches "^\\d{4}-\\d{2}-\\d{2}"
        source_identifier: attributes["log.file.path"]

Para sobrevivir a los reinicios sin releer ni omitir datos, dale al receiver una extensión de almacenamiento:

extensions:
  file_storage:
    directory: /var/lib/otelcol/storage

receivers:
  filelog:
    include: [/var/log/myapp/*.log]
    storage: file_storage

service:
  extensions: [file_storage]

En Kubernetes, los logs de los contenedores viven bajo /var/log/pods/*/*/*.log. El preset logsCollection del chart de Helm configura este receiver, monta la ruta del host y analiza el formato del runtime de contenedores por ti, así que prefiérelo a escribir el receiver a mano.

Métricas de host con hostmetrics

En una VM o un nodo, el receiver hostmetrics lee cifras de CPU, memoria, disco, sistema de archivos y red desde el sistema operativo:

receivers:
  hostmetrics:
    collection_interval: 30s
    scrapers:
      cpu:
      memory:
      load:
      disk:
      filesystem:
        exclude_mount_points:
          mount_points: [/dev/*, /proc/*, /sys/*, /run/*]
          match_type: regexp
      network:
      paging:

Ejecútalo en un agente en cada host. En un contenedor, informa de la vista del contenedor a menos que montes el sistema de archivos del host y definas root_path, así que consulta el README del receiver antes de depender de ello allí. Añade el processor resourcedetection para etiquetar las métricas con detalles de host, nube o Kubernetes:

processors:
  resourcedetection:
    detectors: [env, system]
    timeout: 5s
    override: false

Métricas de Kubernetes

El uso de recursos de nodos y pods viene del kubelet a través de kubeletstats, ejecutado como DaemonSet:

receivers:
  kubeletstats:
    collection_interval: 30s
    auth_type: serviceAccount
    endpoint: ${env:K8S_NODE_NAME}:10250
    insecure_skip_verify: true
    metric_groups: [node, pod, container]

Pasa el nombre del nodo mediante la downward API:

env:
  - name: K8S_NODE_NAME
    valueFrom:
      fieldRef:
        fieldPath: spec.nodeName

insecure_skip_verify es común porque los certificados del kubelet suelen ser autofirmados; usa una configuración de CA adecuada donde puedas. La service account necesita permiso para leer nodes/stats, que concede el preset de Helm.

El estado a nivel de clúster (réplicas de deployments, fase de los pods, condiciones de nodos) viene del receiver k8s_cluster, y los eventos de Kubernetes de k8sobjects. Ejecuta ambos una sola vez por clúster, en un Deployment de una sola réplica, o recopilarás duplicados. Ambos están disponibles como presets de Helm (clusterMetrics y kubernetesEvents).

Recopila endpoints de Prometheus

El receiver prometheus acepta una configuración de scrape estándar de Prometheus, así que los targets existentes se trasladan sin reescribirlos:

receivers:
  prometheus:
    config:
      scrape_configs:
        - job_name: node-exporter
          scrape_interval: 30s
          static_configs:
            - targets: ["node-exporter:9100"]
        - job_name: kubernetes-pods
          kubernetes_sd_configs:
            - role: pod
          relabel_configs:
            - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
              action: keep
              regex: "true"

Dos trampas: en una configuración del Collector, escribe un signo de dólar literal en una regex o reemplazo de Prometheus como $$, porque de lo contrario el Collector intenta expandirlo como una variable; y si ejecutas varias réplicas que recopilan los mismos targets, tendrás duplicados. El Target Allocator del OpenTelemetry Operator existe para repartir los targets entre las réplicas del Collector, igual que ejecutar una sola réplica de scraping.

Muchos receivers, un pipeline

Los receivers alimentan pipelines del mismo tipo de señal:

service:
  pipelines:
    metrics:
      receivers: [otlp, hostmetrics, kubeletstats, prometheus]
      processors: [memory_limiter, resourcedetection, batch]
      exporters: [otlphttp/prometheus]
    logs:
      receivers: [otlp, filelog]
      processors: [memory_limiter, batch]
      exporters: [otlphttp/loki]

También puedes dividir en varios pipelines por señal (metrics/infra, metrics/apps) para aplicar distintos processors a cada origen.

Métricas a partir de trazas con el connector spanmetrics

Si tus servicios emiten trazas pero no métricas de peticiones, el connector spanmetrics deriva recuentos de peticiones, recuentos de errores e histogramas de latencia a partir de los spans. Un connector es un exporter en un pipeline y un receiver en otro:

connectors:
  spanmetrics:
    histogram:
      explicit:
        buckets: [10ms, 50ms, 100ms, 250ms, 500ms, 1s, 2.5s, 5s]
    dimensions:
      - name: http.request.method
      - name: http.response.status_code

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp/tempo, spanmetrics]
    metrics/spanmetrics:
      receivers: [spanmetrics]
      processors: [batch]
      exporters: [otlphttp/prometheus]

Cada dimensión multiplica el número de series temporales, así que añade solo atributos con un conjunto pequeño y acotado de valores. Nunca uses IDs de usuario ni URLs con identificadores. Pon el connector antes de cualquier muestreo para que los números reflejen todo el tráfico (consulta la guía de muestreo).

Verifica

Añade el exporter debug con verbosity: detailed a una copia del pipeline y ejecuta el Collector en primer plano. Deberías ver registros de log con la severidad analizada, o nombres de métricas como system.cpu.time, k8s.pod.cpu.usage o traces.span.metrics.calls (el nombre puede diferir según la versión). Si no aparece nada, comprueba los permisos de archivo de filelog, la variable del nombre del nodo de kubeletstats y que cada receiver esté listado en un pipeline.