百亿级访问量的实时监控系统如何实现?,百亿级实时监控系统

笔者自2016年加入WiFi万能钥匙,现任WiFi万能钥匙高级架构师,拥有10年互联网研发经验,喜欢折腾技术。主要专注于:分布式监控平台、调用链跟踪平台、统一日志平台、应用性能管理、稳定性保障体系建设等领域。

在本文中,笔者将与大家分享一下在实时监控领域的一些实战经验,介绍WiFi万能钥匙是如何构建APM端到端的全链路监控平台,从而实现提升故障发现率、缩短故障处理周期、减少用户投诉率、树立公司良好品牌形象等目标。

WiFi万能钥匙开发运维团队的困扰

始于盛大创新院的WiFi万能钥匙,截至到2016年底,我们总用户量已突破9亿、月活跃达5.2亿,用户分布在全球223个国家和地区,在全球可连接热点4亿,日均连接次数超过40亿次。

随着日活跃用户大规模的增长,WiFi万能钥匙各产品线服务端团队正进行着一场无硝烟的战争。越来越多的应用服务面临着流量激增、架构扩展、性能瓶颈等问题。为了应对并支撑业务的高速发展,我们迈入了SOA、Microservice、API
Gateway等组件化及服务化的时代。

伴随着各系统微服务化的演进,服务数量、机器规模不断增长,线上环境也变得日益复杂,工程师们每天都会面临着诸多苦恼。例如:线上应用出现故障问题时无法第一时间感知;面对线上应用产生的海量日志,排查故障问题时一筹莫展;应用系统内部及系统间的调用链路产生故障问题时难以定位等等。

综上所述,线上应用的性能问题和异常错误已经成为困扰开发人员和运维人员最大的挑战,而排查这类问题往往需要几个小时甚至几天的时间,严重影响了效率和业务发展。WiFi万能钥匙亟需完善监控体系,帮助开发运维人员摆脱烦恼,提升应用性能。依据公司的产品形态及业务发展,我们发现监控体系需要解决一系列问题:

◆面对全球多地域海量用户的WiFi连接请求,如何保障用户连接体验?

◆如何通过全链路监控提升用户连接WiFi的成功率?

◆随着微服务大规模推广实施,钥WiFi万能钥匙产品服务端系统越来越复杂,线上故障的发现、定位、处理难度也随之增长,如何通过全链路监控提升故障处理速度?

◆移动出海已经进入深入化发展的下半场,全链路监控如何应对公司全球化的业务发展?

◆……

全链路监控

早期为了快速支撑业务发展,我们主要使用了开源的监控方案保障线上系统的稳定性:Cat、Zabbix,随着业务发展的需要,开源的解决方案已经不能满足我们的业务需求,我们迫切需要构建一套满足我们现状的全链路监控体系:

◆多维度监控(系统监控、业务监控、应用监控、日志搜索、调用链跟踪等)

◆多实例支撑(满足线上应用在单台物理机上部署多个应用实例场景需求等)

◆多语言支撑(满足各团队多开发语言场景的监控支撑,Go、C++、PHP等)

◆多机房支撑(满足国内外多个机房内应用的监控支撑,机房间数据同步等)

◆多渠道报警(满足多渠道报警支撑、内部系统对接,邮件、掌信、短信等)

◆调用链跟踪(满足应用内、应用间调用链跟踪需求,内部中间件升级改造等)

◆统一日志搜索(实现线上应用日志、Nginx日志等集中化日志搜索与管控等)

◆……

监控目标

从“应用”角度我们把监控体系划分为:应用外、应用内、应用间。如下图所示:

图片 1

应用外:主要是从应用所处的运行时环境进行监控(硬件、网络、操作系统等)

应用内:主要从用户请求至应用内部的不同方面(JVM、URL、Method、SQL等)

应用间:主要是从分布式调用链跟踪的视角进行监控(依赖分析、容量规划等)

罗马监控体系的诞生

根据自身的实际需求,WiFi万能钥匙研发团队构建了罗马(Roma)监控体系。之所以将监控体系命名为罗马,原因在于:

1、罗马不是一天成炼的(线上监控目标相关指标需要逐步完善);

2、条条大路通罗马(罗马通过多种数据采集方式收集各监控目标的数据);

3、据神话记载特洛伊之战后部分特洛伊人的后代铸造了古代罗马帝国(一个故事的延续、一个新项目的诞生)。

一个完美的监控体系会涵盖IT领域内方方面面的监控目标,从目前国内外各互联网公司的监控发展来看,很多公司把不同的监控目标划分了不同的研发团队进行处理,但这样做会带来一些问题:人力资源浪费、系统重复建设、数据资产不统一、全链路监控实施困难。目前,各公司在监控领域采用的各解决方案,如下图所示:

图片 2

正如图中所示,罗马监控体系希望能够汲取各方优秀的架构设计理念,融合不同的监控维度实现监控体系的“一体化”、“全链路”等。

高可用架构之道

面对每天40多亿次的WiFi连接请求,每次请求都会经历内部数十个微服务系统,每个微服务的监控维度又都会涉及应用外、应用内、应用间等多个监控指标,目前罗马监控体系每天需要处理近千亿次指标数据、近百TB日志数据。面对海量的监控数据罗马(Roma)如何应对处理?接下来,笔者带大家从系统架构设计的角度逐一进行剖析。

架构原则

一个监控系统对于接入使用方应用而言,需要满足如下图中所示的五点:

• 性能影响:对业务系统的性能影响最小化(CPU、Load、Memory、IO等)

• 低侵入性:方便业务系统接入使用(无需编码或极少编码即可实现系统接入)

• 无内部依赖:不依赖公司内部核心系统(避免被依赖系统故障导致相互依赖)

• 单元化部署:监控系统需要支撑单元化部署(支持多机房单元化部署)

• 数据集中化:监控数据集中化处理、分析、存储等(便于数据统计等)

整体架构

Roma系统架构如下图所示:

图片 3

Roma架构中各个组件的功能职责、用途说明如下:

