OpenTelemetry là gì và nó có thể cải thiện chất lượng phụ trợ của bạn như thế nào?

Trước đây, khi nói về phần phụ trợ, chúng ta thường đề cập đến một ứng dụng lớn với một cơ sở dữ liệu lớn duy nhất và việc ghi nhật ký là đủ để theo dõi. Giờ đây, nhờ các công nghệ như Kubernetes , microservice đã trở thành tiêu chuẩn. Các ứng dụng ngày càng nhiều và được phân phối, đồng thời việc ghi nhật ký truyền thống không còn đủ để gỡ lỗi và chẩn đoán sự cố trong ứng dụng của chúng tôi.

Một giải pháp tuyệt vời để tổ chức giám sát là OpenTelemetry — một bộ công cụ hiện đại có thể được sử dụng để gỡ lỗi và phân tích hiệu suất của các hệ thống phân tán.

Bài viết này dành cho các chuyên gia CNTT đang tìm cách mở rộng kiến thức về tối ưu hóa phụ trợ. Dưới đây, chúng tôi sẽ trình bày chi tiết OpenTelemetry là gì, các khái niệm chính của nó và các vấn đề mà nó giúp giải quyết. Nếu bạn quan tâm đến cách OpenTelemetry có thể thay đổi cách tiếp cận của bạn đối với việc giám sát và gỡ lỗi các hệ thống phụ trợ, nâng cao độ tin cậy và hiệu quả của chúng — hãy đọc tiếp.

Tóm tắt lịch sử của OpenTelemetry

Các công ty công nghệ lớn lần đầu tiên phải đối mặt với thách thức trong việc ghi nhật ký và truy tìm phân tán vào cuối những năm 2000. Năm 2010, Google đã xuất bản một bài báo, Dapper, Cơ sở hạ tầng theo dõi hệ thống phân tán quy mô lớn , đặt nền móng cho công cụ theo dõi của Twitter, Zipkin, được phát hành vào năm 2012.

Năm 2014, Kubernetes xuất hiện, đơn giản hóa đáng kể việc phát triển các dịch vụ vi mô và các hệ thống phân tán trên nền tảng đám mây khác. Điều này dẫn đến nhiều công ty gặp phải vấn đề với việc ghi nhật ký và theo dõi phân tán trong vi dịch vụ. Để chuẩn hóa hoạt động theo dõi phân tán, tiêu chuẩn OpenTracing được CNCF áp dụng và dự án OpenCensus của Google đã được tạo ra.

Năm 2019, dự án OpenTracing và OpenCensus đã công bố sáp nhập với tên OpenTelemetry. Nền tảng này kết hợp các phương pháp thực hành tốt nhất được tích lũy qua nhiều năm, cho phép tích hợp liền mạch tính năng theo dõi, ghi nhật ký và số liệu vào bất kỳ hệ thống nào, bất kể độ phức tạp của chúng.

Ngày nay, OpenTelemetry không chỉ là một dự án; nó là một tiêu chuẩn công nghiệp để thu thập và truyền dữ liệu đo từ xa. Nó được phát triển và hỗ trợ bởi cộng đồng các chuyên gia và các công ty dẫn đầu thị trường như Google và Microsoft. Dự án tiếp tục phát triển, đạt được các khả năng mới để đơn giản hóa quá trình tích hợp và sử dụng.

Có gì bên trong?

OpenTelemetry là một tập hợp toàn diện các phương pháp và công cụ xác định những tín hiệu mà ứng dụng có thể tạo ra để tương tác với thế giới bên ngoài cũng như cách thu thập và hiển thị các tín hiệu này để theo dõi trạng thái của toàn bộ ứng dụng và hệ thống. Ba loại tín hiệu chính là theo dõi, ghi nhật ký và thu thập số liệu .

**Chúng ta hãy xem xét kỹ hơn từng thành phần: \

Bối cảnh

OpenTelemetry giới thiệu khái niệm về bối cảnh hoạt động. Một ngữ cảnh chủ yếu bao gồm các thuộc tính như `trace_id` (mã định danh cho hoạt động hiện tại) và `span_id` (mã định danh cho một yêu cầu phụ, với mỗi lần thử lại yêu cầu phụ có một `span_id` duy nhất).

Ngoài ra, ngữ cảnh có thể chứa thông tin tĩnh, chẳng hạn như tên nút nơi ứng dụng được triển khai hoặc tên môi trường (prod/qa). Các trường này, được gọi là tài nguyên trong thuật ngữ OpenTelemetry, được đính kèm vào mọi nhật ký, số liệu hoặc dấu vết để có thể tìm kiếm dễ dàng hơn. Ngữ cảnh cũng có thể bao gồm dữ liệu động, như mã định danh của điểm cuối hiện tại ( `http_path: "GET /user/:id/info"` ), có thể được gắn có chọn lọc vào các nhóm nhật ký, số liệu hoặc dấu vết.

