内网专线网络质量
*****************

实现内网DCI专线之间的网络质量采集和报警。

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

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

数据来源于内网质量监控中的跨DC的采集数据。我们使用DCx至DCy之间的所有采集数据来定义DC之间专线流量。

鉴于当前服务器agent的覆盖度的问题。改为以一些源部分主机做限制


数据汇总
~~~~~~~~~~~~~~~~

DC之间的丢包率汇总
-------------------

需要汇总DCx和DCy之间的数据来作为DCx-DCy的丢包率，延时等信息。假设采集源s处于DCx，则使用源s至目标DCy的所有数据为基础数据。

#. 对于任意两个DC，DCx --> DCy，丢包率，延时分别计算如下。下方中s代表采集器，和源DCx同机房。以每分钟维度来计算。

 | DCx至DCy的丢包率为 :math:`L_{s \rightarrow y} = {C_{fail}\over{C_{total}}}`
 | DCx至DCy的延时为 :math:`D_{s \rightarrow y} =  sum(D_{all}/Count_{all-delay>0})`

和专线的关联
-------------------

我们需要将DCx-DCy关联至DCx-DCy之间的专线上。注意正常情况下，数据是双向的。DCx至DCy，和DCy-DCx不能混合。会出现四种情况。
情况1：DCx-DCy之间有实际的专线，且DCx和DCy两个数据中心之间有采集数据；
情况2：DCx-DCy之间有实际的专线，且DCx和DCy两个数据中心之间只有单向有采集数据（即DCx至DCy有采集数据，但DCy至DCx没有采集数据）；
情况3：DCx-DCy之间并没有实际的专线；
情况4：DCx-DCy之间有专线，但DCx和DCy两个数据中心之间没有采集数据；

#. 情况1，根据采集源所在的DC和专线落地两端的DC做自动匹配关联；
#. 情况2，根据采集源所在的DC和专线落地两端的DC做自动匹配关联；
#. 情况3，则忽略；
#. 情况4，需要额外提供一个专线和两端采集器之间的一个关联表，以此作为数据和专线的关联；


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

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

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

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

    * - **策略筛选条件**
      - #. 源DC
        #. 目标DC

    * - **策略生效时间**
      - 支持到小时级别（0-23）

    * - **阈值类型**
      - #. z-score值（具体后面描述）
        #. 延时大小

    * - **触发阈值**
      - #. 概率P，即网络正常情况ping丢包率的成功率，这个是个固定值。具体后面描述(针对阈值类型为z-score的）
        #. Z-score值>=x，衡量丢包严重的阈值。（实数）。具体后面描述。(针对阈值类型为z-score的）
        #. 延时比历史均值增大比率M，且增量>N。(针对阈值类型为延时大小的）

    * - **恢复阈值**
      - #. 概率P，即网络正常情况ping丢包率的成功率，这个是个固定值。具体后面描述
        #. Z-score值<x，衡量丢包严重的阈值。（实数）。具体后面描述
        #. 延时<=历史均值+浮动阈值S。(针对阈值类型为延时大小的）

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

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

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


z-score策略阈值说明
~~~~~~~~~~~~~~~~~~~~~

因为我们选择的是服务器IP作为目标，所以当个别服务器故障或者有问题时候，并不代表网络就有问题。另外，正常情况下，也会出现探测不通的情况。
所以要对这个事件做一个概率统计，设备p。即每次采集的时候，有概率p成功，有1-p的概率失败。那么，n次采集中有m次成功的概率即为

.. math:: P(X=m) = C^m_n p^m(1-p)^{n-m}

所以判断一批采集中网络是不是有问题即可转化为：如果m太小，就认为网络有问题。即求二项分布的积累分布：:math:`P(X\leq m) = \sum_{i=1}^{n}{C^i_n p^i(1-p)^{n-i}}`
因为m的值跟每次采集的n有关系，没法转化为固定值。同时上述计算量会很大。当二项分布的n很大的时候（n>100)，标准化后的二项分布可以近似为方差为1，均值为0的正态分布。
这里我们不直接极端积累分布的值，因为计算量也很大。我们直接计算m在标准化后的值。即下式：

.. math:: z_0 = {{m-np}\over \sqrt{{np(1-p)}}}

