Bảng điều khiển có màu xanh lá cây nhưng khách hàng lại phàn nàn rằng việc thanh toán bị hỏng. Nếu bạn đã ở vị trí này, bạn đã hiểu sự khác biệt giữa giám sát và khả năng quan sát. Việc giám sát của bạn chỉ kiểm tra những gì bạn nghĩ cần kiểm tra và lỗi này là một điều gì đó mới mẻ.

Hướng dẫn này giải thích cả hai ý tưởng mà không cần ngôn ngữ tiếp thị và theo dõi một sự cố hư cấu từ cảnh báo đến nguyên nhân cốt lõi. Nhật ký, dấu vết và số được phát minh để minh họa quá trình. Bạn cũng nên biết rằng các nhà cung cấp và những người hành nghề vẽ đường này một cách khác nhau và một số người coi đó một phần là sự phân biệt về mặt tiếp thị. Chúng tôi tập trung vào phần thực tế.

Câu trả lời ngắn gọn

Giám sát là một hoạt động. Bạn quyết định trước những gì cần xem, chẳng hạn như CPU, tỷ lệ lỗi hoặc dung lượng ổ đĩa và bạn đặt các ngưỡng kích hoạt cảnh báo. Nó trả lời: “Có phải điều tôi lo lắng đã xảy ra không?”

Khả năng quan sát là một thuộc tính của hệ thống của bạn. Thuật ngữ này xuất phát từ lý thuyết điều khiển, trong đó nó mô tả mức độ bạn có thể suy ra trạng thái bên trong của hệ thống từ các đầu ra bên ngoài của nó. Trong thực tế, nó trả lời: “Điều gì đang xảy ra và tại sao, kể cả những vấn đề mà tôi chưa bao giờ lường trước được?”

Hãy nghĩ về một chiếc xe hơi. Các đèn cảnh báo trên bảng đồng hồ đang theo dõi. Chúng bao gồm một tập hợp các vấn đề đã biết. Cổng chẩn đoán đầy đủ của thợ cơ khí, cho phép ai đó đặt câu hỏi mới về bất kỳ bộ phận nào của động cơ, gần với khả năng quan sát hơn.

Giám sát và khả năng quan sát cạnh nhau

Đây không phải là sự lựa chọn giữa hai người. Bạn vẫn cần thông báo để cho bạn biết khi nào cần xem xét.

Tại sao chỉ giám sát thôi là chưa đủ

Với một ứng dụng trên một máy chủ, danh sách những sự cố có thể xảy ra khá ngắn nên bạn có thể xem tất cả. Một hệ thống hiện đại có thể có hàng tá dịch vụ, hàng đợi và API của bên thứ ba, cùng với vùng chứa đến và đi. Thất bại trở thành sự kết hợp mà không ai có thể đoán trước được: một khu vực, một loại khách hàng, một phiên bản ứng dụng cụ thể và một sự phụ thuộc chậm chạp.

Bạn không thể viết trước bảng điều khiển cho một câu hỏi mà bạn chưa nghĩ tới. Bạn cần dữ liệu cho phép bạn hỏi nó sau đó.

Nhật ký, số liệu và dấu vết

Ba loại phép đo từ xa này thường được gọi là trụ cột của khả năng quan sát. Mỗi người trả lời một câu hỏi khác nhau:

Số liệu

http_requests_total{service="checkout", status="500"} 1832
http_request_duration_seconds{service="checkout", quantile="0.95"} 2.4

Các số liệu có chi phí lưu trữ thấp và truy vấn nhanh, điều này khiến chúng trở nên lý tưởng cho trang tổng quan và cảnh báo. Hãy cảnh giác với các nhãn có lượng số cao, chẳng hạn như ID người dùng, trong nhiều hệ thống số liệu vì chúng có thể làm tăng mạnh chi phí.

Dấu vết

Dấu vết theo sau một yêu cầu trên các dịch vụ. Mỗi bước là một span với thời gian bắt đầu và thời lượng:

