运维

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

【今日推荐】：为什么一到面试就懵逼！>>> puppet自动化运维之service资源 作用： ①.管理服务的状态； ② . 服务能够在配置文件更改的情况下自动重启。 格式： service {"title": #服务名, 通常就是在 /etc/init.d/ 目录下的名字 ensure => {running|stopped}, #当前service的状态 enable => {true|false}, #service是否开机启动， chkconfig [status|start|stop|restart] => "cmd", # 指定要执行的完整命令，当且仅当，启动脚本不在/etc/init.d/下的 path => " 目录", #启动脚本的搜索路径,可以用 冒号 分割多个路径,或者用数组指定 hasrestart => {true|false}, #是否支持restart参数,如果不支持,就用stop和start实现restart效果. hasstatus => {true|false}, #是从命令行status查询还是从进程表（有没有该进程）中，查询service的状态 provider => base|daemontools|init; #默认为init } 实例： #vsftpd，启动且开机自起 vi /etc/puppet/manifest/test.pp

【今日推荐】：为什么一到面试就懵逼！>>> exec简介： Puppet通过exec来执行外部的命令或者脚本，一般来讲是shell脚本。 这里面就涉及到一个 重复执行的问题 ，因为默认的agent一连接上来就会自动执行对应的命令或者脚本。如果脚本重复执行对系统没影响的还无所谓，如果会对系统造成影响呢？ 一个有用的方法是使用像 creates参数 来，除非达到了某个条件才会运行命令。比如执行之前判断文件是否存在等等。你可以使用refreshonly参数限制一个exec只有收到某个事件才执行。 作用： ①、远程执行系统命令，其实就是shell的调用； ②、由于exec是 一次性执行资源 ，在不同类里面exec名字可相同。 格式： exec {"title": #一般写上要执行的命令，如不写，则需要指定command cwd => " 目录的绝对路径", #在那个目录下执行，也可不要 path => "/bin:/sbin:...", #命令执行的搜索路径,如不要，需指定命令的绝对路径 command => " 执行的命令", #写上要执行的命令，一般不需要，可在title中写上 creates => " 文件名（绝对路径）", #当且仅当，该文件名不存在，命令才被执行，可不要 user => " 用户名", #定义运行命令的用户。 注意如果你使用了这个参数

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

做系统优化，必须首先要知道系统的瓶颈在哪里，是CPU处理能力太低？还是IO吞吐太小？本文将介绍监控系统性能的工具。 top： 查找系统性能的瓶颈，经常使用的判别工具是top。只要在命令行输入top，再回车，就会显示系统现在的负载情况。 top 显示的系统信息包括运行时间、进程的数量和状态、CPU周期的百分比和每个进程占用的存储空间、每个进程运行的时间，以及大量的其它信息。进程是按使用资源的多少来排列的，显示每5秒钟自动更新一次。在显示过程中，也可以按下空格键手动更新显示。在查找并解决系统性能故障时，这些信息是相当有用的。 大家可以看到显示的系统情况，运行中的进程有正在使用的top程序，140个进程，1个运行，其他都是休眠，这里还可以看到内存和swap的使用情况。 /proc/cpuinfo： 通过查看/proc/cpuinfo文件，可以得到CPU的型号，主频，缓存等信息。 free： 使用free命令可以查看系统中内存空间的大小。其中，Mem行中的total栏显示了当前Linux正在使用的RAM总量。used栏显示的是被占用的内存空间，但Mem行与这一栏结合并不能产生最好的分析结果，因为其中包含了Linux分配给磁盘缓冲区的一部分分区。在大多数系统中，used栏显示的值和total栏的值相当。然而，我们可以核对used栏、-/+buffers

本文作者：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自身故障（负载过高或者遇到机器重装、重启等）或遇到其他偶然因素，探测也可能失败，但并不能说明此时存在网络问题，这种情况我们称为 数据噪声 。 虽然单台服务器故障的概率不高

本文作者：AIOps智能运维 作者简介 运小羴 百度云高级研发工程师 负责百度云Noah智能监控产品数据采集子系统相关研发工作，在分布式监控系统架构、服务器客户端研发等方向有着较为广泛的实践经验。 干货概览 在百度云Noah智能监控产品中，我们提供了多维度数据聚合计算、智能异常检测、数据可视化、智能报警合并、逐级通告等丰富功能。今天，我们追根溯源，讲讲所有这些能力的基础，数据的来源， 监控数据采集（入门篇） 。 不同业务场景下都有着不同的监控需求，比如服务器的运行时信息、服务进程信息、日志信息、网络状态信息以及服务状态信息等。与之对应的，数据采集也需要提供丰富的采集方式来满足这些需求，一般地，针对应用场景的不同，可分别通过 本地客户端采集 和 远程服务采集 的方式来实现。 图1 监控平台架构简化图 本地客户端采集主要负责服务器自身的信息采集以及服务器上运行程序的信息采集，远程服务采集则通过远程发起探测的方式进行域名监控、网络监控、死机探测等，本文也将从这几个方面来阐述。当然，除此之外，还有更高级的数据采集方式，暂不在本文（入门篇）讨论范畴内。 本地客户端采集 本地客户端采集提供 基础的机器信息采集和用户服务信息采集 。机器信息采集主要关注机器硬件信息、机器资源使用、机器负载情况等。服务信息采集则通过插件的形式提供服务，包括进程采集、日志采集、自定义脚本采集、自定义HTTP采集等。

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