:math:`z_0` 是标准化后的值，叫z分数(z-score)。所以我们给定一个 :math:`z_0` 就代表着给定了一个m和n的比值。我们只要判断m在标准化后是不是低于 :math:`z_0`，即认为网络整。反之则异常。
n的取值为DCx-->DCy探测结果中的总探测数，一分钟累计的。即以DC为单位计算。

.. warning:: 我们不直接计算m和n的比值是因为当n很大的时候，这个时候没有问题。但n很小的时候，m/n会严重受到噪声干扰，即可信度不高。另外一个问题是一次探测的时候，丢包不一定是网络引起的，因此引入概率去除这些噪声。

.. warning:: 概率p和z-score值需要一定的经验测试才能配置。实际情况是我们要根据历史数据做统计得出这两个值，而不是随便填写。


历史延时均值
~~~~~~~~~~~~~~~~~~~~~

因为延时的增减变化不合适用增幅，减幅这样的比列来描述，对于绝大多数基数比较的小的延时，稍微的变化就可能突破增幅、减幅设定的值。我们选择一个相对简单的方式定义一个均值。
这个均值代表着过去一段时间的延时情况。n代表着这段时间内所有的DCx-DCy的采集总数。

.. math:: E_{x \rightarrow y} = {1\over n}\sum_i^n {{D_{x \rightarrow y}}}


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

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

.. code:: shell

  **如果合并多条发送，标题取阈值最高值的一条的信息**

  邮件：
  -----------------------
  标题：【告警通知时间/恢复通知时间】【告警状态（告警/恢复）】【告警等级】【告警策略名】【专线名】
       【丢包阈值大于/小于Z（z-score值）/延时超过/小于阈值Y（基数*比率+增量，或者对于恢复为历史均值+浮动阈值S）】
  邮件内容：
  故障开始时间, 故障持续时间，故障恢复时间（当且仅当告警状态为“恢复”时候才有该时间），
  源区域，源机房，源DC，目的区域，目的DC，专线名，当前阈值，报警阈值


  短信，咚咚，电话，微信：
  ------------------------
  【告警通知时间/恢复通知时间】【告警状态（告警/恢复）】【告警等级】【告警策略名】【专线名】
  【丢包阈值大于/小于Z（z-score值）/延时超过/小于阈值Y（基数*比率+增量，或者对于恢复为历史均值+浮动阈值S）】【故障开始时间, 故障持续时间，故障恢复时间（当且仅当告警状态为“恢复”时候才有该时间）】


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

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

a. 策略触发后，可能DCx至DCy，DCy至DCx同时触发阈值，需要合并发送信息。
#. 如果在未满足恢复阈值前提条件下，再次触发了阈值，则该次触发的报警被抑制，不对外发送报警信息。但会涉及一些计数器的更新。
#. 只有所有源DC至目的DC的满足恢复阈值时候，才发送告警恢复信息。同时更新一些计数器。
#. 之后，如报警阈值被再次满足，则对外发送新的报警通知。


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

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

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工单关闭或者自动触发恢复时候，从故障池子清除条目。不在故障池子里则认为恢复。


告警池字段要求如下：

#. 故障开始时间
#. 故障持续时间
#. 源区域
#. 源机房
#. 源DC
#. 目的区域
#. 目的机房
#. 目的DC
#. 专线名
#. 当前阈值

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

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



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

以源机房+源DC，目的机房+目的DC维度展示DC之间的阈值情况。

#. 以矩阵的形式展示DC之间的丢包情况和延时两个维度信息；
#. 配合报警阈值的设备，用不同颜色展示满足报警阈值的DC；
#. 因为DC的数量很大，需要考虑容易展示和友好交互的事情；
#. 提供在展示页连接今对单个DC的情况详情页的连接。


以DCx-->DCy（专线维度）的角度。展示丢包、延时、z-score值

#. 以Y轴为DCx-->DCy的丢包、延时、z-score值，X轴为时间。展示三个维度的数据。
#. 标注出延时和z-score的告警阈值线
#. 可以鼠标选择一个片段内的时间的原始采集值信息。

以单个采集源-->目标IP地址维度，展示单个IP的延时、丢包、TTL数据信息

#. 以Y轴为采集源-->目标IP的丢包、延时、TTL，X轴为时间。展示三个维度的数据。



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

#. 尚未开始