Master Kubernetes Observability: Tăng cường hiệu suất, bảo mật và tính ổn định với Tracestore, OPA, Flagger và Custom Metrics

Development

Bizfly Cloud

3951

29-12-2025

Khi các ứng dụng mở rộng trong môi trường Kubernetes, việc theo dõi các vấn đề về hiệu suất, tuân thủ bảo mật và đảm bảo triển khai suôn sẻ là những thách thức phức tạp. Các giải pháp giám sát truyền thống không thể giải quyết triệt để những thách thức này.

Cùng Bizfly Cloud khám phá bốn công cụ mạnh mẽ giúp cải thiện đáng kể khả năng quan sát và kiểm soát trong môi trường microservices:

• Tracestore: Cung cấp sâu các thông tin chi tiết về theo dõi phân tán, cho phép các dev theo dõi luồng requests, xác định các vấn đề về độ trễ và chẩn đoán các điểm nghẽn trên toàn bộ dịch vụ microservices. 
• OPA (Open Policy Agent): Đảm bảo bảo mật và khả năng quản trị thông qua triển khai các dynamic policy trực tiếp trong môi trường Kubernetes.
• Flagger: Cho phép tự động progressive delivery, giảm thiểu rủi ro triển khai thông qua các chiến lược shift và rollback lưu lượng thông minh.
• Custom Metrics: Thu thập các chỉ số cụ thể của ứng dụng, cung cấp thông tin chi tiết nâng cao mà các công cụ giám sát chung có thể bỏ qua.

Các developer thường gặp khó khăn trong việc chẩn đoán các vấn đề về độ trễ, bảo mật và đảm bảo triển khai ổn định trong môi trường Kubernetes động. Với việc kết hợp Tracestore, OPA, Flagger và Custom Metrics, bạn có thể “unlock” khả năng hiển thị nâng cao, cải thiện thực thi bảo mật và tối ưu progressive delivery.

OPA (Open Policy Agent) dành cho Developers

Tại sao nên sử dụng OPA cho bảo mật và tuân thủ policy?

Open Policy Agent (OPA) là một công cụ mạnh mẽ để đảm bảo tuân thủ chính sách bảo mật và quản lý truy cập nhất quán trong môi trường Kubernetes. Sử dụng logic Rego, OPA xác thực các yêu cầu một cách linh hoạt, ngăn chặn truy cập trái phép và tăng cường các biện pháp tuân thủ. Dưới đây là những lợi ích chính của OPA đối với việc thực thi chính sách và bảo mật.

Kiểm soát Admission: Xác thực các manifest trước khi chúng được áp dụng vào cluster để ngăn chặn triển khai trái phép. Kiểm soát Access: Đảm bảo chỉ những người dùng và dịch vụ được cấp quyền mới có thể truy cập vào các endpoint hoặc tài nguyên cụ thể. Data Filter: Hạn chế việc lộ dữ liệu nhạy cảm bằng cách áp dụng các quy tắc lọc ở lớp API.

Ví dụ thực tế: Trong môi trường SaaS nhiều tài khoản sử dụng, OPA có thể:

Từ chối các yêu cầu truy cập vào tài nguyên không nằm trong phạm vi được truy cập của tài khoản của người dùng. Thực thi các quy tắc dynamic RBAC dựa trên các tham số yêu cầu mà không cần sửa đổi code ứng dụng.

Các Rego policy linh hoạt của OPA cho phép các developer xác định logic phức tạp có thể thích ứng được với các yêu cầu về bảo mật và vận hành ngày một cao.

Hiểu về OPA Webhook

OPA Webhook được thiết kế để thiết lập chính sách trước khi tài nguyên được tạo hoặc sửa đổi trong Kubernetes. Khi một webhook được kích hoạt, OPA sẽ đánh giá requests đến dựa trên các quy tắc đã thiết lập trước đó và trả về quyết định cho phép hoặc từ chối.

Sơ đồ trên trình bày quy trình đánh giá webhook OPA trong quá trình kiểm soát truy cập Kubernetes, đảm bảo tính an toàn trước khi tạo tài nguyên.