Ngữ cảnh OpenTelemetry có thể được truyền giữa các ứng dụng khác nhau bằng cách sử dụng các giao thức truyền ngữ cảnh. Các giao thức này bao gồm các bộ tiêu đề được thêm vào mọi yêu cầu HTTP hoặc gRPC hoặc tiêu đề của thông báo cho hàng đợi. Điều này cho phép các ứng dụng hạ nguồn xây dựng lại bối cảnh hoạt động từ các tiêu đề này.

Dưới đây là một số ví dụ về lan truyền bối cảnh:

1. B3-Propagation Đây là một tập hợp các tiêu đề ( x-b3-* ) ban đầu được phát triển cho hệ thống truy tìm Zipkin. Nó đã được chuyển thể thành OpenTracing và được nhiều công cụ và thư viện sử dụng. B3-Propagation mang theo trace_id / span_id và một cờ cho biết liệu có cần lấy mẫu hay không.

   
   

2. Bối cảnh theo dõi W3C Được phát triển bởi nhóm làm việc W3C, tiêu chuẩn này hợp nhất các phương pháp truyền bá bối cảnh khác nhau thành một tiêu chuẩn duy nhất và là mặc định trong OpenTelemetry. Một ví dụ điển hình về việc áp dụng các tiêu chuẩn này là theo dõi quá trình thực hiện yêu cầu đi qua các vi dịch vụ được triển khai bằng các công nghệ khác nhau mà không ảnh hưởng đến độ chính xác của việc giám sát và gỡ lỗi.

Truy tìm

Theo dõi là quá trình ghi lại và sau đó trực quan hóa dòng thời gian của đường dẫn yêu cầu thông qua nhiều vi dịch vụ.

Trong hình ảnh trực quan, mỗi thanh được gọi là "span" và có một "span_id" duy nhất. Khoảng gốc được gọi là "dấu vết" và có "trace_id" , đóng vai trò là mã định danh cho toàn bộ yêu cầu.

Kiểu trực quan này cho phép bạn:

• Phân tích thời gian thực hiện các yêu cầu trên các hệ thống và cơ sở dữ liệu khác nhau để xác định các điểm nghẽn cần tối ưu hóa.
• Phát hiện sự phụ thuộc theo chu kỳ giữa các dịch vụ.
• Tìm các yêu cầu trùng lặp. Bằng cách sử dụng dữ liệu theo dõi, bạn cũng có thể xây dựng các phân tích bổ sung, chẳng hạn như tạo bản đồ vi dịch vụ hoặc phân bổ thời gian trên các hệ thống khác nhau trong quá trình xử lý hoạt động. Ngay cả khi bạn không sử dụng dữ liệu theo dõi để trực quan hóa các mốc thời gian, OpenTelemetry vẫn tạo trace_id và span_id để sử dụng trong các tín hiệu khác.

Nhật ký

Mặc dù có vẻ đơn giản nhưng việc ghi nhật ký vẫn là một trong những công cụ mạnh mẽ nhất để chẩn đoán sự cố. OpenTelemetry tăng cường ghi nhật ký truyền thống bằng cách thêm thông tin theo ngữ cảnh. Cụ thể, nếu có dấu vết đang hoạt động, các thuộc tính `trace_id` và `span_id` sẽ tự động được thêm vào nhật ký, liên kết chúng với dòng thời gian theo dõi. Hơn nữa, thuộc tính nhật ký có thể bao gồm thông tin tĩnh từ ngữ cảnh OpenTelemetry, chẳng hạn như mã định danh nút, cũng như thông tin động, như mã định danh điểm cuối HTTP hiện tại (`http_path: "GET /user/:id"`).

Bằng cách sử dụng `trace_id`, bạn có thể tìm thấy nhật ký từ tất cả vi dịch vụ được liên kết với yêu cầu hiện tại, trong khi `span_id` cho phép bạn phân biệt giữa các yêu cầu phụ. Ví dụ: trong trường hợp thử lại, nhật ký từ những lần thử khác nhau sẽ có `span_id` khác nhau. Việc sử dụng các mã định danh này cho phép phân tích nhanh chóng hành vi của toàn bộ hệ thống trong thời gian thực, tăng tốc độ chẩn đoán sự cố cũng như nâng cao độ ổn định và độ tin cậy.

Số liệu

Bộ sưu tập số liệu cung cấp dữ liệu định lượng về hiệu suất hệ thống, chẳng hạn như độ trễ, tỷ lệ lỗi, mức sử dụng tài nguyên, v.v. Giám sát số liệu theo thời gian thực cho phép bạn phản hồi kịp thời các thay đổi về hiệu suất, ngăn ngừa lỗi và cạn kiệt tài nguyên, đồng thời đảm bảo tính sẵn sàng và độ tin cậy cao của ứng dụng cho người dùng.