图片 4

Roma整体架构中划分了不同的处理环节:数据采集、数据传输、数据同步、数据分析、数据存储、数据质量、数据展示等,数据流处理的不同阶段主要使用到的技术栈如下图所示:

图片 5

数据采集

对于应用内监控主要是通过client客户端同所在机器上的agent建立TCP长连接的方式处理,agent同时也需要具备通过脚本调度的方式获取系统性能指标数据。

图片 6

面对海量的监控指标数据,罗马监控通过在各层中预聚合的方式进行汇总计算,比如在客户端中相同URL请求的指标数据在一分钟内汇总计算后统计结果为一条记录(分钟内相同请求进行累加计算,通过占用极少内存、减少数据传输量),对于一个接入并使用罗马的系统,完全可以根据其实例数、指标维度、采集频率等进行监控数据规模的统计计算。通过各层分级预聚合,减少了海量数据在网络中的数据传输,减少了数据存储成本,节省了网络带宽资源和磁盘存储空间等。

应用内监控的实现原理(如下图所示):主要是通过客户端采集,在应用内部的各个层面进行拦截统计:
URL、Method、Exception、SQL等不同维度的指标数据。

图片 7

应用内监控各维度指标数据采集过程如下图所示:针对不同的监控维度定义了不同的计数器,最终通过JMX规范进行数据采集。

图片 8

数据传输

数据传输TLV协议,支持二进制、JSON、XML等多种类型。

图片 9

每台机器上都会部署agent(同客户端建立TCP长连接),agent的主要职责是数据转发、数据采集(日志文件读取、系统监控指标获取等),agent在获取到性能指标数据后会发送至kafka集群,在每个机房都会独立部署kafka集群用于监控指标数据的发送缓冲,便于后端的节点进行数据消费、数据存储等。

为了实现数据的高效传输,我们对比分析了消息处理的压缩方式,最终选择了高压缩比的GZIP方式,主要是为了节省网络带宽、避免由于监控的海量数据占用机房内的网络带宽。针对各个节点间数据通信的时序图如下图所示:建立连接->读取配置->采集调度->上报数据等。

图片 10

数据同步

海外运营商众多,公网覆盖质量参差不齐,再加上运营商互联策略的不同,付出的代价将是高时延、高丢包的网络质量,钥匙产品走向海外过程中,首先会对整体网络质量情况有正确的预期,比如如果需要对于海外机房内的应用进行监控则依赖于在海外建立站点(主机房)、海外主站同国内主站进行互联互通,另外需要对监控指标数据分级处理,比如对于实时、准实时、离线等不同需求的指标数据采集时进行归类划分(控制不同需求、不同数据规模等指标数据进行采样策略的调整)

由于各产品线应用部署在多个机房,为了满足各个应用在多个机房内都可以被监控的需求,罗马监控平台需要支持多机房内应用监控的场景,为了避免罗马各组件在各个机房内重复部署,同时便于监控指标数据的统一存储、统一分析等,各个机房内的监控指标数据最终会同步至主机房内,最终在主机房内进行数据分析、数据存储等。

为了实现多机房间数据同步,我们主要是利用kafka跨数据中心部署的高可用方案,整体部署示意图如下图所示:

图片 11

在对比分析了MirrorMaker、uReplicator后,我们决定基于uReplicator进行二次开发,主要是因为当MirrorMaker节点发生故障时,数据复制延迟较大,对于动态添加topic则需要重启进程,黑白名单管理完全静态等。虽然uReplicator针对MirrorMaker进行了大量优化,但在我们的大量测试之后仍遇到众多问题,我们需要具备动态管理MirrorMaker进程的能力,同时我们也不希望每次都重启MirrorMaker进程。

数据存储

为了应对不同监控指标数据的存储需求,我们主要使用了HBase、OpenTSDB、Elasticsearch等数据存储框架。

图片 12

数据存储我们踩过了很多的坑,总结下来主要有以下几点:


集群划分:依据各产品线应用的数据规模,合理划分线上存储资源,比如我们的ES集群是按照产品线、核心系统、数据大小等进行规划切分;

• 性能优化:Linux系统层优化、TCP优化、存储参数优化等;


数据操作:数据批量入库(避免单条记录保存),例如针对HBase数据存储可以通过在客户端进行数据缓存、批量提交、避免客户端同RegionServer频繁建立连接(减少RPC请求次数)

数据质量

我们的系统在持续不断地产生非常多的事件、服务间的链路消息和应用日志,这些数据在得到处理之前需要经过Kafka。那么,我们的平台是如何实时地对这些数据进行审计呢?

为了监控Kafka数据管道的健康状况并对流经Kafka的每个消息进行审计,我们调研并分析了Uber开源的审计系统Chaperone,在经过各种测试之后,我们决定自研来实现需求,主要是因为我们希望具备任意节点任意代码块内的数据审计需求,同时需要结合我们自己的数据管道特点,设计和实现达成一系列目标:数据完整性与时延;数据质量监控需要近实时;数据产生问题时便于快速定位(提供诊断信息帮助解决问题);监控与审计本身高度可信;监控平台服务高可用、超稳定等;

为了满足以上目标,数据质量审计系统的实现原理:把审计数据按照时间窗口聚合,统计一定时间段内的数据量,并尽早准确地检测出数据的丢失、延迟和重复情况。同时有相应的逻辑处理去重,晚到以及非顺序到来的数据,同时做各种容错处理保证高可用。

数据展示

为了实现监控指标的数据可视化,我们自研了前端数据可视化项目,同时我们也整合了外部第三方开源的数据可视化组件(grafana、kibana),在整合的过程中我们遇到的问题:权限控制问题(内部系统SSO整合)主要是通过自研的权限代理系统解决、去除kibana官方提供的相关插件、完善并自研了ES集群监控插件等。

核心功能及落地实践

系统监控

