这里有很全的监控组件,你适合哪一款?(2)
OpenTracing大有一统天下的架势,它在其中融合Tracing、Log、Metrics的概念。我们还是看张图吧,等真正去做的时候去了解也不晚(来源于网络): 值得一提的是,SpringCloud对它的支持还是比较全面的(OpenTracing API Contributions),但依赖关系和版本搞的非常混乱。建议参考后自己开发,大体使用”spring boot starter”技术,可以很容易的写上一版。 至于”Spring Cloud 2”,更近一步,集成了micrometer这种神器,对prometheus集成也是非常的有好。业务metrics监控将省下不少力气。 以上谈了这么多,仅仅是聊了一下收集方面而已。标准这个思路是非常对的,否则每个公司都要写一遍海量的收集组件,多枯燥。至于国内大公司的产品,是否会主动向其靠拢,我们拭目以待。 服务端方面,我们以Uber的Jaeger为例,说明一下服务端需要的大体组件:
是的,典型的无状态系统,对等节点当机无影响。 4、分析和预警 上面的状态图不止一次提到流计算,这也不用非要整个Spark Streaming,从kafka接收一份数据自己处理也叫流计算,选用最新的kafka stream也是不从的选择。重要的是聚合聚合聚合,重要的事情说三遍。 一般,算一些QPS,RT等,也就是纯粹的计数;或者斜率,也就是增长下降速度;复杂点的有TP值(有百分之多少的请求在XX秒内相应),还有调用链的服务拓扑图、日志异常的统计,都可以在这里进行计算。 幸运的是,流计算的API都比较简单,就是调试比较费劲。 分析后的数据属于加工数据,是要分开存储的,当然量小的话,也可以和原始数据混在一起。 分析后的数据量是可评估的,比如5秒一条数据,一天就固定的17280条,预警模块读的是分析后的数据(原始数据太大了),也会涉及大量的计算。 那么分析后的统计数据用来干什么用呢?一部分就是预警;另一部分就是展示。 1)预警 拿我设计的一个原型来看,对一个metric的操作大体有以下内容:
仅做参考,这只是配置的冰山一角。要把各种出发动作做一遍,你是要浪费很多脑细胞的。 2)展示 有很多可视化js库,但工作量一般都很大。但没办法,简单的用grafana配置一下就可以了,复杂点的还需要亲自操刀。 我这里有两张简单的grafana图,可以参考一下: [系统监控] [jvm监控一部分] 5、小结 整体来说,整个体系就是收集、处理、应用这大三类数据(logs、metrics、trace)。 其中有些组件的经验可以共用,但收集部分和应用部分相差很大。我尝试总结了一张图,但从中只能看到有哪些组件参与,只看图是临摹两可的。 具体的数据流转和处理,每种结构都不尽相同,这也是为什么我一直强调分而治之的原因。 但使用方式上,最好相差不要太大。无论后端的架构如何复杂,一个整体的外观将让产品变得更加清晰,你目前的工作,是不是也集中在此处呢? 三、一些组件 通过了解上面的内容,可以了解到我们习惯性的将监控系统所有的模块进行了拆解,你可以很容易的对其中的组件进行替换。比如beat替换flume、cassandra替换ES… 下面我将列出一些常用的组件,如有遗漏,欢迎补充。 1、数据收集组件 telegraf 用来收集监控项,influxdata家族的一员,是一个用Go编写的代理程序,可收集系统和服务的统计数据,并写入到多种数据库。支持的类型可谓非常广泛。 flume 主要用来收集日志类数据,apache家族。Flume-og和Flume-ng版本相差很大,是一个高可用的,高可靠的,分布式的海量日志采集、聚合和传输的系统。 Flume支持在日志系统中定制各类数据发送方,用于收集数据;同时,Flume提供对数据进行简单处理,并写到各种数据接受方(可定制)的能力。 Logstash Logstash是一个开源的日志收集管理工具,elastic家族成员。功能和flume类似,但占用资源非常的贪婪,建议使用时独立部署。功能丰富,支持ruby定义过滤条件。 StatsD node开发,使用udp协议传输,专门用来收集数据,收集完数据就发送到其他服务器进行处理。与telegraf类似。 CollectD collectd是一个守护(daemon)进程,用来定期收集系统和应用程序的性能指标,同时提供了机制,以不同的方式来存储这些指标值。 2、可视化 独立的可视化组件比较少,不过解决方案里一般都带一个web端,像grafana这么专注的,不太多。 Grafana 专注展示,颜值很高,集成了非常丰富的数据源。通过简单的配置,即可得到非常专业的监控图。 3、存储 有很多用的很少的,可以看这里: Grafana Plugins - extend and customize your Grafana. InfluxDB influx家族产品。Influxdb是一个开源的分布式时序、时间和指标数据库,使用go语言编写,无需外部依赖。支持的数据类型非常丰富,性能也很高。单节点使用时不收费的,但其集群要收费。 OpenTSDB OpenTSDB是一个时间序列数据库。它其实并不是一个db,单独一个OpenTSDB无法存储任何数据,它只是一层数据读写的服务,更准确的说它只是建立在Hbase上的一层数据读写服务。能够承受海量的分布式数据。 Elasticsearch 能够存储监控项,也能够存储log,trace的关系也能够存储。支持丰富的聚合函数,能够实现非常复杂的功能。但时间跨度太大的话,设计的索引和分片过多,ES容易懵逼。 4、解决方案 Open-Falcon 小米出品,它其实包含了agent、处理、存储等模块,并有自己的dashboard,算是一个解决方案,赞一下。 但目前用的较少,而且国内开源的东西尿性你也知道:公司内吹的高大上,社区用的却是半成品。 Graphite Graphite并不收集度量数据本身,而是像一个数据库,通过其后端接收度量数据,然后以实时方式查询、转换、组合这些度量数据。 Graphite支持内建的Web界面,它允许用户浏览度量数据和图。 最近发展很不错,经常和Collectd进行配对。grafana也默认集成其为数据源。 Prometheus golang开发,发展态势良好。它启发于 Google 的 borgmon 监控系统,2015才正式发布,比较年轻。 prometheus目标宏大,从其名字就可以看出来—普罗米修斯。另外,SpringCloud对它的支持也很好。 5、传统监控 图形还停留在使用AWT或者GD渲染上。总感觉这些东东处在淘汰的边缘呢。 Zabbix 使用占比特别大,大到我不需要做过多介绍。但随着节点的增多和服务的增多,大概在1k左右,你就会遇到瓶颈(包括开发定制瓶颈)。整体来说,小公司用的很爽,大公司用的很鸡肋。 Nagios 也算是比较古老了,时间久客户多。其安装配置相对较为复杂。功能不全较专一,个人不是很喜欢。 Ganglia (编辑:ASP站长网) |