设备接口DROP包
***************

获取交换机接口DROP包。


采集侧
==================

采集原理
~~~~~~~~~

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

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


采集任务参数配置要求
~~~~~~~~~~~~~~~~~~~~

.. list-table::
    :widths: auto
    :stub-columns: 1
    :align: left

    * - **采集方式**
      - SNMP

    * - **SNMP OID**
      - #. H3C: 1.3.6.1.2.1.2.2.1.19[出向]
        #. Huawei: 1.3.6.1.4.1.2011.5.25.32.4.1.4.3.3.1.8[出向]
        #. Cisco: 1.3.6.1.2.1.2.2.1.13[入向]， 1.3.6.1.2.1.2.2.1.19[出向]（不区分Nexus和Catalyst系列）
        #. RuiJie: 1.3.6.1.2.1.2.2.1.19[出向]
        #. Juniper: 1.3.6.1.2.1.2.2.1.19[出向]

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

    * - **采集超时时间**
      - 默认10000ms

    * - **采集周期**
      - 次/5min

    * - **配置筛选条件**
      - #. 业务线
        #. 区域(地域)
        #. 机房
        #. POD
        #. 业务属性（服务角色）
        #. 设备角色
        #. 设备IP、IP地址段

    * - **特殊要求**
      - #. 使用同一机房的采集去采集该机房的设备存活状态，如果该机房没有采集器，使用一组指定的默认采集器去采集
        #. 支持手动指定某一些IP地址（ip地址段）使用特定的采集器


任务处理流程
~~~~~~~~~~~~~~

a. 从筛选条件中筛选出符合要求的设备；设备优先使用带内IP地址作为目标地址去采集，如果没有带内地址，则使用带外去采集。
#. 将筛选出的设备，设置采集周期；
#. 对上述设备执行下发任务至指定的采集节点（包括人工指定，和按同一个机房使用本机房的采集器两种方式，后一种为默认行为）；
#. 对于不能通过自动下发任务至同机房采集器的任务，下发任务至默认的采集器去采集；
#. 采集器执行采集任务，当请求报文发出去之后。如果超时时间内（默认 10000ms）没有收到返回，认为设备没有返回。



采集值预处理
~~~~~~~~~~~~~~~~

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

a. 采集超时，没有取回结果时，则本次采集为空，即这个时刻没有采集数据，不做任何数据的补充，不能标记为0值等；
#. 解析返回值，取出返回值中的index和对应的端口DROP报文累计值。具体如下方所示。
#. 将本次采集值减去上一次采集值的绝对值，作为 ``DROP报文增量值`` 。（这里考虑到复杂处理，我们不额外处理计数器溢出导致的情况） :math:`C_{increase} = C_{current} - C_{last}`
#. 将 ``DROP报文增量值`` 换算为平均每分钟增量。 :math:`C_{inc/min} = C_{increase}/SampleInterval`
#. 通过index逆向从CMDB中解析出端口名字 

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

.. list-table::
    :widths: auto
    :stub-columns: 1
    :align: left

    * - **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包数。