我们的系统监控主要使用了OpenTSDB作为数据存储、Grafana作为数据展示,TSDB数据存储层我们通过读写分离的方式减轻存储层的压力,TSDB同Grafana整合的过程中我们也遇到了数据分组展示的问题(海量指标数据下查询出分组字段值,通过建立独立的指标项进行数据查询),如下图某机器系统监控效果:

图片 13

应用监控

针对各个Java应用,我们提供了不同的监控类型用于应用内指标数据的度量。

图片 14

业务监控

针对业务监控,我们可以通过编码埋点、日志输出、HTTP接口等不同的方式进行业务监控指标采集,同时支持多维度数据报表展示,如下图所示:

图片 15

我们的业务监控通过自助化的方式让各应用方便捷的接入,如下图监控项定义:

图片 16

日志搜索

为了支撑好研发人员线上排查故障,我们开发了统一日志搜索平台,便于研发人员在海量日志中定位问题。

图片 17

未来展望

随着IT新兴技术的迅猛发展,罗马监控体系未来的演进之路:

• 多语言支撑:满足多语言的监控需求(性能监控、业务监控、日志搜索等)

• 智能化监控:提高报警及时性、准确性等避免报警风暴(ITOA、AIOps)

• 容器化监控:随着容器化技术的验证落地实施,容器化监控开启布局;

总结

罗马(Roma)是一个能够对应用进行深度监控的全链路监控平台,主要涵盖了应用外、应用内、应用间等不同维度的监控目标,例如应用监控、业务监控、系统监控、中间件监控、统一日志搜索、调用链跟踪等。能够帮助开发者进行快速故障诊断、性能瓶颈定位、架构梳理、依赖分析、容量评估等工作。

笔者自2016年加入WiFi万能钥匙,现任WiFi万能钥匙高级架构师,拥有10年互联网…

◆面对全球多地域海量用户的WiFi连接请求,如何保障用户连接体验?

5.6 日志监控

通常情况下,随着系统的运行,操作系统会产生系统日志,应用程序会产生应用程序的访问日志、错误日志,运行日志,网络日志,我们可以使用ELK来进行日志监控。

对于日志监控来说,最见的需求就是收集、存储、查询、展示,开源社区正好有相对应的开源项目:
logstash + elasticsearch + kibana
我们将这三个组合起来的技术称之为ELK Stack,所以说ELK
Stack指的是Elasticsearch、Logstash、Kibana技术栈的结合。

如果收集了日志信息,那么如果部署更新有异常出现,可以立即在kibana上看到。

图片 18

Elk日志展示

当然也可以通过Zabbix过滤错误日志来进行告警。

图片 19

zabbix日志展示

CPU

CPU有几个重要的概念:上下文切换、运行队列和使用率。

这也是我们CPU监控的几个重点指标。
通常情况,每个处理器的运行队列不要高于3,CPU
利用率中用“户态/内核态”比例维持在70/30,空闲状态维持在50%,上下文切换要根据系统繁忙程度来综合考量。

针对CPU常用的工具有:htop、top、vmstat、mpstat、dstat、glances

早期为了快速支撑业务发展,我们主要使用了开源的监控方案保障线上系统的稳定性:Cat、Zabbix,随着业务发展的需要,开源的解决方案已经不能满足我们的业务需求,我们迫切需要构建一套满足我们现状的全链路监控体系:

5.9 性能监控

全面监控网页性能,DNS响应时间、HTTP建立连接时间、页面性能指数、响应时间、可用率、元素大小等
zabbix提供URL监控:Zabbix Web 监控
图片 20

Zabbix站点监控

图片 21

图片 22

图片 23

图片 24

终端响应时间

第三方监控监控大盘。各类图表一目了然,全面体现网页性能健康状况。

9.流量分析。

平时我们分析日志都是拿awk sed
xxx一堆工具来实现。这样对我们统计ip、pv、uv不是很方便。那么可以使用百度统计、google统计、商业,让开发嵌入代码即可。为了避免隐私也可以使用piwik来做相关的流量分析。

图片 25

4 监控流程

上面介绍了这么多,那么到底选择什么监控工具最合适呢,我这里推荐几款开源监控工具:zabbix、Open-Falcon、LEPUS天兔
但是本文还是基于zabbix来构建整个监控体系生态圈。
那么下面我们就来聊聊,zabbix的整个流程:

图片 26

监控流程

1.数据采集:
Zabbix通过SNMP、Agent、ICMP、SSH、IPMI等对系统进行数据采集
2.数据存储: Zabbix存储在MySQL上,也可以存储在其他数据库服务
3.数据分析:
当我们事后需要复盘分析故障时,zabbix能给我们提供图形以及时间等相关信息,方面我们确定故障所在。
4.数据展示: web界面展示、(移动APP、java_php开发一个web界面也可以)
5.监控报警:电话报警、邮件报警、微信报警、短信报警、报警升级机制等(无论什么报警都可以)
6.报警处理:当接收到报警,我们需要根据故障的级别进行处理,比如:重要紧急、重要不紧急,等。根据故障的级别,配合相关的人员进行快速处理。

6.Web监控。

web监控的话题其实还是很多。比如可以使用自带的web监控来监控页面相关的延迟、js响应时间、下载时间、等等。这里我推荐使用专业的商业软件,监控宝或听云来实现。毕竟人家全国各地都有机房。(如果本身是多机房那就另说了)

◆……

5.1 硬件监控

早期我们通过机房巡检的方式,查看硬件设备灯光闪烁情况判断是否故障,这样非常浪费人力,并且是重复性无技术含量的工作,大家懂得。

图片 27

硬件监控

当然我们现在可以通过IPMI对硬件详细情况进行监控,并对CPU、内存、磁盘、温度、风扇、电压等设置报警设置报警阈值(自行对监控报警内容编写合理的报警范围)
IPMI监控硬件服务参考资料

图片 28

IPMI

IPMI工具无法获取到硬件的状态,可以借助MegaCli工具探测Raid磁盘队列状态
zabbix提供IPMI监控模板:Zabbix IPMI Interface
系统自带的IPMI模板只能监控,风扇,电源,和部分温度

7.日志监控。

