OpenTelemetry năm 2023

 (bit.kevinslin.com)
2 điểm bởi GN⁺ 2023-08-29 | 1 bình luận | Chia sẻ qua WhatsApp
  • OpenTelemetry, bắt đầu từ việc hợp nhất OpenTracing và OpenCensus vào năm 2019, sau 4 năm đã trở thành tiêu chuẩn observability bao quát trace, metric và log
  • Cấu trúc cốt lõi được chia thành đặc tả và triển khai, cùng cung cấp tiêu chí tương thích giữa các vendor và công cụ thực tế để instrumentation, thu thập dữ liệu
  • Đặc tả OTEL đã ổn định với tracing vào năm 2020, metric vào năm 2021 và log vào năm 2023, nghĩa là mọi tín hiệu đều đã stable, nhưng hỗ trợ log vẫn còn khác nhau giữa các SDK
  • OTLP và Collector là nền tảng để gửi và xử lý dữ liệu observability theo định dạng chung, và các agent của những vendor như Grafana, Datadog cũng triển khai chúng
  • OTEL đang mở rộng phạm vi sang Collector, Semantic Conventions, OpAMP, OTTL và Demo, trở thành nền tảng chung cho observability trung lập với vendor

Vị thế hiện tại của OpenTelemetry

  • OpenTelemetry, viết tắt là OTEL, bắt đầu vào năm 2019 khi OpenTracing và OpenCensus được hợp nhất
  • Ban đầu đây là một dự án tập trung vào tracing, nhưng sau khi hợp nhất, phạm vi đã mở rộng ra toàn bộ observability
  • Mục tiêu là giúp các tổ chức cung cấp telemetry chất lượng cao, phổ quát và có tính di động
  • Sau 4 năm, OTEL đã có những nền tảng sau
    • tiêu chuẩn ổn định cho metric, log và trace
    • Collector có thể nhận, xử lý và xuất telemetry trong mọi môi trường
    • SDK hỗ trợ instrumentation mã nguồn ở các ngôn ngữ chính
    • Semantic Conventions và các tiêu chuẩn bổ sung liên quan đến quản lý agent
  • Hiện tại OTEL là dự án năng động thứ hai trong CNCF sau Kubernetes, với cộng tác viên đến từ hầu hết các vendor observability lớn, và giao thức của nó gần như đã được các nhà cung cấp observability áp dụng rộng rãi

Cấu trúc OTEL: đặc tả và triển khai

  • OTEL được cấu thành chủ yếu bởi đặc tả (specification) và triển khai (implementation)
  • Đặc tả định nghĩa cách telemetry được ghi nhận, thu thập, xử lý và xuất ra
    • Có thể xem đây là tiêu chuẩn chung mà các vendor phải tuân theo để tương thích với OTEL
  • Triển khai là các thư viện client và công cụ xử lý dữ liệu telemetry
    • Đây là phần mà người dùng cuối trực tiếp tiếp xúc khi instrumentation mã nguồn
  • Mức độ ổn định của dự án thường được biểu thị theo từng tín hiệu
    • Trong OTEL, tín hiệu là các loại dữ liệu telemetry như metric, log và trace
  • Các dự án con chính gồm có
    • OpenTelemetry Specification
    • OpenTelemetry SDKs
    • OpenTelemetry Protocol
    • OpenTelemetry Collector
    • Open Agent Management Protocol
    • OpenTelemetry Semantic Conventions

OpenTelemetry Specification 1.24.0

  • OpenTelemetry Specification là nền tảng của OTEL, cung cấp API, SDK và mô hình dữ liệu làm cơ sở cho các tiêu chuẩn OTEL khác
  • Việc ổn định hóa được thực hiện theo từng tín hiệu
    • Tháng 9/2020: tracing stable
    • Tháng 11/2021: metric stable
    • Tháng 4/2023: log stable
  • Hiện tại đặc tả OTEL đã stable ở mọi tín hiệu
  • Vì tín hiệu log chỉ mới ổn định trong năm 2023 nên nhiều OTEL SDK vẫn chưa hỗ trợ log

