《建设DevOps统一运维监控平台.docx》由会员分享，可在线阅读，更多相关《建设DevOps统一运维监控平台.docx（14页珍藏版）》请在课桌文档上搜索。
1、建设DevOps统一运维监控平台-全面的系统监控日期:2023-03-1417:20浏览:100评论:0刖三随着Devopsx云计算、微效劳、容器等理念的逐步落地和大力开展，机器越来越多，应用越来越多，效劳越来越微，应用运行根底环境越来多样化，容器、虚拟机、物理机不一而足。面对动辄几百上千个虚拟机、容器，数十种要监控的对象，现有的监控系统还能否支撑的住？来自于容器、虚拟机、物理机、网络设备、中间件的指标数据如何采用同一套方案快速、完整的收集和分析告警？怎样的架构、技术方案才更适合如此庞大繁杂的监控需求呢？目录：一、统一监控平台架构解析二、系统监控的技术栈三、开源系统监控软件ZabbixVSNa
2、giosVSOpen-Falcon四、基于k8s容器云背景下的系统监控实践：CAdvisor+Heapster+InfIuxdb五、容器时代的监控利器：Prometheus一、统一监控平台架构解析先做一下回忆，统一监控平台由七大角色构成：雌源、数据采集、数据存储、数据分析、数据展现、预警中心、CMDB（企业软硬件资产管理）。监控源：从层次上来分，大致可以分为三层，业务应用层、中间件层、根底设施层。业务应用层主要包括应用软件、企业消息”总线等，中间件层包括数据库、缓存、配置中心、等各种系统软件，根底设施层主要有物理机、虚拟机、容器、网络设备、存储设备等等。数据采集：数据源如此多样,数据采集的任务
3、自然轻松不了。数据采集从指标上划分可以分为业务指标、应用指标、系统软件监控指标、系统指标。应用监控指标如：可用性、异常、吞吐量、响应时间、当前等待笔数、资源占用率、请求量、日志大小、性能、队列深度、线程数、效劳调用次数、访问量、效劳可用性等，业务雌指标如大额流水、流水区域、流水明细、请求笔数、响应时间、响应笔数等，系统监控指标如：CPU负载、内存负载、磁盘负载、网络。、磁盘10、tcp连接数、进程数等。从采集方式来说通常可以分为接口采集、客户端agent采集、通过网络协议主动抓取、snmp等数据存储：采集到的数据一般都会存储到文件系统如HDFS、索引系统如elasticsearch、指标库如i
4、nfluxdb)s消息队列如kafka,做消息临时存储或者缓冲)、数据库如mysql数据分析：针对采集到的数据，进行数据的处理。处理分两类：实时处理和批处理。技术包括Map/Reduce计算、全日志检索、流式计算、指标计算等，重点是根据不同的场景需求选择不同的计算方式。数据展现：将处理的结果进行图表展现，在多屏时代，跨设备的支持必不可少。预警：如果在数据处理过程发现了问题，那么需要进行异常的分析、风险的预估以及事件的触发或告警。CMDB（企业软硬件资产管理）：CMDB在统一监控平台中是很重要的一环，监控源虽然种类繁多，但是他们大都有着关系，如应用运行在运行环境中，应用的正常运行又依赖网络和存储
5、设备，一个应用也会依赖于其他的应用业务依赖，一旦其中任何一个环节出了问题,都会导致应用的不可用。CMDB除了存储软硬件资产外，还要存储这样一份资产间的关联关系,一个资产发生了故障,要能根据这个关系迅速得知哪些其他的资产会被影响，然后逐一解决问题。OK,回忆到此为止，进入正题,系统监控。二、系统监控的技术栈系统监控的局部技术栈如下列图所示，监控技术众多，这里自然不可能列出所有的技术，选择了局部比拟经典、受欢送的开源技术。数据采集数据缓冲数据存储数据展现告警snmpKafkaMysqlEchartsZabbixAgentRabbitMQInfluxdbGrafanaNagiosCadvisorZe
6、roMQOpenTSDBOpen-falconHeapsterGraphitePrometheus系统雌不同于日志监控，有很多开源软件把数据库采集、数据存储、数据展现、事件告警的任务都完成了，所以对于系统监控的技术栈中，将这些开源软件暂且并E除,待后面章节再进行讲解。此处主要关注于如何自建一个统一系统监控平台。数据采集：系统雌数据采集一般分为两种方式：主动采集、客户端采集。主动采集一般是通过SNMP、SSHxTelnet.IPMkJMX等手段进行远程采集，客户端采集那么是需要在每一个要监控的主机中部署一个客户端进行数据采集并发送到远程效劳端进行接收。数据缓冲：和日志监控一样，在面临海量监控时，
7、考虑到网络的压力和数据处理的瓶颈，可以在数据存储前先经过一层数据缓冲，将采集到的数据先放置到消息队列中，然后再从分布式队列中读取数据并存储。如果数据量不大的话,那么可以不考虑此层。数据存储：对于系统监控数据，通常采用时序数据库来存储，时序数据库全称为时间序列数据库。时间序列数据库主要用于指处理带时间标签按照时间的顺序变化，即时间序列化的数据，带时间标签的数据也称为时间序列数据。如influxdb和OPentSdb,是其中翘楚。OPenTSDB是用hbase存储所有的时序无须采样来构建的一个分布式、可伸缩的时间序列数据库，可以从大规模的集群包括集群中的网络设备、操作系统、应用程序）中获取相应的m
8、etrics并进行存储、索引以及效劳，从而使得这些数据更容易让人理解,如web化,图形化等。用JAVA语言实现，对于JAVA系的同学们是f福音,不过其依赖hbase也许会让一局部同学望而却步，毕竟还要先去维护hbaseoInfluxdb是新兴的f时序数据库，用go语言编写，无需外部依赖，开展很快最新版本已经到了12提供类Sql的查询语法,安装方便，单点即可使用，虽然有集群的能力，不过该特性是非开源的不过单点性能根本也都能满足企业需求了。提供API,便于调用和封装。对于想基于influxdb自行进行数据处理和展现的同学们而言很是友好。数据展现：说到时序数据的图形化展现，Grafana是Y不得不提
9、的利器。Grafana是一个开源的时序数据的查询和展现软件，提供了灵活丰富的图形化选项；可以混合多种风格，有着功能齐全的度量仪表盘和图形编辑器。支持与GraphitexElasticsearchxCIoudWatchxPrometheussInfIuxdbDB等众多数据存储对接,进行数据的查询和图表展现。一些开源的监控软件如Zabbix、Graphite.PrOmetheUS也都有着自己的数据图形化展现能力，但是一般也都是建议使用Grafana来代替它们的页面。可想而知Grafana的优秀。当然，Grafana的数据源都是来自时序数据库,在实际场景中，可能你想要查看的报表的一局艘据还来自于业务
10、系统，这就是Grafana或者其他的监控软件做不到的了，去扩展是一种方式，另外一种方式就是结合自己的需求实现图表展现,通过对时序数据的计算分析以及结合业务数据，使用如echarts等开源图表前端框架进行展现。这时候Influxdb的优势就表达出来了，对夕隈供api非常适合自主封装图形化页面。告警：在日志监控的分享中，确实没有对告警进行说明。像Zabbix、NagiosxOpen-Falcon.PrometheUS等开源雌软件，都是有些自己的告警能力的。如果你采用了他们作为监控平台,实际上告警能力就已经有了。如果是纯自建统一监控平台的话，也可以自己实现告警中心。我们自己的做法是,在数据处理时，根
11、据配置的事件触发规那么，生成相应事件扔到kafka中，事件处理引擎监听kafka中的事件数据，进行解析并根据事件处理策略进行告警通知等处理。三、开源系统监控软件ZabbixVSNagiosVSOpen-Falcon上面大致介绍了运维监控的技术栈，但是实际上已经有些开源监控软件功能都很全面，从数据采集到数据展现都提供了支持，如果是小团队,不想自建监控平台的话，选择这些开源软件其实是一个很好的选择。ZabbixZabbiX是T企业级的开源分布式监控解决方案，支持实施从数以万计的效劳器、虚拟机、网络设备等收集百万的指标数据，具备常见的商业雌软件所具备的功能主机的性能监控、网络设备性能监控、数据库性能
12、监控、FTP等通用协议监控、多种告警方式、详细的报表图表绘制支持自动发现网络设备和效劳器；支持分布式，能集中展示、管理分布式的监控点；扩展性强，SerVer提供通用接口，可以自己开发完善各类监控。ZabbiX重要组件说明：zabbiserver:负责接收agent发送的报告信息的核心组件,所有配置、统计数据及操作数据都由它组织进行；databasestorage:专用于存储所有配置信息，以及由zabbix收集的数据；webinterface:zabbix的GUI接口;proxy:可选组件，常用于监控节点很多的分布式环境中，代理server收集局部数据转发到server,可以;蝠server的压
13、力；agent:部署在被监控的主机上，负责收集主机本地数据如cpu、内存、数据库等数据发往SerVer端或proxy端；优点：AllinOne:部署相当便捷Server对宿主机性能要求很低。自动发现效劳器与网络设备分布式监控，以及WEB集中管理功能同时支持agent采集和无agent采集，主机通过agent或者ipmi采集数据，网络设备、存储设备等通过SNMP客户端采集数据，agent支持常用的UNIX和WindoWS操作系统功能全面，数据采集、数据存储、数据展现、事件告警。开放式接口，扩展性强，插件编写容易缺乏：数据库瓶颈，使用mysql作为底层存储，大数据读写的时候，对于数据库的压力非常大
14、需要在主机中安装agent对容器监控支持不好，需要自己扩展。NagiosNagioS全名为NagiosAirftGoonalnsistonSaintood,最初工程名字是NetSainL它是一款免费的开源IT根底设施监控系统其功能强大,灵活性强,能有效监控WindowsxLinux.VMware和Unix主机状态,交换机、路由器等网络设置等。NagioS核心功能是监控报警,告警能力很不错，但是图形展示效果很差。同时nagios更加灵活，很多功能都要通过插件化来实现,对于技术能力没那么强的同学,上手会有些困难。当然，对于运维老手，上手会很快。Nagios的功能特性如下：监控网络效劳SMTP、Po
15、P3、NNTPxPlNG等;监控主机资源处理器负荷、磁盘利用率等；简单地插件设计使得用户可以方便地扩展自己效劳的检测方法；并行效劳检查机制；具备定义网络分层结构的能力,用parent主机定义来表达网络主机间的关系,这种关系可被用来发现和明晰主机宕机或不可达状态；当效劳或主机问题产生与解决时将告警发送给联系人通过EMaiI、短信、用户定义方式）；可以定义一些处理程序,使之能够在效劳或者主机发生故障时起到预防作用；自动的日志滚动功能；可以支持并实现对主机的冗余触；可选的WEB界面用于查看当前的网络状态、通知和故障历史、日志文件等；Open-FalconOPen-Falcon是小米运维部门开源出来的
16、互联网企业级雌系统，目前包括小米、金山云、美团、京东金融、赶集网等都在使用OPen-Falcon。Open-Falcon整体可以分为两局部，即绘图组件、告警组件。，绘图组件负责数据的采集、收集、存储、归档、采样、查询、展示Dashboard/Screen等功能，可以单独工作，作为timeseriesdata的一种存储展示方案。“告警组件负责告警策略配置portals告警判定UUdge）、告警处理alarm/sender、用户组管理uic）等,可以单独工作。架构如下:aggregator!令多个metfk关键特性有：数据采集免配置：agent自发现、支持Plugin,主动推送模式容量水平扩展：生
17、产环境每秒50万次数据收集、告警、存储、绘图，可持续水平扩展。告警策略自发现：Web界面、支持策略模板、模板继承和覆盖、多种告警方式、支持回调动作。告警设置人性化：支持最大告警次数、告警级别设置、告警恢复通知、告警暂停、不同时段不同阈值、支持维护周期，支持告警合并。历史雌高效查询：秒级返回上百个指标一年的历史数据。Dashboard人性化：多维度的数据展示，用户自定义Dashboard等功能。架构设计高可用：整个系统无核心单点，易运维，易部署。缺点：支持的监控类型较少，不支持常用应用效劳器如tomcat、apache、jetty等的监控。没有专门的运维支持，代码更新较少，没有一个较大的社区来维
18、护，后续想要有什么新的能力根本只能指望自己扩展。ZabbixsNagiosxOpen-Falcon的整体比照方下：工具ZabbixNagiosOpen-Falcon优点1 .AllinOne:部署相当便捷,开箱即用2 .SerVer对宿主机性能要求很低.3 .自动发现服务器与网络设备4 .分布式监控，以及WEB集中管理功统5 .功能全面，散据采集、数据存储、数据展现、事件告警.6 .开放式接口，扩展性强.插件编写容界L轻灵活，插件机制支持扩展自己想要的监控畿力.2 .监控全面，报警机制很强.3 .结构简单，可维护性强4 .可以支持并实现对主机的冗余监控；1 .数据采集免配雷：agent自发现2
19、 .容量水平扩展3 .告警策略功能全面4 .历史数据高效直询:秒级返回上百个指标一年的历史数据.5 .用户可自定义DaShboard,多维度的数据展示7.架构设计高可用：整个系统无核心单点,窈运推，易部署.缺点1 .数据麻醐,使用mysql作为底层存储，大数据读写的时候，对于数据库的压力非常大2 .需要在主机中安装agent3 .对容容监控支持不好,需要自己扩展1 .很多功蚓需要额外$装插件,对初学者挑战较大2 .图表力很弱1 .支持的监控类型较少，不支持就用应用98务器如tomcat、apache、jetty等的监控2 .没有专门的运堆支持，代码更新较少，没有一个较大的社区来维护，后续想要有
20、什么新的能力蜃本只能指望自己扩震四、基于k8s容器云背景下的系统监控实践：cAdvisor+Heapster+Influxdb上面介绍的都是比拟传统的系统监控架构,在容器时代到来后，对于容器的支持就显得差强人意了。下面介绍下我们基于k8s容器云背景下的系统监控方案，首先还是介绍下我们的DevOps平台架构，平台运行在由kubernetes+docker构建的容器云中，kubernetessdocker等效劳运行在IaaS平台上我们的生产环境是阿里云）。I ier8, I rDashboard业务应用产品（前台角色交互场景）DevOps产用架构产品开发与裔试产且运推 一/ SCMSRMSoftw
21、are Config Mgmt. Software Resource Mgmt.求件资iSK3!软件WEi餐理SEMUnified Momtonng Center.Wi-AK中心8PRDPRContinuou$ Integration Binary Package Repository Deployed Package Repository朝仓生笛t仓段心二岗叫7x1二.”J.”Port* PIl产品运石Quality Assuraixe Feedback.verson Control System0本按期系蛇基础服务DeNgn 3htTrtDev 开发Deliver 11 Monitor 交
22、付HTfouMe 故4Offline TttIffideocy 喙,SPMIdentity & Access Mgmt. Software ProdiRt Mgmt.身份识别与访问我建Software Environment Mgml状件环境皆现中间件服务微服务框架（发现、注册、例、伸缩、漂移）基础设施IaaS、CaaS（DockerKubernetes）私有云、公有云、混合云我们的统一监控平台，在系统上，采用了cAdvisor+Heapster+lnfluxdb的方案。架构如下：为什么采用这种方案呢？先来了解下这三个工具。CAdViSor是谷歌公司用来分析运行中的DoCker容器的资源占用以
23、及性能特性的工具,CAdViSOr部署为一个运行中的daemon,它会收集、聚集、处理并导出运行中容器的信息。这些信息能够包含容器级别的资源隔离参数、资源的历史使用状况、反映资源使用和网络统计数据完整历史状况。对docker的监控能力非常强大。同时还提供了自己的web页面，用户可以通过web页面直接查看该宿主机上所有容器的监控数据。CAdvior功能已经被集成到了kubelet组件中也就是说,安装好kubernetes后,CAdvisor就已经安装到了每一个计算节点上。在每一个计算节点上都可以通过IP+端口默认为4194访问CAdvisor的页面了。Heapster同样是GOogIe提供的用于
24、对k8s集群的监控。Heapster可以通过容器启动传入kubernetesmaster的地址,heapster会通过调用kubernetesapi获取所有kubernetes计算节点，然后通过kubelet的外部调用端口号默认为10250）调用kubelet的api,kubelet会进行调用CAdViSor接口获取当前计算节点上的容器数据以及当前主机的性能数据，返回给heapter.这样heapster就收集到了kubernetes集群的所有容器数据以及主机数据。HeaPSter支持数据传输到InfIUXdb中进行存储。数据展现我们就是自己调用influxdb的api获取数据，结合我们的业务
25、相关数据进行计算，用echarts进行前端图表展现。可能有的同学会问，这样只是监控到了所有计算节点的容器数据和主机性能数据，这样有些非计算节点的主机监控该怎么办？确实，因为Heapster只是针对于kubernetes集群去监控，非kubelet节点确实是拿不到数据的，而我们又不想再用另外一种方式去单独监控主机，那样得到的数据格式也不一样。于是我们采取了折中的方法,在每个非k8s集群节点上,也安装kubelet,并且参加到kubernetes集群中，但是配置成不参与集群调度，也就是容器不会被部署到这些机器上。这样，heapster就可以采集到这些主机的性能数据了。五、容器时代的监控利器：Pro
26、metheus除了我们实践的cAdvisor+Heapster+lnfluxdb方案可以做到容器和主机性能数据同时监控外，其实还有一个相对而言更好的方案，那就是PrometheusePrometheus是一套开源的监控&报警&时间序列数据库的组合，由社交音乐平台SoUndeI。Ud在2023年开发。随着开展，越来越多公司和组织接受采用Prometheus,社区也十分活泼，他们便将其独立成开源工程，并且不依赖于任I可公司。Prometheusft初是参照google内部监控系统BorgMon开发的，现在最常见的Kubernetes容器管理系统中，通常会搭配Prometheus进行监控。2023年
27、Prometheus正式成为CIoUdNativeComputingFoundation的孵化工程该基金会是在Google的支持下由一群IT行业巨头创立并指导Kubernetes容器管理系统的开发。在CNCF的主导下,PrOmetheUS成为该开放平台栈的第二个正式的组件。特性如下：高维度数据模型高效的时序数据存储能力查询语言灵活具体时序数据图形化展现的能力易于运维提供丰富的客户端开发库告警中心功能全面Prometheus的架构图如下：PrometheusServer:Prometheus主效劳器，用来收集和存储时间序列数据clientlibraries:客户端库pushgateway:短时j
28、obs的中介网关GUI-baseddashboardbuilder:基于Rails/SQL的GUIdashboardExporters:数据采集探针，支持包括数据库、主机、消息队列、存储、应用效劳器、github等软件、其他雌系统等多种类的探针。Alertmanager:告警中心Prometheus是ggle力捧的监控方案，社区非常活泼，开展很是迅速，功能在不断的飞速补充和完善。一个监控范围覆盖容器、主机、存储、数据库、各种中间件,同时还具体完善的时序数据存储、告警中心等能力，开展又很迅速，相信PrometheUS会越来越炽热。六、总结系统雌的方案有很多，甚至优秀的开源兼容软件也有很多，如果需求不高，也许ZabbiX就很适宜，如果想要带上容器监控，那么Prometheus也许是个较好的方案。总之，适合自己的才是最好的。