如果是web的话可以使用监控Nginx的50x、40x的错误日志,PHP的ERROR日志。其实这些需求无非是,收集、存储、查询、展示,我们其实可以使用开源的ELKstack来实现。Logstash(收集)、elasticsearch(存储+搜索)、kibana(展示)

随着IT新兴技术的迅猛发展,罗马监控体系未来的演进之路:

5.5 流量分析

网站流量分析对于运维人员来说,更是一门必须掌握的知识了。比如对于一家电商公司来说:
通过对订单来源的统计和分析,可以了解我们在某个网站上的广告投入有没有收到预期的效果。
可以区分不同地区的访问人数、甚至商品交易额等。

百度统计、google分析、站长工具等等,只需要在页面嵌入一个js即可。
但是,数据始终是在对方手中,个性化定制不方便,于是google出一个叫piwik的开源分析工具

图片 29

piwik

图片 30

百度统计

5.7 安全监控

虽然Linux开源的安全产品不少,比如四层iptables,七层WEB防护nginx+lua实现WAF,最后将相关的日志都收至Elkstack,通过图形化进行不同的攻击类型展示。但是始终是一件比较耗费时间,并且个人效果并不是很好。这个时候我们可以选择接入第三方服务厂商。

三方厂商提供全面的漏洞库,涵盖服务、后门、数据库、配置检测、CGI、SMTP等多种类型全面检测主机、Web应用漏洞自主挖掘和行业共享相结合第一时间更新0day漏洞,杜绝最新安全隐患

图片 31

前言介绍

内存

通常我们需要监控内存的使用率、SWAP使用率、同时可以通过zabbix描绘内存使用率的曲线图形发现某服务内存溢出等。

针对内存常用的工具有: free、top、vmstat、glances

每台机器上都会部署agent(同客户端建立TCP长连接),agent的主要职责是数据转发、数据采集(日志文件读取、系统监控指标获取等),agent在获取到性能指标数据后会发送至kafka集群,在每个机房都会独立部署kafka集群用于监控指标数据的发送缓冲,便于后端的节点进行数据消费、数据存储等。

5.7 安全监控

虽然Linux开源的安全产品不少,比如四层iptables,七层WEB防护nginx+lua实现WAF,最后将相关的日志都收至Elkstack,通过图形化进行不同的攻击类型展示。但是始终是一件比较耗费时间,并且个人效果并不是很好。这个时候我们可以选择接入第三方服务厂商。

图片 32

图片 33

图片 34

某某三方安全

三方厂商提供全面的漏洞库,涵盖服务、后门、数据库、配置检测、CGI、SMTP等多种类型
全面检测主机、Web应用漏洞自主挖掘和行业共享相结合第一时间更新0day漏洞,杜绝最新安全隐患

5.4 网络监控

网络监控是我们构建监控平台是必须要考虑的,尤其是针对有多个机房的场景,各个机房之间的网络状态,机房和全国各地的网络状态都是我们需要重点关注的对象,那么如何掌握这些状态信息呢?我们需要借助于网络监控工具Smokeping。

Smokeping 是rrdtool的作者Tobi
Oetiker的作品,是用Perl写的,主要是监视网络性能,www
服务器性能,dns查询性能等,使用rrdtool绘图,而且支持分布式,直接从多个agent进行数据的汇总。

同时,由于自己监控点比较少,还可以借助很多商业的监控工具,比如监控宝、听云、基调、博瑞等。同时这些服务提供商还可以帮助你监控CDN的状态。

为了满足以上目标,数据质量审计系统的实现原理:把审计数据按照时间窗口聚合,统计一定时间段内的数据量,并尽早准确地检测出数据的丢失、延迟和重复情况。同时有相应的逻辑处理去重,晚到以及非顺序到来的数据,同时做各种容错处理保证高可用。

监控是整个运维乃至整个产品生命周期中最重要的一环,事前及时预警发现故障,事后提供详实的数据用于追查定位问题。
目前业界有很多不错的开源产品可供选择。选择一款开源的监控系统,是一个省时省力,效率最高的方案。当然对监控不是很明白的朋友们,看了以下文章可能会对监控整个体系有比较深刻的认识。

三方监控:

现在市场上有很多不错的第三方监控,比如:监控宝、监控易、听云、还有很多云厂商自带监控,但是在这里我们不打算着重介绍,如果想了解三方监控可自行上官网咨询。

一个完美的监控体系会涵盖IT领域内方方面面的监控目标,从目前国内外各互联网公司的监控发展来看,很多公司把不同的监控目标划分了不同的研发团队进行处理,但这样做会带来一些问题:人力资源浪费、系统重复建设、数据资产不统一、全链路监控实施困难。目前,各公司在监控领域采用的各解决方案,如下图所示:

5.3 应用监控

把硬件监控和系统监控研究明白后,我们进一步操作是需要登陆到服务器上查看服务器运行了哪些服务,都需要监控起来。
应用服务监控也是监控体系中比较重要的内容,例如:
LVS、Haproxy、Docker、Nginx、PHP、Memcached、Redis、MySQL、Rabbitmq等等,相关的服务都需要使用zabbix监控起来。

图片 35

nginx_status

图片 36

PHP-FPM_status

图片 37

Redis_status

图片 38

JVM监控

笔者之前写过服务监控详细的操作过程,这里就不一一展示,详情访问:zabbix监控各种应用服务

zabbix提供应用服务监控:Zabbix Agent UserParameter
zabbix提供的Java监控:Zabbix JMX Interface
percona提供MySQL数据库监控:percona-monitoring-plulgins

IO

IO分为磁盘IO和网络IO。除了在做性能调优我们要监控更详细的数据外,那么日常监控,只关注磁盘使用率、磁盘吞吐量、磁盘写入繁忙程度,网络也是监控网卡流量即可。

常用工具有:iostat、iotop、df、iftop、sar、glances

全链路监控

5.8 API监控

