การเลือกระบบเก็บและค้น log กลางเป็นหนึ่งในการตัดสินใจที่ส่งผลระยะยาวมากที่สุดในทีม DevOps — ทั้งเรื่อง cost, performance และ learning curve ของทีม ตัวเลือกหลักในตลาดปัจจุบันมีสองค่ายใหญ่: ELK Stack (Elasticsearch + Logstash + Kibana) ที่ครองตลาด centralized logging มานานกว่า 10 ปี และ Loki + Grafana ที่ Grafana Labs ออกแบบมาให้ light-weight, ราคาถูก และทำงานเข้ากับ Prometheus stack ได้ตรง ๆ บทความนี้จะเปรียบเทียบทั้งสองระบบอย่างละเอียดเพื่อให้เลือกได้ตรงกับ workload จริง

ELK Stack คืออะไร

ELK เป็นชื่อย่อของสาม component หลัก: Elasticsearch (search engine + storage), Logstash (pipeline แปลง log), และ Kibana (UI สำหรับ query และ visualization) หลายทีมเพิ่ม Beats (Filebeat, Metricbeat) เข้ามาด้วย จนเรียกรวมว่า “Elastic Stack” จุดเด่นคือ full-text indexing — log ทุกฟิลด์ถูก tokenize และ index ทำให้ค้นหาคำใด ๆ ภายในข้อความ log ได้เร็วระดับมิลลิวินาที เหมาะกับการทำ forensic analysis ที่ต้องหาคำเฉพาะในข้อมูลนับพันล้าน record

ข้อดีอื่น ๆ คือ ecosystem ใหญ่มาก — มี dashboard template, alerting module, machine learning, APM, SIEM และ integration กับ SaaS ระดับ enterprise ครบชุด ผู้ใช้สามารถทำ aggregation complex เช่น group by หลายระดับ, percentile, date histogram ได้ใน query เดียว และมี query DSL (JSON-based) ที่ flexible มาก

Loki + Grafana คืออะไร

Loki คือ log aggregation system จาก Grafana Labs ที่ได้ inspiration จาก Prometheus — index เฉพาะ label (เช่น app, host, level) ไม่ index ตัวเนื้อหา log ทำให้กิน storage น้อยกว่า ELK มหาศาล ตัว log จริงถูกเก็บแบบ compressed chunk บน object storage (S3, GCS) และค้นด้วย LogQL ที่ไวยากรณ์คล้าย PromQL ส่วน UI ใช้ Grafana เดียวกับที่ดู metric จาก Prometheus

จุดขายคือ “cheap by design” — เก็บข้อมูลได้ในราคาใกล้เคียง object storage ล้วน ไม่ต้องจ่ายค่า index heavy เหมือน Elasticsearch ที่ต้องใช้ SSD NVMe และ RAM สูงตลอด การ scale ก็ทำแบบ stateless ด้วย microservice (distributor, ingester, querier, compactor) คล้ายกับ Mimir/Cortex ทำให้ deploy บน Kubernetes ได้ง่าย

ตารางเปรียบเทียบคุณสมบัติหลัก

ด้าน	ELK Stack	Loki + Grafana
วิธี Index	Full-text (ทุกฟิลด์)	Label-only
Storage	SSD + RAM สูง	Object storage + disk น้อย
Cost ต่อ GB	สูง	ต่ำมาก
Query Language	Elasticsearch DSL / KQL	LogQL
Full-text Search	Index — เร็วมาก	Scan chunk — ช้ากว่า
UI	Kibana	Grafana (ร่วมกับ metric)
Ecosystem	APM, SIEM, ML, Alert	Grafana stack (LGTM)
Learning Curve	กลาง-สูง	ต่ำ (ถ้าคุ้น PromQL)
Multi-tenancy	ต้องใช้ Elastic Cloud / x-pack	built-in

เมื่อไหร่ควรเลือก ELK

• ต้องทำ forensic / security investigation ที่ค้นคำ arbitrary ในข้อความ log บ่อย ๆ — ELK index full-text ตอบเร็วระดับวินาที แม้ข้อมูลเป็น TB
• ต้องการ dashboard ที่ complex (heatmap, pivot, ML anomaly detection) — Kibana แข็งแกร่งกว่าการดู log อย่างเดียว
• ระบบมี compliance ที่ต้องใช้ SIEM หรือ audit log มาตรฐาน (PCI DSS, HIPAA) — Elastic Security หรือ ArcSight-compatible มีให้พร้อมใช้
• ทีมคุ้นเคยกับ Elasticsearch / Kibana อยู่แล้ว — โค้ช onboard ใหม่ประหยัดเวลา
• ต้องรวม log + metric + APM trace เข้าใน platform เดียวและใช้ Elastic APM ที่ย้ายมาจาก OpenTelemetry ได้