POST /checkout                      2410 ms
├─ auth-service: verify token         18 ms
├─ cart-service: load cart            42 ms
├─ pricing-service: calculate       2290 ms   <-- slow
│  └─ SELECT coupons ...            2265 ms
└─ payment-service: not reached

Dấu vết làm cho bước chậm trở nên rõ ràng, rất khó nhìn thấy trong nhật ký riêng biệt với các dịch vụ riêng biệt.

Nhật ký

Nhật ký cung cấp chi tiết về những gì đã xảy ra tại một thời điểm. Chúng tôi xem xét cách làm cho chúng hữu ích trong giây lát.

Hướng dẫn sự cố

Đây là cách các mảnh khớp với nhau, trong một ví dụ hư cấu.

Giám sát được xử lý ở bước 1. Mọi thứ sau đó là khả năng quan sát được. Lưu ý mỗi câu hỏi đến từ câu trả lời trước đó như thế nào. Không ai có thể xây dựng trước một trang tổng quan cho “truy vấn phiếu giảm giá ứng dụng di động từ chiến dịch ngày hôm nay”. Để khắc phục, hướng dẫn của chúng tôi về Tối ưu hóa truy vấn SQL sẽ chỉ ra cách đọc loại kế hoạch đó.

Nhật ký tốt hơn

Nhật ký văn bản thuần túy được tạo cho mắt người và khó truy vấn. Nhật ký có cấu trúc sử dụng các trường mà máy có thể lọc:

# Hard to search
ERROR Payment failed for user 42 after 3 tries

# Easy to search
{"level":"error","event":"payment_failed","user_id":"42",
 "attempts":3,"provider":"acme","trace_id":"a1b2c3","duration_ms":2410}

Với biểu mẫu thứ hai, bạn có thể hỏi ngay “có bao nhiêu nhà cung cấp thất bại trong một giờ qua?” Trường trace_id đặc biệt có giá trị vì nó liên kết dòng nhật ký với toàn bộ yêu cầu, trên mọi dịch vụ mà nó chạm vào.

Không bao giờ đăng nhập mật khẩu, mã thông báo hoặc số thẻ và cẩn thận với dữ liệu cá nhân. Như hướng dẫn của chúng tôi giải thích, JWT có thể được sử dụng lại bởi bất kỳ ai đọc chúng từ nhật ký.

Những tín hiệu vàng

Bạn không chắc chắn nên theo dõi những gì? Cuốn sách Kỹ thuật độ tin cậy trang web của Google gợi ý bốn tín hiệu cho các hệ thống hướng tới người dùng:

Sử dụng phần trăm cho độ trễ, vì mức trung bình sẽ ẩn các yêu cầu chậm, như chúng tôi đã trình bày trong thử nghiệm tải so với thử nghiệm căng thẳng.

Cảnh báo mọi người tin tưởng

Nếu cảnh báo liên tục xuất hiện, mọi người sẽ ngừng đọc chúng. Những cái tốt tuân theo một số quy tắc:

• Cảnh báo về các triệu chứng mà người dùng cảm thấy. “Lỗi thanh toán trên 2%” đánh bại “CPU ở mức 85%”. CPU cao mà không hại ai thì không nên đánh thức ai cả.
• Làm cho mọi cảnh báo có thể thực hiện được. Nếu không ai cần làm gì, hãy đặt cảnh báo đó thành một mục trên trang tổng quan hoặc xóa cảnh báo đó.
• Liên kết tới sổ tay. Nói cho người trả lời biết nơi cần tìm và những gì cần thử.
• Xem lại chúng thường xuyên. Xóa hoặc sửa bất kỳ cảnh báo nào bị bỏ qua trong tháng trước.

Mục tiêu cấp độ dịch vụ

