需求
- 功能性监控(availability):我们希望能够及时的发现线上的bug,异常。
- 性能监控与调优(performance):我们希望能够识别可能的性能瓶颈,并且有数据支撑方便对性能进行调优。比如慢速SQL,缓存命中率,链接池等。
- 预警报警:我们希望能够第一时间收到线上异常,进行处理。
- 辅助线上故障定位、故障分析
- 运维支持:我们系统能够有数据支撑我们进行容量规划、报警和扩容,等。
- 自动化运维:比如自动扩容;或者根据监控的数据和配置的SLA进行服务降级。等等。
性能监控平台
- 提供一站式的性能数据收集、计算、存储和展示服务
- 支持自定义的数据指标名称和数据纬度
- 提供任意指标任意纬度的实时数据查询
监控对象
1、模块调用监控(URI监控)
- URI
- 调用总数
- 最大并发
- 总耗时
- 平均耗时
- 最快
- 最慢
- 错误数
- URIProfile(每个URL访问的具体调用信息,即使Tracer功能)
- URI请求方法
- 类型:Service/URL/DAO/IBATIS
- 总数
- 总耗时
- 平均耗时
- 耗时
- 错误数
2、Spring监控
- 类
- 方法
- 调用次数
- 总耗时
- 平均耗时
- 最大并发
- 最慢
- 错误次数
3、数据源监控
- 链接池中链接数
- 链接池链接数峰值
- 池中连接数峰值时间
- 活跃连接数
- 活跃连接数峰值
4、JDBC访问统计监控
- SQL语句
- 执行数
- 执行时间
- 错误数
- 读取行数
- 更行行数
5、Exception监控
- 异常类型:java.io.IOException, etc.
- 异常方法:
- URI
- 产生时间
- 异常数量
- 堆栈信息
6、JVM监控
- Overview
- Threading
- GC
- CPU
- Heap
7、其他信息
- 业务自定义信息,比如订单数量,支持成功数,点击次数,下载次数,等。
- Cache命中率
- 队列大小
- ...
监控方案设计
监控方案决策
1、每个应用自监控或者统一上报监控?
应用自监控,就是每个应用实例的监控数据存放在应用本身,比如一个Map。然后通过JMX或者其他方式暴露出去。然后开发人员可以通过JConsole或者API(一般是Web界面)得到这些监控数据。比如Druid就是这种做法。访问: hk01-xxxx-mob03.hk01:8090/druid/index.html 得到hk01-xxxx-mob03.hk01:8090这个应用的监控数据。
而统一上报监控方式,就是所有的应用监控数据都上报到监控中心,由监控中心负责接收、分析、合并、存储、可视化查询、报警等逻辑。这种方式是瘦客户端模型,客户端的职责就是埋点上报监控数据。所有的监控逻辑都在中心处理。
结论
自监控的话实现起来简单,并且没有与监控中心的网络交互,性能也会好很多。但是缺点就是缺乏全局的统计和监控。从实用角度来说还是集中式监控好一些。
2、如何避免key冲突?如何区分各个应用实例?
为了监控简单,我们希望监控项是不需要预定义的,监控项是一个
key => value
的形式。其中key是监控项的唯一ID,而value可以为数值类型(比如counter, timeInterval),文本类型(如exceptionMessage)。 如果不预定义监控项,那么就是由客户端按需创建key,然后上报 监控项, 服务器检测如果改监控项不存在就创建,否则根据监控项类型进行相应的操作(叠加 for counter,计算平均值 for timer等)。 这个特性很方便客户端监控自动化,但是这样也带来两个可能的问题:
- 不同的应用,有可能上报一样的key,这样会导致监控项冲突。
- 想要查看相同的应用的不同实例的上报情况。这种情形主要发生在查找集群短板的时候。Dragoon的监控上也有实例筛选项。
但是最理想的情况是我们既希望能够合并统计,又希望能够在需要的时候区分查看。比如我们希望统计NanTianMen这个应用的所有实例的监控数据,同时又希望能够单独查看每个实例的监控数据。Google和OpenTSDB提供了一种解决方案——对metrics打tags。这样相同key的 metrics会合并统计,又可以根据tags进行区分。对于上面的例子,假如上报的metric含有一 个host=xxx的tag和一个port=xxx的tag就可以区分出来了。但是这种情况会导致key对应的 数据特别多。根据tag过来会影响查询速度。所以需要trade off。
结论
对于key冲突,可以强制每个应用的客户端必须分配一个独立的appName/projectName `作为前缀。这个是合理的要求,这个appName也有利于区分应用各自的监控。如果出于安全考虑,不同应用还应该有appKey。 对于同一个应用不同实例的区分,可以在上报接口增加上报来源作为tag。可以让应用传递参数,也可以自动根据ip来。比如Google和OpenTSDB就是通过对metrics打tags来解决这个问题。这样相同key的 metrics会合并统计,又可以根据tags进行区分。对于上面的例子,假如上报的metric含有一个host=xxx的tag。但是这种情况会导致key对应的数据特别多。根据tag过来会影响查询速度。所以需要tradeoff。比如OpenTSDB就是支持并且要求必须有一个tag,比如host=webserver01。
3、监控中心与客户端应用之间要不要通过本地Agent上报?
采用集中式监控中心,意味着客户端与监控中心有交互。很多监控平台,比如阿里的Dragoon、新浪微博的Watchman,
Stackify都是有个本地agent的概念。Agent是OPS安装系统的时候预先安装好,每台机器一个Agent,负责该机器的所有监控数据上报。相当于应用与监控中心之间的一个通讯网关。应用通过JMX获取采集的数据,然后将数据上报给Agent,Agent再统一上报给Monitor。
这样的好处就是Client上报速度非常的快,而且基本不会失败。另外,同一机器上的多个client可以共用一个Agent通讯。而且Agent往往还承当了一个角色,就是主动收集机器监控信息(拉的方式)。缺点是需要预先按照Agent。所有也有很多监控平台是不走Agent的,直接client上报监控中心的方式。比如腾讯的ITIL和模块调用监控、Etsy的StatsD、Google的Cloud Monitor。大部分处于性能的考虑都是走UDP协议的,Google估计是因为是开发平台,走的是HTTP协议(Thus TCP协议)。这种方式简化了对客户端的预设要求和监控逻辑,实现起来比较简单。
结论
如果客户端与监控中心网络顺畅的情况下,绕开agent会简单很多。如果跨机房上报,那么异步化可能是很有必要的。采用agent是一个不错的方案。
4、存储最终状态还是事件序列
比如监控一个URL的请求数,每次+1,最终我们能够得到请求总数。这样的好处是节省存储空间和计算时间。但是由于只有一个最终状态,我们没有办法得到在什么时间段请求数最多。于是有另一种记录方式:对于每次请求都记录一次,而不是简单的+1。然后我们根据所有的签到记录,就可以统计出总请求数,和分布状况。但是缺点也很显然,就是浪费存储,并且每次都需要执行统计计算。
结论
最终状态还是弱了一些,事件序列会好一些,存储可以采用HBase这样的分布式存储系统,性能问题可以采用预聚合等方式解决。
Google Cloud Monitor就是采用这个这种方式的:
The Google Cloud Monitoring API lets you access monitoring data for Google Cloud services. The data is organized as metrics and stored as data points that represent information at a specific time or over a specific time period. Examples include the current CPU utilization of your virtual machine, the number of requests received by you web server, or custom metrics you define yourself. A list of data points measured at successive times is called a time series.
不过对于Counter类型的统计,确实可以考虑只是存储最终状态的。因为这种类型的metric,一般要的就是快速得到最终的状态,并且可能会有相应的报警策略。如果每次都要汇总,性能上往往不可接受。
5、数据模型
数据模型非常重要,它决定了监控系统的能力。比如我们为什么不使用NOAH,其中一个原因就是NOAH的监控项只是简单的key-value形式。当然,它会自动记录请求源IP。但是其他的参数,比如应用等,就没有办法上报存储了。
根据上面的描述,其实我们的metrics基本就是抽象为带tags/labels标签的key-value格式。这个也是
Google Cloud Monitor和
OpenTSDB对metrics的定义:
- key
- timestamp
- value - 这个OpenTSDB支持数值型的:integer和floating point。而Google Cloud Monitor支持的类型要丰富一些,见下面描述。
- tag(s) - A key/value pair consisting of a tagk (the key) and a tagv (the value). OpenTSDB要求至少要有一个tag。
Google Cloud Mnoitor对Metric进行分类,支持的metricType有(@see
metric-types):
- cumulative: The value is a total, accumulated since a given start time. For example, the total number of errors detected since a process started.
- delta: The value is a change over a specified time period. For example, the number of errors detected in a minute.
- gauge: The value is an instantaneous sample of a continuously-varying metric at a specific time. For example, a CPU's current temperature.
而metric的valueType有:
- bool: A Boolean value, either "true" or "false".
- distribution: A distribution, consisting of a list of buckets and optionally an underflow bucket and an overflow bucket. Each bucket has an upper bound, a lower bound, and a count. The distribution can be used to create a histogram.
- double: A double-precision floating-point value.
- int64: An integer value in the range [-263..263-1].
- string: A Unicode string with backslash escaping.
6、 数据存储
因为Events或者Metrics的特殊性,一般都会采用一种专门的存储结构——Distributed time series database。比较有名的开源产品有如下这些:
- RRD(round-robin-database): RRDtool使用的底层存储。C语言编写的。性能比较高
- whisper: Graphite底层的存储,Python写的
- prometheus: An open-source service monitoring system and time series database. 目前只有单机版本。
- InfluxDB: 开源distributed time series, metrics, and events database。Go语言编写, 不依赖于其他外部服务。底层支持多种存储引擎,目前是LevelDB, RocksDB, HyberLevelDB和LMDB(0.9之后只支持Bolt,最新版本采用了自己写的存储引擎)。
- OpenTSDB: 基于HBase编写的Time Series Database
- kairosdb: OpenTSDB的改善版,底层存储引擎是Cassandra。
- Heroic: Kairosdb的改善版,Spotify公司开源的时序数据库(Spotify的监控框架),引入了ElasticSearch作为元数据索引。目前还处于不稳定状态。
具体可以参考这篇论文:
tsdb: A Compressed Database for Time Series。
结论
如果要存储事件序列,那么InfluexDB和OpenTSDB是个非常不错的选择。都是可扩展,分布式存储,文档很详细,还是开源的。
influexDB 0.9.0之后支持tag,使用风格跟Google Cloud Monitor很相似,而且支持String类型。并且最重要的是不需要额外搭建HBase(Thus Hadoop & Zookeeper),看起来非常值得期待,不过笔者曾经试过0.9.6版本的InfluxDB用来存储我们的接口响应时间,结果根本撑不住(
InfluxDB becomes unavailable after heavy insert load)个人觉得这个产品还是太年轻,还没有到产品级别。OpenTSDBvalue不支持String类型,这意味着日志不能上报到OpenTSDB,需要另外处理。
由于这个比较复杂而且非常重要,我们在后面再单独详细讨论。
7、如果服务器挂掉了,统计数据怎么处理?缓存本地,等服务器起来再发送?还是丢弃?
前期可以先丢弃,后续要缓存起来。受影响比较大的是counter接口。
存储的话,可以考虑使用本地存储在RRD文件或者BDB中,或者消息队列中(RabbitMQ, ie.),最后再异步批量上报给中心的TSDB。
timestamp metrics value tags..
1366399993 mysql.Binlog_cache_disk_use 0 host=mydb.example.com
1366399993 mysql.Bytes_received 19453687 host=mydb.example.com
1366399993 mysql.Bytes_sent 1238166682 host=mydb.example.com
8、网络通信和协议
如何高性能的接收大量客户端的上报请求。以及使用什么通讯协议。
有几种选择:
- HTTP
- TCP
- UDP: fire and forget, 主要需要注意MTU问题。
同时要考虑同步和异步接口。
应用监控平台概要设计
初步决定采用基于metrics上报的中心监控(无Agent)模式。
业务监控流程
- 业务对需要监控的地方埋点监控逻辑
- 监控统计数据通过某种方式上报到监控中心(或者监控中心通过某种方式采集业务监控数据)
- 监控中心对监控数据提供可视化查询界面,方便查看监控结果
- 如果监控结果满足配置的报警条件,会自动通知相关的负责人进行处理
监控系统模块
1、Client
主要职责是提供便利的方式让用户添加监控项。包括如下几个模块:
- Metrics 监控项:counter, timer, etc.
- AOP拦截配置或者注解方便业务埋点(提供缺省的采集实现,业务通过配置开启相应的监控项)
- 监控数据上报客户端(Reporter)
- 当监控中心挂掉的时候,将消息先存储在本地(BDB?)
2、监控中心(MonitorCenter)
监控中心应该提供接收客户端监控统计数据的上报接口。接收数据包,并且对这些数据进行存储,分析和可视化。 可抽象为一个事件状态机,接收客户端发送的事件,对事件进行响应。主要包含如下模块:
- 上报API接口服务(事件接收器,receive packets, UDP is prefered)
- 事件处理器
- EventHandlers, Pipeline模式
- 内建的EventHandler: metrics(increment counters, timer, etc.)、Storage(periodically save the metrics to disk)、Analizer、Notifier
- 缓存和存储:对事件进行存储(需要考虑性能和容量)
- 定时任务处理器:Triggers, Actions, Scheduler
- 可视化界面(dashboards):Visualizer
- 配置管理界面,配置事件相应的负责人 && 事件处理工作流程。
上报API接口
- Counter接口: A counter is a value that never decreases.
void increment(String key);
void increment(String key, Integer delta);
- Gauges接口:A gauge is a value that has a discrete value at any given moment, like "heap_used" or "current_temperature".
void addGauge(String key, Double value);
- Metrics接口:A metric is tracked via distribution, and is usually used for timings. Metrics are collected by tracking the count, min, max, mean (average), and a simple bucket-based histogram of the distribution. This distribution can be used to determine median, 90th percentile, etc.
void addMetric(String key, T value);
其中针对时间的监控可以提供一个便利函数:
void addTimeMetric(String key, long timeInMillis);
- 日志上报接口: A label is just a key/value pair of strings, usually used to report a subsystem's state, like "boiler=offline".
void log(LoggerLevel level, String key, String message);
They have no real statistical value, but can be used to raise flags in logging and monitoring. 增加一个日志级别,可以根据日志级别来做相应的action。
大概是这样子的使用方式:
import me.arganzheng.study.monitor.*;
Agent agent = new Agent("yourAppName");
agent.increment("myapp.login");
agent.gauge("heap_free", 8675309);
agent.time("some.longProcess", new Runnable() {
public void run() {
// Do something....
});
agent.addMetric("Maintenance Now.", 600);
可以考虑使用注解简化客户端上报逻辑
newrelic:
@Trace(metricName=”YouMetricName”)
By default, the metric name will include the class name followed by the method name
时序数据库讨论
这里我们以两大开源的时序数据库:influxDB和OpenTSDB做对比讨论。
就文档看起来,influexDB使用起来更像传统的RDB。需要创建DB,但是不需要schema,columns是动态创建的。感觉columns就是OpenTSDB的tags键值对。
InfluxDB的抽象更类似于传统的关系型数据库,只是schemeless:Database, shard space, series(table), column。
写入格式:
- OpenTSDB: <tagk1=tagv1[ tagk2=tagv2 ...tagkN=tagvN]>
- influxDB: name [columns] [points]。其中timestamp由服务端生成。columns和points类似于SQL的insert columns values(..)语法。
例如:统计mysql.Bytes_received,
OpenTSDB是这样子:
1385327470774 mysql.Bytes_received 19453687 host=mydb.example.com app=mysql
HTTP格式是:
{
"metric": "mysql.Bytes_received",
"timestamp": 1385327470774,
"value": 19453687,
"tags": {
"hostName": "mydb.example.com",
"app": "mysql"
}
},
influxDB则是:
[
{
"name" : "mysql.Bytes_received",
"columns" : ["app", "value", "host"],
"points" : [
["mysql",19453687, "mydb.example.com"]
]
}
]
0.9之后支持tags:
{
"database": "mydb",
"retentionPolicy": "default",
"points": [
{
"name": "Bytes_received",
"tags": {
"host": "mydb.example.com",
"app": "mysql",
"region": "us-west"
},
"time": "2009-11-10T23:00:00Z",
"fields": {
"value": 19453687
}
}
]
}
需要注意的是influxDB的tags是默认索引的,但是fields(columns)则是没有索引的。也就是说我们无法高效的执行:响应时间(value) > 1000ms的记录。
另外值得注意的是influxDB的value值可以是String类型,这个OpenTSDB目前是不支持的。这意味着我们可以将错误日志也放在influxDB中。
可视化组件
如果我们采用了一站式的监控平台,像
Relic,
moskito,
prometheus,或者
graphite(严格来说,Graphite其实只是包含存储和可视化展示,并没有包含收集),那么你就不太需要关心可视化的事情(那可是相当烦人的,特别是对于一个后端开发工程师来说)。但是如果采用了OpenTSDB或者influxDB,那么其实它们只是解决了数据存储而已。数据收集和数据展示这块还是需要另外的组件来解决。有需求就有产品。在监控可视化这块,
Grafana貌似是唯一的选择。而且默认支持Graphite, InfluxDB & OpenTSDB。节目风格看起来非常像kibana,试试上就是在kibana的基础上二次开发的,原来是为了Graphite创建的。
这里有一篇文章介绍influxDB和grafana整合的,非常详细,可以参考一下:
OBIEE Monitoring and Diagnostics with InfluxDB and Grafana。
日志事件收集组件
参考文章
- Application Monitoring 收费产品,功能很强大。
- moskito 开源监控产品,思路跟我的挺match的。
- OpenTSDB2.0 非常好的PPT
- influxDB
- Grafana
- Relic
- kairosdb: OpenTSDB的改善版,底层存储引擎是Cassandra。
- Heroic: Kairosdb的改善版,Spotify公司开源的时序数据库
- Spotify的监控框架
- Advanced Time Series with Cassandra
文章来源:http://blog.arganzheng.me/posts/java-monitor-platform.html