Triển khai Prometheus và Grafana trên Node Proxmox
Bước đầu tiên là thiết lập nền tảng thu thập dữ liệu (Metrics) trực tiếp trên node vật lý Proxmox. Việc này giúp giám sát tài nguyên vật lý (CPU, RAM, I/O) ảnh hưởng đến hiệu năng của các VM chạy OAI và srsRAN.
Tại sao: Proxmox không có module exporter mặc định cho Prometheus. Chúng ta cần cài đặt Node Exporter để thu thập thông số hệ thống và cấu hình Prometheus để scrape dữ liệu này.
Kết quả mong đợi: Prometheus có thể thấy target "prometheus-node-exporter" với trạng thái "UP" và dữ liệu tài nguyên hiển thị trên UI.
Truy cập vào console của Proxmox VE và thực thi các lệnh sau để cài đặt Node Exporter:
apt update && apt install prometheus-node-exporter -y
File cấu hình của Node Exporter cần được chỉnh sửa để chỉ lắng nghe trên giao diện mạng nội bộ hoặc IP cụ thể để tránh rủi ro bảo mật, nhưng trong môi trường lab nội bộ, chúng ta để mặc định để dễ kết nối.
Tạo file cấu hình scraping cho Prometheus tại đường dẫn sau:
cat > /etc/prometheus/prometheus.yml
Khởi động lại dịch vụ Prometheus để áp dụng cấu hình mới:
systemctl restart prometheus
Triển khai Grafana để trực quan hóa dữ liệu đã thu thập:
apt install grafana -y && systemctl enable --now grafana-server
Thêm datasource Prometheus vào Grafana thông qua UI (địa chỉ: http://:3000) hoặc cấu hình file yaml:
cat > /etc/grafana/provisioning/datasources/prometheus.yml
Khởi động lại Grafana:
systemctl restart grafana-server
Verify: Truy cập http://:3000, đăng nhập (admin/admin), vào Configuration > Data Sources, kiểm tra Prometheus có trạng thái "Data source is working".
Cấu hình Exporter cho OAI và srsRAN
Bây giờ chúng ta cần thu thập các metric chuyên biệt của mạng 5G từ các container đang chạy OAI (5GC) và srsRAN (RAN).
Tại sao: Các metric mặc định của Linux không thể đo lường được độ trễ truyền dẫn (latency), số lượng UE kết nối, hoặc tỷ lệ gói tin bị mất (packet loss) ở tầng radio. Chúng ta cần custom exporter hoặc scrape các endpoint REST API nếu có.
Kết quả mong đợi: Prometheus có thêm các job "oai-5gc" và "srsran-gnb" với các metric như "gnb_connected_ues", "oai_throughput".
Giả sử container OAI 5GC đang chạy trên port 8080 và srsRAN GNB trên port 2905 (port metrics mặc định thường được cấu hình trong phần 3 và 4). Nếu chưa có, chúng ta sẽ tạo một script Python đơn giản để expose metrics dạng Prometheus.
Trên VM chạy srsRAN (GNB), tạo file script exporter tại /opt/srsran_metrics_exporter.py:
#!/usr/bin/env python3
import socket
import time
import subprocess
import re
PORT = 9150
def get_srs_metrics():
# Giả lập lấy số lượng UE kết nối từ log hoặc socket nội bộ
# Trong thực tế, srsRAN có thể expose qua socket hoặc file
# Ở đây dùng command giả lập để demo
try:
# Giả sử có file log chứa số lượng UE
# result = subprocess.run(['grep', '-c', 'RRC Connected', '/var/log/srsRAN.log'], capture_output=True, text=True)
# ues = int(result.stdout)
ues = 2 # Mock data cho ví dụ
except:
ues = 0
# Giả lập throughput (Mbps)
throughput = 15.5
return f"""
# HELP srs_gnb_connected_ues Số lượng UE đang kết nối
# TYPE srs_gnb_connected_ues gauge
srs_gnb_connected_ues {ues}
# HELP srs_gnb_throughput_mbps Băng thông thực tế (Mbps)
# TYPE srs_gnb_throughput_mbps gauge
srs_gnb_throughput_mbps {throughput}
# HELP srs_gnb_rss_dbm Tín hiệu trung bình (dBm)
# TYPE srs_gnb_rss_dbm gauge
srs_gnb_rss_dbm -85.0
"""
def serve():
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
s.bind(('0.0.0.0', PORT))
s.listen(5)
print(f"Exporter listening on port {PORT}")
while True:
conn, addr = s.accept()
data = conn.recv(1024)
conn.send(get_srs_metrics().encode())
conn.close()
if __name__ == "__main__":
serve()
Chạy script exporter trên VM srsRAN:
chmod +x /opt/srsran_metrics_exporter.py && python3 /opt/srsran_metrics_exporter.py &
Làm tương tự cho VM OAI 5GC (tạo script exporter tại port 9151) để đo lường số lượng session và throughput core.
Cập nhật file cấu hình /etc/prometheus/prometheus.yml trên node Proxmox (hoặc trên VM chạy Prometheus nếu tách biệt) để thêm các target mới:
cat > /etc/prometheus/prometheus.yml
Thay thế <IP-VM-srsRAN> và <IP-VM-OAI> bằng địa chỉ IP thực tế của các VM.
Khởi động lại Prometheus:
systemctl restart prometheus
Verify: Truy cập UI Prometheus (http://:9090), vào tab Status > Targets. Kiểm tra "srsran-gnb" và "oai-5gc" có trạng thái "UP". Vào tab Graph và nhập query srs_gnb_connected_ues để xem biểu đồ.
Tạo Dashboard trực quan hóa trạng thái mạng
Sử dụng Grafana để tạo dashboard tổng hợp hiển thị trạng thái kết nối UE, tải CPU của RAN/Core và băng thông thực tế.
Tại sao: Giám sát bằng số liệu thô khó nắm bắt xu hướng. Dashboard giúp kỹ thuật viên nhìn nhận nhanh tình trạng mạng và phát hiện sự cố ngay lập tức.
Kết quả mong đợi: Một Dashboard Grafana hiển thị 3 panel chính: Số lượng UE, Throughput (Mbps), và CPU Load của các thành phần.
Truy cập Grafana, vào Dashboard > New > Import. Chúng ta sẽ tạo template JSON custom cho hệ thống Open RAN này.
Tạo file /opt/grafana/openran_dashboard.json:
{
"dashboard": {
"id": null,
"uid": "openran-monitor",
"title": "Open RAN 5G Status",
"tags": ["5G", "OpenRAN", "OAI", "srsRAN"],
"timezone": "browser",
"schemaVersion": 16,
"version": 1,
"panels": [
{
"id": 1,
"gridPos": {"h": 8, "w": 8, "x": 0, "y": 0},
"title": "Connected UEs (GNB)",
"type": "stat",
"datasource": "Prometheus",
"targets": [
{
"expr": "srs_gnb_connected_ues",
"legendFormat": "UE Count",
"refId": "A"
}
],
"fieldConfig": {"defaults": {"unit": "none", "mappings": []}}
},
{
"id": 2,
"gridPos": {"h": 8, "w": 8, "x": 8, "y": 0},
"title": "Downlink Throughput (Mbps)",
"type": "graph",
"datasource": "Prometheus",
"targets": [
{
"expr": "srs_gnb_throughput_mbps",
"legendFormat": "Throughput",
"refId": "A"
}
]
},
{
"id": 3,
"gridPos": {"h": 8, "w": 8, "x": 16, "y": 0},
"title": "RAN CPU Load",
"type": "stat",
"datasource": "Prometheus",
"targets": [
{
"expr": "100 - (avg by (instance) (rate(node_cpu_seconds_total{mode=\"idle\"}[5m])) * 100)",
"legendFormat": "CPU %",
"refId": "A"
}
],
"fieldConfig": {"defaults": {"unit": "percent"}}
},
{
"id": 4,
"gridPos": {"h": 8, "w": 24, "x": 0, "y": 8},
"title": "Network Latency (Round Trip)",
"type": "graph",
"datasource": "Prometheus",
"targets": [
{
"expr": "rate(srs_gnb_rtt_ms[1m])",
"legendFormat": "RTT (ms)",
"refId": "A"
}
]
}
],
"refresh": "5s",
"time": {"from": "now-1h", "to": "now"}
},
"overwrite": true
}
Import file JSON này vào Grafana thông qua giao diện Import hoặc dùng API (ở đây dùng UI cho đơn giản): Copy nội dung file trên, chọn tab "Import via URL or JSON file", dán vào và nhấn Import.
Verify: Dashboard "Open RAN 5G Status" xuất hiện trong danh sách, hiển thị số liệu real-time. Khi UE kết nối mới, panel "Connected UEs" sẽ tăng lên.
Phân tích log để tối ưu tham số Handover và Retransmission
Sử dụng các công cụ dòng lệnh để phân tích log từ OAI và srsRAN nhằm tinh chỉnh tham số mạng, giảm độ trễ và tăng độ ổn định.
Tại sao: Trong môi trường IoT công nghiệp, độ trễ (latency) và độ tin cậy (reliability) là ưu tiên hàng đầu. Các tham số mặc định của OAI/srsRAN có thể chưa tối ưu cho tải trọng cụ thể.
Kết quả mong đợi: Xác định được nguyên nhân gây mất gói tin hoặc độ trễ cao và điều chỉnh file cấu hình để cải thiện.
Trên VM chạy srsRAN, xem log thời gian thực để tìm các lỗi về RRC hoặc Handover thất bại:
tail -f /var/log/srsRAN.log | grep -E "RRC|Handover|ReTx|Error"
Phân tích log để tìm tỷ lệ retransmission (Retx) cao. Nếu thấy nhiều dòng "Retransmission timeout", cần tăng tham số số lần truyền lại hoặc giảm kích thước gói tin.
Chỉnh sửa file cấu hình srsRAN (thường là /etc/srsRAN/gnb.conf hoặc tương đương tùy phiên bản) để tối ưu hóa:
cat > /etc/srsRAN/gnb_optimized.conf
Trên VM OAI 5GC, phân tích log AMF (Access and Mobility Management Function) để kiểm tra tốc độ thiết lập session:
grep "N1 N2" /var/log/oai/amf.log | tail -n 20
Nếu thấy độ trễ khi handover (UE di chuyển giữa các cell), cần điều chỉnh tham số hysteresis trong file cấu hình OAI (thường nằm trong /etc/oai/amf.conf hoặc ue_handler.conf):
cat > /etc/oai/amf_optimized.conf
Khởi động lại dịch vụ RAN và Core để áp dụng thay đổi:
systemctl restart srsRAN-gnb && systemctl restart oai-amf
Verify: Chạy lại lệnh tail -f và thực hiện test kết nối. Quan sát xem số lượng lỗi "Handover failure" hoặc "Retx timeout" giảm xuống không. So sánh thông số RTT trên Dashboard Grafana trước và sau khi tối ưu.
Cấu hình cảnh báo (Alerting) khi độ trễ vượt ngưỡng
Thiết lập cơ chế cảnh báo tự động qua email hoặc Slack khi các chỉ số quan trọng vượt quá ngưỡng an toàn cho IoT công nghiệp.
Tại sao: Trong môi trường sản xuất, con người không thể canh 24/7. Cần hệ thống tự động báo động khi mạng gặp sự cố (ví dụ: độ trễ > 50ms, mất kết nối > 30s).
Kết quả mong đợi: Khi độ trễ tăng cao hoặc số lượng UE kết nối về 0 bất thường, email cảnh báo được gửi đến admin.
Triển khai Alertmanager trên node Proxmox:
apt install alertmanager -y
Tạo file cấu hình Alertmanager tại /etc/alertmanager/alertmanager.yml:
cat > /etc/alertmanager/alertmanager.yml
Cấu hình Alert Rules trong Prometheus. Tạo file /etc/prometheus/rules/openran_alerts.yml:
cat > /etc/prometheus/rules/openran_alerts.yml 80
for: 5m
labels:
severity: warning
annotations:
summary: "Tải CPU RAN quá cao ({{ \$value }}%)"
description: "CPU của GNB vượt quá 80%, có nguy cơ mất gói tin hoặc độ trễ tăng."
EOF
Cập nhật file /etc/prometheus/prometheus.yml để load file rules mới:
cat > /etc/prometheus/prometheus.yml
Thay <IP-VM-srsRAN> và <IP-VM-OAI> bằng IP thực tế.
Khởi động lại Prometheus và Alertmanager:
systemctl restart prometheus && systemctl restart alertmanager
Verify: Truy cập UI Prometheus, vào tab Alerting. Kiểm tra các rule đã được load. Để test, bạn có thể giả lập độ trễ cao bằng cách sửa script exporter (thay giá trị mock thành 60) và chờ 1 phút, sau đó kiểm tra email có nhận được cảnh báo hay không.
Điều hướng series:
Mục lục: Series: Series: Xây dựng nền tảng Private 5G Network (Open RAN) với OAI, srsRAN và CUPS trên hạ tầng Proxmox để kết nối IoT công nghiệp an toàn
« Phần 6: Triển khai thiết bị IoT và kiểm tra kết nối thực tế
Phần 8: Troubleshooting và các mẹo nâng cao cho môi trường Open RAN »