#OpenTelemetry คืออะไร? คู่มือ Observability สำหรับระบบสมัยใหม่

ระบบซอฟต์แวร์ในปัจจุบันไม่ได้ประกอบด้วย Web Application และ Database เพียงสองส่วน แต่มีองค์ประกอบจำนวนมาก เช่น API Gateway, Microservices, Cache, Message Queue, Background Jobs, Container, Kubernetes และบริการ Cloud

เมื่อระบบเกิดปัญหา การตรวจสอบจาก Log เพียงอย่างเดียวอาจไม่สามารถตอบคำถามสำคัญได้ เช่น

  • Request นี้เดินทางผ่าน Service ใดบ้าง
  • Service ใดตอบสนองช้าที่สุด
  • Database Query ใดใช้เวลานาน
  • External API ใดเกิด Timeout
  • Queue Job ล้มเหลวในขั้นตอนใด
  • Error ที่พบสัมพันธ์กับ Request ใด
  • ปัญหาเริ่มขึ้นหลังจาก Deployment เวอร์ชันใด

OpenTelemetry หรือเรียกสั้น ๆ ว่า OTel จึงเข้ามาช่วยสร้างมาตรฐานสำหรับการเก็บและส่งข้อมูลจากระบบ เพื่อให้ทีมพัฒนาและทีมปฏิบัติการสามารถวิเคราะห์พฤติกรรม ประสิทธิภาพ และข้อผิดพลาดของแอปพลิเคชันได้อย่างเป็นระบบ

#OpenTelemetry คืออะไร

OpenTelemetry คือชุดมาตรฐาน เครื่องมือ API และ SDK แบบ Open Source สำหรับดำเนินการกับข้อมูล Telemetry ของระบบ โดยครอบคลุมกระบวนการสำคัญ ได้แก่

  1. การสร้างข้อมูล Telemetry
  2. การเก็บรวบรวมข้อมูล
  3. การประมวลผลข้อมูล
  4. การส่งข้อมูลไปยังระบบปลายทาง

ข้อมูล Telemetry ที่สำคัญประกอบด้วย

  • Traces — แสดงเส้นทางการทำงานของ Request
  • Metrics — แสดงค่าตัวเลขและแนวโน้มของระบบ
  • Logs — บันทึกเหตุการณ์และข้อผิดพลาด
  • Baggage — Context ที่ส่งต่อระหว่าง Service

คุณสมบัติสำคัญของ OpenTelemetry คือเป็น Vendor-neutral หมายความว่า Application ไม่จำเป็นต้องผูกติดกับผู้ให้บริการ Observability รายใดรายหนึ่ง

ข้อมูลที่สร้างด้วย OpenTelemetry สามารถส่งไปยังระบบปลายทางได้หลายประเภท เช่น

  • Prometheus
  • Grafana
  • Jaeger
  • Grafana Tempo
  • Grafana Loki
  • Elasticsearch
  • ระบบ Observability บน Cloud
  • แพลตฟอร์ม Observability เชิงพาณิชย์

อย่างไรก็ตาม OpenTelemetry ไม่ใช่ระบบ Dashboard และไม่ใช่ฐานข้อมูลสำหรับจัดเก็บ Telemetry โดยตรง แต่ทำหน้าที่เป็นมาตรฐานกลางสำหรับสร้าง เก็บ ประมวลผล และส่งข้อมูลไปยัง Observability Backend

#Observability คืออะไร

Observability คือความสามารถในการทำความเข้าใจสถานะภายในของระบบจากข้อมูลที่ระบบส่งออกมา

ระบบที่มี Observability ที่ดีช่วยให้ทีมสามารถตอบคำถามเกี่ยวกับระบบได้โดยไม่จำเป็นต้องแก้ไข Source Code หรือเพิ่ม Log ใหม่ทุกครั้งที่เกิดปัญหา

Observability ช่วยตอบคำถาม เช่น

  • API Endpoint ใดมี Error Rate สูง
  • Request ใช้เวลานานในขั้นตอนใด
  • Service ใดเป็นคอขวดของระบบ
  • ระบบใช้ CPU หรือ Memory มากผิดปกติหรือไม่
  • Queue มีงานค้างอยู่จำนวนเท่าใด
  • Database Connection Pool ใกล้เต็มหรือไม่
  • Error ที่เกิดขึ้นเชื่อมโยงกับผู้ใช้หรือธุรกรรมใด
  • ระบบเริ่มช้าลงหลังจาก Release ใด

โดยทั่วไป Observability มักอาศัยข้อมูลหลักสามประเภท ได้แก่ Traces, Metrics และ Logs

#Telemetry Signals ที่สำคัญ

