k6 Grafana: Kiểm thử tải phân tán & phân tích hiệu suất

Tôi từng kiểm tra API của mình bằng cách gửi một curl nhanh hoặc chạy một tập lệnh tải cơ bản từ máy tính xách tay của mình. Mọi thứ đều ổn—cho đến khi chúng tôi có một chiến dịch tiếp thị lớn và cơ sở dữ liệu ngay lập tức sập.

Việc tìm ra điểm yếu của hệ thống trước khi người dùng của bạn phát hiện ra là rất quan trọng. Đó là lúc tôi chuyển sang k6, Grafana và Prometheus. Bộ công cụ này cung cấp cho bạn một cách thân thiện với nhà phát triển để viết kịch bản kiểm thử phân tán bằng JavaScript, truyền các số liệu độ trễ theo thời gian thực và thực sự xem máy chủ của bạn bị tắc nghẽn ở đâu khi bạn gửi 50.000 người dùng ảo đồng thời đến chúng.

Tại sao các tập lệnh tải cục bộ không đủ

Nếu bạn đang chạy một trình tạo tải từ một máy duy nhất, bạn thường sẽ làm tắc nghẽn mạng cục bộ hoặc CPU của chính mình trước khi bạn gây áp lực lên máy chủ backend. Khi kiểm thử các microservice hiện đại, bạn cần phân phối tải người dùng ảo trên nhiều nút worker.

Tôi yêu k6 vì nó được xây dựng bằng Go và sử dụng công cụ JavaScript V8 nhúng. Nó có dung lượng bộ nhớ nhỏ. Không giống như các công cụ dựa trên Java cũ hơn tạo ra một luồng OS nặng cho mỗi người dùng ảo, k6 sử dụng goroutine. Một phiên bản 4-vCPU duy nhất có thể tạo ra hơn 30.000 yêu cầu mỗi giây một cách thoải mái.

// Example: Basic k6 load testing script with custom thresholds and checks
import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '30s', target: 50 },  // Ramp-up to 50 Virtual Users
    { duration: '1m', target: 200 },  // Stay at 200 VUs for peak load test
    { duration: '30s', target: 0 },   // Ramp-down to 0 VUs
  ],
  thresholds: {
    http_req_duration: ['p(95)<250', 'p(99)<500'], // 95% of requests must complete under 250ms
    http_req_failed: ['rate<0.01'],                 // Error rate must remain under 1%
  },
};

export default function () {
  const res = http.get('https://api.example.com/v1/catalog');
  
  check(res, {
    'status is 200': (r) => r.status === 200,
    'response body contains catalog': (r) => r.body.includes('products'),
  });

  sleep(1); // Simulating realistic user think-time between requests
}

Hiểu kiến trúc goroutine này giải thích tại sao k6 mang lại hiệu quả tính toán vượt trội so với các trình tạo tải GUI cũ. Tuy nhiên, khi thông lượng mục tiêu vượt quá 100.000 yêu cầu mỗi giây, việc tạo tải phân tán bằng cách sử dụng k6-operator trên Kubernetes trở nên bắt buộc để phân phối việc tạo socket mạng trên nhiều nút worker.

# Kubernetes Spec: Distributed load test using k6-operator Custom Resource
apiVersion: k6.io/v1alpha1
kind: K6
metadata:
  name: distributed-black-friday-test
  namespace: load-testing
spec:
  parallelism: 4 # Spawns 4 parallel worker pods running k6
  script:
    configMap:
      name: k6-test-scripts
      file: load-test.js
  arguments: --tag testid=black-friday-sim
  runner:
    resources:
      limits:
        cpu: "2"
        memory: "2Gi"
      requests:
        cpu: "1"
        memory: "1Gi"

k6-operator tự động quản lý vòng đời của các pod runner, chia phạm vi lặp thực thi, tổng hợp nhật ký kịch bản và truyền dữ liệu đo từ xa hiệu suất theo thời gian thực đến hệ thống giám sát trung tâm của bạn.

