智能运维

【今日推荐】：为什么一到面试就懵逼！>>> 本文作者：AIOps智能运维 在之前的系列文章《百度网络监控实战：NetRadar横空出世》中，我们介绍了百度内网质量监测平台NetRadar的原理和架构，其中， 判障算法 是内网监测系统的重要一环，今天我们将详细介绍在NetRadar中实际使用的一种判障算法——基于二项分布的网络判障算法。 业务场景 我们的内网监测系统 NetRadar 实时对百度内网连通性进行探测并根据探测数据判断是否存在网络故障。以探测机房A到机房B的连通性为例，如下图所示，首先从机房A和B中选择n个服务器对 ，机房A中的服务器 去探测机房B中的服务器 ，每次探测有 成功/失败 两种结果。在每个探测周期内，我们会收到n个探测数据，其中m个数据探测成功，(n-m)个数据探测失败。 理论上，在网络状态正常的情况下，m/n=100%。但实际中，由于服务器自身问题（发起探测的服务器负载过高、被探测的服务器重启等）以及一些偶然因素，少量的探测失败是不可避免的，所以需要设定一个判断网络是否故障的 阈值 。 阈值设定 在实际设定阈值的过程中，我们遇到两个问题： 单服务器故障导致产生探测数据的噪声 如前面所述，当服务器a探测服务器b时，如果服务器b自身故障（负载过高或者遇到机器重装、重启等）或遇到其他偶然因素，探测也可能失败，但并不能说明此时存在网络问题，这种情况我们称为 数据噪声

【今日推荐】：为什么一到面试就懵逼！>>> 本文作者：AIOps智能运维 干货概览 书接前文，在上一篇文章中我们介绍了大规模命令执行的意义以及所面对的问题和困难，简单介绍了百度集群控制系统（Cluster Control System，以下简称CCS系统）通过构建两级数据模型、四级调度模型、三级代理执行的方式解决了这些问题，在本篇文章中，我们将续接前文，继续对CCS系统的设计实现进行详细剖析。 两级数据模型 设计考量 回顾前文，在面临的需求中我们提到，需要在大规模的服务器上执行命令并且能够灵活控制。为了满足这样的需求，建立数据模型时，只有执行信息是不够的，还要有控制信息，如路由、并发度、暂停点等，两者组合在一起，构成了CCS系统中的数据模型。 控制信息 控制信息包括命令传递所需的“路由”信息和调度过程的控制信息，如下： 目标机器：命令执行的目标服务器列表，可以是IP，也可以是Hostname。 并发程度：分组并发执行时每组的机器数量，用于控制分组执行，避免系统升级时所有服务器同时升级造成业务中断。 暂停节点：指定执行到第几台服务器时暂停执行，方便先操作几台服务器并确认没问题后再继续执行，若有问题也可将问题控制在小范围内。 执行信息 执行信息是指命令到达目标机器后开始执行时所必需的信息，如下： 认证信息：标示执行者是谁的信息，用来确认执行者的合法性，如不合法则拒绝执行。 鉴权信息

【今日推荐】：为什么一到面试就懵逼！>>> 本文作者：AIOps智能运维 作者简介 运小伟 百度高级研发工程师 负责百度监控平台报警子系统的设计和研发，在大规模分布式系统、运维监控、精准报警等方面具有广泛的实践经验。 干货概览 Argus（Noah 监控3.0）是百度内部最大的监控平台，提供了 机器监控、进程监控、日志监控、远程监控、自定义监控 等多种监控方式。它还支持集群级别的监控配置和管理，并支持复杂的 异常判断 ，提供多种途径的 报警手段 。 图1 Argus监控系统示意图 从系统架构层面，Argus主要包括 采集、汇聚计算、数据存储、报警通路 和 可视化 五个主要部分。报警通路除负责异常判断、报警发送外，还支持 报警回调 和联动 故障自愈机器人 等功能。报警通路目前承载了千万级实例异常判断和报警，每天会自动执行数百次故障自愈任务。本篇文章会重点分异常判断和报警发送两部分来介绍报警通路的功能。 异常判断 判断规则 异常判断是报警通路的核心部分，其支持的判断规则决定了监控报警能力的强大与否，Argus报警通路支持以下两类判断规则： 内置的判断规则 ： 该部分支持 四则运算 、 逻辑运算 以及各种 内置函数 。例如：metric_a < 99.99% && metric_b < 99.99% 、 abs(metric_c) > 100 等 。 自定义的判断规则 ：

【今日推荐】：为什么一到面试就懵逼！>>> 本文作者：AIOps智能运维 作者简介 小拳拳 百度云高级研发工程师 负责百度云智能运维Noah外网质量监测平台的系统和策略研发，在网络监控方向有广泛实践经验。 干货概览 在此前介绍百度云智能运维Noah外网质量监测平台文章《百度网络监控实战：猎鹰一战成名（上）》中，我们简要介绍了一种网络异常类型—— 机房侧异常 （百度侧设备/链路异常）。该故障在数据上表现为多个省份访问某个百度机房服务不通畅，因此在猎鹰（百度外网监控平台）外网判障中，可以通过设置访问某机房出现异常的省份比例超过给定阈值，来判定机房侧异常的发生。 在外网故障统计中我们发现，运营商 骨干网链路 出现故障同样会导致多个省份到特定机房访问异常，在现有外网判障框架中，会将骨干网链路异常也判定为机房侧异常。然而，机房侧异常与骨干网链路异常无论是从起因还是数据表现上，都是存在一定差异的，两者的止损方式也不相同。因此，我们需要设计 判障策略 来区分两类异常，以便自动止损系统根据异常类型执行合适的外网止损方案。 在下文中，我们将为大家介绍骨干网链路及其异常表现，以及判障策略的设计思路。 什么是骨干网链路？ 骨干网是运营商用来连接多个地域或地区的高速网络，因此骨干网的一个重要作用就是 承载跨地域传输的网络数据 。若干条跨地域连接的骨干网链路，共同组成了完整的运营商骨干网。

本文作者：AIOps智能运维 干货概览 书接前文，在上一篇文章中我们介绍了大规模命令执行的意义以及所面对的问题和困难，简单介绍了百度集群控制系统（Cluster Control System，以下简称CCS系统）通过构建两级数据模型、四级调度模型、三级代理执行的方式解决了这些问题，在本篇文章中，我们将续接前文，继续对CCS系统的设计实现进行详细剖析。 两级数据模型 设计考量 回顾前文，在面临的需求中我们提到，需要在大规模的服务器上执行命令并且能够灵活控制。为了满足这样的需求，建立数据模型时，只有执行信息是不够的，还要有控制信息，如路由、并发度、暂停点等，两者组合在一起，构成了CCS系统中的数据模型。 控制信息 控制信息包括命令传递所需的“路由”信息和调度过程的控制信息，如下： 目标机器：命令执行的目标服务器列表，可以是IP，也可以是Hostname。 并发程度：分组并发执行时每组的机器数量，用于控制分组执行，避免系统升级时所有服务器同时升级造成业务中断。 暂停节点：指定执行到第几台服务器时暂停执行，方便先操作几台服务器并确认没问题后再继续执行，若有问题也可将问题控制在小范围内。 执行信息 执行信息是指命令到达目标机器后开始执行时所必需的信息，如下： 认证信息：标示执行者是谁的信息，用来确认执行者的合法性，如不合法则拒绝执行。 鉴权信息：标示执行者所持有的权限

本文作者：AIOps智能运维 干货概览 书接前文，在上一篇文章中我们介绍了大规模命令执行的意义以及所面对的问题和困难，简单介绍了百度集群控制系统（Cluster Control System，以下简称CCS系统）通过构建两级数据模型、四级调度模型、三级代理执行的方式解决了这些问题，在本篇文章中，我们将续接前文，继续对CCS系统的设计实现进行详细剖析。 两级数据模型 设计考量 回顾前文，在面临的需求中我们提到，需要在大规模的服务器上执行命令并且能够灵活控制。为了满足这样的需求，建立数据模型时，只有执行信息是不够的，还要有控制信息，如路由、并发度、暂停点等，两者组合在一起，构成了CCS系统中的数据模型。 控制信息 控制信息包括命令传递所需的“路由”信息和调度过程的控制信息，如下： 目标机器：命令执行的目标服务器列表，可以是IP，也可以是Hostname。 并发程度：分组并发执行时每组的机器数量，用于控制分组执行，避免系统升级时所有服务器同时升级造成业务中断。 暂停节点：指定执行到第几台服务器时暂停执行，方便先操作几台服务器并确认没问题后再继续执行，若有问题也可将问题控制在小范围内。 执行信息 执行信息是指命令到达目标机器后开始执行时所必需的信息，如下： 认证信息：标示执行者是谁的信息，用来确认执行者的合法性，如不合法则拒绝执行。 鉴权信息：标示执行者所持有的权限

本文作者：AIOps智能运维 在之前的系列文章《百度网络监控实战：NetRadar横空出世》中，我们介绍了百度内网质量监测平台NetRadar的原理和架构，其中， 判障算法 是内网监测系统的重要一环，今天我们将详细介绍在NetRadar中实际使用的一种判障算法——基于二项分布的网络判障算法。 业务场景 我们的内网监测系统 NetRadar 实时对百度内网连通性进行探测并根据探测数据判断是否存在网络故障。以探测机房A到机房B的连通性为例，如下图所示，首先从机房A和B中选择n个服务器对 ，机房A中的服务器 去探测机房B中的服务器 ，每次探测有 成功/失败 两种结果。在每个探测周期内，我们会收到n个探测数据，其中m个数据探测成功，(n-m)个数据探测失败。 理论上，在网络状态正常的情况下，m/n=100%。但实际中，由于服务器自身问题（发起探测的服务器负载过高、被探测的服务器重启等）以及一些偶然因素，少量的探测失败是不可避免的，所以需要设定一个判断网络是否故障的 阈值 。 阈值设定 在实际设定阈值的过程中，我们遇到两个问题： 单服务器故障导致产生探测数据的噪声 如前面所述，当服务器a探测服务器b时，如果服务器b自身故障（负载过高或者遇到机器重装、重启等）或遇到其他偶然因素，探测也可能失败，但并不能说明此时存在网络问题，这种情况我们称为 数据噪声 。 虽然单台服务器故障的概率不高

