Monitoring & ObservabilityMonitoring & Observability

Thuộc bộ kiến thức Data Engineer Roadmap.

Tổng quan

Một pipeline có thể chạy xong với dấu tick xanh, không có lỗi nào trong log, và thời gian chạy nằm hoàn toàn trong khoảng bình thường — nhưng vẫn đưa cho team business một dashboard được xây trên dữ liệu cũ (stale), bị thiếu (truncated), hoặc âm thầm hỏng. Đây chính là vấn đề trọng tâm mà note này giải quyết: monitoring truyền thống chỉ cho bạn biết job có chạy hay không; nó không nói gì về việc dữ liệu mà job tạo ra có đúng hay không. Một câu SELECT COUNT(*) trên bảng đáng lẽ phải nhận 2 triệu dòng qua đêm nhưng chỉ nhận 4.000 dòng sẽ không làm bất kỳ exception nào bật lên ở đâu cả. Một thay đổi schema ở upstream đổi tên user_id thành userId sẽ không làm task Airflow nào fail; nó chỉ khiến mọi query downstream âm thầm trả về NULL cho cột đó, và người đầu tiên phát hiện ra chuyện này là một analyst bối rối hỏi tại sao số liệu cohort tuần trước lại tụt về 0.

Khoảng cách giữa “pipeline chạy thành công” và “pipeline tạo ra dữ liệu đúng” chính là lý do data engineering phát triển riêng một mảng gọi là data observability, khác biệt — nhưng được xây trên nền — các thực hành observability hạ tầng và ứng dụng tổng quát đã nói ở DevOps — Monitoring & Observability. Note đó bàn kỹ về ba trụ cột (metrics, logs, traces), Prometheus, SLO, và thiết kế alerting; nên đọc trước nếu các thuật ngữ đó còn xa lạ. Note này giả định bạn đã có nền tảng đó và đặt một câu hỏi hẹp hơn, sắc hơn: một khi đã biết job có chạy, làm sao biết được dữ liệu nó tạo ra có đáng tin không?

Cách đóng khung đã trở thành chuẩn ngành cho câu hỏi này là năm trụ cột của data observability do Monte Carlo Data phổ biến: freshness (độ mới), volume (khối lượng), schema (cấu trúc), distribution (phân phối giá trị), và lineage (dòng chảy dữ liệu). Mỗi trụ cột nhắm vào một kiểu lỗi âm thầm cụ thể mà pipeline có thể mắc phải — đến muộn, đến sai số lượng, đổi hình dạng mà không báo trước, trôi lệch thống kê ra ngoài phạm vi kỳ vọng, hoặc làm hỏng thứ gì đó downstream mà không ai ngờ tới. Note này sẽ đi qua từng trụ cột, đối chiếu trực tiếp operational monitoring với data monitoring, tóm tắt ngắn gọn cách bộ công cụ observability tổng quát (logs, metrics, Prometheus, Datadog) áp dụng cho code pipeline, rồi bàn cách thiết kế alerting sao cho bắt được sự cố dữ liệu mà không nhấn chìm cả team trong nhiễu. Về các quy tắc chất lượng dữ liệu và hệ thống metadata mà công cụ data observability thường xây dựng dựa trên, xem ./14-data-quality-governance-and-metadata.md; về scheduler và DAG mà các check này được gắn vào, xem ./09-workflow-orchestration.md.

Kiến thức nền tảng

Operational monitoring vs. data monitoring

Sự phân biệt quan trọng nhất trong toàn bộ chủ đề này là “monitoring” thực ra mang hai nghĩa hoàn toàn khác nhau tùy vào việc ai đang hỏi.

	Operational monitoring	Data monitoring (data observability)
Câu hỏi nó trả lời	Job có chạy không? Chạy mất bao lâu? Có lỗi không?	Dữ liệu job này tạo ra có đúng, đầy đủ, và mới không?
Tín hiệu điển hình	Exit code, thời gian chạy task, CPU/memory, số lần retry, trạng thái DAG run	Số dòng dữ liệu, tỷ lệ null, diff schema, dịch chuyển phân phối, độ trễ freshness
Nơi lưu trữ	UI orchestrator (Airflow/Dagster), Prometheus, Datadog	Nền tảng data observability, dbt tests, SQL check tự viết, bảng audit trong warehouse
Kiểu lỗi nó bắt được	Task crash, timeout, OOM, lỗi mạng	API upstream âm thầm đổi field; nguồn dữ liệu đột nhiên chỉ gửi 90% khối lượng thường ngày; bảng không update suốt 8 tiếng nhưng không task nào fail
”Xanh” thực sự chứng minh điều gì	Code đã chạy mà không throw lỗi	Không chứng minh điều gì về tính đúng đắn — một job có thể “thành công” trong khi ghi 0 dòng, toàn null, hoặc trùng lặp dữ liệu

