应用zabbix的实时导出(real-time export)功能

zabbix,real,time,export · 浏览次数 : 0

小编点评

## zabbix History Data Export Comparison **Three methods for exporting historical data:** 1. **Real-time:** Exporting directly to a file with filebeat or other tools. 2. **Database:** Reading data directly from the database. 3. **File system:** Exporting data as files and storing them on the file system. **Comparison:** | Method | Real-time | Database | File system | |---|---|---|---| | Speed | Fastest | Slower | Moderate | | Security | Most secure | Potentially less secure | Moderate | | Exposure | Most exposed | Less exposed | Less exposed | | Configuration | Simple | Complex | Moderate | **Recommended method:** Use the **file system** method for exporting historical data. This approach offers a good balance between performance and security. **Steps to configure file system export:** 1. **Modify zabbix_server.conf:** - Set the `ExportDir` to the desired export directory. - Set the `ExportFileSize` to control the file size. - Set the `ExportType` to the desired data type (events, history, trends). 2. **Restart Zabbix server:** - This ensures the configuration changes take effect. 3. **Modify docker container environment variables:** - Set `ZBX_EXPORTFILESIZE` and `ZBX_EXPORTTYPE` to specify file size and data type. 4. **Create container data files:** - Run a `docker run` command with appropriate environment variables. 5. **Use filebeat to process data:** - Start the `filebeat` process and point its configuration to the container directory. **Additional points:** * Consider setting up cron jobs to automatically delete old files. * Ensure sufficient disk space is available to avoid write errors. * Monitor file size and delete old files to avoid storage issues.

正文

说明

zabbix作为监控软件,有时也会需要获取历史数据作进一步的分析,通常可以采用3种办法:

  1. 通过zabbix API定期获取(通过web)
  2. 通过后端数据库定期读取(通过db)
  3. 应用实时导出功能配合filebeat或其他工具获取(通过server)

对比以上三种方法:

  1. 实时性:毫无疑问,通过实时导出功能将数据发送出去是实时性最好的,周期性调用API或者读取数据库都存在一定的延时。
  2. 暴露面:通过API暴露数据是最合理的,因为web服务本身就是对外的;数据库一般情况下不应该对外暴露,甚至不需要公网地址;而server则需要分情况讨论,如果涉及外网proxy或者agent,则也需要有公网地址,而如果仅仅作内网的监控,则不需要具备公网地址。
  3. 安全性:通过实时导出主动发送数据是安全性最好的,因为不存在任何的入访机会;而使用API或者读取数据都必须要开放入访和提供密码或者token,需要通过做白名单、管控账号权限来保证安全性。

本文将介绍第三种方法,将历史数据导出为文件,以备其他工具处理。

配置

修改配置文件

如果zabbix部署方式为编译或者rpm,则修改zabbix_server.conf配置文件,注意3个字段的配置:

  1. ExportDir: 导出文件的目录,注意此目录一定要有写权限,会以history syncer进程的数量创建文件
  2. ExportFileSize: 限制导出文件的大小,默认是1G,如果文件超出,则以 .old 结尾重命名该文件,并创建一个和原名称相同的新文件
  3. ExportType: 导出数据的类型,包括events、history、trends,如果不设置,则默认为全部

示例如下:

ExportDir:/zabbix/history/
ExportFileSize:500M
ExportType:history,trends

配置完成后重启zabbix_server生效。

修改docker容器环境变量

如果zabbix部署方式为容器,则需要配置环境变量,相关的2个环境变量为:ZBX_EXPORTFILESIZEZBX_EXPORTTYPE,目录变量无法修改,因为固定位于容器内的/var/lib/zabbix/export/目录下
为对历史数据文件进行读取,需要做一个卷映射,将容器内的文件映射到宿主机上
示例如下:

……
-e ZBX_EXPORTFILESIZE="500M" -e ZBX_EXPORTTYPE="history" \
……
-v /zabbix/history:/var/lib/zabbix/export \

以此配置创建容器

数据文件处理

完成配置并启动后,会在设定的目录下(本例中为/zabbix/history/)生成名为history-history-syncer-*.ndjson(本例中只保存了history数据)的一批文件,数量对应history syncer进程,例如有10个进程,则会生成名为syncer-[1-10]的ndjson文件。
文件格式示例为:

{"host":{"host":"Host B","name":"Host B visible"},"groups":["Group X","Group Y","Group Z"],"item_tags":[{"tag":"Application","value":"system"}],"itemid":3,"name":"Agent availability","clock":1519304285,"ns":123456789,"value":1,"type":3}

可以通过filebeat之类工具进行数据的实时处理。

定时删除文件