Việc tích hợp với các hệ thống lưu trữ và hiển thị số liệu như Prometheus và Grafana giúp trực quan hóa dữ liệu này dễ dàng hơn, đơn giản hóa đáng kể việc giám sát.

Bộ sưu tập số liệu

Bộ thu thập số liệu OpenTelemetry tương thích với các tiêu chuẩn Prometheus và OpenMetrics, cho phép chuyển đổi dễ dàng sang các giải pháp OpenTelemetry mà không có thay đổi đáng kể. SDK OpenTelemetry cho phép xuất các ví dụ trace_id cùng với số liệu, giúp có thể tương quan các số liệu với ví dụ nhật ký và dấu vết.

Tương quan tín hiệu

Cùng với nhau, nhật ký, số liệu và theo dõi tạo ra cái nhìn toàn diện về trạng thái của hệ thống:

• Nhật ký cung cấp thông tin về các sự kiện của hệ thống, cho phép xác định và giải quyết lỗi nhanh chóng.
• Số liệu phản ánh các chỉ số hiệu suất định tính và định lượng của hệ thống, chẳng hạn như thời gian phản hồi hoặc tỷ lệ lỗi.
• Việc theo dõi bổ sung cho chế độ xem này bằng cách hiển thị đường dẫn thực hiện yêu cầu thông qua các thành phần hệ thống khác nhau, giúp hiểu được mối quan hệ qua lại của chúng. Mối tương quan rõ ràng giữa nhật ký, dấu vết và số liệu là một tính năng đặc biệt của OpenTelemetry. Ví dụ: Grafana cho phép người dùng xem số liệu theo dõi và yêu cầu tương ứng khi xem nhật ký, giúp nâng cao đáng kể khả năng sử dụng và hiệu quả của nền tảng.

Ngoài ba thành phần cốt lõi, OpenTelemetry còn bao gồm các khái niệm về Lấy mẫu, Hành lý và quản lý bối cảnh hoạt động.

Lấy mẫu

Trong các hệ thống tải cao, khối lượng nhật ký và dấu vết trở nên khổng lồ, đòi hỏi nguồn lực đáng kể cho cơ sở hạ tầng và lưu trữ dữ liệu. Để giải quyết vấn đề này, các tiêu chuẩn OpenTelemetry bao gồm lấy mẫu tín hiệu — khả năng chỉ xuất một phần dấu vết và nhật ký. Ví dụ: bạn có thể xuất tín hiệu chi tiết từ phần trăm yêu cầu, yêu cầu chạy dài hoặc yêu cầu lỗi. Cách tiếp cận này cho phép lấy mẫu đầy đủ để xây dựng số liệu thống kê đồng thời tiết kiệm nguồn lực đáng kể.

Tuy nhiên, nếu mỗi hệ thống quyết định một cách độc lập những yêu cầu nào cần giám sát chi tiết thì chúng ta sẽ có một cái nhìn phân mảnh về từng yêu cầu. Một số hệ thống có thể xuất dữ liệu chi tiết trong khi những hệ thống khác chỉ có thể xuất một phần hoặc không xuất chút nào.

Để giải quyết vấn đề này, cơ chế truyền ngữ cảnh của OpenTelemetry truyền cờ lấy mẫu cùng với `trace_id`/`span_id`. Điều này đảm bảo rằng nếu dịch vụ ban đầu nhận được yêu cầu của người dùng quyết định rằng yêu cầu đó cần được giám sát chi tiết thì tất cả các hệ thống khác sẽ tuân theo. Mặt khác, tất cả các hệ thống sẽ xuất một phần hoặc không xuất tín hiệu để bảo tồn tài nguyên. Cách tiếp cận này được gọi là "Lấy mẫu đầu" - một quyết định được đưa ra khi bắt đầu xử lý yêu cầu, ngẫu nhiên hoặc dựa trên một số thuộc tính đầu vào.

Ngoài ra, OpenTelemetry hỗ trợ "Lấy mẫu đuôi", trong đó tất cả các ứng dụng luôn xuất tất cả các tín hiệu một cách chi tiết nhưng vẫn tồn tại một bộ đệm trung gian. Sau khi thu thập tất cả dữ liệu, bộ đệm này sẽ quyết định giữ lại toàn bộ dữ liệu hay chỉ giữ lại một phần mẫu. Phương pháp này cho phép lấy mẫu đại diện hơn cho từng danh mục yêu cầu (thành công/dài/lỗi) nhưng yêu cầu thiết lập cơ sở hạ tầng bổ sung.

Hành lý

