cassandra 监控方案评估
摘要
最开始做cassandra monitor 方案的选型时,主要是从cassandra 本身入手,后来发现cassandra运行在JVM上,所有的metrics都是通过JMX 暴露出来。所以又可以使用一些通用的Java Application 的监控方案,作者在调查了很多的实现方案后,最终将范围缩小在graphite,newrelic,opscenter三种解决方案。本文只给出各自的优劣势,具体选用哪种,相信读者自有判断。
想了解更多cassandra 知识请访问 http://www.webpersonaldeveloper.cn
opscenter VS graphite VS newrelic
环境部署
opscenter:
从datastax 下载opscenter,install完了以后,就可以在opscenter 的UI 上面安装cassandra cluster,然后在cluster 上面安装opscenter agent.cassandra 和agent可以在opscenter 的UI上面安装,也可以在各个Node上面安装
graphite:
主要有三部分构成graphite 绘图,Carbon作为缓存,Whisper存储数据。此外通常需要使用grafana 来作为UI显示,因为graphite绘图太丑了,功能也有限。graphite 环境搭建及配置及其复杂,需要安装很多的插件,所以版本适配也很麻烦。不过有了docker以后一切变得简单了。
https://github.com/kamon-io/docker-grafana-graphite
(可以fork这个repo然后按照你的需求更改)
部署好graphite server,还需要在每个cassandra 配置发送
新建一个metrics.yaml
graphite:
period: 30
timeunit: 'SECONDS'
prefix: 'cassandra-cluster-prefix.node1'
hosts:
- host: 'xxx'
port: 2003
predicate:
color: "white"
useQualifiedName: true
patterns:
- "^org.+"
- "^jvm.+"
- "^java.lang.+"
然后在cassandra-env.sh 配置JVM启动项
JVM_OPTS="$JVM_OPTS -Dcassandra.metricsReporterConfigFile=metrics.yaml"
newrelic:
只用配置下newrelic 的config,然后run plugin
https://github.com/threelegs/newrelic-plugins
warning
newrelic cassandra 的plugin很多年没有更新了,所以应该支持Cassandra 2.x版本,不支持Cassandra 3.x的版本。
不过自己开发也很简单,只是有些metrics 名字,包名换了,可以自己fork下来进行修改。
opscenter=newrelic>graphite(即使使用docker,graphite还是部署最复杂的一个)
收集的metrics对比
cassandra metrics
cassandra metrics 主要就是JMX 暴露出来的MBean,包括Read/Write request,latency.还有一些是compaction task等信息。我们通过JConsole 工具就能够查看,不过是JConsole 界面过于丑陋,以及无法保存历史数据,绘制图形也不美观等种种缺点导致我们不去使用它。
opscenter=graphite=newrelic cassandra metrics 三种收集方案都可以收集到,没什么差异。
os metrics
OS metrics 包括cpu,内存,disk使用情况。
opscenter集成在一起,看起来很方便;graphite需要使用第三方插件collectd进行收集;newrelic 同样也可以。
opscenter=newrelic>graphite
application metrics
cassandra 是数据库服务,但是作为monitor,通常需要查看整体情况。client请求出现问题了,我们可能不仅需要分析数据库,还需要分析application server.当然希望能够将application server 的信息与cassandra整合到同一页面而不是多个监控平台。opscenter 没法做到,graphite 可以,newrelic 可以
graphite=newrelic>opscenter
扩展功能
历史数据保存
opscenter、graphite 都是支持参数配置保存多少天的。
newrelic 需要钱才可以保存更多天。
权限管理
opscenter支持admin对权限进行管理,但是所有的metrics作为一个整体,无法控制让某些用户只看某部分metrics
https://docs.datastax.com/en/latest-opsc/opsc/configure/opscManageUsers.html
graphite 支持organization,不同的organization可以有不同的dashboard.organization中可以添加user,user 角色有四种admin,editor,read only editor,view. 不同的用户在不同的organization中可以有不同的角色。
newrelic 支持admin,user,restricted user三种,不同的用户可以看到不同的内容。
开发维护成本
opscenter 不需要开发,维护如果使用datastax 商业版的cassandra,交license费用即可。其他就是opscenter server的费用
graphite开源,但是环境部署需要时间和金钱,另外,graphite 有很多的插件构成整个monitor服务,这些插件的维护需要成本。在作者搭建过程就遇到很多的问题。比如多个server的数据聚合问题,读取数据不正确。这些都是需要运营投入到更多的时间的。要是系统不稳定,多投入一个运营,对于公司来说也是一笔不小的投入。
newrelic 有免费版,但是功能受限,像上面提到的历史数据保存,只能保存一天。收费版就不便宜了。但是newrelic有个独有的好处,是SaaS服务。当需要监控的数据规模增多的时候,不用自己构建监控集群。在这点上,opscenter,graphite 则需要构建cluster 环境
金钱上 graphite>opscenter>newrelic
人力上 newrelic>opscenter>graphite
cassandra 版本限制
opscenter最新版本只支持cassandra opensource 2.1,datastax enterprise 4.8,截止目前,cassandra opensource 已经release 3.7了。所以opscenter 版本比较滞后。graphite 是通用版本,可支持最新版本。
newrelic 是plugin形式,需要根据cassandra 更新的metrics来更新plugin 发送的metrics。
graphite=newrelic>opscenter
总结
无论从监控的metrics收集还是监控工具本身的管理来说,三种方案都能提供对应的解决方案。在其他方面略有差异
1.opscenter 很容易部署,另外集成了对cassandra 的常用操作。无需再登录到cassandra server 上,使用命令行来操作了。他本身不仅仅是个monitor工具,还是个cassandra的操作UI界面。opscenter 有个致命的缺点,cassandra版本受限,如果你想使用最新的cassandra无法实现,这点上觉得是致命的缺陷,是因为一个辅助的监控工具,而影响到主要的数据库功能。
2.graphite
开源是graphite的优势,社区活跃是支撑。有人力能够投入尽管选用此方案。
3.newrelic 没有什么技术问题需要去解决,花钱解放生产力,如果监控的内容不是产品的核心,也未尝不是一种好方案
以上仅作者意见,只作参考
参考
http://blog.ailms.me/2014/08/17/note-about-graphite-arch.html
http://docs.grafana.org/troubleshooting/
cassandra 监控方案评估的更多相关文章
- 【译】Kubernetes监控实践(2):可行监控方案之Prometheus和Sensu
本文介绍两个可行的K8s监控方案:Prometheus和Sensu.两个方案都能全面提供系统级的监控数据,帮助开发人员跟踪K8s关键组件的性能.定位故障.接收预警. 拓展阅读:Kubernetes监控 ...
- 移动端性能监控方案Hertz
移动端性能监控方案Hertz 吴凯 瑞利 富强 徐宏 ·2016-12-19 16:10 性能问题是造成App用户流失的罪魁祸首之一.App的性能问题包括崩溃.网络请求错误或超时.响应速度慢.列表滚动 ...
- 字节跳动 iOS Heimdallr 卡死卡顿监控方案与优化之路
点这里申请 本文主要介绍Heimdallr对卡死.卡顿异常的监控原理,并结合长时间的业务沉淀发现的问题进行不断迭代和优化,逐步实现全面.稳定.可靠的历程. 作者:字节跳动终端技术--白昆仑 前言 卡死 ...
- Kubernetes 集群和应用监控方案的设计与实践
目录 Kubernetes 监控 监控对象 Prometheus 指标 实践 节点监控 部署 Prometheus 部署 Kube State Metrics 部署 Grafana 应用如何接入 Pr ...
- 前端性能监控方案window.performance 调研(转)
1. 业界案例 目前前端性能监控系统大致为分两类:以GA为代表的代码监控和以webpagetest为代表的工具监控. 代码监控依托于js代码并部署到需监控的页面,手动计算时间差或者使用浏览器的的API ...
- OpenStack 虚拟机监控方案确定
Contents [hide] 1 监控方案调研过程 1.1 1. 虚拟机里内置监控模块 1.2 2. 通过libvirt获取虚拟机数据监控. 2 a.测试openstack的自待组件ceilomet ...
- Redis监控方案
Redis 监控最直接的方法当然就是使用系统提供的 info 命令来做了,你只需要执行下面一条命令,就能获得 Redis 系统的状态报告. redis-cli info 内存使用 如果 Redis 使 ...
- 斌哥的 Docker 进阶指南—监控方案的实现
过去的一年中,关于 Docker 的话题从未断过,而如今,从尝试 Docker 到最终决定使用 Docker 的转化率依然在逐步升高,关于 Docker 的讨论更是有增无减.另一方面,大家的注意力也渐 ...
- 一张表搞懂各种 Docker 监控方案 - 每天5分钟玩转 Docker 容器技术(86)
前面我们已经介绍了ps/top/stats.Sysdig.Weave Scope.cAdvisor 和 Prometheus 多种容器监控工具和方案,是时候做一个比较了.下面将从五个方面来对比它们之间 ...
随机推荐
- HTTP你真的懂了吗?
最近面试踩了些坑,自己看书看过的内容,即使能记得差不多,回答起来就是很混乱(绝望脸).比如HTTP的这几个问题,现在整理一下,一个点一个点的说! 1. 聊一聊你理解的HTTP 1) Http ...
- pymysql实现从a表过滤出有效信息添加至b表
# Author: yeshengbao # -- coding: utf-8 -- # @Time : 2018/4/16 19:23 import pymysql # 创建连接 conn = py ...
- php代码审计之变量覆盖
变量覆盖一般由这四个函数引起 <?php $b=3; $a = array('b' => '1' ); extract($a,EXTR_OVERWRITE); print_r($b); / ...
- [NOI2016]循环之美
Description 牛牛是一个热爱算法设计的高中生.在他设计的算法中,常常会使用带小数的数进行计算.牛牛认为,如果在 k 进制下,一个数的小数部分是纯循环的,那么它就是美的.现在,牛牛想知道:对 ...
- Evensgn 的债务
问题 A: Evensgn 的债务 大致题意:a欠b5元,b欠c5元,那么最小债务总额为a欠c5元,给你关系,求最小债务总额! 不想说话...一句超级大水题,我居然没读懂!!差点想到网络流了...其实 ...
- codeforces Gym - 100633J Ceizenpok’s formula
拓展Lucas #include<cstdio> #include<cstdlib> #include<algorithm> #include<cstring ...
- hdu 5011(博弈)
题意:在许多堆石子中,两人轮流取,1.在一堆中取至少一个 2.将这一堆分成两堆 思路:NIM游戏,所有值的异或,当其为0时失败 nim游戏: 假设只有两堆,游戏人取得胜利并不在于N1和N2的值具体是 ...
- hdu 1542 线段树扫描(面积)
Atlantis Time Limit: 2000/1000 MS (Java/Others) Memory Limit: 65536/32768 K (Java/Others)Total Su ...
- 几种常用hash算法及原理
计算理论中,没有Hash函数的说法,只有单向函数的说法.所谓的单向函数,是一个复杂的定义,大家可以去看计算理论或者密码学方面的数据.用“人 类”的语言描述单向函数就是:如果某个函数在给定输入的时候,很 ...
- Java连接FTP成功,但是上传是失败,报错:Connected time out
Java代码在本机上传文件到FTP服务器的时候成功,但是部署到测试服务器的时候出现,连接FTP成功但是上传失败,并且报Connected time out错误: 测试服务器和FTP服务都在阿里云上:( ...