OpenTelemetry (OTel)

ถ้าจะจำเทคโนโลยีเดียวจากหลักสูตรนี้ที่จะสำคัญที่สุดในอีก 5 ปีข้างหน้า — ให้จำ OpenTelemetry มันคือมาตรฐานกลางที่กำลังรวมโลก observability ให้เป็นหนึ่งเดียว

ปัญหาที่ OTel มาแก้

ก่อนมี OTel โลก observability วุ่นวายมาก:

อยากได้ metrics → ใช้ Prometheus client library
อยากได้ traces  → ใช้ Jaeger client / Zipkin client
อยากได้ logs    → ใช้ logging library อีกตัว

เปลี่ยน vendor (เช่นย้ายจาก Jaeger ไป Datadog)?
→ ต้องรื้อ instrument ในโค้ดทั้งหมดใหม่ 😱  (vendor lock-in)

แต่ละเจ้ามี SDK, format, protocol ของตัวเอง ทำงานซ้ำซ้อน และผูกติดกับ vendor

OTel คือคำตอบ: instrument ครั้งเดียว ส่งไปไหนก็ได้

OpenTelemetry = มาตรฐานกลาง (open standard) + ชุดเครื่องมือสำหรับสร้างและส่ง telemetry ทั้ง 3 ชนิด (metrics, logs, traces) ด้วย API/SDK เดียว แล้ว export ไปยัง backend อะไรก็ได้ (Prometheus, Jaeger, Tempo, Datadog, ...) โดยไม่ต้องแก้โค้ด — เป็นโปรเจกต์ CNCF ที่ active เป็นอันดับต้นๆ

             ┌─── export ──▶ Prometheus (metrics)
โค้ดคุณ       │
+ OTel SDK ──┼─── export ──▶ Jaeger / Tempo (traces)
(instrument  │
 ครั้งเดียว)  └─── export ──▶ Loki / ELK (logs)

เปลี่ยน backend = แก้แค่ config ปลายทาง ไม่แตะโค้ด ✅

ส่วนประกอบหลักของ OTel

ส่วน	หน้าที่
API	interface สำหรับสร้าง span/metric ในโค้ด (ไม่ผูก implementation)
SDK	ตัว implement จริง — จัดการ sampling, batching, การ export
Instrumentation libraries	auto-instrument framework ยอดนิยม (Express, HTTP, DB) โดยแทบไม่ต้องเขียนเอง
Collector	ตัวกลางรับ telemetry → process → ส่งต่อหลาย backend
OTLP	OpenTelemetry Protocol — format มาตรฐานที่ทุกส่วนใช้คุยกัน

OTel Collector — พระเอกที่ควรรู้จัก

Collector คือ service กลางที่รับ telemetry จากแอป แล้วจัดการก่อนส่งต่อ — มี 3 ส่วน:

receivers  →  processors  →  exporters
(รับเข้า)      (แปลง/กรอง)     (ส่งออก)

รับ OTLP     batch, sample,   ส่งไป Jaeger,
จากแอป       ลบ PII, เพิ่ม     Prometheus,
             attribute        Tempo, ฯลฯ

ข้อดีของการมี Collector คั่นกลาง:

• แอปไม่ต้องรู้จัก backend — แอปส่ง OTLP ไป Collector จบ เปลี่ยน backend แก้ที่ Collector ที่เดียว
• จัดการ sampling/batching รวมศูนย์ — ลดภาระแอป
• กรอง/แปลงข้อมูล — เช่นลบ PII ก่อนออกนอกระบบ (บทที่ 30)

pattern ที่นิยม: แอปทุกตัวส่ง OTLP → Collector ตัวเดียว → fan-out ไป Prometheus (metrics) + Jaeger/Tempo (traces) + Loki (logs) นี่คือสถาปัตยกรรม observability สมัยใหม่ที่รวมทุกอย่างเข้าจุดเดียว

Auto-instrumentation — เริ่มได้แทบไม่ต้องเขียนโค้ด

จุดขายใหญ่: OTel auto-instrument framework ดังๆ ให้ ตัวอย่าง Node.js — แค่ import ตัว SDK ก่อนแอปเริ่ม ก็ได้ trace ของทุก HTTP request + query DB อัตโนมัติ:

// tracing.js — โหลดก่อนโค้ดแอป (node -r ./tracing.js app.js)
const { NodeSDK } = require("@opentelemetry/sdk-node");
const { getNodeAutoInstrumentations } = require("@opentelemetry/auto-instrumentations-node");
const { OTLPTraceExporter } = require("@opentelemetry/exporter-trace-otlp-http");

const sdk = new NodeSDK({
  serviceName: "order-service",
  traceExporter: new OTLPTraceExporter({ url: "http://collector:4318/v1/traces" }),
  instrumentations: [getNodeAutoInstrumentations()], // auto! จับ express, http, pg, ...
});
sdk.start();

เท่านี้ทุก request ที่ผ่าน Express + query ผ่าน pg จะมี span อัตโนมัติ พร้อม context propagation (W3C traceparent จากบทที่ 40) ให้ครบ — เราจะใช้แนวนี้ใน lab ถัดไป

Manual instrumentation ก็ทำได้เมื่อต้องการ span ของ business logic เฉพาะ (เช่น "คำนวณราคา", "เรียก external API") — เขียน tracer.startSpan(...) เอง ใช้คู่กับ auto ได้

ทำไม OTel = อนาคต

• Vendor-neutral — ไม่ผูกกับเจ้าใดเจ้าหนึ่ง ย้าย backend ได้อิสระ
• รวม 3 เสา — API เดียวได้ทั้ง metrics/logs/traces + correlate กันง่าย (บทที่ 50)
• มาตรฐานอุตสาหกรรม — ทุก vendor ใหญ่ (Datadog, New Relic, Grafana, AWS) รองรับ OTLP หมดแล้ว
• Prometheus ก็รับ OTLP ได้แล้ว — โลกกำลัง converge มาที่มาตรฐานนี้

สรุป

• OpenTelemetry = มาตรฐานกลาง instrument ครั้งเดียว ได้ทั้ง 3 เสา ส่งไป backend ไหนก็ได้ (ไม่ vendor lock-in)
• ส่วนประกอบ: API + SDK + auto-instrumentation + Collector + protocol OTLP
• Collector (receivers → processors → exporters) เป็นตัวกลาง fan-out ไปหลาย backend
• Auto-instrumentation ได้ trace ของ HTTP/DB อัตโนมัติแทบไม่ต้องเขียนโค้ด
• เป็นทิศทางอนาคตของทั้งวงการ — คุ้มมากที่จะลงทุนเรียน

พอแล้วทฤษฎี — ไป Lab: OpenTelemetry + Jaeger ดู trace แบบ waterfall ข้าม service จริง!