Kiểm thử OpenTelemetry Collector: batching, backpressure và mất telemetry

Pipeline observability phải trả lời ba nhóm câu hỏi. Completeness: trong số telemetry item producer tạo, bao nhiêu item đến backend và trường quan trọng có còn nguyên không. Timeliness: độ trễ từ lúc phát sinh đến khi truy vấn được là bao lâu. Resilience: backend chậm, mạng gián đoạn hoặc Collector restart tạo gap, duplicate hay memory pressure như thế nào.

Ngoài ra phải đo tác động lên ứng dụng và host. Exporter timeout hoặc backpressure không nên kéo latency nghiệp vụ vượt SLO. Sampling phải có mục tiêu: giảm volume nhưng vẫn giữ error, high-latency trace và tín hiệu phục vụ incident. Tỷ lệ mẫu cấu hình không tự động bằng tỷ lệ tín hiệu hữu ích được giữ.

Topology tham chiếu gồm workload/SDK, agent Collector nếu có, gateway Collector, load balancer, network impairment point và backend cho traces/metrics/logs. Đặt counter tại từng stage: items produced, accepted, refused, sent, failed, retried, queued và ingested. Backend query cần đối chiếu với run ID và sequence do producer tạo.

Ground truth nên là generator tạo telemetry có số thứ tự, timestamp, signal type, tenant và expected attributes. Đồng thời ghi application transaction để nối trace/log/metric. Không dùng backend làm ground truth duy nhất vì chính nó là đối tượng đo. Đồng hồ cần đồng bộ; nếu không, chỉ đo latency bằng monotonic timing tại cùng thành phần.

Ghi phiên bản SDK/Collector/contrib components, deployment mode, receiver, processor, exporter, OTLP transport, TLS, compression, batch size/timeout, memory limiter, sending queue, retry policy, persistent queue, load balancing, sampling và backend quota. Component trong Collector core và contrib có maturity khác nhau; tính năng phải kiểm tra theo đúng distribution/version.

Traffic profile cần tách signal type và event rate: spans/s, metric points/s, log records/s, bytes/s, attribute count/size, trace width/depth và burst. Một trace lớn có thể gây áp lực khác hàng nghìn trace nhỏ. Cardinality cao ở metrics/log attributes phải được kiểm soát vì có thể làm backend quá tải trước Collector.

Nhóm biến · Cần ghi · Rủi ro nếu bỏ qua Components · receiver/processor/exporter + version · Hành vi khác giữa distribution Buffer · batch, memory limiter, queue, storage · Không giải thích được drop/recovery Transport · OTLP gRPC/HTTP, TLS, compression · Ảnh hưởng throughput và CPU Sampling · head/tail rules, decision wait · Mất trace quan trọng hoặc tăng memory Backend · quota, ingest latency, retention · Nhầm backend loss thành Collector loss Workload · items/s, bytes/s, burst, cardinality · Benchmark không đại diện production

Chạy từng signal riêng ở tải thấp để xác nhận schema, resource attributes, timestamp và end-to-end query. Sau đó tăng tải theo bậc đến mức mục tiêu, không đi thẳng tới overload. Mỗi bậc cần steady state đủ để queue và memory ổn định. Capacity envelope là vùng load mà completeness, timeliness và resource budget cùng đạt tiêu chí.

Tiếp theo chạy traffic mix gần production. CPU, RSS, GC, queue size/capacity, send failure, refused item và backend ingest phải cùng timeline. Collector restart giữa run baseline có thể tạo cold-start hoặc queue replay; ghi riêng thay vì trộn vào số trung bình.

Completeness nên đo theo run ID/sequence ở backend, không chỉ dựa vào exporter success. Duplicate cũng cần tính vì at-least-once delivery và retry có thể tạo bản ghi lặp tùy backend. Timeliness đo từ producer timestamp đến backend queryable time, báo p50/p95/p99 và max.