Lý do sự phân biệt này quan trọng trong thực tế: một dashboard giám sát pipeline — loại được xây từ ba trụ cột trong note DevOps — có thể hoàn toàn xanh trong khi một dashboard business xây trên output của pipeline đó lại âm thầm sai. Một câu INSERT chạy trên một bảng nguồn rỗng “thành công” xét về mọi khía cạnh operational: exit code trả về 0, không throw lỗi, chạy trong thời gian bình thường. Nó cũng ghi 0 dòng, và trừ khi có gì đó đang kiểm tra rõ ràng dữ liệu, không ai biết chuyện này cho tới khi một stakeholder để ý thấy biểu đồ nằm ngang vài ngày sau. Data observability tồn tại chính là để lấp khoảng trống này — giám sát nội dung (payload), chứ không chỉ tiến trình mang nó.

Logs, metrics, traces cho code pipeline — tóm tắt ngắn

Ba trụ cột từ note DevOps vẫn áp dụng trực tiếp cho việc thực thi pipeline, và là nền tảng cần thiết trước khi data observability có ý nghĩa — bạn không thể lý luận về “dữ liệu có bị muộn không” nếu chưa có timestamp, và không thể debug tại sao job fail nếu không có structured log. Trong bối cảnh data engineering cụ thể:

• Structured logging trong job orchestration. Mỗi lần task thực thi nên log, ở định dạng structured (JSON), tối thiểu: tên DAG/flow, tên task, run ID, thời điểm bắt đầu/kết thúc, và — điều quan trọng nhưng hay bị bỏ qua — số dòng đã đọc và ghi. {"dag": "orders_daily", "task": "load_fct_orders", "run_id": "2026-07-19T02:00", "rows_read": 482913, "rows_written": 482913, "duration_s": 94} là một dòng log hỗ trợ cả debug operational (task có chạy không, mất bao lâu) lẫn tuyến đầu của data monitoring (số dòng, có thể thấy ngay mà không cần query warehouse). Thực hành logging tổng quát — level, structured field, correlation ID, tổng hợp log bằng Loki/ELK — đã được nói ở DevOps — Monitoring & Observability; điều bổ sung riêng cho data pipeline chỉ đơn giản là: luôn log hình dạng (shape) của dữ liệu bạn đụng vào, không chỉ việc code có chạy hay không.
• Công cụ metrics. Prometheus vẫn là chuẩn cho metrics hạ tầng và runtime pipeline — thời gian chạy task, độ sâu queue, CPU/memory worker, counter thành công/thất bại của DAG được export qua tích hợp StatsD của Airflow hoặc metrics tích hợp sẵn của Dagster. Các nền tảng observability rộng hơn như Datadog, New Relic, Sentry thường chính là những công cụ mà phần còn lại của tổ chức kỹ thuật đã dùng cho application monitoring và error tracking; team data thường cắm metrics pipeline và exception vào các nền tảng chung này thay vì dựng hạ tầng riêng, giúp on-call và incident response thống nhất giữa team data và team ứng dụng. Các công cụ này đã được nói kỹ ở note DevOps; không có gì thay đổi cho data pipeline ngoài việc cái gì được instrument.
• Traces ít quan trọng hơn với batch ETL/ELT (một DAG chạy đêm không có “request” nào để trace) nhưng lại trực tiếp liên quan với pipeline streaming/real-time, nơi hành trình của một event qua ingestion → xử lý → sink hưởng lợi từ cùng khái niệm distributed tracing như microservices — xem ./11-streaming-and-realtime-data.md.

CAP theorem, nhìn lại từ góc độ observability

