【免费下载链接】community-templatesZabbix Community Templates repository项目地址https://gitcode.com/gh_mirrors/co/community-templates点击查看免费下载导读本文围绕 Zabbix Community Templates 仓库中的App Logstash模板6.0 版本文档展开剖析一种不依赖 JMX、不依赖 SNMP 的 Logstash 监控方案由 Python protobix 库编写的配套脚本读取 Logstash 节点统计 JSON再通过 Zabbix trapperSender协议将 40 余项 JVM、GC、Pipeline、进程级指标推送到 Zabbix Server。读完本文你将掌握该模板的完整监控项清单、发现规则、触发器逻辑、宏的作用以及它背后的脚本采集 Trapper 上报 Agent 哨兵三层数据流设计可直接在 Zabbix 6.0 环境中部署落地。一、模板定位与整体方案App Logstash是 Zabbix 社区为LogstashELK 中的 L提供的应用级监控模板作者为 fredprod。模板的核心思路写在 6.0 版 README 的 Overview 中This method uses python protobix library, and check metrics from logstash JSON file.即使用 Python protobix 库从 Logstash 的 JSON 统计数据中提取指标。也就是说监控数据的生产方不是 Zabbix 本身而是一个独立配套脚本——脚本在 Logstash 节点上读取其节点统计接口输出的 JSON解析出 JVM 内存、GC、线程、Pipeline 事件、进程 CPU、文件描述符等指标然后借助 protobix 库按 Zabbix trapper 协议推送给 Server。这种方案的典型优势在于Logstash 本身是 JVM 应用若用 JMX 监控需要额外开启 JMX 端点并维护 keytool 信任链而本模板只需脚本能访问 Logstash 的统计 JSON监控链路轻量、无侵入。模板本体template_logstash.yaml只负责在 Zabbix 侧定义接收指标的桶items、节点发现的入口discovery rule和告警规则triggers。仓库中的版本分布当前仓库中该模板按 Zabbix 主版本维护了三个版本目录目录面向 Zabbix 版本模板文件格式Applications/template_logstash/5.05.0XMLtemplate_logstash.xmlApplications/template_logstash/5.45.4YAMLtemplate_logstash.yamlApplications/template_logstash/6.06.0YAMLtemplate_logstash.yaml三个版本的 README 内容一致模板结构宏、发现规则、监控项、触发器也基本保持同步6.0 的 YAML 导出时间为 2021-11-21zabbix_export.version: 6.0可直接导入 Zabbix 6.0 及以上版本。5.0 的 XML 版本额外保留了applications分组Logstash、Logstash Memory、Logstash Node JVM、Logstash Pipeline Events、Logstash Process CPU、Logstash Process File Descriptors而 6.0 YAML 采用tags替代了 applications 分组这是 Zabbix 5.4 对旧分组机制的演进。二、模板宏{$ZBX_TPL_VERSION}README 中明确列出的宏只有一个宏名称描述默认值类型{$ZBX_TPL_VERSION}模板/脚本版本标识0.0.1Text macro文本宏在 6.0 YAML 的macros段中对应定义macros: - macro: {$ZBX_TPL_VERSION} value: 0.0.1这个宏不是用来计算数值的而是模板版本与脚本版本的握手令牌。配套脚本会把自身版本通过logstash.zbx_version这个 trapper 项上报给 Server模板中的触发器Logstash Template and Script version mismatched会用find()函数在logstash.zbx_version的取值中正则匹配0.0.1如果脚本版本与宏不一致说明脚本或模板有一方已更新而另一方未同步触发 INFO 级提示。这保证了模板升级后脚本也得跟着升级的运维一致性。三、发现规则Logstash discovery模板只定义了一条发现规则负责把 Logstash 节点纳入监控名称类型Key更新周期Logstash discoveryZabbix trapperlogstash.node.discovery0不轮询由脚本推送YAML 中的完整定义discovery_rules: - uuid: 02bcf2252dc6437ba7e10e0a213bb6a7 name: Logstash discovery type: TRAP key: logstash.node.discovery delay: 0 filter: conditions: - macro: {#NODENAME} value: .* formulaid: A lifetime: 3d解读其工作机制类型为 TrapperZabbix Server 不会主动轮询该 key而是等待脚本通过 trapper 协议推送发现数据JSON数据中应包含宏{#NODENAME}节点名由此生成被监控节点的 LLD 条目。过滤条件{#NODENAME}匹配.*接受所有上报的节点名不做白名单过滤。lifetime 为 3d若某个节点超过 3 天没有向logstash.node.discovery推送数据Server 会将其自动清理出监控列表——这天然覆盖了节点下线/脚本停止的场景。另外还有一条名为Logstash discovery的Zabbix agent (active)监控项key 同样是logstash.discovery更新周期 1h注意与上面的发现规则区分这条 item 由 agent 主动采集用于周期性报告脚本的发现执行状态。四、监控项全解析44 项模板定义了 44 个监控项README 的 Items collected 表绝大部分42 项是Zabbix trapper类型由脚本推送另有 2 项由Zabbix agent (active)采集。按功能可分为以下类别。4.1 健康检查与版本哨兵agent active / 文本名称Key类型更新备注Logstash checklogstash.checkZabbix agent (active)1m脚本运行状态0 为正常Logstash discoverylogstash.discoveryZabbix agent (active)1h发现任务执行状态Logstash zabbix script versionlogstash.zbx_versionZabbix trapper—TEXT 类型history 15dtrends 关闭logstash.zbx_version在 YAML 中的定义比较特殊value_type: TEXT、trends: 0不做趋势存储因为它只是版本字符串用于与{$ZBX_TPL_VERSION}宏比对无需保留历史趋势。4.2 JVM 内存Heap / Non-Heap所有内存指标单位均为B字节value_type 为 FLOAThistory 30d名称KeyLogstash JVM Mem heap committedlogstash.jvm.mem.heap_committed_in_bytesLogstash JVM Mem heap maxlogstash.jvm.mem.heap_max_in_bytesLogstash JVM Mem heap usedlogstash.jvm.mem.heap_used_in_bytesLogstash JVM Percent Mem heap usedlogstash.jvm.mem.heap_used_percent单位%Logstash JVM Mem non heap committedlogstash.jvm.mem.non_heap_committed_in_bytesLogstash JVM Mem non heap usedlogstash.jvm.mem.non_heap_used_in_bytesheap_used_percent是模板中唯一带双级告警的指标详见触发器章节也是日常看板最常用的JVM 健康度指标。4.3 JVM 内存池Poolsyoung / survivor / old三类内存池各自有 5 个维度committed、max、used、peak_max、peak_used共 15 项单位均为BYoung 代logstash.jvm.mem.pools.young.committed_in_byteslogstash.jvm.mem.pools.young.max_in_byteslogstash.jvm.mem.pools.young.used_in_byteslogstash.jvm.mem.pools.young.peak_max_in_byteslogstash.jvm.mem.pools.young.peak_used_in_bytesSurvivor 区logstash.jvm.mem.pools.survivor.committed_in_byteslogstash.jvm.mem.pools.survivor.max_in_byteslogstash.jvm.mem.pools.survivor.used_in_byteslogstash.jvm.mem.pools.survivor.peak_max_in_byteslogstash.jvm.mem.pools.survivor.peak_used_in_bytesOld 代logstash.jvm.mem.pools.old.committed_in_byteslogstash.jvm.mem.pools.old.max_in_byteslogstash.jvm.mem.pools.old.used_in_byteslogstash.jvm.mem.pools.old.peak_max_in_byteslogstash.jvm.mem.pools.old.peak_used_in_bytespeak_*系列反映的是历史峰值自 JVM 启动以来的最高水位对判断内存池是否曾接近上限、是否需要调大堆很有价值。4.4 JVM GC 收集器名称Key单位Logstash JVM gc collectors old collection countlogstash.jvm.gc.collectors.old.collection_count—Logstash JVM gc collectors old collection timelogstash.jvm.gc.collectors.old.collection_time_in_millismsLogstash JVM gc collectors young collection countlogstash.jvm.gc.collectors.young.collection_count—Logstash JVM gc collectors young collection timelogstash.jvm.gc.collectors.young.collection_time_in_millismsyoung 与 old 两个收集器的次数/耗时分开统计配合前面的内存池指标可以完整评估 GC 频率与停顿对 Logstash 吞吐的影响。4.5 JVM 线程与运行时间名称Key单位Logstash JVM Threads countlogstash.jvm.threads.count—Logstash JVM Threads peak countlogstash.jvm.threads.peak_count—Logstash JVM uptimelogstash.jvm.uptime_in_millismsuptime_in_millis可辅助判断节点是否发生过重启——重启后该值会归零重新累计配合 heartbeat 触发器可还原故障时间线。4.6 Pipeline 事件统计名称Key单位Logstash Pipeline Events durationlogstash.pipeline.events.duration_in_millismsLogstash Pipeline Events filteredlogstash.pipeline.events.filtered—Logstash Pipeline Events inlogstash.pipeline.events.in—Logstash Pipeline Events outlogstash.pipeline.events.out—in / filtered / out是 Logstash 管道最核心的三组计数进入管道的事件数、经 filter 处理后的事件数、成功输出的事件数。duration_in_millis则是事件在管道中停留的总耗时毫秒可用于评估 filter 链的处理效率。4.7 进程 CPU 与负载名称Key单位Logstash Process CPU load 1logstash.process.cpu.load_average.1m—Logstash Process CPU load 5logstash.process.cpu.load_average.5m—Logstash Process CPU load 15logstash.process.cpu.load_average.15m—Logstash Process CPUlogstash.process.cpu.percent%Logstash Process CPU Total in mslogstash.process.cpu.total_in_millisms三个 load average 分别对应 1/5/15 分钟的系统负载percent是 CPU 使用百分比total_in_millis是进程累计 CPU 时间。4.8 文件描述符与虚拟内存名称Key单位Logstash Process Max File descriptorslogstash.process.max_file_descriptors—Logstash Process Open File descriptorslogstash.process.open_file_descriptors—Logstash Process Peak File descriptorslogstash.process.peak_open_file_descriptors—Logstash Mem Total Virtuallogstash.process.mem.total_virtual_in_bytesB文件描述符三项上限/当前打开/历史峰值对排查 Too many open files 类故障至关重要total_virtual_in_bytes表示进程占用的虚拟内存总量。4.9 监控项的通用属性从 6.0 YAML 可以看到所有 trapper 项都遵循同样的定义模式- uuid: f0ee1d0ded7f46f5bd4f17a40138d2f1 name: Logstash JVM Mem heap committed type: TRAP key: logstash.jvm.mem.heap_committed_in_bytes delay: 0 history: 30d value_type: FLOAT units: B tags: - tag: Application value: Logstash Node JVM几个关键点type: TRAPdelay: 0trapper 项不轮询delay 恒为 0数据到达时间完全由脚本推送频率决定。history: 30dJVM/Pipeline 类指标保留 30 天历史而logstash.check、logstash.discovery、logstash.zbx_version以及三个 load average 项为15d在 YAML 中可逐一核对。tags取代 applications6.0 版本用Application: Logstash Node JVM、Application: Logstash Pipeline Events、Application: Logstash Process CPU、Application: Logstash Process File Descriptors、Application: Logstash Memory、Application: Logstash等标签对监控项分类这也是 5.0 XML 中applications分组的等价物。value_type 与 units绝大多数为 FLOAT内存类B、时间类ms、百分比%版本项为 TEXT。五、触发器详解README 与模板文件的差异说明这里有一个值得注意的细节README 的 Triggers 章节写的是 There are no triggers in this template.模板中没有触发器但实际模板文件里定义了 6 条触发器。以 6.0 YAML 和 5.0 XML 为准实际触发器如下触发器名称表达式优先级含义Logstash check failedmin(/App Logstash/logstash.check,3m)0AVERAGE3 分钟内 check 值最小值 0即脚本检查失败Logstash discovery failedlast(/App Logstash/logstash.discovery)0WARNING最近一次发现结果 0即发现任务异常Logstash JVM Heap used percent is highavg(/App Logstash/logstash.jvm.mem.heap_used_percent,30m)75AVERAGE30 分钟堆使用率均值 75%Logstash JVM Heap used percent is TOO HIGHavg(/App Logstash/logstash.jvm.mem.heap_used_percent,30m)85HIGH30 分钟堆使用率均值 85%Logstash heartbeatnodata(/App Logstash/logstash.zbx_version,10m)1WARNING版本数据 10 分钟无更新判定脚本/节点失联Logstash Template and Script version mismatchedfind(/App Logstash/logstash.zbx_version,,regexp,0.0.1)0INFO脚本版本与模板宏版本不一致值得展开的两个设计双级堆告警依赖关系is high75%与is TOO HIGH85%都基于heap_used_percent的 30 分钟均值。YAML 中is high通过dependencies声明依赖is TOO HIGH从而形成先 AVERAGE 后 HIGH的分级告警阶梯堆水位 75% 持续 30 分钟先报 AVERAGE若继续恶化到 85% 再升级 HIGH避免抖动导致告警风暴。YAML 中触发器描述还指出is high的描述为 JVM heap used percent average is above 75% for 30m.is TOO HIGH为 JVM heap used percent average is above 90% during 30m.注意描述中的 90% 与表达式 85 存在轻微出入以表达式为准。心跳与版本一致性Logstash heartbeat依赖logstash.zbx_version的 10 分钟无数据nodata并带恢复表达式nodata(...,1m)1数据恢复后 1 分钟内解除Logstash Template and Script version mismatched用find()正则检查上报版本是否含0.0.1与{$ZBX_TPL_VERSION}宏呼应。这两条触发器共同保证脚本活着、且版本与模板匹配。六、数据流与工作机制三层配合综合 README 与模板定义整套方案的数据流可以归纳为三层采集层脚本 protobix配套 Python 脚本在 Logstash 节点上运行读取 Logstash 节点统计的 JSON 数据对应 Logstash 节点统计接口输出的字段结构如jvm.mem.heap_used_in_bytes、jvm.gc.collectors.young.collection_count、pipeline.events.in、process.cpu.percent等。README 明确指出该方法依赖python protobix 库该库封装了 Zabbix trapper/sender 协议脚本只需把解析出的指标以key → value形式交给 protobix即可批量推送给 Zabbix Server。接收层Zabbix trapper itemsServer 侧由模板预置的 42 个 trapper 项按 key 接收数据logstash.node.discovery则接收含{#NODENAME}的发现 JSON驱动 LLD 生成节点监控条目lifetime 3d 自动清理失联节点。哨兵层Zabbix agent activelogstash.check1 分钟与logstash.discovery1 小时由 agent 主动模式采集反馈脚本自身的健康状态——任何一层脚本崩溃、JSON 解析失败、推送中断都会体现为 check/discovery 非零或zbx_version无数据从而触发上面的告警。这种trapper 收数据、agent 做哨兵、宏做版本握手的组合让监控项完全不受轮询间隔限制数据按脚本自身的节奏推送又保留了独立于推送链路的故障检测能力。七、部署与使用要点仓库根目录 README.md 说明了社区模板的标准使用流程应用到本模板即获取模板文件从 Applications/template_logstash/6.0 下载template_logstash.yamlZabbix 6.0 环境5.x 环境请使用 5.4 版 YAML 或 5.0 版 XML。导入模板在 Zabbix 前端进入Data collection → Templates → Import选择下载的 YAML/XML 文件导入模板名为App Logstash所属组为 Templates。准备配套脚本模板本身不包含采集脚本需要按原文档说明README Overview 中注明脚本的获取方式部署 fredprod 提供的 logstash-zabbix 脚本及 Python protobix 库到 Logstash 节点并确保脚本能读取 Logstash 的节点统计 JSON。配置 Host 并关联模板为主机对应 Logstash 节点关联App Logstash模板配置 Zabbix agentactive以支撑logstash.check/logstash.discovery两个哨兵项。验证导入后检查logstash.zbx_version是否收到脚本上报的0.0.1若触发Logstash Template and Script version mismatched说明脚本版本与{$ZBX_TPL_VERSION}宏不一致需对齐两者。八、常见问题与排障思路Logstash heartbeat告警logstash.zbx_version超过 10 分钟无数据通常是脚本未运行、protobix 推送失败或 Logstash 统计 JSON 不可读。先确认脚本进程与日志再检查 Server 端 trapper 端口连通性。Logstash check failed/Logstash discovery failed检查脚本是否写入了非零状态值如 JSON 解析失败、节点名获取失败以及 agent active 模式是否正常回传。Logstash JVM Heap used percent is high / TOO HIGH对应堆使用率持续高位需结合heap_max_in_bytes、pools.old.*与 GC 指标判断是否需要调整-Xmx或优化 filter 链内存占用。发现列表为空或节点消失确认logstash.node.discovery是否收到含{#NODENAME}的推送节点超过 3 天lifetime未上报会被自动清理属预期行为。总结App Logstash模板是一套结构清晰、职责分明的 Logstash 应用监控方案42 个 trapper 指标覆盖 JVM 堆/非堆/内存池/GC/线程、Pipeline 事件计数与耗时、进程 CPU/负载/文件描述符/虚拟内存配合logstash.node.discovery的 LLD 节点发现、{$ZBX_TPL_VERSION}宏的版本握手、以及 check/discovery/heartbeat 三层故障哨兵让 Logstash 节点在无 JMX、无 SNMP 的前提下获得完整可观测性。部署时请以本仓库 6.0 YAML 中的实际触发器与监控项定义为准README 中 no triggers 的表述与模板文件存在出入并注意脚本与模板的版本一致性。赞分享【免费下载链接】community-templatesZabbix Community Templates repository项目地址https://gitcode.com/gh_mirrors/co/community-templates点击查看免费下载相关推荐Zabbix 监控 Logstash基于 Protobix 与 Zabbix Trapper 的 App Logstash 模板实战解析Zabbix 监控 Logstash基于 Protobix 与 Zabbix Trapper 的 App Logstash 模板实战解析 本文以 ZabbixZabbix App Logstash 模板实战基于 Python Protobix 与 Trapper 的 Logstash 监控方案Zabbix App Logstash 模板实战基于 Python Protobix 与 Trapper 的 Logstash 监控方案 导读 本文围绕 coFlexGen 基准测试中的 HuggingFace Transformers第三方基线框架的安装、核心 API 与 OPT 推理实战FlexGen 基准测试中的 HuggingFace Transformers第三方基线框架的安装、核心 API 与 OPT 推理实战 HuggingFace上一篇easy-vibe 后端架构演进实战指南从单体到微服务的拆分时机、策略与数据治理下一篇Effect 数据库迁移MigratorWindows 文件路径兼容修复Migrator.fromFileSystem 如何通过 File URL 让 ESM 加载器接受绝对路径创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考