Vì sao triển khai GitOps vẫn có thể ‘gãy’ âm thầm?
Trong mô hình GitOps, Argo CD đóng vai trò như đài chỉ huy. Mọi thay đổi manifest trên Git đều được Argo CD tự động pull và apply xuống cụm Kubernetes. Nhưng thực tế vận hành không phải lúc nào cũng êm đẹp.
Ứng dụng có thể kẹt ở trạng thái OutOfSync hoặc rơi vào Degraded. Nếu không có cảnh báo kịp thời, bản release mới sẽ bị treo, thậm chí kéo sập cả service production mà anh em không hề hay biết.
Hệ thống giám sát của mình gồm Prometheus và Grafana quản lý 15 cụm server với hơn 80 microservices. Trước đây, một dev trong team từng vô tình đặt sai indentation trong file values-prod.yaml của Helm chart. Git vẫn nhận commit, nhưng Argo CD âm thầm báo lỗi sync suốt 3 ngày. Đến khi QA test tính năng mới ngã ngửa ra là code mới chưa từng được rollout.
Để chấm dứt cảnh này, bài toán đặt ra rất rõ ràng: gom toàn bộ metrics về Sync Status và Health Status của Argo CD về Prometheus, sau đó vẽ dashboard và bắn alert qua Slack hoặc Telegram.
Cào metrics từ Argo CD về Prometheus Operator
Các thành phần cốt lõi của Argo CD như argocd-server, argocd-repo-server và argocd-application-controller đều export sẵn metrics qua port 8082 hoặc 8083. Nếu cụm của anh em đã chạy kube-prometheus-stack, việc setup chỉ tốn đúng 2 file ServiceMonitor.
Đầu tiên, kiểm tra xem các Service metrics đã sẵn sàng trong namespace argocd chưa:
kubectl get svc -n argocd -l app.kubernetes.io/name=argocd-metricsNếu output trả về service lắng nghe trên cổng 8082, anh em tạo file argocd-servicemonitor.yaml để Prometheus Operator tự động scrape:
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: argocd-metrics
namespace: argocd
labels:
release: kube-prometheus-stack
spec:
selector:
matchLabels:
app.kubernetes.io/name: argocd-metrics
endpoints:
- port: metrics
interval: 30s
scrapeTimeout: 10sBên cạnh controller, argocd-server và argocd-repo-server cũng cần được theo dõi sát sao. Metrics từ repo-server sẽ cho anh em biết Git repo có đang bị nghẽn hoặc dính rate limit hay không:
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
name: argocd-server-metrics
namespace: argocd
labels:
release: kube-prometheus-stack
spec:
selector:
matchLabels:
app.kubernetes.io/name: argocd-server-metrics
endpoints:
- port: metrics
interval: 30sApply cả hai cấu hình vào cluster:
kubectl apply -f argocd-servicemonitor.yamlBóc tách metrics và dựng câu lệnh PromQL
1. Bốn metrics đáng tiền nhất của Argo CD
Argo CD cung cấp khá nhiều dữ liệu, nhưng để trực chiến hàng ngày, anh em chỉ cần tập trung vào 4 metric này:
argocd_app_info: Metric quan trọng nhất. Chứa đầy đủ label nhưsync_status(Synced, OutOfSync) vàhealth_status(Healthy, Degraded, Progressing, Suspended). Metric này luôn trả về giá trị1.argocd_app_sync_total: Tổng số lần sync theo từng kết quả (phase="Succeeded",phase="Failed", hoặcphase="Error").argocd_app_reconcile_count: Tần suất controller so khớp sai khác giữa manifest Git và live state trên cluster.argocd_git_request_total: Lượng request gửi tới GitHub hay GitLab. Rất hữu ích khi cần debug lỗiHTTP 429 Too Many Requests.
2. Các câu truy vấn PromQL dùng hàng ngày
Liệt kê danh sách các app đang bị lỗi sức khỏe (Degraded):
sum(argocd_app_info{health_status="Degraded"}) by (name, dest_server, namespace)Lọc các app đang bị lệch cấu hình giữa Git và cluster (OutOfSync):
sum(argocd_app_info{sync_status="OutOfSync"}) by (name, dest_server, namespace)Đo tỷ lệ sync lỗi trong 15 phút gần nhất (nếu tỷ lệ này vượt 5%, pipeline CI/CD chắc chắn đang có vấn đề):
sum(rate(argocd_app_sync_total{phase=~"Failed|Error"}[15m]))
/
sum(rate(argocd_app_sync_total[15m])) * 1003. Cấu hình PrometheusRule để bắn cảnh báo
Đừng chờ đến khi mở Grafana mới biết app chết. Hãy cấu hình alert tự động để bot réo tên ngay khi sự cố kéo dài:
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
name: argocd-application-alerts
namespace: argocd
labels:
release: kube-prometheus-stack
spec:
groups:
- name: argocd.rules
rules:
- alert: ArgoAppDegraded
expr: argocd_app_info{health_status="Degraded"} == 1
for: 5m
labels:
severity: critical
annotations:
summary: "Ứng dụng {{ $labels.name }} bị Degraded"
description: "App {{ $labels.name }} trên cluster {{ $labels.dest_server }} đã kẹt ở trạng thái lỗi hơn 5 phút."
- alert: ArgoAppOutOfSync
expr: argocd_app_info{sync_status="OutOfSync"} == 1
for: 15m
labels:
severity: warning
annotations:
summary: "Ứng dụng {{ $labels.name }} bị OutOfSync"
description: "Cluster và Git của app {{ $labels.name }} đang lệch nhau hơn 15 phút chưa được reconcile."
4. Import Dashboard lên Grafana
Thay vì tự build từng chart tốn hàng giờ, anh em nên tận dụng dashboard có sẵn từ cộng đồng Argo CD. Truy cập giao diện Grafana, chọn Dashboards > Import rồi nhập ID 14584 (Argo CD Official Dashboard) hoặc 13038.
Dashboard này cung cấp ngay các panel thiết yếu: tổng số Application, biểu đồ tỷ lệ Healthy/Sync, bảng kê các app đang hỏng và latency của repo-server. Sau khi chọn đúng Prometheus data source, dữ liệu sẽ lên đủ ngay lập tức.
Kiểm thử kịch bản thực tế
Setup xong chưa thể coi là hoàn tất nếu chưa test tạo lỗi giả lập.
Trước tiên, xác nhận Prometheus đã nhận diện target của Argo CD:
kubectl port-forward svc/kube-prometheus-stack-prometheus -n monitoring 9090:9090Mở đường dẫn http://localhost:9090/targets. Kiểm tra endpoint serviceMonitor/argocd/argocd-metrics/0 đã báo UP với nền xanh hay chưa.
Tiếp tục tạo sự cố thử nghiệm trên một app staging. Anh em sửa file manifest trên Git, chỉnh image tag thành một bản không tồn tại như auth-service:v999-notfound rồi push lên. Argo CD sẽ pull commit mới về. Ngay lập tức pod dính lỗi ImagePullBackOff, và Argo CD chuyển health status sang Degraded.
Mở Grafana ra kiểm tra: panel Healthy Apps lập tức giảm đi 1, trong khi panel Degraded hiển thị đúng tên auth-service. Chờ đúng 5 phút, Alertmanager sẽ kích hoạt alert ArgoAppDegraded.
Cuối cùng, revert commit trên Git về image tag chuẩn. Argo CD tự động reconcile thành công, pod xanh trở lại và alert tự động resolve. Lúc này, toàn bộ quy trình GitOps của team đã được bọc lưới an toàn 24/7.