Khi một alert bật lên báo “dữ liệu đang trông không nhất quán”, sẽ rất hữu ích nếu bạn đã biết trước liệu hệ thống đó có từng được cam kết consistency chặt chẽ hay không. CAP theorem và hệ quả thực tiễn của nó — sự đánh đổi giữa consistency và availability khi có network partition, cùng phổ các mô hình consistency (strong, eventual, causal) mà các data store phân tán lựa chọn — đã được bàn kỹ ở Backend — NoSQL Databases. Điểm cần rút ra ở góc độ observability: nếu hệ thống nguồn được xây trên một store eventually-consistent (nhiều NoSQL database, một số cache replicated, hầu hết setup multi-region), thì việc một replica trễ vài giây và tạm thời trả về dữ liệu cũ là hành vi kỳ vọng, không phải sự cố. Phân biệt được “store này eventually consistent và đây là độ trễ replication bình thường” với “store này lẽ ra phải strongly consistent và có gì đó thực sự hỏng” giúp tránh cả báo động giả (page on-call vì độ trễ vốn dự kiến) lẫn sự chủ quan giả (bỏ qua một vấn đề staleness thật sự chỉ vì “eventual consistency mà”). Freshness monitoring, bàn ở phần sau, thực chất là một công cụ ở tầng business phản ánh chính sự căng thẳng giữa consistency và tính kịp thời này.

Horizontal vs. vertical scaling, sync vs. async — lý luận về nghẽn cổ chai

Hai khái niệm hệ thống phân tán tổng quát xuất hiện liên tục khi diễn giải tại sao một alert data monitoring bật lên. Vertical scaling (máy lớn hơn — thêm CPU/RAM cho một node warehouse hoặc Spark driver duy nhất) có trần và một điểm lỗi duy nhất (single point of failure); horizontal scaling (thêm worker/node/shard) là cách hầu hết nền tảng dữ liệu hiện đại (Spark, Snowflake, BigQuery, Kafka) hấp thụ khối lượng tăng, nhưng nó dịch chuyển nghẽn cổ chai sang phối hợp (coordination), shuffle dữ liệu, và lệch phân vùng (partition skew) — một anomaly về volume đôi khi thực ra là vấn đề “một partition nhận gấp 100 lần dữ liệu so với các partition khác” chứ không phải nguồn thực sự giảm khối lượng. Giao tiếp synchronous (một bước pipeline block chờ phản hồi API) khiến độ trễ cộng dồn và một dependency chậm làm nghẽn cả chuỗi, đe dọa trực tiếp SLA về freshness; giao tiếp asynchronous (queue, event stream, pub/sub) tách rời tốc độ producer và consumer nhưng lại đưa câu hỏi freshness trở lại dưới một hình thức khác — “consumer đang chậm bao xa so với đầu stream” (consumer lag) tự nó chính là một metric freshness. Các khái niệm này được bàn tổng quát hơn từ góc độ thiết kế hệ thống ở Backend; điểm cần lưu ý ở đây hẹp hơn: trước khi coi một alert freshness hoặc volume là “dữ liệu sai”, hãy kiểm tra xem đó có phải thực ra là “hạ tầng bên dưới đã scale hoặc giao tiếp theo cách làm thay đổi khái niệm ‘bình thường’” hay không.

Khái niệm chính

Năm trụ cột của data observability

Monte Carlo Data đã phổ biến một khung năm trụ cột từ đó trở thành từ vựng mặc định của mảng này (được các công cụ cạnh tranh như Bigeye, Soda, Metaplane áp dụng, với vài biến thể nhỏ). Mỗi trụ cột tương ứng với một kiểu lỗi âm thầm khác nhau — một cách pipeline trông ổn về mặt operational trong khi dữ liệu bên dưới lại sai.

Freshness (độ mới)

