Giám sát Kubernetes hợp nhất: Hướng dẫn thực hành Grafana Alloy

Table of Contents

Thực trạng hỗn loạn khi bùng nổ Agent

Triển khai observability (khả năng quan sát) trên Kubernetes thường mang lại cảm giác như đang quản lý một đội quân robot hoạt động độc lập. Trong nhiều năm, chiến lược phổ biến là một “mảnh vá” chắp vá: Promtail cho log, Node Exporter cho thông số phần cứng, và có thể là một OpenTelemetry Collector cho trace. Mỗi loại đều yêu cầu ConfigMap riêng, mức tiêu thụ CPU/memory riêng và chu kỳ nâng cấp riêng.

Tình trạng “bùng nổ agent” (agent sprawl) này ảnh hưởng đến hai thứ: túi tiền và sự tỉnh táo của bạn. Trên một cụm 50 node, việc chạy bốn agent riêng biệt trên mỗi node gây lãng phí tài nguyên đáng kể. Tệ hơn nữa, việc tương quan dữ liệu là một cơn ác mộng. Nếu collector thu thập log gắn nhãn cho pod là app_name nhưng collector thu thập metric lại gọi nó là container_label_app, các dashboard Grafana của bạn chắc chắn sẽ bị lỗi vào đúng thời điểm xảy ra sự cố nghiêm trọng.

Tại sao các Collector cũ đang dần bị thay thế

Tại sao mọi thứ lại phức tạp như vậy? Trong quá khứ, log, metric và trace được coi là ba vương quốc riêng biệt. Các công cụ được xây dựng trong các silo tách biệt. Promtail là chuyên gia cho Loki, trong khi Prometheus agent chỉ sống vì metric. Chúng không được thiết kế để chia sẻ bộ não hoặc ngôn ngữ cấu hình chung.

Chúng ta đã đạt đến điểm mà một collector duy nhất, hợp nhất sẽ hợp lý hơn nhiều. Grafana Alloy là phiên bản kế nhiệm của Grafana Agent. Nó là một công cụ mạnh mẽ, không phụ thuộc vào nhà cung cấp (vendor-agnostic), hỗ trợ thông thạo cả OpenTelemetry (OTel) và Prometheus. Nó sử dụng ngôn ngữ cấu hình có thể lập trình được—lấy cảm hứng mạnh mẽ từ HCL—cho phép bạn xây dựng các data pipeline như đang viết code.

Tôi đã triển khai công cụ này trong các môi trường production để thay thế stack đa agent cũ. Kết quả đến ngay lập tức: chúng tôi thấy mức sử dụng bộ nhớ giảm 35% trên các worker node. Quan trọng hơn, chúng tôi không còn phải vật lộn với metadata không khớp vì chỉ có một công cụ duy nhất xử lý mọi thứ.

Bước 1: Chuẩn bị môi trường Kubernetes

Bạn sẽ cần một cụm cluster đang hoạt động và Helm đã sẵn sàng. Chúng ta sẽ triển khai Alloy dưới dạng DaemonSet. Điều này đảm bảo rằng mỗi node trong cụm của bạn có chính xác một instance Alloy để thu thập log cục bộ và metric hệ thống.

# Thêm repository Helm của Grafana
helm repo add grafana https://grafana.github.io/helm-charts
helm repo update

Hãy giữ mọi thứ gọn gàng bằng cách tạo một namespace riêng cho các công cụ giám sát:

kubectl create namespace observability

Bước 2: Triển khai Grafana Alloy qua Helm

Chúng ta sẽ không sử dụng các thiết lập mặc định ở đây. Để tận dụng tối đa Alloy, chúng ta cần kích hoạt chế độ “Flow”. Đây là tiêu chuẩn mới cho các pipeline có thể lập trình. Hãy tạo một file values.yaml để định nghĩa cấu trúc triển khai.

alloy:
  type: 'daemonset'
  storagePath: /var/lib/alloy
  configMap:
    create: true
    content: "" # Chúng ta sẽ chèn logic ở Bước 3
controller:
  replicas: 1

Tiến hành cài đặt với các giá trị tùy chỉnh của bạn:

helm install alloy grafana/alloy -f values.yaml -n observability

