大家好，我是小斐呀。
7月26日，我有幸受邀出席了由中国计算机学会主办的第二届 CCF 夜莺开发者创新论坛。在此次会议中，我分享了一些关于网络可观测性的思考与实践。现在，我想借此机会，将当时的分享内容做进一步延伸，并结合更多的深度思考，与大家交流探讨。
会议回顾
会议开场就是重量级大佬，LVS 的作者、CCF 常务理事章文嵩博士代表计算机学会致辞，为我们揭秘了在建的计算机博物馆的故事，计算机博物馆希望能成为全世界计算机发展史的永久展示中心，向公众及青少年普及计算机科学精神、素养和知识的基地。
场馆在横店，2026年开馆，到时候有兴趣的可以去看看。
夜莺的联合创始人秦晓辉就介绍了下关于夜莺的 V7 正式版本发布和 V8 版本的规划，V7 正式版本越来越完善，重点强调以指标监控为重心，日志相关功能慢慢弱化，力争把监控告警的最佳实践用开源的方式赋能千行百业，而不再是大厂才能玩的转，同时 CTO 华明介绍了 Flashduty 产品体系建设心得和思考规划。
字节跳动的舒博老师带来了关于对观测数据的埋点标准化实践，随着字节业务规模越来越大，稳定性也是越来越重要，从这几次的大厂公有云故障影响的面来看，稳定性只会越来越重要，而舒博老师觉得稳定性建设的数据基石就是观测数据的标准化，只有能及时感知各系统的状态才能做好稳定性。
毕业于北京大学的张同浩老师，更是带来了关于 eBPF 在内核层面的可观测性故障定位实践，我听到一半后，发现后面有些听不懂，内核这块东西还是太深。
接下来就是宋庆羽老师关于期货行业 OnCall 实践，期货行业在交易高峰期对期货信息系统的安全稳定运行有着极高的要求，并且分散多源的告警以及告警量的庞大，通过夜莺的 Flashduty 可以完美的解决这些业务痛点。同时夜莺的于双羽老师也带来了关于 OnCall 在 Flashduty 的最佳落地实践。
来自小米的马千里老师，介绍了小米在多地多机房的场景下如何更好的落地可观性系统，包括监控、日志、以及链路等可观测性三大支柱整体架构落地说明。
知乎的邱天罡老师，带来了关于知乎内部的可观测性实践，特别介绍了整体可观测性架构：
同时介绍了知乎内部自研的北斗一体化监控平台的一些功能和实践，初看北斗这个系统有点意思。
来自 AutoMQ 的 CTO 周新宇老师介绍了下关于 AutoMQ 云原生共享存储架构的一些成本优势，可以助力可观测数据源降本增效。
作业帮的聂安老师让我记忆尤深，他分享了关于观测数据治理（从生命周期的视角思考），从抽象建模的角度展开说明。字节和作业帮都在分享观测数据标准化治理，说明现在大厂越来越重视可观测性数据，也越来越趋向于数据标准统一，而不是各个团队各自为战，不然后续成本越来越高也越来越难以为继。
钱誉老师分享了关于 Zenlayer 在运维体系中 AI Agent 探索和实践，介绍了 Zenlayer 在私域数据尝试使用 FT or RAG，让我印象比较深的是 BGP 趋势分析上的应用，通过 AI 与工具链 BGP 全链路的波动、异常、给出分析，并输出桑基图，给运维专家提供完整的 BGP 链条视图能力。
网络可观测性
网络设备可观测性，目前来看主要还是基于指标（Metrics）和日志（Log），目前市面上的网络设备数据的收集都支持 SNMP ，某些网络设备数据的收集支持 Telemetry ，而网络设备日志通常都支持 syslog 进行采集和传输，还有附加的网络流量分析协议 sfow 可作为补充手段，下面的图直观展示网络设备可观测性的采集方式：
日志及流量分析体系在此不展开讨论，后续在可观测性的日志模块展开，这里主要还是基于可观测性三大支柱的指标监控展开说明，网络设备的指标监控数据采集方式主要如下几种：
网络设备最通用的还是
SNMP 兼容性强适应性广，不需要额外写代码，只需要写采集配置文件，相对网工朋友更加容易上手；而其他像 Telemetry 和 CLI 或者某些设备提供 API 可暴露指标数据，比如 Arbua 品牌设备，或多或少的都需要写代码获取数据并清洗加工插入时序库中，故下面我们只展开对 SNMP 协议方式的数据采集。
指标采集
网络可观测性的指标大致可以分为设备指标和状态指标，相关指标如下所示：
上面的指标基本是覆盖了网络的基本情况，更多需要呈现的其他指标可根据实际情况做增删。
当知道对网络设备采集那些指标后，我们应该利用什么工具进行采集呢，开源的方案中，有三个比较通用并推荐的，第一个是 Prometheus 社区开源的 SNMP Exporter 采集器，另外两个是 Categraf 和 Telegraf 两者原理和代码层面没有什么特别大的差异，故只针对夜莺的 Categraf 展开说明，下图是针对 SNMP Exporter 采集器和 Categraf 采集器的采集模式对比：
当指标采集完成后，就需要把指标数据写入到时序库中，实现指标监控的关键步骤，这里强烈推荐开源夜莺架构或魔改架构，关于指标监控告警架构可看这篇文章：网络监控：架构选择 。
在日常使用 SNMP 协议采集指标的过程中，有很多比较容易犯的错误和陷阱存在，往往这些错误一卡就一整天的节奏，下面展开说明下这些陷阱问题和解决办法。
陷阱说明
这里展开说明日常使用 Categraf 比较常见的陷阱问题，以便更顺畅的使用 Categraf 采集器，助力网络基础设施领域可观测性实践。
陷阱1
MIB文件解析程序陷阱，由于在 Categraf 中解析 MIB 文件有两种选择：
- netsnmp（解析处理MIB） + 环境变量（指定要加载MIB文件的所在目录）
- gosmi（解析处理MIB） + path（指定加载MIB文件的所在目录）
netsnmp 和 gosmi 有什么区别：
- netsnmp 是 C 语言编写的SNMP实现，里面包含了核心组件用于解析处理 SNMP MIB 文件
- gosmi 是一个基于 Go 语言编写的库，用于解析和处理 SNMP MIB 文件
由于 netsnmp 是一个系统级别管理包，故如果在 Categraf 使用 netsnmp 作为 MIB 文件解析器需要系统层面安装 netsnmp 依赖：
# Debian & Ubuntu
sudo apt-get install unzip build-essential libsnmp-dev
# Redhat & CentOS
sudo yum install net-snmp net-snmp-utils net-snmp-libs net-snmp-devel由于是外置系统依赖包，故 Categraf 调用 netsnmp 是通过系统层面的方式，即使用操作系统提供的命令行工具或库来与 SNMP 设备通信并收集数据。
而如果需要加载指定的 MIB 文件，就需要通过配置 MIBDIRS 路径并作为环境变量加载到系统中才能正常实现需求，如下所示：
当
Categraf 下的配置文件使用 netsnmp 后，需要在测试过程和正式采集中加入环境变量，以使得正确加载指定目录下的 MIB 文件：
由于
Categraf 直接集成 gosmi 库，不需要额外的外部依赖，直接在配置文件里面配置解析器和 MIB 文件目录路径参数即可：
然后测试和正式采集可以直接执行测试命令和运行程序即可，不需要做额外的操作。
陷阱2
MIB 引入的依赖文件缺失以及 MIB 文件格式错误，如下图所示：
建立对应文件夹管理不同品牌的 MIB 文件，私有 MIB 库和公有 MIB 库分开管理：
### 陷阱3
合理规划 Categraf 中 SNMP OID返回的数据哪些作为标签，哪些作为指标存在，只要把这些确定好了，才能出现避免浮点数限制的陷阱，这是 Prometheus 数据模型的限制，也是采集器设计初衷：指标数据只采集数值，不采集字符串，标签维持稳态结构：
SNMP OID 中的 Gauge、Counter、Integer 数据类型可直接作为指标值或标签的形式来采集得到，String 数据类型只可作为标签采集，其他特殊数据类型，需要特殊处理，比如 MAC 地址，IP地址等都可以使用数据转换的参数处理好以标签的形式插入指标中。
陷阱4
执行采集的过程中出现报错：
performing bulk walk … request timeout after 3 retries
这个问题是如何产生的，以及如何解决这个问题呢？
问题如何产生的？我们需要了解下 SNMP 请求 OID 检索数据的操作方式：
- GetNext：一次请求单个回复
- GetBulk：一次请求批量回复
GetNext Requests 是一个请求回复一个消息，等于需要请求20次，响应20次，而 GetBulk Requests 是请求一次，批量响应所有（上限）。
打个比方：你刚从超市购物回来，车上有一堆的东西需要拿进屋里面，你可能会发现，与其一件一件地把每件物品拿进去（Get 和 GetNext）不如直接用一个袋子把所有物品都拿进去（GetBulk），这样效率更高，耗时更少。
平时我们在使用 netsnmp 提供的命令工具时，不同的命令对应的就是不同的方式请求的，可以尝试使用这些命令查看返回的大批量数据的异同：
GetBulk 请求命令：
- snmpbulkget
- snmpbulkwalk
GetNext 请求命令：
- snmpgetnext
- snmpwalk
而 Categraf 采集标量的时候是使用最基础的 GetRequests 操作，而采集表量的时候是使用了 GetBulk Requests 操作，很多厂商为了安全以及性能考虑，大多都限制了 GetBulk 最大重复次数，以提高请求效率，同时避免响应数据超过设备设定的字节，故我们采集表量的时候需要遵循 max-repetitions ，这个参数用于控制返回的数据量。
如何解决这个问题呢？
1、有些厂商设备会限制响应PDU，一般升级固件可解决，或主动调整设备的最大响应字节数 2、在配置文件中设定合理的 max-repetitions 参数
如上图所示，设定适当的参数，确保采集的响应数据在上限范围内，从而解决实际采集过程中的各种异常错误。
大会分享的内容延伸到这里，关于大会PPT领取可直接到这拿：第二届CCF·夜莺开发者创新论坛成功举办，免费领取 PPT 。更多关于网络监控这块可进星球探讨。
