เมื่อองค์กรเติบโตจนมี microservices หลักสิบหรือหลักร้อย service กระจายอยู่บนหลายเซิร์ฟเวอร์ การ SSH เข้าไปดู log แต่ละเครื่องทีละตัวเป็นสิ่งที่เป็นไปไม่ได้ — ระบบ centralized logging จึงเป็นหัวใจสำคัญของ production environment ที่ทีม DevOps และ SRE ขาดไม่ได้

Elasticsearch + Kibana (ร่วมกับ Logstash หรือ Beats จะเรียกว่า ELK/Elastic Stack) เป็นหนึ่งใน stack ยอดนิยมสำหรับงาน log aggregation ระดับ enterprise บทความนี้จะพาไปรู้จักสถาปัตยกรรม, การทำงาน, ข้อดี-ข้อจำกัด, และแนวทางการใช้งาน Elasticsearch + Kibana สำหรับระบบ centralized logging ที่สามารถ scale ได้จริง

Elasticsearch คืออะไร และทำไมเหมาะกับ Logs

Elasticsearch เป็น distributed search engine ที่พัฒนาบน Apache Lucene เก็บข้อมูลแบบ JSON document และ index ทุก field ทำให้ค้นหาด้วยเงื่อนไขซับซ้อนได้เร็วมาก เดิมออกแบบมาสำหรับ full-text search ของเว็บไซต์ แต่คุณสมบัติที่ index ทุกอย่างและกระจายโหลดได้ ทำให้เหมาะกับการเก็บ logs มหาศาลที่ต้องค้นหาได้ทันที

ข้อมูลใน Elasticsearch จะถูกเก็บใน Index ซึ่งแบ่งเป็น Shards (primary + replica) กระจายไปตาม nodes ในคลัสเตอร์ เมื่อ query เข้ามา จะมีการส่งไปยังทุก shard ที่เกี่ยวข้องแบบขนาน แล้วรวมผลลัพธ์กลับมา ทำให้ค้นหา logs หลายพันล้าน document ได้ในระดับวินาที

Kibana — UI สำหรับ Visualization และ Analysis

Kibana คือเว็บ UI อย่างเป็นทางการของ Elastic Stack ใช้สำหรับค้นหา, วิเคราะห์, และสร้าง dashboard จากข้อมูลใน Elasticsearch มีฟีเจอร์หลักอย่าง Discover (ค้นหา logs แบบ interactive), Visualize (สร้าง chart), Dashboard (รวม chart หลายตัว), และ Alerting (แจ้งเตือนเมื่อเงื่อนไขตรง)

ภาษา query ที่ใช้ใน Kibana มีสองแบบ — KQL (Kibana Query Language) ที่เรียบง่ายเหมาะกับงานประจำ และ Lucene syntax สำหรับงานซับซ้อน เช่น fuzzy match, wildcard, range query ผู้ใช้สามารถบันทึก query เป็น saved search และใช้ซ้ำใน dashboard ได้

ELK Stack Architecture — Beats, Logstash, Elasticsearch, Kibana

ELK Stack ประกอบด้วยองค์ประกอบหลัก 4 ส่วน:

• Beats — lightweight shippers ติดตั้งบนเครื่อง source (Filebeat สำหรับ file, Metricbeat สำหรับ metric, Packetbeat สำหรับ network) ส่งข้อมูลไป Logstash หรือ Elasticsearch โดยตรง
• Logstash — data processing pipeline ที่ parse, filter, และ transform logs ก่อนส่งเข้า Elasticsearch (รองรับ grok pattern, mutate, date parsing)
• Elasticsearch — ตัว storage และ search engine ที่เก็บ logs และ index ทุก field
• Kibana — UI สำหรับ query, visualize, และ alert

สำหรับงานส่วนใหญ่ ใช้ Filebeat ส่ง logs ตรงไป Elasticsearch ก็เพียงพอ แต่ถ้าต้อง transform logs ซับซ้อน (เช่น parse Apache log format, enrich ด้วย GeoIP, mask PII) ควรใช้ Logstash คั่นกลาง หรือใช้ Elasticsearch Ingest Node ที่เป็น processor แบบเบาในตัว

ติดตั้ง Elasticsearch + Kibana ด้วย Docker Compose

