​
Mục tiêu

Tài liệu này triển khai bộ test thực thi cho mô hình:
  • Agent 1..N -> Forwarder 1 -> Forwarder 2 -> BlackHole Database -> Dashboard
  • Trọng tâm chính: E2E latency (p50/p95/p99).
  • Trọng tâm phụ: performance baseline (throughput, CPU/RAM, queue behavior) và resilience.

​
Kiến trúc đo kiểm

​
KPI và tiêu chí pass/fail

​
Latency KPI

  • E2E latency:
    • event_emit_ts tại Agent
    • event_search_hit_ts tại Dashboard
    • Công thức: e2e_ms = event_search_hit_ts - event_emit_ts
  • Stage latency:
    • Agent -> Forwarder1
    • Forwarder1 -> Forwarder2
    • Forwarder2 -> Database ingest
    • Database ingest -> Dashboard searchable

​
Performance KPI

  • Throughput ổn định (events/s) ở 3 mức tải: low, medium, high.
  • CPU/RAM từng node: Agent, Forwarder1, Forwarder2, Database.
  • Error profile:
    • retry rate
    • timeout rate
    • drop rate
    • duplicate rate
  • Queue profile:
    • channel buffer saturation
    • inventory usage (max_messages, max_bytes)
    • backlog recovery time

​
Pass/Fail vòng 1 (baseline)

  • Không drop event tại baseline load.
  • shipper/request error rate < 0.1%.
  • Độ lệch p95 giữa 3 lần chạy cùng điều kiện < 20%.
  • Không có backlog kéo dài quá 2 x batch_interval sau khi kết thúc burst.

​
Chuẩn bị dữ liệu và observability

​
1) Chuẩn dữ liệu test

Mỗi event nên có các trường bắt buộc:
  • event_id: UUID duy nhất.
  • agent_id: định danh Agent.
  • event_type: auth, syslog, apm, sca, …
  • event_size_class: small, medium, large.
  • emit_ts: timestamp phát sinh tại Agent.
  • sequence: số thứ tự để kiểm tra thiếu/lặp.
Khuyến nghị kích thước payload:
  • small: 0.5-1 KB.
  • medium: 2-4 KB.
  • large: 8-16 KB.

​
2) Nguồn metrics và logs cần thu thập

  • Agent/Forwarder logs ở mức info (chuyển debug khi phân tích bottleneck).
  • Host metrics chu kỳ 10s:
    • CPU, RAM, network Rx/Tx, disk I/O
  • Pipeline metrics:
    • queue depth
    • in-flight requests
    • retry/timeouts
    • inventory depth

​
3) Đồng bộ thời gian

  • Bắt buộc đồng bộ clock giữa tất cả nodes (NTP hoặc tương đương).
  • Nếu lệch clock > 100ms, không dùng kết quả cho latency KPI.

​
Kịch bản test chi tiết

​
A. Baseline latency (happy path)

Mục tiêu: lấy đường cơ sở latency theo tải nhẹ/trung bình/cao. Thiết lập ban đầu:
  • Agent gRPC sink:
    • use_streaming: true
    • max_concurrent_requests: 1
  • Forwarder:
    • giữ mặc định rate_limit và channel_buffers.
  • Workload:
    • 2k events/s (low)
    • 5k events/s (medium)
    • 10k events/s (high)
Trình tự chạy:
  1. Warm-up 5 phút.
  2. Chạy mỗi mức tải 15 phút.
  3. Lặp lại 3 lần cho mỗi mức tải.
  4. Lưu p50/p95/p99 và stage latency.
Kết quả cần có:
  • Bảng latency distribution theo tải.
  • Điểm bắt đầu tăng p95/p99 rõ rệt.

​
B. Sensitivity latency tuning

Mục tiêu: tìm cấu hình low-latency và balanced-throughput. Nguyên tắc:
  • Mỗi lần chỉ thay 1 biến.
  • Giữ workload cố định ở mức medium trong lúc đo sensitivity.
Ma trận biến:
  • rate_limit.batch_size: 100 / 500 / 1000
  • rate_limit.batch_interval: 50 / 200 / 1000 ms
  • max_concurrent_requests: 1 / 2 / 4 / 8
  • router_max_in_flight_routes: 2 / 4 / 8
  • tcp_nodelay: on / off (nơi có hỗ trợ)
Kết quả cần có:
  • Tương quan latency p95/p99 với CPU cost.
  • 2 cấu hình đề xuất:
    • profile low-latency
    • profile balanced

​
C. Performance baseline (throughput vs resource)

Mục tiêu: xác định ngưỡng throughput ổn định và knee point. Trình tự chạy:
  1. Bắt đầu từ 30% tải baseline.
  2. Tăng tải theo bậc thang mỗi 10 phút.
  3. Dừng tăng khi xuất hiện 1 trong các điều kiện:
    • queue tăng liên tục không hồi phục
    • timeout/retry tăng đột ngột
    • p99 latency tăng > 2 lần so với bậc trước
Đầu ra:
  • Throughput tối đa ổn định.
  • Knee point và nguyên nhân nghẽn chính (CPU, network, queue, DB ingest).

​
D. Burst latency/performance

Mục tiêu: kiểm tra khả năng hấp thụ đột biến. Kịch bản:
  • Nền: 30% tải đỉnh ổn định.
  • Burst: 3x đến 5x trong 30-60 giây, lặp lại mỗi 5 phút.
  • Thời lượng toàn test: 60 phút.
Đánh giá:
  • p99 trong burst và sau burst.
  • Thời gian hồi về steady-state.
  • Có drop/duplicate hay không.

​
E. Resilience impact on latency

Mục tiêu: đo ảnh hưởng latency khi lỗi hạ tầng/dịch vụ. Fault scenarios:
  1. Mất kết nối Forwarder1 <-> Forwarder2 trong 30, 60, 120 giây.
  2. Database chậm (thêm delay hoặc giới hạn băng thông).
  3. Restart 1 Forwarder khi đang chạy medium load.
Đánh giá:
  • Backlog growth.
  • Recovery time về steady-state.
  • Có replay đầy đủ từ inventory/queue không.

​
Lịch chạy đề xuất (2 ngày)

Ngày 1:
  1. Setup observability + dữ liệu test + clock sync.
  2. Chạy Baseline latency.
  3. Chạy Sensitivity tuning.
Ngày 2:
  1. Chạy Performance baseline.
  2. Chạy Burst test.
  3. Chạy Resilience test.
  4. Tổng hợp report và cấu hình đề xuất.

​
Mẫu kết quả cần bàn giao

  1. Test spec:
    • test ID
    • objective
    • input load
    • runtime
    • config delta
  2. KPI dashboard export:
    • p50/p95/p99
    • throughput
    • error/drop/retry
    • CPU/RAM
  3. Decision sheet:
    • profile low-latency
    • profile balanced-throughput
  4. Risk list + vòng 2:
    • stress test sâu hơn
    • soak test 24h

​
Phụ lục: checklist trước khi chạy

  • Tất cả node đồng bộ NTP.
  • Agent/Forwarder dùng cấu hình cố định cho baseline (không thay ngoài kế hoạch).
  • Dashboard query filter đúng theo event_id và time window.
  • Có cơ chế lưu raw kết quả cho từng lần chạy.
  • Chỉ thay duy nhất biến được chỉ định trong sensitivity matrix.