Phân biệt log metric và trace khi chẩn đoán

Khi khách hàng báo một giao dịch chậm, ba bảng theo dõi có thể kể ba câu chuyện khác nhau. Việc chẩn đoán đầu tiên là hỏi từng nguồn thực sự đo điều gì. Đừng coi mọi biểu đồ và bản ghi sự kiện là bằng chứng thay thế cho nhau. Giao mục đích cho từng tín hiệu, rồi nối chúng quanh cùng dịch vụ, thao tác và khoảng thời gian.

Gắn mỗi tín hiệu với một câu hỏi

OpenTelemetry mô tả trace là đường đi của yêu cầu qua ứng dụng, metric là phép đo trong lúc chạy và log là bản ghi sự kiện.[4] Các định nghĩa này là điểm khởi đầu hữu ích. Hỏi metric về phạm vi và xu hướng, trace về một đường đi cụ thể, log về sự kiện giải thích một quyết định.

Một yêu cầu chậm không chứng minh mọi khách hàng đều gặp vấn đề. Tương tự, số tổng hợp bình thường không đủ để bác bỏ một hành trình thất bại cụ thể. Trước khi kết luận, nêu rõ bằng chứng mô tả một sự kiện, một mẫu được chọn hay toàn bộ tập đã tổng hợp.

Nối ngữ cảnh trước khi tăng khối lượng

Chọn tên dịch vụ, nhãn môi trường và mã tương quan nhất quán. Mã tương quan nối các quan sát liên quan mà không cần ghi tên khách hàng vào mọi sự kiện. Yêu cầu nhóm chứng minh có thể theo một yêu cầu đã chọn qua những thành phần liên quan.

Quyết định trường nào được phép đưa vào dữ liệu quan sát và ai được xem. Loại giá trị bí mật cùng dữ liệu cá nhân không cần thiết khỏi thiết kế chẩn đoán. Đồng thời ghi cách lưu giữ và lấy mẫu. Nếu một số yêu cầu không được thu thập, việc không có trace không thể trở thành bằng chứng rằng sự kiện chưa từng xảy ra.

Yêu cầu trình diễn khả năng chẩn đoán

Trước khi mua gói quan sát lớn hơn, yêu cầu trình diễn bằng lưu lượng thử đại diện và một lỗi được chủ động tạo ra trong phạm vi kiểm soát.

• Xác định metric mô tả thao tác người dùng bị ảnh hưởng.
• Theo một yêu cầu được chọn qua ranh giới dịch vụ.
• Tìm sự kiện liên quan bằng mã tương quan chung.
• Cho người rà soát thấy cách thể hiện lấy mẫu và thiếu dữ liệu.
• Kiểm tra đầu ra không chứa giá trị bí mật hoặc trường cá nhân không cần thiết.

Ví dụ giả định: phê duyệt tài liệu chậm

Trong ví dụ giả định này, ứng dụng phê duyệt có độ trễ hoàn tất tăng lên. Metric giúp nhóm xác định thao tác và giai đoạn bị ảnh hưởng. Một trace được chọn cho thấy yêu cầu mất thời gian chờ bước chuyển đổi tài liệu.

Log liên quan cho thấy định dạng tài liệu của yêu cầu đó bị từ chối. Nhóm phân biệt lỗi định dạng với các lượt phê duyệt chậm khác trước khi chọn cách sửa. Tình huống minh họa chuỗi câu hỏi, không khẳng định công cụ luôn tìm ra nguyên nhân.

Chi theo quyết định cần đưa ra

Sự kiện chi tiết và trace rộng có thể cần thêm lưu trữ, xử lý và công sức rà soát. Metric tổng hợp dễ so sánh hơn nhưng có thể thiếu ngữ cảnh của một lỗi khác thường. Chọn mức cân bằng theo câu hỏi mà nhóm cần trả lời.

Giữ bản ghi chẩn đoán ngắn, tách quan sát khỏi giả thuyết. Trước khi sửa mã, hỏi bằng chứng có hỗ trợ cách giải thích đề xuất không và quan sát nào có thể bác bỏ nó. Hệ thống quan sát hữu ích hỗ trợ lập luận đó, không thay thế lập luận.