由于API变得越来越重要,很显然我们也需要这样的数据来分辨我们提供的
API是否能够正常运作。
监控API接口GET、POST、PUT、DELETE、HEAD、OPTIONS的请求
可用性、正确性、响应时间为三大重性能指标

图片 39

API监控

图片 40

三方API监控

图片 41
图片 42

响应时间

5.9 性能监控

全面监控网页性能,DNS响应时间、HTTP建立连接时间、页面性能指数、响应时间、可用率、元素大小等

由于各产品线应用部署在多个机房,为了满足各个应用在多个机房内都可以被监控的需求,罗马监控平台需要支持多机房内应用监控的场景,为了避免罗马各组件在各个机房内重复部署,同时便于监控指标数据的统一存储、统一分析等,各个机房内的监控指标数据最终会同步至主机房内,最终在主机房内进行数据分析、数据存储等。

1 监控方法

既然我们了解到了监控的重要性、以及监控的目的,那么下面我们需要了解下监控有哪些方法。

图片 43

监控方法

1.了解监控对象:我们要监控的对象你是否了解呢?比如CPU到底是如何工作的?
2.性能基准指标:我们要监控这个东西的什么属性?比如CPU的使用率、负载、用户态、内核态、上下文切换。
3.报警阈值定义:怎么样才算是故障,要报警呢?比如CPU的负载到底多少算高,用户态、内核态分别跑多少算高?
4.故障处理流程:收到了故障报警,那么我们怎么处理呢?有什么更高效的处理流程吗?

7 报警处理

一般报警后我们故障如何处理,首先,我们可以通过告警升级机制先自动处理,比如nginx服务down了,可以设置告警升级自动启动nginx。
但是如果一般业务出现了严重故障,我们通常根据故障的级别,故障的业务,来指派不同的运维人员进行处理。
当然不同业务形态、不同架构、不同服务可能采用的方式都不同,这个没有一个固定的模式套用。

图片 44

image.png

图片 45

  • 一篇文章全面了解监控知识体系
    • 前言介绍
    • 作者介绍
    • 0 监控目标
    • 1 监控方法
    • 2 监控核心
    • 3 监控工具
    • 4 监控流程
    • 5 监控指标
      • 5.1 硬件监控
      • 5.2 系统监控
      • 5.3 应用监控
      • 5.4 网络监控
      • 5.5 流量分析
      • 5.6 日志监控
      • 5.7 安全监控
      • 5.8 API监控
      • 5.9 性能监控
      • 5.10 业务监控
    • 6 监控报警
    • 7 报警处理
    • 8 面试监控
    • 9 监控总结

5.6 日志监控

通常情况下,随着系统的运行,操作系统会产生系统日志,应用程序会产生应用程序的访问日志、错误日志,运行日志,网络日志,我们可以使用ELK来进行日志监控。

对于日志监控来说,最见的需求就是收集、存储、查询、展示,开源社区正好有相对应的开源项目:
logstash(收集) + elasticsearch(存储+搜索) + kibana(展示)
我们将这三个组合起来的技术称之为ELK Stack,所以说ELK
Stack指的是Elasticsearch、Logstash、Kibana技术栈的结合。

如果收集了日志信息,那么如果部署更新有异常出现,可以立即在kibana上看到。

6 监控报警

故障报警通知的方式有很多种,当然我们最常用的还是短信,邮件

图片 46

图片 47

短信报警

图片 48

邮件报警

分分钟拯救监控知识体系
5.1 硬件监控
5.2 系统监控
5.3 应用监控
5.4 网络监控
5.5 流量分析
5.6 日志监控
5.7 安全监控
5.8 API监控
5.9 性能监控
5.10 业务监控
0 监控目标
1 监控方法
2 监控核心
3 监控工具
4 监控流程
5 监控指标
6 监控报警
7 报警处理
8 面试监控
9 监控总结

应用外:主要是从应用所处的运行时环境进行监控(硬件、网络、操作系统等)

5.10 业务监控

没有业务指标监控的监控平台,不是一个完善的监控平台,通常在我们的监控系统中,必须将我们重要的业务指标进行监控,并设置阈值进行告警通知。比如电商行业:

每分钟产生多少订单,
每分钟注册多少用户,
每天有多少活跃用户,
每天有多少推广活动,
推广活动引入多少用户,
推广活动引入多少流量,
推广活动引入多少利润,
今天商品打包出库多少,
今天退货商品有多少,
等等 重要指标都可以加入zabbix上,然后通过screen展示。
注:由于业务监控图表,涉及到隐私的数据太多,就不截图。

6 监控报警

故障报警通知的方式有很多种,当然我们最常用的还是短信,邮件

图片 49

image.png

• 性能影响:对业务系统的性能影响最小化(CPU、Load、Memory、IO等)

5 监控指标

我们上面了解了监控方法、目标、流程、也了解了监控有哪些工具,可能有人会疑惑,我们具体要监控写什么东西,那么我在这里进行了分类整理:

硬件监控
系统监控
应用监控
网络监控
流量分析
日志监控
安全监控
API监控
性能监控
业务监控

5.2 系统监控

中小型企业基本全是Linux服务器,那么我们肯定是要监控起系统资源的使用情况,系统监控是监控体系的基础。

监控主要对象:

图片 50

image.png

数据存储

7 报警处理

一般报警后我们故障如何处理,首先,我们可以通过告警升级机制先自动处理,比如nginx服务down了,可以设置告警升级自动启动nginx。
但是如果一般业务出现了严重故障,我们通常根据故障的级别,故障的业务,来指派不同的运维人员进行处理。
当然不同业务形态、不同架构、不同服务可能采用的方式都不同,这个没有一个固定的模式套用。

图片 51

5.5 流量分析

网站流量分析对于运维人员来说,更是一门必须掌握的知识了。比如对于一家电商公司来说:
通过对订单来源的统计和分析,可以了解我们在某个网站上的广告投入有没有收到预期的效果。
可以区分不同地区的访问人数、甚至商品交易额等。

百度统计、google分析、站长工具等等,只需要在页面嵌入一个js即可。
但是,数据始终是在对方手中,个性化定制不方便,于是google出一个叫piwik的开源分析工具。

