Cài đặt và cấu hình Vector: Pipeline gom log hiệu năng cao thay thế Logstash

Monitoring tutorial - IT technology blog
Monitoring tutorial - IT technology blog

So sánh các giải pháp Pipeline Log phổ biến hiện nay

Trước khi chuyển sang Vector, team mình từng vật lộn với bài toán gom log từ hơn 40 microservices. Cứ đến đợt flash sale, lưu lượng log vọt lên 50GB mỗi giờ. Lúc này, shipper truyền thống bắt đầu nghẽn cổ chai và ngốn sạch tài nguyên cụm máy chủ.

Ba công cụ phổ biến nhất anh em DevOps thường cân nhắc gồm:

  • Logstash (Elastic Stack): Chạy trên JVM. Kho plugin bạt ngàn, viết grok tiện nhưng cực kỳ nặng. Khởi động xong một instance trống đã mất đứt 1GB đến 2GB RAM. Khi tải nặng, garbage collection dừng đột ngột khiến dữ liệu đọng lại cả hàng đợi.
  • Fluentbit: Viết bằng C nên rất nhẹ, chỉ tốn vài chục megabyte bộ nhớ. Công cụ này cực hợp để gom log pod trên Kubernetes node. Đổi lại, khâu enrich và parse chuỗi phức tạp khá gò bó, cấu hình config file qua nhiều tầng rất dễ nhầm lẫn.
  • Vector (Datadog open-source): Viết bằng Rust, an toàn bộ nhớ tuyệt đối. Instance chạy thực tế chỉ ăn tầm 40MB đến 80MB RAM. Đặc biệt, ngôn ngữ VRL (Vector Remap Language) đi kèm cho phép xử lý dữ liệu sâu mà không làm giảm thông lượng.

Phân tích ưu nhược điểm: Logstash vs Vector

Bảng so sánh thực tế sau sẽ giúp bạn dễ quyết định trước khi tái cấu trúc pipeline:

Tiêu chí Logstash Vector
Ngôn ngữ & Runtime Java (JVM), phụ thuộc JRE/JDK Rust, native binary duy nhất, không phụ thuộc môi trường
Mức ăn RAM khi chạy thực tế 1.5GB – 4GB RAM cho throughput trung bình 40MB – 120MB RAM ở cùng mức tải
Engine biến đổi dữ liệu Grok, Mutate, Ruby script (chạy chậm) Vector Remap Language (VRL) – JIT compiled, type-safe
Phạm vi dữ liệu Chuyên logs, xử lý metrics khá gượng ép Hỗ trợ trọn vẹn cả Logs, Metrics lẫn Traces
Độ phong phú của Sink Lâu năm, hỗ trợ mọi hệ thống lưu trữ Đầy đủ các sink chính: Kafka, S3, ClickHouse, ES, Loki

Khi nào nên đổi sang Vector?

Hạ tầng của mình chạy cụm Kubernetes 15 node. Trước đây, mỗi lần service bung lỗi 500 hàng loạt, Logstash trên node gom log lập tức dính OOM kill. CPU chạm trần 100%. Toàn bộ luồng cảnh báo trên Grafana bị trễ tới 10 phút, khiến team mất dấu nguyên nhân gốc rễ.

Bạn nên cân nhắc đổi sang Vector ngay trong các trường hợp sau:

  • Cần cắt giảm chi phí hạ tầng: Cùng mốc tải 50,000 events/giây, Vector chỉ ăn khoảng 1 core CPU và 90MB RAM. Logstash cần tới 4 core cùng 3GB RAM.
  • Muốn tinh gọn agent: Một binary duy nhất vừa đọc file log Nginx, vừa lấy Docker container log, vừa đẩy song song về cả ClickHouse để query lẫn S3 để lưu trữ lạnh.
  • Cần validate log an toàn: VRL bắt buộc xử lý trường hợp lỗi null và parse fail, tránh nguy cơ crash cả tiến trình giữa chừng.

Triển khai thực tế: Thu thập và parse log Nginx sang Elasticsearch