OpenTelemetry รองรับ Signals หลายประเภท แต่ Signals ที่ใช้บ่อยที่สุดมีดังนี้

Signal หน้าที่
Traces แสดงเส้นทางของ Request ผ่านระบบ
Metrics แสดงสถานะและประสิทธิภาพในรูปค่าตัวเลข
Logs บันทึกเหตุการณ์หรือข้อผิดพลาด
Baggage ส่ง Context ระหว่าง Service

#1. Traces

Trace คือข้อมูลที่แสดงเส้นทางการทำงานของ Request หนึ่งรายการ ตั้งแต่เริ่มต้นจนสิ้นสุด

ตัวอย่างเช่น ผู้ใช้ส่งคำขอสั่งซื้อสินค้า

Browser
   |
   v
API Gateway
   |
   v
Order Service
   |
   +----> Product Service
   |
   +----> Payment Service
   |
   +----> PostgreSQL

Trace ช่วยให้เราทราบว่า Request เดินทางผ่าน Service ใดบ้าง และแต่ละ Service ใช้เวลาประมวลผลเท่าใด

#Span คืออะไร

Trace หนึ่งรายการประกอบด้วยหน่วยการทำงานย่อยที่เรียกว่า Span

Trace: Create Order
├── HTTP POST /api/orders
├── Validate request
├── Query product database
├── Process payment
├── Insert order
└── Send confirmation email

Span แต่ละรายการอาจประกอบด้วยข้อมูล เช่น

trace_id
span_id
parent_span_id
service.name
operation.name
start_time
duration
status
attributes
events

ตัวอย่างข้อมูลของ Span:

{
  "service.name": "order-service",
  "operation.name": "process-payment",
  "payment.provider": "example-provider",
  "duration_ms": 850,
  "status": "ERROR"
}

#Trace ID และ Span ID

OpenTelemetry ใช้ข้อมูลสำคัญสองส่วนเพื่อเชื่อมโยงการทำงาน

  • trace_id ใช้ระบุ Trace ทั้งรายการ
  • span_id ใช้ระบุขั้นตอนการทำงานแต่ละขั้น

Span ที่อยู่ใน Request เดียวกันจะมี trace_id เดียวกัน แต่มี span_id แตกต่างกัน

#Context Propagation

Context Propagation คือกลไกสำหรับส่ง Trace Context ระหว่าง Service

Frontend
   |
   v
API Gateway
   |
   v
Order Service
   |
   v
Payment Service

ถึงแม้แต่ละ Service จะทำงานอยู่คนละ Process, Container หรือ Server แต่ Context Propagation จะช่วยให้ Span ทั้งหมดถูกรวมเป็น Trace เดียวกันได้

#Traces เหมาะสำหรับตรวจสอบอะไร

Traces เหมาะสำหรับวิเคราะห์ปัญหา เช่น

  • Request ตอบสนองช้า
  • Microservice เกิด Timeout
  • Database Query ใช้เวลานาน
  • External API ไม่ตอบสนอง
  • Queue Job ทำงานผิดพลาด
  • Error เกิดขึ้นระหว่างหลาย Service
  • ขั้นตอนใดใช้เวลาประมวลผลมากที่สุด

#2. Metrics

Metric คือค่าตัวเลขที่ใช้วัดสถานะหรือประสิทธิภาพของระบบในช่วงเวลาหนึ่ง

ตัวอย่าง Metrics:

http.server.request.count = 1,250
http.server.request.duration = 320 ms
system.cpu.utilization = 72%
system.memory.usage = 2.4 GB
database.connection.count = 45
queue.jobs.pending = 120

Metrics เหมาะสำหรับ

  • สร้าง Dashboard
  • ตรวจสอบแนวโน้มของระบบ
  • ตั้งค่า Alert
  • วัด Availability
  • วัดประสิทธิภาพของ API
  • ตรวจสอบ Resource Usage
  • ใช้ประกอบการ Auto Scaling
  • ตรวจสอบ Service Level Indicator หรือ SLI

#Metric Instruments

OpenTelemetry มี Metric Instruments หลายประเภท

#Counter

ใช้สำหรับค่าที่เพิ่มขึ้นอย่างต่อเนื่อง

http.request.count
login.success.count
order.created.count

#UpDownCounter

ใช้สำหรับค่าที่สามารถเพิ่มหรือลดได้

active.user.count
database.connection.active
queue.worker.count

#Gauge

ใช้แสดงค่าปัจจุบันของระบบ

cpu.utilization
memory.usage
disk.free.space
queue.size

#Histogram

ใช้วัดการกระจายของค่า เช่น ระยะเวลาในการตอบสนอง

