设备存活

主要是监控设备是否可到达。通过周期性的对设备做ping，通过ping是否收到返回来确认设备的状态。

采集侧

采集原理

采集器发送ping请求，如果在超时时间内，没有收到设备的ping Respone。则认为该次探测任务失败。 对本次采集的结果标记为失败，或者丢包100%。

采集任务参数配置要求

采集方式

ping

采集周期

次/3s, 每次1个请求报文

返回值

丢包率，0 或者 100%

采集超时时间

默认2000ms

任务筛选条件

  1. 业务线

  2. 区域(地域)

  3. 机房

  4. POD

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

  6. 设备角色

  7. IP地址类型（带内，带外）

  8. 设备IP、IP地址段

特殊要求

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

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

任务筛选条件的互斥关系

  1. IP地址类型是必选项；其他都需要支持多选；但在有父子关系情况下，如果父节点被多选，子节点不能继续被多选。

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

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

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

采集任务处理流程

  1. 从筛选条件中筛选出符合要求的设备；

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

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

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

  5. 采集器执行ping任务，当请求报文发出去之后。如果超时时间内（默认 2000ms）没有收到返回，认为设备没有返回。将本次采集结果设置为丢包率100%。否则，则设置为0%。

采集值预处理

ping采集会出现两种情况，一是在超时时间内，收到target的response；二是在超时时间内没有收到target的response；两种情况做下述处理：

  1. 在超时时间内，收到target的response, 将该次采集值设置为0%(即丢包率为0），意味着探测成功；

  2. 超时时间内没有收到target的response, 将该次采集值设置为100%(即丢包率为100），意味着探测失败；

数据染色

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

  1. 时间戳（采集时间）

  2. 业务线

  3. 区域(地域)

  4. 机房

  5. POD

  6. 房间

  7. 机柜

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

  9. 设备角色

  10. 带内管理IP

  11. 带外管理IP

  12. 设备名

  13. 厂商

  14. 设备品牌

  15. 设备型号

  16. 设备流程状态

  17. 探活丢包率

  18. 探测IP地址类型（带内、带外）

数据分析和报警

策略配置

警告

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

策略名

  1. 报警策略名字

策略筛选条件

  1. 业务线

  2. 区域(地域)

  3. 机房

  4. POD

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

  6. 设备角色

  7. IP地址类型（带内，带外）

  8. 设备IP、IP地址段

策略生效时间

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

触发阈值
连续N次（3S/次）丢包100%，N为正整数。
连续的计算方式举例：N=10，第1-10个点丢包率是100%为触发阈值；
如果第1个点丢包0%第2-11丢包100%为触发阈值，第1-2个点丢包0%第3-12丢包100%为触发阈值。

恢复阈值

连续N次（3S/次）丢包0%，N为正整数

策略生效状态

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

策略告警等级

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

告警组和通知方式

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

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

策略筛选条件的互斥关系

  1. IP地址类型是必选项；其他都需要支持多选；但在有父子关系情况下，如果父节点被多选，子节点不能继续被多选。

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

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

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

报警信息格式

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

邮件：
-----------------------
标题：【告警通知时间/恢复通知时间】【告警状态（告警/恢复）】【告警等级】【告警策略名】【IP地址类型（带内，带外），角色，设备IP】
邮件内容：
故障开始时间, 故障持续时间，故障恢复时间（当且仅当告警状态为“恢复”时候才有该时间），
业务线，区域，机房，POD，业务属性，设备角色, IP地址类型，设备IP，设备名称


短信，咚咚，电话，微信：
------------------------
【告警通知时间/恢复通知时间】【告警状态（告警/恢复）】【告警状态（告警/恢复）】【告警等级】【告警策略名】
【机房，POD，IP地址类型（带内，带外），角色，设备IP，设备名称】【故障开始时间, 故障持续时间，故障恢复时间（当且仅当告警状态为“恢复”时候才有该时间）】

报警的默认收敛规则

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

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

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

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

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

报警的聚合规则

因所属场景下存在同机房大批量的设备报警的情况，所以需要对一个时间段内的报警做聚合，封装在一封告警通知里对外发送，对应的，告警信息的格式也有所改变。 同样，在报警恢复的时候，也会面临这大批量的报警恢复这样的情况。也做同样的处理。 遵循如下规则：

  1. 当一条告警触发时候（包括告警和恢复两种类型，但要分别对这两种类型做聚合），等待15s钟；

  2. 如果15s内收到的 相同的策略名 和报警设备字段里 机房 相同，则聚合到一条报警信息里；重新开始新一轮计时。

  3. 如果 相同的策略名 和 机房 字段不相同，则聚合；

  4. 对于聚合组里只有1个条目的（也就是说15s内只有一条报警），则按单条的报警信息格式发送报警；

  5. 否则，则按聚合类型的报警信息格式发送报警， 格式见下方。

邮件格式：
-----------------------
标题：【聚合告警通知时间/聚合告警恢复时间】【告警状态（告警/恢复）】【告警等级】【告警策略名】【{xx机房}有N台设备不存活/恢复正常】
邮件内容：
---------依次将每台设备的信息列出， 如下-----------
故障开始时间, 故障持续时间，故障恢复时间（当且仅当告警状态为“恢复”时候才有该时间），业务线，区域，机房，POD，业务属性，设备角色, IP地址类型，设备IP，设备名称



短信，咚咚，电话，微信：
------------------------
标题：【聚合告警通知时间/聚合告警恢复时间】【告警状态（告警/恢复）】【告警等级】【告警策略名】【{xx机房}有N台设备不存活/恢复正常】

关于报警时间的规则

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

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. 业务线

  6. 机房

  7. 历史告警数（24H）

  8. NOC工单状太

NOC工单状态说明

NOC返回状态值

状态

说明

1

新工单

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

10

待处理

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

20

处理中

NOC人员进行处理操作

21

已转派

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

99

已取消

NOC人员进行取消操作

100

已完成

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

101

自动恢复

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

可视化

针对单台设备，对一段时间内的设备探活丢包率做可视化。要求如下。

  1. 以横坐标为时间轴，纵坐标为丢包率。刻画设备丢包率。每个采集时刻一个数据点。

  2. 默认展示一个小时的丢包率信息；

  3. 在时间轴上标记处触发告警的的时间点；

未完成的部分

  1. 自助任务下发；

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

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

  4. 报警的合并，即报警时候同时带出带内带外的状态，带内带外报警合并在一条。需求未提。