Posted inAI

AIOps trong thực tiễn: Sử dụng LLM để phân tích cảnh báo Prometheus và RCA

AI tutorial - IT technology blog
AI tutorial - IT technology blog

Vượt xa tiếng chuông báo thức lúc 3 giờ sáng: Tại sao giám sát thủ công lại thất bại

Các ca trực on-call không nên giống như một trò chơi đoán mò. Hầu hết các kỹ sư DevOps mất 20 phút đầu tiên của một sự cố chỉ để thu thập ngữ cảnh. Bạn thường phải săn tìm pod cụ thể đang bị lỗi, quét log để tìm stack trace, hoặc kiểm tra xem liệu một đợt deployment gần đây có gây ra mức tăng vọt 15% về độ trễ (latency) hay không. Đây là một quy trình thủ công mệt mỏi và làm giảm năng suất.

Prometheus rất xuất sắc trong việc xác định cái gì đang bị hỏng, nhưng nó thiếu logic để giải thích tại sao. Khoảng cách này dẫn đến tình trạng mệt mỏi vì cảnh báo (alert fatigue), nơi các đội ngũ bị vùi lấp dưới hàng trăm thông báo cần mắt người để lọc. Bằng cách tích hợp các Mô hình Ngôn ngữ Lớn (LLM) như một người ứng cứu đầu tiên, chúng ta có thể tự động hóa giai đoạn điều tra ban đầu.

Việc triển khai điều này trong môi trường production thường mang lại kết quả ấn tượng. Trong các dự án gần đây của tôi, luồng công việc này đã giảm Thời gian giải quyết trung bình (MTTR) xuống 40% chỉ bằng cách cung cấp cho các kỹ sư một báo cáo phân tích sẵn trước khi họ đăng nhập vào terminal.

Kết nối Prometheus với các mô hình ngôn ngữ lớn (LLM)

Mục tiêu là xây dựng một cầu nối giữa dữ liệu giám sát của bạn và một LLM như GPT-4o hoặc một instance Llama 3 chạy cục bộ. Chúng ta không chỉ yêu cầu AI tóm tắt một cảnh báo. Thay vào đó, chúng ta muốn nó thực hiện Phân tích Nguyên nhân Gốc rễ (RCA) chuyên sâu bằng cách đánh giá siêu dữ liệu (metadata), các mẫu lịch sử và các hướng dẫn trong runbook.

Kiến trúc luồng công việc (Workflow Architecture)

Pipeline tự động của chúng ta bao gồm năm giai đoạn rõ ràng:

  1. Phát hiện (Detection): Prometheus xác định việc vi phạm ngưỡng, chẳng hạn như rò rỉ bộ nhớ.
  2. Nhóm (Grouping): Alertmanager gom các cảnh báo liên quan và gửi một payload JSON đến một webhook tùy chỉnh.
  3. Làm giàu dữ liệu (Enrichment): Một webhook dựa trên Python sẽ lấy thêm ngữ cảnh, bao gồm các log gần đây hoặc trạng thái pod.
  4. Phân tích (Analysis): LLM xử lý dữ liệu và tạo ra một báo cáo RCA có cấu trúc.
  5. Phân phối (Delivery): Kết quả phân tích cuối cùng xuất hiện trên Slack với giải pháp đề xuất và một nút thực thi.

Hướng dẫn triển khai

Hãy cùng xây dựng một bộ nhận (receiver) bằng Python để xử lý các công việc nặng nhọc. Dịch vụ này sẽ đóng vai trò là lớp trí tuệ trong hệ thống giám sát của bạn.

Bước 1: Định nghĩa cảnh báo Prometheus

Chúng ta cần một cảnh báo chất lượng cao để kích hoạt quy trình. Quy tắc sau đây giám sát việc sử dụng bộ nhớ. Nếu mức tiêu thụ vượt quá 85% trong hơn năm phút, nó sẽ kích hoạt cảnh báo. Lưu tệp này vào alert_rules.yml của bạn.

groups:
- name: host_alerts
  rules:
  - alert: HighMemoryUsage
    expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100 > 85
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "Sử dụng bộ nhớ máy chủ cao trên {{ $labels.instance }}"
      description: "Mức sử dụng bộ nhớ trên 85% trong hơn 5 phút."

Bước 2: Xây dựng LLM Webhook Receiver

FastAPI là công cụ lý tưởng for việc này vì nó nhẹ và xử lý các yêu cầu JSON bất đồng bộ một cách hiệu quả. Script này nắm bắt cảnh báo Prometheus và chuyển tiếp nó đến OpenAI API.