Freshness đặt câu hỏi: dữ liệu có đến đúng thời điểm cần thiết không? Một bảng mà dashboard BI kỳ vọng cập nhật mỗi giờ, nhưng lần update gần nhất cách đây sáu tiếng, là một lỗi freshness — và đó là lỗi âm thầm, vì job upstream vốn thường điền dữ liệu vào bảng đó có thể đơn giản là ngừng được schedule, bị kẹt trong queue, hoặc bị bỏ qua âm thầm, mà không throw lỗi ở bất kỳ đâu. Giám sát freshness thường hoạt động bằng cách theo dõi, cho từng bảng, timestamp của lần update gần nhất (hoặc giá trị max của cột updated_at/loaded_at) và cảnh báo khi độ trễ giữa “hiện tại” và “lần update cuối” vượt ngưỡng kỳ vọng. Bản thân ngưỡng cần được học hoặc cấu hình riêng cho từng bảng — một bảng update mỗi 15 phút và một bảng update mỗi ngày đều cần giám sát freshness, nhưng với khung cảnh báo khác nhau hoàn toàn. Đây là trụ cột liên quan trực tiếp nhất tới kịch bản “họp BI 8 giờ sáng”: nếu dashboard cấp điều hành cần fct_orders phải mới tính đến 8 giờ, freshness monitoring chính là thứ page ai đó lúc 7 giờ thay vì để VP là người phát hiện đầu tiên.

Volume (khối lượng)

Volume đặt câu hỏi: lượng dữ liệu có nằm trong khoảng kỳ vọng không? Một nguồn thường gửi 500.000 event mỗi ngày mà đột nhiên chỉ gửi 50.000 — giảm 90% — gần như chắc chắn báo hiệu một vấn đề upstream đáng để điều tra: một tích hợp API bị hỏng, một đối tác ngừng gửi feed, một filter upstream bị áp nhầm. Tương tự, một cú tăng đột biến 10 lần về volume có thể chỉ ra lỗi xử lý trùng lặp (cùng một batch bị ingest lại) chứ không phải tăng trưởng thật. Giám sát volume thường được triển khai bằng cách theo dõi số dòng theo từng bảng hoặc từng lần load, so sánh với baseline lịch sử (trung bình trượt, baseline có nhận biết ngày trong tuần, hoặc ngưỡng phần trăm thay đổi đơn giản), và đây là một trong những check rẻ nhất để thêm vào vì số dòng gần như luôn đã sẵn có từ chính job load — điểm đã nói ở trên về việc log rows_read/rows_written trong structured log chính là nguồn cấp trực tiếp cho trụ cột này.

Schema (cấu trúc)

Schema đặt câu hỏi: hình dạng của dữ liệu có thay đổi mà không ai được báo không? Một cột bị đổi tên, một kiểu dữ liệu chuyển từ INT sang STRING, một field lồng nhau được thêm hoặc bỏ, một API nguồn thêm một field bắt buộc mới — bất kỳ điều nào trong số này đều có thể âm thầm phá vỡ các transformation downstream, hoặc bằng cách tạo ra NULL ở nơi một JOIN hay tham chiếu cột không còn khớp, hoặc bằng cách khiến một phép cast fail sâu bên trong một transformation mà không ai theo dõi đủ sát để nhận ra kịp thời. Giám sát schema hoạt động bằng cách chụp snapshot schema (tên cột, kiểu, cấu trúc lồng nhau) ở mỗi lần load và diff với snapshot trước đó, cảnh báo khi có thay đổi bất ngờ — trong khi vẫn cho phép một luồng rõ ràng, đã được review, cho việc tiến hóa schema có chủ đích (một migration, một cột mới có chủ ý) đi qua mà không báo động. Trụ cột này chồng lấn trực tiếp với các thực hành schema validation và contract testing ở ./14-data-quality-governance-and-metadata.md; note đó bàn về khía cạnh governance (ai sở hữu một schema, thay đổi được review và truyền đạt như thế nào), còn trụ cột này bàn về khía cạnh phát hiện (bắt được một thay đổi xảy ra mà hoàn toàn không đi qua quy trình đó).

Distribution (phân phối giá trị)

Distribution đặt câu hỏi: các giá trị bên trong dữ liệu có bình thường về mặt thống kê không? Số dòng có thể chính xác tuyệt đối và schema có thể không hề bị đụng tới trong khi giá trị của từng cột trôi lệch theo những cách khiến dữ liệu sai về bản chất: một cột discount_pct lẽ ra nằm trong khoảng 0–100 đột nhiên chứa giá trị âm; tỷ lệ null trên email vốn thường dưới 1% nhảy vọt lên 40% vì một form upstream ngừng bắt buộc field đó; một cột phân loại (categorical) lẽ ra chỉ chứa năm trạng thái đã biết bắt đầu chứa giá trị thứ sáu chưa được ánh xạ. Giám sát distribution so sánh các đặc tính thống kê — tỷ lệ null, giới hạn min/max, mean/độ lệch chuẩn, cardinality của các trường phân loại, tính duy nhất của key — với baseline lịch sử, và là trụ cột chồng lấn nhiều nhất với kiểm thử chất lượng dữ liệu kiểu cổ điển (dbt test, Great Expectations, Soda checks): khác biệt trong thực tế chủ yếu nằm ở việc các check được viết tay theo từng cột (data quality testing) hay được tự động suy ra và giám sát liên tục bởi một nền tảng học “bình thường” từ lịch sử (công cụ data observability).

