共计 3529 个字符，预计需要花费 9 分钟才能阅读完成。
写在开篇
不论 zabbix 的后端数据库是 oracle 还是 mysql，当 zabbix 监控的量级达到了肯定水平后，那么对数据库的性能是一个十分严厉的挑战。特地是对历史数据的查问，将会变得十分十分的慢，别通知我能够建索引优化，当量级达到肯定的水平的时候，索引真的没啥成果了。如果再不持续寻找适合的解决方案，那么就肯定会引发数据库层面的问题，最终导致服务不可用。当监控数据越来越大的时候，存储有余的时候，怎么办？那就删历史数据呗，但如果要求至多要保留半年甚至 1 年以上的历史数据，且又高端存储磁阵紧缺面临扩容难题的时候怎么办？而且又同时面临着单个历史表十分宏大的时候怎么办？分库、分表、分区？做读写拆散？不！一切都是浮云，还有一个更值得举荐的解决方案，那就是利用 Zabbix 自身对 ES 反对的机制来将历史数据存储到 ES 集群。目前，官网尽管示意 Zabbix 对 Elasticsearch 的反对仍处于试验阶段，但笔者认为还是值得一试，且在测试阶段未发现有啥不妥。“生产环境”上也革新了几套对接 ES 的架构，目前运行均一切正常，ES 可疾速横向扩大的能力是人尽皆知啊！谁用谁晓得。
上面笔者附上对接 ES 的官网文档链接：https://www.zabbix.com/docume…，且利用测试环境输入了本篇的“精髓”。心愿能够起到抛砖引玉的成果，欢送宽广盆友能够和笔者一起独特探讨。
架构图
笔者简略画了一下大略的架构图，如下：
环境搭建
因为 Oracle、ES、Kibana、Zabbix 不是本文的主题，因而这几个组件的装置过程笔者在本文就省略了哈。对于 Oracle 的装置，笔者在以前的文章中有所讲到，那么 ES、Kibana、Zabbix 的相干知识点笔者后续也会抽时间输入“精髓”，望宽广敌人们多多关注哦，非常感谢！
在 es 中创立索引
-
增加数字（无符号）类型的索引
curl -X PUT \ http://localhost:9200/uint \ -H 'content-type:application/json' \ -d '{"settings": {"index": {"number_of_replicas": 1,"number_of_shards": 5} }, "mappings": { "properties": { "itemid": {"type": "long"}, "clock": { "format": "epoch_second", "type": "date" }, "value": {"type": "long"} } } }' -
增加数字（浮点型）类型的索引
curl -X PUT \ http://localhost:9200/dbl \ -H 'content-type:application/json' \ -d '{"settings": {"index": {"number_of_replicas": 1,"number_of_shards": 5} }, "mappings": { "properties": { "itemid": {"type": "long"}, "clock": { "format": "epoch_second", "type": "date" }, "value": {"type": "double"} } } }' -
增加字符类型的索引
curl -X PUT \ http://localhost:9200/str \ -H 'content-type:application/json' \ -d '{"settings": {"index": {"number_of_replicas": 1,"number_of_shards": 5} }, "mappings": { "properties": { "itemid": {"type": "long"}, "clock": { "format": "epoch_second", "type": "date" }, "value": { "fields": { "analyzed": { "index": true, "type": "text", "analyzer": "standard" } }, "index": false, "type": "text" } } } }' -
增加日志类型的索引
curl -X PUT \ http://localhost:9200/log \ -H 'content-type:application/json' \ -d '{"settings": {"index": {"number_of_replicas": 1,"number_of_shards": 5} }, "mappings": { "properties": { "itemid": {"type": "long"}, "clock": { "format": "epoch_second", "type": "date" }, "value": { "fields": { "analyzed": { "index": true, "type": "text", "analyzer": "standard" } }, "index": false, "type": "text" } } } }' -
增加文本类型的索引
curl -X PUT \ http://localhost:9200/text \ -H 'content-type:application/json' \ -d '{"settings": {"index": {"number_of_replicas": 1,"number_of_shards": 5} }, "mappings": { "properties": { "itemid": {"type": "long"}, "clock": { "format": "epoch_second", "type": "date" }, "value": { "fields": { "analyzed": { "index": true, "type": "text", "analyzer": "standard" } }, "index": false, "type": "text" } } } }'
配置 Zabbix
1. zabbix server 对接 es
-
vi /opt/aspire/product/zabbixsvr5/etc/zabbix_server.conf
HistoryStorageURL=local.es.svr:9200 HistoryStorageTypes=uint,dbl,str,log,text
2. zabbix web 前端对接 es
-
vi /opt/aspire/product/nginx/html/conf/zabbix.conf.php
<?php // Zabbix GUI configuration file. global $DB, $HISTORY; $HISTORY['url'] = 'http://local.es.svr:9200'; $HISTORY['types'] = ['uint', 'text', 'log', 'str', 'dbl'];
3. 重启 zabbix server 和 php-fpm 即可
# 杀死和拉起 zabbix server
ps -aux | grep zabbix_server | grep -v grep | awk '{print $2}' | xargs kill -9
/opt/aspire/product/zabbixsvr5/sbin/zabbix_server -c /opt/aspire/product/zabbixsvr5/etc/zabbix_server.conf
# 杀死和拉起 php-fpm
pkill php-fpm
/opt/aspire/product/php7/sbin/php-fpm 对接实现后的验证
1. zabbix 查看最新上报的数据
上图可看出上报监控数据失常
2. 在 zabbix 数据库（oracle）中查问相干历史表是否有数据
笔者通过 plsql 登录了 oracle 19c 进行 select count 操作
通过上图可看到，history、history_log、history_str、history_text、history_uint 这 5 张表都没有数据写入了
3. 登录 kibana 查看
上图可看到，历史数据都写入到对应的索引了。
写在最初
此计划是 Zabbix 官网内置反对的机制，也是比拟举荐的解决方案，其实 Zabbix 从 4.2 版本就开始反对时序数据库 TimescaleDB 了，但目前时序数据库不反对 Zabbix proxy。如果后端的 Oracle 或 MySQL 换成 TimescaleDB，再联合 ES，是不是变得能够反对更大规模的监控？这是一个值得去测试的解决方案。笔者回头找工夫搭建一下，并做压测。好了！工夫无限，今晚就此搁笔，感激宽广盆友的关注，望多多点赞、珍藏、转发，谢谢！