公网网络质量 *************** 实现从每个机房的不同网络出口至各个省份不同运营商的网络丢包率监控。 采集侧 ============================ 采集原理 ~~~~~~~~~ 从每个机房的每个出口（联通、电信、移动、BGP、代播）的源地址去探测每个省份联通、电信、移动三个不同运营商的地址。从而得到互联网出口到这些省份的丢包和延时。 鉴于当前服务器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 * - **配置筛选条件** - 无 * - **特殊要求** - #. 每个省份每个运营商至少5个IP地址作为目标 #. 自有机房作为一个独立的目标，即XX机房+xx出口也作为一个探测目标 任务处理流程 ~~~~~~~~~~~~~~ a. 每个机房部署采集节点，对于新增机房，需要新增该的机房的采集器； #. 对每组目标，选取一批目标IP地址。执行探测。 #. 采集器执行ping任务，当请求报文发出去之后。如果超时时间内（默认 2000ms）没有收到返回，认为设备没有返回。将本次采集结果设置为丢包率100%。否则，则设置为0%。 目标IP的选择 ~~~~~~~~~~~~~~~~~~~~~ 目标IP有两部分，一部分是从各个省份选取的。一部分是从自有机房出口地址池中选择的。 #. 从各个省份的选择的地址，我们从DNS团队的提供的API中获TOP5的地址，剔除不可达地址作为目标地址。不足5个的继续选择，直到满足5个。 #. 自有机房的，选择LB团队的各个运营商的VIP地址作为目标地址。 采集值预处理 ~~~~~~~~~~~~~~~~ ping采集会出现两种情况，一是在超时时间内，收到target的response；二是在超时时间内没有收到target的response；两种情况做下述处理： a. 在超时时间内，收到target的response, 将该次采集值设置为0%(即丢包率为0），意味着探测成功； #. 超时时间内没有收到target的response, 将该次采集值设置为100%(即丢包率为100），意味着探测失败； #. 记录该数据包往返延时，当丢包率为100%时候，该值设置为0； #. 记录该数据包的TTL值，当丢包率为100%时候，该值设置为0； 数据染色 ~~~~~~~~~~~~~~~~ 对每条采集数据，染色如下。 a. 时间戳（采集时间） #. 源机房 #. 源出口提供商 #. 源出口类型（电信、移动、联通等等） #. 源IP地址 #. 目标省份/机房 #. 目标出口类型（电信、移动、联通等等） #. 目标IP #. 丢包率 #. 延时 #. TTL 数据汇总 ~~~~~~~~~~~~~~~~ 实际我们需要的是某个源IP到目标地址集的一个丢包率和延时汇总。我们以每个省份/机房+每个运营商维度做数据聚合。如北京马驹桥电信出口-北京市电信。以每分钟的维度来计算。 | 采集源s至目标t的丢包率为 :math:`L_{s \rightarrow t} = {C_{fail}\over{C_{total}}}` | 采集源s至目标t的延时为 :math:`D_{s \rightarrow t} = sum(D_{all}/Count_{all-delay>0})` | TTL不处理 数据分析和报警 ================== .. warning:: 公网的阈值类型我们不选择和内网的类型，如Z-score，这种计算方式。因为公网质量很不可控，很难估算一个合理的概率p。所以我们会选择历史均值这种更容易的操作方式。 鉴于公网的复杂性，质量不是一直持续稳定，我们需要支持如某个出口到多少个省份异常才算网络质量异常。同时对持续时间也要作为考量因素。 历史均值计算 ~~~~~~~~~~~~~~~~~~ 对于每个目标组（比如北京市电信），对其过去7天内（以自然日算，不过实时计算）所有的丢包率和延时做均值统计（延时需要剔除丢包为100%的这些）。对于丢包率，这个均值会有两种情况。 有可能为0%，或者100%。这样对后面做阈值控制时候我们就很难处理。比如阈值为0，则一旦突破这个阈值就会触发报警。当阈值为100，不管如何，都没法触及这个封顶的阈值。 所以我们针对丢包率，会做两个限制，下限(a)和上限(b)。如下。当丢包率大于L时候，我们认为该目标组网络异常。 .. math:: L = {\left\{\begin{matrix} a, L' \leq a; \\ L', a=M;(异常的省份，运营商类型-同运营商：同运营商统计；运营商类型-跨运营商：非同运营商统计） #. 丢包率下限a：A；（*仅仅针对出口维度*） #. 丢包率上限b: B;（*仅仅针对出口维度*） #. 丢包率阈值>=N；（*仅仅针对省份维度*, 我们使用固定阈值，不是动态阈值，**后期去掉**） * - **告警升级** - #. 故障持续时间>S (S>=满足连续x次的时间)；通知第一联系组 #. 故障持续时间>R (R>=S)；通知第二联系组 #. 故障持续时间>T (T>=R)；通知第三联系组 #. 故障每持续时间U；通知第一联系组 * - **恢复阈值** - 连续触发V次为满足触发阈值。 * - **策略生效状态** - 默认为策略生效状态，开启时源数据进入告警分析模块进行计算和比对，禁用时源数据不进行告警分析 * - **策略告警等级** - #. 用于标识该策略的告警重要性程度，分5个等级：A1严重，A3主要，A5次要，A7一般，A9通知 #. 故障持续时间>S (S>=满足连续x次的时间)的等级； #. 故障持续时间>R (R>=S)的等级； #. 故障持续时间>T (T>=R)的等级； #. 故障每持续时间U；已持续时间最长的等级为准。 * - **告警组和通知方式** - #. 告警组，将不同人员分成不同的组，按组的方式发送告警； #. 通知方式：邮件、咚咚、微信、短信、电话；针对每个组可多选或者不选； #. **这里需要支持3个不通联系人组，作为告警升级的不同联系人。** 报警信息格式 ~~~~~~~~~~~~~~~~~~~~ 报警信息分为两种，一种是触发阈值告警，一种是满足恢复阈值告警。我们把它称之为告警状态，分为 ``告警`` ``恢复`` 。因为告警通道的的不同，为了便于阅读，需要针对不同渠道的报警设置信息格式。 .. code:: shell 邮件： ----------------------- 标题：【告警通知时间/恢复通知时间】【告警状态（告警/恢复）】【告警等级】【告警策略名】【同运营商/跨运营商】 【X出口到有N个省份网络质量异常】 邮件内容： 故障开始时间, 故障持续时间，故障恢复时间（当且仅当告警状态为“恢复”时候才有该时间）， -----N个省份依次列出来----- 探测时间，源机房，源IP地址，目的省份，目的IP地址，当前丢包率，当前延时，报警丢包率阈值 短信，咚咚，电话，微信： ------------------------ 【告警通知时间/恢复通知时间】【告警状态（告警/恢复）】【告警等级】【告警策略名】【同运营商/跨运营商】 【X出口到有N个省份网络质量异常】【故障开始时间, 故障持续时间，故障恢复时间（当且仅当告警状态为“恢复”时候才有该时间）】 报警的默认收敛规则 ~~~~~~~~~~~~~~~~~~~~ 对同一个报警级别的重复报警信息，实行收敛。 a. 策略触发后，会随着时间增长，可能触发升级，触发则对外发送告警，再未满足持续时间之内，不继续发送。 #. 满足恢复阈值时候，发送告警恢复信息。 #. 之后，如报警阈值被再次满足，则对外发送新的报警通知。 关于报警时间的规则 ~~~~~~~~~~~~~~~~~~~~~~ 整个策略匹配过程及报警过程中，分别涉及多个时间，做如下说明。 1.故障开始时间：第一次触发阈值（满足告警阈值的第一个点的时间） 2.故障触发告警时间：满足告警频次达到告警条件 3.告警通知时间：告警平台对外发送告警通知的时间 4.聚合告警通知时间：故障触发告警时间满足告警聚合周期，多条告警聚合后的由告警平台发出的告警通知时间（仅仅在有聚合报警策略的情况下），有4没有3。 --以下仅针对有恢复的策略-- 5.故障持续时间：未恢复的告警，从故障开始时间计算到当前时间点的时间段，在告警实时看板中展示；恢复的告警，故障持续时长=故障恢复时间-故障开 始时间； 6.故障恢复时间：第一个满足恢复条件的时间，通常只有在触发了第7个“故障触发恢复条件时间”时才会被记录 7.故障触发恢复条件时间：满足恢复阈值和频次达到恢复条件 8.恢复通知时间：告警平台发送恢复通知的时间 9.聚合恢复通知时间：故障触发恢复时间满足恢复聚合周期，告警平台发出的恢复通知时间（仅仅在有聚合报警策略的情况下），有9没有8 和NOC工单系统的联动 ~~~~~~~~~~~~~~~~~~~~~~~ 对于产生的故障告警，需要推送给NOC工单进入工单管理。需要根据工单返回结果对该告警做一个标记，表示目前关于此告警的工单的处理情况。 处理规则： #. 对于产生的告警（而非进行聚合后的告警，即聚合前的单条告警。），同时满足一定告警级别，需要推送给NOC工单平台，根据noc平台的返回信息对该条告警设置一个 ``工单状态标记`` 。 #. 当有告警升级的情况下，如果有相同级别的告警触发，noc工单只能记录一次。 #. 当NOC工单对该单条告警改变了状态，需要同步的跟新报警系统中该条报警的 ``工单状态标记`` ； #. 当NOC工单标记为“已完成”，则触发告警恢复，忽略掉恢复阈值的检测，对外发送告警恢复信息；同时这条告警彻底清除，即便真实情况下告警并未恢复。 #. 如果告警恢复阈值检测到满足，则触发告警恢复信息，同时通知NOC工单平台修改该工单状态为"已完成", 关闭工单。 故障池（故障看板）的联动 ~~~~~~~~~~~~~~~~~~~~~~~~~ 但每条告警产生的时候，将该告警加入一个告警池。不通告警级别的告警只能存在告警池子中一条。在告警池中对该条告警的状态进行跟踪。包括三个方面的状态跟踪。 故障持续时间，24小时内触发次数，NOC工单状态，故障恢复与否。 故障持续时间：当前时间-故障开始时间。 24小时内触发次数：最近一天满足触发阈值的次数-1。 NOC工单状态：NOC工单的状态信息。 故障恢复与否：但手工对NOC工单关闭或者自动触发恢复时候，从故障池子清除条目。不在故障池子里则认为恢复。 告警池字段要求如下： #. 故障开始时间 #. 故障持续时间 #. 源机房 #. 源出口提供商 #. 运营商类型（同运营商，跨运营商） #. 简略表述（如网络异常） NOC工单状态说明 ~~~~~~~~~~~~~~~~~~ +---------------+----------+----------------------------------+ | NOC返回状态值 | 状态 | 说明 | +---------------+----------+----------------------------------+ | 1 | 新工单 | 告警事件生成工单的初始状态 | +---------------+----------+----------------------------------+ | 10 | 待处理 | NOC人员接单后触发这个状态 | +---------------+----------+----------------------------------+ | 20 | 处理中 | NOC人员进行处理操作 | +---------------+----------+----------------------------------+ | 21 | 已转派 | NOC人员处理不了转派给网络运维 | +---------------+----------+----------------------------------+ | 99 | 已取消 | NOC人员进行取消操作 | +---------------+----------+----------------------------------+ | 100 | 已完成 | NOC人员进行跟进确认后触发该状态 | +---------------+----------+----------------------------------+ | 101 | 自动恢复 | 这个是根据告警这边的恢复通知生成 | +---------------+----------+----------------------------------+ 可视化 ================== 以源机房，目的省份/机房维度展示出口和其他地区之间的网络丢包情况。 #. 以矩阵的形式展示出口和省份/机房之间的丢包情况和延时两个维度信息； #. 配合报警阈值的设备，用不同颜色展示满足报警阈值的省份/机房； #. 提供在展示页连接今对单个省份/机房的情况详情页的连接。 以单个出口至某个省份的维度。展示丢包、延时值 #. 以Y轴为丢包、延时，X轴为时间。展示二个维度的数据。 #. 标注出丢包率的告警阈值线 #. 可以鼠标选择一个片段内的时间的原始采集值信息。 以单个采集源-->目标IP地址维度，展示单个IP的延时、丢包、TTL数据信息 #. 以Y轴为采集源-->目标IP的丢包、延时、TTL，X轴为时间。展示三个维度的数据。