ELK Stack là gì? Hướng dẫn cài đặt Elasticsearch, Logstash, Kibana chi tiết

ELK Stack là viết tắt của ba công cụ mã nguồn mở: Elasticsearch, Logstash, và Kibana — kết hợp tạo thành một nền tảng quản lý và phân tích log tập trung mạnh mẽ. Sau này, Beats được thêm vào, biến bộ ba thành bộ tứ, nhưng cái tên ELK Stack vẫn được giữ nguyên vì độ nhận diện thương hiệu.

Với ELK Stack, bạn có thể thu thập log từ hàng trăm server, ứng dụng, container, xử lý và chuẩn hóa dữ liệu, lưu trữ tập trung, và hiển thị dưới dạng dashboard trực quan để monitor toàn bộ hệ thống từ một giao diện duy nhất. Nếu bạn đang vận hành hệ thống với nhiều service chạy trên Docker, việc triển khai ELK Stack gần như là bắt buộc để kiểm soát log hiệu quả.

Tại sao cần Centralized Logging khi dùng ELK Stack?

Trước đây, khi ứng dụng chỉ chạy trên một server, bạn có thể SSH vào và grep file log. Nhưng với kiến trúc microservices, container hóa, và multi-cloud, log nằm rải rác trên hàng trăm instance — không thể SSH vào từng máy để tìm lỗi. Thú thật là mình từng mất 3 tiếng debug một lỗi 500 chỉ vì log nằm trên container đã bị restart và mất sạch.

Centralized logging với ELK Stack giải quyết vấn đề này:

• Single pane of glass: Xem tất cả log từ một dashboard duy nhất thay vì SSH vào từng máy
• Real-time search: Tìm kiếm và filter log tức thì — giống như Google cho log hệ thống
• Correlation: Ghép log từ nhiều service để trace một request xuyên suốt hệ thống
• Alerting: Cảnh báo khi có bất thường, giúp phát hiện sự cố trước khi user phàn nàn
• Compliance: Lưu trữ log phục vụ kiểm toán, đáp ứng yêu cầu regulatory

Nếu bạn đã quen với Monitoring và Logging trong hệ thống Observability, ELK Stack chính là giải pháp phổ biến nhất cho phần logging trong bộ ba observability (logs, metrics, traces).

Các thành phần cốt lõi trong hệ thống

1. Elasticsearch — Search Engine phân tán

Elasticsearch là một distributed search và analytics engine dựa trên Apache Lucene. Đây là trái tim của ELK Stack, chịu trách nhiệm lưu trữ, đánh index, và tìm kiếm dữ liệu. Theo trải nghiệm thực tế của mình, Elasticsearch có thể xử lý hàng triệu log events mỗi giây khi được cấu hình đúng cách.

Đặc điểm nổi bật của Elasticsearch:

• Schema-less: Dữ liệu dạng JSON, không cần định nghĩa schema trước — rất tiện cho log data có cấu trúc thay đổi liên tục
• Full-text search: Tìm kiếm mờ, fuzzy query, ranking — tìm log chứa “timeout” trong hàng tỷ dòng chỉ mất vài mili giây
• Distributed by nature: Cluster nhiều node, tự động sharding và replication — scale horizontal dễ dàng
• RESTful API: Giao tiếp qua HTTP, dễ tích hợp với bất kỳ ngôn ngữ lập trình nào
• Near real-time: Dữ liệu có thể search được trong ~1 giây sau khi được index

Elasticsearch lưu dữ liệu dưới dạng JSON documents trong các index. Mỗi index có thể được chia thành nhiều shards, phân tán trên các nodes trong cluster. Cách hoạt động này giống như cơ chế phân tán trong các hệ thống cache — chia nhỏ dữ liệu ra nhiều node để tăng throughput.

2. Logstash — ETL Pipeline xử lý Log

Logstash là công cụ xử lý dữ liệu theo mô hình Input → Filter → Output. Nó nhận dữ liệu từ nhiều nguồn (file log, TCP/UDP, syslog, Kafka…), xử lý và biến đổi, rồi gửi đến đích (Elasticsearch, file, Kafka…). Nói một cách đơn giản, Logstash là “nhà máy xử lý” biến log thô thành dữ liệu có cấu trúc mà Elasticsearch có thể đánh index.