http.request.duration
database.query.duration
ai.request.duration

Histogram สามารถนำไปใช้วิเคราะห์ค่า Percentile เช่น

P50
P90
P95
P99

#3. Logs

Log คือข้อมูลบันทึกเหตุการณ์ที่เกิดขึ้นภายใน Application หรือ Infrastructure

ตัวอย่าง Structured Log:

{
  "timestamp": "2026-07-29T10:30:00Z",
  "severity": "ERROR",
  "service.name": "payment-service",
  "message": "Payment provider timeout",
  "trace_id": "4fd0bfc621823ac0",
  "span_id": "a23fc9937a"
}

ข้อดีของ Structured Log คือสามารถค้นหา กรอง และเชื่อมโยงข้อมูลได้ง่ายกว่า Log แบบข้อความธรรมดา

ตัวอย่าง Log แบบข้อความทั่วไป:

Payment failed

ตัวอย่าง Structured Log:

{
  "message": "Payment failed",
  "order.id": "ORD-1001",
  "payment.provider": "example-provider",
  "error.type": "timeout",
  "trace_id": "4fd0bfc621823ac0"
}

#การเชื่อม Logs กับ Traces

OpenTelemetry สามารถเพิ่ม trace_id และ span_id ลงใน Log ทำให้ผู้ดูแลระบบเชื่อมโยง Log กับ Trace ที่เกี่ยวข้องได้

Metric แจ้งว่า Error Rate สูง
           |
           v
เปิด Trace ที่มีสถานะ Error
           |
           v
ค้นหา Span ที่ผิดปกติ
           |
           v
เปิด Log ที่มี Trace ID เดียวกัน
           |
           v
ค้นหาสาเหตุของปัญหา

การเชื่อมโยงข้อมูลลักษณะนี้ช่วยลดเวลาที่ใช้ตรวจสอบและแก้ไขปัญหา

#4. Baggage

Baggage คือข้อมูล Context ที่สามารถส่งต่อไปพร้อมกับ Request ระหว่าง Service

ตัวอย่าง:

tenant.id = university-001
customer.tier = premium
region = asia-southeast

Baggage อาจใช้เพิ่ม Context ให้กับ Traces, Metrics หรือ Logs แต่ต้องใช้อย่างระมัดระวัง เนื่องจากข้อมูลอาจถูกส่งผ่านหลาย Service

ไม่ควรบันทึกข้อมูลสำคัญลงใน Baggage เช่น

  • Password
  • Access Token
  • API Key
  • Session Token
  • เลขประจำตัวประชาชน
  • ข้อมูลสุขภาพ
  • ข้อมูลส่วนบุคคลที่ไม่จำเป็น

#สถาปัตยกรรมของ OpenTelemetry

สถาปัตยกรรมทั่วไปของ OpenTelemetry ประกอบด้วย Application, OpenTelemetry SDK, Collector และ Observability Backend

flowchart LR
    A[Application] --> B[OpenTelemetry API และ SDK]
    B --> C[OTLP Exporter]
    C --> D[OpenTelemetry Collector]
    D --> E[Processors]
    E --> F1[Prometheus หรือ Mimir]
    E --> F2[Jaeger หรือ Tempo]
    E --> F3[Loki หรือ Elasticsearch]
    F1 --> G[Grafana]
    F2 --> G
    F3 --> G

กระบวนการทำงานมีดังนี้

  1. Application ถูก Instrument เพื่อสร้างข้อมูล Telemetry
  2. OpenTelemetry SDK จัดการ Traces, Metrics และ Logs
  3. Exporter ส่งข้อมูลผ่าน OTLP
  4. OpenTelemetry Collector รับข้อมูลจาก Application
  5. Collector ประมวลผล กรอง หรือเพิ่มข้อมูล
  6. Collector ส่งข้อมูลไปยัง Observability Backend
  7. ผู้ดูแลระบบวิเคราะห์ข้อมูลผ่าน Dashboard

#องค์ประกอบหลักของ OpenTelemetry

#OpenTelemetry API

OpenTelemetry API กำหนด Interface สำหรับสร้างข้อมูล Telemetry เช่น

  • Tracer
  • Span
  • Meter
  • Counter
  • Histogram
  • Logger

Library หรือ Framework สามารถเรียกใช้ API โดยไม่จำเป็นต้องทราบว่าจะส่งข้อมูลไปยัง Backend ใด

#OpenTelemetry SDK

