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基础安装配置

linuxea:Zabbix-complete-works之Zabbix基础安装配置 我花了一点时间整理了一套zabbix的安装脚本，便于部署和安装。它包括了zabbix-server,zabbix-agent的安装，初始化配置，在4.0之后加入了docker-compose，随后的server端都采用了docker安装。在最新的更新中，引入了elasticsearch:6.1.4。git地址：https://github.com/marksugar/zabbix-complete-works如果你喜欢这个项目，你可以在github上的zabbix-complete-works右上角点击 ♥ Star或者Fork.我使用了一套docker-compose来编排server端，对于zabbix-agent我使用脚本安装。docker和docker-compose安装参考-docker官网的安装方式 And - docker-compose安装参考docker-compose官网的安装方式先睹为快在zabbix最近的几个版本中的Graph绘图功能我非常讨喜，大致是这样的这样以来，我就可以在 一张图里面看到自定义一个组，或者一部分机器和某个items组成的一张图，这是非常有效的zabbix-server使用最新的4.2稳定版本，引入了elasticsearch，但是对于elasticsearch功能处于开发阶段，支持的版本有限，我这里使用的是6.1.4。我在此主要介绍zabbix的参数，因为这里使用的是docker，如果你要快速了解和安装，那么很有必要了解的。参考zabbix-complete-works项目的docker-compose.yaml文件zabbix/zabbix-server-mysql:alpine-4.2-latest根据以往的使用方式，将数据保存在本地 volumes: - /etc/localtime:/etc/localtime:ro - /etc/timezone:/etc/timezone:ro - /data/zabbix/zbx_env/usr/lib/zabbix/alertscripts:/usr/lib/zabbix/alertscripts:ro - /data/zabbix/zbx_env/usr/lib/zabbix/externalscripts:/usr/lib/zabbix/externalscripts:ro - /data/zabbix/zbx_env/var/lib/zabbix/modules:/var/lib/zabbix/modules:ro - /data/zabbix/zbx_env/var/lib/zabbix/enc:/var/lib/zabbix/enc:ro - /data/zabbix/zbx_env/var/lib/zabbix/ssh_keys:/var/lib/zabbix/ssh_keys:ro - /data/zabbix/zbx_env/var/lib/zabbix/mibs:/var/lib/zabbix/mibs:ro - /data/zabbix/zbx_env/var/lib/zabbix/snmptraps:/var/lib/zabbix/snmptraps:rw环境变量 environment: - DB_SERVER_HOST=127.0.0.1 - MYSQL_DATABASE=zabbix - MYSQL_USER=zabbix - MYSQL_PASSWORD=password - MYSQL_ROOT_PASSWORD=abc123 - ZBX_HISTORYSTORAGEURL=http://127.0.0.1:9200 # elasticsearch - ZBX_HISTORYSTORAGETYPES=dbl,uint,str,log,text # stor add elasticsearch type - DebugLevel=5 - HistoryStorageDateIndex=1 - ZBX_STARTDISCOVERERS=10这里的环境变量对应zabbix-server.conf的配置参数，只不过在前面加上了ZBX_而已注意1，这里提供了MYSQL_ROOT_PASSWORD是数据库root的密码。但这里提供了root密码后，zabbix-server会自动创建用户以及导入sql，请观察日志查看是否有报错产生。2，这里使用了elasticsearch，根据官网的文档，在server配置后，还需要修改web断的配置文件 - ZBX_HISTORYSTORAGEURL=http://127.0.0.1:9200 # elasticsearch - ZBX_HISTORYSTORAGETYPES=dbl,uint,str,log,textzabbix/zabbix-web-nginx-mysql:alpine-4.2-latest环境变量 environment: - DB_SERVER_HOST=127.0.0.1 - MYSQL_DATABASE=zabbix - MYSQL_USER=zabbix - MYSQL_PASSWORD=password - ZBX_SERVER_HOST=127.0.0.1 - ZBX_HISTORYSTORAGEURL=http://127.0.0.1:9200 - ZBX_HISTORYSTORAGETYPES=['dbl','uint','str', 'text', 'log'] # uint,dbl,str,log,text其中，提供在Zabbix-server环境变量中的密码，也就是web链接数据库的密码。而关于elasticsearch的配置需要和server相匹配。最终这里的变量会被替换到容器中的配置文件中。 - ZBX_HISTORYSTORAGEURL=http://127.0.0.1:9200 - ZBX_HISTORYSTORAGETYPES=['dbl','uint','str', 'text', 'log']快速安装mkdir /data/zabbix -p curl -Lk https://raw.githubusercontent.com/marksugar/zabbix-complete-works/master/zabbix_server/graphfont.TTF -o /data/zabbix/graphfont.ttf wget https://raw.githubusercontent.com/marksugar/zabbix-complete-works/master/zabbix_server/docker_zabbix_server/docker-compose.yaml docker-compose -f docker-compose.yaml up -d> elasticsearch你需要注意权限问题，如本示例docker-compose中需要授权: chown -R 1000.1000 /data/elasticsearch/我整理了索引文件，执行创建索引即可(创建索引尤为重要),你也可以参考官网文档正常情况下你将看到如下信息：$ curl http://127.0.0.1:9200/_cat/indices?v health status index uuid pri rep docs.count docs.deleted store.size pri.store.size yellow open str MQWM2bNNRzOvBywM7ne-lw 5 1 0 0 1.1kb 1.1kb yellow open .monitoring-es-6-2019.04.20 tIfs0MkNQUCI4YuEHRmQ6g 1 1 1926 208 901.6kb 901.6kb yellow open dbl Y0992hqaR8KTin9iXKsljQ 5 1 0 0 1.1kb 1.1kb yellow open text s2XMyJtdQQ27b9rS3nWVfg 5 1 0 0 1.1kb 1.1kb yellow open log MAysNczpSKGZbjfjJXBvTg 5 1 0 0 1.1kb 1.1kb yellow open uint JA_8kyXlSLqawyHzo28Ggw 5 1 0 0 1.1kb 1.1kbzabbix-agent快速部署curl -Lk https://raw.githubusercontent.com/marksugar/zabbix-complete-works/master/zabbix_agent/install-agentd.sh|bash -s local IPADDR 在zabbix-agent的附加脚本中监控的默认项体现如下：/root/.ssh/authorized_keys/etc/passwd/etc/zabbix/zabbix_agentd.confOOMiptables磁盘iotcpnginx和php-fpmmariadb-galera其中配置文件和脚本被打包在一个[zabbix_agent_status.tar.gz包中自动发现参考自动发现基于zabbix4.2 zabbix Discovery 教程阅读更多zabbix监控教程docker教程zabbix-complete-workslinuxea:zabbix4.2新功能之TimescaleDB数据源测试