Ngoài các API HTTP tiêu chuẩn, các ứng dụng thời gian thực hiện đại cũng giao tiếp qua các giao thức WebSockets và gRPC. k6 hỗ trợ nguyên bản việc kiểm thử các dịch vụ gRPC bằng cách sử dụng bộ đệm giao thức, cũng như kiểm thử các luồng WebSocket hai chiều. Tính linh hoạt này cho phép các nhóm kỹ thuật kiểm thử tải các máy chủ trò chuyện thời gian thực, truyền thông báo đẩy và các nền tảng giao dịch tần số cao trong một API kịch bản thống nhất.

// Example: Testing gRPC endpoints under load using k6/net/grpc
import grpc from 'k6/net/grpc';
import { check, sleep } from 'k6';

const client = new grpc.Client();
client.load(['definitions'], 'user_service.proto');

export const options = {
  vus: 50,
  duration: '1m',
};

export default function () {
  client.connect('grpc.example.com:443', { plaintext: false });

  const response = client.invoke('user.UserService/GetUserProfile', { userId: 101 });
  check(response, {
    'status is OK': (r) => r && r.status === grpc.StatusOK,
  });

  client.close();
  sleep(1);
}

Cách viết kịch bản k6 tùy chỉnh với ngưỡng và kiểm tra?

Viết kịch bản kiểm thử hiệu suất k6 nâng cao yêu cầu xác định các kịch bản thực thi tùy chỉnh mô hình hóa hành vi người dùng thực tế, các đợt tăng đột biến lưu lượng truy cập và các chuỗi quy trình làm việc API. Sử dụng scenarios của k6, các nhà phát triển có thể kết hợp các mẫu lưu lượng truy cập riêng biệt trong một lần chạy kiểm thử duy nhất.

k6 hỗ trợ một số mô hình thực thi kịch bản, bao gồm ramping-arrival-rate, constant-vus và per-vu-iterations. Trình thực thi ramping-arrival-rate đặc biệt có giá trị vì nó duy trì tốc độ yêu cầu cố định mỗi giây bất kể phản hồi của máy chủ mục tiêu chậm đến mức nào, ngăn chặn các đợt tăng đột biến độ trễ mục tiêu làm giảm thông lượng của trình tạo tải một cách giả tạo.

// Advanced multi-scenario k6 load test script
import http from 'k6/http';
import { check, group, sleep } from 'k6';
import { Rate, Trend } from 'k6/metrics';

// Custom Prometheus metrics registered in k6
const checkoutErrorRate = new Rate('checkout_failure_rate');
const DBProcessingTrend = new Trend('db_query_duration_ms');

export const options = {
  scenarios: {
    constant_browsing: {
      executor: 'constant-vus',
      vus: 100,
      duration: '3m',
    },
    checkout_spike: {
      executor: 'ramping-arrival-rate',
      startRate: 10,
      timeUnit: '1s',
      preAllocatedVUs: 50,
      maxVUs: 300,
      stages: [
        { duration: '1m', target: 50 },  // 50 checkouts/sec
        { duration: '2m', target: 200 }, // Spike to 200 checkouts/sec
      ],
    },
  },
  thresholds: {
    'checkout_failure_rate': ['rate<0.005'], // Checkout errors must stay under 0.5%
    'http_req_duration{scenario:checkout_spike}': ['p(95)<400'],
  },
};

export default function () {
  group('Browsing Catalog', function () {
    const res = http.get('https://api.example.com/v1/products');
    check(res, { 'catalog status 200': (r) => r.status === 200 });
  });

  group('Executing Checkout', function () {
    const payload = JSON.stringify({ cartId: 'cart_9912', paymentToken: 'tok_test' });
    const params = { headers: { 'Content-Type': 'application/json' } };
    
    const res = http.post('https://api.example.com/v1/checkout', payload, params);
    const success = check(res, { 'checkout success': (r) => r.status === 201 });
    
    checkoutErrorRate.add(!success);
    if (res.headers['X-DB-Duration']) {
      DBProcessingTrend.add(parseFloat(res.headers['X-DB-Duration']));
    }
  });

  sleep(2);
}

Đăng ký các số liệu tùy chỉnh như Rate và Trend cho phép các nhà phát triển thu thập các chỉ số hiệu suất miền kinh doanh cùng với thời lượng yêu cầu HTTP tiêu chuẩn. Bằng cách gắn thẻ các số liệu bằng các định danh kịch bản, bảng điều khiển Grafana có thể cô lập độ trễ giao dịch thanh toán khỏi độ trễ duyệt danh mục đơn giản.