Lineage (dòng chảy dữ liệu)

Lineage đặt câu hỏi: nếu cái này hỏng, cái gì khác sẽ hỏng theo? Freshness, volume, schema, và distribution đều phát hiện rằng có gì đó sai; lineage là thứ cho bạn biết phạm vi ảnh hưởng (blast radius) — những bảng downstream, dashboard, feature ML, và báo cáo nào phụ thuộc vào bảng vừa gặp sự cố, và ai sở hữu chúng. Không có lineage, một bảng nguồn hỏng duy nhất chỉ tạo ra một alert và một số nạn nhân downstream âm thầm không xác định: các dashboard cách ba bước join lặng lẽ trở nên cũ hoặc sai, và những người muốn biết chuyện này không bao giờ được báo, vì chẳng ai từng vẽ ra dependency đó từ đầu. Lineage thường được thu thập bằng cách parse các lệnh SQL/dbt ref()/source() để tự động xây dựng đồ thị phụ thuộc, hoặc qua metadata do orchestrator và warehouse đẩy ra (column-level lineage trong các công cụ như OpenLineage, DAG tích hợp sẵn của dbt, hoặc lineage từ lịch sử query gốc của warehouse). Trụ cột này vừa mang tính metadata/governance vừa mang tính observability, và được bàn thêm từ góc độ cataloging ở ./14-data-quality-governance-and-metadata.md.

Tóm tắt các trụ cột — điều gì hỏng nếu bỏ qua, cách giám sát điển hình

Trụ cột	Điều gì hỏng nếu bỏ qua	Cách giám sát điển hình
Freshness	Dashboard và báo cáo âm thầm trở nên cũ; quyết định được đưa ra dựa trên số liệu của hôm qua (hoặc tuần trước) mà không ai nhận ra	Theo dõi max(updated_at)/loaded_at theo từng bảng; cảnh báo khi hiện tại trừ lần update cuối vượt ngưỡng kỳ vọng riêng cho từng bảng
Volume	Sự cố upstream, tích hợp hỏng, hoặc load trùng lặp không bị phát hiện vì job vẫn “thành công”	Theo dõi số dòng theo từng lần load, so với baseline lịch sử/có nhận biết ngày trong tuần; cảnh báo khi lệch phần trăm
Schema	Join/cast downstream âm thầm fail hoặc trả về NULL; transformation hỏng theo cách trông giống vấn đề dữ liệu chứ không phải vấn đề schema	Chụp snapshot schema theo từng lần load, diff với snapshot trước, cảnh báo khi có thay đổi chưa được review; kiểm tra contract/schema registry ở khâu ingestion
Distribution	Giá trị sai về mặt thống kê (null, số ngoài khoảng, category chưa được ánh xạ) lan vào các aggregate và model mà không bị phát hiện	Theo dõi tỷ lệ null, min/max, mean/stddev, cardinality theo từng cột so với baseline lịch sử; dbt tests / Great Expectations / Soda checks
Lineage	Một sự cố upstream duy nhất gây thiệt hại downstream không xác định, không được ánh xạ — không ai biết cần kiểm tra gì hoặc báo cho ai	Đồ thị phụ thuộc tự động từ việc parse SQL/dbt hoặc metadata kiểu OpenLineage; column-level lineage trong catalog

Best Practices

Thiết kế alert quanh SLA, không phải ngưỡng thô