OpenTelemetry SDK và auto instrumentation

  • OTEL SDK cung cấp instrumentation phía client dựa trên đặc tả OTEL
  • Mỗi SDK theo ngôn ngữ có mức độ trưởng thành riêng cho từng tín hiệu metric, log và trace
  • Một số SDK hỗ trợ auto instrumentation tùy theo ngôn ngữ lập trình
    • Auto instrumentation là cách SDK tự động chèn tín hiệu, chủ yếu là trace, vào mã ứng dụng để giảm gánh nặng instrumentation thủ công
  • Với các ngôn ngữ biên dịch như go và rust, auto instrumentation không hoạt động
  • Tuy vậy, nếu dùng các công cụ dựa trên eBPF hoặc service mesh bên ngoài SDK thì vẫn có thể có khả năng tự động chèn trace

OTLP 1.0 và tiêu chuẩn truyền dữ liệu

  • OTLP là wire protocol chung để truyền dữ liệu observability
  • Có hai phương thức truyền chính thức
  • Đặc tả này được xem là stable và có thể được triển khai bởi mọi dịch vụ nhận, xử lý và xuất dữ liệu OTEL
  • OTLP được OpenTelemetry Collector triển khai, đồng thời các agent của những vendor observability như Grafana và Datadog cũng triển khai nó

OpenTelemetry Collector 0.83.0

  • OTEL Collector là agent trung lập với vendor dùng để thu thập, chuyển đổi và truyền dữ liệu observability
  • Collector gồm các thành phần sau
    • receivers: nhận dữ liệu từ nhiều nguồn theo cơ chế push/pull
    • processors: chuyển đổi, lọc, bổ sung và suy diễn dữ liệu đang di chuyển
    • exporters: gửi dữ liệu tới đích downstream
    • connectors: hoạt động vừa như receiver vừa như exporter để nối nhiều pipeline lại với nhau
    • pipelines: chuỗi gồm receiver, 0 hoặc nhiều processor và exporter
    • extensions: cung cấp các chức năng ngoài xử lý telemetry như basic auth, health check
  • Các thành phần này cùng vận hành như một pipeline observability, cho phép thu thập telemetry từ bất kỳ nguồn nào, xử lý trên đường đi rồi gửi tới đích mong muốn
  • Collector được chia thành hai dự án
    • otel-collector: chỉ bao gồm các thành phần cốt lõi của Collector, chủ yếu chứa logic liên quan trực tiếp đến xử lý dữ liệu OTLP
    • otel-collector-contrib: bộ tích hợp bao gồm exporter và receiver cho phần lớn các nhà cung cấp observability
  • Tại thời điểm bài viết được viết, otel-collector-contrib bao gồm 91 receiver, 48 exporter và 24 processor
  • Người dùng cuối được khuyến nghị dùng OpenTelemetry Collector Builder để tạo bản dựng otel-collector-contrib tùy chỉnh chỉ chứa những thành phần cần thiết
  • Các vendor như AWS và Splunk cũng cung cấp bản phân phối OTEL riêng của họ

OpAMP và quản lý agent từ xa

  • OpAMP là giao thức mạng dành cho quản lý agent từ xa
  • Đây là tiêu chuẩn tương đối mới được thêm vào OTEL trong năm 2022, cung cấp cách làm trung lập với vendor để điều khiển một tập hợp agent
  • Đối tượng được quản lý có thể là các instance otel-collector, hoặc agent chuyên biệt của vendor có triển khai OpAMP
  • Với OpAMP, có thể kích hoạt các chức năng sau
    • triển khai cấu hình động
    • cập nhật agent
    • quản lý thông tin xác thực
  • Hiện tại triển khai Go của đặc tả OpAMP vẫn đang trong quá trình phát triển

