linuxea:zabbix 4.2 使用Simple check监控VIP和端口 在实际使用中，通常我们会对一些端口进行监控，比如nginx，mariadb,php等。要完成一个端口监控是简单容易的。net.tcp.listen[80]如上，既可对tcp 80获取状态，而后配置Triggeres做告警处理即可{HOST.NAME} nginx is not running {nginx_80_port:net.tcp.listen[80].last()}<>1 Enabled但是，现在。我要说的并不是这个。在一个环境中一般来讲会有负载均衡和HA冗余，就不能避免的要使用VIP，顾名思义就是虚拟IP。通过操作虚拟IP的飘逸来完成故障后的IP上业务的切换。通常而言，每个VIP都会伴随一个端口。如: lvs,haproxy,nginx。阅读这篇文章，你将了解如何监控VIP:PORT。尤为提醒的是，通过某一台机器添加一次模板就可以对VIP和VIP端口进行检查。创建模板1，Configuration->Templates->Create template 输入名称即可。如：Template App Telnet VIP2，并且Create application ,如：Telnet VIP3，创建Itemstype: Simple check为什么是Simple check，而不是telent?相比较telnet与 Simple check，后者要比前者好用的多，在我看来，不需要写脚本，简单配置就能够完成我们需求。所以，我们这里仍然使用的是: net.tcp.service。推荐阅读官网的service_check_details与simple_checksKey: net.tcp.service[tcp,10.10.195.99,9200]意思为：获取10.10.10.195.99ip地址的tcp 9200端口状态在Applications中选择Telnet VIP除此之外，创建Triggers创建Triggers0 - 服务停止，1 - 服务正在运行 ，由此，我们的触发器就如下：{Template App Telnet VIP:net.tcp.service[tcp,10.10.195.99,9200].last(#3)}=0如果最新三次回去的值都是0就触发告警。如下图即可：到此，使用zabbix简单监控ip和端口已经完成。自动发现参考自动发现基于zabbix4.2 zabbix Discovery 教程延伸阅读service_check_detailssimple_checks阅读更多zabbix监控教程docker教程zabbix-complete-workslinuxea:Zabbix-complete-works之Zabbix基础安装配置linuxea:zabbix4.2新功能之TimescaleDB数据源测试

linuxea:zabbix4.2新功能之TimescaleDB数据源测试 Zabbix发布了4.2版本，带有一系列新功能。在Zabbix自己的网站上有一个很好的概述，但一定要检查文档中的“Zabbix 4.2中的新功能”部分，因为它更完整！一个新功能是TimescaleDB的实验支持。一个当前流行的开源时间序列的SQL数据库 ，TimescaleDB打包为PostgreSQL扩展。这套数据库由PostgreSQL构建，提供跨时间和空间的自动分区（分区键），同时保留标准的PostgreSQL接口以及完整的SQL支持。前言为什么要使用时间序列的SQL数据库？以及如何配置它，以及它是什么？首先是数据库分区，但要了解分区，我们需要考虑下zabbix server的历史数据。假设此时有5个历史数据和两个表，数据的时间设置在前段中进行配置，他可以是任何时间。然而现在，我们说的是zabbix的内部趋势数据的House keeping，而House keepingje是控制从数据库中删除过时的信息的。而一个任务去一个数据库内扫描所有的历史和趋势表以及更老的数据，在指定删除。但是这个过程中会变得缓慢，因为他将会扫描所有表格删除数据，在同时还有其他的内部调用流程，这样一来，数据删除的过程将会更慢，也无法删除更多的数据。现在我们讨论下如何进行分区，假设我们使用三个月的数据，按天分组多个分区，如：1，2，3，4，此时如我们只想保留最近一天的，就会删除1，2，3三张表分区，而不是扫描表 。这样一来，首先没有了性能的问题，第二就是更快了，并且释放了磁盘空间。而TimescaleDB就是时间序列的数据库，内部自动分区，TimescaleDB不是一个数据库引擎，而是一个积极SQL数据库的扩展。安装Zabbix官方docker有一个选项打开就可以支持TimescaleDB：# ENABLE_TIMESCALEDB=true 在4.2的版本中我在我的环境中实验了，一如既往，我会选择“Docker安装”（使用docker-compose）,docker官方也提供了现有的docker容器，阅读zabbix文档和GitHub的仓库。为此，我在此前的我自己的github上提供了TimescaleDB数据源的安装方式，参阅此docker-compose，但是目前，目前，Zabbix-proxy不支持TimescaleDB。参考我的: github上的https://github.com/marksugar/zabbix-complete-works快速部署curl -Lk https://raw.githubusercontent.com/marksugar/zabbix-complete-works/master/zabbix_server/zabbix-install/install_zabbix_timescaledb.sh|bashtimescaledb在timescaledb中挂在数据目录到本地 - /data/zabbix/postgresql/data:/var/lib/postgresql/data:rw传递两个环境变量设置用户和密码 environment: - POSTGRES_USER=zabbix - POSTGRES_PASSWORD=abc123version: '3.5' services: timescaledb: image: timescale/timescaledb:latest-pg11-oss container_name: timescaledb restart: always network_mode: "host" volumes: - /etc/localtime:/etc/localtime:ro - /data/zabbix/postgresql/data:/var/lib/postgresql/data:rw user: root stop_grace_period: 1m environment: - POSTGRES_USER=zabbix - POSTGRES_PASSWORD=abc123 logging: driver: "json-file" options: max-size: "1G"zabbix使用pgsql镜像zabbix/zabbix-server-pgsql:alpine-4.2-latest zabbix/zabbix-web-nginx-pgsql:alpine-4.2-latestzabbix-server-pgsql在zabbix-server-pgsql环境变量中修改数据库链接 environment: - ENABLE_TIMESCALEDB=true - DB_SERVER_HOST=127.0.0.1 - POSTGRES_DB=zabbix - POSTGRES_USER=zabbix - POSTGRES_PASSWORD=abc123 并且开启HOUSEKEEPINGFREQUENCY - ZBX_HOUSEKEEPINGFREQUENCY=1 - ZBX_MAXHOUSEKEEPERDELETE=100000zabbix-web-nginx-pgsql在zabbix-web-nginx-pgsql的环境变量中也需要修改 environment: - DB_SERVER_HOST=127.0.0.1 - POSTGRES_DB=zabbix - POSTGRES_USER=zabbix - POSTGRES_PASSWORD=abc123 - ZBX_SERVER_HOST=127.0.0.1配置完成后，在web界面中默认已经启用了在文档中的提到配置，为了对历史和趋势使用分区管理，必须启用这些选项。可以仅对趋势（通过设置“ 覆盖项目趋势期”）或仅对历史记录（“ 覆盖项目历史记录期间”）使用TimescaleDB分区。Override item history period Override item trend period可以通过如下方式查看，在Administration → General → Housekeeping查看勾选的Override item history period和Override item trend period现在zabbix在TimescaleDB上运行，这样数据库在查询和提取的时候是有一定的好处，如：zabbix的housekeeping，在TimescaleDB之前，使用许多DELETE查询删除数据，这肯定会损害整体性能。现在使用TimescaleDB的分块表，过时的数据将作为一个整体进行转储，而性能负担则更少。测试假如此刻历史数据保留为1天，那么在数据库中，其他的数据将会被删除类似这样存储几天的数据[root@LinuxEA ~]# docker exec -it timescaledb bash bash-4.4# psql -U zabbix psql (11.2) Type "help" for help.zabbix=# \d+ history Table "public.history" Column | Type | Collation | Nullable | Default | Storage | Stats target | Description --------+---------------+-----------+----------+---------+---------+--------------+------------- itemid | bigint | | not null | | plain | | clock | integer | | not null | 0 | plain | | value | numeric(16,4) | | not null | 0.0000 | main | | ns | integer | | not null | 0 | plain | | Indexes: "history_1" btree (itemid, clock) "history_clock_idx" btree (clock DESC) Triggers: ts_insert_blocker BEFORE INSERT ON history FOR EACH ROW EXECUTE PROCEDURE _timescaledb_internal.insert_blocker() Child tables: _timescaledb_internal._hyper_1_11_chunk, _timescaledb_internal._hyper_1_16_chunk, _timescaledb_internal._hyper_1_21_chunk, _timescaledb_internal._hyper_1_26_chunk, _timescaledb_internal._hyper_1_6_chunkzabbix=# \d+ trends Table "public.trends" Column | Type | Collation | Nullable | Default | Storage | Stats target | Description -----------+---------------+-----------+----------+---------+---------+--------------+------------- itemid | bigint | | not null | | plain | | clock | integer | | not null | 0 | plain | | num | integer | | not null | 0 | plain | | value_min | numeric(16,4) | | not null | 0.0000 | main | | value_avg | numeric(16,4) | | not null | 0.0000 | main | | value_max | numeric(16,4) | | not null | 0.0000 | main | | Indexes: "trends_pkey" PRIMARY KEY, btree (itemid, clock) "trends_clock_idx" btree (clock DESC) Triggers: ts_insert_blocker BEFORE INSERT ON trends FOR EACH ROW EXECUTE PROCEDURE _timescaledb_internal.insert_blocker() Child tables: _timescaledb_internal._hyper_6_14_chunk, _timescaledb_internal._hyper_6_19_chunk, _timescaledb_internal._hyper_6_24_chunk, _timescaledb_internal._hyper_6_29_chunk, _timescaledb_internal._hyper_6_9_chunk我们修改history和trends为1天后进行清理试试看，我们现在即将进行删除操作，timescaledb中的数据看似是三天的，其实只有两天的数据量，包含一个最早一天的和当前一天的，以保留一天为例开始清理[root@LinuxEA ~]# docker exec -it zabbix-server-pgsql bash bash-4.4# zabbix_server -R config_cache_reload zabbix_server [260]: command sent successfully bash-4.4# zabbix_server -R housekeeper_execute zabbix_server [261]: command sent successfully在回到timescaledbzabbix=# \d+ history Table "public.history" Column | Type | Collation | Nullable | Default | Storage | Stats target | Description --------+---------------+-----------+----------+---------+---------+--------------+------------- itemid | bigint | | not null | | plain | | clock | integer | | not null | 0 | plain | | value | numeric(16,4) | | not null | 0.0000 | main | | ns | integer | | not null | 0 | plain | | Indexes: "history_1" btree (itemid, clock) "history_clock_idx" btree (clock DESC) Triggers: ts_insert_blocker BEFORE INSERT ON history FOR EACH ROW EXECUTE PROCEDURE _timescaledb_internal.insert_blocker() Child tables: _timescaledb_internal._hyper_1_21_chunk, _timescaledb_internal._hyper_1_26_chunkzabbix=# \d+ trends Table "public.trends" Column | Type | Collation | Nullable | Default | Storage | Stats target | Description -----------+---------------+-----------+----------+---------+---------+--------------+------------- itemid | bigint | | not null | | plain | | clock | integer | | not null | 0 | plain | | num | integer | | not null | 0 | plain | | value_min | numeric(16,4) | | not null | 0.0000 | main | | value_avg | numeric(16,4) | | not null | 0.0000 | main | | value_max | numeric(16,4) | | not null | 0.0000 | main | | Indexes: "trends_pkey" PRIMARY KEY, btree (itemid, clock) "trends_clock_idx" btree (clock DESC) Triggers: ts_insert_blocker BEFORE INSERT ON trends FOR EACH ROW EXECUTE PROCEDURE _timescaledb_internal.insert_blocker() Child tables: _timescaledb_internal._hyper_6_24_chunk, _timescaledb_internal._hyper_6_29_chunk为了看的更明显，我们在web查看自动发现参考自动发现基于zabbix4.2-zabbix-Discovery教程延伸阅读zabbix TimescaleDB阅读更多zabbix监控教程docker教程zabbix-complete-workslinuxea:Zabbix-complete-works之Zabbix基础安装配置