OpenTelemetry SDK เป็น Implementation ของ OpenTelemetry API และมีหน้าที่ เช่น

  • สร้างและจัดการ Span
  • สร้าง Metrics
  • กำหนด Resource
  • ทำ Sampling
  • ประมวลผลข้อมูล
  • Batch ข้อมูล
  • Export ข้อมูล
  • เชื่อมต่อกับ Collector

#Instrumentation Libraries

Instrumentation Library ช่วยเก็บข้อมูลจาก Framework และ Library ที่นิยมใช้โดยอัตโนมัติ เช่น

  • HTTP Client
  • HTTP Server
  • Web Framework
  • Database Driver
  • Message Queue
  • Cache
  • RPC Framework
  • Background Job
  • Cloud SDK

#Resource

Resource คือข้อมูลที่ใช้อธิบายแหล่งกำเนิดของ Telemetry

ตัวอย่าง Resource Attributes:

service.name
service.version
service.namespace
deployment.environment.name
host.name
container.id
cloud.provider
cloud.region

ตัวอย่างการกำหนดค่า:

OTEL_SERVICE_NAME=order-service
OTEL_RESOURCE_ATTRIBUTES=service.version=1.0.0,deployment.environment.name=production

#Semantic Conventions

Semantic Conventions คือมาตรฐานการตั้งชื่อ Attributes และข้อมูล Telemetry

ตัวอย่าง:

service.name
service.version
deployment.environment.name
http.request.method
http.response.status_code
server.address
url.path
db.system.name
error.type

การใช้ชื่อมาตรฐานช่วยให้ข้อมูลจากหลายภาษา หลาย Framework และหลาย Service สามารถนำมาวิเคราะห์ร่วมกันได้

#OpenTelemetry Collector คืออะไร

OpenTelemetry Collector เป็น Component กลางสำหรับรับ ประมวลผล และส่งข้อมูล Telemetry ไปยังระบบปลายทาง

Collector ช่วยลดภาระของ Application เพราะ Application ไม่จำเป็นต้องเชื่อมต่อกับ Observability Backend ทุกระบบโดยตรง

โครงสร้างพื้นฐานของ Collector คือ

Receiver → Processor → Exporter

#Receiver

Receiver ทำหน้าที่รับข้อมูล Telemetry จาก Application หรือระบบอื่น

ตัวอย่าง Receiver:

  • OTLP
  • Prometheus
  • Jaeger
  • Zipkin
  • Kafka
  • Fluent Forward
  • Host Metrics
  • File Log

ตัวอย่างการตั้งค่า:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

#Processor

Processor ทำหน้าที่ประมวลผลข้อมูลก่อนส่งออก

ตัวอย่างการทำงานของ Processor:

  • Batch ข้อมูล
  • จำกัดการใช้ Memory
  • กรองข้อมูล
  • เพิ่ม Attributes
  • ลบ Attributes
  • ปิดบังข้อมูลสำคัญ
  • ทำ Sampling
  • แปลงรูปแบบข้อมูล

ตัวอย่าง:

processors:
  memory_limiter:
    check_interval: 1s
    limit_mib: 512

  batch:
    timeout: 5s
    send_batch_size: 1024

#Exporter

Exporter ทำหน้าที่ส่งข้อมูลไปยังระบบปลายทาง

ตัวอย่าง Exporter:

  • OTLP Exporter
  • Prometheus Exporter
  • Jaeger Exporter
  • Zipkin Exporter
  • Kafka Exporter
  • Debug Exporter

ตัวอย่าง:

exporters:
  debug:
    verbosity: detailed

#Service Pipeline

การประกาศ Receiver, Processor และ Exporter เพียงอย่างเดียวยังไม่ทำให้ Component ทำงาน ต้องนำ Component เหล่านั้นไปกำหนดใน service.pipelines

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  memory_limiter:
    check_interval: 1s
    limit_mib: 512

  batch:
    timeout: 5s

exporters:
  debug:
    verbosity: detailed

service:
  pipelines:
    traces:
      receivers:
        - otlp
      processors:
        - memory_limiter
        - batch
      exporters:
        - debug

    metrics:
      receivers:
        - otlp
      processors:
        - memory_limiter
        - batch
      exporters:
        - debug

    logs:
      receivers:
        - otlp
      processors:
        - memory_limiter
        - batch
      exporters:
        - debug

#OTLP คืออะไร

OTLP ย่อมาจาก OpenTelemetry Protocol

OTLP เป็น Protocol มาตรฐานสำหรับส่งข้อมูล Telemetry ระหว่าง Application, OpenTelemetry Collector และ Observability Backend

OTLP รองรับ Transport หลัก ได้แก่

OTLP/gRPC
OTLP/HTTP

พอร์ตที่ใช้โดยทั่วไปคือ