Cài đặt các thư viện cần thiết trước:

pip install fastapi uvicorn openai

Đây là logic cốt lõi cho bộ nhận:

from fastapi import FastAPI, Request
from openai import OpenAI
import os

app = FastAPI()
client = OpenAI(api_key="nhập_api_key_của_bạn_tại_đây")

@app.post("/webhook")
async def prometheus_webhook(request: Request):
    data = await request.json()
    
    for alert in data.get('alerts', []):
        alert_name = alert['labels'].get('alertname')
        instance = alert['labels'].get('instance')
        description = alert['annotations'].get('description')
        
        # Hướng dẫn LLM đóng vai trò là một SRE
        prompt = f"""
        Phân tích cảnh báo Kubernetes sau:
        - Cảnh báo: {alert_name}
        - Instance: {instance}
        - Mô tả: {description}
        
        Cung cấp một báo cáo ngắn gọn bao gồm:
        1. Các nguyên nhân gốc rễ có khả năng xảy ra.
        2. Các lệnh để chẩn đoán (ví dụ: kubectl top pods).
        3. Các bước khắc phục ngay lập tức.
        """
        
        response = client.chat.completions.create(
            model="gpt-4o",
            messages=[{"role": "user", "content": prompt}]
        )
        
        analysis = response.choices[0].message.content
        print(f"--- Kết quả RCA cho {alert_name} ---\n{analysis}")
        
    return {"status": "processed"}

Bước 3: Thiết kế Prompt cho RCA thực tế

Chất lượng của hệ thống AIOps phụ thuộc hoàn toàn vào ngữ cảnh. Nếu bạn chỉ cung cấp tên cảnh báo, AI sẽ đưa ra những lời khuyên chung chung. Để có được câu trả lời cụ thể, bạn phải đưa các runbook nội bộ của mình vào prompt template.

Bằng cách cung cấp cho LLM các đoạn tài liệu của bạn, bạn sẽ biến nó từ một trợ lý thông thường thành một chuyên gia về hạ tầng cụ thể của bạn. Ví dụ: yêu cầu mô hình kiểm tra các lỗi OOM kill cụ thể trong log dmesg nếu nó phát hiện áp lực bộ nhớ.

# Tăng cường ngữ cảnh để có độ chính xác tốt hơn
system_context = """
Bạn là một kỹ sư SRE chuyên gia. Hãy tuân thủ các quy tắc nội bộ sau:
- Đối với các vấn đề về bộ nhớ, hãy xác định 3 tiến trình hàng đầu sử dụng 'top -o %MEM'.
- Kiểm tra xem Java Heap có vượt quá 80% giới hạn của container hay không.
- Tìm kiếm các mẫu 'Out of memory' trong 100 dòng log cuối cùng.
"""

Bước 4: Kích hoạt Alertmanager Webhook

Cuối cùng, cấu hình Prometheus Alertmanager để định tuyến các thông báo đến dịch vụ Python của bạn. Cập nhật cấu hình alertmanager.yml:

receivers:
- name: 'aiops-bridge'
  webhook_configs:
  - url: 'http://your-webhook-server:8000/webhook'

route:
  receiver: 'aiops-bridge'

Con đường dẫn đến hệ thống tự chữa lành (Self-Healing)

Phân tích chỉ là một nửa chặng đường. Bước logic tiếp theo là tự động hóa với sự tham gia của con người (“Human-in-the-loop”). Mặc dù tôi không khuyên bạn nên để LLM tự ý thực thi các lệnh trên máy chủ production, nhưng bạn có thể cung cấp một cầu nối.

Một mô hình phổ biến bao gồm việc thêm một nút tương tác vào cảnh báo trên Slack. Nếu LLM gợi ý xóa thư mục /tmp đang ở mức dung lượng 95%, tin nhắn Slack có thể bao gồm nút [Thực thi dọn dẹp]. Nhấp vào nút này sẽ kích hoạt một Ansible playbook đã được định nghĩa trước.

Cách tiếp cận này duy trì tính bảo mật trong khi loại bỏ nhu cầu làm việc thủ công trên CLI. Thiết lập này sẽ phát triển cùng với hạ tầng của bạn. Khi bạn tinh chỉnh các prompt, kết quả RCA sẽ trở nên chính xác đến mức bạn sẽ có sẵn giải pháp trước cả khi uống xong tách cà phê đầu tiên buổi sáng.

Share:
Tags: