Tôi đã hoàn thành 12 Dashboard SigNoz trong 4 ngày: Cách tối ưu hóa 864 Panel và 134K dòng code

Tôi đã hoàn thành 12 Pull Request (PR) cho các dashboard SigNoz trong vòng 4 ngày — với tổng cộng 864 panel và 134K dòng JSON. Dưới đây là kiến trúc kỹ thuật đã giúp tôi thực hiện được điều này.

Tại sao lại chọn SigNoz?

SigNoz là một nền tảng observability (giám sát và quan sát) mã nguồn mở, dựa trên OpenTelemetry, đang phát triển vô cùng mạnh mẽ. Hệ thống mẫu dashboard của họ sử dụng một lược đồ JSON rất cụ thể; khi bạn đã hiểu rõ nó, nó sẽ trở thành một "nhà máy" sản xuất các cấu hình giám sát.

Sự thật thú vị là SigNoz thưởng cho nhiều người đóng góp cho mỗi vấn đề (issue) về dashboard. Không giống như các chương trình tiền thưởng (bounty) thông thường nơi người "merge" đầu tiên sẽ chiến thắng toàn bộ, ở đây các bài nộp chất lượng đều được trả công. Điều này thay đổi hoàn toàn cách tiếp cận kinh tế của việc đóng góp mã nguồn.

Schema JSON của Dashboard SigNoz

Mọi dashboard SigNoz đều tuân theo cấu trúc sau:

{
  "title": "Kafka Server Monitoring",
  "description": "Comprehensive monitoring for Apache Kafka brokers",
  "tags": ["kafka", "messaging", "prometheus"],
  "layout": [
    {
      "id": "panel-uuid",
      "x": 0, "y": 0, "w": 6, "h": 2,
      "panelTypes": "graph"
    }
  ],
  "widgets": [
    {
      "id": "panel-uuid",
      "title": "Broker Active Controller Count",
      "description": "Should always be exactly 1 in a healthy cluster",
      "panelTypes": "value",
      "queryData": {
        "queryType": "builder",
        "promQL": "kafka_controller_active_controller_count"
      }
    }
  ]
}

Mảng layout kiểm soát vị trí trên lưới (grid 12 cột). Mảng widgets chứa các định nghĩa panel thực tế. Mọi widget đều cần một mục tương ứng trong layout.

Cuộc chạy đua 4 ngày với 12 Dashboard

Dưới đây là bảng tổng kết thành quả trong 4 ngày làm việc:

PR	Công nghệ	Panels	Dòng code	Chỉ số quan trọng
#290	ASP.NET Core (OTLP)	~60	9K	Thời gian request, tỷ lệ ngoại lệ, áp lực GC
#291	Istio Service Mesh	~70	11K	Độ trễ proxy, kích hoạt cầu chì (circuit breaker), trạng thái mTLS
#295	CloudNativePG	87	13K	Độ trễ replication, kích thước WAL, pool kết nối
#296	cert-manager	90	13K	Hết hạn chứng chỉ, lỗi ACME, tỷ lệ gia hạn
#298	Kafka Server	138	21K	Sức khỏe Broker, lệch phân vùng (partition skew), độ trễ consumer
#299	Kong Gateway	97	14K	Độ trễ upstream, hit rate limiting, lỗi plugin
#300	AWS MSK	103	18K	Throughput cluster, sử dụng đĩa, đồng bộ Zookeeper
#301	OTel Collector	98	15K	Lỗi pipeline, span bị bỏ sót, hàng đợi exporter
#302	PostgreSQL (fix)	2	200	Phân chia kết nối Idle và Active
#303	Keycloak	56	10K	Thất bại đăng nhập, tỷ lệ cấp token, phiên realm
#304	Apache Spark	63	10K	Bộ nhớ Executor, shuffle spill, thời gian stage

Tổng cộng: 864 panel, 134K dòng JSON có cấu trúc.

Mô hình Kiến trúc Chuẩn

Mọi dashboard đều tuân theo cùng một phân cấp — được ánh xạ theo cách mà các kỹ sư SRE (Site Reliability Engineering) thực sự phân loại sự cố:

1. Dòng Tổng quan (Overview Row) (4-6 panel giá trị)

   • Hệ thống còn sống không? Tỷ lệ lỗi? Throughput?

2. Sử dụng Tài nguyên (6-8 panel đồ thị)

   • CPU, bộ nhớ, đĩa, mạng, kết nối.

3. Chỉ số Kinh doanh/Lĩnh vực (8-15 panel mỗi phần)

   • Đi sâu vào chi tiết cụ thể của từng công nghệ.

4. Phân tích Lỗi (4-8 panel)

   • Phân loại lỗi theo loại, tỷ lệ theo thời gian.

5. Đi sâu vào Hiệu suất (6-10 panel)

   • Phân vị độ trễ (p50/p95/p99), các truy vấn chậm.

Khi một trang báo đỏ (alert) fire lúc 3 giờ sáng, SRE sẽ nhìn vào phần tổng quan trước tiên. Bố cục nhất quán trên mọi dashboard giúp phản xạ vận dụng được chuyển đổi dễ dàng.

Xây dựng Dashboard Kafka 138 Panel

Dashboard Kafka (PR #298) là cái phức tạp nhất:

Tổng quan Sức khỏe Cluster

• kafka_controller_active_controller_count → value (nên là 1)
• kafka_server_broker_count → value
• kafka_server_under_replicated_partitions → value (cảnh báo nếu > 0)
• kafka_network_request_rate → graph

Hiệu suất Broker

• kafka_server_bytes_in_per_sec → đồ thị theo broker
• kafka_server_bytes_out_per_sec → đồ thị theo broker
• kafka_network_request_latency_ms{quantile} → đồ thị p50/p95/p99

Sức khỏe Partition

• kafka_cluster_partition_count → bảng theo topic
• kafka_cluster_partition_under_min_isr → panel cảnh báo
• kafka_log_log_size → bản đồ nhiệt (heatmap) theo partition
• kafka_controller_leader_election_rate → đồ thị (nhọn đỉnh = không ổn định)

5 Mẫu PromQL Phủ sóng 80% Dashboard

Sau khi làm xong 12 dashboard, những mẫu này xử lý hầu hết mọi tình huống:

Tỷ lệ thay đổi (Rate of change):

rate(metric_total{label="value"}[5m])

Gauge hiện tại với bộ lọc:

metric_gauge{namespace=~"", pod=~""}

Phân vị từ histogram:

histogram_quantile(0.99, rate(metric_bucket[5m]))

Top-K cho bảng:

topk(10, sum by (label) (rate(metric_total[5m])))

Tỷ lệ thành công:

sum(rate(success_total[5m])) / sum(rate(total_total[5m])) * 100

Công cụ Hỗ trợ Tăng tốc Độ

Cấu trúc lặp đi lặp lại của JSON dashboard là nơi phát triển hỗ trợ bởi AI tỏa sáng:

• Dashboard Builder Skill — Sinh ra JSON tương thích SigNoz từ một đặc tả metrics. Dashboard Kafka 138 panel bắt đầu từ một bản spec metrics, sau đó công cụ mở rộng thành JSON hoàn chỉnh với các loại panel, vị trí lưới và truy vấn PromQL chính xác.
• API Connector Skill — Xử lý tích hợp khi dashboard nạp metrics từ các nguồn không chuẩn (như AWS MSK CloudWatch bridge sang Prometheus).

Phần việc của con người — quyết định CHỈ SỐ NÀO quan trọng — là nơi kiến thức lĩnh vực thắng thế. Phần việc của máy — sinh ra 21K dòng JSON được cấu trúc đúng — là nơi công cụ tự hoàn vốn.

Bài học từ 12 Dashboard

1. Số lượng panel tín hiệu chất lượng. Dashboard của tôi có 56-138 panel so với 20-40 của đối thủ. Các Maintainer để ý điều này.
2. Mô tả quan trọng hơn tiêu đề. Mọi panel đều có mô tả giải thích ý nghĩa metric và khi nào cần lo lắng.
3. Vấn đề không có cạnh tranh vẫn tồn tại. Keycloak và Spark không có PR cạnh tranh nào.
4. PR sửa lỗi xây dựng uy tín. Các sửa đổi nhỏ chỉ 2 panel cho thấy bạn hiểu codebase.
5. Schema nhất quán = review nhanh. Cấu trúc dự đoán được giúp Maintainer review nhanh hơn.

Cách Bắt đầu

1. Fork repo SigNoz dashboards và nghiên cứu các mẫu có sẵn.
2. Chọn một công nghệ bạn am hiểu.
3. Bắt đầu với dòng tổng quan — 4-6 panel giá trị trả lời câu hỏi "nó có khỏe không?".
4. Mở rộng từng phần một.
5. Kiểm tra các truy vấn PromQL với tên metrics thực tế.

Công cụ Dashboard Builder sẽ xử lý phần dựng khung JSON để bạn tập trung vào việc chọn metrics và bố cục.