Zabbix 面试题

HistoryCacheSize=128M           # 历史缓存大小（建议 128M-1G）
HistoryIndexCacheSize=32M       # 索引缓存
TrendCacheSize=64M              # 趋势缓存
ValueCacheSize=256M             # 值缓存（SNMP 等指标）
CacheUpdateFrequency=60         # 配置同步周期
HousekeepingFrequency=1         # 清理频率（小时）

T+0s      采集到新值，写入 History Cache
T+0s      同步到 ValueCache，触发器引擎评估
T+5s      flush 周期到达，批量写入 DB history 表
T+1h      Housekeeper 删除超过保留期的历史

poller 数 ≈ NVPS / 1000  （经验公式，每 poller 约 1k NVPS）
trapper 数 ≥ 主动 Agent 数量 / 10
http poller 数 ≈ 活跃 Web 场景数 / 50
SNMP 设备多时加大 StartSNMPPollers
JMX 应用多时加大 StartJMXPollers

# /etc/zabbix/zabbix_server.conf

StartPollers=20
StartTrappers=10
StartPingers=5
StartHTTPPollers=5
StartSNMPPollers=10
StartIPMIPollers=2
StartJMXPollers=5
StartLLD=5
StartAlerters=5
StartEscalators=5
StartPreprocessors=10
HistorySyncer=8

# 内部监控项 zabbix[process,<type>,<mode>,<state>]
# 例如：zabbix[process,poller,avg,busy] > 75% 表示 poller 繁忙
zabbix_get -s localhost -k 'zabbix[process,poller,avg,busy]'
zabbix_get -s localhost -k 'zabbix[queue]'

Template Module Linux (基础模板)
  ├─ Template Module Linux CPU
  ├─ Template Module Linux Memory
  ├─ Template Module Linux Filesystems (LLD)
  └─ Template Module Linux Network Interfaces (LLD)

主机 web-01 链接到 Template Module Linux
  → 自动继承所有子模板、Item、Trigger、LLD

Zabbix 优势场景:
  - 传统 IDC（物理机、网络设备、存储）
  - 大量 SNMP/IPMI 设备（交换机、路由器、BMC）
  - 中小规模业务（数千到数万台主机）
  - 需要开箱即用的告警升级/值班
  - 数据库、中间件、应用有官方模板

Prometheus 优势场景:
  - Kubernetes / Service Mesh / 微服务
  - 容器化业务（Pod 生命周期短）
  - 多维标签聚合分析（按 Service/Env/Region）
  - 大规模时序聚合（PromQL 灵活）
  - 与 Grafana / Loki / Tempo 生态集成

现代监控栈:
  指标:  Prometheus / VictoriaMetrics / Thanos
  日志:  Loki / ELK / OpenSearch
  追踪:  Tempo / Jaeger / SkyWalking
  传统: Zabbix（保留对物理设备/网络/中间件的统一监控）
  
  → Zabbix 与 Prometheus 长期并存，互为补充

Agent 2 内置插件:
  - PostgreSQL / MySQL / Oracle / MSSQL / MongoDB
  - Redis / Memcached / RabbitMQ / Kafka / MQTT
  - Docker / systemd / Ceph / Proxmox
  - HTTP / ICMP / SNMP / Modbus / Smart
  - FilePath / Directory / LogFile / WindowsEventLog
  - ... (持续扩展)

# /etc/zabbix/zabbix_agent2.conf (Agent 2)
Plugins.PostgreSQL.Sessions.<SessionName>.URI=postgresql://user:pass@host:5432/db
Plugins.Redis.Sessions.<SessionName>.URI=redis://host:6379

# /etc/zabbix/zabbix_agentd.conf (传统 Agent)
UserParameter=mysql.questions,mysqladmin -uroot status | awk '{print $6}'

# Agent 2 使用插件 Key (内置)
postgresql.ping[session1]
redis.info[session1,used_memory]
mysql.custom.query[session1,"SHOW GLOBAL STATUS LIKE 'Threads_connected'"]

# 传统 Agent 需 UserParameter 自定义
mysql.questions

# /etc/zabbix/zabbix_agentd.conf

# 被动模式（必须配置）
Server=192.168.1.100
ListenPort=10050
ListenIP=0.0.0.0

# 主动模式（必须配置）
ServerActive=192.168.1.100:10051
HostnameItem=system.hostname
RefreshActiveChecks=120

# 同时启用：可减少 Server 轮询压力

Item Type:
  Zabbix agent           → 被动
  Zabbix agent (active)  → 主动
  SNMP agent             → 被动
  IPMI agent             → 被动
  JMX agent              → 被动
  Zabbix trapper          → 主动推送（由 Agent/Script sender）
  Zabbix aggregate       → 计算型
  HTTP agent             → 被动

# /etc/zabbix/zabbix_server.conf
StartSNMPPollers=10
SNMPTrapperFile=/tmp/zabbix_traps.tmp

# 时间相关参数（超时与重试）
Timeout=3
SNMPTimeout=1       # 覆盖全局 Timeout

# 单设备并发（避免拖垮）
MaxConcurrentChecksPerPoller=10

Host Configuration:
  SNMP interface: 192.168.1.1:161
  Use bulk requests (SNMPv2c/v3): ✓
  SNMP version: SNMPv2c
  Community: public

# 通用 OID 形式
IF-MIB::ifInOctets.2                          # 端口 2 入口字节
IF-MIB::ifOutOctets.2                         # 端口 2 出口字节
SNMPv2-MIB::sysName.0                         # 设备名
HOST-RESOURCES-MIB::hrStorageSize.1           # 存储大小
HOST-RESOURCES-MIB::hrStorageUsed.1           # 存储已用

# 计算速率（Zabbix 触发器）
{host:net.if.in[ifInOctets.2].change(60)} > 100000000  # 入流量 > 100MB/min

# 1. Zabbix 配置 snmptrapd
cat /etc/snmp/snmptrapd.conf
# traphandle default /usr/sbin/zabbix_trap_receiver.pl
# 或者用 snmptrapd 内置方式（Zabbix 5.0+）
disableAuthorization yes
traphandle default /usr/sbin/zabbix_trap_receiver

# 2. Zabbix Server 启用 trapper
StartSNMPTrapper=1
SNMPTrapperFile=/tmp/zabbix_traps.tmp

# 3. 创建 Item: Type = SNMP trap

Template SNMP Interfaces     # 通用接口流量（LLD 自动发现）
Template SNMP Generic        # 通用 OID 监控
Template SNMP OS Linux       # 主机资源
Template SNMP OS Cisco       # Cisco 设备
Template SNMP OS Huawei      # 华为设备
Template SNMP OS H3C         # H3C 设备

IPMI 监控项示例（标准模板）:
  - ipmi.sensor[CPU1 Temp]
  - ipmi.sensor[System Temp]
  - ipmi.sensor[Power Supply 1]
  - ipmi.sensor[FAN1 Speed]
  - ipmi.sensor[+12V]
  - ipmi.sensor[Chassis Intrusion]

# /etc/zabbix/zabbix_server.conf
StartIPMIPollers=5

# /etc/zabbix/zabbix_agentd.conf
# IPMI 由 Server 端直接轮询 BMC，无需 Agent
# Agent 端无需配置

Host Configuration:
  IPMI interface: 10.0.0.1:623
  IPMI sensor:   # 默认不填，自动发现
  IPMI authentication algorithm: Default
  IPMI privilege level: Operator
  IPMI username: zabbix
  IPMI password: ********

✔ 必须 IPMI 监控的场景:
  - 物理机/裸金属服务器（核心生产）
  - 温度异常敏感的高密度机房
  - 硬件故障预警（CPU 过热、内存 ECC、电源失效）
  - 静默故障捕获（系统挂掉后 Agent 无法上报，IPMI 仍可报告）

✘ 不适合 IPMI 的场景:
  - 虚拟机（无 BMC）
  - 云主机（厂商 API 替代）
  - 网络设备（用 SNMP）
  - 嵌入式/工控机

# /etc/zabbix/zabbix_server.conf
StartTrappers=5
TrapperTimeout=30

# Item Type 配置（Web UI）:
Type: Zabbix trapper
Key:  trap.queue.depth
Type of information: Numeric (unsigned)

# 单值推送
zabbix_sender -z 192.168.1.100 -s "web-01" -k trap.queue.depth -o 42

