设备接口DROP包

获取交换机接口DROP包。

采集侧

采集原理

采集器通过周期性的查询交换机的端口当前的DROP报文的统计总数。

注意

华为设备采集返回值是每个端口的8个队列的计数，需要对8个队列的数据做累加作为端口的Drop值。思科设备需要同时采集出入两个方向

采集任务参数配置要求

采集方式

SNMP

SNMP OID

  1. H3C: 1.3.6.1.2.1.2.2.1.19[出向]

  2. Huawei: 1.3.6.1.4.1.2011.5.25.32.4.1.4.3.3.1.8[出向]

  3. Cisco: 1.3.6.1.2.1.2.2.1.13[入向]， 1.3.6.1.2.1.2.2.1.19[出向]（不区分Nexus和Catalyst系列）

  4. RuiJie: 1.3.6.1.2.1.2.2.1.19[出向]

  5. Juniper: 1.3.6.1.2.1.2.2.1.19[出向]

返回值

累计流量的DROP报文总数, 华为返回是每个接口下8个队列的drop值；注意: 华为返回值类型为Counter64, 其他返回值类型为Counter32

采集超时时间

默认10000ms

采集周期

次/5min

配置筛选条件

  1. 业务线

  2. 区域(地域)

  3. 机房

  4. POD

  5. 业务属性（服务角色）

  6. 设备角色

  7. 设备IP、IP地址段

特殊要求

  1. 使用同一机房的采集去采集该机房的设备存活状态，如果该机房没有采集器，使用一组指定的默认采集器去采集

  2. 支持手动指定某一些IP地址（ip地址段）使用特定的采集器

任务处理流程

  1. 从筛选条件中筛选出符合要求的设备；设备优先使用带内IP地址作为目标地址去采集，如果没有带内地址，则使用带外去采集。

  2. 将筛选出的设备，设置采集周期；

  3. 对上述设备执行下发任务至指定的采集节点（包括人工指定，和按同一个机房使用本机房的采集器两种方式，后一种为默认行为）；

  4. 对于不能通过自动下发任务至同机房采集器的任务，下发任务至默认的采集器去采集；

  5. 采集器执行采集任务，当请求报文发出去之后。如果超时时间内（默认 10000ms）没有收到返回，认为设备没有返回。

采集值预处理

采集会有二类情形，一是采集超时，没有取回结果；二是采集正常。

  1. 采集超时，没有取回结果时，则本次采集为空，即这个时刻没有采集数据，不做任何数据的补充，不能标记为0值等；

  2. 解析返回值，取出返回值中的index和对应的端口DROP报文累计值。具体如下方所示。

  3. 将本次采集值减去上一次采集值的绝对值，作为 DROP报文增量值 。（这里考虑到复杂处理，我们不额外处理计数器溢出导致的情况） \(C_{increase} = C_{current} - C_{last}\)

  4. 将 DROP报文增量值 换算为平均每分钟增量。 \(C_{inc/min} = C_{increase}/SampleInterval\)

  5. 通过index逆向从CMDB中解析出端口名字

SNMP请求返回值为oid和DROP包值的对应关系。需要从oid中截取部分为ifindex。最终表示为 ifindex = 返回值。

H3C

截取最后一位为ifindex。如：.1.3.6.1.2.1.2.2.1.19. 14333 = 0;

Huawei
截取倒数第三位为ifindex，并且将相同ifindex的返回值累加赋值给ifindex。如：
.1.3.6.1.4.1.2011.5.25.32.4.1.4.3.3.1.8. 112 .0.1 = 17785
.1.3.6.1.4.1.2011.5.25.32.4.1.4.3.3.1.8. 112 .0.2 = 22571
.1.3.6.1.4.1.2011.5.25.32.4.1.4.3.3.1.8. 112 .0.3 = 9682
.1.3.6.1.4.1.2011.5.25.32.4.1.4.3.3.1.8. 112 .0.4 = 0
.1.3.6.1.4.1.2011.5.25.32.4.1.4.3.3.1.8. 112 .0.5 = 0
.1.3.6.1.4.1.2011.5.25.32.4.1.4.3.3.1.8. 112 .0.6 = 0
.1.3.6.1.4.1.2011.5.25.32.4.1.4.3.3.1.8. 112 .0.7 = 2
.1.3.6.1.4.1.2011.5.25.32.4.1.4.3.3.1.8. 112 .0.8 = 67

