这里有很全的监控组件，你适合哪一款？

但使用方式上，最好相差不要太大。无论后端的架构如何复杂，一个整体的外观将让产品变得更加清晰，你目前的工作，是不是也集中在此处呢?

三、一些组件

通过了解上面的内容，可以了解到我们习惯性的将监控系统所有的模块进行了拆解，你可以很容易的对其中的组件进行替换。比如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

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!