OpenTelemetry đã nổi lên như một tiêu chuẩn đầy hứa hẹn cho khả năng quan sát ứng dụng, cung cấp cho các nhà phát triển một cách thống nhất để thu thập traces, metrics và logs. Tuy nhiên, khi ngày càng nhiều tổ chức cố gắng triển khai công nghệ này, những thách thức đáng kể đang nổi lên vượt xa độ phức tạp thiết lập ban đầu.
Các Thành Phần Cốt Lõi của OpenTelemetry
| Thành Phần | Mô Tả |
|---|---|
| Trace | Hành trình hoàn chỉnh từ đầu đến cuối của một yêu cầu |
| Span | Đơn vị công việc cơ bản trong một trace |
| Context | Siêu dữ liệu được mang theo cùng với các yêu cầu |
| Attributes | Các cặp khóa-giá trị mô tả các span |
| Events | Các thông điệp log được đính kèm vào span |
| Links | Kết nối giữa các span trong những trace khác nhau |
Chi Phí Lưu Trữ Trở Thành Mối Quan Ngại Chính
Một trong những vấn đề cấp bách nhất mà những người áp dụng OpenTelemetry phải đối mặt là lượng dữ liệu khổng lồ được tạo ra bởi việc tracing toàn diện. Các tổ chức đang phát hiện ra rằng việc lưu trữ dữ liệu trace trong vài tuần có thể yêu cầu hàng chục terabyte không gian lưu trữ. Điều này đã dẫn đến những cuộc thảo luận sôi nổi về các chiến lược sampling, nơi các nhóm phải cân bằng giữa việc thu thập đủ dữ liệu để phân tích có ý nghĩa và quản lý chi phí lưu trữ.
Cộng đồng đã phát triển nhiều cách tiếp cận khác nhau để giải quyết thách thức này. Một số ủng hộ conditional sampling thu thập tất cả error traces trong khi chỉ sampling một tỷ lệ nhỏ các request thành công. Những người khác lại tranh luận về việc duy trì khả năng logging đầy đủ trong môi trường production, bất chấp chi phí đáng kể liên quan.
Phạm Vi Hạn Chế Ngoài Ứng Dụng Web
Một hạn chế đáng kể khác đã làm các nhà phát triển thất vọng là sự tập trung hẹp của OpenTelemetry vào các dịch vụ backend web. Framework này gặp khó khăn với các tình huống ngoài các mẫu request-response HTTP truyền thống. Các ứng dụng desktop, các công việc batch chạy dài và các workload chuyên biệt như tính toán tăng tốc GPU thường yêu cầu các giải pháp thay thế sáng tạo hoặc đơn giản là không phù hợp với các giả định thiết kế của OpenTelemetry .
Các công việc batch chạy dài đặt ra một thách thức đặc biệt vì spans chỉ được gửi sau khi hoàn thành. Điều này có nghĩa là không có cách nào để theo dõi tiến độ trong quá trình thực thi đối với các công việc có thể chạy trong nhiều giờ hoặc nhiều ngày, khiến framework gần như không thể sử dụng cho các tình huống này.
Các Loại Span và Trường Hợp Sử Dụng
| Loại Span | Mục Đích | Ví Dụ Trường Hợp Sử Dụng |
|---|---|---|
| INTERNAL | Các hoạt động nội bộ của ứng dụng | Gọi hàm, logic nghiệp vụ |
| CLIENT | Yêu cầu gửi đi tới các dịch vụ bên ngoài | Yêu cầu HTTP, truy vấn cơ sở dữ liệu |
| SERVER | Xử lý các yêu cầu đến | Các endpoint máy chủ HTTP |
| PRODUCER | Xuất bản tin nhắn | Xuất bản tin nhắn Kafka |
| CONSUMER | Xử lý tin nhắn | Tiêu thụ tin nhắn Kafka |
Chi Phí Phát Triển và Độ Phức Tạp
Gánh nặng triển khai cũng đã thu hút sự chỉ trích từ các nhà phát triển, những người thấy mình phải dành thời gian đáng kể cho mã telemetry thay vì các tính năng cốt lõi. Trong khi auto-instrumentation có thể giúp giảm chi phí này cho một số framework, manual instrumentation vẫn yêu cầu mã bổ sung đáng kể và nỗ lực tinh thần.
Lượng mã bổ sung mà nó cần là khủng khiếp. Chúng tôi bây giờ sẽ phải dành nhiều năng lượng trí tuệ hơn cho telemetry khi làm việc trên một tính năng.
Tuy nhiên, những người ủng hộ lập luận rằng khoản đầu tư trước này sẽ mang lại lợi ích khi khắc phục các vấn đề phức tạp, đặc biệt là trong các hệ thống phân tán nơi các vấn đề có thể khó tái tạo và chẩn đoán.
Các Anti-Pattern Triển Khai Phổ Biến
- Root span thiếu đặc tả SpanKind
- Tên span quá chi tiết làm giảm tính đa dạng
- Thiếu thông tin lỗi trong thuộc tính span
- Ánh xạ phụ thuộc không đầy đủ giữa các span
- Lưu trữ dữ liệu PII nhạy cảm trong thuộc tính
- Rò rỉ bộ nhớ từ các span không được tách rời
Sự Không Nhất Quán Trong Triển Khai Vendor
Bất chấp mục tiêu tiêu chuẩn hóa của OpenTelemetry , các triển khai thực tế khác nhau đáng kể giữa các vendor khác nhau. Điều này đã dẫn đến các vấn đề tương thích và tăng độ phức tạp khi các tổ chức cố gắng chuyển đổi giữa các nền tảng observability khác nhau hoặc tích hợp nhiều công cụ.
Cộng đồng tiếp tục làm việc để giải quyết những thách thức này, với những cải tiến liên tục đối với tài liệu, công cụ và hỗ trợ framework. Tuy nhiên, những cuộc thảo luận này làm nổi bật khoảng cách giữa tầm nhìn đầy tham vọng của OpenTelemetry và thực tế thực tiễn của việc triển khai trong các môi trường production đa dạng.
Tham khảo: What are Traces and Spans in OpenTelemetry: A Practical Guide