Khái niệm Observability và quá trình phát triển của các công cụ

• Khái niệm Observability:

  • Thước đo cho biết có thể suy luận trạng thái bên trong của hệ thống tốt đến mức nào từ các kết quả đầu ra (tri thức) ở bên ngoài hệ thống
  • Hệ thống động được thiết kế để ước đoán trạng thái hệ thống từ việc đo các giá trị đầu ra
  • Khi môi trường cloud trở nên phổ biến, cùng với việc ứng dụng được container hóa bằng Docker và kiến trúc microservice trở nên thông dụng, nhu cầu về Observability cũng tăng lên

• Sự khác biệt giữa Observability và monitoring:

  • Monitoring: điều do người dùng thực hiện. Cho thấy điều gì đang sai
  • Observability: khái niệm cấp cao bao gồm cả monitoring. Cung cấp phong phú thông tin nền về hoạt động bên trong và giải quyết các vấn đề hệ thống ở mức sâu hơn. Cho thấy cả việc “vì sao” có gì đó sai

• Những tình huống tổ chức cần Observability:

  • Khi sự cố xảy ra trên production và nảy sinh câu hỏi: “Dữ liệu để xác định nguyên nhân sự cố là gì, nằm ở đâu, và phải xem dữ liệu đó như thế nào?”
  • Khi một dịch vụ vẫn ổn đến tận 1 phút trước nhưng đột nhiên gặp vấn đề, và phải đối mặt với câu hỏi “Nên tìm nguyên nhân gốc rễ ở đâu?”
  • Khi tổ chức trăn trở “Làm thế nào để đội phát triển biết trước các dấu hiệu bất thường của dịch vụ trước cả khách hàng hoặc đội hỗ trợ/vận hành?”
  • Khi muốn tìm cách theo dõi hiệu quả lỗi dịch vụ và lỗi hiệu năng trong microservice, hoặc thắc mắc liệu “có thể kiểm tra điều này dưới dạng log hoặc application performance monitoring (APM) hay không”

• Quá trình phát triển của các công cụ Observability:

  • Từ sau những năm 2010, nhiều công cụ Observability đa dạng đã xuất hiện trong ngành IT
  • Năm 2010, Google giới thiệu hạ tầng theo dõi hệ thống phân tán quy mô lớn mang tên ‘Dapper’
  • Sau đó, Uber và Twitter lần lượt tạo ra các hệ thống distributed tracing là ‘Jaeger’ (Uber) và ‘Zipkin’ (Twitter)
  • ‘Open Tracing’ xuất hiện như một bộ API tiêu chuẩn để tiếp tục mô hình hóa và mô tả hoạt động của hệ thống phân tán
  • ‘Open Census’ được công bố: bộ thư viện đa ngôn ngữ dùng để thu thập metric ứng dụng và distributed tracing rồi truyền dữ liệu thời gian thực đến backend
  • Tiếp đó là sự xuất hiện của ‘Prometheus’
  • Năm 2019, bộ công cụ, API và SDK mang tên ‘Open Telemetry (OTel)’, tích hợp Open Tracing và Open Census, được công bố

• Open Telemetry:

  • Framework Observability mã nguồn mở, trung lập với nhà cung cấp
  • Dữ liệu telemetry giúp phân tích hiệu năng và hành vi của phần mềm bao gồm log, metric và trace; Open Telemetry được dùng để instrument, tạo, thu thập và xuất các dữ liệu này
    • Log: metadata dấu thời gian. Dùng để xác định nguyên nhân gốc rễ của sự cố
    • Metric: dữ liệu thống kê hoặc dữ liệu tổng hợp có các thẻ key/value được đo từ dịch vụ. Là các giá trị đo lường của dịch vụ được ghi nhận trong lúc runtime
    • Trace: bản ghi các sự kiện xảy ra với người dùng và ứng dụng. Ghi lại đường đi lan truyền của từng request riêng lẻ
  • Cách sử dụng: công cụ Observability gửi cảnh báo -> kiểm tra nội dung cảnh báo rồi vào dashboard để xác định điểm có vấn đề -> truy vấn chi tiết phần cụ thể tại điểm đó -> tìm và kiểm tra log -> tìm dữ liệu trace liên quan đến log này để nhận diện mẫu -> từ đó xác định và sửa vấn đề, triển khai Observability
  • Hầu hết các công cụ Observability được tạo ra ngày nay đều hỗ trợ Open Telemetry theo mặc định

• Lý do Open Telemetry ra đời:

  • Trước đây, mỗi backend Observability đều có thư viện instrument và agent riêng để truyền dữ liệu bằng công cụ của mình, và có nhiều cách khác nhau để instrument code
  • Không có định dạng dữ liệu tiêu chuẩn để gửi dữ liệu đến backend Observability
  • Sau đó, để tạo ra một tiêu chuẩn thống nhất, Open Tracing và Open Census được hợp nhất thành Open Telemetry

• SigNoz: công cụ APM mã nguồn mở

  • Giúp theo dõi ứng dụng và xử lý sự cố
  • Sử dụng công nghệ distributed tracing để nắm bắt software stack của người dùng
    • Theo dõi các metric ứng dụng như latency, requests per second, error rates
    • Quan sát cả các metric hạ tầng như mức sử dụng CPU hay bộ nhớ
    • Theo dõi request của người dùng trên toàn bộ dịch vụ
    • Thiết lập cảnh báo cho metric
    • Có thể đi đến đúng trace gây ra vấn đề để tìm nguyên nhân gốc rễ
    • Cũng có thể xem flame graph chi tiết của từng request riêng lẻ

[ninebow]

Cảm ơn bạn vì bài viết hay!

[ironlung]

Cảm ơn bạn đã để lại bình luận! :)

[kaistj]

Cảm ơn vì bài viết hay~

[ironlung]

Cảm ơn bình luận của bạn! :)

[jujumilk3]

Làm sao để giám sát việc hệ thống giám sát đang hoạt động tốt?

Tôi từng có một băn khoăn hơi giống trong bộ truyện tranh Watchmen, hóa ra lại có khái niệm gọi là observability, cảm ơn bạn.

[ironlung]

Cảm ơn bạn! Dạo này mình cũng thấy nổi lên những nơi phát triển các công cụ đơn giản hóa Observability bằng AI. Đây là một lĩnh vực mình muốn tìm hiểu thêm! :)

[inthelife]

Cảm ơn vì bài viết hay :)

[ironlung]

Cảm ơn bạn! :D