4、核心网日志与指标采集：网元日志格式（3GPP标准）、关键KPI指标、Prometheus与Grafana在核心网监控中的应用

各位好，我是老赵。在核心网运维这行摸爬滚打了十几年，今天咱们聊聊一个非常实在的话题——日志与指标采集。

说实话，很多刚入行的朋友觉得这活儿简单，不就是抓抓日志、看看告警吗？但真正出过事故的人都知道，日志和指标就是核心网的“黑匣子”和“仪表盘”。你想想看，一个5G核心网网元挂了，全网几十万用户掉线，这时候你靠什么定位？靠的就是这些数据。

我个人习惯，把核心网的可观测性分成三层：日志（Logs）、指标（Metrics）、链路追踪（Traces）。今天咱们重点讲前两层，第三层后面章节会单独展开。

4.1 网元日志格式：3GPP标准到底长什么样？

先说说日志。3GPP标准里对核心网网元的日志格式有明确规范，主要遵循TS 32.421和TS 32.422系列。说白了，就是告诉你每条日志该写什么、怎么写。

我见过不少厂商的私有格式，但最终都逃不开这几个核心字段：

• 时间戳：精确到毫秒，最好带时区。我曾经遇到过一次跨局点故障，两边日志差了8小时，排查了整整两天才发现是时区没对齐。
• 网元标识：比如AMF、SMF、UPF的实例ID。在云化部署里，同一个网元可能有几十个实例，没有这个字段你根本不知道是哪个Pod出了问题。
• 会话ID：SUPI（用户永久标识）或GUTI（全球唯一临时标识）。这是关联用户行为的唯一线索。
• 事件类型：比如Registration Request、PDU Session Establishment、Handover等。
• 结果码：成功/失败，以及3GPP定义的Cause Code（原因码）。

下面是一个典型的3GPP标准日志示例（简化版）：

2025-03-15 14:23:45.678 | AMF-01 | SUPI: 123456789012345 | Registration Request | Cause: 0 (Success)
2025-03-15 14:23:45.890 | AMF-01 | SUPI: 123456789012345 | Registration Accept | Cause: 0 (Success)
2025-03-15 14:23:46.012 | SMF-02 | SUPI: 123456789012345 | PDU Session Establishment Request | Cause: 0 (Success)
2025-03-15 14:23:46.234 | SMF-02 | SUPI: 123456789012345 | PDU Session Establishment Accept | Cause: 0 (Success)

4.2 关键KPI指标：哪些数字能救命？

指标这东西，说白了就是核心网的“体温”和“血压”。你不需要记住所有指标，但下面这几个，我建议你刻在脑子里。

4.2.1 注册成功率（Registration Success Rate）

这是最基础的指标。用户能不能接入网络，就看它。计算公式很简单：

注册成功率 = (注册成功次数 / 注册请求总次数) × 100%

正常值应该在99.5%以上。低于98%就要拉警报了。我记得有一次，某省核心网升级后注册成功率掉到95%，排查发现是AMF的DNS解析配置错了，导致用户无法找到正确的SMF。

4.2.2 PDU会话建立成功率（PDU Session Establishment Success Rate）

注册成功只是第一步，用户能不能上网、打电话，还得看PDU会话能不能建起来。这个指标比注册成功率更敏感，因为涉及SMF、UPF、PCF等多个网元协同。

PDU会话建立成功率 = (PDU会话建立成功次数 / PDU会话建立请求总次数) × 100%

我建议你把这个指标拆成两个维度看：

• 按切片维度：不同网络切片（eMBB、URLLC、mMTC）的成功率可能差异很大。
• 按APN/DNN维度：企业专线和普通上网的成功率要分开统计。

4.2.3 时延（Latency）

核心网时延通常指控制面时延和用户面时延。控制面时延关注的是信令交互速度，用户面时延关注的是数据包转发速度。

指标名称	正常范围	告警阈值
注册时延（Registration Latency）	< 50ms	> 100ms
PDU会话建立时延	< 30ms	> 80ms
用户面单向时延	< 5ms	> 15ms

4.2.4 吞吐量（Throughput）

吞吐量是UPF的核心指标。通常分上行和下行统计，单位是Gbps或Mbps。

这里有个坑：很多厂商的吞吐量统计只算用户面数据，忽略了信令开销。但实际上，信令风暴发生时，吞吐量指标会先于其他指标出现异常。我建议你同时监控：

• 用户面吞吐量：实际业务流量
• 信令面吞吐量：NAS消息、NGAP消息等

4.3 Prometheus与Grafana：核心网监控的黄金搭档

说到指标采集，Prometheus和Grafana几乎是标配。为什么？因为核心网云化之后，传统SNMP采集方式已经跟不上节奏了。Prometheus的Pull模型天然适合Kubernetes环境。

4.3.1 Prometheus怎么采集核心网指标？

核心网网元通常通过Exporter暴露指标。比如：

• AMF Exporter：暴露注册成功率、注册时延、N1/N2接口消息量等
• SMF Exporter：暴露PDU会话建立成功率、会话数、N4接口流量等
• UPF Exporter：暴露吞吐量、包转发率、连接数等

下面是一个Prometheus配置示例，抓取AMF的指标：

scrape_configs:
  - job_name: 'amf'
    static_configs:
      - targets: ['amf-01:9090', 'amf-02:9090']
    metrics_path: '/metrics'
    scrape_interval: 15s
    scrape_timeout: 10s

嗯，这里要注意：scrape_interval别设太短。我见过有人设成1秒，结果Prometheus自己先扛不住了。15秒是经验值，既能保证实时性，又不会给网元造成太大压力。

4.3.2 Grafana仪表盘怎么设计？

Grafana的核心价值在于可视化。我个人习惯把仪表盘分成三层：

• 全局视图：显示全网注册成功率、PDU会话成功率、平均时延。适合领导看。
• 网元视图：显示单个AMF/SMF/UPF的详细指标。适合运维工程师看。
• 用户视图：按SUPI或切片维度下钻。适合故障排查时用。

下面是一个简单的Grafana查询示例，用于展示注册成功率：

# 注册成功率 = 成功次数 / 总次数 * 100
(
  sum(rate(amf_registration_success_total[5m]))
  /
  sum(rate(amf_registration_total[5m]))
) * 100

4.4 知识体系总览

为了让你更直观地理解本章内容，我画了一张图。这张图展示了日志、指标、采集工具之间的关系：

这张图你看懂了吗？从左到右，数据从网元产生，经过Prometheus采集，最终落到Grafana展示和告警。说白了，这就是一套完整的“数据管道”。

4.5 避坑指南

最后，分享几个我踩过的坑：

• 日志轮转策略：核心网日志增长极快，一天可能几十GB。如果不做轮转，磁盘很快会满。我建议按天轮转，保留30天，压缩存储。
• 指标基数爆炸：Prometheus的Label不能乱加。比如把SUPI作为Label，几百万用户就会导致指标基数爆炸。正确的做法是用聚合指标，或者用日志系统查明细。
• 时间同步：所有网元必须用NTP同步时间。我曾经因为一个AMF的时间慢了3秒，导致日志和指标对不上，排查了整整一个通宵。

好了，这一章的内容就到这里。日志和指标是核心网运维的基石，你把这些搞明白了，后面讲告警、自动化、AI运维才有根基。下一章咱们聊聊告警规则怎么设计，才能既不漏报又不误报。

---

公众号:蓝海资料掘金营，微信deep3321