Ba mươi chín phần trước, mỗi phần dựng một hệ trong container, đo một thứ, rồi xoá đi. Phần này gom chúng lại. Nhưng một bài chốt cũng phải có phép đo của riêng nó, và phép đo đúng cho một bài chốt là câu hỏi thực dụng nhất: từ con số không, mất bao lâu để có một cảnh báo thật sự reo?

Danh sach kiem quan sat va cac hang so do duoc qua bon muoi phan

Số đo của bài này

Đo từ lệnh docker network create đầu tiên — chưa có gì cả — tới khoảnh khắc webhook nhận được cảnh báo cho một dịch vụ hỏng thật. Bốn container: exporter, Prometheus, Alertmanager, máy nhận. Ba lần:

Lần Exporter trả lời Chuông reo
1 0,6 s 11,3 s
2 0,6 s 19,4 s
3 0,7 s 19,5 s

Từ con số không đến một cảnh báo được giao tận nơi: 11–20 giây. Biên độ 8 giây chính là thứ đã đo ở phần 34 — lưới thu thập và lưới đánh giá, mỗi cái góp một khoảng chờ ngẫu nhiên.

Con số này đáng để nói ra, vì "dựng hệ giám sát" thường được hình dung là một dự án. Phần lõi của nó — có chỉ số, có luật, có cảnh báo tới được nơi cần tới — là chuyện của hai mươi giây. Cái tốn thời gian là ba mươi chín phần còn lại: biết mình đang đo đúng thứ gì.

Danh sách kiểm

Mười hai dòng, mỗi dòng dẫn về một phép đo trong sê-ri.

Log

  • Ghi log có cấu trúc, và biết chi phí một dòng: print 0,18 µs, logging 4,51 µs, loguru 6,98 µs (phần 2)
  • Xoay vòng log không dùng copytruncate — nó mất 4.317 trong 300.000 dòng mà không báo lỗi (phần 8)
  • Log có mang trace_id — trả thêm 59,8% dung lượng để giảm số dòng phải đọc từ 48.000 xuống 4 (phần 25)

Chỉ số

  • Biết số chuỗi của mình, không chỉ số chỉ số — một Histogram sinh gấp 9 lần một Counter (phần 9)
  • Cảnh báo trên phân vị, không trên trung bình — p50 nhích 3% trong khi p99 tăng 927% (phần 12)
  • Không bao giờ lấy trung bình của phân vị — avg(p99) báo nhẹ đi 4,4 lần đúng lúc có sự cố (phần 13)
  • Cửa sổ rate ít nhất bốn lần chu kỳ thu thập, và step không lớn hơn cửa sổ — sai chỗ này giấu mất 75% chiều cao đỉnh (phần 33)

Trace

  • Kiểm BatchSpanProcessor có đang vứt span không — mặc định vứt 62,5% khi dịch vụ chạy nhanh, và chỉ ghi một dòng log (phần 21)
  • Mọi chặng đều chuyển tiếp traceparent — một chặng quên là tỷ lệ trace đầy đủ rơi từ 9,93% xuống 1,01% (phần 22)

Chính hệ giám sát

  • Có up == 0 cho mọi job — khi mục tiêu biến mất, luật ngưỡng của bạn im lặng hoàn toàn (phần 38)
  • Dead man's switch không đi qua Alertmanager mà nó đang canh — nhịp tim vẫn đập 164–190 giây sau khi Prometheus đã chết (phần 38)
  • Biết trần đĩa của mình, không chỉ trần RAM — đĩa chạm trần sớm hơn 7,3 lần (phần 39)

Bảng hằng số

Những con số dùng lại được để ước lượng, tất cả đều đo trên máy thật:

Đại lượng Giá trị Phần
Một mẫu chỉ số đã nén 2,16 byte 19
Một dòng log 67 byte 31
Một span 135 byte 21
Một pod Kubernetes 187 chuỗi 36
RAM mỗi chuỗi Prometheus 2,07 KB 39
Trace so với chỉ số, cùng lưu lượng gấp 4.178 lần 35
Cả ba lớp bật cùng lúc −12,9% thông lượng 31
Proxy sidecar mỗi request +33,1 µs 37
eBPF mỗi request +1,4 µs 37
Sàn thời gian phát hiện 14,6 giây 34

Với mười dòng này, bạn ước lượng được hoá đơn của gần như mọi cấu hình quan sát mà không cần dựng thử.