Cách bền vững nhất để tránh cả bỏ sót sự cố lẫn alert fatigue là neo alert vào một cam kết business thực sự thay vì một ngưỡng thống kê tùy tiện. Nếu buổi họp sáng của team finance phụ thuộc vào việc fct_revenue phải mới tính đến 8:00 sáng, đó chính là SLA: “bảng này phải được update trước 08:00” là một điều kiện cụ thể, có thể kiểm chứng, ánh xạ trực tiếp sang một check freshness, và nó cho bạn biết chính xác mức độ khẩn cấp khi bị vi phạm (rất khẩn cấp — ai đó sắp trình bày số liệu cũ) so với một tín hiệu chung chung kiểu “bảng này hôm nay chậm hơn 20% so với bình thường”, vốn có thể hoàn toàn ổn. Hãy viết rõ các SLA này cho từng bảng quan trọng — hạn chót freshness, khoảng volume chấp nhận được, chủ sở hữu, và các bên tiêu thụ downstream — theo cách một team SRE viết SLO cho service, và xử lý vi phạm SLA dữ liệu với mức độ nghiêm túc của incident response tương tự như những gì note DevOps mô tả cho error-budget burn.

Tinh chỉnh ngưỡng theo anomaly thật, không phải nhiễu

Một check volume bật lên mỗi khi số dòng hàng ngày dao động hơn 2% sẽ thỉnh thoảng đúng và thường xuyên sai, và những báo động giả liên tục sẽ huấn luyện đội on-call bỏ qua kênh cảnh báo hoàn toàn — tương đương alert fatigue trong data observability mà phần alerting của note DevOps đã mô tả. Ưu tiên các baseline có tính đến biến động đã biết, kỳ vọng trước: tính mùa vụ theo ngày trong tuần (volume thứ Hai khác volume thứ Bảy với hầu hết doanh nghiệp consumer), đợt tăng vọt cuối tháng/cuối quý, và xu hướng tăng trưởng dần dần, thay vì một dải phần trăm phẳng tính so với riêng hôm qua. Khi có thể, để vài tuần lịch sử tự thiết lập khoảng “bình thường” thay vì chọn tay ngưỡng ngay từ ngày đầu — đây chính là điều các nền tảng data observability chuyên dụng (Monte Carlo, Bigeye, Metaplane) tự động hóa, so với các check dbt/SQL viết tay, vốn cần tinh chỉnh ngưỡng thủ công nhiều hơn theo từng bảng.

Kết hợp data observability với pipeline observability thay vì thay thế nó

Data observability không làm cho operational monitoring trở nên thừa thãi — nó nằm chồng lên trên đó. Một pipeline được instrument tốt vẫn cần các metrics ở cấp task, structured log, và alerting DAG-run đã nói ở note DevOps; data observability thêm vào một lớp check thứ hai, độc lập, trên output của các task đó. Trong thực tế, hầu hết các team gắn cả hai vào cùng một orchestrator: hook on_failure_callback/SLA-miss của chính DAG Airflow xử lý các lỗi operational, trong khi một task data-quality ở cuối DAG (một lần chạy dbt test, một checkpoint Great Expectations, hoặc một lời gọi API tới nền tảng data observability) xử lý lớp tính đúng đắn của dữ liệu, và cả hai đều đẩy alert vào cùng một kênh on-call để không ai phải kiểm tra hai dashboard riêng biệt mới biết được liệu lần chạy đêm qua có thực sự đáng tin hay không.

Làm cho lineage và ownership dễ tra cứu trước sự cố, không phải trong lúc sự cố

Thời điểm tệ nhất để tìm hiểu “ai sở hữu bảng này và cái gì phụ thuộc vào nó” là giữa lúc sự cố đang diễn ra. Hãy đầu tư vào một đồ thị lineage được tạo tự động (qua DAG của dbt, OpenLineage, hoặc một công cụ catalog) và đảm bảo mọi bảng quan trọng đều có chủ sở hữu được gán từ trước, trước khi có bất kỳ sự cố thực sự nào xảy ra — điều này biến một cuộc điều tra root-cause dựa trên lineage từ một cuộc săn lùng trên Slack thành một lần tra cứu đồ thị mất hai phút, và là thứ thực sự khiến trụ cột “phạm vi ảnh hưởng” hữu ích về mặt vận hành thay vì chỉ mang tính lý thuyết.

Tài liệu tham khảo

• Monte Carlo Data — What is Data Observability?
• Monte Carlo Data — The Five Pillars of Data Observability
• Monte Carlo Data — Data Reliability Engineering
• OpenLineage documentation
• dbt — Data tests
• Great Expectations documentation
• Google SRE Book — Monitoring Distributed Systems
• DevOps — Monitoring & Observability (repo này)