.. code-block:: shell

    [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。

.. code-block:: shell

    [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


数据染色
~~~~~~~~~~~~~~~~

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

a. 时间戳（采集时间）
#. 业务线
#. 区域(地域)
#. 机房
#. POD
#. 房间
#. 机柜
#. 业务属性（服务角色）
#. 设备角色
#. 带内管理IP
#. 带外管理IP
#. 设备名
#. 厂商
#. 设备品牌
#. 设备型号
#. 设备流程状态
#. 端口index
#. 端口名
#. 端口DROP报文当前值
#. 端口DROP报文增量
#. 端口DROP报文每分钟增量
#. 丢包方向

数据分析和报警
==================

策略配置
~~~~~~~~~~~~~~~~~

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

.. list-table::
    :widths: auto
    :stub-columns: 1
    :align: left

    * - **策略名**
      - #. 报警策略名字

    * - **策略筛选条件**
      - #. 业务线
        #. 区域(地域)
        #. 机房
        #. POD
        #. 业务属性（服务角色）
        #. 设备角色
        #. 设备IP、IP地址段
        #. 端口名
        #. 丢包方向

    * - **策略生效时间**
      - 支持到小时级别（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通知

    * - **告警组和通知方式**
      - #. 告警组，将不同人员分成不同的组，按组的方式发送告警；
        #. 通知方式：邮件、咚咚、微信、短信、电话；针对每个组可多选或者不选；


策略筛选条件的互斥关系
~~~~~~~~~~~~~~~~~~~~~~~~

a. 端口名不能单独选择，必须在单选设备IP情况下才能选择对应设备的端口。
#. 机房--POD--设备IP--端口名，存在父子关系，当父节点未被选中或者是多选状态下，子节点不能继续选择；当且仅当机房、POD同时处于单选状态下方可继续选择设备IP；
#. 区域--机房，存在父子关系，当父节点未被选中或者是多选状态下，子节点不能继续选择；
#. 设备IP地址仅仅可以在没有任何其他项勾选的情况下，才可以支持手工输入多个IP地址，或者多个地址段；


报警信息格式
~~~~~~~~~~~~~~~~~~~~

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

.. code:: shell

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


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


报警的默认收敛规则
~~~~~~~~~~~~~~~~~~~~

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

a. 即一条策略被触发后，发送报警通知。同时更新一些计数器。
#. 如果在未满足恢复阈值前提条件下，再次触发了阈值，则该次触发的报警被抑制，不对外发送报警信息。但会涉及一些计数器的更新。
#. 当满足恢复阈值时候，发送告警恢复信息。同时更新一些计数器。
#. 之后，如报警阈值被再次满足，则对外发送新的报警通知。

关于报警时间的规则
~~~~~~~~~~~~~~~~~~~~~~

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

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
#. 端口名
#. DROP报文每分钟增长量
#. 丢包方向
#. 设备角色
#. 业务线
#. 机房
#. 历史告警数（24H）
#. NOC工单状态

NOC工单状态说明
~~~~~~~~~~~~~~~~~~

+---------------+----------+----------------------------------+
| NOC返回状态值 | 状态     | 说明                             |
+---------------+----------+----------------------------------+
| 1             | 新工单   | 告警事件生成工单的初始状态       |
+---------------+----------+----------------------------------+
| 10            | 待处理   | NOC人员接单后触发这个状态        |
+---------------+----------+----------------------------------+
| 20            | 处理中   | NOC人员进行处理操作              |
+---------------+----------+----------------------------------+
| 21            | 已转派   | NOC人员处理不了转派给网络运维    |
+---------------+----------+----------------------------------+
| 99            | 已取消   | NOC人员进行取消操作              |
+---------------+----------+----------------------------------+
| 100           | 已完成   | NOC人员进行跟进确认后触发该状态  |
+---------------+----------+----------------------------------+
| 101           | 自动恢复 | 这个是根据告警这边的恢复通知生成 |
+---------------+----------+----------------------------------+


可视化
==================

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

#. 以横坐标为时间轴，纵坐标为DROP报文累计值和每分钟增量。刻画设备每个端口的DROP报文数目端口状态变化。
#. 默认展示一个小时的使用率信息；

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

#. 以表格形式展示，每行一个端口和对应的丢包方向、端口DROP报文累计数、DROP报文增量、端口DROP报文的采集时间
#. 如果所选时刻没有对应时刻的端口状态信息，则取最近一次采集值
#. 支持对端口名、DROP报文累计数、DROP报文增量来排序

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

#. 以表格形式展示，每行一个端口和对应的丢包方向、端口DROP报文累计数、DROP报文增量、端口DROP报文的采集时间。还包括其他额外的信息：机房、POD、设备IP、设备名、设备角色。
#. 为减少数据计算量，DROP报文累计数、DROP报文增量可以用时间段内最后一条和最开始的一条数据的 ``DROP报文当前值`` 差值来计算(忽略掉计数器溢出带来的误差)。
#. 也可以使用时间段内每条数据的累加后平均计算（准确性较高）。
#. 默认TOP20


报表
====================

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

#. 业务线
#. 区域(地域)
#. 机房
#. POD
#. 房间
#. 机柜
#. 业务属性（服务角色）
#. 设备角色
#. 带内管理IP
#. 带外管理IP
#. 设备名
#. 厂商
#. 设备品牌
#. 设备型号
#. 设备流程状态
#. 端口index
#. 端口名
#. 端口DROP报文总增量
#. 丢包方向



未完成的部分
==================

#. 自助任务下发；
#. 策略的分级，即按类似ACL的方式匹配策略；需求未提
#. 实现业务线的支持，或者所是多用户的支持；