Đã đăng vào khoảng 10 giờ trước 12 phút đọc

#5 Monitoring đã cứu mình: Hành trình dựng nền tảng quan sát hệ thống cho công ti

Đây là một phần trong series mình chia sẻ về những gì mình đã làm khi xây dựng và vận hành hạ tầng backend trên AWS cho công ty. Không phải là best practice hoàn hảo, cũng không phải kiến thức quá cao siêu. Chỉ đơn giản là những gì mình đã học được, thử nghiệm và áp dụng trong quá trình làm việc hằng ngày.

Có lẽ trong năm đầu tiên mình làm tại công ti mới, thứ mà mình cảm thấy tự hào nhất chính là dựng được một nền tảng monitoring cho hệ thống của công ti. Và thực sự nhờ nó mình đã hiểu ra được rất nhiều điều mới mẻ mà trước kia vẫn mù mờ không hiểu.

Tại sao mình phải dựng nền tảng monitoring

Thời điểm đó, công ti không có nền tảng nào như vậy. Để xem log ứng dụng, dev phải ssh vào server để lấy log, việc debug trở nên khó khăn và tốn nhiều thời gian.

Ở công ti cũ, mình đã được tiếp xúc với Datadog. Theo mình đánh giá, đây là một trong những nền tảng monitoring tốt nhất thời điểm hiện tại bởi vì:

Tính tập trung
Giao diện hiện đại
Hỗ trợ nhiều tính năng

Hồi đó mình cũng biết xem log, xem các tính năng APM rồi CPU utilization, nhưng chủ yếu vẫn là xem log. Các thứ khác thì biết là có đó thôi, dù mình cũng khá ấn tượng với công cụ này.

Qua công ti mới, mình tự hỏi tại sao không dựng một nền tảng monitoring cho công ti. Thời điểm bây giờ, gần như công ti nào cũng phải có, và mình tin rằng nếu có nó sẽ có rất nhiều thứ hay ho có thể khai thác.

Không dễ như mình tưởng tượng

Trong đầu mình bắt đầu tìm kiếm những cách để xây dựng nền tảng như vậy. Có nhiều giải pháp mà mình bắt đầu suy nghĩ tới.

Datadog

Đây có lẽ là cách hoàn hảo nhất.

Nhưng chi phí không hề rẻ. Với một công ti startup có vài services mà dùng tới Datadog có vẻ hơi quá so với nhu cầu. Mình vẫn ưu tiên tìm kiếm một giải pháp open-source trước khi nghĩ đến các mô hình trả phí.

ELK – Bộ ba cho phân tích log

Elasticsearch + Logstash + Kibana.

Nếu chỉ riêng phân tích log thì đây có lẽ là bộ ba thần thánh. Nhưng nếu muốn có trace hoặc metrics thì lại phải cài thêm vài tool khác nữa.

Mình muốn có một giải pháp mà cài đặt càng ít tool càng tốt, nhiều quá thì khó bảo trì.

Prometheus + Grafana

Bộ đôi này lại mạnh về metrics.

Nhưng nếu muốn có trace hoặc log thì lại phải cài thêm các tool khác như Thanos… nên vẫn chưa phải thứ mình muốn.

OpenTelemetry + Grafana

Mình đã thử triển khai stack này, nhưng bị vướng trong quá trình tích hợp OpenTelemetry với Spring Boot do vấn đề version giữa Java và Spring Boot.

Thành ra cũng chưa test được nhiều.

AWS CloudWatch, X-Ray

Thực sự mình không quá thích các giải pháp monitoring của AWS.

Không phải mình có thành kiến gì, nhưng mình cảm thấy giao diện không được thân thiện lắm (xin lỗi AWS dù mình rất yêu bạn).

Giải pháp đến bất ngờ

Lần này không phải do mình đọc blog mà biết được.

Mình đã tham gia một buổi chia sẻ về công nghệ, một công ti có sản phẩm là web phim đã giới thiệu công nghệ họ dùng để monitoring hệ thống.

Và thật bất ngờ, đó chính là thứ mà mình tìm kiếm bấy lâu nay.

Một công nghệ tương tự Datadog nhưng open-source (all-in-one).

Đó là sự kết hợp giữa:

OpenTelemetry
SigNoz

Không cần cài đặt thêm bất cứ tool nào khác.

Trong SigNoz đã có đầy đủ mọi thứ liên quan đến:

Logs
Metrics
Traces

OpenTelemetry cũng có thể tích hợp với Spring Boot thông qua file opentelemetry-agent rất đơn giản mà không cần khai báo dependency phức tạp.

Sau buổi chia sẻ đó mình kiểu:

Wow, vậy là mình có thể dùng stack này để xây dựng hệ thống monitoring cho công ti.

Bắt tay vào làm luôn

Sau khi trở về, mình bắt tay vào làm luôn (cho nóng).

Thực ra việc tích hợp cũng không quá khó. Mình bắt đầu ở local trước rồi làm tương tự cho production.

Các bước mình làm:

Format log Spring Boot thành JSON với Logback
Cài đặt SigNoz bằng Docker
Config chạy OpenTelemetry Java agent để gửi dữ liệu sang SigNoz

Kết quả thực sự khiến mình bất ngờ.

SigNoz có đầy đủ gần như mọi thứ mình cần. Dù lúc đó mình chưa tìm hiểu hết tất cả tính năng, nhưng có là tốt rồi, có thời gian thì tìm hiểu tiếp.

Mình chỉ mất khoảng 2 tuần để có thể đưa phiên bản monitoring đầu tiên lên production.

Cả team đều hài lòng.

Những thứ học được từ monitoring

Nhờ tìm hiểu về monitoring, mình đã biết thêm các khái niệm mới mà trước kia mình vẫn mù mờ:

