คุณจัดการ logging และ monitoring สำหรับ container อย่างไร?

Question

Accepted Answer

แอปพลิเคชันแบบ container ต้องการ **logging แบบรวมศูนย์** และ **monitoring** เพราะ container ไม่ถาวรและมีจำนวนมาก — logs และ metrics ต้องถูกเก็บรวบรวมไว้ภายนอกเพื่อให้คงอยู่หลังจากที่ container ถูกลบและให้มองเห็นภาพรวมทั้งระบบ นี่เป็น observability ที่จำเป็นสำหรับ container ใน production

## Logging: log ไปยัง stdout/stderr แล้วรวบรวมแบบรวมศูนย์

```text
BEST PRACTICE: containers should log to STDOUT/STDERR (not to files inside the container):
  → Docker captures these (`docker logs`); a logging DRIVER forwards them elsewhere
  → WHY: containers are EPHEMERAL — logs in a removed container are LOST. Centralize them.
```

```text
Logging drivers / pipelines forward logs to a central system:
  → json-file (default), syslog, fluentd, awslogs, gelf, etc. (--log-driver)
  → Aggregation stacks: ELK/Elastic (Elasticsearch+Logstash+Kibana), Loki+Grafana,
    cloud logging (CloudWatch, Stackdriver), Datadog, etc.
→ Centralized logs: searchable, persistent, span ALL containers/hosts → real visibility
```

## Monitoring: metrics, health, alerts

```text
✓ METRICS — collect CPU, memory, network, app metrics per container
  → Prometheus (scrapes metrics) + Grafana (dashboards) — the common stack
  → cAdvisor / node-exporter for container/host metrics
✓ HEALTH — health checks + orchestrator status (which containers are healthy)
✓ ALERTING — alert on failures, resource limits, errors (Alertmanager, etc.)
✓ DISTRIBUTED TRACING — trace requests across microservices (Jaeger, OpenTelemetry)
```

## ทำไม observability ของ container จึงแตกต่าง

```text
Containers are EPHEMERAL (created/destroyed dynamically) and NUMEROUS (many across hosts):
  → can't rely on logging into a box or local log files (containers come and go)
  → need EXTERNAL, centralized, dynamic collection that handles churn
  → orchestrators add labels/metadata to correlate logs/metrics to services
→ Observability must be designed for dynamic, distributed, ephemeral workloads.
```

## ทำไมจึงสำคัญ

การเข้าใจ logging และ monitoring สำหรับ container เป็นความรู้ระดับ senior ที่สำคัญ เพราะ **observability จำเป็นต่อการปฏิบัติงานกับระบบ production** และธรรมชาติของ container ที่ไม่ถาวร มีจำนวนมาก และกระจายตัว ทำให้มันแตกต่างจากแนวทางดั้งเดิม

แนวปฏิบัติ **logging** สำคัญ — container ควร **log ไปยัง stdout/stderr** (ไม่ใช่ไปยังไฟล์ภายใน container) เพื่อให้แพลตฟอร์มเก็บและส่งต่อไปยัง **การรวบรวมแบบรวมศูนย์** — เป็นเรื่องสำคัญเพราะ **container ไม่ถาวร**: logs ที่เก็บไว้ภายใน container จะ **สูญหายเมื่อมันถูกลบ** ดังนั้นการรวมศูนย์ (ผ่าน logging driver ไปยัง ELK, Loki/Grafana, cloud logging ฯลฯ) จึงจำเป็นต่อการเก็บ logs ไว้และการมองเห็นภาพรวมทั่วทุก container และ host **Monitoring** ก็จำเป็นเช่นกัน: การเก็บ **metrics** (CPU, memory, application metrics โดยทั่วไปผ่าน Prometheus + Grafana) การติดตาม **health** (health checks และสถานะของ orchestrator) การ **alert** เมื่อมีปัญหา และ **distributed tracing** (การติดตาม request ข้าม microservices ด้วย Jaeger/OpenTelemetry) ให้การมองเห็นที่จำเป็นต่อการเข้าใจพฤติกรรมของระบบ วินิจฉัยปัญหา และตอบสนองต่อปัญหา

การเข้าใจ **ว่าทำไม observability ของ container จึงแตกต่าง** — container ไม่ถาวร (ถูกสร้าง/ทำลายแบบ dynamic ดังนั้นจึงพึ่งพาไฟล์ในเครื่องหรือการ login เข้าเครื่องไม่ได้) และมีจำนวนมากทั่วหลาย host (ต้องการการเก็บรวบรวมจากภายนอกแบบ dynamic ที่รองรับการเปลี่ยนแปลง โดยมี metadata ของ orchestrator เชื่อมโยง logs/metrics เข้ากับ service) — คือข้อค้นพบเชิงแนวคิดที่กำหนดว่า observability ต้องถูกออกแบบสำหรับระบบแบบ container อย่างไร

เนื่องจากการปฏิบัติงานกับระบบ production ต้องการ observability (คุณจัดการสิ่งที่มองไม่เห็นไม่ได้) และเนื่องจากธรรมชาติที่ไม่ถาวรและกระจายตัวของ container ต้องการ logging และ monitoring แบบรวมศูนย์ที่เก็บรวบรวมจากภายนอกซึ่งออกแบบมาสำหรับ workload แบบ dynamic การเข้าใจ logging และ monitoring ของ container จึงเป็นความรู้ระดับ senior ที่สำคัญสำหรับการรันแอปพลิเคชันแบบ container อย่างมีความรับผิดชอบ — เป็น observability ที่จำเป็นซึ่งทำให้ระบบแบบ container สามารถปฏิบัติงาน debug และดูแลรักษาได้ใน production และสะท้อนวุฒิภาวะด้านการปฏิบัติงานที่คาดหวังจากบทบาทระดับ senior ที่จัดการการ deploy container