如果监控项很多,数据的增长速度可能会比较快,本实验环境中监控项有17万,所有历史数据文件大小总和以7-10M/分钟的速度增长。如果硬盘空间没有预留足够,可能不出几天就会被写满。首先可以增加数据盘,以保留更久的数据,然而不管硬盘多大,时间久了总归还是会写满的,可以设置一个crontab的脚本,每隔一段时间去删除.old文件。
示例如下:

0 * * * * /bin/bash -c 'find /zabbix/history -type f -name "history-history-syncer-*.ndjson.old" -exec rm {} \;'

每小时进行一次检查,删除/zabbix/history目录下的history-history-syncer-*.ndjson.old文件。

与应用zabbix的实时导出(real-time export)功能相似的内容:

应用zabbix的实时导出(real-time export)功能

说明 zabbix作为监控软件,有时也会需要获取历史数据作进一步的分析,通常可以采用3种办法: 通过zabbix API定期获取(通过web) 通过后端数据库定期读取(通过db) 应用实时导出功能配合filebeat或其他工具获取(通过server) 对比以上三种方法: 实时性:毫无疑问,通过实时导

logging 模块因权限问题写入日志失败

哈喽大家好,我是咸鱼 今天跟大家分享一个使用 Python 的 logging 模块写入日志文件时遇到的权限问题,不知道你们有没有遇到过 ## 1.案例现象 今天上班的时候手机短信收到了 zabbix 告警,但是发现了不对劲的地方:微信没有收到告警信息,按理说短信跟微信应该是同时收到告警信息的 咸鱼

记一次RocketMQ消费非顺序消息引起的线上事故

应用场景 C端用户提交工单、工单创建完成之后、会发布一条工单创建完成的消息事件(异步消息)、MQ消费者收到消息之后、会通知各处理器处理该消息、各处理器处理完后都会发布一条将该工单写入搜索引擎的消息、最终该工单出现在搜索引擎、被工单处理人检索和处理。 事故异常体现 1、异常体现 从工单的流转记录发现、

Angular 集成 StreamSaver 大文件下载

应用场景: 实现目标: 在网页端实现大文件(文件大小 >= 2 G) 断点续传 实际方案: 发送多次请求, 每次请求一部分文件数据, 然后通过续写将文件数据全部写入. 难点: 无法实现文件续写, 最后采用 StreamSaver 来解决这个问题. 1. 首先从 git hub 将 StreamSav

virtualapp 应用启动源码分析

应用启动源码分析 在HomeActvity中的OnCreate方法会调用initLaunchpad private void initLaunchpad() { mLauncherView.setHasFixedSize(true); StaggeredGridLayoutManager layou

栈的应用(后进先出 LIFO)--括号匹配问题

博客地址:https://www.cnblogs.com/zylyehuo/ # -*- coding: utf-8 -*- class Stack: def __init__(self): self.stack = [] def push(self, element): self.stack.ap

轻应用技术是什么?如何进行落地

移动互联网风起云涌的数十年来,App 似乎成为了企业与用户打交道最“理所当然”的形式,更年轻一代的用户甚至可能认为 App 就是一个“与生俱来”的事物,但随着移动互联网发展的高峰离去,App 面临着发展的困境和疲态。最明显的感知就是这几年以微信、支付宝、抖音等“超级 App”们大行其道,占据了用户超过80%的手机使用时间,而其他大多数 App 则成为了用户手机的内存侵夺者。

应用部署初探:3个主要阶段、4种常见模式

应用部署是一个将软件提供给用户的过程,通常包含配置环境、安装及测试等步骤。现如今,大部分企业在部署新的应用程序时,会至少自动化其中一些步骤。应用程序部署的策略会影响该应用的性能、稳定性以及运行速度,因此有时会在向所有人提供更新之前,先对一小部分用户进行测试。 软件开发和用户体验的现代标准要求开发人员

应用部署初探:微服务的3大部署模式

在之前的文章中,我们已经充分了解了应用部署的4种常见模式(金丝雀部署、蓝绿部署、滚动部署及影子部署)。随着云原生技术逐步成熟,企业追求更为灵活和可扩展的系统,微服务架构大行其道。 微服务固然有诸多优点,但也给架构及运维工程师带来了新的挑战。在单体架构中,应用的设计、部署以及扩展都是作为一个单元进行,

应用部署初探:6个保障安全的最佳实践

在之前的文章中,我们了解了应用部署的阶段以及常见的部署模式,包括微服务架构的应用应该如何部署等基本内容。本篇文章将介绍如何安全地部署应用程序。 安全是软件开发生命周期(SDLC)中的关键部分,同时也需要成为 SDLC 中每个环节的一部分,尤其是部署。因此,保障应用部署安全并不是开始于部署阶段,而是从