Observability

"Web có bị sập không?"

Không có observability, điều đầu tiên bạn biết về một lần sập là tin nhắn từ một người không dùng được sản phẩm của bạn.

web hỏng trong im lặng · user là cảm biến duy nhất của bạn · observability xóa bỏ đúng phần đó

Một câu hỏi, cả ngày dài

Mọi thứ ở chủ đề này đều để trả lời cùng ba điều, nhanh hơn và sớm hơn cả user.

Ba trụ cột

Bạn hiếm khi cần cả ba phải hoàn hảo — nhưng phải biết mỗi thứ là gì.

Ba câu trả lời cho "đang xảy ra gì?"

App của bạn tạo ra cả ba. Công cụ khác nhau thu thập từng loại — và câu hỏi khác nhau dẫn bạn tới từng loại.

hôm nay tập trung uptime + metrics — hai thứ giữ cho web sống

Nhìn thấy nó. Rồi được đánh thức.

Observability gồm hai nửa, phải có cả hai — thiếu một nửa thì chưa đủ.

Ba công cụ, một việc

Làm quen với các nhân vật trước khi vào truyện. Mỗi thứ làm một việc mà các thứ kia không làm được.

Một trình kiểm tra, nằm ngoài app

Ý chính: trình kiểm tra <b>không phải</b> app của bạn. Nó theo dõi từ bên ngoài, như y tá đo mạch.

Vài phút cũng quan trọng

Giám sát uptime là cách rẻ nhất, nhanh nhất để phát hiện kiểu hỏng tệ nhất: sập toàn bộ.

Cái dễ nhất

Uptime Kuma là trình kiểm tra uptime mã nguồn mở, tự host. Bạn chạy nó trong một container và nó chạy trong chính stack của bạn.

Uptime Kuma trong docker compose

Một service, một cổng, một volume cho dữ liệu. Đó là toàn bộ việc triển khai.

services:
  uptime-kuma:
    image: "louislam/uptime-kuma:1"   # the official image
    container_name: uptime-kuma
    restart: unless-stopped              # come back after a reboot
    ports:
      - "3001:3001"                    # your browser -> the web UI
    volumes:
      - kuma-data:/app/data             # heartbeats + settings survive

rồi: docker compose up -d → mở http://your-vps:3001

Chạy trong ba lệnh

Khởi động, kiểm tra nó chạy, và xác nhận web trả lời.

Kiểm tra → ghi nhận → (có thể) cảnh báo

Vòng lặp nhỏ này, chạy mỗi phút, là toàn bộ sản phẩm.

thành công = im lặng (bạn không muốn tin nhắn mỗi phút) · thất bại = ồn ào

Metrics vs logs

Chúng là hai hình dạng dữ liệu khác nhau, và mỗi thứ trả lời một câu hỏi khác.

Sáu con số đáng một dashboard

Bạn sẽ không bao giờ học thuộc mọi metrics — sáu con số này bao phủ phần lớn thứ mà người vận hành thật sự theo dõi.

Một scrape_config nhỏ

Prometheus hỏi: "mỗi 15 giây, tới địa chỉ này và lấy /metrics." Đó là toàn bộ config.

scrape_configs:
  - job_name: "myapp"             # a named target to scrape
    scrape_interval: 15s              # how often to pull
    metrics_path: /metrics            # the endpoint with the numbers
    static_configs:
      - targets: ["localhost:5000"]  # where the app listens

app của bạn chỉ cần mở một endpoint /metrics — phần kế tiếp

Prometheus tự tìm tới bạn

Đây là phần khiến nhiều người bất ngờ: app của bạn <b>không</b> đẩy metrics ra ngoài. Prometheus ghé vào và kéo chúng.

Vòng kéo, mỗi 15 giây

Không push, không gửi. Prometheus giữ một danh sách địa chỉ /metrics và cứ hỏi, theo lịch.