SLO biến “trang web phải nhanh và đáng tin cậy” thành mục tiêu có thể đo lường được, chẳng hạn như “99,9% yêu cầu thanh toán thành công sau 30 ngày”. Điều đó cho phép xảy ra khoảng 0,1% số lần thất bại, được gọi là ngân sách lỗi. Nếu còn nhiều, bạn có thể vận chuyển nhanh hơn và nếu gần hết, bạn có thể ưu tiên độ tin cậy. Đó là một cách hữu ích để giải quyết các tranh cãi giữa tốc độ phân phối và độ ổn định.

OpenTelemetry và các công cụ

OpenTelemetry là một tiêu chuẩn nguồn mở, trung lập với nhà cung cấp để tạo và xuất dữ liệu đo từ xa. Đây là một dự án của Tổ chức Điện toán Đám mây. Việc trang bị nó có nghĩa là bạn có thể thay đổi phần phụ trợ sau này mà không cần viết lại mã. Bản thân nó không phải là sản phẩm lưu trữ hoặc bảng điều khiển, vì vậy bạn kết hợp nó với một sản phẩm:

Hãy tự kiểm tra các tính năng hiện tại và định giá vì những sản phẩm này thay đổi thường xuyên. Chi phí có thể tăng nhanh theo khối lượng dữ liệu, vì vậy hãy sử dụng phương pháp lấy mẫu và đặt giới hạn lưu giữ.

Làm thế nào để bắt đầu

1. Bắt đầu với những tín hiệu vàng cho dịch vụ quan trọng nhất của bạn.
2. Thêm một hoặc hai cảnh báo về các triệu chứng mà người dùng nhận thấy.
3. Chuyển sang nhật ký có cấu trúc, có ID yêu cầu ở mỗi dòng.
4. Thêm tính năng theo dõi vào hành trình người dùng chính của bạn với OpenTelemetry, vì công cụ đo lường tự động có thể bao gồm nhiều khung phổ biến.
5. Liên kết các hoạt động triển khai với biểu đồ của bạn, để bạn có thể biết liệu bản phát hành từ quy trình CI/CD của bạn có gây ra thay đổi hay không.
6. Tìm hiểu từ mỗi sự cố. Sau mỗi sự cố, hãy hỏi xem dữ liệu nào sẽ giúp giải quyết nhanh hơn và bổ sung dữ liệu đó.

Một nhóm nhỏ với một dịch vụ không cần một nền tảng lớn. Số liệu cơ bản, nhật ký tốt và một vài cảnh báo có thể rất nhiều. Truy tìm kiếm được lợi nhuận khi số lượng dịch vụ tăng lên.

Những lỗi thường gặp

• Mua một công cụ và gọi nó là khả năng quan sát. Giá trị đến từ công cụ đo lường tốt và cách bạn sử dụng dữ liệu.
• Xử lý ba trụ cột như một danh sách kiểm tra. Phân tách dữ liệu mà không có cách nào để liên kết dữ liệu đó khiến bạn phải tìm kiếm khắp các tab. ID được chia sẻ quan trọng.
• Thu thập mọi thứ. Việc đo từ xa không được lọc sẽ trở nên đắt đỏ và gây thêm tiếng ồn.
• Quá nhiều trang tổng quan. Một vài lượt xem đáng tin cậy đánh bại cả trăm lượt xem mà không ai mở.
• Suy nghĩ rằng nó thay thế việc thử nghiệm. Bạn vẫn cần thử nghiệm trước khi phát hành. Tuy nhiên, các bản phát hành của Canary kết hợp tốt với các tín hiệu này.

Lời kết

Việc giám sát cho bạn biết có điều gì đó không ổn và khả năng quan sát cho bạn phương tiện để tìm hiểu lý do. Thử nghiệm thực tế rất đơn giản: khi một vấn đề lạ xuất hiện, bạn có thể tìm ra nguyên nhân mà không cần gửi mã mới không? Lần tới khi bạn gặp sự cố, hãy viết ra mọi câu hỏi mà bạn không thể trả lời. Danh sách đó là lộ trình của bạn.

Câu hỏi thường gặp

Tiếp tục học hỏi