Ví dụ về cấu hình OPA Webhook

apiVersion: admissionregistration.k8s.io/v1

kind: MutatingWebhookConfiguration

metadata:

  name: opa-webhook

webhooks:

  - name: "example-opa-webhook.k8s.io"

    clientConfig:

      url: "https://opa-service.opa.svc.cluster.local:443/v1/data/authz"

    rules:

      - operations: ["CREATE", "UPDATE"]

        apiGroups: [""]

        apiVersions: ["v1"]

        resources: ["pods"]

    failurePolicy: Fail

Các Rego Policy được cấu hình ở đâu?

Các Rego Policy được lưu trữ trong policy repositories được chỉ định hoặc bên trong Kubernetes ConfigMaps. Ví dụ:

Ví dụ về Policy ConfigMap:

apiVersion: v1

kind: ConfigMap

metadata:

  name: opa-policy-config

  namespace: opa

  labels:

    openpolicyagent.org/policy: rego

  annotations:

    openpolicyagent.org/policy-status: "active"

data:

  authz.rego: |

    package authz

    default allow = false

    allow {

        input.user == "admin"

        input.action == "read"

    }

    allow {

        input.user == "developer"

        input.action == "view"

    }

Triển khai YAML với OPA làm Sidecar

Để tích hợp OPA làm Sidecar, hãy sửa đổi YAML như bên dưới:

apiVersion: apps/v1

kind: Deployment

metadata:

  name: sample-app

spec:

  replicas: 2

  selector:

    matchLabels:

      app: sample-app

  template:

    metadata:

      labels:

        app: sample-app

    spec:

      containers:

      - name: sample-app

        image: sample-app:latest

        ports:

        - containerPort: 8080

      - name: opa-sidecar

        image: openpolicyagent/opa:latest

        args:

        - "run"

        - "--server"

        - "--config-file=/config/opa-config.yaml"

        volumeMounts:

        - mountPath: /config

          name: opa-config-volume

        - mountPath: /policies

          name: opa-policy-volume

      volumes:

      - name: opa-config-volume

        configMap:

          name: opa-config

      - name: opa-policy-volume

        configMap:

          name: opa-policy-config

Biểu đồ trên cho thấy vai trò nổi bật của OPA sidecar trong việc chặn các request và đảm bảo bảo mật trong môi trường Kubernetes.

Các OPA policy mẫu (Rego) cho Access Control

Các OPA policy được viết bằng ngôn ngữ Rego. Dưới đây là các policy mẫu để kiểm soát truy cập API endpoint.

package authz

default allow = false

allow {

    input.user == "admin"

    input.action == "read"

}

allow {

    input.user == "developer"

    input.action == "view"

}

allow {

    input.role == "finance"

    input.action == "approve"

}

allow {

    input.ip == "192.168.1.1"

    input.method == "GET"

}

allow {

    input.role == "editor"

    startswith(input.path, "/editor-area/")

}

allow {

    input.role == "viewer"

    startswith(input.path, "/public/")

}

Giải thích Rule

• Admin Rule: Cấp quyền đọc cho người dùng là admin.
• Developer Rule: Cho phép view cho vai trò developer.
• Finance Role Rule: Cấp quyền phê duyệt cho người dùng có finance role.
• IP-Based Restriction Rule: Cho phép GET requests từ IP 192.168.1.1. Sử dụng cho các API endpoint nội bộ.
• Editor Access Rule: Cấp quyền truy cập vào các endpoint bắt đầu bằng /editor-area/ cho vai trò editor.Viewer Access Rule: Cho phép viewer truy cập vào các /public/ endpoint.

Mỗi rule đều đảm bảo các điều kiện rõ ràng để cải thiện bảo mật, quản lý role và kiểm soát tài nguyên.

Tích hợp Java - Chạy OPA Policy

Các OPA rule có thể được tích hợp vào các ứng dụng Java khi sử dụng các HTTP request để giao tiếp với OPA sidecar.

Mẫu Java Code cho Access Control