Semantic Conventions và các dự án bổ sung

  • OTEL Semantic Conventions định nghĩa tập thuộc tính chung được dùng trong dữ liệu observability
  • Phạm vi áp dụng bao gồm tài nguyên đám mây, cơ sở dữ liệu, ngoại lệ, hệ thống và hơn thế nữa
  • Semantic Conventions được OTEL SDK sử dụng, và với các SDK hỗ trợ auto instrumentation thì chúng sẽ được áp dụng tự động
  • Hệ ngữ nghĩa chung này cho phép tương quan giữa các tín hiệu khác nhau
  • Những thành phần quan trọng khác của OTEL cũng tồn tại riêng
    • OpenTelemetry Transformation Language (OTTL): ngôn ngữ biến đổi chung cho telemetry, được thiết kế và triển khai trong otel-collector-contrib với hiệu năng và độ linh hoạt cao
    • OTEL Demo: trang mua sắm dựa trên microservice dùng để trình diễn các tính năng của OTEL và phần lớn SDK theo ngôn ngữ

4 năm thay đổi

  • OTEL khởi đầu từ việc hợp nhất các đặc tả tracing cạnh tranh và đã phát triển thành tiêu chuẩn ngành cho observability
  • 4 năm vừa qua là giai đoạn xây dựng nền tảng chung xuyên suốt các vendor và công cụ

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-08-29
Các ý kiến trên Hacker News

  • OpenTelemetry có hai vấn đề

    1. Bản chất không rõ ràng. Không biết nó là tiêu chuẩn ngữ nghĩa, giao thức, facade, thư viện, hay cung cấp tầng trừu tượng nào; câu trả lời gần như là “tất cả”
    2. Phía OpenTelemetry trông như chưa có ai thực sự thử instrument thư viện. Cũng không có đề xuất nào về việc người instrument nên dùng metric, trace, log như thế nào, nên dùng cả ba hay chỉ một trong số đó. Tôi đã hỏi 2 năm trước nhưng không nhận được câu trả lời: https://github.com/open-telemetry/opentelemetry-specificatio...
    • Đồng ý. Nó giống như đưa cho bạn cả bồn rửa lẫn căn nhà gắn với nó cùng một lúc, khiến tài liệu vừa mỏng vừa khó hiểu
      Tương tự, tôi từng muốn triển khai một heartbeat đơn giản trong ứng dụng desktop để nắm mức sử dụng, nhưng xét theo tên dự án thì thật ngạc nhiên là việc đó gần như bất khả thi. Phản hồi cho câu hỏi cũng ít, nên tôi đã bỏ hẳn kế hoạch dùng OpenTelemetry: https://github.com/open-telemetry/community/discussions/1598, https://github.com/open-telemetry/semantic-conventions/issue...
    • Đồng ý. Một số thứ OpenTelemetry khuyến nghị lại không thể làm được bằng SDK thực tế
      Ví dụ, không thể định nghĩa bucket gần nơi định nghĩa histogram. Bạn phải truyền một danh sách “override” ánh xạ từ tên histogram sang bucket ở đâu đó như exporter toàn cục. Nếu có một thư viện phát ra metric thì chuyện này trở nên rất lộn xộn: https://github.com/open-telemetry/opentelemetry-go/issues/38...
    • Đây là những câu hỏi hay, nhưng tôi không cho là quá quan trọng. Những câu hỏi như vậy rất khó có câu trả lời rõ ràng trong lĩnh vực observability, dù là OpenTelemetry hay hệ thống độc quyền khác
      Nhìn vào website của các công ty observability hàng đầu, nội dung về custom instrumentation cũng chỉ khoảng 4 trang và chỉ đề cập những điều rất cơ bản. Không phải OTel đặc biệt tụt hậu; câu trả lời phần lớn là “còn tùy”. Khi tích lũy kinh nghiệm, những điểm khiến người mới bối rối như thế này cũng có thể dần được tháo gỡ
    • Thứ cần làm thực ra chỉ ở mức duy trì 3 file schema JSON
    • Câu hỏi thứ ba là liệu có khả năng mở rộng hay không

  • Tôi rất thích OpenTelemetry và muốn theo dõi gần như mọi span. Nếu dùng một vendor nào đó, chắc tôi đã phá sản vì chi phí
    Tôi gắn OpenTelemetry gần như không tốn công nhờ Java auto-instrumentation, rồi gửi về ClickHouse tự host, lưu hơn 700 triệu span mỗi ngày trên một EC2 giá 100 đô: https://clickhouse.com/blog/how-we-used-clickhouse-to-store-...

    • Trong một dự án cá nhân nhỏ, tôi đang dùng SigNoz để gửi trace/log/metric vào ClickHouse. Khoảng 400.000–800.000 span mỗi ngày (https://i.imgur.com/s0J6Mzo.png), chạy trên một t4g.small duy nhất, CPU thường khoảng 11%, IOPS khoảng 4%
      Với thời gian lưu trace 1 tháng, signoz_index_v2 có 26,9 triệu hàng chiếm 17.06GiB, trace_log có 123 triệu hàng chiếm 2.64GiB, samples_v2 có 949 triệu hàng chiếm khoảng 345MiB, tỷ lệ nén khá tốt. Nếu dùng máy ClickHouse theo cấu hình khuyến nghị thì có lẽ đã giảm thời gian tinh chỉnh, nhưng hiện tại vẫn chạy tốt
      Nhược điểm là IOPS của ổ sc1 nhỏ chỉ khoảng 4 nên ClickHouse mất chừng 5 phút để khởi động, và UI của SigNoz tuy đủ chức năng nhưng khó kỳ vọng mức độ hoàn thiện như Datadog
    • Nên đặt tỷ lệ sampling, nhưng cần đảm bảo lỗi thì gửi đầy đủ
      Ở công ty cũ, chúng tôi chỉ thu thập 5% trace không phải lỗi
    • Thực tế là đa số không muốn tự vận hành kho lưu trữ ClickHouse, và không phải kỹ sư nào cũng xử lý SQL hiệu quả như code. Dù vậy đây vẫn là một cấu hình khá hay
    • Điểm hay nữa là công sức cấu hình cần thiết rất ít. Đó là tổ hợp Java auto-instrumentation + ClickHouse exporter + plugin Grafana ClickHouse

  • Tôi rất thất vọng về OpenTelemetry. Theo trải nghiệm của tôi, nó là một mớ hỗn độn được thiết kế quá mức, và trải nghiệm sử dụng mặc định rất thù địch với người dùng.
    Nó tự quảng bá như một định dạng tracing/metrics/logs đa dụng, cùng một bộ thư viện plug-and-play có adapter cho mọi thứ cần thiết, nhưng thực tế lại giống một bộ thư viện nửa vời với nhiều chi tiết triển khai nội bộ bị rò rỉ ra ngoài, chất lượng adapter kém và cũng không có nhiều tính năng.

    • Đồng ý. Mỗi lần dùng SDK, tôi có cảm giác phải suy nghĩ theo cách vuông góc với lẽ thường. Không có gì hoạt động như kỳ vọng, mọi thứ đều có 3 lớp trừu tượng không cần thiết, và phải đi đường cửa sau mới truy cập được.
      Rất nhiều tính năng đi kèm các điều kiện kiểu nó hoạt động khi nào, ở đâu, bao nhiêu, pha Mặt Trăng ra sao, khi sao Mộc hiện trên bầu trời, hay khi độ dài chuỗi ở mức nào.
      Dù vậy, nếu bỏ qua các API SDK bị rò rỉ và những tính năng mới triển khai nửa chừng, lời hứa về khả năng thay thế thì phần nào được giữ. Trước OTel, mọi thứ đều là stack chuyên dụng, nhưng giờ có thể cắm backend logging khác vào một SDK chuẩn và kỳ vọng nó phần lớn hoạt động. Nó vẫn kém hơn một stack tích hợp theo chiều dọc, nhưng từ góc nhìn kiến trúc thì đây là một thắng lợi một phần, vì cho phép cạnh tranh và tiến hóa theo từng phần mà không phải lật tung toàn bộ stack observability.
    • Tôi cũng đã trải qua cùng nỗi đau đó, nhưng khi dùng các lựa chọn thay thế tự nhận là tốt hơn vì có đặc tả OpenAPI thì cũng chẳng khá hơn bao nhiêu: https://github.com/openzipkin/zipkin-api-example
      Ví dụ chỉ cho thấy cách dùng công cụ swagger để phân tích đặc tả OpenAPI (https://github.com/openzipkin/zipkin-api/blob/master/zipkin2...), tự động sinh mã glue bằng Go, rồi gọi một hàm được sinh tự động để ghi trace.
      Hoàn toàn không có tài liệu hay ví dụ nào khác, nên tôi đã tự hỏi liệu có ai thật sự dùng cách này trong thực tế không, và cuối cùng đã dùng trực tiếp service API (https://zipkin.io/zipkin-api/#/) bằng các lời gọi REST. OTel thì đau đớn, nhưng các lựa chọn thay thế cũng chẳng tốt hơn. Khi việc đo SLO và SLI ngày càng quan trọng, tôi mong lĩnh vực này được quan tâm nhiều hơn.
    • Nếu vậy tôi muốn biết liệu có thể đề xuất lựa chọn thay thế nào không, hay đơn giản là chấp nhận OTel.
    • Sẽ rất tốt nếu có thể nêu trải nghiệm cụ thể và đề xuất cải thiện.

  • Thư viện chính thức của OTel hiện vẫn chưa hoạt động tốt trên frontend web. Ví dụ, ở trạng thái mặc định không có cách nào liên kết lỗi với sourcemap.
    Web browser collector do dự án OTel phát hành dùng Zone.js để chặn gần như mọi thứ trong trình duyệt dưới dạng context. Nếu từng dùng Angular hiện đại, bạn sẽ biết Zone.js đôi khi khá gây đau đớn và có thể đụng vào global, tạo ra hành vi khó dự đoán.
    Tôi cũng không rõ có chuẩn OTel nào cho những thứ như session replay hay không. Nhiều nền tảng telemetry như Sentry, Rollbar, DataDog đều hỗ trợ nó. Các nhóm backend có vẻ khá thích OTel, và tôi thích đặc tính băng qua ranh giới của span, cho phép theo dõi toàn bộ hệ thống bằng một tag duy nhất. Tuy nhiên payload được tạo ra đôi khi rất dài dòng, trong khi một số nền tảng logging thì gọn hơn. Trong thực tế tôi chưa cảm thấy đây là vấn đề lớn.

    • Trong môi trường Promise native và async/await, hiện có vẻ không có cách nào triển khai đúng đắn những thứ như Zone.js.
      Tôi cũng đã thử instrumentation thủ công, nhưng dễ lỗi và dài dòng. Trình duyệt thật sự cần thứ gì đó như https://nodejs.org/api/async_context.html#class-asynclocalst....
    • Trên hầu hết nền tảng, Otel giống điểm khởi đầu để xây dựng một thư viện instrumentation tốt hơn.
      Trong package của chúng tôi, chúng tôi đặt session replay, theo dõi exception cải tiến, v.v. lên trên phần triển khai SDK trình duyệt Otel/Splunk. Đáng tiếc là những thứ này còn rất xa mới được cung cấp mặc định. Dù vậy, tôi cho rằng việc có thể liên kết session frontend với trace/log backend đã thay đổi đáng kể trải nghiệm của developer: https://www.hyperdx.io/blog/browser-based-distributed-tracin...
    • Tài liệu này của Otel cũng đáng xem: https://opentelemetry.io/docs/instrumentation/js/getting-sta...
      Nó không giải quyết hoàn toàn vấn đề, nhưng là một điểm khởi đầu.
    • Real User Monitoring, phần instrumentation frontend của DataDog, cũng không được trau chuốt rõ rệt. Độ tinh tế chỉ ở mức thao tác với các khối Duplo.
      Tôi tò mò liệu đã có ai bắt đầu làm frontend tracing dù chỉ một chút chưa.
    • Tôi tò mò liệu bạn đã xem Grafana Faro chưa. Có thể cấu hình để gửi tới Grafana Agent, và Grafana Agent là mã nguồn mở, đồng thời có thể lưu trace ở nơi khác.

  • Tôi cùng vài đồng nghiệp đã có một ý tưởng hơi kỳ quặc rằng không còn cần log nữa. Thay vì thông điệp log, chỉ cần gắn span event: https://opentelemetry.io/docs/instrumentation/ruby/manual/#a...
    Sau đó chỉ log tiêu đề của span và liên kết tới span tương ứng trong Jaeger. Tôi mới thử trong dự án cá nhân nhưng cảm thấy khá ổn; chỉ mong Jaeger UI hỗ trợ tốt hơn kiểu sử dụng này
    Thực ra các đồng nghiệp đó cũng có một bài trình bày về chủ đề này. Nếu bạn ở gần Hannover, Đức, hãy tìm “Nie wieder Log-Files!” tại https://javaforumnord.de/2023/programm/

    • Tùy dự án greenfield đến mức nào, có thể bạn thậm chí không cần span event, trừ khi chỉ cần timestamp của một tác vụ cụ thể chứ không cần thời lượng
      Dùng span cho mọi tác vụ có ý nghĩa cũng giống như dùng structured log mạnh hơn. Điều này khó với nhiều hệ thống phải mang theo log hiện có, nhưng nếu đủ greenfield thì tôi khuyến nghị
    • Tôi cũng đã nghĩ đến cách này, nhưng tôi thích việc có thể nắm sơ bộ chuyện gì đang xảy ra bằng những công cụ đơn giản
      Để dùng trace thì có rất nhiều thứ phải hoạt động đúng. Hoặc có lẽ tôi vẫn thiếu kinh nghiệm nên thấy công cụ đáng sợ
    • Đây là ý tưởng của dự án Veneur của Stripe. Cách tiếp cận là xử lý span, log và metric theo cùng một định dạng, rồi “tự động” roll up cardinality khi cần
      Khi xem bài trình bày vài năm trước, tôi thấy nó rất hay, nhưng có vẻ sẽ rất khó thuyết phục các lập trình viên không phải SRE: https://github.com/stripe/veneur
    • Bạn cũng không cần gửi trace đi đâu cả. Có thể giữ chúng trong tiến trình và xây API trên dữ liệu trace in-memory đó
    • Chúng tôi cũng đang nói chuyện tương tự ở công ty. Nghe khá hợp lý, và tôi nghĩ có thể gần như loại bỏ hoàn toàn log

  • OpenTelemetry là một dự án dẫn dắt bởi marketing, được thiết kế kiểu ủy ban và triển khai một cách ngây thơ, kém hiệu quả; có vẻ mục tiêu chính là giúp các CTO Fortune X00 đánh dấu checkbox trong tài liệu roadmap chiến lược
    Đây không phải thứ mà người có quyền lựa chọn nên dùng

    • Các bình luận khác trong thread này nhìn chung là thiện cảm hoặc rất tích cực, nên tôi muốn nghe cụ thể hơn điều gì không tốt
    • Với tư cách là nhà sáng lập highlight.io, từ góc độ người tiêu dùng, tôi đã thấy nhiều giá trị trong OTEL. Chúng tôi dùng nó để mở rộng hỗ trợ ngôn ngữ cho nhiều khách hàng, và cộng đồng cũng rất cởi mở
      Ví dụ về thay đổi chúng tôi đóng góp ở đây: https://github.com/open-telemetry/opentelemetry-js/pull/4049
      Rất mong bạn chia sẻ lý do vì sao bạn cho rằng không ai nên dùng nó
    • Tôi không nghĩ đánh giá đó đúng. Ngược lại, có vẻ giống kiểu “các phần mềm mã nguồn mở đang xuất metric Prometheus và trace Jaeger, còn chúng tôi muốn bán một sản phẩm độc quyền thay thế và không muốn gửi patch cho mọi dự án” hơn
      Datadog thực sự đã đưa rất nhiều người đi thêm hỗ trợ Datadog vào các dự án OSS. Nhảy vào những codebase xa lạ là một năng lực mạnh, nên có lẽ cũng khá tốt cho giai đoạn đầu sự nghiệp
      OTel khiến các dự án mã nguồn mở dùng một lớp trừu tượng, để người dùng có thể mua dịch vụ thay vì tự host. Tôi không hẳn thích điều đó, nhưng nếu là dịch vụ do người ngoài công ty vận hành thì giờ tôi có lẽ sẽ cân nhắc OTel. Vì như vậy, nếu một người dùng muốn dùng Datadog, chúng tôi sẽ không cản trở họ
      Khi dùng OTel ở giai đoạn rất sớm, tôi thất vọng vì Go API rất kém hiệu quả. Để tăng counter cần context.Context, và abstraction cũng bị rò rỉ, chẳng hạn không có cách cấu hình histogram bucket khi xuất sang Prometheus. Tôi đoán bây giờ có lẽ đã sửa rồi
    • Nhận xét đó quá khắc nghiệt. Tôi nghĩ data model là một bước tiến đúng hướng
      Processor cũng khá có năng lực, và bộ sưu tập receiver cùng exporter contrib nhìn chung cũng ổn. Tôi không nói đây là lời giải tốt nhất, còn tùy use case, nhưng phê phán mạnh như vậy có vẻ không thỏa đáng. Nói thêm, tôi thuộc nhóm bảo trì fluent-bit
    • Điểm tuyệt vời là có thể để service nói bằng OTLP, rồi đơn giản hóa cấu hình ứng dụng thành gửi dữ liệu tới OTEL Collector
      Từ góc độ vận hành, bất kể developer thêm observability gì vào code, bạn vẫn có thể áp đặt việc lọc ở trung tâm, và ứng dụng cũng chỉ cần một lối vào trung tâm để nói chuyện
      Vì mọi thứ đều xuất OTLP, khi muốn chuyển sang backend mới thì chỉ cần đổi file YAML, không cần viết lại ứng dụng để hỗ trợ backend logging mới. Dù có khiếm khuyết, 10/10 lần tôi vẫn sẽ tiếp tục dùng OTEL thay vì quay lại cách cũ với các thư viện logging theo từng vendor

  • Tôi thật sự ghét popup đăng ký của blog này. Không có nút x, nên hoàn toàn không rõ rằng có thể đóng mà không cần đưa email
    Bên dưới nút đăng ký có dòng “continue reading” rất không trực quan; tôi không nghĩ nó sẽ hoạt động, và bấm ra ngoài cũng không đóng. Những thứ như thế này cần được cải thiện
    Về OpenTelemetry, từ lâu tôi đã muốn thử xem nó có cung cấp tất cả chức năng cần thiết khi gửi dữ liệu tới Datadog hay không. Nhưng nếu ngoài các chức năng cơ bản vẫn cần Datadog agent, thì nghĩa là lại có thêm một thứ phải quản lý và đào tạo, nên tôi còn do dự
    Tôi tò mò không biết có ai đã thực sự tích hợp với Datadog chưa. Mục tiêu không nhất thiết là tiếp tục bị khóa vào Datadog, nhưng hiện tại khá nhiều cảnh báo và log của chúng tôi nằm ở đó, nên nếu trước tiên chuyển sang OpenTelemetry thì về lý thuyết sau này có thể chuyển sang thứ khác

    • Popup đó là tính năng của medium.com. Tôi đồng ý là cực kỳ khó chịu
    • Cá nhân tôi thấy khảo sát còn tệ hơn. Nó hỏi ý kiến tôi, tôi bấm một lựa chọn, và được “thưởng” bằng một cửa sổ tạo tài khoản toàn màn hình
      Tôi bấm quay lại thì bị đưa về HN

  • Tôi thắc mắc liệu còn frontend nào không làm hao hụt đáng kể dòng doanh thu xét về chi phí nhân sự, hạ tầng và giấy phép hay không
    Nhận hơn 2.000 request mỗi giây, chỉ riêng việc duy trì log cũng đã đắt

    • Nếu chưa làm, tôi khuyên dùng trace sampling. Datadog APM không có cấu hình rẻ nên không gây ấn tượng
      Chúng tôi đang vận hành stack Jaeger tự quản với tỷ lệ sampling 0,1%, và so với Datadog APM thì chi phí gần như không đáng kể
      Sampling không hữu ích lắm với metric và log nên không có câu trả lời hay. Nếu gross margin của Datadog là 80% thì chi phí hạ tầng trong khoản bạn trả nhiều nhất là 20%, và nếu chi phí nhân sự của bạn thấp hơn 80% đó thì có thể tự vận hành một stack mã nguồn mở để cắt giảm rất nhiều chi phí. Dù dùng Datadog, cứ 3 tháng chúng tôi lại có một dự án giảm mức sử dụng, nên đằng nào cũng phải liên tục chăm sóc nó
    • Câu trả lời là sampling. Chỉ cần sample 1% request thành công và thu thập toàn bộ lỗi
      Chi phí là một vấn đề, nhưng bạn có thể ngạc nhiên khi thấy observability gây tải lên dịch vụ nặng hơn tưởng tượng. Nó dùng khá nhiều CPU
    • Cần định nghĩa tiêu chí của “đáng kể”. Ở công ty trước, chúng tôi route trace vào Cassandra, lưu trong AWS Elasticsearch domain và trực quan hóa bằng Jaeger
      Tôi cũng viết vài truy vấn Elasticsearch để tạo báo cáo cơ bản nhằm tìm các truy vấn chậm. Nếu làm theo tutorial OTEL/Jaeger thì đây là cấu hình khá tiêu chuẩn
      Trace ở mức vài trăm mỗi giây và chúng tôi thu thập toàn bộ mà không downsample. Thời gian lưu giữ có thể đặt là 7 ngày, và vào lúc tôi rời đi gần như chưa có tối ưu hóa thực sự nào. Tôi nghĩ chi phí hằng tháng vào khoảng vài chục đến vài trăm đô la
      Có thể định nghĩa hành vi tracing sampler bằng biến môi trường đặt cho container. Xem OTEL_TRACES_SAMPLER trong tài liệu: https://opentelemetry.io/docs/specs/otel/configuration/sdk-e...
    • Hầu hết các nhà cung cấp observability hiện nay đều hỗ trợ OTEL. Dự án OSS tôi tham gia cũng hỗ trợ thu thập OTEL: https://github.com/grafana/tempo/
    • Không hiểu vì sao lại bị downvote. Chúng tôi cũng có cùng nỗi đau, chỉ là ở quy mô 500.000 request mỗi giây
      Hiện đang dùng Datadog nhưng ai cũng biết nó quá đắt

  • Phần lớn thread này đang nói về việc dùng OpenTelemetry để gửi metric/log tới collector tự host
    Bản thân việc dùng một thư viện tiêu chuẩn được nhiều công cụ collector như ClickHouse hỗ trợ cũng hữu ích, nhưng một lợi ích khác là đặc tả cho phép truyền trace ID qua ranh giới hệ thống
    Nếu cả bạn và các dependency đều triển khai đặc tả OpenTelemetry, bạn có thể nhận được các span cho thấy chi tiết những gì đã xảy ra trong hành trình. Ví dụ, có thể biết nguyên nhân trang tải lâu là do database phải load disk page, hay span metadata plane của một dịch vụ cloud là nguyên nhân gây độ trễ cao

  • Tôi rất hài lòng với tiến triển của OpenTelemetry. Vài năm trước khi tôi thúc đẩy việc áp dụng, các developer còn do dự vì nó mới và chưa từng nghe đến; nhưng khi nhìn lại một năm trước, OpenTelemetry đã hiện diện khắp hệ thống của chúng tôi và cả nhà cung cấp log/tracing mà chúng tôi dùng cũng đang chuyển sang hướng đó