内网网络质量 ************* 实现内网基于机房、POD、机柜等多维度之间的网络质量采集。 采集侧 ============================ 采集原理 ~~~~~~~~~ 理想状态下，依赖于埋于每台服务器端的agent根据一定的算法去探测一批目标地址。这些探测目标可能是同POD内，跨POD，跨机房的。综合所有采集的数据， 计算出一个覆盖，机房、POD、机柜之间的网络情况。 鉴于当前服务器agent的覆盖度的问题。改为以一些源部分主机做限制 .. attention:: 因受限于目前服务器上的agent数量和分布的限制，第一个版本实现从部分采集器探测每个POD下的部分地址。 .. tip:: 可参考微软的 `PingMesh`_。 .. _PingMesh: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/11/pingmesh_sigcomm2015.pdf 采集任务参数配置要求 ~~~~~~~~~~~~~~~~~~~~ .. list-table:: :widths: auto :stub-columns: 1 :align: left * - **采集方式** - icmp ping * - **采集周期** - 次/5s, 每次1个请求报文 * - **返回值** - icmp replay * - **采集超时时间** - 默认2000ms * - **配置筛选条件** - 无 * - **特殊要求** - #. 对于被探测地址长时间不可达的实现自动替换地址，避免影响结果 #. 如果有新POD的上线，或者新的机房开通，需要自动发起采集（部分依赖于CMDB） 任务处理流程 ~~~~~~~~~~~~~~ a. 每个机房部署采集节点，对于新增机房，需要新增该的机房的采集器；严格来说这里的每个机房指的是一组LE设备下管辖的所有POD，因为一个物理DC可能有多组LE，他们之间是逻辑隔离的。 #. 从LE管辖范围的每个POD选择若干服务器地址（要求：每个/27位掩码的地址范围内只能随机取1-5个，每个POD不超过500个IP地址，也可根据性能选择总上限） #. 每个机房对这些地址做探测，对采集回来的值做处理 #. 对于长时间（比如30min）内，一个目标一致不能探测成功，认为该目标异常，需要从目标地址里剔除，重新的地址（优先从问题地址的/27掩码范围内选取，无可选项在随机虽则其他段的）。 采集值预处理 ~~~~~~~~~~~~~~~~ ping采集会出现两种情况，一是在超时时间内，收到target的response；二是在超时时间内没有收到target的response；两种情况做下述处理： a. 在超时时间内，收到target的response, 将该次采集值设置为0%(即丢包率为0），意味着探测成功； #. 超时时间内没有收到target的response, 将该次采集值设置为100%(即丢包率为100），意味着探测失败； #. 记录该数据包往返延时，当丢包率为100%时候，该值设置为0； #. 记录该数据包的TTL值，当丢包率为100%时候，该值设置为0； 数据染色 ~~~~~~~~~~~~~~~~ 对每条采集数据，染色如下。 a. 时间戳（采集时间） #. 源区域(地域) #. 源机房 #. 目标区域(地域) #. 目标机房 #. 目标POD #. 源探测IP地址 #. 目标IP #. 目标IP机柜 #. 丢包率 #. 延时 #. TTL 数据汇总 ~~~~~~~~~~~~~~~~ POD之间的丢包率汇总 ------------------- 数据最终期望的是某一个IP到另一个IP的丢包率，延时等信息。但目前没法做到这一步，如上数据采集的粒度，我们能推算的是POD-POD的丢包率，延时等信息。 实际上都不是严格的POD到POD，仅仅是采集器到POD这个维度。在此我们要将数据聚合成POD到POD的形式。其中一个主要原因是便于数据展示。 #. 对于任意两个POD，PODx --> PODy，丢包率，延时分别计算如下。下方中s代表采集器，和源PODx同机房。以每分钟维度来计算。 | 采集源s至PODx的丢包率为 :math:`L_{s \rightarrow x} = {C_{fail}\over{C_{total}}}` | 采集源s至PODy的丢包率为 :math:`L_{s \rightarrow y} = {C_{fail}\over{C_{total}}}` | PODx至PODy的丢包率为 :math:`L_{x \rightarrow y} = max \left \{ L_{s\rightarrow x},{L_{s\rightarrow y}}\right \}` | 采集源s至PODx的延时为 :math:`D_{s \rightarrow x} = sum(D_{all}/Count_{all-delay>0})` | 采集源s至PODy的延时为 :math:`D_{s \rightarrow y} = sum(D_{all}/Count_{all-delay>0})` | PODx至PODy的延时为 :math:`D_{x \rightarrow y} = D_{s \rightarrow x} + D_{s \rightarrow y}` 数据分析和报警 ================== 策略配置 ~~~~~~~~~~~~~~~~~ .. list-table:: :widths: auto :stub-columns: 1 :align: left * - **策略名** - #. 报警策略名字 * - **策略筛选条件** - #. 目的机房 #. 目标POD * - **策略生效时间** - 支持到小时级别（0-23） * - **阈值类型** - #. z-score值（具体后面描述） #. 延时大小 * - **触发阈值** - #. 概率P，即网络正常情况ping丢包率的成功率，这个是个固定值。具体后面描述(针对阈值类型为z-score的） #. Z-score值>=x，衡量丢包严重的阈值。（实数）。具体后面描述。(针对阈值类型为z-score的） #. 延时比历史均值增大比率M，且增量>N。(针对阈值类型为延时大小的） * - **恢复阈值** - #. 概率P，即网络正常情况ping丢包率的成功率，这个是个固定值。具体后面描述 #. Z-score值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的取值为PODx-->PODy探测结果中的总探测数，一分钟累计的。即以POD为单位计算。 .. warning:: 我们不直接计算m和n的比值是因为当n很大的时候，这个时候没有问题。但n很小的时候，m/n会严重受到噪声干扰，即可信度不高。另外一个问题是一次探测的时候，丢包不一定是网络引起的，因此引入概率去除这些噪声。 .. warning:: 概率p和z-score值需要一定的经验测试才能配置。实际情况是我们要根据历史数据做统计得出这两个值，而不是随便填写。 历史延时均值 ~~~~~~~~~~~~~~~~~~~~~ 因为延时的增减变化不合适用增幅，减幅这样的比列来描述，对于绝大多数基数比较的小的延时，稍微的变化就可能突破增幅、减幅设定的值。我们选择一个相对简单的方式定义一个均值。 这个均值代表着过去一段时间的延时情况。n代表着这段时间内所有的PODx-PODy的采集总数。 .. math:: E_{x \rightarrow y} = {1\over n}\sum_i^n {{D_{x \rightarrow y}}} 报警信息格式 ~~~~~~~~~~~~~~~~~~~~ 报警信息分为两种，一种是触发阈值告警，一种是满足恢复阈值告警。我们把它称之为告警状态，分为 ``告警`` ``恢复`` 。因为告警通道的的不同，为了便于阅读，需要针对不同渠道的报警设置信息格式。 .. code:: shell **如果合并多条发送，标题取阈值最高值的一条的信息** 邮件： ----------------------- 标题：【告警通知时间/恢复通知时间】【告警状态（告警/恢复）】【告警等级】【告警策略名】【目的机房，目的POD】 【有X个POD到目的POD丢包阈值大于/小于Z（z-score值）/延时超过/小于阈值Y（基数*比率+增量，或者对于恢复为历史均值+浮动阈值S）】 邮件内容： 故障开始时间, 故障持续时间，故障恢复时间（当且仅当告警状态为“恢复”时候才有该时间）， -----X个POD依次列出来----- 源区域，源机房，源POD，目的区域，目的机房，目的POD，当前阈值， 报警阈值 短信，咚咚，电话，微信： ------------------------ 【告警通知时间/恢复通知时间】【告警状态（告警/恢复）】【告警等级】【告警策略名】【目的机房，目的POD】 【有X个POD到目的POD丢包阈值大于/小于Z（z-score值）/延时超过/小于阈值Y（基数*比率+增量，或者对于恢复为历史均值+浮动阈值S）】【故障开始时间, 故障持续时间，故障恢复时间（当且仅当告警状态为“恢复”时候才有该时间）】 报警的默认收敛规则 ~~~~~~~~~~~~~~~~~~~~ 对重复的报警信息，实行收敛。 a. 策略触发后，会有多个源POD和目的POD都有触发阈值，所以需要将满足报警阈值的这批累计在一条信息里发送。 #. 如果在未满足恢复阈值前提条件下，再次触发了阈值，则该次触发的报警被抑制，不对外发送报警信息。但会涉及一些计数器的更新。 #. 只有所有源POD至目的POD的满足恢复阈值时候，才发送告警恢复信息。同时更新一些计数器。 #. 之后，如报警阈值被再次满足，则对外发送新的报警通知。 报警的聚合规则 ~~~~~~~~~~~~~~~~~~~~ 当出现一个机房内多个POD的同时报警，很可能的原因是专线或者一些边界设备有异常。所以这种情况下我们需要其他策略来满足这样的情况。所以需要和其他策略满足的条件下。 需要对一个机房内多个POD的同时报警这类做抑制。 关于报警时间的规则 ~~~~~~~~~~~~~~~~~~~~~~ 整个策略匹配过程及报警过程中，分别涉及多个时间，做如下说明。 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工单关闭或者自动触发恢复时候，从故障池子清除条目。不在故障池子里则认为恢复。 告警池字段要求如下： #. 故障开始时间 #. 故障持续时间 #. 源区域 #. 源机房 #. 源POD #. 目的区域 #. 目的机房 #. 目的POD #. 当前阈值 NOC工单状态说明 ~~~~~~~~~~~~~~~~~~ +---------------+----------+----------------------------------+ | NOC返回状态值 | 状态 | 说明 | +---------------+----------+----------------------------------+ | 1 | 新工单 | 告警事件生成工单的初始状态 | +---------------+----------+----------------------------------+ | 10 | 待处理 | NOC人员接单后触发这个状态 | +---------------+----------+----------------------------------+ | 20 | 处理中 | NOC人员进行处理操作 | +---------------+----------+----------------------------------+ | 21 | 已转派 | NOC人员处理不了转派给网络运维 | +---------------+----------+----------------------------------+ | 99 | 已取消 | NOC人员进行取消操作 | +---------------+----------+----------------------------------+ | 100 | 已完成 | NOC人员进行跟进确认后触发该状态 | +---------------+----------+----------------------------------+ | 101 | 自动恢复 | 这个是根据告警这边的恢复通知生成 | +---------------+----------+----------------------------------+ 可视化 ================== 以源机房+源POD，目的机房+目的POD维度展示POD之间的阈值情况。 #. 以矩阵的形式展示POD之间的丢包情况和延时两个维度信息； #. 配合报警阈值的设备，用不同颜色展示满足报警阈值的POD； #. 因为POD的数量很大，需要考虑容易展示和友好交互的事情； #. 提供在展示页连接今对单个POD的情况详情页的连接。 以PODx-->PODy的为的角度。展示丢包、延时、z-score值 #. 以Y轴为PODx-->PODy的丢包、延时、z-score值，X轴为时间。展示三个维度的数据。 #. 标注出延时和z-score的告警阈值线 #. 可以鼠标选择一个片段内的时间的原始采集值信息。 以单个采集源-->目标IP地址维度，展示单个IP的延时、丢包、TTL数据信息 #. 以Y轴为采集源-->目标IP的丢包、延时、TTL，X轴为时间。展示三个维度的数据。 未完成的部分 ================== #. 尚未开始