Một công ty SaaS từng mất tới 40 giây để phát hiện sự cố, trong khi khách hàng đã nhận ra ngay lập tức. Họ đã tối ưu hóa hệ thống monitoring bằng cách kết hợp OpenTelemetry, Apache Kafka và Apache Flink trên Kubernetes để giảm thời gian phát hiện sự cố xuống dưới 10 giây. Sự thay đổi này giúp hệ thống xử lý dữ liệu từ 300GB/giây với độ trễ chỉ 50ms, thay vì phải chờ hàng chỗi giây trước đó. Điều đáng học hỏi là cách họ thiết kế pipeline xử lý dữ liệu với Flink stateful processing để phát hiện bất thường trong thời gian thực, kết hợp với Kafka buffering đảm bảo độ tin cậy của dữ liệu ngay cả khi hệ thống gặp sự cố.
AI có thể tóm tắt sai. Đọc bài gốc trước khi dựa vào thông tin quan trọng.
Vì sao nên đọc: Bài viết này giúp lập trình viên tối ưu hóa hệ thống giám sát sự cố từ 40 giây xuống dưới 10 giây bằng cách triển khai lại hệ thống phát hiện sự cố trên OpenTelemetry, Apache Kafka và Apache Flink.
Trả lời 3 câu hỏi ngắn để nhận điểm thưởng cho bài này. Chỉ làm khi bạn muốn lấy điểm.
3 câu hỏi · dưới một phút · không bắt buộc
Nguồn: https://www.cncf.io/blog/2026/09/30/from-40-seconds-to-under-10-rebuilding-incident-detection-on-opentelemetry-apache-kafka-and-apache-flink-on-kubernetes. 8 Sync News chỉ tóm tắt và dẫn link; bản quyền nội dung thuộc tác giả và nguồn gốc.
Đọc tin ở đây, luyện code, học theo lộ trình và luyện IELTS trên các sản phẩm anh em — tất cả kết nối với nhau trong hệ sinh thái 8 Sync.
Cổng chính của hệ sinh thái: giới thiệu sản phẩm, blog và bảng giá trọn bộ.
Khám pháHọc theo lộ trình rõ từng chặng: video, quiz chấm tự động, certificate và mentor đang làm nghề.
Xem lộ trình1.000 bài DSA, đề tiếng Việt, chấm tự động 7 ngôn ngữ — nhiều bài FREE, chạy ngay trên trình duyệt.
Luyện miễn phíChấm bốn kỹ năng IELTS bằng AI, phản hồi chi tiết theo rubric.
Dùng thử miễn phíAI IDE 22 MB cho dev Việt.
Tải miễn phíBộ nhớ tổ chức cho AI agent.
Khám pháAI trực Fanpage, tự sàng lọc lead.
Dùng thửEvent-driven architecture (EDA) phổ biến nhưng tiềm nhiều thách thức trong production environment. Vấn đề truy xuất lỗi (tracing) trở nên phức tạp khi sự kiện (event) đi qua nhiều service khác nhau, đòi hỏi hệ thống phân tích log tập trung như ELK stack. Hàng đợi tin hỏi (dead letter queues) dễ bị đầy nếu không implement validation logic kỹ càng, dẫn đến mất dữ kiện quan trọng. Sự không nhất quán cuối cùng (eventual consistency) gây race condition khi nhiều consumer xử lý cùng event đồng thời. Các EDA system cần thiết kế event schema versioning và comprehensive testing framework với Contract Testing để đảm bảo reliability khi số lượng service tăng lên.
Bài viết này giúp lập trình viên nhận diện và giải quyết các vấn đề phổ biến trong kiến trúc hướng sự kiện như tracing, dead letter queues, tính nhất quán cuối cùng và testing.
What is OpenTelemetry? See how the OTel framework standardizes traces, metrics, and logs so you can switch backends freely.
OpenTelemetry JavaScript has released SDK 3.0 (stable v3.0.0 packages and experimental v0.300.0 packages) and API 1.10.0. Migration guide For a detailed description of breaking changes, see the OpenTelemetry JS SDK 3.x migration guide. What is JS SDK 3.x? JS SDK 3.x encompasses new releases of the @opentelemetry/* JavaScript packages published from the opentelemetry-js repository, except the API and semantic-conventions packages. The package versions for this new major will be >=3.0.0 for the stable and >=0.300.0 for the unstable packages. Details on the full list of packages can be found in the migration guide.
To make accurate decisions at machine speed, we need to maintain the state of the business as it changes. It needs to be always current, decentralized across systems that already run the business, and dependable for software to act on it. The architecture that makes this possible is the Streamhouse.
LinkedIn has built an OpenTelemetry-based telemetry platform that connects what members do in its iOS, Android, and web applications with the backend services processing those interactions.
Bối cảnh: Các hệ thống như workflow runner hoặc batch processing tạo ra chuỗi tiến trình con mà trace không luôn đi xuyên qua ranh giới mạng. Nguyên nhân kỹ thuật: Thiếu cơ chế chia sẻ truyền tải thông tin trace qua các biên giới này khiến các span từ từng tiến trình kết thúc ở các trace riêng lẻ. Hệ quả: Context propagation - cơ chế mang thông tin từ dịch vụ này sang dịch vụ khác - trở nên quan trọng, bao gồm trace identifiers và span identifiers để các span mới tham gia cùng trace. Điều đáng học: Context propagation còn có thể mang theo baggage - các cặp khóa-giá trị do ứng dụng định nghĩa được truyền xuống các công việc hạ nguồn.
Bài viết này giúp lập trình viên hiểu cách đảm bảo việc truyền ngữ cảnh thông qua biến môi trường để duy trì tính nhất quán trong hệ thống phân tán và quy trình liên tục.
Bối cảnh: The Kubernetes attributes processor đã đạt version 1.0.0, component này giúp enrich telemetry data với metadata từ Kubernetes. Nguyên nhân kỹ thuật: Phiên bản 1.0.0 này đã đáp ứng các tiêu chí 'stable' bao gồm testing, benchmarking, documentation và telemetry stability. Hệ quả: Bạn có thể sử dụng processor này trên custom distribution hoặc qua opentelemetry-collector-contrib và opentelemetry-collector-k8s distro. Điều đáng học: Component này hiện có thể redistributed như Go library hoặc binary mà không lo API breakage.
Bài này quan trọng vì trình xử lý thuộc tính Kubernetes đạt phiên bản ổn định v1.0.0, đảm bảo khả năng tích hợp tin cậy cho hệ thống giám sát của bạn.
Dynatrace unifies AI Observability ingest across coding agents, OneAgent, and OpenInference.
Đang tải bình luận…