Protocol Port
OTLP/gRPC 4317
OTLP/HTTP 4318

ตัวอย่าง Environment Variables:

OTEL_SERVICE_NAME=order-service
OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector:4318
OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
OTEL_RESOURCE_ATTRIBUTES=service.version=1.0.0,deployment.environment.name=production

#รูปแบบการทำ Instrumentation

OpenTelemetry รองรับการทำ Instrumentation สองรูปแบบหลัก

#Automatic Instrumentation

Automatic Instrumentation หรือ Zero-code Instrumentation เป็นการเพิ่ม Telemetry โดยแทบไม่ต้องแก้ไข Source Code

เหมาะสำหรับ

  • เริ่มต้นใช้งานอย่างรวดเร็ว
  • เก็บข้อมูล HTTP Request
  • เก็บข้อมูล Database Query
  • ติดตาม External API Call
  • ติดตาม Exception
  • ระบบที่ใช้ Framework มาตรฐาน

ข้อมูลที่มักเก็บได้โดยอัตโนมัติ ได้แก่

HTTP Request
HTTP Response
Database Query
External HTTP Call
Messaging Operation
Exception

#Manual Instrumentation

Manual Instrumentation เป็นการเพิ่ม Span, Metric หรือ Event ลงใน Business Logic โดยตรง

ตัวอย่างแนวคิดในภาษา PHP:

<?php

$span = $tracer
    ->spanBuilder('generate-student-portfolio')
    ->startSpan();

try {
    $span->setAttribute('portfolio.template', 'university');
    $span->setAttribute('ai.model', 'gpt-4o-mini');

    $result = $portfolioService->generate();

    $span->setStatus(StatusCode::STATUS_OK);
} catch (Throwable $exception) {
    $span->recordException($exception);
    $span->setStatus(StatusCode::STATUS_ERROR);

    throw $exception;
} finally {
    $span->end();
}

Manual Instrumentation เหมาะสำหรับติดตาม Business Operation เช่น

  • การสมัครสมาชิก
  • การสร้างคำสั่งซื้อ
  • การชำระเงิน
  • การสร้าง Portfolio ด้วย AI
  • การประมวลผลเอกสาร
  • การแนะนำหลักสูตร
  • การเรียกใช้ Large Language Model
  • การทำงานของ Queue Job

Automatic Instrumentation และ Manual Instrumentation สามารถใช้งานร่วมกันได้

#OpenTelemetry แตกต่างจาก Prometheus, Grafana และ Jaeger อย่างไร

OpenTelemetry, Prometheus, Grafana และ Jaeger มีหน้าที่แตกต่างกัน แต่สามารถนำมาใช้งานร่วมกันได้

เครื่องมือ หน้าที่หลัก
OpenTelemetry สร้าง เก็บ ประมวลผล และส่งข้อมูล Telemetry
Prometheus จัดเก็บและ Query Metrics
Grafana สร้าง Dashboard และแสดงผลข้อมูล
Jaeger จัดเก็บและวิเคราะห์ Distributed Traces
Grafana Tempo จัดเก็บ Distributed Traces
Grafana Loki จัดเก็บและ Query Logs
Elasticsearch จัดเก็บ ค้นหา และวิเคราะห์ Logs

ตัวอย่าง Observability Stack:

Application
   |
   v
OpenTelemetry SDK
   |
   v
OpenTelemetry Collector
   |
   +----> Prometheus หรือ Mimir: Metrics
   |
   +----> Tempo หรือ Jaeger: Traces
   |
   +----> Loki หรือ Elasticsearch: Logs
   |
   v
Grafana: Dashboard และ Visualization

#ตัวอย่างการใช้ OpenTelemetry กับ Laravel

ระบบที่พัฒนาด้วย Laravel สามารถใช้ OpenTelemetry เพื่อติดตามองค์ประกอบต่าง ๆ ได้

#HTTP Requests

ข้อมูลที่ควรเก็บ เช่น

HTTP Method
Route Name
Status Code
Response Time
Request Size
Response Size
Error Type

ตัวอย่าง Attributes:

http.request.method
http.response.status_code
url.path
server.address

ไม่ควรใช้ URL ที่มี Parameter หรือ ID แตกต่างกันจำนวนมากเป็น Metric Attribute เพราะอาจทำให้เกิด High Cardinality

#Database Operations

ข้อมูลที่ควรติดตาม เช่น

Database Type
Database Operation
Query Duration
Connection Error
Slow Query

ไม่ควรบันทึก SQL Parameters หรือข้อมูลส่วนบุคคลโดยไม่จำเป็น

#Queue Jobs

สามารถสร้าง Span สำหรับแต่ละขั้นตอนของ Queue Job

