跳到主要内容
返回文章列表

OpenTelemetry Collector: รับ Trace, Metric และ Log ผ่าน Pipeline เดียว

เข้าใจ receiver, processor และ exporter ของ OpenTelemetry Collector พร้อมตัวอย่างทดสอบเส้นทางข้อมูลก่อนส่งเข้า backend จริง

OpenTelemetry Collector: รับ Trace, Metric และ Log ผ่าน Pipeline เดียว

เมื่อแอปส่ง trace ไปที่หนึ่ง metric ไปอีกที่หนึ่ง และ log ไปอีกระบบ ทีมมักแก้เรื่อง endpoint, credential และการกรองข้อมูลซ้ำหลายจุด OpenTelemetry Collector เป็นบริการกลางที่รับ telemetry ประมวลผล แล้วส่งไป backend ที่เลือกได้ บทความนี้เริ่มจากเส้นทางเล็กที่ดูผลได้ในเครื่อง ก่อนขยายไป production

แยกส่วนประกอบของ pipeline

receiver รับข้อมูล เช่น OTLP จากแอป; processor จัดชุดหรือปรับข้อมูล; exporter ส่งผลไปปลายทาง แต่ละส่วนจะทำงานต่อเมื่อถูกอ้างใน service.pipelines ด้วย ดังนั้นการประกาศ component ไว้เฉย ๆ ไม่ได้แปลว่ามีข้อมูลไหลผ่าน ควรแยก pipeline ของ traces, metrics และ logs เพราะชนิดข้อมูลและปลายทางอาจต่างกัน

ตัวอย่างทดลอง trace แบบสั้นให้แอปส่ง OTLP ไปที่ Collector แล้วใช้ debug exporter แสดงผลก่อน:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 127.0.0.1:4317
processors:
  batch: {}
exporters:
  debug:
    verbosity: detailed
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug]

ตัวอย่างนี้ผูกพอร์ตกับ loopback เพื่อทดลองในเครื่องเดียว หากแอปอยู่คนละคอนเทนเนอร์ต้องเปลี่ยน endpoint และควบคุมเครือข่ายให้เหมาะสม อย่าเปิดพอร์ตรับ telemetry สู่สาธารณะโดยไม่มีการยืนยันตัวตนหรือข้อจำกัดเครือข่าย

ตรวจเส้นทางข้อมูลทีละช่วง

ส่งคำขอหนึ่งครั้งที่รู้เวลาและชื่อ service จากแอป แล้วดูว่า span เข้าถึง debug exporter หรือไม่ ถ้าไม่ถึง ให้ตรวจ endpoint, protocol, firewall และค่าของ SDK ก่อนปรับ backend เมื่อเห็น trace แล้วจึงสลับ exporter ไปยังปลายทางจริง และตรวจ trace ID เดียวกันที่ระบบค้นหา อย่าดูแค่สถานะ process ของ Collector เพราะ process ยังทำงานได้แม้ exporter ส่งข้อมูลไม่สำเร็จ

สำหรับ metrics และ logs ให้เพิ่ม pipeline แยกและตรวจจำนวนรายการเข้าออก รวมถึงอัตราที่ถูก drop หรือ retry เปิด internal telemetry ของ Collector เพื่อดู queue, export failure และภาระหน่วยความจำ หากใช้ processor ลบ attribute ส่วนบุคคล ให้ทดสอบทั้งข้อมูลปกติและข้อมูลที่ไม่ควรออกจากระบบ

ก่อนวางใน production

กำหนดขีดจำกัดหน่วยความจำและการส่งซ้ำตามโหลดจริง แยกสิทธิ์ของ Collector ที่รับข้อมูลจากสิทธิ์ที่เขียนลง backend ทดสอบปลายทางล่มชั่วคราวว่าข้อมูลค้างหรือสูญหายเท่าไร แล้วระบุเป้าหมายที่รับได้ การมี Collector เพิ่มความยืดหยุ่น แต่ก็เพิ่มจุดที่ต้องดูแลและอัปเกรดเอง

อ่านเพิ่มเติม: Quick start ของ Collector, ส่วนประกอบ, ภาพรวม