# 批量推送（推荐）
cat > /tmp/data.txt <<EOF
"web-01" trap.queue.depth 1234567890 42
"web-01" trap.cache.hit 1234567890 0.85
"web-01" trap.api.qps 1234567890 1523
EOF

zabbix_sender -z 192.168.1.100 -T -i /tmp/data.txt

HTTP Agent 通过 HTTP 拉取数据:
  - 监控 Web 业务健康（状态码、响应时间、Body 内容）
  - 拉取 RESTful API 数据（JSONPath 提取）
  - 与云厂商 API 集成（AWS CloudWatch、阿里云监控）
  - 模拟用户访问链路（多步调用、Cookie 处理）
  - 自定义数据源（业务系统暴露 /metrics 端点）

Item Type: HTTP agent
URL: https://api.example.com/v1/health
Request method: GET
Request headers: Authorization: Bearer xxxxx
Timeout: 5s
Status codes: 200
Response body:
  Type: JSON
  JSONPath: $.data.health
Required status codes: 200

Scenario（场景）:
  Steps:
    Step 1: POST /api/login  → 提取 Token（Variables: token=$.data.token）
    Step 2: GET /api/orders  → 携带 Token + Headers
    Step 3: 提取订单数（JSONPath: $.total）

适用: 复杂 Web 业务可用性监控、登录后业务流断言

Template App MySQL (主模板)
  ├─ Template App MySQL Processes       (子模板)
  ├─ Template App MySQL Connections     (子模板)
  ├─ Template App MySQL InnoDB          (子模板)
  └─ Template App MySQL Replication      (子模板)

应用主模板只做:
  - 链接所有子模板
  - 定义通用宏 (如 {$MYSQL.HOST}, {$MYSQL.PORT}, {$MYSQL.USER})
  - 创建 Dashboard

链接（Link）:
  - 主机/模板添加其他模板的完整内容
  - 可链接多个

模板继承（Template nesting）:
  - 模板 A "Includes other templates"
  - 实质是子模板机制
  - 方便拆分主模板

主机 db-master-01 配置:
  Linked templates:
    1. Template App MySQL (主模板)
    2. Template Module Linux (OS 基础)
  
  Macros:
    {$MYSQL.HOST} = localhost
    {$MYSQL.PORT} = 3306
    {$MYSQL.USER} = zbx_monitor
  
  → 自动应用所有子模板的 Items/Triggers/Graphs/LLD

命名规范:
  Template Module <OS>           # OS 基础（CPU/Mem/Disk/Net）
  Template App <AppName>         # 应用层
  Template App <AppName> <Feature># 应用子功能
  Template Service <Service>     # 业务服务
  Template Custom <Team>         # 团队自定义

目录:
  Templates/
    OS/
    Databases/
    Middleware/
    WebServers/
    Network/
    Business/

{HOST.NAME}         主机名
{HOST.ID}           主机 ID
{HOST.IP}           主机 IP
{HOST.PORT}         端口
{HOST.CONN}         连接 IP:Port
{HOST.DNS}          DNS 名称
{HOST.GROUP}        主机所属组
{ITEM.LASTVALUE}    当前值
{ITEM.VALUE}        历史值
{TRIGGER.SEVERITY}  严重等级
{TRIGGER.STATUS}    状态
{EVENT.SEVERITY}    事件等级
{EVENT.TIME}        事件时间
{DATE}              当前日期
{TIME}              当前时间
{INVENTORY.<FIELD>} 资产清单字段

# 模板级宏
{$CPU.WARN}    = 70
{$CPU.CRIT}    = 90
{$MEM.WARN}    = 80
{$DISK.WARN}   = 85
{$IF.HIGHER}   = 1000000000     # 1Gbps 阈值

# Item 中使用
vfs.fs.size[/,pfree]   # 触发器
{Template App Linux: vfs.fs.size[/,pfree].last()} < {$DISK.WARN:20}

# 主机级覆盖
{$MYSQL.PORT} = 13306  # 覆盖模板默认 3306

# 宏的上下文：内建宏引用用户宏
{HOST.NAME} on {HOST.IP} failed: {ITEM.LASTVALUE} > {$THRESHOLD}

# 宏内嵌宏
{$ALERT.URL}  = http://alertmanager/{HOST.ID}?p={$ENV}

# 主机宏覆盖模板宏
主机级别: {$MYSQL.PORT} = 13306
模板级别: {$MYSQL.PORT} = 3306
实际生效: 13306（主机级覆盖）

# 缺省值
{$MYSQL.PORT:3306}    # 未定义时用 3306

# 用户宏在 Script/Command 中
{$SNMP_COMMUNITY} 替换到外部脚本

# 操作系统
vfs.fs.discovery              # 文件系统
net.if.discovery              # 网卡
cpu.discovery                 # CPU 核心
memory.discovery              # 内存
system.sw.packages.discovery  # 软件包
system.disk.discovery         # 磁盘（SMART）

# 数据库（Agent 2 插件）
postgresql.discovery          # PostgreSQL 数据库/表
mysql.discovery               # MySQL 数据库/表
redis.discovery               # Redis 节点

# 中间件
docker.container.discovery    # Docker 容器

# 自定义发现脚本（返回 JSON）
cat > /etc/zabbix/scripts/discover_services.sh <<'EOF'
#!/bin/bash
systemctl list-units --type=service --state=running --no-legend | \
  awk '{print "{\"{#SERVICE}\": \"" $1 "\"}"}' | \
  jq -s .
EOF

# 配置文件: UserParameter=service.discovery,/etc/zabbix/scripts/discover_services.sh

{
  "data": [
    {"{#SERVICE}": "nginx.service", "{#PID}": "1234"},
    {"{#SERVICE}": "mysql.service", "{#PID}": "5678"},
    {"{#SERVICE}": "redis.service", "{#PID}": "9012"}
  ]
}