Job dispatched
Job received
Job started
Job completed
Job failed
Job retried

Attributes ที่อาจใช้:

messaging.system
messaging.destination.name
job.name
job.attempt
queue.name

#Cache

สามารถติดตามการใช้งาน Cache เช่น

cache.hit
cache.miss
cache.operation.duration
cache.error.count

#AI Operations

สำหรับระบบ Laravel ที่เชื่อมต่อกับ AI Model สามารถเก็บข้อมูล เช่น

AI Provider
Model Name
Operation Name
Request Duration
Input Token Count
Output Token Count
Retry Count
Tool Name
Agent Name
Error Type

ตัวอย่าง Attributes:

gen_ai.provider.name
gen_ai.request.model
gen_ai.operation.name
gen_ai.usage.input_tokens
gen_ai.usage.output_tokens

ไม่ควรบันทึก Prompt และคำตอบจาก AI โดยอัตโนมัติ โดยเฉพาะกรณีที่ข้อมูลอาจมีข้อมูลส่วนบุคคล ข้อมูลนักศึกษา หรือข้อมูลลับขององค์กร

#Business Metrics

ตัวอย่าง Custom Metrics สำหรับระบบ Laravel:

portfolio.generated.count
portfolio.generation.duration
ai.request.count
ai.request.error.count
ai.token.usage
course.recommendation.count
queue.job.failure.count
student.registration.count

Business Metrics ช่วยให้ระบบ Observability ไม่ได้ตรวจสอบเพียง Infrastructure แต่สามารถสะท้อนผลลัพธ์ทางธุรกิจของระบบได้ด้วย

#การใช้งาน OpenTelemetry กับ Docker Compose

ตัวอย่าง docker-compose.yml:

services:
  application:
    build:
      context: .
    environment:
      OTEL_SERVICE_NAME: laravel-application
      OTEL_EXPORTER_OTLP_ENDPOINT: http://otel-collector:4318
      OTEL_EXPORTER_OTLP_PROTOCOL: http/protobuf
      OTEL_RESOURCE_ATTRIBUTES: >
        service.version=1.0.0,
        deployment.environment.name=development
    depends_on:
      - otel-collector

  otel-collector:
    image: otel/opentelemetry-collector-contrib:latest
    command:
      - --config=/etc/otelcol-contrib/config.yaml
    volumes:
      - ./otel-collector-config.yaml:/etc/otelcol-contrib/config.yaml:ro
    ports:
      - "4317:4317"
      - "4318:4318"
      - "8888:8888"
      - "8889:8889"

ตัวอย่างไฟล์ otel-collector-config.yaml:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  memory_limiter:
    check_interval: 1s
    limit_mib: 512

  batch:
    timeout: 5s

exporters:
  debug:
    verbosity: basic

service:
  pipelines:
    traces:
      receivers:
        - otlp
      processors:
        - memory_limiter
        - batch
      exporters:
        - debug

    metrics:
      receivers:
        - otlp
      processors:
        - memory_limiter
        - batch
      exporters:
        - debug

    logs:
      receivers:
        - otlp
      processors:
        - memory_limiter
        - batch
      exporters:
        - debug

สำหรับ Production ควรระบุเวอร์ชันของ Container Image แทนการใช้ Tag latest

#Deployment Patterns ของ OpenTelemetry Collector

OpenTelemetry Collector สามารถติดตั้งได้หลายรูปแบบ

#Agent Pattern

ติดตั้ง Collector ไว้ใกล้กับ Application เช่น หนึ่ง Collector ต่อหนึ่ง Host หรือ Kubernetes Node

Application
   |
   v
Local Collector
   |
   v
Observability Backend

ข้อดี:

  • ลด Latency
  • ลดภาระของ Application
  • เก็บ Host Metrics ได้สะดวก

#Gateway Pattern

ติดตั้ง Collector เป็นศูนย์กลางสำหรับรับข้อมูลจากหลาย Application

Application A ─┐
Application B ─┼──> Collector Gateway ──> Backend
Application C ─┘

ข้อดี:

  • บริหารจัดการง่าย
  • กำหนด Policy จากส่วนกลาง
  • ทำ Sampling และ Filtering จากส่วนกลางได้

#Agent และ Gateway Pattern

ระบบขนาดใหญ่สามารถใช้ทั้งสองรูปแบบร่วมกัน

Applications
     |
     v
Agent Collectors
     |
     v
Gateway Collectors
     |
     v
Observability Backends

รูปแบบนี้เหมาะสำหรับ Microservices และ Kubernetes Cluster ขนาดใหญ่

#Sampling คืออะไร

