Phần lớn hệ thống giám sát (monitoring) tôi từng gặp đều do đội vận hành (ops) dựng lên, và dựng cho chính đội vận hành dùng. Còn lập trình viên, những người trực tiếp viết ra lỗi rồi phải tự đi sửa, thì bị nghĩ tới sau cùng. Như vậy là ngược. Giám sát là một sản phẩm, và người dùng của nó là lập trình viên. Nếu họ không dùng, thì độ phủ trông đầy đủ đến mấy cũng chẳng để làm gì.
Làm sai thì cái giá phải trả hiện ra ngay trước mắt. Lập trình viên mất hàng giờ cố tái hiện những lỗi mà họ không nhìn thấy. Môi trường production gặp sự cố, mà người báo tin đầu tiên lại là người dùng đang bực mình chứ không phải hệ thống cảnh báo. Cả một bức tường cảnh báo không kèm ngữ cảnh, nên rốt cuộc chẳng ai thèm để ý cái nào. Sự cố xảy ra, thiệt hại đã có rồi, mà quãng thời gian đầu tiên chỉ để đi tìm hiểu xem chuyện gì vừa xảy ra. Hậu quả không chỉ là giao sản phẩm chậm hơn, mà còn bào mòn tinh thần cả đội, vì chẳng ai thích gỡ lỗi mò trong bóng tối.
“Tốt” thực ra nghĩa là gì#
Ba trụ cột của khả năng quan sát (observability) là chỉ số (metrics), nhật ký (logs) và dấu vết (traces), và đó là thứ tối thiểu phải có. Chỉ số báo cho bạn biết có gì đó đang sai (CPU, bộ nhớ, tốc độ yêu cầu, các phân vị độ trễ), nhật ký cho biết chuyện gì đã xảy ra, còn dấu vết cho biết nó bắt đầu từ đâu. Điều phân biệt một hệ thống tốt với một đống công cụ đặt cạnh nhau là ba thứ này được nối với nhau, để bạn đi từ cảnh báo sang nhật ký rồi sang dấu vết mà không phải đổi cách nghĩ hay ngồi sao chép dấu thời gian từ chỗ này sang chỗ khác.
Bảng điều khiển (dashboard) nên làm cho người đọc, chứ không phải cho người tạo ra nó. Nghĩa là chỉ số kinh doanh nằm ngay cạnh chỉ số kỹ thuật, tình trạng hệ thống liếc qua là thấy, xem được từ tổng quan đi xuống chi tiết, và những ngữ cảnh như lần triển khai gần nhất hay thay đổi cấu hình nằm sẵn trên trang. Lập trình viên không cần phải là chuyên gia giám sát mới trả lời được câu “dịch vụ của mình có ổn không?”
Cảnh báo là chỗ mà hầu hết các hệ thống gãy. Ngưỡng cảnh báo nên dựa trên mức nền (baseline) và cơ chế phát hiện bất thường, chứ không phải con số ai đó đoán bừa từ hồi năm 2022. Sự cố nên được chuyển thẳng tới đội sở hữu nó. Các cảnh báo liên quan nên được gom lại, đừng bắn riêng lẻ năm mươi lần. Và cảnh báo nào cũng phải trả lời được câu “cái gì đang hỏng?”, ít nhất cũng gợi ý được “nên bắt đầu từ đâu?”. Cuối cùng, vòng phản hồi phải nhanh: từ lúc sự cố xảy ra đến lúc lập trình viên biết chỉ nên tính bằng giây. Muốn vậy thì cần chỉ số theo thời gian thực, nhật ký dạng luồng tìm kiếm được, truy vết xuyên qua ranh giới giữa các dịch vụ, và mốc triển khai (deploy marker) để đối chiếu các lần phát hành với thời điểm bắt đầu có chuyện.
Làm cho xong phần nền móng chẳng ai khen#
Trước khi chọn công cụ, hãy ngồi cạnh lập trình viên trong một buổi gỡ lỗi. Ghi lại những câu họ cứ hỏi đi hỏi lại, những chỗ quy trình hiện tại làm họ khổ, và những chỉ số nào thật sự phản ánh sản phẩm có đang thành công hay không. Sau đó hạ rào cản xuống: có sẵn thư viện và SDK để việc gắn mã đo đạc (instrumentation) trở nên dễ như ăn kẹo, mẫu dựng sẵn cho các trường hợp phổ biến, bảng điều khiển mà ai cũng tự làm được, và tài liệu giải thích tại sao chứ không chỉ làm thế nào.
Và hãy coi hệ thống giám sát là thứ phải thay đổi theo thời gian: toàn bộ cấu hình quản lý theo kiểu hạ tầng dưới dạng mã (infrastructure-as-code), định nghĩa cảnh báo và bảng điều khiển nằm trong hệ thống quản lý phiên bản, có kiểm thử tự động cho các quy tắc giám sát, và có sẵn kế hoạch cho đa vùng hay đa đám mây trước khi bị ép phải làm.
Bộ công nghệ cụ thể#
Tên tuổi thì thay đổi, nhưng hình dạng chung của một bộ công nghệ giám sát hiện đại khá ổn định:
- Chỉ số: một cơ sở dữ liệu chuỗi thời gian như Prometheus, InfluxDB hoặc TimescaleDB, cộng thêm một công cụ APM, cộng thêm các chỉ số tuỳ chỉnh lấy ra từ logic nghiệp vụ của bạn.
- Nhật ký: gom nhật ký về một chỗ (ELK Stack, Splunk hoặc Loki), có chuẩn ghi nhật ký có cấu trúc để truy vấn được, và chính sách lưu trữ cân bằng giữa chi phí với mức độ hữu ích.
- Dấu vết: OpenTelemetry để gắn mã đo đạc, một công cụ như Jaeger, Zipkin hay Honeycomb để trực quan hoá, và một chiến lược lấy mẫu khi lưu lượng bắt đầu lớn.
- Giám sát mô phỏng (synthetics): kiểm tra thời gian hoạt động (uptime) từ nhiều vùng, kịch bản mô phỏng hành trình người dùng, kiểm tra tình trạng (health check) cho API.
- Real User Monitoring (giám sát người dùng thật): hiệu năng phía giao diện, các chỉ số trải nghiệm người dùng, và theo dõi lỗi từ lưu lượng truy cập thật trên môi trường production. Lý do đơn giản thôi: bài kiểm tra canary mô phỏng của bạn đâu có chạy trên một chiếc điện thoại Android ba năm tuổi, bắt wifi khách sạn.
Đội nhỏ trên AWS: cứ CloudWatch trước đã#
Với một đội nhỏ chạy trên AWS, CloudWatch là đường ngắn nhất để có được thứ gì đó thật sự hữu ích. EC2, Lambda, RDS và ECS tự đẩy dữ liệu về đó mà không cần cấu hình gì, nên bạn nhìn được hạ tầng ngay mà chẳng phải viết dòng mã đo đạc nào. Dùng bao nhiêu trả bấy nhiêu, thường khoảng $10–50 một tháng ở quy mô nhỏ, không có phí nền tảng cố định, và chỉ số, nhật ký, dấu vết (qua X-Ray) cùng cảnh báo đều nằm một chỗ. Chỉ vài giờ là bạn đã có cảnh báo và bảng điều khiển ra hồn.
Để tận dụng tối đa:
- CloudWatch Logs Insights thay được khá nhiều thứ mà người ta hay dựng hẳn Elasticsearch lên để làm. Một câu truy vấn như
fields @timestamp, @message | filter @message like /ERROR/ | stats count() by bin(5m)trả lời câu “lỗi có đang tăng không?” chỉ bằng một dòng. - Composite alarm (cảnh báo kết hợp) giúp giảm nhiễu: chỉ cảnh báo khi tỉ lệ lỗi cao và thời gian phản hồi đang xấu đi, chứ không cảnh báo riêng từng điều kiện.
- Bảng điều khiển trộn chỉ số kinh doanh với chỉ số kỹ thuật thì rất đáng công làm. Treo một cái lên TV, hoặc thả liên kết vào Slack.
- Chỉ số tuỳ chỉnh gửi qua agent thu thập hoặc SDK mới là chỗ có giá trị thật: lượt đăng ký, thanh toán, mức độ dùng từng tính năng, đặt ngay cạnh các con số về hạ tầng.
- CloudWatch Synthetics chạy canary định kỳ qua các luồng quan trọng, để bạn biết trang thanh toán hỏng trước khi người dùng phát hiện ra.
- X-Ray cho bạn truy vết phân tán (distributed tracing) mà gần như không phải cài đặt gì, và phần tích hợp với CloudWatch nối chỉ số với dấu vết tới tận từng yêu cầu.
Sớm muộn gì bạn cũng sẽ vượt qua nó: khi đội lên quá khoảng 50 kỹ sư, khi chuyển sang đa đám mây, khi cần phát hiện bất thường bằng học máy (ML) đúng nghĩa, hoặc khi nhu cầu tuỳ biến bảng điều khiển và logic cảnh báo đụng trần những gì giao diện cho phép.
Ở quy mô doanh nghiệp lớn: DataDog#
Khi bạn đang chạy hàng trăm dịch vụ trên nhiều môi trường, DataDog gần như là lựa chọn mặc định, và phần lớn là xứng đáng. Nó theo dõi mọi thứ trên cùng một màn hình: AWS, Azure, GCP, hạ tầng tại chỗ (on-prem), container, phi máy chủ (serverless), cơ sở dữ liệu, dịch vụ bên thứ ba, phía giao diện. Watchdog dùng học máy để đánh dấu bất thường và chỉ ra nguyên nhân gốc có khả năng nhất. Điều này quan trọng, vì chẳng ai ngồi canh nổi hàng nghìn dịch vụ. Nửa giá trị còn lại nằm ở phần cộng tác: bảng điều khiển riêng cho từng đội, phân quyền theo vai trò, notebook điều tra dùng chung, và tích hợp với PagerDuty lẫn Opsgenie. Cảnh báo thì sâu đến đâu tuỳ bạn: logic boolean nhiều điều kiện, cảnh báo dự báo bắn ra trước khi chạm ngưỡng, phát hiện bất thường tự thích nghi theo mẫu hình lưu lượng, và khung giờ bảo trì. Còn APM thì đi tới tận phân tích hiệu năng (profiling) ở cấp mã nguồn, giám sát bảo mật gắn với dấu vết, phân bổ chi phí theo từng dịch vụ, và bản đồ dịch vụ tự sinh.
Triển khai nó trong một tổ chức lớn thì phải có kế hoạch hẳn hoi. Chia làm nhiều giai đoạn: các dịch vụ quan trọng trước, sắp xếp bằng một chiến lược gắn thẻ (tag) tử tế theo đội, môi trường và đơn vị kinh doanh. Đặt chuẩn từ sớm: cách đặt tên chỉ số và thẻ, mẫu bảng điều khiển cho từng loại dịch vụ, các mức độ nghiêm trọng của cảnh báo và quy trình chuyển cấp xử lý (escalation), định nghĩa SLO cho từng cấp dịch vụ. Nối nó vào mọi thứ: CI/CD để có mốc triển khai, hệ thống quản lý sự cố, Slack hoặc Teams, hệ thống phiếu yêu cầu ITSM. Đầu tư vào đào tạo: tài liệu nội bộ, mỗi đội một người đi đầu, các buổi workshop về APM và phân tích hiệu năng. Và phải quản lý hoá đơn có chủ đích, vì ở cấp doanh nghiệp lớn nó lên tới $20–100K+ một năm: lọc bỏ những chỉ số ồn ào mà ít giá trị, lấy mẫu dấu vết ở các dịch vụ lưu lượng lớn, rà lại xem tính năng nào đang thật sự được dùng, và gắn thẻ để phân bổ chi phí.
Khi mọi thứ chạy ổn, cái bạn nhận lại là: xử lý sự cố nhanh hơn nhờ các tính năng đối chiếu dữ liệu, bắt được vấn đề trước khi người dùng nhận ra, lập trình viên tự xoay xở được thay vì xếp hàng chờ đội vận hành, và đủ tầm nhìn về mức dùng tài nguyên để điều chỉnh hạ tầng cho vừa. Đôi khi riêng khoản tiết kiệm này đã đủ trả tiền bản quyền.
Vài lựa chọn khác đáng để hỏi giá: New Relic (năng lực tương đương, đôi khi rẻ hơn nếu truy vết lưu lượng lớn), Dynatrace (AIOps mạnh, hay gặp ở các công ty tài chính lớn), Splunk (phân tích nhật ký không ai sánh bằng, nếu đội bảo mật vốn đã dùng sẵn), và Grafana Cloud (bước đi tự nhiên nếu bạn đang dùng Prometheus/Loki).
Rất nhiều tổ chức chạy mô hình lai và thấy ổn: các dịch vụ gốc của AWS tự đẩy dữ liệu về CloudWatch, DataDog lo phần ứng dụng và mọi thứ nằm ngoài AWS, đồng thời kéo luôn chỉ số từ CloudWatch vào để vẫn chỉ cần nhìn một màn hình. Vừa cân được chi phí với năng lực, vừa chẳng có gì phải đau đầu.
Văn hoá là nửa còn lại#
Công cụ sẽ thất bại nếu không có thói quen đi kèm. Hãy coi mã đo đạc như mã chạy trên production: nó phải qua rà soát mã, chỉ số tuỳ chỉnh phải có kiểm thử, và các quyết định về giám sát phải được ghi lại trong các buổi thảo luận kiến trúc. Hãy coi mỗi sự cố là một lần góp ý cho hệ thống giám sát: làm buổi phân tích sau sự cố (postmortem) không đổ lỗi, luôn hỏi “giám sát thế nào thì đã bắt được vụ này sớm hơn?”, rồi thật sự đi cập nhật bảng điều khiển và cảnh báo. Và rà soát mỗi quý một lần: xoá bảng điều khiển và cảnh báo không ai dùng, chỉnh ngưỡng khi hệ thống thay đổi, kiểm tra xem cảnh báo có còn bắn không, và giữ cho tài liệu phản ánh đúng thực tế.
Những cái bẫy thì dễ đoán, và tôi đã chứng kiến đủ cả: chạy theo mọi công cụ mới hào nhoáng thay vì chọn vài cái tích hợp tốt với nhau; biểu đồ không có mức nền hay xu hướng, nên chẳng ai biết một con số là tốt hay xấu; một hệ thống xuất sắc về mặt kỹ thuật nhưng thất bại vì không ai được hướng dẫn cách dùng; thu thập chỉ số vì tò mò chứ không phải vì nó quan trọng với người dùng; và không có phương án dự phòng cho chính hệ thống giám sát, nên bạn bị mù đúng vào lúc cần nhìn nhất.
Nếu bạn đang chuẩn bị đại tu hệ thống giám sát, đây là thứ tự tôi sẽ đi: rà lại những lỗ hổng và điểm đau hiện tại, định nghĩa SLO và SLI xoay quanh trải nghiệm người dùng, gắn mã đo đạc cho các hành trình quan trọng của người dùng trước, thêm truy vết phân tán (thứ giúp gỡ lỗi nhiều nhất trong thế giới vi dịch vụ), gắn mỗi cảnh báo với một sổ tay xử lý (runbook), rồi đo xem mọi thứ có hiệu quả không: MTTR, tần suất triển khai, và lập trình viên có thật sự nói rằng công việc của họ dễ thở hơn hay không.
Tiêu chí cuối cùng mới là phép thử thật. Làm DevOps tốt không chỉ là giữ cho hệ thống chạy; nó còn giúp đội phát triển làm nhanh hơn và bình tĩnh hơn. Khi lập trình viên tự nguyện mở hệ thống giám sát ra xem, đó là một trong những dấu hiệu rõ nhất cho thấy bạn đã làm được điều đó.