SecDb Observability Journey

Goldman Sachs · 2023 · 4. Điều chỉnh · Độ khó: Trung bình — bài gốc

Bối cảnh

• SecDb: nền tảng giao dịch, định giá, quản trị rủi ro của Goldman Sachs, dùng liên tục hơn 30 năm bởi hơn 3.000 developer: hơn 200 triệu dòng code Slang (ngôn ngữ riêng), hơn 160 triệu job mỗi ngày, hơn 13.000 người dùng cuối mỗi ngày.
• Hơn 10.000 database KV trong RAM, phân tán toàn cầu: hơn 2,5 tỉ kết nối, 164 TB message, khoảng 8 PB dữ liệu. Các DB gom thành ring nhất quán cuối: ứng dụng ghi vào bất kỳ thành viên nào, tiến trình SecSync phân phối cập nhật và phát hiện bất nhất.
• Giám sát cũ là một TSDB gắn chặt với SecDb cùng công cụ vẽ PlotTool, vốn làm cho dữ liệu tài chính chứ không phải cho tín hiệu vận hành thời gian thực; báo cáo và email cảnh báo qua batch job. Số DB tăng thì số email không cần xử lý ngay cũng tăng, nhất là lúc sự cố.

Thay đổi chính (khoảng ba năm)

• Giữ TSDB, thêm engine sự kiện có leo thang: cùng team SRE chọn Prometheus + PromQL + Alertmanager. Vì DB quá quan trọng, bước đầu không sửa DB: một metrics probe nói chuyện với daemon có sẵn trên mỗi máy, xuất số liệu cho Prometheus của SRE. Dashboard theo ring, host, DB; rule PromQL tạo sự kiện, cái nhẹ thành tracker rủi ro vận hành, cái nặng leo thang qua PagerDuty.
• Metric Server bên trong DB: khi có alert thời gian thực, team bắt đầu hỏi câu cần trạng thái nội bộ. Thành phần native lưu telemetry trong shared memory của các tiến trình DB và mở cổng cho Prometheus (tự viết vì thư viện có sẵn vướng vấn đề đồng thời và khoá). Từ một endpoint mỗi host thành một endpoint mỗi DB, nhiều SLI hơn, theo dõi được giao dịch đi qua pipeline nội bộ.
• Prometheus khu vực: Prometheus toàn cầu của SRE cần cấu hình endpoint khá tĩnh, trong khi SecDb dời hàng trăm DB giữa máy và tạo DB theo yêu cầu. Thêm tầng Prometheus khu vực cập nhật cấu hình động, quyết định cái gì đẩy lên SRE để lưu lâu, cái gì giữ ngắn cho chẩn đoán.
• Quy trình: trực theo vòng mặt trời, mỗi khu vực 6 người xoay tuần, công cụ SOS chuyển giao giữa khu vực. Metric mới đến từ điều tra hằng ngày, từ action item sau sự cố, và từ SLO mới; SLO đẩy vào kho SLO chung của SRE.
• Log: connection log (có DB tới 150.000 kết nối đồng thời) và log thành phần gửi vào kho log tập trung trên BigQuery; không alert trên log mà trên chuỗi số kết nối trong Prometheus, log dùng để chẩn đoán.

Vì sao

• Với hệ di sản quá quan trọng để đụng vào, quan sát từ bên ngoài trước (probe) tạo được giá trị và lòng tin, rồi mới đưa telemetry vào trong (Observability và monitoring).
• Alert thời gian thực có leo thang thay cho email batch là điều kiện cho trực theo vòng mặt trời (Xử lý sự cố và on-call).

Bài học cho SWE

• Hệ cũ quan trọng: bắt đầu bằng probe bên ngoài, sau đó mới thêm metric server native.
• Đơn vị giám sát nên theo đơn vị di chuyển (mỗi DB), cần một tầng trung gian khi hệ giám sát chung chỉ hỗ trợ cấu hình tĩnh.
• Alert trên metric, dùng log chi tiết (kết nối) để chẩn đoán.

Liên quan

• Goldman Sachs 2021 · Miro 2020 · SoundCloud 2019
• Observability và monitoring · Xử lý sự cố và on-call