图片 52

2 监控核心

我们了解了监控的方法、监控对象、性能指标、报警阈值定义、以及故障处理流程几步骤,当然我们更需要知道监控的核心是什么?

图片 53

监控核心

1.发现问题:当系统发生故障报警,我们会收到故障报警的信息
2.定位问题:故障邮件一般都会写某某主机故障、具体故障的内容,我们需要对报警内容进行分析,比如一台服务器连不上:我们就需要考虑是网络问题、还是负载太高导致长时间无法连接,又或者某开发触发了防火墙禁止的相关策略等等,我们就需要去分析故障具体原因。
3.解决问题:当然我们了解到故障的原因后,就需要通过故障解决的优先级去解决该故障。
4.总结问题:当我们解决完重大故障后,需要对故障原因以及防范进行总结归纳,避免以后重复出现。

1. 硬件监控。

通过SNMP来进行路由器交换机的监控(这些可以跟一些厂商沟通来了解如何做)、服务器的温度以及其他,可以通过IPMI来实现。当然如果没有硬件全都是云,直接跳过这一步骤。

架构原则

0 监控目标

我们先来了解什么是监控,监控的重要性以及监控的目标,当然每个人所在的行业不同、公司不同、业务不同、岗位不同、对监控的理解也不同,但是我们需要注意,监控是需要站在公司的业务角度去考虑,而不是针对某个监控技术的使用。

图片 54

监控目标

  • 1.对系统不间断实时监控:实际上是对系统不间断的实时监控
  • 2.实时反馈系统当前状态:我们监控某个硬件、或者某个系统,都是需要能实时看到当前系统的状态,是正常、异常、或者故障
  • 3.保证服务可靠性安全性:我们监控的目的就是要保证系统、服务、业务正常运行
  • 4.保证业务持续稳定运行:如果我们的监控做得很完善,即使出现故障,能第一时间接收到故障报警,在第一时间处理解决,从而保证业务持续性的稳定运行。

2. 系统监控。

如CPU的负载,上下文切换、内存使用率、磁盘读写、磁盘使用率、磁盘inode使用率。当然这些都是需要配置触发器,因为默认太低会频繁报警。

◆多维度监控(系统监控、业务监控、应用监控、日志搜索、调用链跟踪等)

3 监控工具

下面我们需要选择一款合适公司业务的监控工具进行监控,这里我对监控工具进行了简单的分类
图片 55

监控工具

老牌监控:
MRTG(Multi Route Trffic
Grapher)
是一套可用来绘制网络流量图的软件,由瑞士奥尔滕的Tobias
Oetiker与Dave Rand所开发,以GPL授权。
MRTG最好的版本是1995年推出的,用perl语言写成,可跨平台使用,数据采集用SNMP协议,MRTG将手机到的数据通过Web页面以GIF或者PNG格式绘制出图像。

Grnglia是一个跨平台的、可扩展的、高性能的分布式监控系统,如集群和网格。它基于分层设计,使用广泛的技术,用RRDtool存储数据。具有可视化界面,适合对集群系统的自动化监控。其精心设计的数据结构和算法使得监控端到被监控端的连接开销非常低。目前已经有成千上万的集群正在使用这个监控系统,可以轻松的处理2000个节点的集群环境。

Cacti是一套基于PHP、MySQL、SNMP和RRDtool开发的网络流量监测图形分析工具,它通过snmpget来获取数据使用RRDtool绘图,但使用者无须了解RRDtool复杂的参数。提供了非常强大的数据和用户管理功能,可以指定每一个用户能查看树状结构、主机设备以及任何一张图,还可以与LDAP结合进行用户认证,同时也能自定义模板。在历史数据展示监控方面,其功能相当不错。
Cacti通过添加模板,使不同设备的监控添加具有可复用性,并且具备可自定义绘图的功能,具有强大的运算能力

Nagios是一个企业级监控系统,可监控服务的运行状态和网络信息等,并能监视所指定的本地或远程主机状态以及服务,同时提供异常告警通知功能等。
Nagios可运行在Linux和UNIX平台上。同时提供Web界面,以方便系统管理人员查看网络状态、各种系统问题、以及系统相关日志等
Nagios的功能侧重于监控服务的可用性,能根据监控指标状态触发告警。
目前Nagios也占领了一定的市场份额,不过Nagios并没有与时俱进,已经不能满足于多变的监控需求,架构的扩展性和使用的便捷性有待增强,其高级功能集成在商业版Nagios
XI中。

Smokeping主要用于监视网络性能,包括常规的ping、www服务器性能、DNS查询性能、SSH性能等。底层也是用RRDtool做支持,特点是绘制图非常漂亮,网络丢包和延迟用颜色和阴影来标示,支持将多张图叠放在一起,其作者还开发了MRTG和RRDtll等工具。
Smokeping的站点为:

开源监控系统OpenTSDB用Hbase存储所有时序的数据,来构建一个分布式、可伸缩的时间序列数据库。它支持秒级数据采集,支持永久存储,可以做容量规划,并很容易地接入到现有的告警系统里。
OpenTSDB可以从大规模的集群(包括集群中的网络设备、操作系统、应用程序)中获取相应的采集指标,并进行存储、索引和服务,从而使这些数据更容易让人理解,如Web化、图形化等。

王牌监控

Zabbix是一个分布式监控系统,支持多种采集方式和采集客户端,有专用的Agent代理,也支持SNMP、IPMI、JMX、Telnet、SSH等多种协议,它将采集到的数据存放到数据库,然后对其进行分析整理,达到条件触发告警。其灵活的扩展性和丰富的功能是其他监控系统所不能比的。相对来说,它的总体功能做的非常优秀。
从以上各种监控系统的对比来看,Zabbix都是具有优势的,其丰富的功能、可扩展的能力、二次开发的能力和简单易用的特点,读者只要稍加学习,即可构建自己的监控系统。

小米的监控系统:open-falcon。open-falcon的目标是做最开放、最好用的互联网企业级监控产品。