KPI · Cách đo · Bằng chứng End-to-end completeness · IDs thấy ở backend / IDs tạo · Manifest + backend query Duplicate rate · IDs xuất hiện 1 lần · Query theo run/sequence Ingest latency · Queryable time − produced time · Timestamp đã đồng bộ Queue pressure · queue size/capacity theo thời gian · Collector internal metrics Drop/refusal · refused/failed/dropped theo component · Metrics và logs từng stage Recovery time · Từ backend phục hồi đến queue về nền · Timeline queue/export Resource overhead · CPU/RSS/network so baseline · Host/container metrics Sampling recall · Error/slow traces được giữ · Golden trace labels

Lưu cấu hình đã redacted, internal metrics, Collector logs, backend query và generator manifest. Dashboard screenshot chỉ minh họa; raw series/query mới là evidence có thể chạy lại.

Backend slowdown, hard failure và network partition tạo hành vi khác nhau. Thêm cả DNS/TLS error, quota 429/RESOURCEEXHAUSTED, partial rejection, Collector restart và disk full nếu dùng persistent queue. Mỗi fault có duration, trigger và expected policy.

Kịch bản · Điều cần quan sát · Rủi ro Backend latency tăng · Queue, timeout, app impact · Queue đầy âm thầm Backend trả quota error · Retry/backoff, refusal · Retry storm Network gián đoạn · Buffer và recovery · Hết TTL/disk Collector restart · Persistent queue/replay · Gap hoặc duplicate Memory pressure · Memory limiter/refusal · OOM kill Disk full · Queue error/fallback · Mất telemetry không cảnh báo Tail sampling burst · Decision buffer và recall · Mất trace slow/error Config reload · Continuity và schema · Khoảng trống hoặc route sai

Không chạy cardinality explosion hoặc disk-fill test trên production. Với partial failure, exporter success tổng quát có thể che item bị từ chối; cần đọc response và internal metrics đúng component.

• Lưu inventory component/version, cấu hình, resource limit và backend quota.
• Xác nhận time sync, run ID, sequence và query đối chiếu.
• Chạy traces, metrics, logs riêng ở tải thấp; kiểm tra schema/fidelity.
• Tăng tải theo bậc; xác định capacity envelope và queue steady state.
• Chạy traffic mix, burst và high-cardinality profile trong giới hạn an toàn.
• Chèn backend latency/quota/network fault từng loại; đo fill/drop/retry.
• Restart Collector có/không persistent queue; đo gap và duplicate.
• Tạo memory/disk pressure trong lab; xác minh alert và fail behavior.
• Kiểm tra sampling bằng golden error/slow traces.
• Phục hồi, chờ queue drain, query toàn bộ ID và báo worst case.

Collector pass ở một backend không chứng minh với backend khác, vì protocol implementation, quota và semantics duplicate khác nhau. Kết quả traces không suy rộng sang metrics/logs. Một dashboard đầy đủ không chứng minh field fidelity hoặc không có duplicate.

OpenTelemetry specification mô tả data model/protocol, còn durability và behavior phụ thuộc Collector distribution, component maturity, configuration và backend. Kết luận chỉ áp dụng cho version, topology, resource limit, traffic profile và fault duration đã ghi.

• OTLP: OpenTelemetry Protocol dùng vận chuyển traces, metrics và logs.
• Collector: Thành phần nhận, xử lý và xuất telemetry qua pipeline.
• Receiver/processor/exporter: Ba nhóm component chính của pipeline.
• Batching: Gom item trước khi gửi để tăng hiệu quả nhưng có thể thêm latency.
• Backpressure: Áp lực ngược khi downstream chậm hơn upstream.
• Sending queue: Hàng đợi trước exporter, có giới hạn và policy cụ thể.
• Head/tail sampling: Quyết định lấy mẫu trước hoặc sau khi có thêm thông tin trace.
• Cardinality: Số lượng tổ hợp label/attribute khác nhau, ảnh hưởng tài nguyên mạnh.