<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>external-secrets on </title>
    <link>/tags/external-secrets/</link>
    <description>Recent content in external-secrets on </description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <lastBuildDate>Sat, 25 Apr 2026 01:00:00 +0800</lastBuildDate><atom:link href="/tags/external-secrets/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Homelab 消息通知：Alertmanager 通过 Gotify 推送告警</title>
      <link>/posts/homelab-alertmanager-gotify-bridge/</link>
      <pubDate>Sat, 25 Apr 2026 01:00:00 +0800</pubDate>
      
      <guid>/posts/homelab-alertmanager-gotify-bridge/</guid>
      <description>背景 Homelab 跑了一套 LGTM 可观测性栈（Loki + Grafana + Tempo + Prometheus），Prometheus Alertmanager 已经在收集各种告警，但一直没有配出通知渠道——告警只是静静地积在队列里，没有任何推送。
Gotify 是一个轻量的自托管推送通知服务，已经在集群里跑着了，主要用于接收 Redpanda Connect 推送的消息。顺手把 Alertmanager 的告警也接进来，省得再引入第三方服务。
架构 Alertmanager 的 webhook receiver 发送的是自己定义的 JSON 格式；Gotify 的 POST /message API 期望的是另一套字段（title / message / priority）。两者不能直接对接，需要一个中间层做格式转换。
DRuggeri/alertmanager_gotify_bridge 是一个专门做这件事的小服务。它的 README 说明默认监听 /gotify_webhook，并把收到的 Alertmanager webhook 转换后转发到 Gotify。
flowchart LR P[Prometheus] --&gt; A[Alertmanager] A --&gt;|webhook| B[alertmanager-gotify-bridge] B --&gt;|POST /message| G[Gotify] 部署拓扑：
组件 Namespace 说明 Gotify personal-services 消息服务端，已有 alertmanager-gotify-bridge monitoring 格式转换 bridge Alertmanager monitoring kube-prometheus-stack 的一部分 Token 管理走 Vault + External Secrets Operator：在 Gotify 创建一个专用 Application，把 token 存入 Vault，ESO 自动同步到 bridge 所在的 monitoring namespace。</description>
    </item>
    
  </channel>
</rss>