Trace อาจสร้างข้อมูลจำนวนมาก โดยเฉพาะระบบที่มี Request ปริมาณสูง จึงจำเป็นต้องใช้ Sampling เพื่อเลือกจัดเก็บเฉพาะ Trace บางส่วน

#Head Sampling

ตัดสินใจว่าจะเก็บ Trace หรือไม่ตั้งแต่ Request เริ่มต้น

ข้อดี:

  • ทำงานรวดเร็ว
  • ใช้ Resource ต่ำ

ข้อจำกัด:

  • ยังไม่ทราบว่า Trace จะเกิด Error หรือใช้เวลานานหรือไม่

#Tail Sampling

ตัดสินใจหลังจากได้รับ Span ของ Trace แล้ว

ตัวอย่าง Policy:

  • เก็บ Trace ที่เกิด Error
  • เก็บ Trace ที่ใช้เวลานานกว่า 2 วินาที
  • เก็บ Trace จาก Service สำคัญ
  • เก็บ Trace บางเปอร์เซ็นต์ของ Request ปกติ

Tail Sampling มักดำเนินการที่ OpenTelemetry Collector

#Cardinality คืออะไร

Cardinality คือจำนวนค่าที่แตกต่างกันของ Attribute

ตัวอย่าง Attribute ที่มี Cardinality ต่ำ:

http.request.method = GET | POST | PUT | DELETE
deployment.environment.name = development | staging | production

ตัวอย่าง Attribute ที่มี Cardinality สูง:

user.id
email
request.id
session.id
order.id
full.url

ไม่ควรใช้ข้อมูลที่มี Cardinality สูงเป็น Metric Attributes เพราะอาจทำให้จำนวน Time Series เพิ่มขึ้นอย่างมาก ส่งผลให้ระบบใช้ Memory และพื้นที่จัดเก็บสูงขึ้น

#ความปลอดภัยและข้อมูลส่วนบุคคล

Telemetry อาจมีข้อมูลสำคัญหรือข้อมูลส่วนบุคคลปะปนอยู่ จึงควรกำหนดมาตรการด้านความปลอดภัย

ข้อมูลที่ควรลบหรือปิดบัง ได้แก่

authorization
cookie
password
access_token
refresh_token
api_key
personal_data
email
phone_number
national_id

แนวทางที่ควรดำเนินการ:

  • ไม่บันทึก Request Body ทั้งหมดโดยอัตโนมัติ
  • ไม่บันทึก HTTP Authorization Header
  • ไม่บันทึก Password หรือ Token
  • ใช้ TLS ในการส่ง Telemetry
  • จำกัดสิทธิ์การเข้าถึง Dashboard
  • กำหนดระยะเวลาการเก็บข้อมูล
  • ใช้ Collector Processor สำหรับลบข้อมูลสำคัญ
  • ตรวจสอบ Telemetry Schema ก่อนนำขึ้น Production

#แนวทางเริ่มต้นใช้งาน OpenTelemetry

#1. กำหนด Service Identity

ทุก Service ควรมีข้อมูลพื้นฐานอย่างน้อยดังนี้

service.name
service.version
deployment.environment.name

ตัวอย่าง:

OTEL_SERVICE_NAME=student-portfolio-service
OTEL_RESOURCE_ATTRIBUTES=service.version=1.0.0,deployment.environment.name=production

#2. เริ่มจาก Automatic Instrumentation

เริ่มเก็บข้อมูลพื้นฐาน เช่น

HTTP Requests
Database Operations
External API Calls
Exceptions

#3. ติดตั้ง OpenTelemetry Collector

ให้ Application ส่งข้อมูลผ่าน OTLP ไปยัง Collector แทนการส่งตรงไปยัง Backend หลายระบบ

#4. เพิ่ม Business Spans

เพิ่ม Manual Span สำหรับขั้นตอนสำคัญของระบบ เช่น

Generate Portfolio
Recommend Course
Process Payment
Create Order
Call AI Model
Generate PDF

#5. สร้าง Metrics และ Alerts

เริ่มจาก Metrics สำคัญ เช่น

Request Rate
Error Rate
Request Duration
CPU Usage
Memory Usage
Queue Backlog

แนวคิดที่นิยมใช้คือ RED Method

  • Rate — จำนวน Request
  • Errors — จำนวนหรืออัตราข้อผิดพลาด
  • Duration — ระยะเวลาการตอบสนอง

สำหรับ Infrastructure สามารถใช้ USE Method

  • Utilization — อัตราการใช้งาน
  • Saturation — ระดับความอิ่มตัวหรือคิวสะสม
  • Errors — จำนวนข้อผิดพลาด