Ví dụ cấu hình Logstash cơ bản trong ELK Stack:

input {
  beats {
    port => 5044
  }
}

filter {
  grok {
    match => { "message" => "%{COMBINEDAPACHELOG}" }
  }
  date {
    match => ["timestamp", "dd/MMM/yyyy:HH:mm:ss Z"]
  }
  geoip {
    source => "clientip"
  }
}

output {
  elasticsearch {
    hosts => ["http://elasticsearch:9200"]
    index => "weblogs-%{+YYYY.MM.dd}"
  }
}

Grok filter là tính năng mạnh nhất của Logstash — nó dùng regex pattern để parse log unstructured thành dữ liệu có cấu trúc. Vấn đề là viết grok pattern không dễ, và sai pattern sẽ khiến log bị parse sai hoàn toàn. Logstash có sẵn hàng trăm pattern cho Apache, Nginx, MySQL, syslog — nên luôn kiểm tra danh sách Grok patterns có sẵn từ Elastic trước khi tự viết.

3. Kibana — Giao diện trực quan hóa Log

Kibana là giao diện web cho Elasticsearch. Bạn có thể tìm kiếm log, tạo biểu đồ, dashboard, và quản lý Elasticsearch cluster từ Kibana. Nếu Elasticsearch là bộ não, thì Kibana là đôi mắt — giúp bạn nhìn thấy những gì đang xảy ra trong hệ thống.

Tính năng chính của Kibana:

• Discover: Tìm kiếm và explore dữ liệu log theo thời gian thực — đây là tab bạn sẽ dùng nhiều nhất khi debug
• Visualize: Tạo bar chart, line chart, pie chart, heat map từ dữ liệu log
• Dashboard: Ghép nhiều visualization vào một view — tương tự như dashboard trong Grafana nhưng chuyên cho log data
• Canvas: Tạo custom presentation-style reports cho management
• Machine Learning: Phát hiện anomaly tự động — cực kỳ hữu ích để phát hiện spike bất thường
• Alerting: Cấu hình cảnh báo dựa trên threshold hoặc ML khi phát hiện bất thường

4. Beats — Bộ thu thập dữ liệu nhẹ

Beats là các agent nhẹ, cài trên máy cần thu thập dữ liệu. Điểm đáng chú ý ở đây là Beats chỉ chiếm rất ít tài nguyên — khác hoàn toàn với Logstash vốn ngốn RAM đáng kể. Mỗi Beat chuyên cho một loại dữ liệu:

• Filebeat: Thu thập log files — phổ biến nhất trong ELK Stack
• Metricbeat: Thu thập metrics (CPU, memory, disk…) — giống chức năng của các tool monitoring nhưng gửi data về Elasticsearch
• Packetbeat: Phân tích network packets
• Heartbeat: Uptime monitoring — kiểm tra service còn sống không
• Winlogbeat: Windows event logs
• Auditbeat: Audit dữ liệu hệ thống

FileBeats là Beat phổ biến nhất — nó đọc log files, dùng ingest node pipelines của Elasticsearch để xử lý, và gửi trực tiếp đến Elasticsearch mà không cần Logstash. Trong nhiều setup hiện đại, Filebeat + Elasticsearch ingest pipeline đã thay thế hoàn toàn Logstash, giúp giảm đáng kể chi phí vận hành.

Kiến trúc ELK Stack trong môi trường Production

Trong môi trường production thực tế, kiến trúc ELK Stack phức tạp hơn lab cơ bản rất nhiều. Nếu bạn hỏi mình đâu là sai lầm phổ biến nhất khi triển khai ELK Stack, câu trả lời là: chạy single-node Elasticsearch trên production. Đây là kiến trúc đề xuất:

• Data collection layer: Filebeat/Metricbeat trên mỗi máy chủ — nhẹ, ít tốn tài nguyên
• Message queue: Kafka hoặc Redis giữa Beats và Logstash để đảm bảo không mất dữ liệu khi Logstash bị quá tải
• Processing layer: Logstash cluster với nhiều instance xử lý song song
• Storage layer: Elasticsearch cluster với ít nhất 3 master nodes và data nodes riêng biệt
• Presentation layer: Kibana với Nginx reverse proxy + authentication
• Monitoring: Elasticsearch monitoring cluster riêng — không monitor chính mình

