Giới thiệu về tác giả: Xin chào mọi người, tôi là Lan Béo.

☁️Trang chủ Blog: Trang chủ Blog Park Giấc mơ lập trình của Lan Béo.

Câu nói trong ngày: Chúng ta sẽ gặp phải bao nhiêu trở ngại trong quá trình lập trình? Nó có nghĩa là từ bỏ. Phải có một ốc đảo ở cuối sa mạc.

Xin chào mọi người, tôi là Lan Fatty. Thực tế có rất nhiều bài viết giải thích về bản demo của theo dõi liên kết, nhưng việc tích hợp theo dõi liên kết vào môi trường sản xuất không hề dễ dàng. Hôm nay chúng ta sẽ nói về việc triển khai thực tế công nghệ theo dõi liên kết. vấn đề phải được giải quyết.

Những vấn đề cần quan tâm khi thực sự triển khai theo dõi liên kết

Chúng ta hãy xem xét hai câu hỏi sau:

• Lưu trữ và truy vấn lượng lớn dữ liệu theo dõi liên kết
• Chi phí R&D và chuyển đổi tương đối cao và cần phải thực hiện số liệu thống kê về các thành phần khác nhau.

Dưới đây là một số suy nghĩ và giải pháp của tôi cho hai vấn đề này.

Lựa chọn phương pháp lấy mẫu

Đầu tiên là vấn đề lưu trữ và truy vấn dữ liệu theo dõi liên kết. Bởi vì dữ liệu theo dõi liên kết được tạo ra trong môi trường trực tuyến thường cực kỳ lớn nên không được thu thập đầy đủ và việc thu thập đầy đủ dữ liệu theo dõi liên kết chắc chắn sẽ dẫn đến tình trạng bị lỗi. nhiều dữ liệu không có sẵn có nghĩa là theo dõi dữ liệu được thu thập, làm tăng chi phí.

Điều này liên quan đến việc lựa chọn phương pháp lấy mẫu, về cơ bản làm giảm lượng dữ liệu được lấy mẫu và làm cho dữ liệu được lấy mẫu có ý nghĩa để giải quyết vấn đề tạo ra một lượng lớn dữ liệu theo dõi liên kết.

Giảm lượng dữ liệu lấy mẫu là một hướng tối ưu hóa. Nếu sau khi giảm lượng dữ liệu lấy mẫu mà dữ liệu lấy mẫu vẫn đủ lớn thì chúng ta chỉ có thể mở rộng dung lượng từ kiến ​​trúc để đáp ứng nhu cầu thu thập lượng dữ liệu lớn chẳng hạn. , nếu es được sử dụng để lưu trữ dữ liệu theo dõi, thì bạn có thể Thêm các nút cụm lưu trữ mới để giải quyết vấn đề lưu trữ số lượng lớn dữ liệu theo dõi và thêm bộ thu thập dữ liệu. Ví dụ: nếu sử dụng Opentelemetry, Opentelemetry Collector có thể là. được mở rộng để đáp ứng vấn đề thu thập số lượng lớn dữ liệu.

Về việc lựa chọn phương pháp lấy mẫu, chúng thường được chia thành hai phương pháp, lấy mẫu trước và lấy mẫu sau.

lấy mẫu trước

Lấy mẫu trước có nghĩa là xác định xem dữ liệu đã được thu thập hay chưa khi thu thập dữ liệu theo dõi từ nút đầu tiên. Ví dụ: nếu có các liên kết A, B và C, nếu quyết định lấy mẫu dữ liệu theo dõi tại A thì việc lấy mẫu này. chiến lược sẽ được B và C kế thừa, B và C cũng sẽ được lấy mẫu.

Lấy mẫu trước dễ hiểu hơn và dễ thực hiện hơn, nhưng lấy mẫu trước không hiệu quả lắm trong môi trường sản xuất vì nhiều khi chúng ta cần một liên kết hoàn chỉnh để dễ dàng xác định xem có nên thu thập toàn bộ liên kết hay không. Ví dụ: nếu có lỗi. trên toàn bộ liên kết thì chúng tôi hy vọng rằng toàn bộ liên kết sẽ được thu thập. Tuy nhiên, việc lấy mẫu trước không thể biết rằng lỗi xảy ra ở các khoảng tiếp theo trong giai đoạn thu thập đầu tiên. Để không bỏ lỡ dữ liệu theo dõi (có ý nghĩa) bị lỗi trực tuyến, chúng tôi thường tắt lấy mẫu xác suất điểm. Điều này dẫn đến thực tế là khi sử dụng lấy mẫu trước, nếu muốn đảm bảo rằng dữ liệu theo dõi phải được thu thập khi có lỗi. xảy ra thì chỉ có Tất cả dữ liệu theo dõi được lấy mẫu, đây rõ ràng không phải là thứ chúng ta cần.

bài lấy mẫu

Vì vậy, chúng ta hãy xem xét một phương pháp lấy mẫu khác để theo dõi liên kết, lấy mẫu sau chờ toàn bộ liên kết được thu thập trước khi đánh giá xem có cần thu thập toàn bộ liên kết hay không.

Do đó, lấy mẫu sau có một nơi để lưu trữ dữ liệu theo dõi vào bộ nhớ đệm. Lấy cấu hình sau lấy mẫu của Opentelemetry Collector làm ví dụ.

