利用Packetbeat监控Cassandra和MongoDB

MongoDB与Cassandra的监控

由于Cassandra数据库经常存在不稳定与报警的情况，为了弄清楚其真实原因，在Cassandra中增加了一个监控，其技术栈为：

PacketBeat：一个第三方的网络抓包工具，其兼容了各大数据库的网络协议
ElasticSearch：ES数据库
Kibina：基于ES的一个可视化图形展示系统

原理为：利用PacketBeat监听网卡的数据包，进行解析之后将数据写入到ES数据库中，然后通过Kibina可视化的展示出来。

这样监控的好处是不影响数据库本身的性能，它是作为一个独立的监控存在，与数据库完全隔离开来，并且可以定制化的对数据库的各个维度进行分析。并且目前基于Cassandra和MongoDB的开源成熟监控工具并不多。

具体配置过程参照官网：https://www.elastic.co/guide/en/beats/packetbeat/current/packetbeat-getting-started.html

遇到的问题与解决

下面主要是具体实施过程中遇到的一些问题及解决方法。

问题一：没有数据

配置Packetbeat开始运行之后，发现数据没有写到ES中。
出现这样的问题的原因是，ES配置文件里面设置成不允许自动创建索引，导致数据写不进去。
因此这里需要动态修改ES集群的配置，命令如下：

PUT /_cluster/settings
{
  "persistent": {
    "action.auto_create_index":"true"
  }
}

修改之后再运行程序，会发现ES中终于有数据进来了。

问题二：莫名其妙的OOM

当终于看到数据后，会非常兴奋。可是用Packetbeat来抓Cassandra的数据包的时候，发现程序运行不到一分钟，packetbeat进程和cassandra进行都挂了。查看系统日志/var/log/message之后发现由于packetbeat程序占用了太大的内存，导致其它程序没有内存可以使用了，于是操作系统内核基于保护措施，把packetbeat进程给Kill掉了。而Cassandra进程是由于内存被它挤用了，内存不够导致Cassandra挂了。

但是奇怪的是，同样的配置，用Packetbeat来抓MongoDB包的时候，没有出现Out of Memory的错误。网上有一篇帖子说是由于滚雪球导致数据包指数级的增长，最终导致这个错误。

但是我这里仔细看了一下，Cassandra数据库与ES之间，不应该有滚雪球的抓包，于是我一个一个的过滤，最后终于发现是由于Cassandra协议中有一类op为RESULT的数据包导致其程序不断占用内存增大的，最终被Kill了。因此在配置文件packetbeat.yml中将这类包过滤掉，如下所示：

packetbeat.protocols:
- type: cassandra
  ports: [9042]
  ignored_ops: ["RESULT"]

问题三：Cassandra与MonogDB的不同

用PacketBeat监控Cassandra与MongoDB还有一些地方稍有不同：

Cassandra数据库是P2P完全对等的，因此该抓包程序需要在每一个部署有Cassandra的物理机器上均运行。
由于MongoDB的部署分为路由节点与数据节点，因此该抓包程序只需在部署有路由节点的物理机器上运行即可。

最终的效果

由于抓包得到的数据都存在ES里面，最终想怎么展示或者怎么分析，那就很随意了，可以定制化制作一些Dashboard什么的，下面是展示截图：

思考与感想

强烈安利ELK，即：Elasticsearch、Logstash、Kibana，这真的是非常成熟的集中式日志系统，非常方便。任何在线的实时的服务或者数据流，其所使用的技术系统是一整套，列举如下：

大数据分析的一整套：Spark、Hadoop、Hive、HBase、HDFS
大数据流式处理的一整套：Flink、Storm
大数据存储的一整套：Redis、MongoDB、Cassandra、Elasticsearch
消息中间件：Kafka
能力及服务的输出：Django、Gunicorn、Nginx

【版权声明】
本文首发于戚名钰的博客，欢迎转载，但是必须保留本文的署名戚名钰（包含链接）。如您有任何商业合作或者授权方面的协商，请给我留言：qimingyu.security@foxmail.com
欢迎关注我的微信公众号：科技锐新

本文永久链接：http://qimingyu.github.io/2018/05/30/利用Packetbeat监控Cassandra和MongoDB/