简介以信息技术运维管理基础知识为主题的幻灯片学习教案面向运维入门者、技术培训讲师和希望系统梳理运维知识的学习者。内容围绕监控软件与采集协议展开涵盖SNMP、RMON、Syslog、Telnet/SSH、ODBC/JDBC、WMI等十余种常用协议并进一步讲解管理信息库MIB的树形结构、对象唯一标识OID、NetFlow流量分析以及基于交换机端口镜像和光口TAP的数据侦听方式同时列举网络设备、安全设备、主机、数据库、应用系统等常见监控对象以及CPU使用率、内存占用、网络流量、端口状态、磁盘空间、IO性能、系统日志、应用可用性等核心性能指标还涉及告警通知、故障定位和报表联动等运维环节。压缩包内共1个pptx文件约390KB图文版式便于课堂演示与自主学习。已有113人学习适合快速建立IT运维管理整体认知为后续运维监控部署、故障排查和自动化运维打下基础。1. IT运维管理基础监控协议选型与设备边界IT运维管理的门槛不在工具而在协议和数据的对应关系。很多团队已经部署了监控软件却依然在“CPU 100%但不知道哪台设备”“告警风暴”里打转本质是没有把性能指标压到正确的采集通道上。SNMP负责设备状态和流量计数器Syslog负责事件日志NetFlow负责流记录端口镜像和光口TAP负责原始报文。这套PPT学习教案把监控软件、系统设备、采集协议和性能指标串成了一条完整的链路下面按这条链路展开成可复现的配置和参数。适合刚接手机房监控的人也适合补协议边界的老手。这里不绑定某个具体厂商或软件只讲每个环节怎么选、怎么调、会踩哪些坑。2. 数据采集管线的四个支柱SNMP、Syslog、NetFlow 与探针从网络设备、安全设备、系统主机到数据库和应用软件单靠一种协议根本不现实。讲稿里列出了SNMP、RMON、Syslog、Event、Telnet/SSH、ODBC/JDBC、WMI、RCP、VBS、Agent、Scripts、xFlow、Probe和Collecter初看像名词堆砌实际是一条采集链路的分层设备对象层有CPU、内存、端口状态、磁盘和日志面向网络的协议层有SNMP/RMON、NetFlow/sFlow、Syslog面向主机的通道层有WMI、Agent/Scripts、SSH/Telnet面向外部环境的接入层通过Probe/Collector接入温湿度和电力。这个分层在工程上的意义是选型时先确认“监控对象提供什么数据出口”再决定用什么协议。比如数据库运行状态更多用JDBC/ODBC因为SNMP里没有MySQL的会话数而温湿度传感器通常走Modbus再转成SNMP Trap或自定义Agent。当前PPT列出的协议可以对映到下表。协议或机制常用端口/载体数据形态典型监控对象选型要点SNMP v1/v2c/v3161/UDP(轮询)、162/UDP(Trap)计数器、离散值CPU、内存、接口流量、端口状态、系统名设备支持最广但计数器回绕要处理RMON161/UDP RMON MIB历史统计和事件以太网流量、历史趋势兼容性下降多数厂商只在MIB保留Syslog514/UDP6514/TCPTLS事件文本系统日志、设备日志、应用日志不可靠传输生产环境要加TLS和队列NetFlow9995/9996/UDP 常见流记录流量组成、Top N 会话、路径分析依赖设备流缓存和导出策略WMITCP 135 动态RPC端口Windows类对象进程、服务、补丁、磁盘防火墙策略复杂需要放行RPC动态范围Agent/Scripts自定义端口、定时任务任意深度指标应用可用性、业务拨测被管端要装组件注意升级和权限表里几组容易混淆SNMP和Syslog是互补关系前者要主动去问后者由设备主动推送NetFlow和端口镜像也不同NetFlow给你的是聚合后的流记录镜像给你的是原始报文。按PPT里的说法“多种展示通过采集进行获取”所有拓扑、报表和告警都建立在上述数据通道上通道选错了后面再漂亮的仪表盘都是看着热闹。2.1 SNMP 轮询与 Trap从 GetRequest 到 MIB 树的 OID 定位SNMP 的模型非常明确网络管理工作站作为管理实体被管设备上运行 SNMP Agent两者通过 GetRequest、GetNextRequest、GetBulkRequest 和 SetRequest 交互正常响应是 GetResponse当设备遇到接口 DOWN、温度过高这类事件时Agent 主动向网管发 Trap。v1/v2c 用 community string 做口令v3 增加了用户名、认证和加密。PPT 里提到的 MIB-2、ISO、Organization、Internet、Management、Private 这些节点对应的是一个树形对象标识体系每个对象有唯一 OIDIAB 管理机构维护公共部分厂商维护 1.3.6.1.4.1 下的私有分支。实战中造不出 OID 时不要猜用 snmpwalk 直接扫子树。# 扫描系统组 MIB查看设备返回的全部系统对象 snmpwalk -v2c -c public -On 192.0.2.1 1.3.6.1.2.1.1 # 读取设备名称 snmpget -v2c -c public -On 192.0.2.1 1.3.6.1.2.1.1.5.0第一个命令列出系统组全部对象第二个命令只取系统名称。-On让输出直接显示数字 OID避免本机没有加载厂商 MIB 时显示成“SNMPv2-MIB::sysName.0”排查时对照手册更方便。-v2c指定版本-c public是社区字符串生产环境要换成只有只读权限的 community并把网管站地址写进 ACL。SNMPv3 的命令可以加-u monitor -l authPriv -a SHA -A authpass -x AES -X privpass优先级高于 v2c尤其在设备可以配置 SNMPv3 时不要偷懒用 v2c。Trap 接收端可以用 snmptrapd 验证# 前台运行并打印 Trap 日志调试完再交给 systemd 托管 snmptrapd -f -Lo -c /etc/snmp/snmptrapd.conf-f前台运行-Lo把日志打到标准输出-c指定配置文件。注意 Trap 默认走 162/UDP如果设备在跨网段需要在防火墙放行 UDP 162 入站否则会出现“设备日志里有发送记录网管收不到”的经典问题。2.2 Syslog 事件通道facility、severity 与 514/UDP 的取舍Syslog 与 SNMP 最大的不同是方向SNMP Trap 虽有主动语义但大部分数据还是轮询采集Syslog 则是设备主动把日志推到 NMS 或中央日志服务器。一条标准 Syslog 消息包含时间戳、facility、severity level、主机名和消息正文。Cisco IOS 的缺省记录级别是 debugging 到 emergencies 都写缓冲但生产环境通常只关心 error 及以上和认证事件。PPT 中的严重级别表是排查日志的标准索引数值关键字含义典型场景0Emergencies系统不可用设备断电、双主控同时挂1Alerts需要立即行动温度超过临界值2Critical严重故障电源或风扇失效3Errors错误CRC 错包、AAA 认证失败4Warnings警告端口利用率突增5Notifications正常但需注意配置变更、接口 up/down6Informational信息登录成功、定时任务执行7Debugging调试仅排障时开平时关设备侧最容易被忽略的是 facility 和日志目的地的搭配。Cisco IOS 上把日志送到远程服务器# 远程日志服务器地址使用 UDP 514 logging host 192.0.2.10 transport udp port 514 # 推送级别notifications 及以上 logging trap notifications # 使用 local6 facility方便日志服务器分文件存储 logging facility local6logging trap notifications表示级别 5 及以上会推送logging facility local6把设备日志归到 local6方便日志服务器按 facility 分文件。UDP 514 是历史遗留下来的轻量方案设备发送即忘高可用环境建议改用 TCP 6514 并用 TLS 加密否则网络抖动时日志会悄悄丢。这里要记住一个原则Syslog 适合分析“发生了什么”不适合做“当前状态是什么”后者还是回到 SNMP 轮询。2.3 NetFlow 流量数据Export Packet 结构与 NetFlow 配置NetFlow 把网络流量抽象成流记录一条流由七元组版本、源目地址、源目端口、协议、ToS、接口等定义。设备把流缓存中的记录打包成 Export Packet通过 UDP 发给 Collector。PPT 里写得很清楚每个 Export Packet 约 1500 字节通常包含 20 到 50 条 flow record当被监控接口流量增大时发送频率也随之提高。这个细节决定了 Collector 的容量规划——不是按设备数算而是按并发流数算。以 Cisco IOS 为例开启 NetFlow 导出# 设置 NetFlow 导出目标和 UDP 端口 ip flow-export destination 192.0.2.20 9995 ip flow-export version 5 ip flow-export source Loopback0 # 在接口下开启入方向和出方向的流采集 interface GigabitEthernet0/1 ip flow ingress ip flow egressip flow-export destination指定 Collector 地址和 UDP 端口常用 9995/9996version 5是固定格式支持基本五元组和字节包计数ip flow ingress/egress分别开启入方向和出方向的流采集。如果只在 interface 下配了 ingress出方向流量统计不到这是排查“明明有流量NetFlow 报表为空”时要看的第一个点。Traffic Collector 运行在 Solaris、HP-UX 或 Linux 上的常见实现是 nfdump 配合 nfcapd启动后能用nfdump -r查看历史文件。流量大时可以在接口下配 sampler例如每 1024 个包采样 1 个减少 CPU 消耗但小流和短连接会被采样掉需要业务场景权衡。2.4 其他采集手段WMI、Agent、Probe/Collector 的适用边界讲稿里还列出了 RMON、Event、Telnet/SSH、ODBC/JDBC、WMI、RCP、VBS、Agent、Scripts、xFlow、dataflow、Probe 和 Collecter。这些不是给同一类对象准备的数据库运行状态用 JDBC/ODBC 最直接例如通过 JDBC 连 Oracle 查 v$instanceWindows 主机性能用 WMI但要放行 RPC 动态端口交换机上的 RMON 在今天更多是历史 MIB 兼容Agent 装在主机上能拿到 SNMP 拿不到的进程级指标但会引入版本和补丁维护成本Probe/Collector 则常用来做分布式采集和业务拨测比如从多个节点探测同一个 Web 服务的可用性。工具套件和系统平台厂家会把这些协议封装成驱动但底层仍然是上面这些通道。选型时可以给一张决策表物理环境用探针存量网络设备用 SNMP事件审计用 Syslog主机深度指标用 Agent数据库用 JDBC/ODBC业务拨测用 Scripts/Probe。这样设计出来的采集层才不会因为“某个协议支持得最好”而绑死在一个厂商上。3. 构建一套可落地的采集与告警链路有了协议通道下一步是把它变成可运行的监控项。我不建议直接上手就是大而全的商业平台先按“设备发现→基础指标→告警路径”三步走把最小闭环跑通再扩展。PPT 里的“全局/多级网络拓扑”“配置信息/软硬件资产”属于展示层展示层的数据来源必须先回答一个问题设备是什么型号、运行什么系统、有哪些接口和序列号。这部分靠 SNMP 扫出来。3.1 设备发现与资产盘点用 SNMP 扫描建立初始台账网络层的设备发现通常用 CDP/LLDP 或 ARP 扫描但资产台账需要的是 sysName、sysDescr、序列号和软硬件版本。最常见的做法是在一个管理网段内做 SNMP 扫描先确认哪台 IP 有 SNMP 应答再补采细节#!/bin/bash # 扫描 192.0.2.0/24 中存在 SNMP 应答的设备 for ip in $(seq 1 254); do target192.0.2.$ip if snmpget -v2c -c public -t 1 -r 0 -On $target 1.3.6.1.2.1.1.1.0 /dev/null 21; then sysname$(snmpget -v2c -c public -On $target 1.3.6.1.2.1.1.5.0 2/dev/null | awk -F: {print $2}) echo $target $sysname fi done脚本先探测 1.3.6.1.2.1.1.1.0sysDescr有返回证明设备开了 SNMP再读取 1.3.6.1.2.1.1.5.0sysName。-t 1是单次超时设为 1 秒-r 0是不重试扫描一个 /24 时不至于因为个别设备无响应拖很久。生产环境不要用 public应该用只读 community并把范围控制在运维网段若设备支持 SNMPv3脚本里的参数改成-u monitor -l authPriv -a SHA -A *** -x AES -X ***。扫描结果写入 CMDB 或 Excel 台账后续拓扑发现和报表都从这里取主数据。3.2 性能指标采集CPU、内存、磁盘与端口状态的参数设计讲到性能指标PPT 把 CPU/内存使用率、网络流量/端口状态、磁盘空间/IO 性能、系统日志/设备日志、数据库运行状态、应用系统运行状态都列进了监控范围。其中网络流量部分要特别小心SNMP 的接口计数器是 Counter32/Counter64直接取当前值没有意义必须按时间差算速率还要处理计数器回绕。常见做法是用监控软件内置的 SNMP 计数器类型Zabbix 里把监控项类型设为“SNMPv2 counter”更新间隔 60 秒系统会自动算出每秒速率。下面是一组典型的 SNMP 监控项参数监控对象OID 示例类型更新间隔建议阈值系统名称1.3.6.1.2.1.1.5.0字符串3600s无接口入方向流量1.3.6.1.2.1.2.2.1.10.计数器60s按端口带宽 70% 告警接口出方向流量1.3.6.1.2.1.2.2.1.16.计数器60s按端口带宽 70% 告警接口状态1.3.6.1.2.1.2.2.1.8.离散值(1 up,2 down)60sdown 即告警CPU 利用率(Cisco 部分版本)1.3.6.1.4.1.9.9.109.1.1.1.1.8.数值60s连续 5 分钟 85%磁盘空间1.3.6.1.2.1.25.2.3.1.6.数值300s使用率 90%这张表只是为了说明参数设计不同厂商的 CPU 和磁盘 OID 差异很大上线前一定要用自己的设备型号验证一遍。验证方法是先snmpwalk到厂商私有分支找到对应对象的数值再写入监控项如果某个 OID 在设备上返回 No Such Instance不是网络问题而是该型号不支持或 OID 索引不对。索引通常是 ifIndex 或 hrStorageIndex同一台设备上接口表的索引与 CPU 表的索引不一定一致不能想当然套用。数据库和应用软件层的采集与网络设备不同MySQL 可以用mysql -u monitor -p -e SHOW GLOBAL STATUS LIKE Threads_connectedOracle 通过 JDBC 查询 v$sysstat这类指标走数据库客户端或 Agent不走 SNMP更新间隔可以放到 5 到 10 秒。3.3 告警路径声光、短信、邮件与运维管理系统联动采集到位后告警路径决定故障能不能被看见。PPT 里的“声光、短信、邮件”是三种不同优先级的通道声光用于机房现场短信用于值班人员邮件用于留痕。常用的做法是在监控平台里定义触发器再通过告警媒介把事件推出去。以 Zabbix 和通用 HTTP 接口为例#!/bin/bash # 放在 /usr/lib/zabbix/alertscripts/ 下脚本接收三个参数 API_KEY$1 MESSAGE$2 curl -s -X POST https://api.example.com/v2/alerts \ -H Authorization: GenieKey $API_KEY \ -H Content-Type: application/json \ -d {\message\:\$MESSAGE\}这个脚本把监控系统的告警消息转成第三方平台的 REST API 请求。Zabbix 在调用时会把{ALERT.SENDTO}、{ALERT.SUBJECT}、{ALERT.MESSAGE}映射为脚本参数所以$1可以放 API Key$2放消息体。实际配置短信时通常把短信网关的 URL 放到$1在脚本里再拼一部分内容声光告警则接一个支持 HTTP 控制的报警灯模块通过 curl 触发红灯和蜂鸣。告警要避免直接对原始指标设阈值而应该加持续时间条件比如 CPU 连续 5 分钟超过 85% 才触发否则一次 5 秒尖峰就会造成告警风暴。最后别忘记告警与运维管理系统联动生成事件单、绑定设备配置档案和最近变更记录才能真正做到“故障快速定位与预防”而不只是把消息发出去。4. 流量分析实战端口镜像与光口 TAP 的配置和排错监控系统要回答“设备有没有故障”流量分析要回答“网络里到底传了什么”。PPT 里用了两页讲数据侦听一页是基于交换机的端口镜像PC-3 接在镜像端口上装协议分析软件即可另一页是基于光口 TAP 的硬件探针。两套方案采集的都是原始报文但适用场景完全不同。4.1 交换机端口镜像monitor port 与 monitored port 的配置PPT 图里的 PORT-24 是被镜像端口monitored portPORT-18 是镜像端口monitor port。流经 PORT-24 的 PC-1 和 PC-2 双向数据都会被复制到 PORT-18接在 PORT-20 的 PC-3 只要能收到复制过来的流量就能做协议分析。Cisco IOS 的实现是本地 SPAN# 把 Gi0/24 双向流量镜像到 Gi0/18 monitor session 1 source interface Gi0/24 both monitor session 1 destination interface Gi0/18source interface指定被镜像的源端口both表示入方向和出方向都复制如果只需要抓服务器上行的攻击包可以改成rx。destination interface指定镜像目的端口接到分析机的网卡。如果交换机的镜像端口本身还跑着业务抓包结果会混入额外流量因此排查时优先找独立的空端口。另外把 10G 端口镜像到 1G 端口会丢包这是必然的镜像链路带宽必须不低于源端口带宽。在老的 CatOS 设备上命令完全不同常见的是set span 24 18 both意思是源端口 24目的端口 18双向。遇到不同厂商设备先看命令是monitor session风格还是set span风格不要凭 Cisco IOS 记忆去套所有交换机。端口镜像对交换机 CPU 和 ASIC 有一定开销高流量核心设备建议只在排障窗口临时开启不要长期全量镜像。4.2 光口 TAP 与硬件探针部署关键链路的无源采集端口镜像依赖交换机正确处理复制动作光口 TAP 则是在光纤链路上做物理分光把一部分光信号复制给探针。最大的优势是设备故障不影响主链路即使 TAP 掉电光路仍然直通。对于 WAN 出口和数据库集群之间的链路我一般优先考虑 TAP。硬件探针接在 TAP 的 RX 端把光信号转换成电口给采集服务器。采集侧常见的抓包命令# 抓链路数据包仅保存报文头减少磁盘占用 tcpdump -i eth1 -s 96 -nn -w /data/capture/20250222_1200.pcap-s 96只抓每个报文前 96 字节足够看到 IP 层和 TCP/UDP 头部用于会话分析时能大幅减少磁盘占用如果要分析应用层内容改为-s 0抓整包。-nn表示不做 DNS 反向解析也不把端口翻译成服务名避免抓包过程产生额外 DNS 查询。-w直接写 pcap后续用 Wireshark 打开。如果现场需要验证 TAP 是否工作先用tcpdump -i eth1 -c 100看是否有包进来如果持续无包检查 TAP 光口 RX 是否接反常见的原因是 TAP 设备的 RX/TX 交叉接线错误。4.3 用 NetFlow/sFlow 补充长期流量统计端口镜像和 TAP 能拿到最全的报文但存不了三个月。NetFlow 和 sFlow 的价值在于用很小的存储代价留住流量统计适合作长期趋势和容量规划。NetFlow 由设备维护流缓存sFlow 则是基于采样二者在实现上差异不小。我在核心交换机上通常同时开两个NetFlow 用于会话级分析和安全审计sFlow 用于整体流量水位。sFlow 配置示例# sFlow 源地址 sflow source 10.0.0.1 # 采样率每1024个包采样1个 sflow sampling-rate 1024 sflow collector-address 192.0.2.30 sflow collector-port 6343sampling-rate 1024表示每 1024 个包抽取 1 个包上报。采样率太高会漏掉带宽占用很小的长尾流量太低又带来设备开销一般从 512 到 1024 起步打开后对比 SNMP 接口流量偏差超过 20% 再调整。collector-address指向 sFlow Collector默认端口 6343。如果只看网络整体流量sFlow 够用如果要做 DDoS 溯源和会话追踪NetFlow 更合适。三类手段的定位可以简单对比如下手段数据粒度存储成本适用场景端口镜像原始报文极高排障、抓包、安全分析光口 TAP原始报文极高核心链路被动采集不依赖交换机NetFlow流记录聚合低长期流量趋势、Top N 会话sFlow采样包很低流量水位、端口利用率统计5. 运维报表与可用性统计公式、SQL 与踩坑清单PPT 最后落到了“网络和系统运行报表”“服务可用性统计报表”和“与运维管理系统联动”。报表能不能信取决于统计口径而不是图表好看。5.1 服务可用性的两种统计口径常见口径有三种但监控报表里最常用的是可用性 可用时间 / 统计周期。计算时要明确探测粒度例如每 5 分钟探测一次一个周期内最多有 288 个数据点只要某一次探测失败就认为对应 5 分钟不可用这会把一次 30 秒的闪断放大成 5 分钟不可用。另一种口径是质量指标比如 HTTP 平均响应时间小于 2 秒算可用适合应用层。PPT 里的“服务可用性统计”没有指明是哪一种所以做报表前要和业务统一口径不然同一个平台会算出两个可用性。5.2 从监控历史表生成月度可用性如果监控项本身返回 1/01 表示可用0 表示不可用可以直接用 Zabbix 的 trends 表聚合月报-- 按月份聚合 trends 表中的 1/0 监控项 SELECT DATE_FORMAT(FROM_UNIXTIME(clock), %Y-%m) AS month, ROUND(AVG(value_avg) * 100, 2) AS availability_pct FROM trends WHERE itemid 10001 AND clock UNIX_TIMESTAMP(2025-01-01) GROUP BY month;trends表保存的是小时级聚合value_avg是该小时内监控项的平均值。对 1/0 型监控项按小时平均后基本等于该小时可用比例。itemid替换成实际可用性探针的 ID如果探针返回的是响应时间而不是 0/1需要先写触发器把可用/不可用转换成 1/0再进这个 SQL。注意FROM_UNIXTIME(clock)的时区要和监控服务器时区一致否则月报边缘会出现偏移。5.3 常见误用与排查清单排障时最常碰到的问题按概率排序一是 community 用 public 且网管所在网段可访问外部扫描器也能读资产暴露面比预期大二是轮询间隔小于设备响应时间60 秒都超时这种超时要先看设备 CPU而不是加并发。三是 OID 报 No Such Instance多半是索引没对上而不是设备不支持。四是 Trap 丢失514/UDP 没有确认要在 snmptrapd 日志里看是否真的收到再考虑升级到 TCP/TLS。五是镜像目的端口带宽小于源端口抓包文件时间不连续先检查探针网卡rx_droppedethtool -S eth1 | grep rx_dropped如果持续增长先扩大镜像目的端口容量而不是加过滤条件。本文还有配套的精品资源点击获取 从SNMP到NetFlow：构建可落地的监控采集链路
简介以信息技术运维管理基础知识为主题的幻灯片学习教案面向运维入门者、技术培训讲师和希望系统梳理运维知识的学习者。内容围绕监控软件与采集协议展开涵盖SNMP、RMON、Syslog、Telnet/SSH、ODBC/JDBC、WMI等十余种常用协议并进一步讲解管理信息库MIB的树形结构、对象唯一标识OID、NetFlow流量分析以及基于交换机端口镜像和光口TAP的数据侦听方式同时列举网络设备、安全设备、主机、数据库、应用系统等常见监控对象以及CPU使用率、内存占用、网络流量、端口状态、磁盘空间、IO性能、系统日志、应用可用性等核心性能指标还涉及告警通知、故障定位和报表联动等运维环节。压缩包内共1个pptx文件约390KB图文版式便于课堂演示与自主学习。已有113人学习适合快速建立IT运维管理整体认知为后续运维监控部署、故障排查和自动化运维打下基础。1. IT运维管理基础监控协议选型与设备边界IT运维管理的门槛不在工具而在协议和数据的对应关系。很多团队已经部署了监控软件却依然在“CPU 100%但不知道哪台设备”“告警风暴”里打转本质是没有把性能指标压到正确的采集通道上。SNMP负责设备状态和流量计数器Syslog负责事件日志NetFlow负责流记录端口镜像和光口TAP负责原始报文。这套PPT学习教案把监控软件、系统设备、采集协议和性能指标串成了一条完整的链路下面按这条链路展开成可复现的配置和参数。适合刚接手机房监控的人也适合补协议边界的老手。这里不绑定某个具体厂商或软件只讲每个环节怎么选、怎么调、会踩哪些坑。2. 数据采集管线的四个支柱SNMP、Syslog、NetFlow 与探针从网络设备、安全设备、系统主机到数据库和应用软件单靠一种协议根本不现实。讲稿里列出了SNMP、RMON、Syslog、Event、Telnet/SSH、ODBC/JDBC、WMI、RCP、VBS、Agent、Scripts、xFlow、Probe和Collecter初看像名词堆砌实际是一条采集链路的分层设备对象层有CPU、内存、端口状态、磁盘和日志面向网络的协议层有SNMP/RMON、NetFlow/sFlow、Syslog面向主机的通道层有WMI、Agent/Scripts、SSH/Telnet面向外部环境的接入层通过Probe/Collector接入温湿度和电力。这个分层在工程上的意义是选型时先确认“监控对象提供什么数据出口”再决定用什么协议。比如数据库运行状态更多用JDBC/ODBC因为SNMP里没有MySQL的会话数而温湿度传感器通常走Modbus再转成SNMP Trap或自定义Agent。当前PPT列出的协议可以对映到下表。协议或机制常用端口/载体数据形态典型监控对象选型要点SNMP v1/v2c/v3161/UDP(轮询)、162/UDP(Trap)计数器、离散值CPU、内存、接口流量、端口状态、系统名设备支持最广但计数器回绕要处理RMON161/UDP RMON MIB历史统计和事件以太网流量、历史趋势兼容性下降多数厂商只在MIB保留Syslog514/UDP6514/TCPTLS事件文本系统日志、设备日志、应用日志不可靠传输生产环境要加TLS和队列NetFlow9995/9996/UDP 常见流记录流量组成、Top N 会话、路径分析依赖设备流缓存和导出策略WMITCP 135 动态RPC端口Windows类对象进程、服务、补丁、磁盘防火墙策略复杂需要放行RPC动态范围Agent/Scripts自定义端口、定时任务任意深度指标应用可用性、业务拨测被管端要装组件注意升级和权限表里几组容易混淆SNMP和Syslog是互补关系前者要主动去问后者由设备主动推送NetFlow和端口镜像也不同NetFlow给你的是聚合后的流记录镜像给你的是原始报文。按PPT里的说法“多种展示通过采集进行获取”所有拓扑、报表和告警都建立在上述数据通道上通道选错了后面再漂亮的仪表盘都是看着热闹。2.1 SNMP 轮询与 Trap从 GetRequest 到 MIB 树的 OID 定位SNMP 的模型非常明确网络管理工作站作为管理实体被管设备上运行 SNMP Agent两者通过 GetRequest、GetNextRequest、GetBulkRequest 和 SetRequest 交互正常响应是 GetResponse当设备遇到接口 DOWN、温度过高这类事件时Agent 主动向网管发 Trap。v1/v2c 用 community string 做口令v3 增加了用户名、认证和加密。PPT 里提到的 MIB-2、ISO、Organization、Internet、Management、Private 这些节点对应的是一个树形对象标识体系每个对象有唯一 OIDIAB 管理机构维护公共部分厂商维护 1.3.6.1.4.1 下的私有分支。实战中造不出 OID 时不要猜用 snmpwalk 直接扫子树。# 扫描系统组 MIB查看设备返回的全部系统对象 snmpwalk -v2c -c public -On 192.0.2.1 1.3.6.1.2.1.1 # 读取设备名称 snmpget -v2c -c public -On 192.0.2.1 1.3.6.1.2.1.1.5.0第一个命令列出系统组全部对象第二个命令只取系统名称。-On让输出直接显示数字 OID避免本机没有加载厂商 MIB 时显示成“SNMPv2-MIB::sysName.0”排查时对照手册更方便。-v2c指定版本-c public是社区字符串生产环境要换成只有只读权限的 community并把网管站地址写进 ACL。SNMPv3 的命令可以加-u monitor -l authPriv -a SHA -A authpass -x AES -X privpass优先级高于 v2c尤其在设备可以配置 SNMPv3 时不要偷懒用 v2c。Trap 接收端可以用 snmptrapd 验证# 前台运行并打印 Trap 日志调试完再交给 systemd 托管 snmptrapd -f -Lo -c /etc/snmp/snmptrapd.conf-f前台运行-Lo把日志打到标准输出-c指定配置文件。注意 Trap 默认走 162/UDP如果设备在跨网段需要在防火墙放行 UDP 162 入站否则会出现“设备日志里有发送记录网管收不到”的经典问题。2.2 Syslog 事件通道facility、severity 与 514/UDP 的取舍Syslog 与 SNMP 最大的不同是方向SNMP Trap 虽有主动语义但大部分数据还是轮询采集Syslog 则是设备主动把日志推到 NMS 或中央日志服务器。一条标准 Syslog 消息包含时间戳、facility、severity level、主机名和消息正文。Cisco IOS 的缺省记录级别是 debugging 到 emergencies 都写缓冲但生产环境通常只关心 error 及以上和认证事件。PPT 中的严重级别表是排查日志的标准索引数值关键字含义典型场景0Emergencies系统不可用设备断电、双主控同时挂1Alerts需要立即行动温度超过临界值2Critical严重故障电源或风扇失效3Errors错误CRC 错包、AAA 认证失败4Warnings警告端口利用率突增5Notifications正常但需注意配置变更、接口 up/down6Informational信息登录成功、定时任务执行7Debugging调试仅排障时开平时关设备侧最容易被忽略的是 facility 和日志目的地的搭配。Cisco IOS 上把日志送到远程服务器# 远程日志服务器地址使用 UDP 514 logging host 192.0.2.10 transport udp port 514 # 推送级别notifications 及以上 logging trap notifications # 使用 local6 facility方便日志服务器分文件存储 logging facility local6logging trap notifications表示级别 5 及以上会推送logging facility local6把设备日志归到 local6方便日志服务器按 facility 分文件。UDP 514 是历史遗留下来的轻量方案设备发送即忘高可用环境建议改用 TCP 6514 并用 TLS 加密否则网络抖动时日志会悄悄丢。这里要记住一个原则Syslog 适合分析“发生了什么”不适合做“当前状态是什么”后者还是回到 SNMP 轮询。2.3 NetFlow 流量数据Export Packet 结构与 NetFlow 配置NetFlow 把网络流量抽象成流记录一条流由七元组版本、源目地址、源目端口、协议、ToS、接口等定义。设备把流缓存中的记录打包成 Export Packet通过 UDP 发给 Collector。PPT 里写得很清楚每个 Export Packet 约 1500 字节通常包含 20 到 50 条 flow record当被监控接口流量增大时发送频率也随之提高。这个细节决定了 Collector 的容量规划——不是按设备数算而是按并发流数算。以 Cisco IOS 为例开启 NetFlow 导出# 设置 NetFlow 导出目标和 UDP 端口 ip flow-export destination 192.0.2.20 9995 ip flow-export version 5 ip flow-export source Loopback0 # 在接口下开启入方向和出方向的流采集 interface GigabitEthernet0/1 ip flow ingress ip flow egressip flow-export destination指定 Collector 地址和 UDP 端口常用 9995/9996version 5是固定格式支持基本五元组和字节包计数ip flow ingress/egress分别开启入方向和出方向的流采集。如果只在 interface 下配了 ingress出方向流量统计不到这是排查“明明有流量NetFlow 报表为空”时要看的第一个点。Traffic Collector 运行在 Solaris、HP-UX 或 Linux 上的常见实现是 nfdump 配合 nfcapd启动后能用nfdump -r查看历史文件。流量大时可以在接口下配 sampler例如每 1024 个包采样 1 个减少 CPU 消耗但小流和短连接会被采样掉需要业务场景权衡。2.4 其他采集手段WMI、Agent、Probe/Collector 的适用边界讲稿里还列出了 RMON、Event、Telnet/SSH、ODBC/JDBC、WMI、RCP、VBS、Agent、Scripts、xFlow、dataflow、Probe 和 Collecter。这些不是给同一类对象准备的数据库运行状态用 JDBC/ODBC 最直接例如通过 JDBC 连 Oracle 查 v$instanceWindows 主机性能用 WMI但要放行 RPC 动态端口交换机上的 RMON 在今天更多是历史 MIB 兼容Agent 装在主机上能拿到 SNMP 拿不到的进程级指标但会引入版本和补丁维护成本Probe/Collector 则常用来做分布式采集和业务拨测比如从多个节点探测同一个 Web 服务的可用性。工具套件和系统平台厂家会把这些协议封装成驱动但底层仍然是上面这些通道。选型时可以给一张决策表物理环境用探针存量网络设备用 SNMP事件审计用 Syslog主机深度指标用 Agent数据库用 JDBC/ODBC业务拨测用 Scripts/Probe。这样设计出来的采集层才不会因为“某个协议支持得最好”而绑死在一个厂商上。3. 构建一套可落地的采集与告警链路有了协议通道下一步是把它变成可运行的监控项。我不建议直接上手就是大而全的商业平台先按“设备发现→基础指标→告警路径”三步走把最小闭环跑通再扩展。PPT 里的“全局/多级网络拓扑”“配置信息/软硬件资产”属于展示层展示层的数据来源必须先回答一个问题设备是什么型号、运行什么系统、有哪些接口和序列号。这部分靠 SNMP 扫出来。3.1 设备发现与资产盘点用 SNMP 扫描建立初始台账网络层的设备发现通常用 CDP/LLDP 或 ARP 扫描但资产台账需要的是 sysName、sysDescr、序列号和软硬件版本。最常见的做法是在一个管理网段内做 SNMP 扫描先确认哪台 IP 有 SNMP 应答再补采细节#!/bin/bash # 扫描 192.0.2.0/24 中存在 SNMP 应答的设备 for ip in $(seq 1 254); do target192.0.2.$ip if snmpget -v2c -c public -t 1 -r 0 -On $target 1.3.6.1.2.1.1.1.0 /dev/null 21; then sysname$(snmpget -v2c -c public -On $target 1.3.6.1.2.1.1.5.0 2/dev/null | awk -F: {print $2}) echo $target $sysname fi done脚本先探测 1.3.6.1.2.1.1.1.0sysDescr有返回证明设备开了 SNMP再读取 1.3.6.1.2.1.1.5.0sysName。-t 1是单次超时设为 1 秒-r 0是不重试扫描一个 /24 时不至于因为个别设备无响应拖很久。生产环境不要用 public应该用只读 community并把范围控制在运维网段若设备支持 SNMPv3脚本里的参数改成-u monitor -l authPriv -a SHA -A *** -x AES -X ***。扫描结果写入 CMDB 或 Excel 台账后续拓扑发现和报表都从这里取主数据。3.2 性能指标采集CPU、内存、磁盘与端口状态的参数设计讲到性能指标PPT 把 CPU/内存使用率、网络流量/端口状态、磁盘空间/IO 性能、系统日志/设备日志、数据库运行状态、应用系统运行状态都列进了监控范围。其中网络流量部分要特别小心SNMP 的接口计数器是 Counter32/Counter64直接取当前值没有意义必须按时间差算速率还要处理计数器回绕。常见做法是用监控软件内置的 SNMP 计数器类型Zabbix 里把监控项类型设为“SNMPv2 counter”更新间隔 60 秒系统会自动算出每秒速率。下面是一组典型的 SNMP 监控项参数监控对象OID 示例类型更新间隔建议阈值系统名称1.3.6.1.2.1.1.5.0字符串3600s无接口入方向流量1.3.6.1.2.1.2.2.1.10.计数器60s按端口带宽 70% 告警接口出方向流量1.3.6.1.2.1.2.2.1.16.计数器60s按端口带宽 70% 告警接口状态1.3.6.1.2.1.2.2.1.8.离散值(1 up,2 down)60sdown 即告警CPU 利用率(Cisco 部分版本)1.3.6.1.4.1.9.9.109.1.1.1.1.8.数值60s连续 5 分钟 85%磁盘空间1.3.6.1.2.1.25.2.3.1.6.数值300s使用率 90%这张表只是为了说明参数设计不同厂商的 CPU 和磁盘 OID 差异很大上线前一定要用自己的设备型号验证一遍。验证方法是先snmpwalk到厂商私有分支找到对应对象的数值再写入监控项如果某个 OID 在设备上返回 No Such Instance不是网络问题而是该型号不支持或 OID 索引不对。索引通常是 ifIndex 或 hrStorageIndex同一台设备上接口表的索引与 CPU 表的索引不一定一致不能想当然套用。数据库和应用软件层的采集与网络设备不同MySQL 可以用mysql -u monitor -p -e SHOW GLOBAL STATUS LIKE Threads_connectedOracle 通过 JDBC 查询 v$sysstat这类指标走数据库客户端或 Agent不走 SNMP更新间隔可以放到 5 到 10 秒。3.3 告警路径声光、短信、邮件与运维管理系统联动采集到位后告警路径决定故障能不能被看见。PPT 里的“声光、短信、邮件”是三种不同优先级的通道声光用于机房现场短信用于值班人员邮件用于留痕。常用的做法是在监控平台里定义触发器再通过告警媒介把事件推出去。以 Zabbix 和通用 HTTP 接口为例#!/bin/bash # 放在 /usr/lib/zabbix/alertscripts/ 下脚本接收三个参数 API_KEY$1 MESSAGE$2 curl -s -X POST https://api.example.com/v2/alerts \ -H Authorization: GenieKey $API_KEY \ -H Content-Type: application/json \ -d {\message\:\$MESSAGE\}这个脚本把监控系统的告警消息转成第三方平台的 REST API 请求。Zabbix 在调用时会把{ALERT.SENDTO}、{ALERT.SUBJECT}、{ALERT.MESSAGE}映射为脚本参数所以$1可以放 API Key$2放消息体。实际配置短信时通常把短信网关的 URL 放到$1在脚本里再拼一部分内容声光告警则接一个支持 HTTP 控制的报警灯模块通过 curl 触发红灯和蜂鸣。告警要避免直接对原始指标设阈值而应该加持续时间条件比如 CPU 连续 5 分钟超过 85% 才触发否则一次 5 秒尖峰就会造成告警风暴。最后别忘记告警与运维管理系统联动生成事件单、绑定设备配置档案和最近变更记录才能真正做到“故障快速定位与预防”而不只是把消息发出去。4. 流量分析实战端口镜像与光口 TAP 的配置和排错监控系统要回答“设备有没有故障”流量分析要回答“网络里到底传了什么”。PPT 里用了两页讲数据侦听一页是基于交换机的端口镜像PC-3 接在镜像端口上装协议分析软件即可另一页是基于光口 TAP 的硬件探针。两套方案采集的都是原始报文但适用场景完全不同。4.1 交换机端口镜像monitor port 与 monitored port 的配置PPT 图里的 PORT-24 是被镜像端口monitored portPORT-18 是镜像端口monitor port。流经 PORT-24 的 PC-1 和 PC-2 双向数据都会被复制到 PORT-18接在 PORT-20 的 PC-3 只要能收到复制过来的流量就能做协议分析。Cisco IOS 的实现是本地 SPAN# 把 Gi0/24 双向流量镜像到 Gi0/18 monitor session 1 source interface Gi0/24 both monitor session 1 destination interface Gi0/18source interface指定被镜像的源端口both表示入方向和出方向都复制如果只需要抓服务器上行的攻击包可以改成rx。destination interface指定镜像目的端口接到分析机的网卡。如果交换机的镜像端口本身还跑着业务抓包结果会混入额外流量因此排查时优先找独立的空端口。另外把 10G 端口镜像到 1G 端口会丢包这是必然的镜像链路带宽必须不低于源端口带宽。在老的 CatOS 设备上命令完全不同常见的是set span 24 18 both意思是源端口 24目的端口 18双向。遇到不同厂商设备先看命令是monitor session风格还是set span风格不要凭 Cisco IOS 记忆去套所有交换机。端口镜像对交换机 CPU 和 ASIC 有一定开销高流量核心设备建议只在排障窗口临时开启不要长期全量镜像。4.2 光口 TAP 与硬件探针部署关键链路的无源采集端口镜像依赖交换机正确处理复制动作光口 TAP 则是在光纤链路上做物理分光把一部分光信号复制给探针。最大的优势是设备故障不影响主链路即使 TAP 掉电光路仍然直通。对于 WAN 出口和数据库集群之间的链路我一般优先考虑 TAP。硬件探针接在 TAP 的 RX 端把光信号转换成电口给采集服务器。采集侧常见的抓包命令# 抓链路数据包仅保存报文头减少磁盘占用 tcpdump -i eth1 -s 96 -nn -w /data/capture/20250222_1200.pcap-s 96只抓每个报文前 96 字节足够看到 IP 层和 TCP/UDP 头部用于会话分析时能大幅减少磁盘占用如果要分析应用层内容改为-s 0抓整包。-nn表示不做 DNS 反向解析也不把端口翻译成服务名避免抓包过程产生额外 DNS 查询。-w直接写 pcap后续用 Wireshark 打开。如果现场需要验证 TAP 是否工作先用tcpdump -i eth1 -c 100看是否有包进来如果持续无包检查 TAP 光口 RX 是否接反常见的原因是 TAP 设备的 RX/TX 交叉接线错误。4.3 用 NetFlow/sFlow 补充长期流量统计端口镜像和 TAP 能拿到最全的报文但存不了三个月。NetFlow 和 sFlow 的价值在于用很小的存储代价留住流量统计适合作长期趋势和容量规划。NetFlow 由设备维护流缓存sFlow 则是基于采样二者在实现上差异不小。我在核心交换机上通常同时开两个NetFlow 用于会话级分析和安全审计sFlow 用于整体流量水位。sFlow 配置示例# sFlow 源地址 sflow source 10.0.0.1 # 采样率每1024个包采样1个 sflow sampling-rate 1024 sflow collector-address 192.0.2.30 sflow collector-port 6343sampling-rate 1024表示每 1024 个包抽取 1 个包上报。采样率太高会漏掉带宽占用很小的长尾流量太低又带来设备开销一般从 512 到 1024 起步打开后对比 SNMP 接口流量偏差超过 20% 再调整。collector-address指向 sFlow Collector默认端口 6343。如果只看网络整体流量sFlow 够用如果要做 DDoS 溯源和会话追踪NetFlow 更合适。三类手段的定位可以简单对比如下手段数据粒度存储成本适用场景端口镜像原始报文极高排障、抓包、安全分析光口 TAP原始报文极高核心链路被动采集不依赖交换机NetFlow流记录聚合低长期流量趋势、Top N 会话sFlow采样包很低流量水位、端口利用率统计5. 运维报表与可用性统计公式、SQL 与踩坑清单PPT 最后落到了“网络和系统运行报表”“服务可用性统计报表”和“与运维管理系统联动”。报表能不能信取决于统计口径而不是图表好看。5.1 服务可用性的两种统计口径常见口径有三种但监控报表里最常用的是可用性 可用时间 / 统计周期。计算时要明确探测粒度例如每 5 分钟探测一次一个周期内最多有 288 个数据点只要某一次探测失败就认为对应 5 分钟不可用这会把一次 30 秒的闪断放大成 5 分钟不可用。另一种口径是质量指标比如 HTTP 平均响应时间小于 2 秒算可用适合应用层。PPT 里的“服务可用性统计”没有指明是哪一种所以做报表前要和业务统一口径不然同一个平台会算出两个可用性。5.2 从监控历史表生成月度可用性如果监控项本身返回 1/01 表示可用0 表示不可用可以直接用 Zabbix 的 trends 表聚合月报-- 按月份聚合 trends 表中的 1/0 监控项 SELECT DATE_FORMAT(FROM_UNIXTIME(clock), %Y-%m) AS month, ROUND(AVG(value_avg) * 100, 2) AS availability_pct FROM trends WHERE itemid 10001 AND clock UNIX_TIMESTAMP(2025-01-01) GROUP BY month;trends表保存的是小时级聚合value_avg是该小时内监控项的平均值。对 1/0 型监控项按小时平均后基本等于该小时可用比例。itemid替换成实际可用性探针的 ID如果探针返回的是响应时间而不是 0/1需要先写触发器把可用/不可用转换成 1/0再进这个 SQL。注意FROM_UNIXTIME(clock)的时区要和监控服务器时区一致否则月报边缘会出现偏移。5.3 常见误用与排查清单排障时最常碰到的问题按概率排序一是 community 用 public 且网管所在网段可访问外部扫描器也能读资产暴露面比预期大二是轮询间隔小于设备响应时间60 秒都超时这种超时要先看设备 CPU而不是加并发。三是 OID 报 No Such Instance多半是索引没对上而不是设备不支持。四是 Trap 丢失514/UDP 没有确认要在 snmptrapd 日志里看是否真的收到再考虑升级到 TCP/TLS。五是镜像目的端口带宽小于源端口抓包文件时间不连续先检查探针网卡rx_droppedethtool -S eth1 | grep rx_dropped如果持续增长先扩大镜像目的端口容量而不是加过滤条件。本文还有配套的精品资源点击获取