Sử dụng các trình thực thi tốc độ đến đảm bảo rằng thời gian phản hồi backend chậm không khiến trình chạy kiểm thử giảm việc tạo yêu cầu. Phương pháp kiểm thử mô hình mở này mô phỏng chính xác các đợt tăng đột biến lưu lượng truy cập của người dùng trong thế giới thực.

// Parameterizing test dataset inputs using SharedArray in k6
import { SharedArray } from 'k6/data';

const userCredentials = new SharedArray('user credentials pool', function () {
  // SharedArray parses heavy JSON fixtures once into shared V8 memory
  return JSON.parse(open('data/users.json'));
});

export default function () {
  const user = userCredentials[Math.floor(Math.random() * userCredentials.length)];
  const res = http.post('https://api.example.com/v1/login', JSON.stringify(user), {
    headers: { 'Content-Type': 'application/json' },
  });
  check(res, { 'login ok': (r) => r.status === 200 });
}

Làm thế nào để bạn truyền số liệu k6 đến Prometheus và Grafana?

Truyền dữ liệu đo từ xa hiệu suất theo thời gian thực từ k6 vào Prometheus và Grafana cung cấp thông tin chi tiết trực quan tức thì về hành vi của máy chủ trong khi các kiểm thử tải đang thực thi tích cực. k6 hỗ trợ các giao thức Ghi từ xa nguyên bản, xuất các mẫu số liệu trực tiếp đến các điểm cuối Prometheus hoặc VictoriaMetrics mà không yêu cầu các tác nhân thu thập sidecar bên ngoài.

Cấu hình công cụ đầu ra Prometheus của k6 yêu cầu truyền các cờ dòng lệnh hoặc đặt các biến môi trường trong quá trình thực thi kiểm thử. k6 định dạng các số liệu dưới dạng các kiểu dữ liệu Prometheus gauge, counter và summary tiêu chuẩn.

# Executing k6 test with direct Prometheus Remote Write output integration
K6_PROMETHEUS_REMOTE_URL="http://prometheus.monitoring.svc:9090/api/v1/write" \
K6_PROMETHEUS_FLUSH_INTERVAL="2s" \
k6 run \
  -o experimental-prometheus-rw \
  --tag test_run_id="build-4091" \
  load-test.js

Khi k6 truyền chuỗi số liệu đến Prometheus, bảng điều khiển Grafana có thể thực hiện các truy vấn PromQL để vẽ biểu đồ thông lượng yêu cầu, tỷ lệ lỗi và độ trễ phần trăm cùng với các số liệu cơ sở hạ tầng máy chủ như mức sử dụng CPU, bộ nhớ RSS và độ bão hòa của nhóm kết nối cơ sở dữ liệu.

# PromQL Query Examples for Grafana Dashboard Panels

# 1. Real-time Requests Per Second (RPS) by HTTP Status Code
sum(rate(k6_http_reqs_total[30s])) by (status)

# 2. 95th Percentile Response Latency in Milliseconds by Endpoint Path
histogram_quantile(0.95, sum(rate(k6_http_req_duration_bucket[1m])) by (le, expected_response, url))

# 3. Virtual User (VU) Active Worker Count Over Time
k6_vus_active

# 4. Custom Error Rate Percentage
(sum(rate(k6_checkout_failure_rate_total{result="true"}[1m])) / sum(rate(k6_checkout_failure_rate_total[1m]))) * 100

Việc tương quan độ trễ phản hồi phía máy khách của k6 với các số liệu điều tiết CPU của pod Kubernetes trong Grafana giúp dễ dàng chẩn đoán chính xác các nút thắt cổ chai của hệ thống. Khi độ trễ yêu cầu phần trăm thứ 95 tăng đột biến đồng thời với độ sâu hàng đợi nhóm kết nối cơ sở dữ liệu, các nhà phát triển có thể xác định khóa cơ sở dữ liệu là nguyên nhân gốc rễ chứ không phải giới hạn CPU của máy chủ web.