ตัวอย่าง docker-compose สำหรับทดสอบ Elastic Stack แบบ single-node:

services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:8.11.0
    environment:
      - discovery.type=single-node
      - xpack.security.enabled=false
      - ES_JAVA_OPTS=-Xms1g -Xmx1g
    volumes:
      - es-data:/usr/share/elasticsearch/data
    ports:
      - "9200:9200"

  kibana:
    image: docker.elastic.co/kibana/kibana:8.11.0
    environment:
      - ELASTICSEARCH_HOSTS=http://elasticsearch:9200
    ports:
      - "5601:5601"
    depends_on:
      - elasticsearch

volumes:
  es-data:

หลังจาก docker compose up -d เปิด http://localhost:5601 จะเห็น Kibana UI พร้อมใช้งาน สำหรับ production ควรเปิด xpack.security, ใช้ multi-node cluster, และตั้ง heap size ให้เหมาะกับ RAM (มักใช้ 50% ของ RAM แต่ไม่เกิน 31GB ต่อ node)

Index Template และ ILM — จัดการ Lifecycle

Logs มักเพิ่มขึ้นเรื่อย ๆ จึงต้องมีกลไกจัดการ storage — Elasticsearch มี Index Lifecycle Management (ILM) ที่ย้าย index ระหว่าง phase อัตโนมัติ ได้แก่ Hot (เขียน active), Warm (อ่านอย่างเดียว), Cold (ข้อมูลเก่า), Frozen (archive), และ Delete

PUT _ilm/policy/logs-policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": { "max_size": "50gb", "max_age": "7d" }
        }
      },
      "warm": {
        "min_age": "7d",
        "actions": { "allocate": { "require": { "data": "warm" } } }
      },
      "delete": {
        "min_age": "30d",
        "actions": { "delete": {} }
      }
    }
  }
}

ILM ช่วยให้ index ใหม่ rollover เมื่อเกินขนาดหรืออายุ และลบข้อมูลเก่าอัตโนมัติ — ลดภาระการจัดการ storage อย่างมาก สำหรับ production ที่ logs เยอะ แนะนำใช้ร่วมกับ node ที่มี SSD สำหรับ Hot phase และ HDD สำหรับ Warm/Cold

ข้อดีและข้อจำกัดของ Elastic Stack

• ข้อดี: ค้นหาได้เร็วมาก รองรับ full-text search, aggregation ซับซ้อน, visualization ครบครัน, community ใหญ่ และมี integration กับเครื่องมืออื่น ๆ มากมาย
• ข้อจำกัด: ใช้ resource หนัก (RAM 8GB+ ต่อ node), storage เพิ่มขึ้นเร็วเพราะ index ทุก field, การ scale ต้องวางแผน shard ให้ดี และ license หลังรุ่น 7.11 เปลี่ยนเป็น SSPL/Elastic License
• เมื่อไหร่ควรเลือก: เมื่อต้อง search ซับซ้อน, ต้อง visualize ละเอียด, มีทีม ops พร้อมดูแล cluster, และ budget สำหรับ infrastructure
• เมื่อไหร่ควรหาทางเลือก: ถ้าต้องการประหยัด storage และ query แบบเรียบง่าย — Loki + Grafana เหมาะกว่า (index เฉพาะ labels)

สรุป

Elasticsearch + Kibana เป็น stack ที่แข็งแกร่งสำหรับ centralized logging ระดับ enterprise จุดเด่นอยู่ที่ความสามารถในการ index ทุก field ทำให้ค้นหาข้อมูลซับซ้อนได้เร็วและมี Kibana ช่วยสร้าง dashboard สวย ๆ เข้าใจง่าย เหมาะกับทีมที่ต้องวิเคราะห์ logs เชิงลึกและมี resource พร้อมสำหรับดูแล cluster

อย่างไรก็ตาม การใช้งานต้องวางแผน architecture ตั้งแต่การเลือก node size, การออกแบบ index template, การตั้ง ILM policy, และการ monitor cluster health อย่างต่อเนื่อง การเริ่มต้นจาก single-node สำหรับทดสอบและขยายเป็น multi-node เมื่อพร้อมคือแนวทางที่ปลอดภัยสำหรับทีมที่เพิ่งเริ่มใช้งาน