import org.springframework.web.bind.annotation.*;

import org.springframework.http.ResponseEntity;

import org.springframework.http.HttpStatus;

import org.springframework.web.client.RestTemplate;

@RestController

@RequestMapping("/secure")

public class SecureController {

    @PostMapping("/access")

    public ResponseEntity<String> checkAccess(@RequestBody Map<String, String> request) {

        RestTemplate restTemplate = new RestTemplate();

        String opaEndpoint = "http://localhost:8181/v1/data/authz";

        ResponseEntity<Map> response = restTemplate.postForEntity(opaEndpoint, request, Map.class);

        boolean allowed = (Boolean) response.getBody().get("result");

        if (allowed) {

            return ResponseEntity.ok("Access Granted");

        }

        return ResponseEntity.status(HttpStatus.FORBIDDEN).body("Access Denied");

    }

}

Tích hợp Node.js - Chạy OPA Policy

OPA cũng có thể được tích hợp vào các ứng dụng Node.js khi sử dụng các  HTTP request để truy vấn sidecar OPA.

Mẫu Node.js Code cho Access Control

const express = require('express');

const axios = require('axios');

const app = express();

app.use(express.json());

app.post('/access', async (req, res) => {

    const opaEndpoint = 'http://localhost:8181/v1/data/authz';

    try {

        const response = await axios.post(opaEndpoint, { input: req.body });

        if (response.data.result) {

            res.status(200).send('Access Granted');

        } else {

            res.status(403).send('Access Denied');

        }

    } catch (error) {

        res.status(500).send('OPA Evaluation Failed');

    }

});

app.listen(3000, () => console.log('Server running on port 3000'));

Giải thích:

/access endpoint chuyển tiếp các role và hành động của người dùng đến sidecar OPA.

Phản hồi của OPA xác định liệu yêu cầu được chấp nhận hay từ chối.

Các cách tối ưu để tích hợp OPA

• Giảm tối đa logic phức tạp trong policy: Hãy để Rego Policy đơn giản, với các rule rõ ràng để tránh nghẽn xử lý.
• Sử dụng tính năng Versioning cho policy: Để ngăn ngừa các vấn đề về khả năng tương thích, hãy quản lý phiên bản các file và gói policy.
• Sử dụng tính năng Decision Logging của OPA: Bật Decision Logging để quan sát và gỡ lỗi tốt hơn.
• Cache OPA Responses tại vị trí thích hợp: Đối với các evaluation lặp lại, việc lưu trữ cache sẽ cải thiện hiệu suất.

Ví dụ về chạy Hierarchical Policy (Vai trò Admin, User, Guest)

OPA xác định ranh giới bảo mật rõ ràng cho các vai trò người dùng khác nhau, chẳng hạn như:

• Admin: Toàn quyền kiểm soát với quyền truy cập không giới hạn.
• User: Quyền hạn chế dựa trên các tiêu chí đã xác định.
• Guest: Chỉ được phép read-only.

Ví dụ về Rego Policy cho Role-Based Access Control:

package authz

default allow = false

allow {

    input.user.role == "admin"

    input.action in ["create", "read", "update", "delete"]

}

allow {

    input.user.role == "user"

    input.action in ["read", "update"]

}

allow {

    input.user.role == "guest"

    input.action == "read"

}

Biểu đồ minh hoạ cách các vai trò khác nhau như Admin, User và Guest được cấp các quyền truy cập khác nhau thông qua Rego Policies.

Một số vấn đề về Sidecar Scaling trong môi trường High-Traffic

• Chi phí CPU/Bộ nhớ: Mỗi Sidecar OPA lại có yêu cầu riêng về tài nguyên, do đó có thể làm tăng chi phí khi mở rộng các pod.
• Ảnh hưởng đến latency: Các OPA evaluation gây ra độ trễ, đặc biệt là với các policy phức tạp.
• Quản lý policy trên toàn bộ cluster: Việc scaling Sidecar trên hàng trăm pod có thể dẫn đến chi phí bảo trì.

Giải pháp:

• Kích hoạt OPA bundle caching để giảm tần suất truy xuất policy.
• Tối ưu hóa Rego Policy bằng cách hạn chế các nested conditions (điều kiện lồng) và tận dụng một phần evaluation  cho pre-compute logic.
• Đối với các môi trường quy mô lớn, hãy cân nhắc triển khai một OPA instance tập trung hoặc sử dụng OPA Gatekeeper để cải thiện khả năng mở rộng.

Chạy Policy Versioning tốt nhất

• Sử dụng Git để Kiểm soát Versioning
• Triển khai CI/CD cho các policy
• Tận dụng  Bundle API của OPA để phân phối policy nhất quán.
• Gắn thẻ Stable Policy Version
• Tự động Rollback cho các policy bị lỗi

Flagger Implementation cho Developers Vai trò của Flagger trong các Pipeline CI/CD

Flagger tự động quá trình progressive delivery trong Kubernetes bằng cách dần dần chuyển traffic sang triển khai canary, đồng thời đo lường tỷ lệ thành công, latency và custom metrics.

Flagger đóng vai trò quan trọng trong việc đảm bảo release các Pipeline CI/CD an toàn và tự động hơn. Bằng cách tích hợp Flagger, các developer có thể:

• Tự động hóa progressive rollout, giảm thiểu rủi ro triển khai.
• Liên tục xác thực mỗi khi release phiên bản mới bằng cách phân tích các số liệu theo thời gian thực.
• Kích hoạt webhook để kiểm tra tự động hoặc xác thực dữ liệu trước khi shift traffic đi hoàn toàn.

Cách này giúp các developer có thể tự tin triển khai các thay đổi trong khi giảm thiểu gián đoạn dịch vụ.

Sơ đồ này hiển thị quy trình triển khai canary tự động của Flagger, trong đó Flagger kích hoạt thử nghiệm tải, đánh giá kết quả và đưa canary lên trạng thái ổn định hoặc khôi phục khi gặp lỗi.

Cấu hình triển khai Flagger Canary

Cấu hình Flagger Canary mẫu

apiVersion: flagger.app/v1beta1

kind: Canary

metadata:

  name: podinfo

  namespace: test

spec:

  provider: istio

  targetRef:

    apiVersion: apps/v1

    kind: Deployment

    name: podinfo

  progressDeadlineSeconds: 60

  autoscalerRef:

    apiVersion: autoscaling/v2beta2

    kind: HorizontalPodAutoscaler

    name: podinfo

  service:

    gateways:

    - monitor/monitor-gw

    hosts:

    - monitor.dev.scus.cld.samsclub.com

    name: podinfo

    port: 9898

    targetPort: 9898

    portName: http

    portDiscovery: true

    match:

      - uri:

          prefix: /

    rewrite:

      uri: /

    timeout: 5s

  skipAnalysis: false

  analysis:

    interval: 1m

    threshold: 10

    maxWeight: 50

    stepWeight: 5

    metrics:

    - name: checkout-failure-rate

      templateRef:

        name: checkout-failure-rate

        namespace: istio-system

      thresholdRange:

        max: 1

      interval: 1m

    webhooks:

      - name: "load test"

        type: rollout

        url: http://flagger-loadtester.test/

        metadata:

          cmd: "hey -z 1m -q 10 -c 2 http://podinfo.test:9898/"

    alerts:

      - name: "dev team Slack"

        severity: error

        providerRef:

          name: dev-slack

          namespace: flagger

      - name: "qa team Discord"

        severity: warn

        providerRef:

          name: qa-discord

Giải thích cho các trường chính

• provider: Chỉ định nhà cung cấp service mesh như istio, linkerd, v.v.
• targetRef: Tham chiếu đến triển khai chính.
• autoscalerRef: Liên kết canary với HPA để tự động mở rộng quy mô.
• analysis: Xác định chiến lược test
• interval: Thời gian giữa mỗi lần tăng traffic.
• threshold: Số lần kiểm tra không thành công trước khi khôi phục.
• maxWeight: Tỷ lệ traffic tối đa được chuyển sang canary.
• stepWeight: Kích thước traffic tăng.
• metrics: Chỉ định mẫu số liệu Prometheus được sử dụng cho tiêu chí thành công.
• webhooks: Xử lý các external test (ví dụ: load tests) trước khi nâng cấp.
• alert: Xác định kích hoạt cảnh báo cho các dịch vụ như Slack, Discord hoặc Teams.

Use Case: Triển khai tính năng cho hệ thống giỏ hàng

Giả định rằng một ứng dụng giỏ hàng cần test logic thanh toán mới. Sử dụng chiến lược Flagger's canary, bạn có thể vừa từng bước đưa ra quy trình thanh toán mới, đồng thời đảm bảo tính ổn định thông qua việc theo dõi các chỉ số như tỷ lệ đơn hàng thành công và độ trễ.

Sơ đồ Progressive Traffic Shifting

Luồng Progressive Traffic Shifting trong Flagger

Sơ đồ này minh họa chiến lược chuyển đổi lưu lượng theo cấp số nhân, trong đó lưu lượng dần chuyển từ phiên bản ổn định sang phiên bản canary, đảm bảo việc triển khai an toàn.

Giải thích: Flagger chuyển đổi lưu lượng dần từ phiên bản ổn định sang phiên bản canary. Nếu việc triển khai canary đạt được các mục tiêu hiệu suất (ví dụ: độ trễ, tỷ lệ thành công), lưu lượng sẽ tiếp tục tăng cho đến khi đạt được mức độ nâng cấp đầy đủ. Nếu các chỉ số vượt quá ngưỡng lỗi, Flagger sẽ tự động khôi phục việc triển khai canary.

Thực hành tốt nhất để xử lý lỗi Webhook

Để đảm bảo khả năng phục hồi trong trường hợp lỗi webhook, hãy làm theo các thực hành sau:

• Triển khai Thử lại với Backoff: Cấu hình webhook để thử lại các yêu cầu không thành công với backoff theo cấp số nhân nhằm giảm tải không cần thiết trong các lỗi tạm thời.
• Giới thiệu Giới hạn Thời gian chờ: Thêm thời gian chờ cho các phản hồi webhook để tránh sự chậm trễ trong các đợt nâng cấp canary.
• Triển khai Cảnh báo Dự phòng: Nếu webhook không thành công sau nhiều lần thử lại, hãy cấu hình hệ thống cảnh báo để thông báo ngay cho các nhà phát triển (ví dụ: Slack, PagerDuty).
• Thêm Kiểm tra Tình trạng Webhook: Định kỳ kiểm tra các điểm cuối webhook để chủ động phát hiện và khắc phục sự cố trước khi xảy ra lỗi triển khai.

Cấu hình mẫu số liệu

Flagger có thể tích hợp các số liệu tùy chỉnh để nâng cao khả năng ra quyết định cho việc phân phối theo từng giai đoạn.

Sơ đồ này cho thấy cách Flagger đánh giá các chỉ số Prometheus để xác định sự thành công hay thất bại của một đợt triển khai canary.

Ví dụ về cấu hình chỉ số tùy chỉnh cho Flagger

apiVersion: flagger.app/v1beta1

kind: MetricTemplate

metadata:

  name: checkout-failure-rate

  namespace: istio-system

spec:

  provider:

    type: prometheus

    address: http://prometheus.istio-system:9090

  query: |

    100 - sum(

        rate(

            istio_requests_total{

              reporter="destination",

              destination_workload_namespace="{{ namespace }}",

              destination_workload="{{ target }}",

              response_code!~"5.*"

            }[{{ interval }}]

        )

    )

    /

    sum(

        rate(

            istio_requests_total{

              reporter="destination",

              destination_workload_namespace="{{ namespace }}",

              destination_workload="{{ target }}",

            }[{{ interval }}]

        )

    ) * 100

Giải thích: Công cụ này tính toán tỷ lệ phần trăm yêu cầu thành công bằng cách lọc ra mã phản hồi 5xx. Sử dụng Prometheus làm nền tảng để lấy dữ liệu số liệu.

Cải thiện mẫu số liệu với truy vấn Prometheus tùy chỉnh

Để cải thiện khả năng ra quyết định của Flagger, hãy cân nhắc tạo các truy vấn Prometheus nâng cao cho các số liệu tùy chỉnh.

Ví dụ về truy vấn Prometheus tùy chỉnh để phân tích độ trễ API:

Thực hành tốt nhất cho tích hợp Flagge

• Thiết kế các bước tăng trưởng nhỏ để Triển khai An toàn hơn: Chuyển đổi lưu lượng dần dần giúp giảm thiểu rủi ro.
• Tận dụng Webhooks để Kiểm tra Tự động: Webhooks cho phép kiểm tra toàn diện trước khi thúc đẩy thay đổi.
• Sử dụng Chỉ số Tùy chỉnh để có Thông tin Chi tiết Tốt hơn: Theo dõi các chỉ số quan trọng của doanh nghiệp, ảnh hưởng trực tiếp đến hiệu suất.
• Đảm bảo Kênh Cảnh báo Rõ ràng: Thông báo của Slack, Discord hoặc Teams giúp các nhóm hành động nhanh chóng khi có sự cố.
• Tích hợp kiểm tra tải: Kiểm tra tải tự động trong quá trình phát hành canary sẽ xác thực tính ổn định trước khi nâng cấp.

Custom Metrics cho Developers 

Tại sao nên sử dụng Chỉ số Tùy chỉnh?

Chỉ số tùy chỉnh mang đến những thông tin hữu ích bằng cách theo dõi các hành vi cụ thể của ứng dụng, chẳng hạn như tỷ lệ thanh toán thành công, kích thước hàng đợi hoặc mức sử dụng bộ nhớ. Bằng cách liên kết các chỉ số với mục tiêu kinh doanh, các nhà phát triển có thể có được cái nhìn sâu sắc về hiệu suất hệ thống, từ đó tối ưu hóa trải nghiệm người dùng và vận hành ứng dụng hiệu quả hơn.

• Theo dõi trải nghiệm người dùng: Theo dõi độ trễ, thời gian phản hồi hoặc tốc độ tải trang.
• Đo lường tình trạng ứng dụng: Quan sát tỷ lệ lỗi, tính khả dụng của dịch vụ hoặc độ dài hàng đợi.
• Theo dõi kết quả kinh doanh: Theo dõi các KPI như đơn hàng, đăng nhập hoặc tỷ lệ giao dịch thành công.

Bằng cách tích hợp những dữ liệu này vào số liệu giám sát, các nhà phát triển có thể cải thiện khả năng xử lý sự cố, xác định các điểm nghẽn về hiệu suất và liên kết các vấn đề của ứng dụng với tác động trực tiếp tới trải nghiệm người dùng.

Cấu hình số liệu tùy chỉnh

Các nhà phát triển có thể tích hợp số liệu tùy chỉnh vào ứng dụng của họ bằng các thư viện như Micrometer (Java) hoặc Prometheus Client (Node.js).

Ví dụ Java - Số liệu tùy chỉnh với Micrometer

Các phụ thuộc trong pom.xml

<dependency>

    <groupId>io.micrometergroupId>

    <artifactId>micrometer-registry-prometheusartifactId>

    <version>1.9.0version>

dependency>

Configuration in Code

@Configuration

public class MetricsConfig {

    @Bean

    public MeterRegistry meterRegistry() {

        return new PrometheusMeterRegistry(PrometheusConfig.DEFAULT);

    }

    @Bean

    public RestTemplate restTemplate() {

        return new RestTemplate();

    }

}

Custom Metric Example

@RestController

@RequestMapping("/api")

public class OrderController {

    private final Counter orderCounter;

    public OrderController(MeterRegistry meterRegistry) {

        this.orderCounter = Counter.builder("orders_total")

                .description("Total number of orders processed")

                .register(meterRegistry);

    }

    @PostMapping("/order")