// Grafana Panel JSON Snippet: 95th Percentile Latency Alert Rule
{
  "title": "95th Percentile API Latency Alert",
  "type": "timeseries",
  "targets": [
    {
      "expr": "histogram_quantile(0.95, sum(rate(k6_http_req_duration_bucket[1m])) by (le))",
      "legendFormat": "p95 latency (ms)"
    }
  ],
  "fieldConfig": {
    "defaults": {
      "thresholds": {
        "mode": "absolute",
        "steps": [
          { "color": "green", "value": null },
          { "color": "yellow", "value": 250 },
          { "color": "red", "value": 500 }
        ]
      }
    }
  }
}

Cấu hình cảnh báo Grafana tự động kích hoạt thông báo Slack hoặc PagerDuty ngay lập tức bất cứ khi nào độ trễ kiểm thử tải vi phạm giới hạn SLA trong quá trình chạy đường ống CI.

Làm thế nào để phân tích các nút thắt cổ chai độ trễ dưới sự đồng thời cao?

Phân tích các nút thắt cổ chai độ trễ dưới sự đồng thời của người dùng ảo cao yêu cầu phân tích các dấu vết thực thi phía máy chủ cùng với các đầu ra số liệu k6. Khi các kiểm thử tải phơi bày các đợt tăng đột biến độ trễ đuôi không mong muốn ở phần trăm thứ 99, các nhà phát triển phải cô lập xem các nút thắt cổ chai có bắt nguồn từ khóa truy vấn cơ sở dữ liệu, thiếu hụt luồng CPU hay tạm dừng thu gom rác hay không.

Việc truyền tiêu đề theo dõi phân tán kết nối các lần lặp kiểm thử k6 với các công cụ theo dõi ứng dụng backend như OpenTelemetry, Jaeger hoặc Grafana Tempo. Việc chèn tiêu đề W3C Trace Context (traceparent) vào các yêu cầu HTTP của k6 cho phép các nhà phát triển theo dõi các yêu cầu k6 chậm riêng lẻ thông qua các chuỗi gọi microservice phức tạp.

// k6 script injecting OpenTelemetry Trace Context headers for request tracing
import http from 'k6/http';
import { check } from 'k6';
import crypto from 'k6/crypto';

function generateTraceparent() {
  const version = '00';
  const traceId = crypto.hexDigest('sha256', `${Math.random()}`).substring(0, 32);
  const parentId = crypto.hexDigest('sha256', `${Math.random()}`).substring(0, 16);
  const flags = '01'; // Sampled flag enabled
  return `${version}-${traceId}-${parentId}-${flags}`;
}

export default function () {
  const params = {
    headers: {
      'Content-Type': 'application/json',
      'traceparent': generateTraceparent(), // Propagate trace header to backend
    },
  };

  const res = http.get('https://api.example.com/v1/orders/recent', params);
  check(res, { 'status is 200': (r) => r.status === 200 });
}

Khi phân tích các microservice Go hoặc Node.js dưới tải, việc phân tích pprof liên tục thu thập các phân bổ heap V8 và biểu đồ ngọn lửa CPU trong các khoảng thời gian tải cao điểm. So sánh các cấu hình CPU pprof được thu thập ở tải cơ bản với các cấu hình được thu thập dưới tải 200 VU làm nổi bật các chức năng chính xác tiêu thụ chu kỳ CPU.

# Executing Go pprof CPU profile during k6 load test run
go tool pprof -http=:8081 http://backend-service:6060/debug/pprof/profile?seconds=30

Phân tích dữ liệu kiểm thử tải thực nghiệm được thu thập trong các lần chạy 500 VU đã tiết lộ ba nguyên nhân chính gây suy giảm độ trễ trong kiến trúc microservice: các truy vấn JOIN cơ sở dữ liệu không được lập chỉ mục, chi phí tuần tự hóa JSON quá mức và thiếu hụt nhóm luồng trong các vòng lặp sự kiện không đồng bộ. Khắc phục ba vấn đề này đã giảm độ trễ phản hồi phần trăm thứ 99 từ 1.200 ms xuống 85 ms dưới tải lưu lượng truy cập giống hệt nhau.