Ví dụ dưới đây sẽ lấy access log của Nginx, bóc tách chuỗi thô thành JSON chuẩn qua VRL, rồi đẩy thẳng vào Elasticsearch.

Bước 1: Cài đặt Vector trên Ubuntu/Debian

Datadog duy trì kho APT chính thức cho Vector. Cách này giúp cập nhật phiên bản mới và quản lý service qua systemd thuận tiện nhất.

# Thêm kho APT chính thức của Vector
curl -1sLf 'https://repositories.timber.io/public/vector/cfg/setup/bash.deb.sh' | sudo -E bash

# Cài đặt gói vector
sudo apt-get update
sudo apt-get install -y vector

# Kiểm tra binary
vector --version

Bước 2: Cấu trúc 3 thành phần của Vector

Pipeline của Vector thiết lập bằng YAML hoặc TOML, xoay quanh đúng 3 khối:

  1. Sources: Nguồn thu thập dữ liệu (file log, syslog, journald, socket, stdin…).
  2. Transforms: Khâu bóc tách và làm sạch (parse chuỗi, ép kiểu dữ liệu, gán nhãn IP, lọc bỏ log vô nghĩa).
  3. Sinks: Đích nhận dữ liệu (Elasticsearch, Kafka, ClickHouse, VictoriaLogs, S3…).

Bước 3: Viết pipeline xử lý log Nginx

Mở file /etc/vector/vector.yaml và dán cấu hình sau:

# 1. SOURCES: Đọc file access log của Nginx
sources:
  nginx_access_logs:
    type: "file"
    include:
      - "/var/log/nginx/access.log"
    read_from: "beginning"

# 2. TRANSFORMS: Parse chuỗi bằng VRL
transforms:
  parse_nginx:
    type: "remap"
    inputs:
      - "nginx_access_logs"
    source: |
      # Bóc tách định dạng Combined Log Format qua regex
      parsed, err = parse_regex(.message, r'^(?P<remote_addr>[\d\.]+) - (?P<remote_user>[^ ]*) \[(?P<time_local>[^\]]+)\] "(?P<request_method>[A-Z]+) (?P<request_uri>[^ ]+) (?P<server_protocol>[^"]+)" (?P<status>\d+) (?P<body_bytes_sent>\d+)')
      
      if err != null {
        .parse_status = "failed"
      } else {
        ., err = merge(., parsed)
        .status = to_int!(.status)
        .body_bytes_sent = to_int!(.body_bytes_sent)
        .parse_status = "success"
      }
      
      # Gắn thêm nhãn server phục vụ truy vấn
      .host = get_hostname!()
      .service = "nginx-gateway"

# 3. SINKS: Đẩy log vào Elasticsearch và in ra màn hình debug
sinks:
  es_cluster:
    type: "elasticsearch"
    inputs:
      - "parse_nginx"
    endpoints:
      - "http://10.0.0.50:9200"
    mode: "bulk"
    bulk:
      index: "logs-nginx-%Y.%m.%d"
    auth:
      strategy: "basic"
      user: "elastic"
      password: "SecretPassword123"

  stdout_debug:
    type: "console"
    inputs:
      - "parse_nginx"
    encoding:
      codec: "json"

Bước 4: Kiểm tra cú pháp và bật service

Vector tích hợp sẵn tính năng kiểm tra lỗi cú pháp trước khi chạy. Lệnh này giúp bạn tránh rủi ro sập pipeline do viết sai indentation hay thiếu biến:

# Validate file cấu hình
vector validate --config /etc/vector/vector.yaml

# Kích hoạt và khởi động service
sudo systemctl enable --now vector

# Theo dõi tiến trình xử lý
sudo journalctl -u vector -f

Chỉ cần cấu hình hợp lệ, Vector sẽ đọc access log ngay lập tức. Các trường remote_addr, status, request_uri được bóc tách gọn gàng thành JSON và đẩy về Elasticsearch với độ trễ chưa tới 20ms.

Share: