Quan sát ứng dụng là thực tiễn thu thập và phân tích telemetry để hiểu ứng dụng đang làm gì, tại sao nó hành xử theo một cách nhất định, và người dùng bị ảnh hưởng như thế nào. Nó thường kết hợp các chỉ số, nhật ký, dấu vết, sự kiện và ngữ cảnh ứng dụng liên quan.
Các ứng dụng hiện đại có thể trải dài từ API, microservices, cơ sở dữ liệu, hàng đợi, cơ sở hạ tầng đám mây đến dịch vụ bên thứ ba. Giám sát truyền thống có thể cho một nhóm biết rằng có điều gì đó không đúng. Quan sát giúp các kỹ sư điều tra nguyên nhân gốc rễ.
Khả năng quan sát ứng dụng là gì?
Quan sát ứng dụng tập trung vào việc làm cho hành vi nội bộ của ứng dụng dễ hiểu từ các tín hiệu mà hệ thống sản xuất ra. Những tín hiệu đó có thể giúp các nhóm trả lời những câu hỏi như tại sao các yêu cầu lại chậm, sự phụ thuộc nào đang gặp sự cố, liệu các lỗi có ảnh hưởng đến một quy trình làm việc cụ thể không, và điều gì đã thay đổi trước một sự cố.
Quan sát rộng hơn là chỉ thu thập dữ liệu. Giá trị đến từ việc kết nối telemetry với các câu hỏi hoạt động có ý nghĩa và sử dụng nó để điều tra và cải thiện phần mềm.
Khả năng quan sát vs. Theo dõi
| Khu vực | Quan sát ứng dụng | Giám sát truyền thống |
|---|---|---|
| Mục đích chính | Hiểu hành vi ứng dụng và điều tra các vấn đề chưa biết | Theo dõi các chỉ số và điều kiện sức khỏe đã biết |
| Dữ liệu | Chỉ số, nhật ký, dấu vết, sự kiện và ngữ cảnh ứng dụng | Thường tập trung vào các chỉ số và cảnh báo được xác định trước |
| Điều tra | Được thiết kế để hỗ trợ khám phá và tương quan | Thường bắt đầu từ các ngưỡng hoặc kiểm tra đã biết |
| Hệ thống phân tán | Có thể tương quan hoạt động giữa các dịch vụ và phụ thuộc | Có thể yêu cầu nhiều góc độ giám sát riêng biệt |
Giám sát vẫn là một phần quan trọng của khả năng quan sát. Hai khái niệm này bổ sung cho nhau thay vì đại diện cho những phương pháp loại trừ lẫn nhau.
Ba tín hiệu quan trọng của khả năng quan sát
Chỉ số
Các chỉ số là các phép đo số học được thu thập theo thời gian. Ví dụ ứng dụng bao gồm tỷ lệ yêu cầu, độ trễ, tỷ lệ lỗi, độ sâu hàng đợi và mức sử dụng tài nguyên.
Nhật ký
Nhật ký ghi lại các sự kiện và tin nhắn ứng dụng. Nhật ký có cấu trúc là đặc biệt hữu ích vì các trường như tên dịch vụ, ID yêu cầu, mức độ nghiêm trọng và hoạt động có thể được tìm kiếm và tương quan một cách nhất quán.
Dấu vết
Các truy dấu phân tán cho thấy cách mà một yêu cầu di chuyển qua nhiều thành phần ứng dụng. Chúng có thể tiết lộ dịch vụ nào, truy vấn cơ sở dữ liệu nào hoặc phụ thuộc bên ngoài nào góp phần vào độ trễ hoặc thất bại.
Các tín hiệu bổ sung như hồ sơ và sự kiện kinh doanh có thể cung cấp thêm ngữ cảnh khi được hỗ trợ bởi kiến trúc khả năng quan sát.
Tại sao khả năng quan sát ứng dụng lại quan trọng
Các ứng dụng ngày càng phụ thuộc vào các thành phần phân tán. Một yêu cầu từ khách hàng có thể đi qua một cổng API, dịch vụ xác thực, dịch vụ ứng dụng, bộ nhớ đệm, cơ sở dữ liệu, nhà cung cấp thanh toán và hệ thống nhắn tin.
Khi một yêu cầu gặp lỗi hoặc trở nên chậm, việc nhìn vào một máy chủ có thể không tiết lộ nguyên nhân. Việc theo dõi telemetry tương quan có thể giúp các kỹ sư theo dõi yêu cầu qua các phụ thuộc của nó và xác định thành phần chịu trách nhiệm cho hành vi quan sát được.
Cách thức hoạt động của khả năng quan sát ứng dụng
- Các ứng dụng và hệ thống hỗ trợ tạo ra telemetry.
- Thiết bị gắn các ngữ cảnh hữu ích vào telemetry đó.
- Các bộ thu hoặc tác nhân nhận và xử lý dữ liệu.
- Telemetry được xuất ra một backend khả năng quan sát.
- Bảng điều khiển, truy vấn, cảnh báo và truy dấu giúp các kỹ sư điều tra hành vi.
- Các đội sử dụng những phát hiện để sửa chữa vấn đề và cải thiện ứng dụng.
Các thành phần chính trong chiến lược khả năng quan sát
Thiết bị
Thiết bị xác định hành vi ứng dụng nào được ghi lại. Nó có thể tự động, thủ công hoặc kết hợp của cả hai.
Thu thập telemetry
Các bộ thu và tác nhân có thể nhận telemetry, làm phong phú nó, lọc nó, nhóm nó lại và định tuyến nó tới các hệ thống lưu trữ hoặc phân tích.
Tương quan
Tương quan kết nối telemetry được tạo ra bởi cùng một yêu cầu, giao dịch, dịch vụ hoặc quy trình kinh doanh. Các định danh nhất quán và ngữ cảnh truy dấu đặc biệt hữu ích trong các hệ thống phân tán.
Phân tích
Các kỹ sư cần công cụ để truy vấn telemetry, khám phá các truy dấu, xem bảng điều khiển và xác định các mẫu.
Cảnh báo
Các cảnh báo nên xác định các điều kiện cần hành động. Các cảnh báo thiết kế kém có thể tạo ra tiếng ồn và khiến các tín hiệu quan trọng bị bỏ qua.
Khả năng quan sát ứng dụng và các hệ thống phân tán
Các kiến trúc phân tán làm tăng nhu cầu về khả năng quan sát vì các lỗi có thể vượt qua biên giới dịch vụ. Một thời gian chờ trong một dịch vụ có thể xuất phát từ một cơ sở dữ liệu chậm hoặc một API hạ lưu.
Truy dấu phân tán có thể cung cấp cái nhìn cấp yêu cầu về những tương tác này. Các chỉ số có thể cho thấy liệu vấn đề có lan rộng hay không, trong khi nhật ký có thể cung cấp ngữ cảnh sự kiện chi tiết.
Giám sát hiệu suất ứng dụng và khả năng quan sát
Giám sát hiệu suất ứng dụng, hay APM, truyền thống tập trung vào hiệu suất ứng dụng, các giao dịch, lỗi và thông tin vận hành liên quan. Các nền tảng khả năng quan sát hiện đại thường tích hợp khả năng APM cùng với telemetry rộng hơn.
Ranh giới chính xác giữa APM và khả năng quan sát thay đổi tùy theo sản phẩm và tổ chức. Điều quan trọng về hoạt động là liệu các kỹ sư có thể lấy đủ ngữ cảnh để phát hiện, điều tra và giải quyết các vấn đề của ứng dụng.
Bối cảnh kinh doanh trong khả năng quan sát
Telemetry kỹ thuật trở nên hữu ích hơn khi nó có thể được kết nối với các quy trình kinh doanh. Ví dụ, một sự gia tăng độ trễ API có thể quan trọng hơn khi nó ảnh hưởng đến việc hoàn tất thanh toán hoặc đăng ký tài khoản.
Các nhóm có thể thêm các thuộc tính hoặc sự kiện kinh doanh được lựa chọn cẩn thận vào telemetry mà vẫn tôn trọng quyền riêng tư và yêu cầu về tối thiểu hóa dữ liệu. Điều này giúp kết nối các sự cố kỹ thuật với tác động đến người dùng.
Khả năng quan sát ứng dụng và OpenTelemetry
OpenTelemetry cung cấp các API, SDK, công cụ đo, quy ước ngữ nghĩa và các thành phần thu thập cho telemetry như traces, metrics và logs. Do đó, nó có thể hình thành một phần quan trọng trong kiến trúc quan sát ứng dụng.
OpenTelemetry không thay thế một backend quan sát. Telemetry thường cần được xuất khẩu đến các hệ thống cung cấp lưu trữ, truy vấn, hình ảnh hóa và cảnh báo.
Xem xét về bảo mật và quyền riêng tư
Dữ liệu quan sát có thể chứa thông tin nhạy cảm. Các URL, tham số yêu cầu, định danh người dùng, câu lệnh cơ sở dữ liệu, tin nhắn ngoại lệ và logs có thể tiết lộ dữ liệu bí mật nếu công cụ đo được thiết kế kém.
- Đừng đặt mật khẩu, khóa API hoặc token trong telemetry.
- Xem xét thông tin cá nhân có thể xác định được trước khi thu thập.
- Áp dụng kiểm soát truy cập đến các nền tảng quan sát.
- Mã hóa telemetry trong quá trình truyền tải khi thích hợp.
- Xác định các chính sách lưu giữ và xóa bỏ.
- Sử dụng bộ lọc hoặc chỉnh sửa cho các trường nhạy cảm.
Xem xét về chi phí và hiệu suất
Telemetry tiêu tốn tài nguyên máy tính, băng thông mạng và lưu trữ. Các metrics có độ cardinality cao và logs chi tiết có thể trở nên tốn kém và khó truy vấn.
Lấy mẫu, lọc, tổng hợp, chính sách lưu giữ và các mức độ log phù hợp có thể giúp kiểm soát chi phí. Các nhóm nên đo lường chất lượng telemetry thay vì chỉ đơn thuần thu thập khối lượng tối đa có thể.
Cách xây dựng một chiến lược khả năng quan sát ứng dụng
- Xác định những hành trình người dùng quan trọng nhất của ứng dụng.
- Định nghĩa các chỉ số mức phục vụ và các metrics hoạt động hữu ích.
- Công cụ đo các đường dẫn ứng dụng và phụ thuộc quan trọng.
- Tiêu chuẩn hóa logging có cấu trúc và các định danh tương quan.
- Thực hiện tracing phân tán khi thích hợp.
- Xây dựng bảng điều khiển xung quanh các câu hỏi hoạt động có ý nghĩa.
- Tạo cảnh báo có thể hành động với chủ sở hữu rõ ràng.
- Xem xét chất lượng telemetry, an ninh, lưu giữ và chi phí thường xuyên.
Mẹo từ chuyên gia
- Bắt đầu với các hành trình người dùng quan trọng thay vì công cụ đo mọi thứ như nhau.
- Sử dụng tên dịch vụ và metadata nhất quán trên các môi trường.
- Kết nối traces, logs và metrics thông qua ngữ cảnh chia sẻ.
- Giữ cho cảnh báo tập trung vào các điều kiện cần hành động của con người.
- Ghi lại đủ ngữ cảnh để chẩn đoán các lỗi mà không thu thập dữ liệu nhạy cảm không cần thiết.
- Kiểm tra khả năng quan sát trong các kịch bản thất bại có kiểm soát, không chỉ trong hoạt động bình thường.
Những sai lầm phổ biến trong quan sát ứng dụng
- Thu thập một lượng lớn telemetry mà không có mục đích rõ ràng.
- Tạo bảng điều khiển hiển thị dữ liệu nhưng không trả lời các câu hỏi vận hành.
- Sử dụng các định danh không đồng nhất giữa các dịch vụ.
- Bỏ qua bảo mật và quyền riêng tư của telemetry.
- Cảnh báo về mọi lỗi thay vì ưu tiên các điều kiện ảnh hưởng đến người dùng.
- Không theo dõi chính đường ống khả năng quan sát.
Câu hỏi thường gặp
Quan sát ứng dụng là gì theo cách đơn giản?
Đây là thực hành sử dụng telemetry để hiểu hành vi nội bộ của một ứng dụng và điều tra lý do tại sao nó sản xuất ra những kết quả cụ thể.
Các tín hiệu quan sát chính là gì?
Các chỉ số, nhật ký và truy vết là những tín hiệu chính thường được sử dụng cho khả năng quan sát của ứng dụng. Các hồ sơ và sự kiện kinh doanh có thể bổ sung thêm ngữ cảnh.
Sự khác biệt giữa quan sát và giám sát là gì?
Theo dõi thường tập trung vào việc theo dõi các điều kiện đã biết, trong khi khả năng quan sát nhấn mạnh việc sử dụng đầu ra của hệ thống để điều tra các hành vi và vấn đề đa dạng.
OpenTelemetry có phải là một nền tảng quan sát không?
OpenTelemetry là một framework khả năng quan sát mã nguồn mở và hệ sinh thái telemetry. Nó thường hoạt động với các backend riêng biệt cho lưu trữ, phân tích, bảng điều khiển và cảnh báo.
Quan sát có cải thiện hiệu suất ứng dụng không?
Khả năng quan sát có thể giúp các nhóm xác định các nút thắt về hiệu suất và sự thoái lui. Nó không tự động cải thiện hiệu suất; các kỹ sư sử dụng thông tin thu được để thực hiện các thay đổi.
Quan sát ứng dụng chỉ dành cho microservices không?
Không. Nó có thể hữu ích cho các ứng dụng monolithic, khối lượng công việc serverless, backend di động và web, và các hệ thống phân phối.
Một ứng dụng nên thu thập bao nhiêu telemetry?
Đủ để trả lời các câu hỏi vận hành quan trọng trong khi kiểm soát chi phí, hiệu suất, quyền riêng tư và thời gian giữ lại. Mức độ phù hợp phụ thuộc vào ứng dụng và hồ sơ rủi ro của nó.
Người mới bắt đầu nên giám sát điều gì trước tiên?
Bắt đầu với tính sẵn có, tỷ lệ yêu cầu, độ trễ, lỗi, phụ thuộc quan trọng, hành trình người dùng quan trọng, và đủ nhật ký và truy vết để điều tra các lỗi.
Kết luận
Quan sát ứng dụng cung cấp cho các nhóm kỹ sư một cách có cấu trúc để hiểu hành vi phần mềm thông qua các chỉ số, nhật ký, truy vết và ngữ cảnh liên quan. Nó đặc biệt có giá trị khi các ứng dụng trải rộng trên nhiều dịch vụ và các lớp hạ tầng.
Một chiến lược khả năng quan sát hữu ích không được xác định bằng khối lượng dữ liệu thu thập được. Nó được xác định bởi việc các kỹ sư có thể nhanh chóng trả lời các câu hỏi quan trọng về sức khỏe của ứng dụng, tác động đến người dùng, các phụ thuộc và lỗi trong khi vẫn duy trì các kiểm soát bảo mật và chi phí phù hợp.
Tiếp tục chuỗi công nghệ: tiếp theo là eBPF Technology, which explores how the Linux kernel can provide powerful visibility and programmability for modern systems.