// Example: Node.js Express server middleware tracking internal execution stages
import { Request, Response, NextFunction } from 'express';

export function performanceHeaderMiddleware(req: Request, res: Response, next: NextFunction) {
  const start = process.hrtime();
  
  res.on('finish', () => {
    const diff = process.hrtime(start);
    const timeInMs = (diff[0] * 1e3 + diff[1] * 1e-6).toFixed(2);
    // Expose internal server processing time in header for k6 analysis
    res.setHeader('X-Server-Execution-Time', `${timeInMs}ms`);
  });
  
  next();
}

Các nhóm nên tự động hóa kiểm thử tải trong triển khai liên tục như thế nào?

Tự động hóa kiểm thử hiệu suất trong các đường ống triển khai liên tục ngăn chặn các commit hồi quy hiệu suất đến sản xuất. Chạy kiểm thử khói k6 tự động trên mọi yêu cầu kéo và kiểm thử tải hồi quy đầy đủ hàng đêm thiết lập các cổng an toàn hiệu suất cho các bản phát hành phần mềm.

Tích hợp k6 vào GitHub Actions hoặc GitLab CI bao gồm việc thực thi các bước CLI k6 không đầu và đánh giá mã thoát dựa trên các tiêu chí ngưỡng đã xác định. Nếu bất kỳ ngưỡng SLA nào không đạt (chẳng hạn như độ trễ phần trăm thứ 95 vượt quá 300 ms), k6 sẽ thoát với mã 99, tự động làm hỏng bản dựng đường ống CI.

# GitHub Actions workflow executing automated k6 performance regression gate
name: Performance Testing Gate
on:
  pull_request:
    branches: [main]

jobs:
  k6-load-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Pull k6 Docker Image
        run: docker pull grafana/k6:latest

      - name: Run k6 Load Test
        run: |
          docker run --rm \
            -v $(pwd):/ci \
            -w /ci \
            grafana/k6:latest run \
            --thresholds "http_req_duration=p(95)<300" \
            e2e/load-tests/smoke-test.js

Việc thiết lập các cổng hiệu suất tự động thay đổi văn hóa kỹ thuật của nhóm. Thay vì phát hiện lỗi mở rộng quy mô trong các sự kiện quảng cáo lớn, các hồi quy hiệu suất được đưa ra và giải quyết trong quá trình xem xét yêu cầu kéo phát triển tính năng.

Kết hợp kiểm thử tải k6 với bảng điều khiển Grafana và cảnh báo Prometheus cung cấp một bộ công cụ kỹ thuật hiệu suất toàn diện. Bằng cách viết kịch bản các tình huống lưu lượng truy cập thực tế, truyền dữ liệu đo từ xa theo thời gian thực và tự động hóa các cổng ngưỡng trong CI, các nhóm có thể mở rộng quy mô các ứng dụng web hiện đại với sự tự tin hoàn toàn.

Thường xuyên thực hiện các kiểm thử tải tự động đối với môi trường staging xây dựng bộ nhớ cơ bắp của tổ chức xung quanh việc quản lý dung lượng. Các kỹ sư cơ sở hạ tầng và nhà phát triển phần mềm chia sẻ các số liệu hiệu suất thống nhất, đảm bảo hệ thống vẫn kiên cường dưới nhu cầu lưu lượng truy cập cao.

Duy trì các tập lệnh kiểm thử tải tự động trong các kho lưu trữ ứng dụng cùng với mã tính năng đảm bảo rằng các kịch bản kiểm thử phát triển đồng bộ với các điểm cuối API. Các nhóm có thể tối ưu hóa an toàn việc lập chỉ mục cơ sở dữ liệu, cập nhật cấu hình bộ đệm và tái cấu trúc giao diện microservice với xác thực hiệu suất dựa trên dữ liệu.

Thiết lập các kiểm thử ngâm theo lịch trình chạy trong sáu đến mười hai giờ sẽ làm lộ ra các rò rỉ bộ nhớ tinh vi, rò rỉ nhóm kết nối và các xử lý mô tả tệp chưa đóng mà các kiểm thử tải ngắn ba phút bỏ lỡ. Tự động hóa các kiểm thử ngâm trong môi trường xây dựng ban đêm cung cấp các đảm bảo chi tiết về tình trạng hệ thống.