linuxea:prometheus基于主机的自动发现(promcr) prometheus自动发现(scrape them)在官网中方式有很多，我这里介绍的是使用consul_sd_config配合registrator来做，registrator作为node节点端，发现容器，且将发现信息注册给consul。拓扑如下：而prometheus中使用consul_sd_config进行重新标记，可以使用的元标签如下：__meta_consul_address：目标的地址__meta_consul_dc：目标的数据中心名称__meta_consul_metadata_<key>：目标的每个节点元数据键值__meta_consul_node：为目标定义的节点名称__meta_consul_service_address：目标的服务地址__meta_consul_service_id：目标的服务ID__meta_consul_service_metadata_<key>：目标的每个服务元数据键值__meta_consul_service_port：目标的服务端口__meta_consul_service：目标所属服务的名称__meta_consul_tags：由标记分隔符连接的目标的标记列表其中目标的IP编号和端口组装为 <__meta_consul_address>:<__meta_consul_service_port>。但是，在一些Consul设置中，相关地址在__meta_consul_service_address。在这些情况下，可以使用relabel 功能替换特殊__address__标签。pcr为了方便使用，我在git创建了一个pcr项目，地址如下https://github.com/marksugar/pcr在此简单说明如何进行基于主机做自动发现，具体可见github说明registratorregistrator运行在每一个node节点，要注册给consul必须是有独立的IP地址，这个ip可能必须是宿主机的ip地址。我们要做的事就是获取每个宿主机的ip地址，并且自动获取。为此，重新封装gliderlabs/registrator:v7容器是很有必要的。添加脚本获取#!/bin/sh # maintainer="linuxea.com" NDIP=`ip a s ${NETWORK_DEVIDE:-eth0}|awk '/inet/{print $2}'|sed -r 's/\/[0-9]{1,}//')` exec /bin/registrator -ip="${NDIP}" ${ND_CMD:--internal=false} consul://${NDIPSERVER_IP:-consul}:8500需要传递几个变量才能使用这个镜象NETWORK_DEVIDE: 网卡名称 NDIPSERVER_IP：consul server ip ND_CMD: 参数Example： environment: - REGISTRATOR_BIND_INTERFACE=eth0 - NETWORK_DEVIDE=eth0 - NDIPSERVER_IP=172.25.250.249 - ND_CMD=-internal=false而在模板中，这里的参数是这样的：- ND_CMD=-internal=false -retry-interval=30 -resync=180-retry-interval=30会在三分钟后自动重新联系CONSUL_SERVERcompose registrator: container_name: registrator image: marksugar/registrator:v7.1 network_mode: "host" depends_on: - consul - cadvisor - node_exporter - alertmanager - grafana - prometheus volumes: - /var/run/docker.sock:/tmp/docker.sock environment: - REGISTRATOR_BIND_INTERFACE=eth0 - NETWORK_DEVIDE=eth0 - NDIPSERVER_IP=172.25.250.249 - ND_CMD=-internal=false -retry-interval=30 -resync=360 cpu_shares: 14 mem_limit: 50m logging: driver: "json-file" options: max-size: "200M" labels: SERVICE_TAGS: prometheusconsulconsul可以是一个集群，也可以说单点，这里已单点的方式运行其中，需要注意绑定的网卡端口-bind '{{ GetInterfaceIP \"eth0\" }}'如果你不是eth0，请修改，如下： consul: container_name: consul image: consul:1.4.0 network_mode: "host" ports: - 8500:8500 command: "agent -server -ui -client=0.0.0.0 -dev -node=node0 -bind '{{ GetInterfaceIP \"eth0\" }}' -bootstrap-expect=1 -data-dir=/consul/data" labels: SERVICE_IGNORE: 'true' environment: - CONSUL_CLIENT_INTERFACE=eth0 cpu_shares: 30 mem_limit: 1024m logging: driver: "json-file" options: max-size: "200M" volumes: - ./consul/config:/consul/config - ./consul/data:/consul/data labels: SERVICE_TAGS: prometheus注册的机器都会在web接口中显示，大致像这样系统与容器在prom/node-exporter:v0.16.0中，选择prom/node-exporter:v0.16.0是有原因的，prom/node-exporter:v0.16.0是可以发现出磁盘，而在prom/node-exporter:v0.17.0经测试，是发现不了的cadvisor启动的端口是18880，这个端口不太会被占用 node_exporter: image: prom/node-exporter:v0.16.0 container_name: node_exporter user: root privileged: true network_mode: "host" volumes: - /proc:/host/proc:ro - /sys:/host/sys:ro - /:/rootfs:ro command: - '--path.procfs=/host/proc' - '--path.sysfs=/host/sys' - '--collector.filesystem.ignored-mount-points=^/(sys|proc|dev|host|etc)($$|/)' restart: unless-stopped ports: - 9100:9100 cpu_shares: 14 mem_limit: 50m logging: driver: "json-file" options: max-size: "200M" labels: - "SERVICE_TAGS=prometheus" cadvisor: image: google/cadvisor:v0.32.0 container_name: cadvisor network_mode: "host" volumes: - /:/rootfs:ro - /var/run:/var/run:rw - /sys:/sys:ro - /var/lib/docker/:/var/lib/docker:ro command: --listen_ip="0.0.0.0" --port=18880 restart: unless-stopped ports: - 18880:18880 cpu_shares: 14 mem_limit: 50m logging: driver: "json-file" options: max-size: "200M" labels: SERVICE_TAGS: prometheusprometheus在prometheus中，我修改了保存的时间，并且配置文件也做了调整 - '--config.file=/etc/prometheus/prometheus.yml' - '--storage.tsdb.path=/prometheus' - '--storage.tsdb.retention=45d' - '--web.console.libraries=/etc/prometheus/console_libraries' - '--web.console.templates=/etc/prometheus/consoles' - '--web.enable-lifecycle'其中，对于每个容器类型，做了区分，如：cadvisor，如下 - job_name: 'cadvisor' metrics_path: /metrics scheme: http consul_sd_configs: - server: 127.0.0.1:8500 services: ['cadvisor'] relabel_configs: - source_labels: ['__meta_consul_service'] regex: '(.*)' target_label: 'job' replacement: '$1' - source_labels: [__meta_consul_tags] target_label: tags - source_labels: ['__meta_consul_service_address'] regex: '(.*)' target_label: 'instance' replacement: '$1' - source_labels: ['__meta_consul_service_address', '__meta_consul_service_port'] regex: '(.*);(.*)' target_label: '__address__' replacement: '$1:$2' - source_labels: ['__meta_consul_tags'] regex: ',(prometheus|app),' target_label: 'group' replacement: '$1'自动发现字段 relabel_configs: - source_labels: ['__meta_consul_service'] regex: '(.*)' target_label: 'job' replacement: '$1' - source_labels: [__meta_consul_tags] target_label: tags - source_labels: ['__meta_consul_service_address'] regex: '(.*)' target_label: 'instance' replacement: '$1' - source_labels: ['__meta_consul_service_address', '__meta_consul_service_port'] regex: '(.*);(.*)' target_label: '__address__' replacement: '$1:$2'其中：__meta_consul_service发现的地址会重写成job__meta_consul_tags的值重写为tags__meta_consul_service_address获取的ip重写为instance__meta_consul_service_address', '__meta_consul_service_port'分别是ip和端口$1和$2分别对应第一个参数和第二个参数。分组但是这还不够，当发现后，这些信息必须有一个标签来做区分，否则我们是不能够用来灵活使用的，我们需要一个标签，如下所示 - source_labels: ['__meta_consul_tags'] regex: ',(prometheus|app),' target_label: 'group' replacement: '$1'如果__meta_consul_tags中包含prometheus字段或者app字段，就重新成一个组，就是上面所示的意思这也说明了为什么在每个容器后都会打上一个标签的原因 labels: SERVICE_TAGS: prometheus我们可以利用这个标签对项目做分组，灵活的划分grafana有了这个标签之后，我们可以对不同的标签进行划分。如下在项目组中，是有多个组，在每个组下，有多台机器，这里使用ip划分。但是，这样还是不够，有一些容器，没有在k8s中，他在宿主机上运行，那么这个模板就不能完美使用，重新编辑后的，就成了这样子。根据项目，和项目中的容器类型，根据容器来看对应容器下的主机情况。在github中还有其他的模板以供参考。对于如何来分组这个问题，我们首先要有一个标签，或者不同的表情，根据标签来分大组，如类型，项目，web等，而后根据每个标签，或者ip，或者容器名称组合一个序列来看项目地址：https://github.com/marksugar/pcr，这个工具我在使用，逐步更新维护，如果对你有帮助，请移步后顺手点个星星。延伸阅读：https://prometheus.io/docs/prometheus/latest/configuration/configuration/#relabel_config延伸阅读：https://prometheus.io/blog/2015/06/01/advanced-service-discovery/

