2、告警源接入：Prometheus告警接入、Zabbix告警接入、云平台告警接入（AWS/Azure/阿里云）、自定义应用告警接入

告警源接入，说白了就是让我们的告警平台能听懂各个监控系统在说什么。我见过不少团队，监控工具装了一大堆，结果告警还是靠人工盯屏幕——这其实就失去了自动化的意义。

今天咱们聊聊四种最常见的告警源接入方式。每种我都踩过坑，希望能帮你少走弯路。

2.1 Prometheus 告警接入

Prometheus 现在几乎是云原生监控的事实标准。它的告警机制核心是 Alertmanager，我们通常通过 Webhook 把告警转发出来。

接入方式：配置 Alertmanager 的 webhook_configs，指向我们的告警接收端点。

# alertmanager.yml 配置片段
receivers:
- name: 'my-webhook'
  webhook_configs:
  - url: 'http://your-alert-platform:8080/api/v1/alerts'
    send_resolved: true

我个人习惯在 Prometheus 的告警规则里加上足够的标签。为什么呢？因为标签是后续路由和去重的关键。

我在项目中遇到过一个问题：告警恢复事件没被正确处理，导致告警一直挂着不消失。后来发现是 send_resolved 没开。嗯，这个小参数坑了不少人。

2.2 Zabbix 告警接入

Zabbix 在传统运维领域根基很深。它的告警接入方式比较灵活，我推荐用脚本方式。

接入方式：配置 Zabbix 的 Action，调用自定义脚本发送告警。

# zabbix_alert.sh 示例
#!/bin/bash
ALERT_SUBJECT="$1"
ALERT_BODY="$2"

curl -X POST http://your-alert-platform:8080/api/v1/alerts \
  -H "Content-Type: application/json" \
  -d '{
    "source": "zabbix",
    "subject": "'"$ALERT_SUBJECT"'",
    "body": "'"$ALERT_BODY"'",
    "timestamp": "'$(date +%s)'"
  }'

我曾经遇到过一个坑：Zabbix 脚本执行超时导致告警丢失。默认脚本执行超时是 30 秒，如果你的告警平台响应慢，记得调大这个值。

2.3 云平台告警接入

云平台的告警接入，说白了就是通过云厂商的 API 或事件总线来接收。AWS、Azure、阿里云各有各的玩法，但思路是相通的。

AWS CloudWatch 告警

AWS 推荐用 SNS 转发告警。我们订阅 SNS Topic，通过 HTTPS 端点接收。

# AWS SNS 订阅示例（Python）
import json
import requests

def lambda_handler(event, context):
    # 解析 SNS 消息
    sns_message = json.loads(event['Records'][0]['Sns']['Message'])
    
    # 构造告警数据
    alert = {
        'source': 'aws_cloudwatch',
        'alarm_name': sns_message['AlarmName'],
        'new_state': sns_message['NewStateValue'],
        'reason': sns_message['NewStateReason'],
        'region': sns_message['Region']
    }
    
    # 转发到告警平台
    requests.post('http://your-alert-platform:8080/api/v1/alerts', json=alert)

Azure Monitor 告警

Azure 使用 Action Group 的 Webhook 动作。配置时注意认证方式，我建议用 Azure AD 认证，更安全。

阿里云告警

阿里云通过云监控的报警回调功能。配置一个 HTTP 地址即可，支持 POST 请求。

我记得有一次，阿里云的一个磁盘告警每分钟发一次，持续了整整一天。我们的告警平台差点被打挂。后来加了滑动窗口去重，才解决问题。

2.4 自定义应用告警接入

自定义应用告警，说白了就是让业务系统自己报故障。这是最灵活的方式，但也最容易出乱子。

接入方式：应用通过 HTTP API 直接推送告警。

# 自定义告警推送示例（Python）
import requests
import json

def send_alert(alert_data):
    """
    alert_data 格式：
    {
        "title": "订单服务超时",
        "level": "critical",
        "service": "order-service",
        "detail": "接口响应时间超过5秒",
        "timestamp": 1234567890
    }
    """
    response = requests.post(
        'http://your-alert-platform:8080/api/v1/custom-alerts',
        json=alert_data,
        headers={'Authorization': 'Bearer your-token'}
    )
    return response.status_code

我在项目中遇到过最离谱的事：某个开发团队直接把日志文件的内容当告警发过来，一次好几兆。你想想看，这哪是告警，分明是 DDoS 攻击。后来我们限制了 payload 大小，超过 10KB 直接丢弃。

2.5 接入后的统一处理

不管哪种告警源接入，最终都要做几件事：

• 格式统一：把不同源的告警转成统一的数据模型
• 去重：相同告警在短时间内只处理一次
• 路由：根据告警级别、服务归属，分发给不同的人或群组
• 归档：所有告警都要存下来，方便事后复盘

告警源接入这件事，说白了就是建管道。管道建好了，水才能流得顺畅。下一章咱们聊聊告警的标准化处理，让这些告警真正变成可执行的行动指令。