Bước 3: Xây dựng Pipeline hợp nhất

Cấu hình Alloy mang lại cảm giác như đang lắp ghép các khối Lego. Bạn định nghĩa một source (nơi dữ liệu bắt đầu), một processor (cách thay đổi dữ liệu) và một sink (nơi dữ liệu kết thúc). Điều này cho phép bạn điều hướng log và metric thông qua cùng một logic.

Cập nhật cấu hình của bạn để xử lý cả log Kubernetes và metric từ Node Exporter cùng một lúc:

// 1. Tìm và thu thập log của pod
discovery.kubernetes "pod_logs" {
  role = "pod"
}

loki.source.kubernetes "local_pods" {
  targets    = discovery.kubernetes.pod_logs.targets
  forward_to = [loki.write.grafana_cloud_loki.receiver]
}

// 2. Thu thập hardware metric (Thay thế cho Node Exporter)
prometheus.exporter.unix "node_stats" {
}

prometheus.scrape "scrape_node_stats" {
  targets    = prometheus.exporter.unix.node_stats.targets
  forward_to = [prometheus.remote_write.grafana_cloud_prom.receiver]
}

// 3. Gửi mọi thứ đến backend của bạn
loki.write "grafana_cloud_loki" {
  endpoint {
    url = "http://loki-gateway.observability.svc.cluster.local/loki/api/v1/push"
  }
}

prometheus.remote_write "grafana_cloud_prom" {
  endpoint {
    url = "http://prometheus-server.observability.svc.cluster.local/api/v1/write"
  }
}

Thiết lập này thay thế hiệu quả cho cả Promtail và Node Exporter. Vì một agent xử lý cả hai luồng dữ liệu, nhãn container_name trên log của bạn sẽ khớp hoàn toàn với container_name trên metric CPU. Không còn phải đoán mò trong những lần xử lý sự cố lúc 2 giờ sáng nữa.

Bước 4: Xác minh và Debug

Alloy bao gồm một giao diện UI tích hợp sẵn, là cứu cánh để debug các pipeline phức tạp. Nó trực quan hóa luồng dữ liệu của bạn và cho bạn thấy chính xác nơi nào pipeline có thể bị lỗi. Truy cập nó thông qua port-forwarding:

kubectl port-forward svc/alloy 12345:12345 -n observability

Truy cập http://localhost:12345. Bạn sẽ thấy biểu đồ trực tiếp của các thành phần. Nếu Loki gặp sự cố hoặc một job scrape bị lỗi, thành phần đó sẽ chuyển sang màu đỏ. Nó thậm chí còn cung cấp thông báo lỗi cụ thể từ log nội bộ của collector.

Để kiểm tra lại đầu ra thô từ terminal, chỉ cần xem log của pod Alloy:

kubectl logs -l app.kubernetes.io/name=alloy -n observability

Kinh nghiệm thực tế cho môi trường Production

Trước khi đẩy cấu hình này lên cụm production, hãy thiết lập một số giới hạn (guardrails). Alloy hoạt động hiệu quả, nhưng một đợt bùng phát log đột ngột (như một ứng dụng bị kẹt trong vòng lặp crash) có thể làm tăng vọt mức sử dụng bộ nhớ. Tôi thường bắt đầu với giới hạn 500m CPU và 512MB RAM cho các node có kích thước trung bình.

Đừng quên OpenTelemetry. Nếu team của bạn bắt đầu sử dụng OTel SDK, bạn không cần cài đặt thêm bất cứ thứ gì khác. Chỉ cần thêm thành phần otelcol.receiver.otlp vào cấu hình Alloy hiện có. Nó sẽ chấp nhận các trace qua gRPC và tự động định dạng chúng cho backend của bạn. Sự linh hoạt này là điều khiến Alloy trở thành lựa chọn lâu dài cho các đội ngũ DevOps.

Hợp nhất stack của bạn với Alloy không chỉ là để tiết kiệm tài nguyên. Đó là về việc giảm nợ kỹ thuật (technical debt). Bạn thoát khỏi cơn đau đầu “mỗi trụ cột một công cụ” và hướng tới một kiến trúc thống nhất, thực sự dễ dàng để mở rộng.