设备ARP条目数¶
获取交换的交换机ARP数目。
采集侧¶
采集原理¶
采集器通过周期性地登录设备执行命令，然后解析返回，提取出ARP条目数。
小技巧
为避免开发工作量比较大，目前只需要实现思科Nexus、H3C、Huawei几个品牌的抓取即可。
注意
不同的交换机需要执行的命令不一样，有时候统一品牌的不通软件版本也略有差异。输出的结果也是各不相同的。需要区别对待。
采集任务参数配置要求¶
采集方式 |
SSH模拟登陆 |
|---|---|
执行的命令 |
|
返回值 |
|
采集超时时间 |
默认20000ms |
采集周期 |
次/30min |
配置筛选条件 |
|
特殊要求 |
|
任务筛选条件的互斥关系¶
机房–POD–设备IP，存在父子关系，当父节点未被选中或者是多选状态下，子节点不能继续选择；当且仅当机房、POD、同时处于单选状态下方可继续选择设备IP；
区域–机房，存在父子关系，当父节点未被选中或者是多选状态下，子节点不能继续选择；
设备IP地址仅仅可以在没有任何其他项勾选的情况下，才可以支持手工输入多个IP地址，或者多个地址段；
任务处理流程¶
从筛选条件中筛选出符合要求的设备；设备优先使用带内IP地址作为目标地址去采集，如果没有带内地址，则使用带外去采集。
将筛选出的设备，设置采集周期；
对上述设备执行下发任务至指定的采集节点（包括人工指定，和按同一个机房使用本机房的采集器两种方式，后一种为默认行为）；
对于不能通过自动下发任务至同机房采集器的任务，下发任务至默认的采集器去采集；
采集器执行SSH登录执行命令任务，当请求报文发出去之后。如果超时时间内（默认 2000ms）没有收到返回，认为登录超时，此时刻没有数据。如果有返回，将返回值做预处理。
采集值预处理¶
采集会有二类情形，一是ssh登录设备超时，没有取回结果；二是登录成功且获取回数据。
如果ssh登录设备超时，则本次采集为空，即这个时刻没有采集数据，不做任何数据的补充，不能标记为0值等；
解析返回值，取出返回值中的
ARP条目数，记为 \(C_{used}\)从CMDB中获取对应设备的ARP可用总数目，记为 \(C_{total}\)
计算出使用率， 即 \(C_{used} \over C_{total}\)
数据染色¶
对每条采集数据，染色如下。
时间戳（采集时间）
业务线
区域(地域)
机房
POD
房间
机柜
业务属性（服务角色）
设备角色
带内管理IP
带外管理IP
设备名
厂商
设备品牌
设备型号
设备流程状态
ARP使用率
ARP使用条目
设备ARP条目采集示例¶
如下是一台华为设备的ARP条目数的抓取信息，执行命令display arp statistics，输出结果选取: Dynamic: 19465 为ARP条目数。
<MJQ_POD4_CORE_209-C-13_209-D-13>display arp statistics
Dynamic: 19465 (Resolved: 18204 Incomplete: 1261) Static: 0
数据分析和报警¶
策略配置¶
策略名 |
|
|---|---|
策略筛选条件 |
|
策略生效时间 |
支持到小时级别（0-23） |
触发阈值 |
使用率>=N%（N为整数）。 |
恢复阈值 |
使用率小于M%（M为整数）,默认M=N |
策略生效状态 |
默认为策略生效状态，开启时源数据进入告警分析模块进行计算和比对，禁用时源数据不进行告警分析 |
策略告警等级 |
用于标识该策略的告警重要性程度，分5个等级：A1严重，A3主要，A5次要，A7一般，A9通知 |
告警组和通知方式 |
|
策略筛选条件的互斥关系¶
IP地址类型是必选项；其他都需要支持多选；但在有父子关系情况下，如果父节点被多选，子节点不能继续被多选。
机房–POD–设备IP，存在父子关系，当父节点未被选中或者是多选状态下，子节点不能继续选择；当且仅当机房、POD同时处于单选状态下方可继续选择设备IP；
区域–机房，存在父子关系，当父节点未被选中或者是多选状态下，子节点不能继续选择；
设备IP地址仅仅可以在没有任何其他项勾选的情况下，才可以支持手工输入多个IP地址，或者多个地址段；
报警信息格式¶
报警信息分为两种，一种是触发阈值告警，一种是满足恢复阈值告警。我们把它称之为告警状态，分为 告警 恢复 。因为告警通道的的不通，为了便于阅读。需要针对不同渠道的报警设置信息格式。
邮件：
-----------------------
标题：【告警通知时间/恢复通知时间】【告警状态（告警/恢复）】【告警等级】【告警策略名】【机房，POD，角色，设备IP，ARP使用率】
邮件内容：
故障开始时间, 故障持续时间，故障恢复时间（当且仅当告警状态为“恢复”时候才有该时间），
业务线，区域，机房，POD，业务属性，设备角色, 设备IP，设备名称
当前ARP使用率，当前ARP条目数
短信，咚咚，电话，微信：
------------------------
【告警通知时间/恢复通知时间】【告警状态（告警/恢复）】【告警状态（告警/恢复）】【告警等级】【告警策略名】
【机房，POD，角色，设备IP，设备名称】【当前ARP使用率，当前ARP条目数】
【故障开始时间, 故障持续时间，故障恢复时间（当且仅当告警状态为“恢复”时候才有该时间）】
报警的默认收敛规则¶
对重复的报警信息，实行收敛。
即一条策略被触发后，发送报警通知。同时更新一些计数器。
如果在未满足恢复阈值前提条件下，再次触发了阈值，则该次触发的报警被抑制，不对外发送报警信息。但会涉及一些计数器的更新。
当满足恢复阈值时候，发送告警恢复信息。同时更新一些计数器。
之后，如报警阈值被再次满足，则对外发送新的报警通知。
关于报警时间的规则¶
整个策略匹配过程及报警过程中，分别涉及多个时间，做如下说明。
1.故障开始时间：第一次触发阈值（满足告警阈值的第一个点的时间） 2.故障触发告警时间：满足告警频次达到告警条件 3.告警通知时间：告警平台对外发送告警通知的时间 4.聚合告警通知时间：故障触发告警时间满足告警聚合周期，多条告警聚合后的由告警平台发出的告警通知时间（仅仅在有聚合报警策略的情况下），有4没有3。 –以下仅针对有恢复的策略– 5.故障持续时间：未恢复的告警，从故障开始时间计算到当前时间点的时间段，在告警实时看板中展示；恢复的告警，故障持续时长=故障恢复时间-故障开 始时间； 6.故障恢复时间：第一个满足恢复条件的时间，通常只有在触发了第7个“故障触发恢复条件时间”时才会被记录 7.故障触发恢复条件时间：满足恢复阈值和频次达到恢复条件 8.恢复通知时间：告警平台发送恢复通知的时间 9.聚合恢复通知时间：故障触发恢复时间满足恢复聚合周期，告警平台发出的恢复通知时间（仅仅在有聚合报警策略的情况下），有9没有8
和NOC工单系统的联动¶
对于产生的故障告警，需要推送给NOC工单进入工单管理。需要根据工单返回结果对该告警做一个标记，表示目前关于此告警的工单的处理情况。
处理规则：
对于产生的告警（而非进行聚合后的告警，即聚合前的单条告警。），需要推送给NOC工单平台，根据noc平台的返回信息对该条告警设置一个
工单状态标记。当NOC工单对该单条告警改变了状态，需要同步的跟新报警系统中该条报警的
工单状态标记；当NOC工单标记为“已完成”，则触发告警恢复，忽略掉恢复阈值的检测，对外发送告警恢复信息；同时这条告警彻底清除，即便真实情况下告警并未恢复。
如果告警恢复阈值检测到满足，则触发告警恢复信息，同时通知NOC工单平台修改该工单状态为”已完成”, 关闭工单。
故障池（故障看板）的联动¶
但每条告警产生的时候，将该告警加入一个告警池。在告警池中对该条告警的状态进行跟踪。包括三个方面的状态跟踪。 故障持续时间，24小时内触发次数，NOC工单状态，故障恢复与否。
故障持续时间：当前时间-故障开始时间。 24小时内触发次数：最近一天满足触发阈值的次数-1。 NOC工单状态：NOC工单的状态信息。 故障恢复与否：但手工对NOC工单关闭或者自动触发恢复时候，从故障池子清除条目。不在故障池子里则认为恢复。
告警池字段要求如下：
故障开始时间
故障持续时间
设备IP
ARP使用条目
ARP使用率
设备角色
业务线
机房
历史告警数（24H）
NOC工单状态
NOC工单状态说明¶
NOC返回状态值 |
状态 |
说明 |
1 |
新工单 |
告警事件生成工单的初始状态 |
10 |
待处理 |
NOC人员接单后触发这个状态 |
20 |
处理中 |
NOC人员进行处理操作 |
21 |
已转派 |
NOC人员处理不了转派给网络运维 |
99 |
已取消 |
NOC人员进行取消操作 |
100 |
已完成 |
NOC人员进行跟进确认后触发该状态 |
101 |
自动恢复 |
这个是根据告警这边的恢复通知生成 |
可视化¶
针对单台设备，对一段时间内的设备ARP使用率做可视化。要求如下。
以横坐标为时间轴，纵坐标为使用率/ARP使用条目数。刻画设备ARP使用率及使用量。每个采集时刻一个数据点。
展示设备的总ARP条目数，以红线等方式绘图于坐标图中；
默认展示一个小时的使用率信息；
未完成的部分¶
完全未完成