Item Prototype:
  Name: Free disk space on {#FSNAME}
  Key:  vfs.fs.size[{#FSNAME},free]
  Type: Zabbix agent (active)
  Update interval: 60s

Trigger Prototype:
  Expression: {Template: vfs.fs.size[{#FSNAME},pfree].last()} < {$DISK.WARN:20}
  Name: Free disk space on {#FSNAME} is low

# 发现时过滤：只发现特定类型的文件系统
LLD Rule → Filters:
  {#FSTYPE} matches (ext4|xfs|btrfs)
  {#FSNAME} does not match (/boot|^/sys|^/proc)

T+0s    LLD Rule 周期执行
T+0s    返回 JSON
T+0s    解析 + 过滤
T+0s    实例化所有原型
T+0s    创建实际 Item/Trigger/Graph
T+300s  下次执行（默认 1h 一次）
        - 新发现：创建新 Item
        - 已存在：跳过
        - 消失：删除旧 Item（或保留，配置项控制）

LLD Rule → "Lost resources period":
  None           # 立即删除
  1h             # 1h 后未发现则删除
  Forever        # 永保留（已发现的不删除）

# 自定义发现脚本返回
{
  "data": [
    {
      "{#DB}": "users",
      "{#TABLE}": "user_profile",
      "{#ENGINE}": "InnoDB"
    }
  ]
}

# Item 原型
mysql.table.size[{#DB},{#TABLE}]

# Trigger 原型
{Template: mysql.table.size[{#DB},{#TABLE}].last()} > 1073741824

# Item 原型中使用宏混合
vfs.fs.size[{#FSNAME},pfree]

# Trigger 阈值用用户宏
{Template: vfs.fs.size[{#FSNAME},pfree].last()} < {$DISK.WARN:20}

# 用户宏可针对 {#FSNAME} 不同设置不同阈值
# 通过主机宏 + 上下文宏

# SNMP ifXTable 返回
{
  "data": [
    {
      "{#IFNAME}": "GigabitEthernet0/0/1",
      "{#IFALIAS}": "uplink-to-core",
      "{#IFSPEED}": "10000000000"
    }
  ]
}

# LLD Rule Filter: 提取 alias 中的 VLAN 信息
Filters:
  {#IFALIAS} matches .*VLAN(\d+).*  
  → 新宏 {#VLANID} = \1（正则捕获）

# 模板 A: Template Module Linux
LLD Rule: vfs.fs.discovery
  → Item 原型: vfs.fs.size[{#FSNAME},pfree]
  → Trigger 原型: ... < {$DISK.WARN}

# 模板 B: Template App MySQL（继承 A）
LLD Rule: mysql.databases.discovery（自定义）
  → Item 原型: mysql.db.size[{#DBNAME}]
  → Trigger 原型: ... < {$DB.SIZE.WARN}
  → 依赖 Trigger: A 模板的 vfs.fs.size[/,pfree]（防止根盘满时反复告警）

# Item 原型（计算型）
Item Prototype:
  Type: Calculated
  Key:  if.util[{#IFNAME}]
  Formula: (last("net.if.in[{#IFNAME}]") + last("net.if.out[{#IFNAME}]")) * 8 / last("net.if.speed[{#IFNAME}]") * 100

# Preprocessing 步骤
Item Prototype → Preprocessing:
  1. JavaScript: return Math.round(value / 1024 / 1024)  // B → MB
  2. Regular expression: \d+

陷阱:
  1. LLD 周期太短（< 5min）导致 Server 压力大
  2. 过滤规则过宽，产生大量无用 Item
  3. 触发器原型硬编码阈值，未用宏
  4. Item 原型未启用 Host Inventory 资产
  5. 主机 LLD 创建的主机未关联模板

最佳实践:
  1. LLD 周期建议 1h-12h（变更不频繁的实体）
  2. 必须配置 Filter，过滤 tmpfs、/proc、/sys 等
  3. 阈值全部用用户宏，团队/主机可覆盖
  4. 命名规范: "Service: <name> on {#HOST.NAME}"
  5. Trigger 原型配合 LLD 宏 + 用户宏 + 触发器依赖
  6. 主机 LLD 自动发现主机时关联完整模板
  7. 大量 LLD 监控项时启用 "Delete lost resources"

LLD 创建的 Item 数 = SUM(每个 LLD Rule 发现的实体数 × 原型数)
例: 5000 主机 × 每机 5 磁盘 × 3 Item/磁盘 = 75,000 Item
    5000 主机 × 每机 3 网卡 × 5 Item/网卡 = 75,000 Item
    合计 150,000 Item

→ NVPS 估算: 150000 / 60 = 2,500 NVPS（仅 1 分钟间隔）
→ 需相应调高 StartPreprocessors、HistorySyncer

{<server>:<key>.<func>(<params>)} <operator> <constant>
{host:item.key.func(params)} <op> <value>

# 1. CPU 5 分钟内平均值 > 80%
{Template App Linux: cpu.util.avg(300)}>80

# 2. 磁盘空间小于 20% 持续 5 分钟
{Template App Linux: vfs.fs.size[/,pfree].last()}<{$DISK.WARN:20}

# 3. 端口流量突变（变化量）
{Template SNMP Interfaces: net.if.in[{#IFNAME}].change(300)}>1000000000

# 4. 5 分钟内连续 3 次超标
{Template App Linux: cpu.util.last()}>80 and
{Template App Linux: cpu.util.count(300,gt,80)}>=3

# 5. 服务宕机（无数据）
{Template App Linux: agent.ping.nodata(300)}=1

# 6. 时间窗口告警（仅工作时间）
{Template App X: queue.depth.last()}>1000 and
{Template App X: time()}>090000 and
{Template App X: time()}<180000

# 7. 多条件组合（AND/OR）
{Template App MySQL: mysql.threads.last()}>200 and
{Template App MySQL: mysql.slow_queries.rate(60)}>5

Not classified → Information → Warning → Average → High → Disaster
（递增严重度）

# 使用宏和单位
{Host: temp.last()}>80      # 80 度
{Host: temp.last()}>$TEMP_WARN}     # 80
{Host: net.if.in.last()}>10Mbps   # 难以比较单位
→ 用宏: {Host: net.if.in.last()}>$BANDWIDTH.WARN:10485760}

# 表达式换行
{Template App Linux: cpu.util.avg(300)} > {$CPU.WARN:80} and
{Template App Linux: cpu.util.avg(300)} < 100

# Problem: > 80%, Recovery: < 70%（迟滞防抖动）
{Template: cpu.last()}>80      # 进入 PROBLEM
{Template: cpu.last()}<70      # 进入 OK

# 配合两套表达式
PROBLEM Expression: {T: cpu.last()}>80
OK Event Generation: Recovery expression: {T: cpu.last()}<70

Trigger B: HTTP Service Unavailable
  Depends on:
    1. HOST: agent.ping (Host is unreachable)
    2. Trigger: Port 80 Unavailable (网络层)
    3. Trigger: Service nginx down (进程层)

当 HOST DOWN 时，HTTP Service 触发器不会告警
只有当 A、B、C 均 OK 时，HTTP Service 仍异常才告警

# 模板层依赖
Template Module Linux:
  Trigger: HOST DOWN（agent.ping）
    → 所有其他 Item 的触发器都依赖它

Template App MySQL（继承 Linux）:
  Trigger: MySQL Connection Failed
    → depends on: HOST DOWN
  Trigger: MySQL Replication Lag
    → depends on: MySQL Connection Failed

Template App Nginx:
  Trigger: Nginx port 80 down
    → depends on: HOST DOWN
  Trigger: Nginx request 5xx
    → depends on: Nginx port 80 down（端口挂了不报 5xx）

Web UI: Trigger → Dependencies → Add parent trigger

或在 trigger 表达式中用 "Depends on":
Trigger: MySQL Connection Failed
  Dependencies:
    - Trigger: {HOST.NAME}: agent.ping.nodata(300)=1
    - Trigger: {HOST.NAME}: icmppingloss.max(60)=100

1. 主机层依赖（HOST DOWN）
   - 主机不在线时，所有服务级 trigger 都不告警
   - 在模板中配置：所有应用 trigger depends on HOST

2. 服务层依赖（Service: 端口 → 进程 → 业务）
   - 端口挂了不报业务异常
   - 进程挂了不报 HTTP 5xx

3. 节点依赖（Node）
   - 数据库主从：主库挂了从库告警升级
   - K8s 节点：节点 NotReady → Pod 异常

4. 避免循环依赖
   - A → B → A 会导致评估异常

场景: 网络交换机故障
1. 交换机挂 → 50 台服务器网络不通
2. 每台服务器触发：agent.ping fail、service down、磁盘读不到、连接超时...
3. 每台机器发 30+ 告警 × 50 台 = 1500 条告警轰炸
4. 值班人员崩溃

→ 依赖配置后：仅 1 条 "交换机 X 不可达" 告警

Operations:
  Step 1: 立即执行
    - Send message: Email to group "ops-l1" (message: ${TRIGGER.NAME} on {HOST.NAME})
  
  Step 2: 10 分钟后（PROBLEM 持续）
    - Send message: SMS to group "ops-l1" (短信模板)
    - Delay between operations: 600s
  
  Step 3: 30 分钟后（仍 PROBLEM）
    - Send message: Email to group "ops-l2-dba" (CC 二线)
    - Delay: 1200s
  
  Step 4: 1 小时后
    - Run remote command: /usr/local/bin/restart.sh on {HOST.IP}
    - Send message: WeChat webhook to channel #sre-alert
  
  Step 5: 4 小时后
    - Send message: Email to group "ops-leader"
    - Run script: 自动化恢复流程

Step from / Step to:  步骤范围
  1 → 1:  仅步骤 1（独立执行）
  1 → 9:  步骤 1-9（连续执行）

Step duration:  单步持续时间（默认 0 = 立即执行）
  Step 1: 0 (立即)
  Step 2: 600 (10min 后)
  Step 3: 1800 (30min 后)
  ...

Operation type:
  - Send message
  - Run remote command
  - Add host to group
  - Remove host from group
  - Add to maintenance
  - Notify all involved

# 告警标题
[Zabbix] {TRIGGER.SEVERITY}: {TRIGGER.NAME} on {HOST.NAME}

# 告警内容
Trigger:    {TRIGGER.NAME}
Host:       {HOST.NAME} ({HOST.IP})
Severity:   {TRIGGER.SEVERITY}
Time:       {EVENT.DATE} {EVENT.TIME}
Value:      {ITEM.LASTVALUE}
Threshold:  {TRIGGER.EXPRESSION}
Status:     {TRIGGER.STATUS}

Event ID:   {EVENT.ID}
Ack URL:    http://zabbix.example.com/tr_events.php?triggerid={TRIGGER.ID}

Operation: Run remote command on {HOST.IP}
  Type: Custom script
  Execute on: Zabbix agent
  Commands:
    sudo /usr/local/bin/restart_service.sh {HOST.NAME}

# Zabbix Server 配置
EnableRemoteCommands=1
# Zabbix Agent 端允许远程命令
AllowKey=system.run[*]

# 危险命令禁用
DenyKey=system.run[*]
DenyKey=system.run[*]

Conditions（Action 触发条件）:
  - Trigger severity >= High
  - Host group = "Production"
  - Trigger name matches "MySQL"
  - Time period: weekday 09:00-18:00
  - Tag: Service = "payment"

Tag 作用域:
  Template tag         # 模板层，所有链接主机继承
  Host tag              # 主机层，可覆盖模板
  Trigger tag           # 触发器层，最具体
  Item tag              # 监控项层（与 LLD 配合）

Tag 命名建议:
  Service:  payment, user, order
  Env:      prod, staging, dev
  Owner:    team-a, team-b
  Component: db, cache, queue
  Severity: critical, warning, info

Action: 支付业务告警
  Conditions:
    A: Trigger severity >= High
    B: Tag "Service" matches "payment"
    C: Host group = "Production"
  Operations:
    Step 1: Send Email to group "payment-team"
    Step 2: SMS to "payment-oncall"
    Step 3: Phone to "payment-lead"

Action: 数据库告警
  Conditions:
    A: Trigger severity >= Warning
    B: Tag "Component" matches "db"
  Operations:
    Step 1: Send to "dba-team"

Action: 基础设施告警
  Conditions:
    A: Tag "Component" matches "infra|network|storage"
  Operations:
    Step 1: Send to "infra-team"

场景: 主机宕机后，MySQL、Nginx、Redis 都会告警

Action: MySQL Down
  Conditions:
    B: Tag "Service" = "mysql"
  Operations:
    Step 1: Send to dba-team

Action: 抑制规则
  Conditions:
    A: Tag "Host" = "{HOST.NAME}" AND Tag "Service" matches ".*"
    B: Trigger severity <= Average
  Operations:
    None (匹配此规则的 trigger 不发送)

→ 当 MySQL 主机已发送 PROBLEM 告警，
  同主机的其他子项告警被抑制，避免风暴

# 模板层
Template App MySQL:
  Host tag: Service=mysql, Component=database
  Trigger tag:  Severity=critical, Type=availability

# 主机层覆盖
Host: order-db-master-01:
  Tag: Env=prod, Owner=order-team, Business=order-service
  Tag: SLA=critical  # 覆盖

# Trigger 层细化
Trigger: MySQL Replication Lag
  Tag: SLA=critical, Impact=write-failover

# 告警内容模板
Host: {HOST.NAME} (IP: {HOST.IP})
Service: {EVENT.SERVICE}        # Tag "Service"
Environment: {EVENT.ENV}        # Tag "Env"
Owner: {EVENT.OWNER}            # Tag "Owner"
Component: {EVENT.COMPONENT}    # Tag "Component"

# 告警 URL
https://alert.example.com/ack?event={EVENT.ID}&service={EVENT.SERVICE}

# Proxy 配置（主动模式，推荐）
ProxyMode=0                     # 0: 主动, 1: 被动
Server=<Server IP>              # Server 地址（主动模式用）
Port=10051
Hostname=proxy-beijing
BufferSize=4096                 # 4MB 数据缓冲（越大越抗网络抖动）
ProxyLocalBuffer=0              # 本地缓冲 0=disable
ProxyOfflineBuffer=1            # 离线缓冲 1=enable（断网时保留数据）

# Proxy 配置（被动模式）
ProxyMode=1
Server=<Server IP>
Port=10051
Hostname=proxy-beijing

正常状态:
  Proxy 实时采集 → 写入本地 Buffer → 批量发送 Server

网络中断:
  Proxy 实时采集 → 写入本地 Buffer → Buffer 满 → 覆盖旧的历史（可配置）

网络恢复:
  Proxy 检测到 Server 可达 → 批量发送缓冲数据 → 触发 Server 处理
  → 历史数据补写（趋势趋势图不受影响）
  → 告警评估由 Server 同步后触发

→ BufferSize 越大，可承受的网络中断时间越长
→ Proxy 内存缓冲不影响 Agent 端的实时采集

Proxy 存储文件：
  /tmp/zabbix_proxy.db   # SQLite
  存储: 配置缓存、历史缓冲、值缓存、队列、趋势

重要:
  - Proxy 本身的元数据文件（SQLite）不是最终数据
  - Proxy 重启后重置 SQLite，不影响 Server 端已同步数据
  - Proxy 离线超过保留期后，Server 触发 Trigger "Zabbix proxy is not available"

Proxy 部署场景:
  ✔ 跨机房/跨 IDC（WAN 环境）
  ✔ 大规模环境（单 Server > 10k Host 时拆分）
  ✔ 网络隔离区域（DMZ、办公网）
  ✔ 远程分支（站点/门店）
  ✔ 需要本地触发器响应的场景

Proxy 配置建议:
  1. 每 Proxy 管理 ≤ 2000 Host（经验值）
  2. Proxy 与 Server 间带宽 ≥ 10 Mbps（批量上报）
  3. 主动模式优先（防火墙友好）
  4. BufferSize ≥ 4MB（容忍网络抖动）
  5. Proxy 配置一致性（与 Server 同版本优先）

1. 网络隔离友好：仅 Proxy 出站发起连接，Server 不需要反向可达
2. 本地缓冲：Proxy 主导数据流，断网缓冲数据不丢失
3. 自我监控：Proxy 提供内部监控项（zbx_proxy[queue,pending]）
4. 批量策略：Proxy 按批次发送，Server 端负载可控
5. 自动重连：Proxy 持续重试，Server 恢复后自动续传

Proxy 强制主动模式:
  ✔ 跨防火墙（Proxy 在 DMZ，Server 在内网）
  ✔ 分支机构（Proxy 在外地，Server 在公司）
  ✔ Server 无法直接访问 Proxy（NAT、VPN）
  ✔ 需要 Proxy 独立处理网络中断

Proxy 被动模式:
  ✔ Proxy 与 Server 同局域网
  ✔ 需要 Server 主动控制采集周期
  ✔ 需要 Server 侧精准监控 Proxy 状态
  ✔ 低延迟要求（Server 高频率拉取）

# Proxy 块参数
StartPollers=40
StartTrappers=10
HeartbeatFrequency=60           # 心跳周期（秒）
ConfigFrequency=180              # 配置同步周期（秒）
DataSenderFrequency=10           # 数据发送周期（秒）

# 数据缓冲
BufferSize=4096
TrapperTimeout=30

# 主动模式专属
Port=10051                       # 监听端口（日常用不上）

ACTIVE       # 当前主节点，正在处理业务（采集/评估/告警）
STANDBY      # 备用节点，实时同步心跳，随时准备接管
STOPPED      # 节点已停止（手动维护/故障）
ERROR        # 节点异常（配置错误、数据库连接失败）

# 1. 所有 Server 节点配置相同的数据库连接
DBHost=192.168.1.10
DBName=zabbix
DBUser=zabbix
DBPassword=xxxx

# 2. 配置 HA 节点名称和地址
HANodeName=server-01.example.com
HANodeAddress=192.168.1.101:10051

# 3. 启动多个 Server 实例
systemctl start zabbix-server@server-01
systemctl start zabbix-server@server-02
systemctl start zabbix-server@server-03

Active 节点:
  - 采集（poller/trapper/snmp/ipmi/jmx）
  - 预处理（preprocessor）
  - 触发器评估（trigger engine）
  - 告警动作（alerter/escalator）
  - 数据库同步（configuration syncer / history syncer）
  - 管理 LLD、Housekeeper

Standby 节点:
  - 不做任何采集/评估/告警
  - 仅做心跳检测 + 数据库连接保活
  - 可选开启 Web 前端但不处理采集业务
  - 所有进程无负载（除心跳进程外基本空闲）

T+0s    Active 节点宕机（进程 crash / 服务器断电）
T+5s    Standby 节点检测到 lastaccess 超时（HAFailoverDelay=5）
T+5s    Standby 节点检查其他节点
T+5s    Standby 节点升为 Active
T+5s    开始接收 Agent/Proxy 连接
T+5~10s Agent/Proxy 重连到新 Active 节点

→ 切换时间: 5-15s（取决于 HAFailoverDelay 和网络延迟）

# 查看 HA 集群状态（数据库级）
mysql -e "SELECT nodeid, name, address, status, lastaccess, ha_nodename FROM ha_node;"

# 内部监控项
zabbix_get -s 127.0.0.1 -k zabbix[ha,status]
# → 'active' | 'standby'

zabbix_get -s 127.0.0.1 -k zabbix[ha,lastaccess]
# → 当前时间戳

zabbix_get -s 127.0.0.1 -k zabbix[ha,nodename]
# → server-01.example.com

场景: HA + Proxy 混合架构
  Proxy 连接 Server HA 集群时，无需配置多个 Server IP
  Proxy 配置:
    Server=<active-server-ip>         # 推荐配置单个 Active 地址
    或用: Proxy 检测到连接的 Server 为 Standby → 自动重试

  更好的做法:
    Proxy 配置同时指定两个 Server 地址:
    Server=192.168.1.101,192.168.1.102
    但注意 Proxy 优先连接第一个可达的（不智能）

架构:
  Server_Active ← VIP: 192.168.1.10 → Agent/Proxy
      │                                   │
      │ DRBD sync                         │
  Server_Standby ← VIP 漂移              │
      │                                   │
  [DRBD Primary/Secondary]
      │
  [MySQL (独立节点)]

流程:
  1. 两台 Server 共享一个 DRBD 块设备（/dev/drbd0）
  2. DRBD Primary 挂载后启动 zabbix_server
  3. Keepalived 维护 VIP（192.168.1.10）
  4. 主节点故障 → DRBD Secondary→Primary → Keepalived VIP 漂移 → 启动 Server

缺点:
  - DRBD 同步延迟（async vs sync 模式）
  - 存储层单点故障（DRBD 本身）
  - 切换期间数据丢失（同步模式下仍可能）

架构:
  Zabbix Server A → MySQL MGR Primary
  Zabbix Server B → MySQL MGR Secondary（Read-Only）
  
  VIP / DNS:
    Server A 关联 VIP
    VIP 切换时 B 接管
  
流程:
  1. MySQL MGR 提供高可用数据库
  2. Server A 正常连接数据库 Primary
  3. Server A 故障 → VIP 漂移到 B
  4. Server B 连接 MySQL MGR Primary（自动切换读/写）

优势:
  - 数据库自动容灾（MGR 自动选主）
  - Server 层轻量（无共享存储）
  - MySQL MGR 本身是 Zabbix 推荐的方案之一

架构:
  多 Proxy 并行（非 HA，而是负载分担）:
  Proxy_A (Beijing) — 10,000 Host
  Proxy_B (Shanghai) — 8,000 Host
  Proxy_C (Guangzhou) — 5,000 Host
  Proxy_D (Hangzhou) — 3,000 Host
  
HA Proxy:
  双 Proxy 同区域:
  Proxy_A1 (Active) — Agent/SNMP 采集
  Proxy_A2 (Standby) — 本地区域备用
  → Agent 配置同时指定两个 Proxy

此方案不是 Server HA，而是 Proxy 层级的高可用
可降低 Server 单点故障风险

推荐架构：
  Zabbix HA Cluster (3 节点)
    ├─ Server-A (Active)
    ├─ Server-B (Standby)
    └─ Server-C (Standby)
  
  MySQL InnoDB Cluster / PostgreSQL Patroni
  ├─ DB-Primary (Read/Write)
  ├─ DB-Replica1 (Read-Only)
  └─ DB-Replica2 (Read-Only)
  
  Web Frontend × N (可多实例)
  
  Proxy × N (按区域)
  
优势:
  - Server 层 5-15s 自动切换
  - 数据库层自动故障转移
  - Web 层无状态，前端可任意分布
  - 无共享存储、无 DRBD 引入的单点

是否需要 Server HA?
├─ Zabbix 6.0+ → 原生 HA（推荐）
└─ Zabbix < 6.0
   ├─ 已有 DRBD 基础设施 → DRBD + Keepalived
   └─ 无 DRBD
      ├─ 可升级 → 升级 6.0+ 原生 HA
      └─ 不可升级
         ├─ 数据库已 HA → 双 Server + VIP + 数据库切换
         └─ 数据库无 HA → Proxy 分担 + 单 Server 容错

TimescaleDB 关键能力:
  1. 自动分区（Chunk）
     CREATE TABLE history (…) → SELECT create_hypertable('history','clock')
     → 按天/小时/分钟自动分 Chunk，不需要手工维护分区

  2. 原生压缩
     空间压缩: 5-15x（housekeeping 前）
     时间压缩: 自动（job 定时运行）
     再分区 + 按时间聚合 → 查询仍高效

  3. 连续聚合
     类似物化视图 + 自动刷新
     大幅提升长周期趋势图/报表性能

  4. 列式存储（超表）
     Chunk 内部按列存储（压缩友好）
     历史查询只需扫描相关列

-- Zabbix 数据库初始化（PostgreSQL + TimescaleDB）
-- create database
CREATE DATABASE zabbix WITH TEMPLATE template0;

-- 启用 TimescaleDB 扩展
CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;

-- 历史表转为超表
SELECT create_hypertable('history', 'clock',
    chunk_time_interval => 86400);        -- 1 天一个 Chunk
SELECT create_hypertable('history_uint', 'clock',
    chunk_time_interval => 86400);
SELECT create_hypertable('history_str', 'clock',
    chunk_time_interval => 86400);
SELECT create_hypertable('history_log', 'clock',
    chunk_time_interval => 86400);
SELECT create_hypertable('history_text', 'clock',
    chunk_time_interval => 86400);
SELECT create_hypertable('trends', 'clock',
    chunk_time_interval => 86400);
SELECT create_hypertable('trends_uint', 'clock',
    chunk_time_interval => 86400);

-- 压缩策略（存储优化）
SELECT add_compression_policy('history',  INTERVAL '7 days');
SELECT add_compression_policy('history_uint', INTERVAL '7 days');
SELECT add_compression_policy('history_str',  INTERVAL '7 days');
SELECT add_compression_policy('history_log',  INTERVAL '7 days');
SELECT add_compression_policy('history_text', INTERVAL '7 days');

-- MySQL 分区（Zabbix 4.x-5.x 常用）
ALTER TABLE `history`
  PARTITION BY RANGE (clock) (
    PARTITION p202601 VALUES LESS THAN (UNIX_TIMESTAMP('2026-02-01 00:00:00')),
    PARTITION p202602 VALUES LESS THAN (UNIX_TIMESTAMP('2026-03-01 00:00:00')),
    PARTITION p202603 VALUES LESS THAN (UNIX_TIMESTAMP('2026-04-01 00:00:00')),
    PARTITION p202604 VALUES LESS THAN (UNIX_TIMESTAMP('2026-05-01 00:00:00')),
    PARTITION p202605 VALUES LESS THAN (UNIX_TIMESTAMP('2026-06-01 00:00:00')),
    PARTITION p202606 VALUES LESS THAN (UNIX_TIMESTAMP('2026-07-01 00:00:00')),
    PARTITION p_future VALUES LESS THAN MAXVALUE
  );

场景 → 推荐
  ← 3,000 NVPS   → MySQL（够用且运维最轻）
  3k-10k NVPS    → PostgreSQL（性能强于 MySQL）
  ≥ 10k NVPS     → TimescaleDB（压缩 + Chunk 自动分区）
  NVPS 极高      → TimescaleDB + 多 Proxy 分担采集

增量迁移:
  MySQL 可在线迁移到 TimescaleDB（pgloader 工具有支持）
  迁移后 Housekeeper 策略改为压缩策略，磁盘节省 5-10x

# Web UI → Administration → General → Housekeeper
Housekeeping frequency:        1        (小时)
Trigger data storage period:  365
Internal events:              365
Network discovery events:     30
Auto-registration events:     30

# Item 级保留期（每个 Item 可单独设置）
Item:
  History storage period: 7d-90d
  Trends storage period:  365d

# 全局保留期（Item 未设置时使用）
History retention:         14d
Trends retention:          365d

问题: Housekeeper 在大表上执行 DELETE 大量数据时：
  - 表锁定/行锁定（MySQL InnoDB 需小心死锁）
  - INSERT 被阻塞（写入 history 表会锁等待）
  - 触发器评估延迟（历史数据被锁定）
  - Event 表 DELETE 影响 event 处理

建议:
  - MySQL: 禁用内置 Housekeeper，改用外部 Cron 分区 Drop/Truncate
  - PostgreSQL: 可启用内置（并行 DELETE 较友好）
  - TimescaleDB: 内置压缩 + Chunk drop（压缩后数据自动过期）

-- 每月 1 日凌晨  将过期分区直接 DROP（极快）
-- 代替 DELETE，秒级完成（DROP TABLE 是 DDL，无锁）

ALTER TABLE `history` DROP PARTITION p20260401;
ALTER TABLE `history` DROP PARTITION p20260402;
-- ...

-- Zabbix 配置：禁用内置 Housekeeper 的历史表删除
HousekeepingFrequency=0            # 关闭内置 Housekeeper

-- TimescaleDB 策略：保留 30 天后自动删除 Chunk
SELECT add_retention_policy('history', INTERVAL '30 days');
SELECT add_retention_policy('history_uint', INTERVAL '30 days');

-- 配合压缩：7 天后自动压缩
SELECT add_compression_policy('history', INTERVAL '7 days');

-- 最佳实践：压缩 7d + 保留 30d → 磁盘节省 80%

#!/bin/bash
# /usr/local/bin/zbx_housekeeper.sh
# cron: 0 2 * * * /usr/local/bin/zbx_housekeeper.sh

DB_USER=zabbix
DB_PASS=xxxx
DB_NAME=zabbix

# 删除 90 天前的 history_uint
echo "DELETE FROM history_uint WHERE clock < UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL 90 DAY)) LIMIT 100000;" | \
  mysql -u$DB_USER -p$DB_PASS $DB_NAME &

# 内部监控项检查 Housekeeper 状态
zabbix_get -s 127.0.0.1 -k zabbix[housekeeping,start_time]      # 上次清理时间
zabbix_get -s 127.0.0.1 -k zabbix[housekeeping,count]            # 本次清理行数
zabbix_get -s 127.0.0.1 -k zabbix[housekeeping,duration]         # 清理耗时(ms)
zabbix_get -s 127.0.0.1 -k zabbix[process,housekeeper,avg,busy] # Housekeeper 负载

NVPS = SUM( 所有 Item 数 / 采集间隔)

例:
  Item 类型            Item 数    采集间隔(s)    NVPS
  Internet/Agent         800          60          13.3
  SNMP                    200         300         0.7
  Trapper                  50           -         10
  Active Agent           1200          60          20.0
  LLD                       5        3600         0.0
  Web Scenario             10         120          0.08
  ------
  总计:                  2265 Item                ~44 NVPS

  → 一台 Server 可承载数千 NVPS（经验值 2,000-10,000）
  → >10,000 NVPS 需 Proxy 分发和 TimescaleDB

# 队列深度（主要指标）
zabbix_get -s 127.0.0.1 -k zabbix[queue]                       # 总队列
zabbix_get -s 127.0.0.1 -k zabbix[queue,5m]                    # 5 分钟以上延迟
zabbix_get -s 127.0.0.1 -k 'zabbix[queue,proxy,5m,beijing]'    # 特指 Proxy

# 进程负载
zabbix_get -s 127.0.0.1 -k zabbix[process,poller,avg,busy]     # poller 忙率
zabbix_get -s 127.0.0.1 -k zabbix[process,trapper,avg,busy]
zabbix_get -s 127.0.0.1 -k zabbix[process,historysyncer,avg,busy]
zabbix_get -s 127.0.0.1 -k zabbix[process,preprocessor,avg,busy]

# Cache 命中
zabbix_get -s 127.0.0.1 -k zabbix[cache,buffer,history]         # 历史缓存使用率
zabbix_get -s 127.0.0.1 -k zabbix[cache,buffer,value]           # 值缓存
zabbix_get -s 127.0.0.1 -k zabbix[cache,buffer,historyindex]   # 索引缓存

# 数据库相关
zabbix_get -s 127.0.0.1 -k zabbix[db,wait_time]                 # DB 等待时间
zabbix_get -s 127.0.0.1 -k zabbix[db,query,insert,history]      # 插入次数

# 高性能配置（假设 10,000 NVPS）
StartPollers=80
StartTrappers=40
StartPingers=5
StartHTTPPollers=20
StartSNMPPollers=20
StartIPMIPollers=5
StartJMXPollers=10
StartLLD=10
StartPreprocessors=20
StartAlerters=10
StartEscalators=10

# Cache 调大
HistoryCacheSize=512M
HistoryIndexCacheSize=128M
TrendCacheSize=256M
ValueCacheSize=512M

# 数据库相关
CacheUpdateFrequency=60
MaxHousekeeperDelete=50000
HistorySyncer=10
TrendFunctionCacheSize=8M
HistoryCacheSetSize=128M

# 超时
Timeout=3
SNMPTimeout=1
TrapperTimeout=30

# 系统参数
kernel.shmmax = 68719476736       # 64GB 共享内存
kernel.sem = 250 32000 100 256    # 信号量（Zabbix 多进程要求）

# 数据库（MySQL）
innodb_buffer_pool_size = 16G     # 总内存 50-70%
innodb_io_capacity = 2000          # SSD
innodb_log_file_size = 2G
innodb_flush_log_at_trx_commit = 2 # 允许 1s 数据丢失提升写入性能

Zabbix 6.0:
  Agent 主动模式：每次采集周期 (60s) 建立新连接 → 断开
  Agent A（5000 host）→ Server: 5000次连接建立/60s ≈ 83次/秒 TCP

Zabbix 7.x:
  Agent 2 主动模式：建立长连接，复用
  Agent A（5000 host）→ Server: 2-5个持久 TCP 连接 → 多路复用
  → 减少 Server 端 TCP 状态表压力
  → 减少 Agent 端 fork/exec 开销（Agent 2）

Zabbix 6.0: 预处理 → poller → 同步等待（polling + preprocessing 串行）
Zabbix 7.x: 预处理 → 异步队列 → preprocessor 空闲进程独立执行

↓ 影响：
  NVPS: +30-80%（预处理密集场景提升最明显）
  CPU 利用率：preprocessor 进程不再与 poller 绑定，可独立控制

# Zabbix 7.x Server 配置
DBCacheSize=32M              # 数据库连接池大小（共用的连接状态缓存）
DBMaxPoolSize=100            # 连接池最大连接数
DBPoolIdleSize=64            # 连接池空闲保持数
DBPoolCheckTimeout=300       # 空闲连接回收时间

↓ 影响：
  高并发: 连接池降低建连开销
  慢查询: 池化连接减少等待
  Proxy: 受益尤甚（频繁连接/断开历史模式）

场景: 10,000 Host × 200 Item = 2,000,000 Item × 60s ≈ 33,333 NVPS

Zabbix 6.0 LTS:
  Server 进程: 100 (poller) + 50 (trapper) + 30 (preprocessor) + ...
  Server 内存: 16-24 GB
  DB: TimescaleDB, 4 核 32G

Zabbix 7.x:
  Server 进程: 60 (poller) + 40 (trapper) + 10 (preprocessor) + ...
  Server 内存: 12-16 GB
  DB: TimescaleDB, 4 核 32G

↓ 提升:
  同 NVPS 下减少 30-50% 进程数
  内存减少 20-40%
  Agent 连接数减少 80%+（持久连接）

重要:
  - Agent 2 需升级到 7.x 版本才能使用持久连接
  - PHP 版本必须 ≥ 8.2
  - 数据库 schema 需要迁移（Zabbix 7.0 有额外表结构变更）
  - 旧版 C-Agent 仍可用，但无法享受持久连接优化
  - Proxy 需与 Server 同版本（向下兼容到 6.0 有限）

# 认证
curl -X POST http://zabbix.example.com/api_jsonrpc.php \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "user.login",
    "params": {"user": "Admin", "password": "zabbix"},
    "id": 1
  }'
# 返回: {"result":"auth_token_xxxx","id":1}

# 后续所有请求携带 auth
AUTH="auth_token_xxxx"

# 场景 1: 批量创建主机
curl -X POST http://zabbix.example.com/api_jsonrpc.php \
  -H "Content-Type: application/json" \
  -d "{
    \"jsonrpc\": \"2.0\",
    \"method\": \"host.create\",
    \"params\": {
      \"host\": \"web-01\",
      \"interfaces\": [
        {\"type\": 1, \"main\": 1, \"useip\": 1, \"ip\": \"10.0.0.1\", \"dns\": \"\", \"port\": \"10050\"}
      ],
      \"groups\": [{\"groupid\": \"5\"}],
      \"templates\": [{\"templateid\": \"10001\"},{\"templateid\": \"10234\"}],
      \"macros\": [
        {\"macro\": \"{$SSH_PORT}\", \"value\": \"22\"}
      ]
    },
    \"auth\": \"$AUTH\",
    \"id\": 2
  }"

# 场景 2: 获取主机 ID 和状态
curl -X POST http://zabbix.example.com/api_jsonrpc.php \
  -H "Content-Type: application/json" \
  -d "{
    \"jsonrpc\": \"2.0\",
    \"method\": \"host.get\",
    \"params\": {
      \"output\": [\"hostid\",\"host\",\"status\"],
      \"filter\": {\"host\": [\"web-01\",\"web-02\"],\"status\": [0]}
    },
    \"auth\": \"$AUTH\",
    \"id\": 3
  }"

# 场景 3: 批量更新主机宏
curl -X POST http://zabbix.example.com/api_jsonrpc.php \
  -H "Content-Type: application/json" \
  -d "{
    \"jsonrpc\": \"2.0\",
    \"method\": \"host.update\",
    \"params\": {
      \"hostid\": \"10234\",
      \"macros\": [
        {\"macro\": \"{$DISK.WARN}\", \"value\": \"85\"}
      ]
    },
    \"auth\": \"$AUTH\",
    \"id\": 4
  }"

# 场景 4: 获取告警事件并确认
curl -X POST http://zabbix.example.com/api_jsonrpc.php \
  -H "Content-Type: application/json" \
  -d "{
    \"jsonrpc\": \"2.0\",
    \"method\": \"event.get\",
    \"params\": {
      \"output\": \"extend\",
      \"severities\": [4,5],
      \"time_from\": \"$(date -d '1 hour ago' +%s)\",
      \"acknowledged\": false
    },
    \"auth\": \"$AUTH\",
    \"id\": 5
  }"

# pip install py-zabbix
from pyzabbix import ZabbixAPI

zapi = ZabbixAPI('http://zabbix.example.com')
zapi.login('Admin', 'zabbix')

# 查询所有激活的主机
hosts = zapi.host.get(output=['hostid', 'host'],
                       filter={'status': 0})
print(f"总激活主机数：{len(hosts)}")

# 批量创建主机
for ip, hostname in cmdb_hosts.items():
    zapi.host.create(
        host=hostname,
        interfaces=[
            {'type': 1, 'main': 1, 'useip': 1, 'ip': ip, 'port': '10050'}
        ],
        groups=[{'groupid': group_id}],
        templates=[{'templateid': tmpl_id}],
        macros=[{'macro': '{$ENV}', 'value': 'prod'}]
    )
    print(f"创建主机 {hostname} ({ip})")

# 批量创建维护期
zapi.maintenance.create(
    name=f"升级维护 {date}",
    hostids=[host_id],
    timeperiods=[
        {'timeperiod_type': 0,
         'start_date': start_ts,
         'period': 3600}  # 1 hour
    ],
    tags_evaltype=0,
    tags=[{'tag': 'source', 'value': 'deploy'}]
)

1. 认证复用: 只 login 一次，auth token 有效期内复用
2. 批量操作: 每次 API 调用可包含多个对象，减少 HTTP 开销
3. 幂等性: host.create → host.get 先检查再 create（防止重复）
4. 错误处理: JSON-RPC 返回 error 时捕获并重试
5. 限速: 单脚本每秒 < 10-20 次 API 调用（Server 端有保护）
6. 配置备份: 定期 configuration.export → Git 仓库（Zabbix 模板版本管理）
7. 与 CMDB 集成: Ansible/Terraform 调用 Zabbix API 自动化主机创建

# 1. 生成 PSK Key
openssl rand -hex 32 > /etc/zabbix/psk.key

# 2. Server 配置
# /etc/zabbix/zabbix_server.conf
TLSConnect=psk
TLSAccept=psk
TLSPSKIdentity=Server1
TLSPSKFile=/etc/zabbix/psk.key

# 3. Agent 配置
# /etc/zabbix/zabbix_agentd.conf
TLSConnect=psk
TLSAccept=psk
TLSPSKIdentity=Agent1
TLSPSKFile=/etc/zabbix/agent_psk.key

# 4. Web UI → Host → Encryption
# 每个主机配置 PSK Identity 和 PSK key
  
# 5. 验证
zabbix_get -s 127.0.0.1 -k agent.ping --tls-connect psk \
  --tls-psk-identity "Server1" --tls-psk-file /etc/zabbix/psk.key

# /etc/zabbix/zabbix_agentd.conf

# 关键：拒绝危险 Key
DenyKey=system.run[*]
AllowKey=system.run[uptime]

# 或者只允许指定 Key（白名单模式推荐）
# AllowKey 优先于 DenyKey
AllowKey=system.run[*]            # 默认禁止
AllowKey=agent.ping
AllowKey=system.hostname
AllowKey=system.cpu.util[*]
AllowKey=system.uname
AllowKey=net.if.discovery
AllowKey=vfs.fs.discovery

# UserParameter 沙箱化
# 不要在 UserParameter 中调用未验证的输入
# 使用 sudo 限制执行用户
AllowRoot=0                       # 禁止 root 执行远程命令
EnableRemoteCommands=0             # 禁止远程命令（默认）

-- Zabbix 数据库用户最小权限
CREATE USER 'zabbix'@'%' IDENTIFIED BY 'strong_password_xxxx';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER, INDEX, REFERENCES
  ON zabbix.* TO 'zabbix'@'%';
-- 注意：Zabbix DBSchema 迁移需要额外权限（如 ALTER TABLE）
-- 但日常运行时不需要 CREATE/DROP/ALTER→可去掉

-- 只读报表用户
CREATE USER 'zabbix_read'@'%' IDENTIFIED BY 'report_password';
GRANT SELECT ON zabbix.* TO 'zabbix_read'@'%';

# Nginx 反向代理
server {
  listen 443 ssl http2;
  server_name zabbix.example.com;
  
  ssl_certificate /etc/ssl/zabbix.crt;
  ssl_certificate_key /etc/ssl/zabbix.key;
  
  # 仅允许内网 IP
  allow 10.0.0.0/8;
  allow 192.168.0.0/16;
  deny all;
  
  # CSP 增强
  add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data:;";
  
  # 禁用目录列表
  autoindex off;
  
  location / {
    proxy_pass http://127.0.0.1:80;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
  }
}

# PHP 安全配置
session.cookie_httponly = 1
session.cookie_secure = 1
session.use_strict_mode = 1

# Web UI → Administration → API Tokens
# 优点：API Token 比密码更安全（可设置过期、权限范围）

# API Token 使用：
curl -X POST http://zabbix.example.com/api_jsonrpc.php \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer api_token_xxxx" \            ← Bearer token
  -d '{...}'

# API Rate Limiting
# Zabbix 默认没有速率限制，可 Nginx 层实现
limit_req_zone $binary_remote_addr zone=zabbix_api:10m rate=10r/s;

Maintenance: 云环境变更窗口
  - 变更期间自动关闭告警（不产生事件）
  - 维护期过后自动恢复
  - 支持周期性维护期（如每月补丁维护）

创建方式:
  - API: maintenance.create
  - 脚本: zabbix_maintenance.py
  - Web UI: Configuration → Maintenance

是否需要监控以下设备:
├─ 物理服务器（温度/IPMI/传感器） → Zabbix（最成熟）
├─ 网络设备（SNMP）               → Zabbix（原生支持）
├─ 数据库/中间件                  → Zabbix 或 Prometheus Exporter
├─ Kubernetes/容器                → Prometheus（标准方案）
├─ 云原生微服务/Service Mesh      → Prometheus + Grafana Tempo
└─ 业务自定义指标                  → Prometheus Client 库

是否已有 Zabbix 基础设施:
├─ 已有 5000+ 监控项               → 扩展 Zabbix 部署
├─ 全面 K8s 化                     → 逐步引入 Prometheus
└─ 混合架构                         → Zabbix（传统层）+ Prometheus（云原生）

团队技能:
├─ 熟悉 PHP/MySQL                  → Zabbix 运维友好
├─ 熟悉 Go/Linux                   → Prometheus 运维友好
└─ 两者兼备                         → 混合架构：统一 Grafana 前端

Grafana → 统一仪表盘入口

数据源一： Zabbix (Zabbix Data Source Plugin)
  - 接入 Zabbix 历史/趋势数据
  - 查询 Zabbix 对象模型（host/group/template）
  - 通过 Zabbix API 获取告警事件

数据源二： Prometheus / Thanos
  - 用 PromQL 查询多维指标
  - Service 级指标聚合展示

数据源三： Loki
  - 日志搜索与面板关联

架构示例:
  Grafana Dashboard:
    ├─ Panel 1: 物理服务器 → Zabbix
    ├─ Panel 2: K8s → Prometheus
    ├─ Panel 3: 日志 → Loki
    └─ Panel 4: 告警 → Alertmanager

推荐架构（中大规模）:
  
  传统层（Zabbix）:
    Zabbix Server HA (3 节点)
    Zabbix Proxy × N (按区域)
    Agent 2 (Linux/Windows)
    SNMP 轮询 (网络设备)
    IPMI (硬件健康)
  
  云原生层（Prometheus + VictoriaMetrics）:
    Prometheus Operator (K8s 监控)
    VictoriaMetrics (长期存储)
    Prometheus AlertManager (告警)
  
  观测性层（Grafana + Loki + Tempo）:
    Grafana (统一仪表盘)
    Zabbix Datasource Plugin
    Prometheus Datasource
    Loki (日志)
    Tempo (分布式追踪)
  
  统一告警:
    PagerDuty / Opsgenie
    Zabbix Action → Webhook → PagerDuty
    Alertmanager → Webhook → PagerDuty

现象:
  - zabbix_server 运行但无响应
  - 队列堆积（zabbix[queue] > 1000）
  - Agent 连接超时

排查:
  # 1. 检查进程负载
  zabbix_get -s 127.0.0.1 -k zabbix[process,poller,avg,busy]
  zabbix_get -s 127.0.0.1 -k zabbix[process,trapper,avg,busy]

  # 2. 检查 Server 日志
  tail -100 /var/log/zabbix/zabbix_server.log | grep -i error

  # 3. 检查 DB 连接
  zabbix_get -s 127.0.0.1 -k zabbix[db,wait_time]

  # 4. 检查 Cache 使用率
  zabbix_get -s 127.0.0.1 -k zabbix[cache,buffer,history]

修复:
  - 调大 HistoryCacheSize / ValueCacheSize
  - 增加 HistorySyncer 数量
  - 检查慢查询（DB 层）
  - 如果是 Housekeeper 阻塞：停止 Housekeeper + 手动分区 Drop

现象:
  - history_syncer 进程繁忙 > 75%
  - DB wait_time 高
  - history/trends 插入延迟（INSERT backlog）
  - Server 日志出现 "lost X values"

排查:
  # 1. 检查慢查询
  # MySQL
  SHOW FULL PROCESSLIST;
  SHOW GLOBAL STATUS LIKE 'Innodb_row_lock%';
  
  # 2. 检查数据库 I/O
  iostat -x 1 | grep -E 'sda|nvme'
  iotop -oP

  # 3. 检查 history 表大小
  SELECT table_name, table_rows, ROUND(data_length/1024/1024,2) size_mb
  FROM information_schema.tables
  WHERE table_schema = 'zabbix';

修复:
  - 增大 HistorySyncer / HistoryCacheSize
  - 切换到 TimescaleDB（原生分区 + 压缩）
  - 关闭内置 Housekeeper（用分区 Drop 代替）
  - 增加 DB 并发写入（innodb_io_capacity）

现象:
  - Trigger: agent.ping.nodata(300)=1
  - Item 显示 No value
  - zabbix_get 连接超时

排查:
  # Server 端
  zabbix_get -s 192.168.1.10 -k agent.ping -p 10050
  # 返回: ZBX_TCP_READ() timed out

  # Agent 端
  systemctl status zabbix-agent
  zabbix_agentd -t agent.ping

  # 网络检查
  tcpdump -i eth0 port 10050 -c 5

常见原因:
  1. Agent 配置错误（Server IP 不对）
  2. 防火墙阻挡（iptables/nftables/安全组）
  3. Agent 端口被占用（多个 Agent 进程冲突）
  4. 超时太短（Timeout < Agent 响应时间）
  5. TLS/PSK 配置不匹配
  6. 主机名不匹配（Hostname / HostnameItem）

修复:
  - 检查 /etc/zabbix/zabbix_agentd.conf
  - 检查防火墙: nc -zv 192.168.1.10 10050
  - 增加 Timeout = 5 (Server 和 Agent 都改)
  - 验证 TLS 配置：tls-connect / tls-accept 匹配

现象:
  - Proxy 状态显示 Not available
  - 该区域监控数据全部停止
  - Trigger: "Zabbix proxy is not available"

排查:
  # 1. 检查 Proxy 进程
  systemctl status zabbix-proxy
  tail -100 /var/log/zabbix/zabbix_proxy.log

  # 2. 检查网络
  telnet <Server IP> 10051
  
  # 3. Proxy 配置
  grep -E '^(Server|Hostname|BufferSize|ConfigFrequency|DataSenderFrequency)' \
    /etc/zabbix/zabbix_proxy.conf

  # 4. 检查 Proxy 缓冲文件
  ls -lh /tmp/zabbix_proxy.db

修复:
  - 重启 Proxy: systemctl restart zabbix-proxy
  - 检查 Proxy 与 Server 版本兼容性
  - 增大 BufferSize（网络不稳定场景）
  - 调整 DataSenderFrequency（减小 = 更频繁上报）

现象:
  - 历史数据时间错位
  - 触发器评估异常（某些函数依赖 clock 排序）
  - 趋势图显示异常

排查:
  # 所有机器（Server/Agent/Proxy/DB）
  timedatectl status
  ntpq -pn
  chronyc tracking

常见原因:
  - NTP 服务未安装或未配置
  - 虚拟机时钟漂移（尤其是 VMotion 后）
  - 硬件 RTC 与系统时间偏差

修复:
  - 配置统一的 NTP 源
  - 启用 chrony / ntpd
  - VM 场景启用 KVM clock=kvm
  - 验证: ntpdate -q pool.ntp.org

现象:
  - Dashboard 页面加载 > 10s
  - PHP 报错（`PHP Fatal error: Allowed memory size exhausted`）
  - PHP/DB 连接超时

排查:
  # PHP 配置
  php -i | grep memory_limit    # 应 ≥ 256M
  php -i | grep max_execution_time  # 应 ≥ 300

  # 慢查询
  tail -100 /var/log/mysql/slow-query.log

修复:
  - PHP memory_limit = 256M-512M
  - PHP max_execution_time = 300
  - PHP post_max_size = 32M
  - 开启 PHP OPcache
  - 检查 Web 前端与 Server 版本一致
  - Dashboard 减少历史数据量（增加时间范围限制）

# Server 状态
systemctl status zabbix-server

# 获取内部指标
zabbix_get -s 127.0.0.1 -k zabbix[queue]
zabbix_get -s 127.0.0.1 -k 'zabbix[queue,5m]'

# 进程负载
zabbix_get -s 127.0.0.1 -k 'zabbix[process,poller,avg,busy]'

# 主动模式测试
zabbix_sender -z 127.0.0.1 -s "test-host" -k test.key -o 1

# 日志
journalctl -u zabbix-server -n 200 --no-pager
tail -f /var/log/zabbix/zabbix_server.log

# 数据库检查
mysql -e "SELECT COUNT(*) FROM proxy_history;"
mysql -e "SHOW ENGINE INNODB STATUS\G" | grep -A5 "HISTORY LIST"

# Housekeeper 监控
zabbix_get -s 127.0.0.1 -k zabbix[housekeeping,start_time]
zabbix_get -s 127.0.0.1 -k zabbix[housekeeping,count]