Cơ chế Hành lý cho phép các cặp khóa-giá trị tùy ý được truyền cùng với trace_id / span_id , tự động chuyển giữa tất cả các vi dịch vụ trong quá trình xử lý yêu cầu. Điều này rất hữu ích để truyền thông tin bổ sung cần thiết trong suốt đường dẫn yêu cầu—chẳng hạn như thông tin người dùng hoặc cài đặt môi trường thời gian chạy.

Ví dụ về tiêu đề để truyền hành lý theo tiêu chuẩn W3C: tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5

Dưới đây là một số ví dụ về cách sử dụng Hành lý:

• Truyền thông tin bối cảnh kinh doanh như userId , productId hoặc deviceId có thể được truyền qua tất cả các vi dịch vụ. Các ứng dụng có thể tự động ghi lại thông tin này, cho phép tìm kiếm nhật ký theo ngữ cảnh của người dùng đối với yêu cầu ban đầu.

• Cài đặt thông số cấu hình cụ thể cho SDK hoặc cơ sở hạ tầng.

• Cờ định tuyến Cờ giúp cân bằng tải đưa ra quyết định định tuyến. Trong quá trình thử nghiệm, một số yêu cầu có thể cần được chuyển đến các chương trình phụ trợ mô phỏng. Vì hành lý được vận chuyển tự động qua tất cả các dịch vụ nên không cần tạo giao thức bổ sung—chỉ cần thiết lập quy tắc trên bộ cân bằng tải.

  
  

Triển khai cơ sở hạ tầng

Việc triển khai OpenTelemetry ở cấp cơ sở hạ tầng bao gồm việc tích hợp các chương trình phụ trợ OpenTelemetry vào kiến trúc ứng dụng và định cấu hình cơ sở hạ tầng để tổng hợp dữ liệu.

Quá trình này bao gồm bốn giai đoạn:

1. Tích hợp ứng dụng Trong giai đoạn đầu tiên, SDK OpenTelemetry được tích hợp trực tiếp vào các ứng dụng để thu thập số liệu, nhật ký và dấu vết, đảm bảo luồng dữ liệu liên tục về hiệu suất của từng thành phần hệ thống.

   
   

2. Định cấu hình nhà xuất khẩu Dữ liệu đã thu thập được định tuyến từ ứng dụng thông qua nhà xuất khẩu đến các hệ thống bên ngoài để xử lý thêm, chẳng hạn như hệ thống ghi nhật ký, giám sát, truy tìm hoặc phân tích, tùy thuộc vào nhu cầu của bạn.

   
   

3. Tổng hợp và lưu trữ Giai đoạn này có thể liên quan đến việc chuẩn hóa dữ liệu, làm phong phú dữ liệu bằng thông tin bổ sung và hợp nhất dữ liệu từ các nguồn khác nhau để tạo ra một cái nhìn thống nhất về trạng thái của hệ thống.

   
   

4. Trực quan hóa dữ liệu Cuối cùng, dữ liệu đã xử lý được trình bày dưới dạng trang tổng quan trong các hệ thống như Grafana (đối với số liệu và dấu vết) hoặc Kibana (đối với nhật ký). Điều này cho phép các nhóm nhanh chóng đánh giá tình trạng của hệ thống, xác định các vấn đề và xu hướng cũng như thiết lập cảnh báo dựa trên các tín hiệu được tạo.

Triển khai ứng dụng

Để tích hợp với một ứng dụng, bạn cần kết nối SDK OpenTelemetry thích hợp cho ngôn ngữ lập trình đang sử dụng hoặc sử dụng các thư viện và khung hỗ trợ trực tiếp OpenTelemetry. OpenTelemetry thường triển khai các giao diện được sử dụng rộng rãi từ các thư viện đã biết, cho phép thay thế tùy ý. Ví dụ: thư viện Micrometer thường được sử dụng để thu thập số liệu trong hệ sinh thái Java. SDK OpenTelemetry cung cấp khả năng triển khai giao diện Micromet, cho phép xuất số liệu mà không thay đổi mã ứng dụng chính. Hơn nữa, OpenTelemetry cung cấp triển khai các giao diện OpenTracing và OpenCensus cũ hơn, tạo điều kiện di chuyển suôn sẻ sang OpenTelemetry.

Phần kết luận

Trong các hệ thống CNTT, OpenTelemetry có thể trở thành chìa khóa cho tương lai của các chương trình phụ trợ đáng tin cậy và hiệu quả. Công cụ này đơn giản hóa việc gỡ lỗi và giám sát, đồng thời mở ra cơ hội hiểu biết sâu sắc về hiệu suất và tối ưu hóa ứng dụng ở cấp độ mới. Tham gia cộng đồng OpenTelemetry để giúp định hình một tương lai nơi việc phát triển phụ trợ trở nên đơn giản và hiệu quả hơn!