linuxea:zabbix4.0通过slack发送警报 此前做了Telegram的警报发送，发现误报较多，尝试使用slack的方式，发现简洁明了，颇为好用。代码来自github，可参阅本章。此前的Telegram和slack都没有做警报收敛，在github之上有现成的警报收敛，感兴趣可以看看。zabbix配置下载slack.sh脚本，存放在/usr/lib/zabbix/alertscripts下[root@DT_Node-172_25_250_249 ~]# curl -Lk https://raw.githubusercontent.com/ericoc/zabbix-slack-alertscript/master/slack.sh -o /usr/lib/zabbix/alertscripts/slack.sh [root@DT_Node-172_25_250_249 /usr/lib/zabbix/alertscripts]# ll total 52 -rw-r--r-- 1 root root 1580 Oct 25 10:10 slack.sh打开配置AlertScriptsPath=/usr/lib/zabbix/alertscripts[root@DT_Node-172_25_250_249 /usr/lib/zabbix/alertscripts]# grep AlertScriptsPath /etc/zabbix/zabbix_server.conf ### Option: AlertScriptsPath # AlertScriptsPath=${datadir}/zabbix/alertscripts AlertScriptsPath=/usr/lib/zabbix/alertscripts [root@DT_Node-172_25_250_249 /usr/lib/zabbix/alertscripts]# slack创建一个频道，使用webhook打开slack创建频道在webhook页面选中创建的频道获取webhook url将URL写入到脚本中url='https://hooks.slack.com/services/TDP9T4YH4UDP/frkSC=' username='linuxea.com'命令行测试[root@DT_Node ~]# bash slack.sh '#linuxea-zabbix-monitor' PROBLEM '!' okzabbix web配置配置Medi types配置Action其中Default message简短为好配置Operations发送的用户媒介Resolved 也是如此而后发送的报警信息大致如下