OWL是TalkingData公司推出的一款开源分布式监控系统OWLgithub地址

三方监控:

现在市场上有很多不错的第三方监控,比如:监控宝、监控易、听云、还有很多云厂商自带监控,但是在这里我们不打算着重介绍,如果想了解三方监控可自行上官网咨询。

10.可视化。

通过screen以及引入一些第三方的库来美化界面,同时我们也需要知道,订单量突然增加、突然减少。或者说突然来了一大波流量,这流量从哪儿来,是不是推广了,还是被攻击了。可以结合监控平来梳理各个系统之间的业务关系。

数据传输

5.2 系统监控

中小型企业基本全是Linux服务器,那么我们肯定是要监控起系统资源的使用情况,系统监控是监控体系的基础。

监控主要对象:

图片 56

CPU有几个重要的概念:上下文切换、运行队列和使用率。

这也是我们CPU监控的几个重点指标。
通常情况,每个处理器的运行队列不要高于3,CPU
利用率中用“户态/内核态”比例维持在70/30,空闲状态维持在50%,上下文切换要根据系统繁忙程度来综合考量。

针对CPU常用的工具有:htop、top、vmstat、mpstat、dstat、glances

zabbix提供系统监控模板:Zabbix Agent Interface

图片 57

CPU整体状态

图片 58

上下文切换

图片 59

负载状态

内存:通常我们需要监控内存的使用率、SWAP使用率、同时可以通过zabbix描绘内存使用率的曲线图形发现某服务内存溢出等。

针对内存常用的工具有: free、top、vmstat、glances

图片 60

内存使用率

IO分为磁盘IO和网络IO。除了在做性能调优我们要监控更详细的数据外,那么日常监控,只关注磁盘使用率、磁盘吞吐量、磁盘写入繁忙程度,网络也是监控网卡流量即可。

常用工具有:iostat、iotop、df、iftop、sar、glances

图片 61

磁盘使用率

图片 62

磁盘读/写吞吐

图片 63

磁盘读/写次数

图片 64

网卡进出口流量

图片 65

TCP11种状态信息

其它的系统监控还有运行的进程端口、进程数、登陆用户、Open
File等(详细查看zabbix自带OS Linux模板)

图片 66

其他相关监控

12.分布式监控

面对每天40多亿次的WiFi连接请求,每次请求都会经历内部数十个微服务系统,每个微服务的监控维度又都会涉及应用外、应用内、应用间等多个监控指标,目前罗马监控体系每天需要处理近千亿次指标数据、近百TB日志数据。面对海量的监控数据罗马(Roma)如何应对处理?接下来,笔者带大家从系统架构设计的角度逐一进行剖析。

8 面试监控

在运维面试中,常常会被问题监控相关的问题,那么这个问题到底该如何来回答,我针对本文给大家提供了一个简单的回答思路。

1.硬件监控。
通过SNMP来进行路由器交换机的监控(这些可以跟一些厂商沟通来了解如何做)、服务器的温度以及其他,可以通过IPMI来实现。当然如果没有硬件全都是云,直接跳过这一步骤。
2.系统监控。
如CPU的负载,上下文切换、内存使用率、磁盘读写、磁盘使用率、磁盘inode使用率。当然这些都是需要配置触发器,因为默认太低会频繁报警。
3.服务监控。
比如公司用的LNMP架构,nginx自带Status模块、PHP也有相关的Status、MySQL的话可以通过percona官方工具来进行监控。Redis这些通过自身的info获取信息进行过滤等。方法都类似。要么服务自带。要么通过脚本来实现想监控的内容,以及报警和图形功能。
4.网络监控。
如果是云主机又不是跨机房,那么可以选择不监控网络。当然你说我们是跨机房以及如何如何。推荐使用smokeping来做网络相关的监控。或者直接交给你们的网络工程师来做,因为术业有专攻。
5.安全监控。
如果是云主机可以考虑使用自带的安全防护。当然也可以使用iptables。如果是硬件,那么推荐使用硬件防火墙。使用云可以购买防DDOS,避免出现故障导致down机一天。如果是系统,那么权限、密码、备份、恢复等基础方案要做好。web同时也可以使用Nginx+Lua来实现一个web层面的防火墙。当然也可以使用集成好的openresty。
6.Web监控。
web监控的话题其实还是很多。比如可以使用自带的web监控来监控页面相关的延迟、js响应时间、下载时间、等等。这里我推荐使用专业的商业软件,监控宝或听云来实现。毕竟人家全国各地都有机房。(如果本身是多机房那就另说了)
7.日志监控。
如果是web的话可以使用监控Nginx的50x、40x的错误日志,PHP的ERROR日志。其实这些需求无非是,收集、存储、查询、展示,我们其实可以使用开源的ELKstack来实现。Logstash、elasticsearch、kibana
8.业务监控。
我们上面做了那么多,其实最终还是保证业务的运行。这样我们做的监控才有意义。所以业务层面这块的监控需要和开发以及总监开会讨论,监控比较重要的业务指标,然后通过简单的脚本就可以实现,最后设置触发器即可
9.流量分析。
平时我们分析日志都是拿awk sed
xxx一堆工具来实现。这样对我们统计ip、pv、uv不是很方便。那么可以使用百度统计、google统计、商业,让开发嵌入代码即可。为了避免隐私也可以使用piwik来做相关的流量分析。
10.可视化。
通过screen以及引入一些第三方的库来美化界面,同时我们也需要知道,订单量突然增加、突然减少。或者说突然来了一大波流量,这流量从哪儿来,是不是推广了,还是被攻击了。可以结合监控平来梳理各个系统之间的业务关系。
11.自动化监控。
如上我们做了那么多的工作,当然不能是一台一台的来加key实现。可以通过Zabbix的主动模式以及被动模式来实现。当然最好还是通过API来实现。

12.分布式监控

0 监控目标

