Graphite作为Metrics界的大哥
- 它是RRDTool的Network Service版,和RRD一样支持Metrics的精度递减,比如一天之内10秒一条,7天之内聚合到1分钟一条,一年之内聚合到1小时一条。
- 它支持丰富的查询函数,从简单的min/max/avg/sum 到 rate、top N等等,以Restful API提供。
- 它有整个生态圈的插件支持,而且简单的TCP Plain Text协议,自己来插入数据也很简单。
- 它有漂亮的DashBoard -- Grafana
- 它有完整的HA和Scalable 方案 -- Carbon-Relay
- 它有数据预聚合方案 -- Carbon-Aggregator
上面的一切,都只靠配置文件就能搞定, 不需要编一行代码。
但是,等你在服务器、应用的监控之外,真的将海量的业务Metrics也交给它,想不写一行代码就赚回一个看起来不错的报表系统时,问题来了。
百万Metrics......
每个Metrics在硬盘里都是一个文件。metrics的个数,最大估算值是所有维度大小的乘积,维度的增加让文件的个呈量级的增加。
写入的时候,依赖于Graphite自己很自豪的架构:Cluster Sharding分摊每台服务器上的Metric个数以及Carbon-Cache里的延时聚合批量写入同一个文件的机制持,对百万Metrics的支持并不困难。(唯一问题就是如果Carbon-Cache崩了,内存中未写入的数据会丢失)
但查询的时候......如果Dashboard里看的并不是某一个Metrics,而是某些维度下的一个合计,每次查询可能动不动都要打开上万个文件,就是件痛苦的事情。
解决方法之一是使用Carbon-Aggregator,像我们在报表系统里常做的那样,先做一些维度下的聚合。
比如,计数器只在每台Web服务器的内存里累加,metrics nam就是 traffic.server1.userlogin.count,因为我们只关心总用户登录数,就将20台server的数据聚合在一起,形成traffic.all.userlogin.count再发给carbon-cache,而原来属于每台server的记录则丢弃掉不再往后传,这样我们就少了20倍的metrics数量。
又比如 我们有时候会专门看某个app的使用情况,有时候又想看全部app的情况,则可以既新增一条allApp的聚合数据,也保留每一条app的数据。
好,铺垫完了。
读取百万Metrics时的真正问题
真正的问题1:carbon-aggregator是python写的基于Twisted的应用,见鬼的GIL问题,居然只能用到单核CPU。有时候单CPU核根本不够用。在Java里完全没想过会遇到的问题,别人说多核编程的时候总是很茫然,本来就多核的呀。。。。
真正的问题2:有些无法预先聚合的场景,比如要从2000个app中找出使用量最大的5个,则必须打开2000个app对应的全部文件。
真正的读取问题3: Sharding之后,查询时需要聚合多台服务器的结果,比如数据分布在三台机器上,第一台机命中了100个metrics,平均值是3;第二台命中了20个,平均值是2;第三台命中了10个,平均值是1。
首先决不能把三个平均值做平均。像MysqlCluster那种会做执行计划分析的,会只要求每台机上传sum 和 count 一共6条数据。但Graphite做不到这一点,只能让每台机把命中的metrics即130条数据都传上来。在0.9.12版中,如何批量上传数据还是个问题,在始终不肯发布的0.9.13 Snapshot版里此问题总算解决了。
但计算聚合时,再次遇到Python的单CPU核问题......
Graphite作者在宣布支持百万Metrics的时候,好像很少考虑这些问题。
要抛弃Graphite么?
现在,坚定一下继续留在Graphite的决心。能掀桌子把Graphite干掉吗? 一个选型的借鉴是Grafana作者合伙创业开的公司Raintank,它提供一个关于Metrics的SAAS平台,看the promising KairosDB 与influxdb: first impressions这两篇博客,也没太好的能下定决心的选择。
1. OpenTSDB
基于HBase,不支持RRD风格的数据精度递减,函数有限比如根本就没有Top N这种功能,运维复杂。
2. Kairosdb
基于Cassandra,8个月没更新了,似乎很不活跃。因为是从OpenTSDB fork出来的,所以不支持RRD与函数有限的问题依然在。
3. InfluxDB
用Go语言编写,是我最看好的一个alternative。但看好它快一年半了,还是没有成熟。最过份是,0.8版与还没发布的0.9版之间,居然几乎是重写。关于Cluster的文档也没写好让人不清楚底细。而且依然不支持RRD,只支持数据超过某个时间段就直接删除。
所以,近期还是留在Graphite吧,继续讨论优化吧。
可选的优化方法列表
两份有用的参考资料:
- http://www.iamsysadmin.ninja/2014/12/graphite-scaling-and-my-evaluation-of.html
- https://wikitech.wikimedia.org/wiki/Graphite/Scaling
还有一个增强信心的案例,Booking.com(携程网的山寨对象),经过改造的Graphite,支持90台Server,50TB数据的方案。
1. 使用SSD
因为要写入和读取大量不同的文件,用SSD无疑会快很多。
但SSD的价格贵,而且Booking.com的视频里也说。在频繁读写下,一块SSD盘的寿命也就一年半。
2. 使用pypy代替python
看官方数据speed.pypy.org,twisted_tcp中比CPython快3倍,一快解千愁,可缓解很多问题了。
Python把py文件编译成字节码(pyc文件),再交给PVM执行,就像Java的JVM一样。但PVM没有JIT,每次都要把字节码翻译成机器码再执行,而JVM可以把解释后机器码保存下来。pypy提供了JIT,让Ruby社区一片羡慕。
3. 接受现实,减少数据精度
比如最初的一天之内就不要10秒一条记录了,降到30秒或一分钟,大大减少relay,aggregate, 写入的压力和文件的大小。
4. 使用Carbon-Agggrator方案做预聚合
Aggregator能减少不必要的存储,预聚合某些维度,见前。
5. 处理Carbon-Aggrator/Carbon-Relay的单CPU瓶颈
方法1: 前面提到的pypy应该有帮助。
方法2: 如果瓶颈是在carbon-replay,Booking.com用C重写的carbon-c-relay (但暂时用链表存储所有要聚合的Metrics,Metrics数量多时也会搞爆CPU的问题,作者在改),或者这个用Go重写的carbon-relay-ng,都是很活跃很值得尝试的项目。
方法3: 如果不想有任何改变,那多开几个carbon-aggregator,每个aggreator只负责少量的规则,甚至sharding出几个aggreator来完成同一条规则(如果该规则允许分区的话),aggregator会为每个要在聚合后吐出来的Metrics建立一个任务,用LoopingCall不断调用,所以要吐出的Metrics数量进行拆分。部署结构越来越复杂了。。。
6. Sharding
Sharding能减少每个节点上要读写文件的数量,Graphite作者预订的方案。
7. 处理Graphite-Web聚合Sharding时的单CPU瓶颈
暂时无法解决。只能期待前面pypy的提升。
Booking.com提供全套用go重写的方案,carbonserver, carbonzipper,carbonapi一起连用,它们都是重新实现了Graphite各部件的功能,但改动好像太大了,暂不推荐。
8. 最后一招,后台预查询预cache数据
可能有些慢查询要30秒才出结果,那就预先在后台查询一次,cache在Graphite-Web说连接的Memcached里。不过这时就只支持一些固定的时间段,不能支持last 15 minutes这种相对时间了。
其他优化
1. 将Whisper存储换成其他backend方案
用Cassandra的graphite-cyanite,Vimeo的同学写的用Influxdb的graphite-influxdb, 但看起来都不成熟也没多少用户,不敢试。
2. 将Graphite-Web换成Graphite-Api
Graphite-Api与Graphite-Web相比,少了用户管理,数据库与PNG渲染,只保留最核心的Query功能,而且有自己的一套plugin架构,比如raintank就写了个Kairosdb的backend
小结
在InfluxDB真正超车之前,我们仍将尝试各种优化,继续实现我们不写一行代码,光靠配置获得一个不错的报表系统的愿望。
转自:http://calvin1978.blogcn.com/articles/graphite.html
ps:写得很棒
相关推荐
赠送jar包:metrics-graphite-3.1.5.jar; 赠送原API文档:metrics-graphite-3.1.5-javadoc.jar; 赠送源代码:metrics-graphite-3.1.5-sources.jar; 赠送Maven依赖信息文件:metrics-graphite-3.1.5.pom; 包含...
赠送jar包:metrics-graphite-3.1.5.jar; 赠送原API文档:metrics-graphite-3.1.5-javadoc.jar; 赠送源代码:metrics-graphite-3.1.5-sources.jar; 赠送Maven依赖信息文件:metrics-graphite-3.1.5.pom; 包含...
打包找不到 metrics-graphite COULD NOT FIND metrics-graphite-3.0.0-BETA3 解压后将jar包与pom文件都放在.m2\repository指定路径下
#storm-graphite-metrics Apache Storm 的度量消费者,它使用 Storm 的度量消费者接口将度量从 Storm 导出到石墨中。 ##Usage 在 Storm 配置中 conf . registerMetricsConsumer( GraphiteMetricsConsumer . class,...
本示例项目使用Dropwizard Metrics将JVM指标导出到Graphite。 Spring Boot自动配置com.codahale.metrics.MetricRegistry 。 有关更多详细信息,请参见Application.java代码注释。 需要启用UDP的Graphite服务器运行...
Metrics是一个java库,能够... Metrics提供了一组通用的模块库用于支持比如Guice,Jetty,Log4j,Apache HttpClient,EhCache,Logback,Spring等,也提供对比如Ganglia和Graphite等后端的报告。 标签:Metrics
docker-graphite, 在 Docker 图像中,Graphite + 碳 Graphite + 碳运行 Graphite 和碳缓存的all-in-one映像。 版本: 0.9.12.这里映像包含 Graphite 和碳缓存的默认默认配置。 启动这里容器将默认绑定下列主机端口:...
camel-spring-boot-metrics-example 从使用Apache Camel的Spring Boot应用程序向Graphite发送指标Spring Boot自动配置com.codahale.metrics.MetricRegistry 。 有关更多详细信息,请参见Application.java代码注释。 ...
graphite-api, Graphite的ruby API工具包 描述使用收费 GraphiteAPI,可以提供两种方式与 Graphite 守护进程交互,第一种方法是使用收费的GraphiteAPI::Client 守护进程,第二个方法实现 Graphite 纯文本协议,这两...
graphite-project.github.io, Graphite 项目的未来网站 Graphite安装bundle install 或者'gem 安装 scss_lint github页面"'npm install正在运行/开发运行Grunt任务并启动osm服务器grunt serve建筑grunt
docker-graphite-statsd, 用于 Graphite & Statsd的Docker 图像 用于 Graphite & Statsd的 Docker 映像立即运行 Graphite & StatsdGraphite & Statsd可能对安装程序很复杂。 这个映像将在几分钟内运行&
Monitoring with Graphite 英文epub 本资源转载自网络,如有侵权,请联系上传者或csdn删除 查看此书详细信息请在美国亚马逊官网搜索此书
Monitoring with Graphite 英文azw3 本资源转载自网络,如有侵权,请联系上传者或csdn删除 本资源转载自网络,如有侵权,请联系上传者或csdn删除
Graphite是计算机图形学,3D建模,数值几何的研究平台。可以用它处理obj文件,对齐进行渲染,修改等操作。
graphite-api-experiment, 实验 Graphite api服务器玩具项目不用于生产 石墨Golang中新一代 Graphite API服务器的实验版本,利用of并发构造的效率。目标是:速度,易于部署&优雅代码。此外,重写允许从根本上重新...
石墨度量标准:度量标准收集器,用于未由(其他)监视守护程序处理(或处理不当)的各种内容该项目的核心是一个简单的守护程序(harvestd),该守护程序收集度量值并将其每间隔一次发送到石墨碳守护程序(和/或其他...
20 亿指标,知乎 Graphite 极致优化
注:下文中的 *** 代表文件名中的组件名称。 # 包含: 中文-英文对照文档:【***-javadoc-API文档-中文(简体)-英语-对照版.zip】 jar包下载地址:【***.jar下载地址(官方地址+国内镜像地址).txt】 ...
下一个指标用于向Graphite发送指标的库,该库还为Next应用程序的标准部分(例如提供了检测工具。 :information: 此仓库是FT.com中最古老的仓库之一,因此未遵循我们当前的; 因为它是一个库,而不是一个应用程序,...
石墨victoriametrics-tldr Victoria Metrics 和 Graphite 的一些实验 Docker 与 Victoriametrics 安装组成,配置为接受 Graphite 指标,以及来自 Graphite-web 的 carbonapi 和静态 Web UI。