linuxea:Zabbix4.0通过Telegram发送告警 zabbix 配置 Zabbix-in-Telegram加入你在香港或者其他地方，需要使用Telegram完成zabbix监控告警功能，你可以参考本章。如果在国内，推荐使用丁丁，或者微信，以及QQ等通讯工具。先决条件1，打开zabbix配置AlertScriptsPath=/usr/lib/zabbix/alertscripts2，申请Telegram机器人申请机器人参考: https://core.telegram.org/bots#creating-a-new-bot而后参考Zabbix-in-Telegram进行配置：https://github.com/ableev/Zabbix-in-Telegram配置Zabbix-in-Telegram克隆代码[root@Linuxea_Node ~]# git clone https://github.com/ableev/Zabbix-in-Telegram.git Cloning into 'Zabbix-in-Telegram'... remote: Enumerating objects: 9, done. remote: Counting objects: 100% (9/9), done. remote: Compressing objects: 100% (9/9), done. remote: Total 474 (delta 3), reused 1 (delta 0), pack-reused 465 Receiving objects: 100% (474/474), 169.39 KiB | 182.00 KiB/s, done. Resolving deltas: 100% (269/269), done.安装pip[root@Linuxea_Node ~]# yum install python-pip安装requirements.txt文件中的依赖[root@Linuxea_Node ~]# cd Zabbix-in-Telegram/ [root@Linuxea_Node ~/Zabbix-in-Telegram]# pip install -r requirements.txt复制zbxtg.py zbxtg_settings.example.py zbxtg_group.py 到/usr/lib/zabbix/alertscripts/[root@Linuxea_Node ~/Zabbix-in-Telegram]# cp zbxtg.py /usr/lib/zabbix/alertscripts[root@Linuxea_Node ~/Zabbix-in-Telegram]# cp zbxtg_settings.example.py /usr/lib/zabbix/alertscripts/[root@Linuxea_Node ~/Zabbix-in-Telegram]# cp zbxtg_group.py /usr/lib/zabbix/alertscripts/而后编辑zbxtg_settings.py，主要修改三个配置信息，如下：tg_key = "KEY" # telegram bot api keyzbx_server = "http://www.linuxea.com/zabbix/" # zabbix server full url zbx_api_user = "Admin" zbx_api_pass = "zabbix"tg_key就是申请机器人时候生成的。zabbix的用户名密码必须是能够登录的，且有权限的，可以使用Admin你可以通过 ./zbxtg.py "group name And username" "test" --group进行测试(你必须先创建群组，而后将bot拉入群内)配置zabbix-server-web创建Media types创建必要的Media types创建用户创建用户为后面添加的部分，此前缺少的部分，由于环境不一样，截图有些不同。但是大致的步骤肯定是一样的创建组我们创建必要的用户来进行发送报警信息，为了方便，我们理应创建一个组Administratior-> User group -> Create user group 在user group中填写创建的名字而后在Permissions中选择读权限，而后在select中选择所有，而后点击Add添加组到Permissions，最后Add创建User group创建用户Administratior-> Users -> Create user 在user 中填写创建的名字。在groups中点击select，在弹出的对话框中选择刚创建的telegram_group组，如下图而后在Media中，点击Add在弹出的对话框中，在type中选择创建过的Media types。而send to在本章Telegram的案例中是指Telegram的群名(Zabbix-in-Telegram)。而后选择之发送Disaster的报警 创建 action登录到页面中在configuration->Actions->Triggers->Create action创建一个action而后在Action的New condition中选择Trigger severity 选择High 和Disaster当发生Disaster和High 就会触发这个动作在Operations中，填写触发后的message，内容如下Default subject：告警主机: {HOST.NAME}问题详情: {ITEM.NAME}:{ITEM.VALUE} 告警时间: {EVENT.DATE} {EVENT.TIME} 告警等级: {TRIGGER.SEVERITY} 告警信息: {TRIGGER.NAME} 告警项目: {TRIGGER.KEY1} 当前状态: {TRIGGER.STATUS}.{ITEM.VALUE} 事件ID: {EVENT.ID} zbxtg;graphs zbxtg;graphs_period=10800 zbxtg;itemid:{ITEM.ID1} zbxtg;title:{HOST.HOST} - {TRIGGER.NAME}而后添加用户权限和媒介，如下图Recovery operations中与Operations一样的操作Default subject：恢复主机: {HOST.NAME}问题详情: {ITEM.NAME}:{ITEM.VALUE} 恢复时间: {EVENT.DATE} {EVENT.TIME} 事件等级: {TRIGGER.SEVERITY} 恢复项目: {TRIGGER.KEY1} 当前状态: {TRIGGER.STATUS}.{ITEM.VALUE} 事件ID: {EVENT.ID} zbxtg;graphs zbxtg;graphs_period=10800 zbxtg;itemid:{ITEM.ID1} zbxtg;title:{HOST.HOST} - {TRIGGER.NAME}而后将机器人拉入到群内，模拟一次故障成功发送图到Telegram中