我们先来了解什么是监控,监控的重要性以及监控的目标,当然每个人所在的行业不同、公司不同、业务不同、岗位不同、对监控的理解也不同,但是我们需要注意,监控是需要站在公司的业务角度去考虑,而不是针对某个监控技术的使用。

图片 67

image.png

  1. 对系统不间断实时监控:实际上是对系统不间断的实时监控(这就是监控)
  2. 实时反馈系统当前状态:我们监控某个硬件、或者某个系统,都是需要能实时看到当前系统的状态,是正常、异常、或者故障
  3. 保证服务可靠性安全性:我们监控的目的就是要保证系统、服务、业务正常运行
  4. 保证业务持续稳定运行:如果我们的监控做得很完善,即使出现故障,能第一时间接收到故障报警,在第一时间处理解决,从而保证业务持续性的稳定运行。

图片 68

9 监控总结

真正想做到更完整的监控体系,目前的开源软件,确实无法很好的满足,有条件的公司都开始自己开发自己的监控系统,比如小米开源的Open-Falcon。
也有比较好的开源的监控框架如Sensu等,再加上influxdb、grafana可以用来定制符合自己企业的监控平台。

5.1 硬件监控

早期我们通过机房巡检的方式,查看硬件设备灯光闪烁情况判断是否故障,这样非常浪费人力,并且是重复性无技术含量的工作,大家懂得。

图片 69

image.png

当然我们现在可以通过IPMI对硬件详细情况进行监控,并对CPU、内存、磁盘、温度、风扇、电压等设置报警设置报警阈值(自行对监控报警内容编写合理的报警范围)

◆调用链跟踪(满足应用内、应用间调用链跟踪需求,内部中间件升级改造等)

5.4 网络监控

作为一个针对全国用户的电商网站,时刻掌握各地到机房的网络状态也是必须的。
网络监控是我们构建监控平台是必须要考虑的,尤其是针对有多个机房的场景,各个机房之间的网络状态,机房和全国各地的网络状态都是我们需要重点关注的对象,那么如何掌握这些状态信息呢?我们需要借助于网络监控工具Smokeping。

Smokeping 是rrdtool的作者Tobi
Oetiker的作品,是用Perl写的,主要是监视网络性能,www
服务器性能,dns查询性能等,使用rrdtool绘图,而且支持分布式,直接从多个agent进行数据的汇总。

同时,由于自己监控点比较少,还可以借助很多商业的监控工具,比如监控宝、听云、基调、博瑞等。同时这些服务提供商还可以帮助你监控CDN的状态。

图片 70

smokeping

图片 71

图片 72

监控宝

11.自动化监控。

如上我们做了那么多的工作,当然不能是一台一台的来加key实现。可以通过Zabbix的主动模式以及被动模式来实现。当然最好还是通过API来实现。

海外运营商众多,公网覆盖质量参差不齐,再加上运营商互联策略的不同,付出的代价将是高时延、高丢包的网络质量,钥匙产品走向海外过程中,首先会对整体网络质量情况有正确的预期,比如如果需要对于海外机房内的应用进行监控则依赖于在海外建立站点(主机房)、海外主站同国内主站进行互联互通,另外需要对监控指标数据分级处理,比如对于实时、准实时、离线等不同需求的指标数据采集时进行归类划分(控制不同需求、不同数据规模等指标数据进行采样策略的调整)

5.3 应用监控

把硬件监控和系统监控研究明白后,我们进一步操作是需要登陆到服务器上查看服务器运行了哪些服务,都需要监控起来。
应用服务监控也是监控体系中比较重要的内容,例如:
LVS、Haproxy、Docker、Nginx、PHP、Memcached、Redis、MySQL、Rabbitmq等等,相关的服务都需要使用zabbix监控起来。

• 数据集中化:监控数据集中化处理、分析、存储等(便于数据统计等)

2 监控核心

我们了解了监控的方法、监控对象、性能指标、报警阈值定义、以及故障处理流程几步骤,当然我们更需要知道监控的核心是什么?

图片 73

  1. 发现问题:当系统发生故障报警,我们会收到故障报警的信息
  2. 定位问题:故障邮件一般都会写某某主机故障、具体故障的内容,我们需要对报警内容进行分析,比如一台服务器连不上:我们就需要考虑是网络问题、还是负载太高导致长时间无法连接,又或者某开发触发了防火墙禁止的相关策略等等,我们就需要去分析故障具体原因。
  3. 解决问题:当然我们了解到故障的原因后,就需要通过故障解决的优先级去解决该故障。
  4. 总结问题:当我们解决完重大故障后,需要对故障原因以及防范进行总结归纳,避免以后重复出现。

2、条条大路通罗马(罗马通过多种数据采集方式收集各监控目标的数据);

3.服务监控。

比如公司用的LNMP架构,nginx自带Status模块、PHP也有相关的Status、MySQL的话可以通过percona官方工具来进行监控。Redis这些通过自身的info获取信息进行过滤等。方法都类似。要么服务自带。要么通过脚本来实现想监控的内容,以及报警和图形功能。

对于应用内监控主要是通过client客户端同所在机器上的agent建立TCP长连接的方式处理,agent同时也需要具备通过脚本调度的方式获取系统性能指标数据。

8 面试监控

在运维面试中,常常会被问题监控相关的问题,那么这个问题到底该如何来回答,我针对本文给大家提供了一个简单的回答思路。

数据同步

1 监控方法

既然我们了解到了监控的重要性、以及监控的目的,那么下面我们需要了解下监控有哪些方法。

图片 74

image.png

  1. 了解监控对象:我们要监控的对象你是否了解呢?比如CPU到底是如何工作的?
  2. 性能基准指标:我们要监控这个东西的什么属性?比如CPU的使用率、负载、用户态、内核态、上下文切换。
  3. 报警阈值定义:怎么样才算是故障,要报警呢?比如CPU的负载到底多少算高,用户态、内核态分别跑多少算高?
  4. 故障处理流程:收到了故障报警,那么我们怎么处理呢?有什么更高效的处理流程吗?

Author

发表评论

电子邮件地址不会被公开。 必填项已用*标注