Observability và monitoring

Bài toán

Lúc đầu, monitoring là vài dashboard và một công cụ cài sẵn; log đọc thẳng từ máy. Khi hệ lớn lên, chính hệ quan sát thành một hệ phân tán có bài toán riêng:

• Dữ liệu quan sát lớn và tăng nhanh (log gấp đôi mỗi năm, traffic telemetry lớn hơn traffic nghiệp vụ nhiều bậc): phải có pipeline, phân tầng lưu trữ, và đo xem pipeline có làm mất dữ liệu không.
• Hệ quan sát phải sống khi hệ được quan sát chết: nếu chạy chung hạ tầng, nó tắt đúng lúc cần nhất.
• Ai giám sát người giám sát, mà không thành hồi quy vô hạn?
• Có dữ liệu rồi thì biến nó thành chẩn đoán nhanh thế nào khi alert bắn?

Trang này nói về hạ tầng quan sát (metric, log, alert, giám sát từ bên ngoài, chẩn đoán tự động). Quy trình trực và vai trò khi có sự cố nằm ở Xử lý sự cố và on-call; bài học từ từng sự cố nằm ở Sự cố và postmortem.

Diễn tiến theo thời gian

• 2013 · Stack Overflow: ghi thời gian SQL, Redis, tag engine và ASP.NET cho mọi request; trang câu hỏi render trung bình 28 ms (11/2013). Theo tác giả, không có số liệu này thì không biết dựa vào đâu để quyết định. Stack Overflow 2013
• 2013→2017 · Stack Overflow: pipeline client timings: navigation timing của 5% lượt xem trang vào SQL columnstore và Bosun (hơn 5 tỷ điểm năm 2017); nhúng <iframe> tới domain thử teststackoverflow.com để đo DNS và CDN bằng traffic thật trước khi chuyển sang Cloudflare rồi Fastly. Stack Overflow 2017
• 2014 · Twitter: Cache ghi log mọi lệnh nhưng tổng hợp ngay tại máy (top key, gai traffic, số khoá) rồi mới gửi qua Storm, vì log thô tốn khoảng 10% băng thông; phần lớn "cache lỗi" là client dùng sai. Twitter 2014
• 2015→2017 · Salesforce: pipeline log mới (Logstash → Kafka mỗi data center → MirrorMaker → Kafka tổng → Camus → HDFS) cho lượng log tăng khoảng 100%/năm. Đo độ đầy đủ đầu-cuối: 12/2016 chỉ khoảng 25%, rồi 99,999% (7/2017) và 99,99999% (9/2017) sau khi đo toàn fleet thay vì lấy mẫu, at-least-once, id duy nhất trên từng bản ghi để khử trùng, sửa giới hạn batch không nhất quán. Salesforce 2017
• 2015→2017 · LinkedIn (Iris): hệ báo động giữ tối giản (chỉ lo incident được nhận, gửi tin qua Twilio/Slack) nên chỉ một sự cố lớn trong khoảng 1,5 năm; bão alert khi bỏ escalate tay được xử lý bằng batching, hạ ưu tiên và gom alert. LinkedIn 2017
• 2015 · Zillow: một service sinh hơn 4 triệu lỗi/ngày thuộc khoảng 20.000 loại; xếp hạng loại lỗi theo mức tăng của một chỉ số trải nghiệm người dùng (Factor X, lấy mẫu mỗi giây) quanh thời điểm lỗi xuất hiện, thay vì theo số lượng; ngưỡng theo phân bố lỗi thất bại vì mỗi lần deploy làm phân bố đổi. Zillow 2015
• 2015 · Zillow: RUM tự làm trong Splunk + WebPageTest nội bộ + performance budget có cảnh báo khi lệch 5%; theo Zillow, onload không phản ánh hiệu năng cảm nhận, nên đặt mốc User Timing cho phần trên màn hình. Zillow 2015
• 2017 · Airbnb: alert là code trong repo, đồng bộ với Datadog qua API: so định nghĩa hiện có, chỉ sửa phần khác, chạy lại mỗi giờ để bám host/role mới. Airbnb 2017
• 2017 · Booking.com: lỗi 1,2 giây chỉ bắt được nhờ metric 10 giây và script ghi pidstat/sar/ss/strace mỗi giây đặt sẵn trên vài máy chờ lỗi tái diễn; theo Booking, lấy mẫu 1 phút trên hệ khoảng 50 nghìn request/giây là bay mù với lỗi ngắn hơn một phút. Booking.com 2017
• 2017 · Two Sigma: usage metric từng query cho một nền tảng dữ liệu nghiên cứu (tới 50.000 query/giây mỗi node): Kafka làm bộ đệm vì Elasticsearch không nhận nổi tốc độ đó, Logstash chuyển sang Elasticsearch/Kibana, Marathon giữ Logstash chạy (bài 2019). Two Sigma 2019
• 2018 · trivago: công cụ PHP nguyên khối kéo metric từ API của CDN được tách thành các exporter Go cho Prometheus; API hay timeout thì đẩy qua Pushgateway thay vì chờ scrape. trivago 2018
• 2018 · Zillow: index Elasticsearch lệch DB; tìm race condition bằng sự kiện có ngữ cảnh (ID, phản hồi và version của Elasticsearch, snapshot, stack trace) cộng job đối chiếu vài lần mỗi ngày gửi alert kèm snapshot. Zillow 2018
• 2018→2019 · Grab: từ log rải rác (storage cloud mất hàng giờ, SaaS timeout) sang ELK tự vận hành, 25 TB/ngày, hơn 400 node; bẫy ở quy mô này: field data cache chiếm 20 GB heap vì một user sort theo id, quá nhiều shard trên node làm hết segment memory, analyzer tách ID thành nhiều token; phí traffic giữa AZ khoảng 30% chi phí cụm, ghim index theo zone. Grab 2019
• 2018 · Netflix: lưu hết log thiết bị và server không scale (chi phí, query chậm), chuyển sang lọc trên luồng bằng Mantis, chỉ lưu phần khớp; đếm lỗi từ log vào Atlas, phát hiện bất thường so với baseline; kho chọn theo cách đọc (Cassandra theo khoá + thời gian, Elasticsearch cho nhiều trường, Hive cho dữ liệu cũ). Netflix 2018
• 2018 · Bumble: hệ thu lỗi client tự làm (Gelato, bài 12/2020, mất gần hai năm) thay HockeyApp sau khi Microsoft mua và đổi luật, và thay hệ lỗi JS trên MySQL: giữ mọi sự kiện không lấy mẫu sáu tháng, đếm cả số user bị ảnh hưởng, hàng đợi trung gian (LSD) vì lượng lỗi tăng vọt khi một SDK hỏng, Elasticsearch theo index mỗi app, giải mã stack trace Android (ReTrace) và iOS (Symbolic qua cgo), gom nhóm bằng fingerprint, so lỗi giữa hai phiên bản như một bước của phát hành. Bumble 2020
• 2018 · Stack Overflow: mọi HTTP request qua HAProxy được ghi vào SQL columnstore kèm header số lệnh và số ms cho SQL, Redis, HTTP, tag engine, Elastic; MiniProfiler trên mọi trang, giữ 100 profile chậm nhất mỗi route trong Redis, ID dùng làm Request ID. Health check là trang chủ. Opserver ra đời vì AlwaysOn báo xanh khi replica đã ngừng mấy ngày: trạng thái lưu lại phải có timestamp. Stack Overflow 2018
• 2018 · LinkedIn (Aeon): metric request/response không thấy luồng bất đồng bộ (gửi tin → push); Aeon ghép tracking event đầu-cuối trên Samza, đẩy latency từng đoạn lên inGraphs; tìm ra đoạn gây chậm của push notification rồi đặt alert theo SLA. LinkedIn 2018
• 2019 · LinkedIn: giám sát ingest vào Hadoop từ trạng thái pass/fail của job sang sự kiện theo từng bước (Gobblin) và chỉ số theo dataset: ingestion lag, data loss theo mapper, data availability (cách nhanh đếm từ Kafka audit, cách chậm mà chính xác bằng consumption test). Mở đầu bằng một lỗi bootstrap job vẫn báo thành công, 1,5 ngày sau mới lộ, gần hai tuần mới đuổi kịp. LinkedIn 2019
• 2019 · Dream11: alert theo chỉ số kinh doanh gần thời gian thực (contest đầy trên 90%, cổng thanh toán sập, traffic lạ) bằng ElastAlert trên Elasticsearch, với luật tần suất, spike, flatline (quá ít sự kiện), giá trị mới; chính pipeline được giám sát độ trễ đầu-cuối (dưới 2 phút trong IPL). Dream11 2019
• 2019 · Salesforce: sản phẩm ghép từ nhiều microservice: định nghĩa khả dụng từ trên xuống (khách kết nối được, chức năng chính chạy), đo luồng đồng bộ bằng percentile latency + tín hiệu concurrency tăng mà rate không tăng, luồng ETL bằng synthetic job chạy định kỳ; mỗi instance tự đo outbound/inbound (service mesh cho sẵn); số liệu theo job (cardinality cao) để trong log, không vào kho metric; trace theo request và theo bản ghi qua các pha ETL. Salesforce 2019
• 2019 · Prometheus: remote read (Thanos đọc từ Prometheus) từng gom cả kết quả chưa nén vào bộ nhớ: 8 giờ × 10.000 series tốn tới 2,5 GB mỗi bên. Bản 2.13 stream frame khoảng 1 MB chứa chính chunk nén của TSDB: bộ nhớ khoảng 50 MB/request không đổi, latency giảm khoảng 2,5 lần. Prometheus 2019
• 2019 · Stripe: canonical log line: một dòng log có cấu trúc gom thông tin chính của mỗi request mỗi service; query lúc sự cố đơn giản và rẻ vì không phải ghép nhiều dòng; schema chốt bằng protobuf để đưa vào warehouse. Stripe 2019
• 2019 · SoundCloud: probe black-box (Catchpoint) chỉ để báo cáo khả dụng chứ không page: không phải traffic thật, quá chậm để thấy tỉ lệ lỗi thấp và latency đuôi. Page dựa trên white-box và burn rate của error budget. SoundCloud 2019
• 2019 · eBay: CAL Ingress gom khoảng 2,5 PB log/ngày (đỉnh 58 GB/s) qua khoảng 1 triệu kết nối TCP; đọc chậm thì client bỏ dữ liệu (TCP disconnect). Tách thread đọc khỏi xử lý trong Netty, off-heap và giảm object để bớt GC, gom gói nhỏ tới 160 KB rồi nén, ghi lười qua ring buffer có giới hạn: TCP disconnect từ hàng nghìn còn vài chục. eBay 2019
• 2019 · LinkedIn (ThirdEye): alert cho metric kinh doanh nhiều chiều: tách detection flow (dimension exploration chỉ theo dõi tổ hợp đủ lớn, rule ngưỡng/Holt-Winters/ML, lọc, merger, grouper) khỏi notification flow (suppression lúc deploy/lễ, gửi theo chiều, qua Iris); preview trên dữ liệu cũ trước khi bật. LinkedIn 2019
• 2019 · LinkedIn: FollowFeed đo feature coverage (có lúc ingest mà thiếu lúc chấm điểm) và đưa vào ThirdEye; dữ liệu lấy từ dark canary để phép đo không đè lên đường phục vụ. LinkedIn 2019
• 2020 · Miro: HA cho Prometheus bằng hai bản giống hệt cùng scrape, Alertmanager cluster khử trùng alert, PushGateway active/passive sau DNS; chia nhiều nhóm Prometheus nhỏ theo phần hạ tầng. Lưu dài hạn tách sang VictoriaMetrics (insert/select stateless, storage trên đĩa cloud rẻ, khử trùng metric từ hai bản). Miro 2020
• 2020 · Fly.io: 7 server Graylog tập trung rơi log ở 20.000–30.000 log/giây; Vector trên mọi server parse và gửi thẳng Elasticsearch, bỏ tầng giữa; schema chung (ECS) để tìm xuyên app; cấu hình phân tán nhưng test được. Fly.io 2020
• 2020→2023 · Goldman Sachs: SecDb (hơn 10.000 DB trong RAM, 30 năm tuổi) từ TSDB + email batch sang Prometheus/Alertmanager: đầu tiên probe bên ngoài không sửa DB, sau đó metric server native trong DB (một endpoint mỗi DB), tầng Prometheus khu vực vì DB di chuyển liên tục mà Prometheus chung cần cấu hình tĩnh. Goldman Sachs 2023
• 2020 · Gojek: hơn một nghìn pipeline Airflow; statsd → Telegraf → InfluxDB, template để tách DAG/task thành tag; đo schedule delay, thời gian parse DAG, heartbeat của tiến trình tự viết; alert deadman khi scheduler im lặng 5 phút. Gojek 2020
• 2020 · Zerodha: hạ tầng lai (rack ở hai DC + AWS, nhiều cụm Kubernetes): Prometheus mỗi cụm remote write về VictoriaMetrics (chọn thay Thanos vì là một binary), khoảng 56 tỉ data point; externalLabels gắn tên cụm ở nơi phát; Alertmanager tập trung, rule đi qua CI rồi tự reload; exporter lấy metric nghiệp vụ thẳng từ SQL. Zerodha 2020
• 2020 · Dropbox: Nginx miễn phí có 7 chỉ số, phần còn lại chắp vá bằng Lua (làm Nginx chậm 3 lần ở bài RPS cao) và parse error.log; Envoy có hàng nghìn metric, đổi mức log khi đang chạy, access log qua gRPC. Bỏ stats chắp vá là một lý do giải phóng tới 60% server. Dropbox 2020
• 2020 · Zillow: giám sát chất lượng event analytics như một hợp đồng: test thụ động liên tục đọc lại 10 phút gần nhất của topic, kiểm trường bắt buộc và thứ tự event. Zillow 2020
• 2020 · WhatsApp: DIT thu metric độ tin cậy (tin có tới không, crash, phiên bản) mà không gắn danh tính: token ẩn danh lấy trước, log gửi qua kết nối không xác thực, định danh giả xoay định kỳ để vẫn gộp được; đo nguy cơ định danh lại và ngừng thu khi vượt ngưỡng. Rollout toàn cầu 2021. WhatsApp 2021
• 2020 · Jane Street: Memtrace: profile bộ nhớ lấy mẫu (OCaml 4.11) đủ rẻ để chạy trong production, thay Spacetime ghi mọi lần cấp phát; viewer lọc theo "còn sống trong khoảng" và "cấp phát trong khoảng" để tách leak khỏi object sống lâu hợp lệ. Jane Street 2020
• 2021 · Meta: với phần cứng, lỗi "đã tự sửa" vẫn là tín hiệu: dịch vụ parse dmesg/SEL ghi tốc độ lỗi corrected theo cửa sổ 10 phút tới 1 ngày; ngưỡng xác định bằng tương quan với stall hệ thống trong Scuba; dữ liệu sửa chữa gom lại chỉ ra một bản firmware lỗi của một nhà cung cấp. Meta 2021
• 2021 · Netflix: Prodicle Distribution từng gỡ lỗi bằng log rải nhiều hệ và SQL vào DB production; chuyển workflow bất đồng bộ lên nền tảng Cosmos có cổng quan sát Nirvana (log, trace, trạng thái workflow ở một chỗ), ticket hỗ trợ giảm. Netflix 2021
• 2021→2026 · Airbnb: rời nhà cung cấp tính tiền theo lượng nạp sang hệ tự vận hành trên Prometheus: 1.000 service, 300 triệu timeseries, 3.100 dashboard, hơn 300.000 alert. Bản v1 bắt đầu bằng service khó nhất và bắt chước hệ cũ thì sa lầy; bản v2 bắt đầu bằng service dễ, dịch ý định của query (gom về query histogram chuẩn) nhờ metadata engine ghi loại metric, thay luôn khung alert (backtesting, diff). Bài học của họ: sở hữu lớp tương tác (UI, công cụ viết alert) để đổi backend dễ. Airbnb 2026
• 2021 · Loveholidays: log Fastly hơn 30 GB/ngày: BigQuery giữ cho phân tích dài hạn, còn thời gian thực đi Fluent Bit → Loki trên GCS (dưới 1 USD/ngày, theo họ); không đẩy vào ELK dùng chung vì đỉnh CDN (DDoS) có thể làm sập log của mọi ứng dụng khác. Loveholidays 2021
• 2021 · DoorDash: giám sát model drift bằng hạ tầng observability sẵn có: template SQL trên prediction log phát metric Prometheus mỗi giờ, Grafana, alert khai báo trong Terraform tới Slack/PagerDuty; bản hai phủ mọi model và feature không cần đăng ký. DoorDash 2021
• 2021 · Slack: dashboard và alerting sập đúng lúc sự cố vì chạy khác VPC với DB của nó, phụ thuộc vào chính Transit Gateway đang hỏng; không dựng lại được vì hệ cấp phát cũng quá tải. Sửa: đặt dashboard cùng VPC với DB. Slack 2021
• 2021 · LinkedIn (Capacity Analyzer): dò service sẽ vỡ ở mục tiêu load test tiếp theo: tín hiệu ngoài latency (threadpool, CPU, GC), ưu tiên nút lá trong call graph, độ dốc latency theo QPS, LSTM autoencoder, MetaRank XGBoost học từ nhãn nguyên nhân gốc. LinkedIn 2021
• 2021 · Zillow: Luminaire: nền tảng phát hiện bất thường chuỗi thời gian dùng chung, tự chọn cấu hình mô hình, model có hạn dùng, và tự giám sát (tỉ lệ bất thường, độ tươi model) để tránh báo quá nhiều hoặc quá ít. Zillow 2021
• 2021 · Jane Street: sampling profiler (khoảng 250 µs/mẫu) vô dụng với hệ giao dịch phản hồi nhanh hơn thế; magic-trace dùng Intel Processor Trace chụp 10 ms trước một hàm được chọn, attach bằng hardware breakpoint, xem từng lần gọi hàm ở thang nanosecond; tìm ra regression 100 ns do mất inline. Jane Street 2022
• 2021 · HRT: Prometheus một instance chạm trần; federation mất khả năng tổng hợp ad-hoc toàn cục nên chọn shard (chỉ ingest) + query node (remote read, không scrape), recording rule chạy từng shard rồi gộp, mỗi server có bản đôi qua Consul; đóng góp remote read đồng thời lên upstream. Khoảng 150 triệu series (2021), WAL replay từ hơn 1 giờ xuống theo số shard. Hudson River Trading 2021
• 2022 · Railway: log của hơn 500.000 deployment trước đọc thẳng từ Docker bằng polling mỗi 2 giây, đè lên daemon giữ deployment chạy. Chuyển sang Vector trên mỗi node → Vector trung tâm, hai tầng lưu (filesystem vài giờ cho stream, GCS cho lâu dài), đọc bằng stream. Railway 2022
• 2022 · Achievers: khi engineer bắt đầu tự sở hữu service, SRE sinh sẵn dashboard và alert mặc định theo golden signals cho mọi service từ metric Istio; chỉ gửi metric được chọn lên New Relic, phần còn lại giữ ở Prometheus trong cluster để tiết kiệm. Metric tầng mesh bắt được lỗi 503 do tắt không êm mà APM bỏ sót. Achievers 2022
• 2022 · Mercari: giám sát pipeline log bảo mật của chính họ: alert khi không có event trong 1 giờ, tỉ lệ lần chạy lỗi trên 1%, tuổi message Pub/Sub chưa ack, job BigQuery lỗi; đóng gói thành module Terraform trong template service (130 policy). Bẫy: lọc log dưới warning để tiết kiệm đã tắt luôn trigger của Error Reporting. Mercari 2022
• 2022 · Twitter: đổi edge mặc định sang edge cloud công cộng ở vài nước, không chia ngẫu nhiên người dùng được; dựng phản thực từ chuỗi thời gian các nước khác (CausalImpact), nhưng trước hết xác nhận latency p95 thật sự giảm và metric khác ổn định. Twitter 2022
• 2022 · Meta: giám sát một tính chất (độ nhất quán cache) bằng một service riêng đóng vai client, đo vi phạm bất biến mà client quan sát được; yêu cầu đầu tiên là không báo nhầm, vì báo nhầm làm người ta phớt lờ chỉ số. Meta 2022
• 2022→2023 · Go: thư viện chuẩn thêm log/slog (Go 1.21) vì hệ sinh thái phân mảnh (logrus được hơn 100.000 package dùng) và chương trình lớn phải cấu hình nhiều logger. Tách frontend Logger khỏi backend Handler để thư viện cũ dùng chung backend; tối ưu theo khảo sát code thật (hơn 95% lời gọi có ≤ 5 thuộc tính), chủ yếu bằng giảm cấp phát. Go 2023
• 2023 · Twitter: máy bare metal của Blobstore vào ra cụm không ai thấy, dung lượng không có alert; đặt bốn trạng thái vòng đời, quy ước mọi công cụ phải phát metric (cron dưới hai phút đẩy qua Scribe vì thư viện metric không thu được). Twitter 2023
• 2024 · LinkedIn (qua ClickHouse): tracing trên ClickHouse (0,8 nghìn tỉ span/ngày ở 1% mẫu), rồi 2025–2026 gom metadata của 13 tỉ metric từ ba hệ (index trong RAM, KV trong RAM, Elasticsearch) về một shard ClickHouse sau cùng gateway: 150.000 query/phút, bộ nhớ còn khoảng 1/5. ClickHouse 2026
• 2024 · ClickHouse (nhà cung cấp): thuộc tính động của OTel để ở Map(String,String) thì mất kiểu và phải quét cả map để đọc một khoá; kiểu JSON viết lại tạo cột con cho mỗi cặp đường dẫn + kiểu. Bài học từ khách: ordering key theo cách lọc, materialized view (ghi vào bảng Null) để biến đổi, tạo ordering key khác, tính trước cho alert. ClickHouse 2024
• 2025 · Meta: DrP, nền tảng viết playbook điều tra thành code (analyzer), tự chạy khi alert bắn, có backtest trong code review; theo Meta hơn 300 team, khoảng 2.000 analyzer, 50.000 lần phân tích/ngày, MTTR giảm 20–80%. Meta 2025
• 2025 · Anthropic: với lỗi biểu hiện bằng chất lượng đầu ra giảm (không phải 5xx), metric hạ tầng không đủ; thêm eval chất lượng chạy liên tục trên hệ production thật và coi phản hồi người dùng (/bug, thumbs down) là tín hiệu giám sát chính thức. Anthropic 2025
• 2025 · ClickHouse: LogHouse (log nội bộ) từ 19 PiB lên hơn 100 PB chưa nén. OpenTelemetry collector tốn hơn 800 core cho 2 triệu log/giây và rơi log ở edge khi spike; thay nguồn lớn nhất bằng SysEx, scraper pull system tables theo cửa sổ trễ 5 phút, chép byte nguyên bản: 70 core cho 37 triệu log/giây (theo ClickHouse). OTel vẫn giữ cho lúc service crash-loop, chỉ thu info trở lên. Chuyển sang wide event, tổng hợp lúc truy vấn. ClickHouse 2025
• 2025 · Grafana Labs (qua WarpStream): ingester của Mimir (TSDB tương thích Prometheus, đã tới 1 tỷ active series) vừa ghi vừa phục vụ query, giữ WAL cục bộ, nên query nặng làm nhiễu ghi. Thiết kế lại đặt Kafka giữa đường ghi và đường đọc; Grafana Cloud dùng WarpStream để chạy đa AZ không tốn phí mạng giữa AZ. WarpStream 2025
• 2025 · ClickHouse: giám sát lưu lượng mạng từng kết nối: agent mỗi node chỉ đọc conntrack (5–20 MB RAM), server không trạng thái giữ informer Kubernetes và gắn nhãn (bản đầu hỏi API server mỗi lần thì nặng control plane, informer trên mọi node thì nặng RAM). Không dùng metric Prometheus vì cardinality cao; một region gần 400 tỉ dòng, nén còn 3%. Né thêm agent eBPF thứ hai bên cạnh Cilium vì rủi ro tương tác. ClickHouse 2025
• 2025 · Mercari: quy trình bắt gói tin tự phục vụ: Ephemeral Container gắn vào pod (quyền tạm qua Carrier), tcpdump -i any để thấy lưu lượng đã giải mã sau Istio mTLS; bắt ở node là dự phòng và chỉ thấy bản mã hoá. Mercari 2025
• 2025 · Rust (crates.io): cookie phiên lọt vào payload gửi lên Sentry; hệ giám sát lỗi là nơi rò secret nếu không che theo danh sách cho phép. Rust 2025
• 2025 · HRT: hàng nghìn alert MetricsQL trên VictoriaMetrics, nhiều trùng lặp và bẫy (series vắng mặt làm alert không bao giờ bắn). HeraclesQL: DSL Python có kiểu sinh MetricsQL từ AST, hàm alert có tham số, meta-alert tự sinh kiểm absent() và kiểm số series; mở mã nguồn. Hudson River Trading 2025
• 2026 · Airbnb: gỡ phụ thuộc vòng của metrics platform: cluster Kubernetes riêng (vẫn do team Cloud vận hành), tầng ingress Envoy riêng thay vì đi qua service mesh Istio, meta-monitoring bằng Prometheus khác AZ, và dead man's switch qua SNS + CloudWatch cho tầng cuối. Airbnb 2026
• 2026 · Upstash: giám sát từ bên ngoài, mỗi replica một check mỗi phút từ 18 điểm, định nghĩa bằng Terraform; benchmark latency ở cụm riêng làm đường page thứ hai; QStash kiểm bằng message thật tới heartbeat. Upstash 2026
• 2026 · eBay: Minerva giám sát hệ tính phí theo chỉ số kinh doanh: service tính phí chỉ đặt định danh vào hàng đợi cục bộ có giới hạn (quá hạn thì bỏ kiểu ring buffer), enrich bất đồng bộ từ read database, lưu ClickHouse, rồi module chạy query theo lịch, xử lý use case (độ lệch phí theo site/giờ, kết hợp khuyến mãi) và định tuyến alert tới PagerDuty, email hay Slack theo mức độ. eBay 2026
• 2026 · Prometheus: ghi chunk lúc compaction bằng direct I/O (feature flag use-uncached-io) để dữ liệu ít đọc lại không chiếm page cache; page cache giảm 20–50%, bộ nhớ của container dễ hiểu hơn (tránh nhầm giữa các metric bộ nhớ dẫn tới OOMKill). Khó ở yêu cầu căn lề; ràng buộc: không thoái lui CPU hay disk I/O. Prometheus 2026
• 2026 · Prometheus: TSDB từ đầu chỉ lưu mẫu float, histogram là một nhóm series _bucket/_count/_sum: tốn index, mất tính nguyên tử qua remote write (một bucket trễ gây cảnh báo sai), bên đọc phải đoán kiểu. Hướng đi: mẫu phức hợp cho mọi kiểu (NHCB từ 2024 hiệu quả hơn ít nhất 30%), OpenMetrics 2.0 và Remote Write 2.0 chở dạng native, kèm chế độ tương thích để query cũ vẫn chạy. Theo một maintainer, chưa chính thức. Prometheus 2026
• 2026 · ScyllaDB: gauge scrape vài phút một lần chỉ là ảnh chụp ngẫu nhiên của giá trị đổi hàng nghìn lần mỗi giây. Latency: xuất tổng latency + số request làm counter rồi rate(). Độ dài hàng đợi: integrated gauge cộng dồn giá trị × thời gian, rate() ra trung bình theo thời gian; trên dashboard nó lộ ra gai và xu hướng mà gauge che mất. Histogram đầy đủ nhất nhưng tốn gấp N lần. Cùng mảng, cuộc điều tra I/O dựa vào tracer nhị phân và số đo hàng đợi trong đĩa có từ một hackathon. ScyllaDB 2026 ScyllaDB 2026
• 2026 · Uber: giám sát mạng nội bộ công ty chuyển từ hệ thương mại sang Telegraf + Prometheus/Thanos; cấu hình poller sinh từ inventory (ServiceNow → Elasticsearch) và tự nạp lại; tầng nhập alert gom trùng, sửa tin tại chỗ khi trạng thái đổi; bỏ hàng trăm nghìn USD license mỗi năm. Uber 2026
• 2026 · ClickHouse: (nhà cung cấp) schema log/trace thừa hưởng từ exporter OpenTelemetry chưa từng được benchmark; dựng benchmark cố định (640 MiB/s, chỉ đổi schema, query, phiên bản) rồi đổi primary key sang bucket 5 phút, text index thay bloom filter, cột key=value để đánh index cho Map, materialized view cho autocomplete. Latency query đại diện giảm hơn 5 lần. ClickHouse 2026
• 2026 · Salesforce, 9/2026: giám sát agent ở production (Agentforce Health Monitoring): metric khả dụng đầu–cuối cho ca "hỏng âm thầm" (request không tới agent, gateway LLM sập mà metric vẫn xanh); telemetry của một phiên rải ở khoảng năm, sáu chỗ phải ghép thành một hành trình trước khi tính metric; độ trễ alert từ khoảng 20 phút xuống vài phút nhờ ingest streaming và query đơn giản hơn; mục tiêu dưới 120 giây từ alert tới trang phiên liên quan. Salesforce 2026
• 2026 · Airbnb: tự vận hành metrics ở 1,3 tỷ series active, 50 triệu sample/giây, 2,5 PB; shadow cluster nhận traffic thật lộ thiếu guardrail query và compaction trễ; giới hạn mỗi tenant suy ra từ một giới hạn series, onboard tự động khi có service mới; Promxy cho query và alert xuyên cụm. Airbnb 2026
• 2026 · Optiver: GitHub Actions không lộ queue time hay utilisation khi tự quản runner bare metal (FPGA, kernel) không autoscale được; dựng lại trạng thái job từ webhook, alert theo p90 queue time, utilisation theo lớp phần cứng, gắn metadata compiler/OS vào build để đo tác động nâng cấp. Optiver 2026
• 2026 · HRT: log dịch vụ chỉ phủ lưu lượng qua dịch vụ; quy băng thông WAN cho từng user/workflow bằng eBPF (tcp_recvmsg, hàm NFS cấp thấp, đếm theo phút trong BPF map), ghép log dịch vụ và đối chiếu với bộ đếm switch, mỗi luồng chỉ đếm một lần. Hudson River Trading 2026
• 2026 · WhatsApp: confidential federated analytics: client gộp số đếm, gửi lúc ngẫu nhiên qua OHTTP; orchestrator và aggregator chạy trong TEE, cắt nhóm nhỏ (k-anonymity), thêm nhiễu differential privacy, lưu checkpoint mã hoá để crash không phải đo lại; client từ chối gửi nếu tham số riêng tư yếu. WhatsApp 2026