本文作者：AIOps智能运维 从事网络监控、可用性建设相关工作，负责百度外网监控平台 猎鹰 、百度内网监控平台 NetRadar 等系统的研发和优化工作。在网络采集、网络异常检测、系统可用性方面有广泛的实践经验。 干货概览 百度外网质量监控平台 猎鹰 实时监控百度的外网访问质量，已实现分钟级的外网故障发现和告警，保障每日数百次亿次用户请求的响应。《 百度网络监控实战：猎鹰一战成名 》系列文章将详细介绍百度面临的典型外网监控场景、需求及百度实现外网监控的原理和百度外网质量监控平台猎鹰的系统架构、核心功能。 背景介绍 百度服务器每天会收到数百亿次来自用户的请求，这些请求在到达百度服务器之前，需要在百度外的公共网络上经过多层网络设备（如运营商接入交换机等）和链路（如运营商骨干网链路、省网链路等）的转发及传输。公共网络中的设备或者链路故障，会导致部分用户无法正常访问百度的服务，影响用户体验。因此，需要对用户到百度的外网连通性进行实时监控，在故障时引导用户流量绕过故障设备／链路，从而提高用户体验。 猎鹰 作为百度外网质量监控平台，对整个百度的外网访问质量进行实时监测，实现了分钟级的外网故障发现和告警，同时提供丰富的数据可视化展示，为百度服务的可用性保驾护航，成为百度运维工程师日常工作的必备利器之一。 接下来， AIOps智能运维 将分上、下两篇对百度外网质量监控平台 猎鹰 进行介绍

本文作者：AIOps智能运维 作者简介 小拳拳 百度云高级研发工程师 负责百度云智能运维Noah外网质量监测平台的系统和策略研发，在网络监控方向有广泛实践经验。 干货概览 在此前介绍百度云智能运维Noah外网质量监测平台文章《百度网络监控实战：猎鹰一战成名（上）》中，我们简要介绍了一种网络异常类型—— 机房侧异常 （百度侧设备/链路异常）。该故障在数据上表现为多个省份访问某个百度机房服务不通畅，因此在猎鹰（百度外网监控平台）外网判障中，可以通过设置访问某机房出现异常的省份比例超过给定阈值，来判定机房侧异常的发生。 在外网故障统计中我们发现，运营商 骨干网链路 出现故障同样会导致多个省份到特定机房访问异常，在现有外网判障框架中，会将骨干网链路异常也判定为机房侧异常。然而，机房侧异常与骨干网链路异常无论是从起因还是数据表现上，都是存在一定差异的，两者的止损方式也不相同。因此，我们需要设计 判障策略 来区分两类异常，以便自动止损系统根据异常类型执行合适的外网止损方案。 在下文中，我们将为大家介绍骨干网链路及其异常表现，以及判障策略的设计思路。 什么是骨干网链路？ 骨干网是运营商用来连接多个地域或地区的高速网络，因此骨干网的一个重要作用就是 承载跨地域传输的网络数据 。若干条跨地域连接的骨干网链路，共同组成了完整的运营商骨干网。 图1所示是用于连接南北地域的一条骨干网链路——第二京汉广链路

本文作者：AIOps智能运维 在之前的系列文章《百度网络监控实战：NetRadar横空出世》中，我们介绍了百度内网质量监测平台NetRadar的原理和架构，其中， 判障算法 是内网监测系统的重要一环，今天我们将详细介绍在NetRadar中实际使用的一种判障算法——基于二项分布的网络判障算法。 业务场景 我们的内网监测系统 NetRadar 实时对百度内网连通性进行探测并根据探测数据判断是否存在网络故障。以探测机房A到机房B的连通性为例，如下图所示，首先从机房A和B中选择n个服务器对 ，机房A中的服务器 去探测机房B中的服务器 ，每次探测有 成功/失败 两种结果。在每个探测周期内，我们会收到n个探测数据，其中m个数据探测成功，(n-m)个数据探测失败。 理论上，在网络状态正常的情况下，m/n=100%。但实际中，由于服务器自身问题（发起探测的服务器负载过高、被探测的服务器重启等）以及一些偶然因素，少量的探测失败是不可避免的，所以需要设定一个判断网络是否故障的 阈值 。 阈值设定 在实际设定阈值的过程中，我们遇到两个问题： 单服务器故障导致产生探测数据的噪声 如前面所述，当服务器a探测服务器b时，如果服务器b自身故障（负载过高或者遇到机器重装、重启等）或遇到其他偶然因素，探测也可能失败，但并不能说明此时存在网络问题，这种情况我们称为 数据噪声 。 虽然单台服务器故障的概率不高