Ba trụ cột không thay thế được nhau

Sê-ri mở đầu bằng câu "log, chỉ số, trace" như thể đó là ba lựa chọn. Bốn mươi phần sau, chúng hiện ra là ba thứ trả lời ba câu hỏi khác hẳn, và giá cũng khác hẳn.

Chỉ số trả lời "có chuyện gì không" và rẻ đến mức gần như miễn phí — 2,16 byte một mẫu, 0,12% một lõi cho hai mươi nghìn chuỗi. Nó là thứ duy nhất bạn nên giữ lâu, và phần 35 đã cho thấy ba trong sáu câu hỏi của một báo cáo sau sự cố cần đúng nguồn rẻ nhất này.

Trace trả lời "chuyện xảy ra ở đâu" và đắt gấp 4.178 lần. Phần 20 là ví dụ rõ nhất: hai sự cố khác hẳn nhau cho cùng một con số ở chỉ số, còn trace chỉ thẳng vào svc-c với 101,45 ms tự làm.

Log trả lời "chuyện gì đã xảy ra" và là thứ duy nhất chứa được chi tiết mà bạn không nghĩ trước là sẽ cần.

Sai lầm tốn kém nhất không phải chọn nhầm một trong ba, mà là đặt cùng một thời gian giữ cho cả ba. Phần 32 đã đo: tách thời gian giữ theo từng loại giảm 88% dung lượng mà vẫn giữ chỉ số lâu gấp ba lần.

Hình dạng chung của bốn mươi phần

Đọc lại toàn bộ, có một khuôn lặp đi lặp lại đến mức nó mới là kết luận thật của sê-ri này.

Hầu hết lỗi quan sát không báo lỗi. copytruncate mất dòng mà không kêu. BatchSpanProcessor vứt 62,5% span và ghi đúng một dòng log. Tempo trả về rỗng bốn lần liên tiếp vì bốn giá trị mặc định khác nhau, không lần nào là lỗi. Một tệp thưa của Badger khiến du báo sai 133 lần. Probe eBPF gắn nhầm syscall cho "chi phí bằng không" trông y hệt thành công. Luật dich_vu_hong > 0 im lặng đúng lúc dịch vụ biến mất.

Không cái nào trong số đó hiện ra ở chỗ người ta nhìn. Chúng hiện ra ở một con số vô lý — và chỉ khi có sẵn một con số khác để đối chiếu.

Đó là lý do gần như mọi bài trong sê-ri này đều có một phép kiểm chuẩn bị trước khi đo: 8 200 request thì probe phải thấy 8 200 sự kiện; 200 000 dòng vào Loki thì truy vấn phải đếm ra 200 000; khai 20 000 chuỗi thì count() phải trả về 20 000. Phép kiểm ấy bắt được nhiều lỗi hơn hẳn việc đọc kỹ output.

Và kết quả "không tốn gì" đáng ngờ ngang với kết quả vượt giới hạn vật lý. Tôi đã gặp cả hai: một lần đo băng thông bộ nhớ ra 380 GB/s trên phần cứng làm được 120, và nhiều lần đo ra "chi phí bằng 0". Cái thứ nhất ai cũng nghi ngay. Cái thứ hai thì dễ tin, vì nó là điều ta mong muốn — và nó thường có nghĩa là phép đo không hề chạy.

Chỗ tôi không kết luận được

Toàn bộ sê-ri đo trên một máy, container dùng một lần, không TLS, không nhiều node. Mọi con số nên đọc là bậc độ lớn và hình dạng, không phải dự toán cho hệ của bạn. Tỷ lệ thì bền hơn con số tuyệt đối: "trace tốn gấp bốn nghìn lần chỉ số" sẽ còn đúng khi "43,45 GB mỗi ngày" đã sai.

Và sê-ri này không đo phần khó nhất: liệu người trực có nhìn vào đúng chỗ lúc 2 giờ sáng hay không. Mọi thứ ở trên chỉ là điều kiện cần.

Thử ba mươi giây

Chọn đúng một dòng trong danh sách kiểm ở trên — dòng bạn không chắc chắn nhất — và kiểm nó trên hệ thật của bạn ngay hôm nay.

Nếu phải chọn hộ, tôi chọn dòng up == 0. Nó là một luật, mất ba mươi giây để thêm, và nó bịt đúng kiểu hỏng mà mọi luật khác của bạn đều mù.