Một production cluster Elasticsearch trong ELK Stack thường có cấu hình tối thiểu:

• 3 master-eligible nodes (quorum cho split-brain prevention) — đây là con số tối thiểu để ELK Stack hoạt động ổn định
• 3+ data nodes với SSD, RAM tối thiểu 32GB/node — Elasticsearch rất tham RAM
• Index lifecycle management (ILM) để tự động rollover và delete index cũ
• Snapshot/backup lên S3 hoặc NFS — theo hướng dẫn Snapshot từ Elastic

Cài đặt ELK Stack với Docker Compose

Cách nhanh nhất để chạy ELK Stack là dùng Docker. Nếu bạn chưa có Docker, có thể tham khảo bài So sánh Docker vs Podman để chọn công cụ container phù hợp. Dưới đây là file docker-compose.yml mẫu cho ELK Stack:

version: '3.8'

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

  logstash:
    image: docker.elastic.co/logstash/logstash:8.15.0
    container_name: elk-logstash
    ports:
      - "5044:5044"
      - "5000:5000/udp"
    volumes:
      - ./logstash.conf:/usr/share/logstash/pipeline/logstash.conf
    depends_on:
      - elasticsearch

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

volumes:
  elasticsearch_data:

Chạy ELK Stack trên Docker

Chạy lệnh sau để khởi động toàn bộ ELK Stack:

# Khoi dong ELK Stack
docker compose up -d

# Kiem tra trang thai
docker compose ps

# Xem log Elasticsearch
docker compose logs -f elasticsearch

Sau khi container chạy, truy cập Kibana tại http://localhost:5601. Lưu ý ELK Stack cần khoảng 30-60 giây để Elasticsearch khởi động hoàn tất — Kibana sẽ hiển thị “Elasticsearch is not ready yet” nếu bạn truy cập quá sớm.

Cấu hình Filebeat gửi log về ELK Stack

Trên server cần thu thập log, cài Filebeat — thành phần quan trọng nhất để đưa log vào ELK Stack:

# Tai va cai Filebeat
curl -L -O https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-8.15.0-amd64.deb
dpkg -i filebeat-8.15.0-amd64.deb

Cấu hình Filebeat (/etc/filebeat/filebeat.yml) để gửi log về ELK Stack:

