智能运维

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

本文作者：AIOps智能运维 干货概览 我们在《AIOps时代，你准备好了吗？》一文中提到，运维操作一般可以分为感知、决策、执行三部分，而在感知阶段我们通过识别服务指标数据中不符合预期的模式来发现服务异常，即监控数据的异常检测。 很多时候，大家手中的异常检测是一条拍脑袋想出来的规则，或者根据经验大致估算的阈值。这样的异常检测常常存在较多误报、漏报、效果不佳的情况。而上线前基于标注数据的效果评估是提高效果最重要的手段。为了获取大量、准确的标注数据来评估算法效果，我们进行了一系列探索。 本文将主要介绍在监控数据异常标注实践中遇到的问题和解决方案，并给出一个当前由百度智能运维团队与清华大学Netman实验室合作研发的辅助标注工具原型https://github.com/baidu/Curve，欢迎大家一起探讨。 时序数据异常标注 在监测服务的收入、流量、可用性、性能等指标时，通常会对数据进行流式的采集和汇聚，每个数据点反映的是某段时间内的服务状态，这些时间序列数据简称时序数据。 在异常检测方面大家或多或少都有过类似经历：针对一次故障设置了报警规则，其中的阈值根据这次故障设置。上线后不断发生误报，因此调低阈值。阈值调低后误报减少，但在一次新故障发生时发生漏报，又调高阈值。如此往复，在误报与漏报之间徘徊。这是因为以bad case（误报、漏报）驱动的阈值调整常常会以偏概全、前后矛盾

本文作者：AIOps智能运维 作者简介 凌薇 百度云智能运维业务研发负责人 负责百度云Noah自动化运维平台和智能运维解决方案的探索，在服务管理、资源管理、变更管理和故障管理的业务分析和设计方面经验丰富，致力于推进AIOps在百度业务、公有云以及私有云客户的运维场景落地。 为什么要写这篇文章 做了这么多年项目，参加过无数次团队内外的项目复盘，发现不少 项目延期 和客户 交付质量 的问题。这些问题给产品和技术负责人带来了不少应急“救火”的困扰。分析这些Case后，发现问题集中在以下几个方面： 需求界定不清晰、系统设计有缺陷、研发质量无保障、无效沟通耗时长，导致项目反复并且严重延期； 跨团队协作推动成本高，多团队交付进度出现Delay，项目整体目标不可控； 概要设计文档、API手册、产品使用手册和运维手册质量差，客户学习成本高； 我们团队通常会使用 项目复盘 （Case Study）的方法来应对这些情况。复盘主要为了解决以下两个问题：其一， 为项目延期和客户交付风险找到可行的解决方法 ；其二， 给团队成员一些指导，避免同一个问题重复出现 。当然，这些复盘工作一般在某个项目组内部开展，需要一种方式能够在多个项目组之间共享，这便是我写此文章的原因。 项目管理和研发质量控制是一个比较复杂的系统工程，本文不会系统的讲解一些理论和原则

本文作者：AIOps智能运维 作者简介 运小军 百度高级研发工程师 负责百度运维部大规模日志处理、海量事件数据存储相关设计研发工作，在分布式系统架构、大数据存储计算、高性能网络服务和即时通讯服务有广泛实践经验。 干货概览 本文主要介绍百度运维部监控架构团队在处理 大规模日志计算任务 时，为保证任务分配均匀性和稳定性，对原始 一致性哈希 算法进行改进。新算法在保持原始一致性哈希算法稳定性的同时，通过设置 不均衡因子 来控制分配的不均匀范围，达到负载分配均匀性与稳定性有效兼容。 一 业务场景 分布式系统中我们经常会面对如下业务场景： 计算系统每分钟有大量的定时任务需要及时调度并按时完成，单机在处理能力和时效性上都无法满足要求，需要将任务分配到大量Work节点上进行并行计算，我们如何均匀分配这些任务，并且在任务增减，Work节点退出/加入(伸缩能力)时保持任务分配的稳定性(不会引起大量任务迁移)。 分布式存储系统，海量数据被分片存储，那么如何让每个Data节点上分片更加均匀，并且在Data节点退出/加入时保持数据分片的稳定性。 高并发Web系统中，架构上几乎都是一个或多个反向代理服务器(如Nginx)来做七层负载均衡，后端使用应用服务器集群(如Tomcat)提供服务，这种架构具备水平伸缩能力，那么反向代理如何均匀分配请求，并且尽量保证请求Session粘性。 二 问题分析

