- Có công cụ nào giúp đơn giản hóa việc quản lý các service ( kiểm tra xem service đó còn running on port, hoặc running trên API health check không ạ? Và khi có bất cứ vấn đề gì liên quan đến việc service đó bị tắt, shutdown thì đều có cảnh báo qua mail hoặc telegram ko ạ?
Có nhiều công cụ/cách làm lắm cậu. Tùy thuộc vào thiết kế/nhu cầu của cậu mà cậu sẽ có cách cài đặt phù hợp.
Thường, với những bên quản lý chỉ vài server vật lý như bên cậu, họ hay có xu hướng dùng cả một gói all-in-one như zabbix hoặc datadog (bản có phí, nhưng cài đặt và sử dụng tương đối đơn giản). Cậu thử nghiên cứu nhé!
Còn nếu cậu cần solution end-to-end monitor cho hệ thống infra hàng ngàn server/container, cậu mới cần ELK stack/prometheus/influx DB. Cậu có thể cài đặt cho use-case hiện tại của cậu, nhưng nó tương đối phức tạp về mặt kiến trúc, khi cậu cần cân nhắc rất nhiều technical decision. Nếu cậu có 1 đội infra/devops khoảng chục người làm 1 hệ thống microservice có rất nhiều service, hoặc chỉ đơn thuần muốn thử nghiệm/học hỏi mà không quan tâm tới cost-effective solution, cậu cũng có thể cân nhắc giải pháp này.
Nếu cậu chỉ cần 1 hệ thống nho nhỏ để healthcheck các hệ thống khác, cậu có thể tự implement/hoặc sử dụng service discovery để làm điều đó (cho dù service discovery không có tính năng báo lỗi - cậu vẫn phải implement phần này). Tự implement có thể giúp cậu đưa ra alert qua email/Telegram theo ý cậu.
- Tương tự đối với công cụ quản lý tài nguyên của server ( Khi CPU/ RAM/ Bộ nhớ ) của server lên quá cao cũng có cảnh báo ạ?
Nếu cậu sử dụng all-in-one solution, cậu cũng sẽ có tính năng này nếu tớ nhớ không nhầm.
Nếu cậu sử dụng ELK stack/prometheus/influx DB, cậu cần có một component riêng cho alert (gọi là alert manager). Ý tưởng là component ấy đọc dữ liệu từ elasticsearch/prometheus/influx DB định kỳ (pull model) hoặc nhận event từ time-base series DB (push model - TH cậu dùng time-base series DB như prometheus có thể dùng cách này) để sinh ra alert phù hợp. Cậu cũng hoàn toàn có thể cài đặt các rule phù hợp trên component này để tạo alert một cách mềm dẻo. Industry thường sử dụng cách này để thực hiện việc sinh ra alert mà không ảnh hưởng tới các service khác, như monitor dashboard.
Cậu cũng có thể sử dụng grafana alert/kibana alert. Cơ mà, tớ phải nói tớ thích việc tách monitor dashboard với alert component riêng hơn là để chung. Tất nhiên, trong TH cậu không có quá nhiều traffic, và cậu cũng chỉ cần các alert rule đơn giản, cậu hoàn toàn có thể dùng grafana alert /kibana.
- Về vấn đề xử lý logs của các hệ thống + cảnh báo lỗi đối với ERROR LOGS, thì mn đang dùng công cụ gì ạ? Hiện tại mình tìm hiểu thì có 3 thàng là Sentry, Kibana, Grafana…Thì nên dùng hệ thống logs nào vừa tốt lại vừa đảm bảo về vấn đề security của hệ thống ạ?
Tớ đoán cậu muốn hỏi về log tracing? Grafana thực ra không có log tracing, ý cậu là Grafana Loki?
Bên tớ có rất nhiều hệ thống, và mỗi hệ thống sử dụng 1 set công nghệ riêng cho việc monitoring/log tracing. Tớ có thể đưa ra một vài set cho cậu tham khảo (tất cả đều được dùng trên production mà không gặp vấn đề gì liên quan tới security).
- Logstash + Elasticsearch để lưu log, Grafana/Jenifer dashboard cho monitor, Graylog cho log tracing, in-house development system cho alert.
- Zabbix hoặc datadog cho tất cả.
- Prometheus + kafka cho metric exporting/storing/query engine, grafana monitor, một alert manager nào đó nhận event push từ prometheus. Cậu có thể thay prometheus bằng influx DB với hiệu quả tương tự.
- Các công nghệ monitor/alert tích hợp với cloud solution.
- Etc.
Hope it helps!
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?