filebeat.inputs:
- type: log
  enabled: true
  paths:
    - /var/log/nginx/*.log
    - /var/log/syslog

output.logstash:
  hosts: ["elk-server:5044"]

# Hoac output truc tiep den Elasticsearch:
# output.elasticsearch:
#   hosts: ["http://elk-server:9200"]

Khởi động Filebeat:

systemctl start filebeat
systemctl enable filebeat

# Kiem tra Filebeat dang chay
systemctl status filebeat

ELK Stack và OpenSearch — Chọn cái nào?

Đầu năm 2021, Elastic thông báo ELK Stack không còn open source nữa (từ version 7.11). Họ chuyển sang dual license (SSPL + Elastic License). Điều này gây tranh cãi lớn và Amazon đã fork Elasticsearch thành OpenSearch. Thực tế thì quyết định này ảnh hưởng khá nhiều đến cộng đồng DevOps vì OpenSearch và ELK Stack giờ đây đi hai hướng khác nhau.

Hiện tại bạn có 2 lựa chọn cho centralized logging:

Nếu bạn hỏi mình, với dự án mới, OpenSearch là lựa chọn an toàn hơn vì không bị vendor lock-in. Tuy nhiên, ELK Stack vẫn chiếm thị phần lớn và tài liệu phong phú hơn — đặc biệt khi bạn cần các tính năng ML và security nâng cao.

Best practices khi vận hành ELK Stack trên Production

Qua nhiều năm vận hành ELK Stack, mình rút ra được một số bài học xương máu. Dưới đây là những best practices quan trọng nhất mà bạn nên áp dụng ngay từ đầu — đừng chờ đến khi ELK Stack sập mới sửa.

1. Index Lifecycle Management (ILM) — Quản lý vòng đời Index

Không để Elasticsearch chứa index mãi mãi — đây là nguyên nhân số 1 khiến Elasticsearch chạy chậm dần theo thời gian. Dùng ILM để tự động quản lý vòng đời index:

• Hot phase: Index active, ghi và search nhiều — lưu trên SSD nhanh
• Warm phase: Ngừng ghi, vẫn cho search — có thể chuyển sang HDD
• Cold phase: Lưu trên HDD hoặc S3, ít truy cập — tiết kiệm chi phí lưu trữ
• Delete phase: Xóa index cũ sau N ngày — giải phóng disk space

2. Cấu hình JVM Heap — Quy tắc 50% RAM

Elasticsearch và Logstash chạy trên JVM. Nguyên tắc quan trọng nhất: không set heap vượt quá 50% RAM vật lý và tối đa 32GB (do compressed OOPs trong JVM). Ví dụ server 64GB RAM → set ES_JAVA_OPTS=-Xms16g -Xmx16g, phần RAM còn lại để cho filesystem cache — Elasticsearch cần rất nhiều filesystem cache để hoạt động hiệu quả.

3. Security — Đừng expose Elasticsearch và Kibana ra Internet

Không bao giờ expose Elasticsearch hay Kibana trực tiếp ra internet. Mình từng thấy một cluster Elasticsearch bị crypto miner tấn công chỉ vì port 9200 mở public. Luôn dùng:

• Nginx reverse proxy với SSL cho Kibana — tham khảo hướng dẫn bảo mật HTTPS từ Elastic
• Authentication (Elasticsearch security features hoặc nginx basic auth)
• Network firewall (chỉ cho phép port 5044 từ các Beats servers)
• Bật xpack.security.enabled=true trong production — mặc định từ version 8.x đã bật sẵn

4. Cấu hình Shards — Tối ưu hiệu suất Elasticsearch

Quá nhiều shards gây overhead nghiêm trọng cho ELK Stack. Rule of thumb mà mình luôn áp dụng:

• Mỗi shard từ 10-50GB — nếu nhỏ hơn 10GB, bạn đang tạo quá nhiều shards
• 1 primary shard cho data index log hàng ngày là đủ với đa số trường hợp
• Theo dõi số lượng shards qua Kibana Stack Monitoring — nên giữ dưới 1000 shards per node
• Dùng rollover index thay vì tạo index theo ngày nếu lượng log không đều — tránh tạo quá nhiều tiny shards

So sánh Elasticsearch với các giải pháp Logging khác

Ngoài Elasticsearch, Logstash và Kibana, thị trường logging hiện tại còn có nhiều lựa chọn đáng cân nhắc. Mỗi giải pháp có ưu nhược điểm riêng, và việc chọn đúng công cụ phụ thuộc vào quy mô hệ thống, ngân sách, và yêu cầu kỹ thuật của bạn.

Theo trải nghiệm thực tế của mình, nếu team bạn đã quen với Grafana cho metrics monitoring, thì Loki là lựa chọn nhẹ nhàng hơn Elasticsearch cho logging. Nhưng nếu bạn cần full-text search mạnh mẽ, query phức tạp, hoặc xử lý log volume lớn (hàng chục GB mỗi ngày), Elasticsearch vẫn là vua trong lĩnh vực này. Điểm đáng chú ý ở đây là chi phí vận hành — một cluster Elasticsearch production tối thiểu cần 3 master + 3 data nodes, tức ít nhất 6 servers.

ELK Stack — Giải pháp Logging không thể thiếu cho DevOps

ELK Stack là giải pháp centralized logging mạnh mẽ và phổ biến nhất hiện nay. Dù đã có nhiều thay đổi về license, Elasticsearch và Kibana vẫn là lựa chọn hàng đầu cho DevOps, System Administrator, và SRE. Theo trải nghiệm thực tế của mình, một ELK Stack được cấu hình đúng cách có thể xử lý hàng chục GB log mỗi ngày mà vẫn cho phép search trong vài mili giây.

Nếu mới bắt đầu với ELK Stack, hãy dùng Docker Compose để chạy local, cấu hình Filebeat trên vài server để gửi log về, và khám phá Kibana Discover. Khi đã tự tin, hãy chuyển sang kiến trúc production với Elasticsearch clustering, message queue (Kafka), và ILM. Còn nếu muốn opensource hoàn toàn, OpenSearch là hướng đi bạn nên cân nhắc — tương thích với Elastic Stack, miễn phí, và không lo vendor lock-in.