เมื่อไหร่ควรเลือก Loki

• งบ infrastructure จำกัด แต่ log volume สูง — Loki เก็บ log ปริมาณเดียวกันในราคาต่ำกว่า ELK ได้ 5-10 เท่า
• ทีมใช้ Prometheus + Grafana อยู่แล้ว — พนักงานเรียน LogQL ได้ภายในวันเดียว เพราะใกล้เคียง PromQL
• Workload มีรูปแบบ query ตามเวลา + label (เช่น “log ของ service X ในช่วง 10 นาทีก่อน”) มากกว่าค้นคำ arbitrary
• Deploy บน Kubernetes และต้องการ stateless scaling ที่ simple
• ต้องการรวม log + metric + trace ใน Grafana ตัวเดียวโดยไม่ต้องสลับ tab

ตัวอย่าง Query ทั้งสองระบบ

# Elasticsearch DSL: หา error ของ service api ในชั่วโมงล่าสุด
GET app-logs-*/_search
{
  "query": {
    "bool": {
      "must": [
        {"match": {"service": "api"}},
        {"match_phrase": {"message": "error"}}
      ],
      "filter": {
        "range": {"@timestamp": {"gte": "now-1h"}}
      }
    }
  },
  "aggs": {
    "by_host": {"terms": {"field": "host.keyword"}}
  }
}

# LogQL: หา error ของ service api ในชั่วโมงล่าสุด
{service="api"} |= "error"
  | json
  | line_format "{{.host}} {{.message}}"

# aggregate count by host
sum by (host) (count_over_time({service="api"} |= "error" [1h]))

สังเกตว่า LogQL อ่านและเขียนง่ายกว่า แต่ถ้าต้อง filter ด้วยคำที่อยู่ลึกใน JSON หลายระดับ ELK ยังชนะเรื่อง performance เพราะทุกฟิลด์ถูก index ไว้ล่วงหน้า ในขณะที่ Loki ต้อง scan chunk ด้วย |= "error" ซึ่ง I/O-bound บน volume ใหญ่

Cost Analysis เบื้องต้น

สมมติ log 500 GB/วัน retention 30 วัน — ELK ต้องการ disk ประมาณ 15-20 TB (รวม index overhead ~30%) บน SSD plus RAM 30-60% ของ data size เพื่อ cache ขึ้น ในทางปฏิบัติต้นทุนรวม (compute + storage + operational) มักอยู่ที่ $0.5-1.5 ต่อ GB/เดือน ขึ้นกับ cloud

Loki บน object storage เก็บแบบ compressed chunk ใช้เนื้อที่จริงประมาณ 30-50% ของ raw log ต้นทุน S3 class ปกติอยู่ที่ $0.02/GB/เดือน บวก compute ของ ingester/querier แล้วรวม $0.05-0.15 ต่อ GB/เดือน — ต่ำกว่า ELK ประมาณ 5-10 เท่าบน workload เดียวกัน

Hybrid: ใช้ทั้งสองระบบ

หลายองค์กรจริง ๆ ใช้ทั้งสองระบบแบ่งหน้าที่ — Loki เก็บ application log ทั่วไป (volume สูง, ค้นน้อย) ส่วน ELK เก็บ security log / audit log ที่ต้องค้นละเอียด (volume ต่ำ, ค้นมาก) วิธีนี้ช่วย optimize cost โดยไม่เสีย capability ของ full-text search ในจุดที่ต้องใช้ ทีมสามารถ pipe log ผ่าน Fluent Bit หรือ Vector แล้ว routing ตาม pattern ของ service หรือ severity

สรุป

ไม่มีคำตอบเดียวว่า ELK หรือ Loki ดีกว่ากัน — เลือกจาก workload pattern และงบเป็นหลัก ถ้าใช้งาน forensic ค้นคำในข้อความ log บ่อย ต้องการ ecosystem enterprise ครบ และพร้อมจ่ายเพื่อ performance ELK คือคำตอบที่ทดสอบด้วยเวลามาแล้ว แต่ถ้างบคุมลำบาก และ query ส่วนใหญ่เป็นการดู log ตาม service/label ตามช่วงเวลา Loki ประหยัดได้มากและเข้ากันกับ stack Prometheus+Grafana ได้เต็มรูปแบบ

สำหรับองค์กรที่กำลังเริ่มต้นและยังไม่ชัดเจน แนะนำให้เริ่มจาก Loki ก่อน — cost entry ต่ำ, setup เร็ว, operate ง่าย แล้วค่อย add ELK เฉพาะ subset ของ log ที่ต้อง full-text จริง ๆ เมื่อระบบโตและความต้องการชัดเจนขึ้น การตัดสินใจแบบนี้หลีกเลี่ยงการจ่ายค่า license หรือ infrastructure สูงตั้งแต่วันแรกโดยไม่จำเป็น