Cấu hình Prometheus và Grafana để theo dõi metric của Kong và OPA
Ta cần cấu hình Prometheus để scrape metric từ Kong Gateway (port 8001) và OPA sidecar (port 8181) để có cái nhìn toàn diện về hiệu năng.
Tại sao: Kong và OPA đều có endpoint /metrics riêng biệt hỗ trợ Prometheus format. Nếu không cấu hình, ta sẽ không thấy latency, số lượng request hay memory usage.
Kết quả mong đợi: Prometheus dashboard hiển thị các metric như kong_requests_total và opa_request_duration_seconds.
Trước tiên, ta tạo file cấu hình Prometheus trong thư mục /etc/prometheus/.
cat > /etc/prometheus/prometheus.yml
Sau khi lưu, Prometheus sẽ bắt đầu scrape metric từ Kong Gateway (port 8001) và OPA (port 8181).
Kiểm tra kết quả: Truy cập http://prometheus:9090/targets. Tất cả các target phải hiển thị trạng thái UP.
Triển khai Grafana Dashboard cho Kong và OPA
Tiếp theo, ta cài đặt Dashboard có sẵn từ cộng đồng để trực quan hóa dữ liệu đã scrape được.
Tại sao: Dữ liệu raw trong Prometheus khó đọc. Dashboard giúp ta nhìn thấy xu hướng latency, error rate và throughput theo thời gian thực.
Kết quả mong đợi: Grafana hiển thị 2 dashboard riêng biệt cho Kong và OPA với các biểu đồ động.
Ta sử dụng curl để import template JSON vào Grafana (giả sử Grafana đang chạy trên port 3000).
curl -XPOST 'http://grafana:3000/api/dashboards/import' \
-H 'Content-Type: application/json' \
-d '{
"dashboard": {
"uid": "kong-dashboard",
"title": "Kong Gateway Metrics",
"inputs": [
{"name": "Prometheus", "pluginId": "prometheus", "type": "datasource", "value": "Prometheus"}
]
},
"overwrite": true,
"dashboardUrl": "https://raw.githubusercontent.com/Kong/kong-prometheus-exporter/master/grafana/kong-dashboard.json"
}'
Lưu ý: Command trên giả định template JSON nằm trên GitHub. Trong môi trường production, bạn nên download file JSON về local rồi upload qua UI hoặc API.
Tương tự cho OPA, ta import dashboard từ repo chính chủ của OPA.
curl -XPOST 'http://grafana:3000/api/dashboards/import' \
-H 'Content-Type: application/json' \
-d '{
"dashboard": {
"uid": "opa-dashboard",
"title": "OPA Policy Evaluation",
"inputs": [
{"name": "Prometheus", "pluginId": "prometheus", "value": "Prometheus"}
]
},
"overwrite": true,
"dashboardUrl": "https://raw.githubusercontent.com/open-policy-agent/opa/master/grafana/opa-dashboard.json"
}'
Kiểm tra kết quả: Truy cập http://grafana:3000, vào mục Dashboards, bạn sẽ thấy "Kong Gateway Metrics" và "OPA Policy Evaluation".
Phân tích logs để tìm lỗi handshake mTLS hoặc lỗi chính sách OPA
Cấu hình Log Level chi tiết cho Kong và OPA
Để debug các vấn đề về mTLS và Policy, ta cần chuyển log level từ info xuống debug hoặc notice.
Tại sao: Log mặc định chỉ ghi lại kết quả thành công/thất bại. Để biết tại sao handshake thất bại (cert expired, wrong CA) hay policy bị deny, cần log chi tiết.
Kết quả mong đợi: Log file xuất hiện các dòng chi tiết về handshake TLS và quá trình evaluate policy.
Chỉnh sửa file cấu hình Kong Gateway trong thư mục /usr/local/kong/ (hoặc path tương ứng trong container).
cat > /usr/local/kong/kong.yml
Sau khi chỉnh sửa, restart service Kong để áp dụng.
kong restart
Kiểm tra kết quả: Chạy tail -f /var/log/kong/error.log và thực hiện một request mTLS. Bạn sẽ thấy dòng log chi tiết về handshake.
Phân tích log OPA để tìm lỗi Policy
OPA thường chạy trong sidecar container, log của nó nằm ở stdout/stderr hoặc file riêng tùy cấu hình.
Tại sao: Khi OPA trả về 403 Forbidden, log sẽ ghi rõ rule nào bị vi phạm (violation) và giá trị biến nào gây ra lỗi.
Kết quả mong đợi: Trong log OPA, xuất hiện dòng violation kèm theo rule và input bị lỗi.
Giả sử OPA đang chạy trong container tên opa-sidecar, ta dùng kubectl logs hoặc docker logs để xem.
kubectl logs -f -c opa | grep -i "violation\|denied\|error"
Hoặc nếu OPA cấu hình log file riêng trong container (ví dụ /var/log/opa/opa.log), ta mount volume ra host và xem.
cat /var/log/opa/opa.log | grep -A 5 "violation"
Trong log, tìm các mẫu như: rule: "deny" if input.method == "DELETE" để xác định chính xác rule nào chặn request.
Xử lý các vấn đề phổ biến: Connection refused, Certificate expired, Policy timeout
Vấn đề 1: Connection Refused (mTLS Handshake Fail)
Triệu chứng: Client nhận lỗi Connection refused hoặc SSL_ERROR_SYSCALL ngay khi bắt đầu kết nối.
Nguyên nhân: Certificate client không khớp với CA của server, hoặc server không cấu hình đúng port cho mTLS.
Cách xử lý: Kiểm tra chuỗi chứng chỉ (Certificate Chain) và cấu hình port trong Kong.
Kiểm tra xem Kong có lắng nghe đúng port 8443 (mTLS) không.
netstat -tlnp | grep 8443
Kiểm tra log error của Kong để xem lỗi cụ thể về chứng chỉ.
grep -i "certificate\|handshake" /var/log/kong/error.log
Nếu log báo certificate verify failed, ta cần kiểm tra lại file CA bundle đã mount vào container.
openssl s_client -connect kong-gateway:8443 -showcerts -verify_return_error
Kiểm tra kết quả: Command openssl phải trả về Verify return code: 0 (ok).
Vấn đề 2: Certificate Expired (Chứng chỉ hết hạn)
Triệu chứng: Request bị từ chối với lỗi 400 Bad Request hoặc 502 Bad Gateway kèm thông báo certificate has expired.
Nguyên nhân: Thời gian hiện tại vượt quá notAfter trong chứng chỉ client hoặc server.
Cách xử lý: Làm mới chứng chỉ và cập nhật vào Kong.
Kiểm tra ngày hết hạn của chứng chỉ đang dùng.
openssl x509 -in /etc/kong/ssl/client.crt -noout -dates
Nếu đã hết hạn, ta cần tạo lại chứng chỉ (theo quy trình Phần 6) và cập nhật vào Kong Admin API.
kong certificate create --cert /path/to/new-cert.pem --key /path/to/new-key.pem
Sau đó, cập nhật plugin mTLS để trỏ vào certificate mới.
kong certificate add --certificate --service
Kiểm tra kết quả: Thực hiện request lại, lỗi expired biến mất.
Vấn đề 3: Policy Timeout (OPA quá chậm)
Triệu chứng: Request treo (hang) trong vài giây rồi trả về 504 Gateway Timeout.
Nguyên nhân: Policy OPA quá phức tạp, truy vấn database chậm, hoặc network latency giữa Kong và OPA sidecar.
Cách xử lý: Tối ưu policy, tăng timeout hoặc cache kết quả.
Kiểm tra log OPA để xem thời gian xử lý (duration).
grep -i "duration" /var/log/opa/opa.log
Tìm các dòng có duration lớn hơn 1 giây (ví dụ: duration: 2.5s).
Tối ưu policy bằng cách tránh truy vấn external data trong runtime nếu không cần thiết, hoặc dùng builtin của OPA.
Cấu hình timeout trong Kong plugin OPA (nếu dùng plugin custom) hoặc trong config OPA.
cat > /etc/opa/config.yaml
Kiểm tra kết quả: Request không còn bị timeout, log OPA hiển thị duration < 1s.
Tips tối ưu hiệu năng cho Gateway khi có nhiều policy phức tạp
Sử dụng Caching cho Policy Decision
Vấn đề: Mỗi request đều gọi OPA sẽ gây tải lớn cho CPU và tăng latency.
Giải pháp: Cache kết quả decision của OPA dựa trên key (ví dụ: user-id, role, action).
Kết quả mong đợi: Giảm latency từ 50ms xuống 5ms cho các request giống nhau.
Cấu hình cache trong OPA hoặc sử dụng Redis để cache kết quả.
cat > /etc/opa/opa.yaml
Hoặc sử dụng plugin proxy-protocol hoặc redis-cache trong Kong để cache response từ OPA.
Kiểm tra kết quả: Quan sát metric opa_request_duration_seconds trên Grafana, giá trị trung bình giảm đáng kể.
Tối ưu Policy Compilation và Reuse
Vấn đề: OPA biên dịch lại policy mỗi khi tải file mới, gây delay ở lần đầu tiên.
Giải pháp: Sử dụng opa run với chế độ --watch hoặc pre-compile policy trước khi deploy.
Kết quả mong đợi: Không có delay khi deploy policy mới, hoặc delay chỉ xảy ra ở lần đầu load.
Chạy OPA với chế độ pre-compile hoặc tối ưu file policy bằng cách gộp các rule nhỏ.
opa eval 'data.example.allow' --data /policies/example.rego --input /input.json
Trong Kubernetes, sử dụng ConfigMap và restart OPA container khi policy thay đổi, thay vì hot-reload nếu không cần thiết.
Kiểm tra kết quả: Thời gian startup của OPA container giảm, không có log compiling policy trong runtime.
Hạn chế số lượng plugin và rule không cần thiết
Vấn đề: Mỗi plugin trong Kong đều chạy Lua script, mỗi rule trong OPA đều tốn CPU. Quá nhiều plugin làm giảm throughput.
Giải pháp: Audit lại danh sách plugin, tắt những plugin không dùng, gộp rule OPA thành một file lớn thay vì nhiều file nhỏ.
Kết quả mong đợi: Throughput (req/sec) tăng lên, CPU usage giảm.
Danh sách plugin đang bật trong Kong.
kong list plugins
Tắt plugin không cần thiết.
kong delete plugins
Gộp các file policy OPA nhỏ thành một file chính main.rego.
cat /policies/*.rego > /policies/main.rego
Kiểm tra kết quả: Chạy benchmark tool (ví dụ wrk) so sánh throughput trước và sau khi tối ưu.
wrk -t12 -c40 -d30s http://kong-gateway:8001/api/test
So sánh kết quả req/sec, giá trị sau tối ưu phải cao hơn.
Điều hướng series:
Mục lục: Series: Xây dựng nền tảng Secure API Gateway với Kong, OPA và mTLS trên Kubernetes
« Phần 6: Tự động hóa chứng chỉ và quản lý vòng đời