    public ResponseEntity<String> createOrder(@RequestBody Map<String, String> request) {

        orderCounter.increment();

        return ResponseEntity.ok("Order Created");

    }

}

Sơ đồ này minh họa luồng dữ liệu tùy chỉnh trong ứng dụng Java sử dụng Micrometer, trong đó các số liệu được định nghĩa trực tiếp trong mã, đăng ký với MeterRegistry và hiển thị thông qua trên Grafana.

Ví dụ về Node.js - Dữ liệu tùy chỉnh với Prometheus Client

Cài đặt dependency: npm install prom-client

Cấu hình trong mã:

const express = require('express');

const client = require('prom-client');

const app = express();

const collectDefaultMetrics = client.collectDefaultMetrics;

collectDefaultMetrics();

const orderCounter = new client.Counter({

    name: 'orders_total',

    help: 'Total number of orders processed'

});

app.post('/order', (req, res) => {

    orderCounter.inc();

    res.send('Order Created');

});

app.get('/metrics', async (req, res) => {

    res.set('Content-Type', client.register.contentType);

    res.end(await client.register.metrics());

});

app.listen(3000, () => console.log('Server running on port 3000'));

Sơ đồ này minh họa cách các số liệu tùy chỉnh được xử lý trong ứng dụng Node.js bằng thư viện Prometheus Client, hiển thị dữ liệu thông qua các điểm cuối /metrics để theo dõi trong Grafana.

Cải thiện ví dụ Micrometer trong Java

1. Thêm biểu đồ Histogram để theo dõi độ trễ (latency)”

import io.micrometer.core.instrument.Timer;

import org.springframework.web.bind.annotation.*;

import io.micrometer.core.instrument.MeterRegistry;

@RestController

@RequestMapping("/api")

public class LatencyController {

    private final Timer requestTimer;

    public LatencyController(MeterRegistry meterRegistry) {

        this.requestTimer = Timer.builder("http_request_latency")

            .description("Tracks HTTP request latency in milliseconds")

            .publishPercentileHistogram()

            .register(meterRegistry);

    }

    @GetMapping("/process")

    public ResponseEntity<String> processRequest() {

        return requestTimer.record(() -> {

            try { Thread.sleep(200); } catch (InterruptedException e) {}

            return ResponseEntity.ok("Request Processed");

        });

    }

}

2. Thêm thước đó liệu cấp hệ thống

import io.micrometer.core.instrument.Gauge;

import io.micrometer.core.instrument.MeterRegistry;

import org.springframework.stereotype.Component;

import java.util.concurrent.atomic.AtomicInteger;

@Component

public class QueueSizeMetric {

    private final AtomicInteger queueSize = new AtomicInteger(0);

    public QueueSizeMetric(MeterRegistry meterRegistry) {

        Gauge.builder("queue_size", queueSize::get)

            .description("Tracks the current size of the task queue")

            .register(meterRegistry);

    }

    public void addToQueue() {

        queueSize.incrementAndGet();

    }

    public void removeFromQueue() {

        queueSize.decrementAndGet();

    }

}

Cải thiện ví dụ Node.js với các phương pháp gắn nhãn tối ưu nhất

Các phương pháp gắn nhãn được khuyến nghị

• Sử dụng nhãn có ý nghĩa: Tập trung vào các yếu tố quan trọng như mã trạng thái, điểm cuối (endpoint) hoặc vùng (region).
• Hạn chế nhãn có số lượng lớn: Tránh gán nhãn với các giá trị duy nhất, như user_id hoặc transaction_id, để giảm độ phức tạp và cardinality của số liệu.
• Sử dụng quy ước đặt tên nhất quán: Duy trì mẫu đặt tên thống nhất cho tất cả số liệu, giúp quản lý, truy vấn và phân tích dễ dàng hơn.

Cải thiện ví dụ về số liệu Node.js:

const client = require('prom-client');

const requestCounter = new client.Counter({

    name: 'http_requests_total',

    help: 'Total HTTP requests processed',

    labelNames: ['method', 'endpoint', 'status_code']

});