Sau khi nhận được dữ liệu nhịp của dấu vết, nó không quyết định ngay lập tức liệu dấu vết có nên được lấy mẫu hay không. Thay vào đó, sau khi đợi thời gian quyết định_wait, khoảng thời gian liên quan đến dấu vết sẽ được lấy ra khỏi bộ nhớ đệm để xác định xem có nên lấy mẫu hay không. Bộ nhớ không tăng vô hạn Có, num_traces giới hạn số lượng dấu vết tối đa có thể được lưu trữ.

Lưu ý rằng không nên đặt num_traces quá nhỏ, nếu không sẽ dễ đạt đến ngưỡng num_traces trong thời gian chờ quyết định_wait, khiến dữ liệu theo dõi chưa được xử lý sẽ bị loại bỏ.

bộ xử lý: tail_sampling: Decision_wait: 5s num_traces: 1 dự kiến_new_traces_per_sec: 1 chính sách: [ { name: test-policy-11, type: boolean_attribute, boolean_attribute: { key: Slowsql, value: true } } ]

Trong cấu hình ở trên, chiến lược lấy mẫu được đặt, nghĩa là nếu thuộc tính Slowsql được đặt thành true trong khoảng được thu thập thì được coi là cần thu thập dấu vết.

Lưu ý rằng chỉ cần một khoảng trong một dấu vết được xác nhận là cần được thu thập thì toàn bộ dấu vết sẽ được thu thập.

Có thể lưu ý rằng thông qua việc lấy mẫu sau, chúng ta có thể thiết kế một số chiến lược thu thập có ý nghĩa như sau, .

• Thu thập các liên kết nơi xảy ra lỗi trong liên kết yêu cầu
• Thu thập liên kết với truy vấn chậm
• Thu thập các liên kết có yêu cầu http chậm

Thông qua chiến lược này, chúng tôi có thể giảm thiểu việc lưu trữ dữ liệu không hợp lệ và giảm đáng kể chi phí thu thập, lưu trữ và truy vấn theo dõi liên kết. Tiếp theo, chúng ta hãy xem những thành phần nào có thể được sử dụng để triển khai lấy mẫu sau. Dưới đây tôi sẽ sử dụng kiến ​​trúc lấy mẫu sau tương đối phổ biến trong ngành làm ví dụ.

Lựa chọn công nghệ

Lấy mẫu sau có thể giải quyết vấn đề chỉ thu thập dữ liệu theo dõi hợp lệ, nhưng không phải tất cả các công cụ theo dõi liên kết đều có chức năng lấy mẫu sau. Ví dụ: jaeger chỉ hỗ trợ lấy mẫu trước. Khi sử dụng jaeger, bạn cần hợp tác với Opentelemetry Collector. và mượn Opentelemetry Collector. Chức năng lấy mẫu sau được sử dụng để lọc dữ liệu theo dõi, sau đó jaeger thu thập và hiển thị dữ liệu đó.

Toàn bộ kiến ​​trúc bộ sưu tập tương tự như thế này.

Opentelemetry Collector gửi dữ liệu sau lấy mẫu đến jaeger Collector để thu thập và cuối cùng hiển thị dữ liệu đó thông qua thành phần UI của jaeger. Kiến trúc này cũng là mô hình kiến ​​trúc được Jaeger chính thức đề xuất. Dưới đây là liên kết đến chế độ triển khai có liên quan của nó.

https://www.jaegertracing.io/docs/1.52/architecture/

Kế hoạch triển khai giám sát tự động

Giải pháp trên thông qua lấy mẫu sau có thể được coi là giải quyết được vấn đề thu thập một số lượng lớn dữ liệu theo dõi. Tiếp theo, chúng ta hãy xem xét các vấn đề chuyển đổi thành phần cơ bản cần thực hiện khi theo dõi các liên kết truy cập dịch vụ dự án.

Hiện tại, khi các dịch vụ Golang truy cập vào chức năng theo dõi liên kết, chúng chủ yếu xử lý nó bằng cách chôn các điểm trong khung cơ bản, bao gồm một lượng chi phí nghiên cứu và phát triển nhất định. Không giống như Java, công nghệ tiêm bytecode của Java có thể đạt được sự tích hợp bằng không đối với các dịch vụ kinh doanh. Công nghệ theo dõi liên kết truy cập xâm nhập.

Tuy nhiên, ở golang, hiện có một dự án mã nguồn mở opentelemetry-go-instrumentation trong ngành. Mục đích của nó là thực hiện giám sát tự động golang thông qua công nghệ epbf mà không cần sửa đổi mã dịch vụ. Bạn có thể chú ý đến khu vực này, nhưng hiện tại nó không hỗ trợ nhiều phạm vi giám sát tự động. Sau đây là địa chỉ truy cập của dự án.

https://github.com/keyval-dev/opentelemetry-go-instrumentation/tree/master

Do đó, tóm lại, các dịch vụ do golang xây dựng vẫn sẽ yêu cầu sửa đổi khung cơ bản theo cách thủ công hơn. Khi có thời gian, tôi sẽ giới thiệu cách sửa đổi khung liên quan để hỗ trợ theo dõi liên kết.

Cuối cùng, bài viết này về những thách thức và giải pháp trong việc triển khai theo dõi liên kết (lõi cứng của lõi cứng) ở đây. Nếu bạn muốn biết thêm về việc triển khai theo dõi liên kết (lõi cứng của lõi cứng). quá trình này, vui lòng tìm kiếm các bài viết của CFSDN hoặc tiếp tục duyệt các bài viết liên quan. Tôi hy vọng bạn sẽ ủng hộ blog của tôi trong tương lai! .