Cisco

截取最后一位为ifindex。如：.1.3.6.1.2.1.2.2.1.13. 438386688 = 2795086。

RuiJie

截取最后一位为ifindex。如：.1.3.6.1.2.1.2.2.1.19. 95 = 0;。

Juniper

截取最后一位为ifindex。如：.1.3.6.1.2.1.2.2.1.19. 45 = 0;。

设备DROP包数采集示例

如下是一台思科的DROP包数采集示例。“ifInDiscards.”后面的数值为接口的ifindex，“=”右边的即每个端口的Drop包数。

[linux ~]$ snmpwalk -c 360buy -v 2c 172.20.0.11 1.3.6.1.2.1.2.2.1.13
.1.3.6.1.2.1.2.2.1.13.438398976 = 13258473
.1.3.6.1.2.1.2.2.1.13.439353344 = 1298
.1.3.6.1.2.1.2.2.1.13.439357440 = 2842
.1.3.6.1.2.1.2.2.1.13.439361536 = 39761
.1.3.6.1.2.1.2.2.1.13.439365632 = 0
.1.3.6.1.2.1.2.2.1.13.439369728 = 16158
.1.3.6.1.2.1.2.2.1.13.439373824 = 0
.1.3.6.1.2.1.2.2.1.13.439377920 = 0
.1.3.6.1.2.1.2.2.1.13.439382016 = 0
.1.3.6.1.2.1.2.2.1.13.439386112 = 0
.1.3.6.1.2.1.2.2.1.13.439390208 = 0
.1.3.6.1.2.1.2.2.1.13.439394304 = 2899
.1.3.6.1.2.1.2.2.1.13.439398400 = 2580

如下是一台华为的DROP包数采集示例。需要把8个队列的包数加和，“=”右边的即每个队列的丢包数。如下ifindex为112端口的drop包数即8个队列的累加50107。

[linux ~]$ snmpwalk -c 360buy -v 2c 172.20.0.1 1.3.6.1.4.1.2011.5.25.32.4.1.4.3.3.1.8
...ommited...
.1.3.6.1.4.1.2011.5.25.32.4.1.4.3.3.1.8.112.0.1 = 17785
.1.3.6.1.4.1.2011.5.25.32.4.1.4.3.3.1.8.112.0.2 = 22571
.1.3.6.1.4.1.2011.5.25.32.4.1.4.3.3.1.8.112.0.3 = 9682
.1.3.6.1.4.1.2011.5.25.32.4.1.4.3.3.1.8.112.0.4 = 0
.1.3.6.1.4.1.2011.5.25.32.4.1.4.3.3.1.8.112.0.5 = 0
.1.3.6.1.4.1.2011.5.25.32.4.1.4.3.3.1.8.112.0.6 = 0
.1.3.6.1.4.1.2011.5.25.32.4.1.4.3.3.1.8.112.0.7 = 2
.1.3.6.1.4.1.2011.5.25.32.4.1.4.3.3.1.8.112.0.8 = 67

数据染色

对每条采集数据，染色如下。

  1. 时间戳（采集时间）

  2. 业务线

  3. 区域(地域)

  4. 机房

  5. POD

  6. 房间

  7. 机柜

  8. 业务属性（服务角色）

  9. 设备角色

  10. 带内管理IP

  11. 带外管理IP

  12. 设备名

  13. 厂商

  14. 设备品牌

  15. 设备型号

  16. 设备流程状态

  17. 端口index

  18. 端口名

  19. 端口DROP报文当前值

  20. 端口DROP报文增量

  21. 端口DROP报文每分钟增量

  22. 丢包方向

数据分析和报警

策略配置

警告

下述配置的一个前提条件是针对染色数据 设备流程状态 为 在线 的执行阈值匹配。如不是，则直接略过。

策略名

  1. 报警策略名字

策略筛选条件

  1. 业务线

  2. 区域(地域)

  3. 机房

  4. POD

  5. 业务属性（服务角色）

  6. 设备角色

  7. 设备IP、IP地址段

  8. 端口名

  9. 丢包方向

策略生效时间

支持到小时级别（0-23）

触发阈值

M分钟内使用率>=N%达到S次（M,N,S为整数）。

恢复阈值

X分钟内使用率<Y%达到X次（X,Y,Z为整数）。默认X=M， Y=N，Z=S

策略生效状态

默认为策略生效状态，开启时源数据进入告警分析模块进行计算和比对，禁用时源数据不进行告警分析

策略告警等级

用于标识该策略的告警重要性程度，分5个等级：A1严重，A3主要，A5次要，A7一般，A9通知

告警组和通知方式

  1. 告警组，将不同人员分成不同的组，按组的方式发送告警；

  2. 通知方式：邮件、咚咚、微信、短信、电话；针对每个组可多选或者不选；

策略筛选条件的互斥关系

  1. 端口名不能单独选择，必须在单选设备IP情况下才能选择对应设备的端口。

  2. 机房–POD–设备IP–端口名，存在父子关系，当父节点未被选中或者是多选状态下，子节点不能继续选择；当且仅当机房、POD同时处于单选状态下方可继续选择设备IP；

  3. 区域–机房，存在父子关系，当父节点未被选中或者是多选状态下，子节点不能继续选择；

  4. 设备IP地址仅仅可以在没有任何其他项勾选的情况下，才可以支持手工输入多个IP地址，或者多个地址段；

报警信息格式

报警信息分为两种，一种是触发阈值告警，一种是满足恢复阈值告警。我们把它称之为告警状态，分为 告警 恢复 。因为告警通道的的不通，为了便于阅读。需要针对不同渠道的报警设置信息格式。

邮件：
-----------------------
标题：【告警通知时间/恢复通知时间】【告警状态（告警/恢复）】【告警等级】【告警策略名】【机房，POD，角色，设备IP，设备名，端口，丢包方向，最近一次DROP报文每分钟增量】
邮件内容：
故障开始时间, 故障持续时间，故障恢复时间（当且仅当告警状态为“恢复”时候才有该时间），
业务线，区域，机房，POD，业务属性，设备角色, 设备IP，设备名称
最近一次DROP报文每分钟增量


短信，咚咚，电话，微信：
------------------------
【告警通知时间/恢复通知时间】【告警状态（告警/恢复）】【告警状态（告警/恢复）】【告警等级】【告警策略名】
【机房，POD，角色，设备IP，设备名称，端口，丢包方向】【最近一次DROP报文每分钟增量】
【故障开始时间, 故障持续时间，故障恢复时间（当且仅当告警状态为“恢复”时候才有该时间）】

报警的默认收敛规则

对重复的报警信息，实行收敛。

  1. 即一条策略被触发后，发送报警通知。同时更新一些计数器。

  2. 如果在未满足恢复阈值前提条件下，再次触发了阈值，则该次触发的报警被抑制，不对外发送报警信息。但会涉及一些计数器的更新。

  3. 当满足恢复阈值时候，发送告警恢复信息。同时更新一些计数器。

  4. 之后，如报警阈值被再次满足，则对外发送新的报警通知。

关于报警时间的规则

整个策略匹配过程及报警过程中，分别涉及多个时间，做如下说明。

1.故障开始时间：第一次触发阈值（满足告警阈值的第一个点的时间） 2.故障触发告警时间：满足告警频次达到告警条件 3.告警通知时间：告警平台对外发送告警通知的时间 4.聚合告警通知时间：故障触发告警时间满足告警聚合周期，多条告警聚合后的由告警平台发出的告警通知时间（仅仅在有聚合报警策略的情况下），有4没有3。 –以下仅针对有恢复的策略– 5.故障持续时间：未恢复的告警，从故障开始时间计算到当前时间点的时间段，在告警实时看板中展示；恢复的告警，故障持续时长=故障恢复时间-故障开 始时间； 6.故障恢复时间：第一个满足恢复条件的时间，通常只有在触发了第7个“故障触发恢复条件时间”时才会被记录 7.故障触发恢复条件时间：满足恢复阈值和频次达到恢复条件 8.恢复通知时间：告警平台发送恢复通知的时间 9.聚合恢复通知时间：故障触发恢复时间满足恢复聚合周期，告警平台发出的恢复通知时间（仅仅在有聚合报警策略的情况下），有9没有8

和NOC工单系统的联动