本文作者：AIOps智能运维 作者简介 运小军 百度高级研发工程师 负责百度运维部大规模日志处理、海量事件数据存储相关设计研发工作，在分布式系统架构、大数据存储计算、高性能网络服务和即时通讯服务有广泛实践经验。 干货概览 本文主要介绍百度运维部监控架构团队在处理 大规模日志计算任务 时，为保证任务分配均匀性和稳定性，对原始 一致性哈希 算法进行改进。新算法在保持原始一致性哈希算法稳定性的同时，通过设置 不均衡因子 来控制分配的不均匀范围，达到负载分配均匀性与稳定性有效兼容。 一 业务场景 分布式系统中我们经常会面对如下业务场景： 计算系统每分钟有大量的定时任务需要及时调度并按时完成，单机在处理能力和时效性上都无法满足要求，需要将任务分配到大量Work节点上进行并行计算，我们如何均匀分配这些任务，并且在任务增减，Work节点退出/加入(伸缩能力)时保持任务分配的稳定性(不会引起大量任务迁移)。 分布式存储系统，海量数据被分片存储，那么如何让每个Data节点上分片更加均匀，并且在Data节点退出/加入时保持数据分片的稳定性。 高并发Web系统中，架构上几乎都是一个或多个反向代理服务器(如Nginx)来做七层负载均衡，后端使用应用服务器集群(如Tomcat)提供服务，这种架构具备水平伸缩能力，那么反向代理如何均匀分配请求，并且尽量保证请求Session粘性。 二 问题分析

本文作者：AIOps智能运维 干货概览 我们在《AIOps时代，你准备好了吗？》一文中提到，运维操作一般可以分为感知、决策、执行三部分，而在感知阶段我们通过识别服务指标数据中不符合预期的模式来发现服务异常，即监控数据的异常检测。 很多时候，大家手中的异常检测是一条拍脑袋想出来的规则，或者根据经验大致估算的阈值。这样的异常检测常常存在较多误报、漏报、效果不佳的情况。而上线前基于标注数据的效果评估是提高效果最重要的手段。为了获取大量、准确的标注数据来评估算法效果，我们进行了一系列探索。 本文将主要介绍在监控数据异常标注实践中遇到的问题和解决方案，并给出一个当前由百度智能运维团队与清华大学Netman实验室合作研发的辅助标注工具原型https://github.com/baidu/Curve，欢迎大家一起探讨。 时序数据异常标注 在监测服务的收入、流量、可用性、性能等指标时，通常会对数据进行流式的采集和汇聚，每个数据点反映的是某段时间内的服务状态，这些时间序列数据简称时序数据。 在异常检测方面大家或多或少都有过类似经历：针对一次故障设置了报警规则，其中的阈值根据这次故障设置。上线后不断发生误报，因此调低阈值。阈值调低后误报减少，但在一次新故障发生时发生漏报，又调高阈值。如此往复，在误报与漏报之间徘徊。这是因为以bad case（误报、漏报）驱动的阈值调整常常会以偏概全、前后矛盾

本文作者：AIOps智能运维 作者简介 胖丁 百度云高级产品经理 负责百度云监控、Noah监控平台的产品设计和运营，致力于为百度云用户提供高效稳定的智能运维产品。 大家好，我是百度智能云的PM，今天与大家分享一下PM精（xi）彩（jing）的日常，我们是如何高效地与研发沟通的~ 为什么要沟通 首先，我们要问问自己，为啥要和研发工程师打交道。因为他们的新拖鞋很好看？ 当然不是。肯定是因为你希望研发按照你的预期完成某个任务，简而言之： Noah要更强！我要提需求！ 沟通的需求 生理需求： 医学研究人员发现，贫乏的人际沟通会危害冠状动脉的健康，其危害程度与抽烟、高血压、血脂肪过高、过度肥胖等一样严重，社交孤独者比活跃社交的人患感冒的几率高了4倍。 认同需求： 沟通是我们认识自己的唯一方法，我们对自我的认同源于我们和他人的互动。 社交需求： 沟通除了可以帮助我们诠释自我之外，也提供我们和他人之间重要的联结。 有效的人际沟通可以提升快乐感：研究超过200名大学生后发现，最快乐的10%都认为自己拥有丰富的社交生活。 实际需求： 沟通能够达成工具性目标。 工具性目标：让他人依照我们想要的去表现。如：让发型师稍微修剪刘海而不是剪成半长不短的狗啃刘海。 准备好论据 然后，我们需要问问自己，我的论据（PRD、原型图等）真的真的准备好了吗？请你指着自己写下的每一句话、画出来的每一个框框

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