Các lựa chọn và đánh đổi

Quy tắc rút ra

1. Hệ quan sát phải tin cậy hơn hệ nó quan sát; vẽ đồ thị phụ thuộc của chính nó và gỡ mọi phần chung với hệ được quan sát ở những tầng quan trọng (compute, mạng). Airbnb 2026
2. Tầng giám sát cuối cùng nên dựa vào tín hiệu phải luôn có (dead man's switch, heartbeat): im lặng là cảnh báo, nên không cần thêm một tầng giám sát nữa. Airbnb 2026 Upstash 2026
3. Với pipeline log/metric, độ đầy đủ đầu-cuối là tiêu chí nghiệm thu, đo trên toàn bộ chứ không lấy mẫu, đếm ở từng chặng để khoanh vùng. Salesforce 2017
4. Tách dữ liệu nóng ngắn hạn khỏi dữ liệu lạnh dài hạn: phần lớn điều tra chỉ cần vài ngày gần nhất. Miro 2020 Railway 2022
5. Đường đọc của observability (xem log) không được đè lên thành phần giữ hệ chạy. Railway 2022
6. HA cho metric có thể rất đơn giản (hai bản giống hệt, khử trùng ở sau); đồng thuận là thừa với dữ liệu chịu được trùng. Miro 2020
7. Giám sát từ góc nhìn khách hàng và từng bản sao, vì failover tự động che mất việc mất bản sao. Upstash 2026
8. Lưu lại câu hỏi chẩn đoán đúng dưới dạng code chạy tự động khi alert bắn; đó là cách biến dữ liệu quan sát thành MTTR thấp hơn. Meta 2025
9. Đo chi phí của chính pipeline quan sát như mọi hệ khác: collector đa dụng có thể tốn hàng trăm core và vẫn rơi dữ liệu khi spike; nguồn lớn nhất, có cấu trúc thì đáng một đường riêng, còn chuẩn chung (OTel) giữ cho phần còn lại và cho lúc service hỏng. ClickHouse 2025
10. Telemetry trên đường nóng đi qua hàng đợi cục bộ có giới hạn và chính sách bỏ rõ ràng: giám sát được phép mất dữ liệu, giao dịch thì không. eBay 2026
11. Với pipeline batch, "job thành công" không có nghĩa dữ liệu đúng và kịp; giám sát lag, độ đầy đủ, độ sẵn sàng theo dataset. LinkedIn 2019 Salesforce 2017
12. Lỗi thể hiện bằng chất lượng đầu ra giảm hay bằng lỗi "đã tự sửa" (corrected) không hiện trên metric lỗi thông thường; cần kiểm tra chất lượng chạy liên tục trên production, hoặc theo dõi tốc độ lỗi với ngưỡng xác định từ tác động thật. Anthropic 2025 Meta 2021
13. Khi team bắt đầu tự sở hữu service, dashboard và alert mặc định do nền tảng sinh là cách nhanh nhất để mọi service có observability; chỉ gửi lên hệ trung tâm (tính tiền theo lượng) phần metric được chọn. Achievers 2022
14. Alert trên chỉ số kinh doanh theo từng phân đoạn (site, loại phí, khuyến mãi) bắt được lỗi mà tổng toàn cục che mất. eBay 2026
15. Định nghĩa khả dụng ở mức sản phẩm trước rồi mới suy ra metric từng service; luồng bất đồng bộ hay traffic thưa cần synthetic transaction để luôn có tín hiệu. Salesforce 2019
16. Dữ liệu cardinality cao (theo job, theo request) để trong log hoặc trace, không đưa vào kho metric. Salesforce 2019
17. Hạ tầng metric lớn gặp đúng bài toán của hệ dữ liệu sản phẩm: tách đường ghi khỏi đường đọc để query nặng không làm mất dữ liệu đang ghi (Grafana Mimir 2025); dữ liệu ghi một lần ít đọc lại không nên chiếm page cache (Prometheus 2026). WarpStream 2025 Prometheus 2026
18. Gauge của giá trị dao động nhanh là ảnh chụp ngẫu nhiên: giá trị cộng được thì xuất counter tổng + số lần rồi rate(); giá trị không cộng được (độ dài hàng đợi) thì tích phân theo thời gian (integrated gauge); histogram khi cần đuôi. ScyllaDB 2026
19. Pipeline log là hệ dữ liệu cỡ PB, mặc định của công cụ dành cho quy mô nhỏ hơn: đọc kịp phía nhận (không thì client bỏ dữ liệu), đệm có giới hạn và chính sách bỏ rõ ràng (eBay 2019); chặn query ad-hoc nuốt heap, tính shard theo bộ nhớ, kiểm phí giữa AZ (Grab 2019); cân nhắc dời xử lý về nguồn để bỏ tầng tập trung (Fly.io 2020). eBay 2019 Grab 2019 Fly.io 2020
20. Cấu hình giám sát sinh từ inventory/đơn vị di chuyển, không viết tay: một endpoint mỗi DB với tầng Prometheus trung gian cấu hình động (Goldman Sachs 2023), poller tự nạp cấu hình từ inventory (Uber 2026). Với hệ di sản quan trọng, bắt đầu bằng probe bên ngoài rồi mới đưa telemetry vào trong. Goldman Sachs 2023 Uber 2026
21. Benchmark cố định trước khi đổi schema của kho quan sát: chỉ để schema, query, phiên bản thay đổi; đo ingest (cả số part chờ merge) trước rồi mới đo query; chạy cả workload để bắt hồi quy ở query không nhắm tới (ClickStack 2026: text index làm chậm tra một dòng log). ClickHouse 2026
22. Sở hữu lớp tương tác (UI, công cụ viết alert, workflow) dù backend là của nhà cung cấp: khi đổi backend, phần đắt nhất là chuyển mọi team sang công cụ mới (theo Airbnb 2026). Airbnb 2026
23. Migrate dashboard/alert theo ý định của query, kèm metadata đáng tin về loại metric, thay vì dịch từng chữ các query sai cũ. Airbnb 2026
24. Lọc log trên luồng rồi chỉ lưu phần khớp khi chi phí lưu tăng theo lưu lượng còn câu hỏi chỉ chạm một phần nhỏ (Netflix 2018 Mantis). Netflix 2018
25. Nguồn log khổng lồ và có đột biến (CDN) không đi chung cụm log với ứng dụng: đỉnh của nó (DDoS) có thể làm mất log của mọi người đúng lúc cần; tách đường hoặc dùng kho rẻ không index nội dung. Loveholidays 2021
26. Với nền tảng điều phối và tác vụ nền, alert theo sự vắng mặt (deadman, heartbeat) bắt được thứ alert ngưỡng không bắt, vì lỗi hay gặp là "không chạy" chứ không phải "chạy lỗi". Gojek 2020 Twitter 2023
27. Thuộc tính động của log/trace cần kiểu lưu đọc được từng khoá mà không quét cả khối (cột con theo đường dẫn), và ordering key theo cách lọc thực tế (theo ClickHouse 2024). ClickHouse 2024
28. Độ phân giải của metric phải ngắn hơn lỗi muốn thấy; với lỗi ngắn, đặt sẵn công cụ ghi mỗi giây trên vài máy rồi chờ lỗi tái diễn. Booking.com 2017
29. Gom metric nhiều cụm về một kho thì gắn nhãn nguồn ở nơi phát, không thì series của hai cụm trộn vào nhau mà không báo lỗi; alert as code đi qua CI như mọi cấu hình khác. Zerodha 2020
30. Dữ liệu lỗi từ client đến theo cơn: đặt hàng đợi giữa API nhận và phần xử lý, giữ đủ sự kiện không lấy mẫu để truy một user, và gắn lỗi với phiên bản phát hành để làm cổng phát hành. Bumble 2020
31. Hệ có thể sai mà không lỗi (model ML) cần giám sát phân phối input/output phủ mặc định, chạy trên chính hạ tầng metric/alert mọi người đã biết. DoorDash 2021 Xem Nền tảng ML (feature, training, serving, giám sát model).
32. Độ trễ alert là tổng của ingest và chu kỳ đánh giá, và alert chỉ có ích khi dẫn tới ngữ cảnh: đo cả thời gian từ alert tới trang chẩn đoán. Salesforce 2026

Câu hỏi mở

• Chi phí của observability ở quy mô lớn: ClickHouse 2025 trả lời một phần (thay hoá đơn Datadog bằng hệ tự dựng, cắt CPU của collector, chỉ thu log info trở lên, Achievers 2022 chỉ gửi metric được chọn lên SaaS) (ClickHouse 2025, Achievers 2022). Vẫn chưa có tỉ lệ chi phí observability so với hạ tầng sản phẩm, và hai nguồn đi hai hướng ngược nhau về cardinality: ClickHouse lưu mọi sự kiện với đủ chiều, Achievers giảm lượng gửi đi; ClickHouse là nhà cung cấp kho dữ liệu nên lời khuyên "lưu hết" cần đọc với ngữ cảnh đó.
• Tracing phân tán: đã tách thành Tracing phân tán và log theo request ở đợt 22 (LinkedIn 2015 và 2026, Pinterest 2017, Stripe 2019, Discord 2026); câu hỏi còn lại (tail sampling, chi phí tracing so với hạ tầng) ghi ở đó.
• Các nguồn đều là tự kể; chưa có số liệu MTTR trước-sau khi tách hệ quan sát (Airbnb) hay số liệu độc lập cho mức giảm MTTR của DrP (Meta).
• Liên hệ: Xử lý sự cố và on-call (alert định tuyến tới ai, quy trình sau khi alert bắn), Mô hình tổ chức SRE (ai dựng mặc định observability cho team), Load shedding, rate limit và backpressure (telemetry không được đè lên đường nóng), Độ tin cậy và multi-region (phụ thuộc vòng và miền lỗi chung), Tự động hoá vận hành và auto-remediation (chẩn đoán và khắc phục tự động), Pipeline dữ liệu và analytics (giám sát độ tươi và đầy đủ của dữ liệu), Tách compute khỏi storage (Mimir tách đường đọc/ghi qua Kafka).