Monitoring có 3 trụ cột chính:

Logs : Bản ghi có dấu thời gian của các sự kiện riêng lẻ xảy ra (lỗi, cảnh báo, thông tin…). Chúng ta dùng nó để debug sự cố cụ thể và hiểu “chuyện gì đã xảy ra và tại sao”.
Metrics: Dữ liệu số theo chuỗi thời gian (đếm, đo lường, histogram…) thể hiện xu hướng và sử dụng tài nguyên theo thời gian (CPU, RAM, tỷ lệ request, tỷ lệ lỗi, latency theo phân vị…). Dùng cho dashboard, cảnh báo và xu hướng dài hạn.
Traces: Cái nhìn toàn bộ hành trình của một request duy nhất khi nó đi qua nhiều service (gồm các span + trace ID). Rất tốt để tìm ra chỗ nào gây chậm hoặc lỗi trong hệ thống microservices.

Ngoài ra còn có các khái niệm như:

SLA (Service Level Agreement): Yêu cầu thoả thuận với khách hàng, nếu vi phạm có thể phải đền bù cho khách hàng, ví dụ service phải đạt 99.5 % uptime, nếu không bị phạt 10%
SLO (Service Level Objective): Mục tiêu mà team mình đặt ra và thường phải tuân thủ nghiêm ngặt hơn giá trị SLA, ví dụ: 99.5 request gửi đến phải thành công hoặc p99 <= 300 ms
SLI (Service Level Indicator): Chỉ số thực tế dùng để đo lường. Ví dụ: Tỷ lệ request thành công, độ trễ p99 hoặc số phần trăm khả dụng

Và các chỉ số latency:

p50 : chỉ số mà 50% số lượng request của chúng ta có độ trễ nhỏ hơn giá trị này, trải nghiệm của đa số người dùng
p95 : chỉ số mà 95% số lượng request nhanh hơn giá trị này, chỉ 5% là thấp hơn, rất quan trọng với trải nghiệm người dùng
p99 : chỉ số mà 99% số lượng request của chúng ta nhanh hơn giá trị này, chỉ 1% là thấp hơn Trong 3 giá trị này, với mình giá trị p99 là giá trị mình theo dõi thường xuyên và quan trọng nhất, nhất là số lượng services càng lớn thì nó càng quan trọng. Mình sẽ dành 1 bài riêng để nói về chủ đề này.

Nhờ trace, mình có thể thấy rõ:

Một request đi từ client tới server
Đi qua những service nào
Mỗi bước mất bao lâu

Tất cả đều được hiển thị rất trực quan.

Việc debug giờ đây trở nên rõ ràng hơn rất nhiều.

Dù tới thời điểm hiện tại mình vẫn chưa khai thác hết tiềm năng của SigNoz, nhưng mình cảm thấy mình đã tiến bộ hơn rất nhiều trong việc hiểu hệ thống.

Nó đã cứu mình một lần

Có một bug khá dai dẳng.

Cứ 12h trưa, hệ thống lại bị chậm.

CPU và RAM của các service đều ổn.

Không có server nào 100%, không có timeout.

Nhưng mọi thứ đều chậm, như thể đang có một hàng đợi nào đó.

Sau khi debug, mình phát hiện vấn đề nằm ở database.

CPU database 100%.

Đúng thời điểm đó, server nhận webhook từ hệ thống thanh toán, gửi tới cùng một lúc, khiến các request phải chờ nhau.

Ban đầu mình nghĩ rất đơn giản:

Quá nhiều request → phải giải quyết ở kiến trúc.

Thế là mình vẽ ra một AWS architecture:

Webhook → SQS
Lambda xử lý queue
Lambda gọi lại webhook server
Giới hạn concurrency

Lúc đó mình khá tự đắc, cảm giác như mình là siêu nhân vậy.

Nhưng khi bắt tay vào làm thì… không đơn giản chút nào.

Sửa tới sửa lui 2 tuần vẫn chưa xong, trong khi mỗi ngày 12h hệ thống vẫn chậm khoảng 20 phút.

Cả công ti đều than phiền.

Debug thật sự

Một lần tình cờ, mình mở monitoring và xem trace của webhook.

Lúc đó mình mới nhận ra rất nhiều vấn đề:

Query select cùng một ID nhưng không cache
Audit log được ghi liên tục
Thread pool async để default
Connection pool database cũng để default
Một số query thiếu index

Sau khi hiểu ra vấn đề, mình sửa lại code:

Cache các query trùng lặp
Giới hạn thread pool async
Giới hạn connection pool database
Thêm index cho các query chậm

Và kết quả…

Không thể tin được.

Trước khi fix:

RDS PostgreSQL cần 20 vCPU

Sau khi fix:

Chỉ cần 0.5 vCPU

Tức là giảm khoảng 40 lần.

Mình không tin nếu chỉ xem log thì có thể tìm ra giải pháp như vậy.

Kết

Với mình, monitoring thực sự mang lại một góc nhìn sâu hơn về hệ thống.

Dù đến thời điểm hiện tại mình vẫn không phải cao thủ monitoring gì cả, nhưng mình tin rằng nhờ nó, mình hiểu hệ thống nhiều hơn trước kia rất nhiều lần.

Bài viết này cũng được mình dịch sang tiếng Anh trên blog substack của mình.

Mình viết lại những điều này như một cách để ghi nhớ hành trình làm nghề của mình. Nếu bạn cũng đang làm backend, devops hoặc cloud, hy vọng những chia sẻ này có thể giúp bạn một chút gì đó. Còn nếu có chỗ nào mình hiểu chưa đúng, mình vẫn luôn sẵn sàng học thêm.