nếu một target biến mất, Prometheus nhận ra cú kéo thiếu — đó cũng là một cảnh báo có sẵn

Một truy vấn PromQL

Bạn sẽ không tự viết nhiều thứ này — nhưng hãy nhận ra hình dạng: <b>một metric, một cửa sổ, một hàm</b>.

# how many requests per second, averaged over 5 minutes:
rate(http_requests_total[5m])

# and the p95 latency (95% of requests were faster than this):
histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))

đừng học thuộc cú pháp — ý tưởng là "metric + khoảng thời gian + thứ bạn muốn"

Một con số + một mốc giờ

Mọi metrics Prometheus giữ là một chuỗi thời gian: cùng một tên, đo lặp đi lặp lại.

Dữ liệu vs dashboard

Một cặp hay xuất hiện khắp nơi — một bên lưu, một bên hiển thị.

Một dashboard trong một cái nhìn

Các panel của metrics, đặt cạnh nhau. Màu xanh nghĩa là khỏe — bạn quét qua trong hai giây.

một dashboard kể một chuyện: độ trễ tăng, lỗi tăng, CPU leo — có vấn đề, và bạn là người thấy trước

Cảnh báo: một luật biết gào lên

Dashboard chỉ hữu ích nếu bạn đang nhìn. Cảnh báo hữu ích khi bạn không đang nhìn.

Con số → luật → điện thoại bạn

Ba mắt xích. Gãy một, chuông báo sẽ im lặng.

luật nằm trong Prometheus · việc gửi có thể dùng lại kênh của Uptime Kuma hay kênh riêng (webhook → bot)

Cảnh báo thứ gì

Ít mà ồn tốt hơn nhiều mà im. Bắt đầu với bốn cái này.

App + Uptime Kuma + Prometheus + Grafana

Một file compose, bốn service, bốn cổng trong trình duyệt. Đây là một bộ khung thật, chạy được.

services:
  app:          # your app, exposing /metrics
    image: "myapp:latest"
    ports: ["5000:5000"]
  uptime-kuma:  # is it reachable? (port 3001)
    image: "louislam/uptime-kuma:1"
    ports: ["3001:3001"]
  prometheus:   # pulls app:5000/metrics (port 9090)
    image: "prom/prometheus:latest"
    ports: ["9090:9090"]
    volumes: ["./prometheus.yml:/etc/prometheus/prometheus.yml"]
  grafana:      # reads prometheus, draws dashboards (port 3000)
    image: "grafana/grafana:latest"
    ports: ["3000:3000"]

docker compose up -d → bốn URL nhỏ: :3001, :9090, :3000 — cùng app của bạn ở :5000

Ai nuôi ai

Hai chuỗi độc lập, đều bắt đầu từ app của bạn. Một chuỗi nhanh và đơn giản; một chuỗi đi sâu.

cùng một app, hai con mắt · uptime cho kịch bản tệ nhất, metrics cho mọi thứ ở giữa

Người vận hành thật sự làm gì

Observability không phải cài đặt một lần — nó là một vòng lặp ngắn, lặp lại.

1. 1

   Quét qua dashboard

   Grafana, hai giây: xanh = khỏe. Đó là toàn bộ việc làm vào một ngày tốt.

2. 2

   Được gọi

   Cảnh báo rơi vào Telegram/Zalo: "tỷ lệ lỗi cao". Giờ bạn đi xem — không phải đoán.

3. 3

   Đọc bức tranh

   Metrics nào dịch chuyển? Bắt đầu lúc nào? Khớp với một lần deploy không? Dashboard + vài dòng logs trả lời.

4. 4

   Sửa, rồi xem nó hồi phục

   Ship bản sửa và xem đường cong quay xuống. Đồ thị xác nhận — chứ không phải cảm giác.

Những gì không học ở đây

Dưới bề mặt là cả một ngành. Bài này cho bạn tấm bản đồ, chứ không phải lãnh thổ.