对于产生的故障告警，需要推送给NOC工单进入工单管理。需要根据工单返回结果对该告警做一个标记，表示目前关于此告警的工单的处理情况。

处理规则：

  1. 对于产生的告警（而非进行聚合后的告警，即聚合前的单条告警。），需要推送给NOC工单平台，根据noc平台的返回信息对该条告警设置一个 工单状态标记 。

  2. 当NOC工单对该单条告警改变了状态，需要同步的跟新报警系统中该条报警的 工单状态标记 ；

  3. 当NOC工单标记为“已完成”，则触发告警恢复，忽略掉恢复阈值的检测，对外发送告警恢复信息；同时这条告警彻底清除，即便真实情况下告警并未恢复。

  4. 如果告警恢复阈值检测到满足，则触发告警恢复信息，同时通知NOC工单平台修改该工单状态为”已完成”, 关闭工单。

故障池（故障看板）的联动

但每条告警产生的时候，将该告警加入一个告警池。在告警池中对该条告警的状态进行跟踪。包括三个方面的状态跟踪。 故障持续时间，24小时内触发次数，NOC工单状态，故障恢复与否。

故障持续时间：当前时间-故障开始时间。 24小时内触发次数：最近一天满足触发阈值的次数-1。 NOC工单状态：NOC工单的状态信息。 故障恢复与否：但手工对NOC工单关闭或者自动触发恢复时候，从故障池子清除条目。不在故障池子里则认为恢复。

告警池字段要求如下：

  1. 故障开始时间

  2. 故障持续时间

  3. 设备IP

  4. 端口名

  5. DROP报文每分钟增长量

  6. 丢包方向

  7. 设备角色

  8. 业务线

  9. 机房

  10. 历史告警数（24H）

  11. NOC工单状态

NOC工单状态说明

NOC返回状态值

状态

说明

1

新工单

告警事件生成工单的初始状态

10

待处理

NOC人员接单后触发这个状态

20

处理中

NOC人员进行处理操作

21

已转派

NOC人员处理不了转派给网络运维

99

已取消

NOC人员进行取消操作

100

已完成

NOC人员进行跟进确认后触发该状态

101

自动恢复

这个是根据告警这边的恢复通知生成

可视化

针对单台设备，对一段时间内指定端口名和其端口的状态。要求如下。

  1. 以横坐标为时间轴，纵坐标为DROP报文累计值和每分钟增量。刻画设备每个端口的DROP报文数目端口状态变化。

  2. 默认展示一个小时的使用率信息；

针对单台设备，对某一时刻所有端口名和其端口的状态。要求如下。

  1. 以表格形式展示，每行一个端口和对应的丢包方向、端口DROP报文累计数、DROP报文增量、端口DROP报文的采集时间

  2. 如果所选时刻没有对应时刻的端口状态信息，则取最近一次采集值

  3. 支持对端口名、DROP报文累计数、DROP报文增量来排序

针对多有设备、一个机房、一个POD、一台设备，在一段时间内DROP报文增量TOP N排名。

  1. 以表格形式展示，每行一个端口和对应的丢包方向、端口DROP报文累计数、DROP报文增量、端口DROP报文的采集时间。还包括其他额外的信息：机房、POD、设备IP、设备名、设备角色。

  2. 为减少数据计算量，DROP报文累计数、DROP报文增量可以用时间段内最后一条和最开始的一条数据的 DROP报文当前值 差值来计算(忽略掉计数器溢出带来的误差)。

  3. 也可以使用时间段内每条数据的累加后平均计算（准确性较高）。

  4. 默认TOP20

报表

统计一天内DROP报文增量大于10000的数据输出报表。包括如下信息。

  1. 业务线

  2. 区域(地域)

  3. 机房

  4. POD

  5. 房间

  6. 机柜

  7. 业务属性（服务角色）

  8. 设备角色

  9. 带内管理IP

  10. 带外管理IP

  11. 设备名

  12. 厂商

  13. 设备品牌

  14. 设备型号

  15. 设备流程状态

  16. 端口index

  17. 端口名

  18. 端口DROP报文总增量

  19. 丢包方向

未完成的部分

  1. 自助任务下发；

  2. 策略的分级，即按类似ACL的方式匹配策略；需求未提

  3. 实现业务线的支持，或者所是多用户的支持；