Sử dụng báo cáo kiểm thử hiệu suất trong các đánh giá sau sự cố tạo ra sự minh bạch giữa các nhóm cơ sở hạ tầng và phát triển. Việc ghi lại các đường cơ sở thông lượng trước và sau khi di chuyển cơ sở hạ tầng đảm bảo rằng các thay đổi kiến trúc mang lại lợi ích hiệu suất thực sự cho người dùng cuối.

Đánh giá dữ liệu đo từ xa hiệu suất trên các phiên bản phát hành tuần tự giúp các trưởng nhóm kỹ thuật xác định sự suy giảm hiệu suất dần dần trước khi giới hạn hệ thống bị vi phạm trong môi trường sản xuất.

Bạn cũng có thể thích

• Kiểm thử hợp đồng Microservices với Pact & Node.js
• Kiểm thử E2E Playwright: 4 quy tắc cho các kiểm thử không lỗi
• Các lựa chọn thay thế Playwright tốt nhất cho tự động hóa doanh nghiệp
• Playwright vs Selenium cho tự động hóa trình duyệt doanh nghiệp

Câu hỏi thường gặp

Grafana k6 là gì và tại sao nó được sử dụng để kiểm thử tải?

Grafana k6 là một công cụ kiểm thử tải mã nguồn mở, hướng đến nhà phát triển, được viết bằng Go với kịch bản kiểm thử JavaScript. Nó được thiết kế cho hiệu suất cao và tiêu thụ tài nguyên thấp, cho phép các nhà phát triển mô phỏng hàng nghìn người dùng ảo đồng thời trên phần cứng tối thiểu trong khi kiểm thử các API REST, GraphQL và WebSocket.

k6 truyền các số liệu theo thời gian thực đến Grafana như thế nào?

k6 truyền dữ liệu đo từ xa trực tiếp đến Prometheus hoặc Grafana Mimir bằng cách sử dụng bộ xuất đầu ra Prometheus Remote Write (-o experimental-prometheus-rw). Prometheus lưu trữ các số liệu, cho phép bảng điều khiển Grafana vẽ biểu đồ thông lượng yêu cầu, tỷ lệ lỗi và độ trễ phần trăm theo thời gian thực.

Sự khác biệt giữa VUs và tốc độ đến trong k6 là gì?

Người dùng ảo (VUs) đại diện cho các luồng thực thi đồng thời mô phỏng các phiên người dùng. Tốc độ đến (ramping-arrival-rate) chỉ định một số lượng yêu cầu HTTP cố định mỗi giây bất kể thời gian phản hồi của máy chủ, ngăn chặn các phản hồi backend chậm làm giảm thông lượng của trình tạo tải.

Các ngưỡng k6 tự động hóa các cổng lỗi bản dựng CI như thế nào?

thresholds của k6 xác định các quy tắc đạt và không đạt hiệu suất (chẳng hạn như p(95)<250ms hoặc http_req_failed<1%). Nếu bất kỳ ngưỡng nào bị vi phạm trong quá trình thực thi, k6 sẽ thoát với mã 99, báo hiệu các công cụ CI như GitHub Actions hoặc GitLab CI tự động làm hỏng bản dựng.

Các kiểm thử k6 có thể được phân phối trên nhiều máy không?

Có, các kiểm thử k6 có thể được phân phối trên các cụm Kubernetes bằng cách sử dụng k6-operator. Trình điều hành tạo ra các pod runner worker song song, tự động chia các lần lặp tải và tổng hợp dữ liệu đo từ xa hiệu suất vào các phiên bản Prometheus và Grafana trung tâm.

Làm cách nào để truyền các mã thông báo xác thực tùy chỉnh vào các tập lệnh k6?

Các mã thông báo xác thực tùy chỉnh có thể được truyền vào các tập lệnh k6 thông qua các biến môi trường (__ENV.AUTH_TOKEN) hoặc được tạo động bên trong tập lệnh bằng cách sử dụng các lệnh gọi xác thực http.post() trước khi hàm kịch bản người dùng ảo chính thực thi.