HermesAgent监控告警：Prometheus配置

一、确认HermesAgent暴露指标端点

要让Prometheus成功抓取数据，第一步是确认源头是否畅通。HermesAgent必须通过HTTP协议，暴露一个符合Prometheus文本格式的指标端点（通常是 /metrics）。这个端点返回的应该是纯文本，每行清晰地展示指标名、标签、数值和时间戳。记住，Prometheus采用的是主动拉取（Pull）模式，所以这个端点必须可被访问且格式完全合规。

具体怎么验证呢？可以分三步走：

1. 使用一条简单的curl命令，看看端点能否返回内容：curl -s http://:/metrics | head -20

2. 检查返回的内容中，是否包含类似 hermes_agent_up 1 或 hermes_agent_http_request_total{method="POST",status="200"} 42 这样的有效指标行。

3. 如果遇到404、返回空白或者格式不对，那就需要回头检查HermesAgent的配置，确保其Metrics端点已启用，并且对应的监听地址和端口没有被防火墙拦截。

二、在prometheus.yml中添加抓取任务

源头没问题了，接下来就得告诉Prometheus去哪儿抓。这需要通过配置“抓取任务”（scrape_config）来实现。关键点在于：job_name要唯一，目标地址（targets）要准确，metrics_path要和HermesAgent暴露的路径一致，协议（scheme）也要匹配。

操作流程很直接：

1. 打开Prometheus的主配置文件 prometheus.yml。

2. 在 scrape_configs 部分，添加一个新的任务块。下面是一个模板，记得把 和 替换成实际值：

  - job_name: 'hermes-agent'
    static_configs:
    - targets: [':']
    metrics_path: '/metrics'
    scheme: http

3. 保存配置文件后，需要让Prometheus重新加载配置。可以给Prometheus进程发送SIGHUP信号，或者更简单地，调用它的reload接口：curl -X POST http://localhost:9090/-/reload。

4. 最后，打开Prometheus的Web UI（通常是 http://:9090），导航到 Status → Targets 页面。找到名为“hermes-agent”的任务，确认其状态是 UP，并且“Last Scrape”时间是最新的，这就表示配置成功了。

三、配置HermesAgent专属告警规则

数据抓取上来，监控的骨架就有了，但还得有“神经”来感知异常。这就是告警规则的作用。规则需要基于HermesAgent特有的指标（比如服务状态、队列长度、请求耗时等）来定义，并且最好独立存放，方便管理。

配置告警规则可以遵循以下步骤：

1. 创建一个独立的告警规则文件，例如 /etc/prometheus/rules/hermes_alerts.yml。

2. 在这个文件里定义规则组。这里给一个实例，当HermesAgent服务下线时触发告警：

groups:
- name: hermes-agent-alerts
  rules:
  - alert: HermesAgentDown
    expr: up{job="hermes-agent"} == 0
    for: 2m
    labels:
      severity: critical
    annotations:
      summary: "HermesAgent instance is down"
      description: "HermesAgent at {{ $labels.instance }} has been unreachable for more than 2 minutes"

3. 光有规则文件还不够，需要在 prometheus.yml 中声明它。在global配置段下方，添加或修改 rule_files 配置项，指向刚才创建的文件：

rule_files:
  - "/etc/prometheus/rules/hermes_alerts.yml"

4. 再次重载Prometheus配置。然后访问Web UI的 Alerts 页面，你应该能看到“HermesAgentDown”这条规则，其状态正常时应为 inactive，如果条件满足，则会变为 firing。

四、通过服务发现自动管理HermesAgent实例

在Kubernetes这类动态环境中，用静态IP配置监控目标简直是“刻舟求剑”。Pod可能随时被调度或重建，IP地址也会变。这时，服务发现（Service Discovery）机制就是救星。它能让Prometheus自动发现并监控所有符合条件的Pod实例。

如何为K8s环境中的HermesAgent配置服务发现？

1. 首先，确保你的HermesAgent Pod被打上了易于识别的标签，比如 app: hermes-agent。

2. 然后，修改 prometheus.yml 中的抓取配置，用 kubernetes_sd_configs 替换之前的 static_configs。下面是一个配置示例，请根据实际情况调整命名空间、标签和端口：

  - job_name: 'hermes-agent-k8s'
    kubernetes_sd_configs:
    - role: pod
      namespaces:
        names: ['default'] # 请替换为实际命名空间
    relabel_configs:
    - source_labels: [__meta_kubernetes_pod_label_app]
      action: keep
      regex: hermes-agent
    - source_labels: [__meta_kubernetes_pod_phase]
      action: keep
      regex: Running
    - source_labels: [__meta_kubernetes_pod_container_port_number]
      action: keep
      regex: "8080" # 替换为HermesAgent实际的metrics端口
    - source_labels: [__meta_kubernetes_pod_ip, __meta_kubernetes_pod_container_port_number]
      target_label: __address__
      replacement: $1:$2

3. 保存并重载配置后，去Targets页面观察一下。你会看到job_name为“hermes-agent-k8s”的target列表，它会随着K8s集群中HermesAgent Pod的上线和下线而自动更新。

五、验证指标可用性与告警触发逻辑

配置都做完了，但事情还没结束。最后，也是最关键的一步：验证。Prometheus内置的表达式浏览器（Expression Browser）是我们验证一切是否按预期工作的终极工具。在告警规则真正生效前，必须确保底层指标可查询、数据连续、标签正确。

如何进行验证？可以按这个顺序来：

1. 打开Prometheus Web UI，进入 Graph 页面。

2. 在查询框中输入基础状态指标：hermes_agent_up，点击执行。确认返回的结果中，instance标签对应的正是你的HermesAgent地址，并且数值为1（表示健康）。

3. 查询请求量趋势：输入 count by (instance) (hermes_agent_http_request_total[5m])，看看过去5分钟内是否有请求计数，这能验证指标是否在持续采集。

4. 模拟异常条件进行测试：输入 hermes_agent_queue_length > 1000。如果立刻有数据返回，说明该指标存在且可能已触发告警条件；如果没返回，则意味着要么这个指标HermesAgent没有暴露，要么采集链路有问题。

5. 最后，切换到 Alerts 页面，找到“HermesAgentDown”这条告警。正常情况下，它的状态应该是 inactive。为了彻底测试，你可以手动停止一个HermesAgent实例，等待2分钟（规则中设置的for时长），再刷新页面，此时应该能看到它的状态变为 firing，这证明整个监控告警链路完全打通了。