app.get('/checkout', (req, res) => {

    requestCounter.inc({ method: 'GET', endpoint: '/checkout', status_code: 200 });

    res.send('Checkout Complete');

});

Tích hợp với Flagger - Ví dụ về các chỉ số quan trọng trong kinh doanh

Ví dụ về truy vấn Prometheus để theo dõi lỗi thanh toán:

apiVersion: flagger.app/v1beta1

kind: MetricTemplate

metadata:

  name: checkout-failure-rate

  namespace: istio-system

spec:

  provider:

    type: prometheus

    address: http://prometheus.istio-system:9090

  query: |

    sum(rate(http_requests_total{job="checkout-service", status_code!="200"}[5m])) /

    sum(rate(http_requests_total{job="checkout-service"}[5m])) * 100

Giải thích

• Chỉ số này đo lường tỷ lệ phần trăm các giao dịch thanh toán thất bại, là một chỉ số then chốt phản ánh mức độ ổn định của nền tảng thương mại điện tử.
• Việc giám sát các chỉ số quan trọng này cung cấp cho các nhà phát triển những thông tin chuyên sâu, giúp họ kịp thời tối ưu hóa và nâng cao trải nghiệm người dùng.

Sơ đồ này minh họa cách Flagger giám sát các số liệu Prometheus của dịch vụ thanh toán, tự động kích hoạt khôi phục (rollback) thông qua Alert Manager và thông báo cho đội ngũ DevOps khi xảy ra sự cố.

Các phương pháp tối ưu nhất để cảnh báo dựa trên số liệu tùy chỉnh

• Xác định ngưỡng cảnh báo hợp lý, phản ánh đúng mức độ tác động đến hoạt động kinh doanh.
• Giảm thiểu cảnh báo dư thừa bằng cách tối ưu hóa khoảng thời gian đánh giá và kích hoạt cảnh báo.
• Sử dụng Prometheus AlertManager để phát đi cảnh báo chủ động khi hiệu suất dịch vụ bị suy giảm.

Kết luận

Khả năng quan sát toàn diện trong môi trường Kubernetes, tuy là thách thức, nhưng lại là yếu tố then chốt để đảm bảo hiệu suất, bảo mật và tính ổn định của ứng dụng. Bằng cách triển khai đồng bộ các công cụ giám sát và áp dụng các phương pháp tối ưu, các nhà phát triển có thể nâng cao đáng kể khả năng quan sát trên toàn bộ hệ thống microservices.

Tracestore cho phép theo dõi luồng yêu cầu giữa các dịch vụ, hỗ trợ phân tích nguyên nhân gốc rễ và xác định các điểm nghẽn hiệu suất. OPA thực thi các chính sách truy cập động, đảm bảo quản lý truy cập nhất quán và bảo vệ tính toàn vẹn dữ liệu. Flagger tự động hóa quá trình triển khai theo tiến trình, giảm thiểu rủi ro thông qua điều phối lưu lượng có kiểm soát, đánh giá dựa trên số liệu và khôi phục chủ động khi cần thiết. Custom Metrics cung cấp các số liệu chuyên sâu về hành vi ứng dụng, liên kết giám sát hiệu suất với các mục tiêu kinh doanh, từ đó hỗ trợ ra quyết định chính xác hơn.

Bằng cách kết hợp các công cụ này, các nhà phát triển có thể xây dựng khối lượng công việc Kubernetes linh hoạt, có khả năng mở rộng và bảo mật. Việc áp dụng các phương pháp hay nhất như truyền phát theo dõi hiệu quả, thiết kế chính sách Rego chu đáo, cấu hình Flagger chiến lược và các số liệu tùy chỉnh được xác định rõ ràng sẽ đảm bảo môi trường Kubernetes của bạn có thể đáp ứng nhu cầu hiệu suất và các mục tiêu kinh doanh đang phát triển.

Việc áp dụng những giải pháp quan sát này giúp các nhóm phát triển chuyển từ xử lý sự cố phản ứng sang tối ưu hóa chủ động, từ đó tăng cường độ tin cậy hệ thống và cải thiện trải nghiệm người dùng.