#6. ควบคุม Cardinality

หลีกเลี่ยงการใช้ข้อมูลที่มีค่าหลากหลายจำนวนมากเป็น Metric Attributes

#7. ป้องกันข้อมูลสำคัญ

กำหนด Processor สำหรับลบหรือปิดบังข้อมูลสำคัญก่อนส่งไปยัง Backend

#8. กำหนด Sampling Strategy

เลือกรูปแบบ Sampling ให้เหมาะสมกับปริมาณ Request และความสำคัญของระบบ

#ข้อควรระวังในการใช้งาน

การติดตั้ง OpenTelemetry ไม่ได้หมายความว่าระบบจะมี Observability ที่ดีทันที ทีมพัฒนาต้องออกแบบข้อมูล Telemetry ให้สอดคล้องกับคำถามที่ต้องการตอบ

ข้อควรระวังที่สำคัญ ได้แก่

  • ไม่เก็บข้อมูลมากเกินความจำเป็น
  • ไม่สร้าง Span สำหรับทุกบรรทัดของโปรแกรม
  • ไม่ใช้ข้อมูล High Cardinality เป็น Metric Attributes
  • ไม่บันทึกข้อมูลส่วนบุคคลโดยไม่มีเหตุผล
  • ไม่ส่ง Trace ทั้งหมดโดยไม่มี Sampling ในระบบปริมาณสูง
  • ไม่ใช้ชื่อ Service ที่เปลี่ยนแปลงตลอดเวลา
  • ไม่ละเลย Business Metrics
  • ไม่ติดตั้ง Collector โดยไม่มี Memory Limiter
  • ไม่ใช้ Container Image Tag แบบ latest ใน Production
  • ไม่เปิด OTLP Endpoint สู่ Internet โดยไม่มีการป้องกัน

#ประโยชน์ของ OpenTelemetry

#ลด Vendor Lock-in

Application สร้าง Telemetry ตามมาตรฐานกลาง ทำให้สามารถเปลี่ยน Observability Backend ได้โดยไม่ต้องแก้ Instrumentation ทั้งระบบ

#เชื่อมโยงข้อมูลหลายประเภท

Traces, Metrics และ Logs สามารถเชื่อมโยงกันผ่าน Resource Attributes, Trace ID และ Span ID

#รองรับ Distributed Systems

Context Propagation ช่วยติดตาม Request ที่เดินทางผ่านหลาย Process, Container หรือ Microservice

#แยก Application ออกจาก Backend

Application ส่งข้อมูลไปยัง Collector ส่วน Collector รับผิดชอบการ Transform, Filter, Batch และ Export

#รองรับหลายภาษา

OpenTelemetry มี SDK สำหรับภาษาโปรแกรมที่นิยมใช้ เช่น

  • Java
  • JavaScript
  • Python
  • Go
  • .NET
  • PHP
  • Ruby
  • Rust
  • C++
  • Swift
  • Kotlin
  • Erlang
  • Elixir

#ลดเวลาในการแก้ไขปัญหา

การเชื่อมโยง Traces, Metrics และ Logs ช่วยลดเวลาในการตรวจพบและแก้ไขปัญหาของระบบ

#สรุป

OpenTelemetry เป็นมาตรฐานกลางสำหรับ Observability ที่ช่วยให้ Application สามารถสร้าง เก็บ ประมวลผล และส่งข้อมูล Telemetry ได้โดยไม่ผูกติดกับผู้ให้บริการรายใด

องค์ประกอบสำคัญประกอบด้วย

OpenTelemetry API
OpenTelemetry SDK
Instrumentation Libraries
Semantic Conventions
OTLP
OpenTelemetry Collector

Signals หลักที่ใช้วิเคราะห์ระบบ ได้แก่

Traces  → Request เดินทางผ่านระบบอย่างไร
Metrics → ระบบมีสถานะและประสิทธิภาพอย่างไร
Logs    → มีเหตุการณ์หรือข้อผิดพลาดอะไรเกิดขึ้น
Baggage → Context ใดถูกส่งระหว่าง Service

สำหรับระบบ Web Application, Laravel, Microservices, Docker และ Kubernetes การใช้ OpenTelemetry Collector เป็นศูนย์กลางจะช่วยให้สถาปัตยกรรม Observability มีความยืดหยุ่น ลด Vendor Lock-in และช่วยให้ทีมค้นหาสาเหตุของปัญหาได้รวดเร็วยิ่งขึ้น

#คำสำคัญ

OpenTelemetry, OTel, Observability, Distributed Tracing, Metrics, Logs, OTLP, OpenTelemetry Collector, Microservices, DevOps, Cloud Native