1. 项目概述：一个专为Kubernetes打造的Uptime Kuma监控方案

如果你在Kubernetes集群里跑着几十上百个服务，每天最怕的就是半夜被电话叫醒，告诉你某个关键API挂了，而你却一脸茫然，不知道它是什么时候、为什么挂的。传统的监控方案要么太重，要么配置起来像解谜，等配好了，黄花菜都凉了。今天要聊的这个项目， dirsigler/uptime-kuma-helm ，就是来解决这个痛点的。简单说，它是一个Helm Chart，能让你在几分钟内，把轻量、强大且颜值在线的开源监控工具Uptime Kuma部署到你的K8s集群里。

Uptime Kuma本身是一个自托管的网站/服务状态监控工具，功能上对标UptimeRobot这类SaaS服务，但数据完全掌握在自己手里。它支持HTTP(s)、TCP、Ping、DNS、推送（如Heartbeat）、Steam游戏服务器等多种监控协议，能通过邮件、Telegram、Discord、Webhook等十几种方式发送告警，还有一个非常直观的Web仪表盘。而 dirsigler/uptime-kuma-helm 这个项目，则是将Uptime Kuma“Kubernetes化”的桥梁。它把Uptime Kuma的部署、配置、持久化存储、服务暴露等一系列运维操作，打包成了一个标准的Helm Chart。这意味着，无论你是个人开发者管理自己的小集群，还是运维团队管理生产环境，都可以通过几条简单的 helm 命令，获得一个高可用、可配置、易于维护的监控系统。

这个Chart的价值在于，它把开源软件的灵活性和Kubernetes声明式管理的便捷性结合了起来。你不再需要手动写Deployment、Service、PVC、Ingress这些YAML文件，也不用操心如何把配置文件挂载进去，或者如何优雅地升级。所有这些，Chart都帮你定义好了，你只需要关心几个核心的配置值，比如用什么数据库、告警怎么配、服务如何对外暴露。接下来，我们就深入拆解这个Chart的设计思路、核心配置以及如何让它在你自己的集群里稳定运行。

2. 核心架构与设计思路解析

2.1 为什么选择Helm Chart化？

在Kubernetes生态中，直接部署一个多组件的应用是件繁琐的事。以Uptime Kuma为例，它本身是一个Node.js应用，依赖数据库（默认是SQLite，也支持MySQL/PostgreSQL）。如果手动部署，你需要：

  1. 创建一个Deployment来运行Uptime Kuma容器。
  2. 创建一个Service来暴露Pod。
  3. 创建一个PersistentVolumeClaim (PVC) 来挂载存储，用于存放SQLite数据库文件或配置文件。
  4. 可能还需要一个Ingress或LoadBalancer Service来让外部访问Web界面。
  5. 需要处理环境变量来配置数据库连接、密钥等。

dirsigler/uptime-kuma-helm 这个Chart的核心价值，就是将上述所有资源定义模板化、参数化。它通过Helm的 values.yaml 文件，提供了一个统一的配置入口。这种设计带来了几个显著优势：

标准化与可复用性 ：Chart定义了一套符合Kubernetes最佳实践的部署规范。任何使用此Chart的人，无论集群环境如何，都能以相同的方式部署和配置Uptime Kuma，极大降低了学习和部署成本。

配置即代码 ：所有的配置（镜像版本、资源限制、数据库类型、网络设置）都通过 values.yaml 管理。你可以将这份文件纳入版本控制系统（如Git），实现部署过程的版本化和可追溯。回滚到上一个稳定版本也变得轻而易举。

简化复杂部署 ：Chart内部已经处理了资源之间的依赖关系。例如，它会确保PVC在Pod之前创建，并正确挂载；会根据你选择的数据库类型（内置SQLite或外部MySQL/PostgreSQL）自动配置相应的环境变量和初始化逻辑。用户无需理解这些底层细节。

易于维护与升级 ：当Uptime Kuma发布新版本时，你通常只需要在 values.yaml 中更新 image.tag 的值，然后执行 helm upgrade 即可。Chart会帮你处理滚动更新策略，确保服务不中断。

2.2 Chart的组件构成与数据流

这个Helm Chart主要创建了以下几类Kubernetes资源，我们可以通过 helm template 命令来预览：

  1. Deployment / StatefulSet ：这是应用的核心。Chart通常使用Deployment来部署Uptime Kuma的无状态实例。它定义了容器镜像、资源请求与限制、健康检查（就绪和存活探针）、环境变量以及数据卷挂载。

  2. Service ：创建一个ClusterIP类型的Service，为Deployment中的Pod提供一个稳定的内部访问端点。这是Ingress或外部负载均衡器流量入口的基础。

  3. PersistentVolumeClaim (PVC) ：这是保证监控数据不丢失的关键。Chart会创建一个PVC，用于挂载到容器内的 /app/data 目录（Uptime Kuma默认的数据目录）。这样，即使Pod被重建或调度到其他节点，你的监控配置、历史状态数据和SQLite数据库文件也会得以保留。

  4. Ingress （可选）：如果你希望通过域名从集群外部访问Web界面，Chart支持配置Ingress资源。它集成了常见的Ingress控制器（如Nginx、Traefik）的注解，可以轻松配置TLS证书、路径规则等。

  5. Secret （可选）：用于安全地存储敏感信息，如外部数据库的密码、告警通知的API密钥等。Chart支持通过 values.yaml 直接定义，或引用已有的K8s Secret。

数据流 可以这样理解：用户通过浏览器访问Ingress域名 -> 流量到达Ingress控制器 -> 转发给Uptime Kuma的Service -> 最终到达运行Uptime Kuma应用的Pod。Pod内的应用会读写挂载的持久化存储（PVC），进行监控任务调度、状态记录和告警判断。所有的配置元数据和监控结果都保存在这个持久化卷中。

注意 ：默认情况下，Chart使用内置的SQLite数据库，这对于大多数中小规模部署（监控几百个端点）来说完全足够，且部署最简单。如果你的监控规模极大，或者对数据库高可用有要求，才需要考虑在 values.yaml 中配置外部的MySQL或PostgreSQL。

3. 部署前准备与环境配置详解

3.1 基础环境与工具检查

在动手之前，确保你的本地环境和目标Kubernetes集群已经就绪。这是后续一切操作的基础。

1. Kubernetes集群 ：你需要一个正在运行的Kubernetes集群。可以是本地的Minikube、Kind、K3s，也可以是云服务商的托管集群（如GKE、EKS、AKS）。通过 kubectl cluster-info 命令可以验证你已正确配置并连接到集群。

2. Helm CLI工具 ：Helm是Kubernetes的包管理器，必须安装。建议使用Helm 3或更高版本，因为它更安全且无需Tiller服务端。你可以从 Helm官网 下载安装。安装后，运行 helm version 确认。

3. 添加Helm仓库 ： dirsigler/uptime-kuma-helm 这个Chart托管在一个Helm仓库中。首先需要将这个仓库添加到本地。

helm repo add dirsigler https://dirsigler.github.io/helm-charts
helm repo update

helm repo update 命令会拉取仓库中最新的Chart索引，确保你能看到所有可用的版本。

4. 查看可用的Chart ：添加成功后，你可以搜索或列出该仓库下的Chart。

helm search repo dirsigler

你应该能看到名为 dirsigler/uptime-kuma 的Chart及其最新版本。

3.2 定制化配置：理解values.yaml

部署的核心是对 values.yaml 文件进行配置。不建议直接使用 helm install 的默认参数，因为那可能不适合你的环境。最佳实践是获取默认的 values.yaml ，在其基础上进行修改。

获取默认配置文件 ：

helm show values dirsigler/uptime-kuma > my-values.yaml

这会生成一个包含所有可配置项的 my-values.yaml 文件。打开它，你会看到大量被注释掉的配置，结构清晰。我们重点关注以下几部分：

镜像配置 ( image ) ：

image:
  repository: louislam/uptime-kuma
  tag: 1.23.12 # 建议指定一个稳定版本，而非latest
  pullPolicy: IfNotPresent
  • repository : Uptime Kuma的官方Docker镜像。
  • tag : 强烈建议固定一个具体的版本号 ，如 1.23.12 。使用 latest 标签在生产环境是危险的，因为自动升级可能导致不兼容。
  • pullPolicy : 通常 IfNotPresent 即可，如果节点上已有该镜像则不再拉取。

副本数与资源限制 ( replicaCount , resources ) ：

replicaCount: 1
resources:
  requests:
    memory: "256Mi"
    cpu: "100m"
  limits:
    memory: "512Mi"
    cpu: "500m"
  • replicaCount : Uptime Kuma本身是有状态的（数据在PVC里），默认设置为1。如果Pod重启，Deployment会创建一个新的Pod并挂载同一个PVC，从而实现快速恢复。 通常不需要也不建议设置为大于1 ，除非你使用外部数据库并做了特殊的分片处理，但这超出了Chart的默认范畴。
  • resources : 为容器设置合理的资源请求和限制至关重要。对于监控几百个端点，上述配置（256Mi内存请求，512Mi限制）是足够的起点。你需要根据实际监控负载观察并调整。不设置限制可能导致Pod占用过多节点资源而被OOM Kill。

持久化存储 ( persistence ) ：

persistence:
  enabled: true
  accessMode: ReadWriteOnce
  size: 8Gi
  storageClass: "" # 如果为空，则使用集群的默认StorageClass
  • enabled : 必须为 true ，否则数据会在Pod重启后丢失。
  • size : 根据你的监控数据量预估。SQLite数据库本身很小，但如果你开启了状态页面截图功能，图片会占用较多空间。8Gi是一个安全的起步大小。
  • storageClass : 这是关键。如果你的集群在云上（如AWS EBS, GCP Persistent Disk），通常有默认的StorageClass。如果是本地测试（如Minikube），可能需要先配置一个本地存储类，或者使用 hostPath （不推荐生产）。如果不确定，留空让集群使用默认值。

服务暴露 ( service , ingress ) ：

service:
  type: ClusterIP # 内部服务类型
  port: 3001 # Uptime Kuma默认端口

ingress:
  enabled: false # 默认不创建Ingress
  className: "" # Ingress Class名称，例如“nginx”
  hosts:
    - host: uptime-kuma.yourdomain.com
      paths:
        - path: /
          pathType: Prefix
  tls: [] # 配置TLS证书
  • service.type : 部署阶段通常先用 ClusterIP ，在集群内部访问进行初始化配置。后续再通过Ingress暴露。
  • ingress : 这是从外部访问Web界面的主要方式。将 enabled 改为 true ，并配置你的域名和Ingress Class。如果你使用Cert-manager等工具自动管理TLS证书，可以在这里配置相应的注解。

数据库配置 ( env ) ：这是高级配置。默认使用SQLite，数据文件就在PVC挂载的目录里。如果你想用MySQL或PostgreSQL，需要通过 env 字段注入额外的环境变量，例如：

env:
  - name: UPTIME_KUMA_DB_TYPE
    value: "mysql"
  - name: UPTIME_KUMA_DB_HOST
    value: "mysql-service"
  - name: UPTIME_KUMA_DB_PORT
    value: "3306"
  - name: UPTIME_KUMA_DB_NAME
    value: "uptimekuma"
  - name: UPTIME_KUMA_DB_USER
    value: "kuma_user"
  - name: UPTIME_KUMA_DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: uptime-kuma-db-secret
        key: password

重要 ：如果你配置了外部数据库，Chart 不会 帮你创建这个数据库和用户。你需要提前在MySQL/PostgreSQL实例中手动创建好数据库和具有相应权限的用户。

4. 完整部署流程与初始化操作

4.1 执行部署命令与验证

假设你已经根据上一节的指导，定制好了自己的 my-values.yaml 文件。现在开始部署。

1. 安装Chart ： 我们为这次安装起一个名字（release name），例如 my-uptime-kuma ，并指定我们修改过的配置文件。

helm install my-uptime-kuma dirsigler/uptime-kuma -f my-values.yaml --namespace monitoring --create-namespace
  • my-uptime-kuma : 这是Helm Release的名称，在同一个命名空间内必须唯一。
  • dirsigler/uptime-kuma : 指定要安装的Chart。
  • -f my-values.yaml : 使用自定义的配置文件。
  • --namespace monitoring : 指定部署到 monitoring 命名空间。这是一个好习惯，将监控组件放在独立的命名空间。
  • --create-namespace : 如果 monitoring 命名空间不存在，则自动创建它。

2. 检查部署状态 ： 安装命令会输出创建的资源列表。你可以通过以下命令跟踪Pod的状态：

kubectl get pods -n monitoring -w

等待Pod的状态变为 Running ，并且就绪探针（ READY 列为 1/1 ）。

3. 验证服务 ：

kubectl get svc,ingress,pvc -n monitoring

你应该能看到创建的Service、PVC，如果启用了Ingress，也会看到Ingress资源。

4. 临时端口转发（用于初始访问） ： 在配置好Ingress之前，我们可以用 kubectl port-forward 快速访问Web界面进行初始化设置。

kubectl port-forward svc/my-uptime-kuma 3001:3001 -n monitoring

现在，你可以在浏览器中打开 http://localhost:3001 ，应该能看到Uptime Kuma的首次安装设置页面。

4.2 首次登录与基础配置

在浏览器中打开Uptime Kuma的界面后，你会看到设置向导。

1. 创建管理员账户 ：输入用户名、邮箱和密码。这个账户拥有最高管理权限，请务必使用强密码并妥善保管。

2. 设置站点名称 ：给你的监控面板起个名字，比如“公司生产环境监控”。

3. 配置反向代理（可选但重要） ：如果你计划通过域名和Ingress访问（例如 https://status.yourcompany.com ），那么 必须 在这里进行配置。在设置页面的“反向代理”或“URL前缀”相关选项中，填写你将要使用的完整基础URL，例如 https://status.yourcompany.com 。这是因为Uptime Kuma需要知道它被访问的根地址，来正确生成链接和重定向。如果跳过这一步，后续通过Ingress访问可能会遇到页面样式丢失、API调用404等问题。

4. 初始化完成 ：点击保存后，你会进入Uptime Kuma的主仪表盘。

5. 配置Ingress（如果之前启用了） ：完成Web界面初始化后，确保你的Ingress控制器已经生效，并且域名解析（DNS）已经指向了Ingress控制器的外部IP或负载均衡器地址。然后你就可以通过配置的域名（如 https://status.yourcompany.com ）访问Uptime Kuma了。记得关闭之前运行的 kubectl port-forward 命令。

4.3 添加第一个监控任务

现在系统已经就绪，我们来添加一个监控项，验证整个流程。

  1. 在Uptime Kuma仪表盘，点击右上角的 “添加监控” 按钮。
  2. 监控类型 ：选择“HTTP(s)”。这是最常用的类型，用于监控网站或API接口。
  3. 友好名称 ：填写一个易于识别的名字，如“公司官网首页”。
  4. URL ：填写要监控的地址，如 https://www.yourcompany.com 。
  5. 心跳间隔 ：选择检查频率，例如“每60秒”。对于生产关键服务，可以选择更短的间隔（如30秒），但会增加对方服务器的负载和你的网络流量。
  6. 超时时间 ：默认10秒，一般足够。
  7. 重试机制 ：建议启用。例如“1次重试，间隔30秒”。这可以避免因网络瞬时波动造成的误报警。
  8. 通知列表 ：可以先跳过，我们稍后配置告警。
  9. 点击“保存”。

保存后，这个监控项会立即开始第一次检查。稍等片刻，你就能在仪表盘上看到它的状态（通常是“运行中”的绿色标志）。点击这个监控项，可以看到详细的响应时间历史图表、最近的事件日志等。

至此，一个基于Helm Chart的、高可用的Uptime Kuma监控系统就已经在你的Kubernetes集群中部署完成并开始工作了。但这只是开始，要让其真正发挥价值，关键在于配置可靠的告警和优化其运行状态。

5. 告警通知集成与最佳实践

监控的核心价值在于“感知”，而告警则是将“感知”转化为“行动”的关键环节。Uptime Kuma支持丰富的通知方式，我们将重点讲解几种在生产环境中最实用、最可靠的集成方法。

5.1 配置通知渠道：以Telegram和Webhook为例

1. Telegram Bot告警 ： Telegram的即时性和丰富的客户端支持，使其成为个人或小团队非常高效的告警渠道。

  • 创建Bot ：在Telegram中搜索 @BotFather ，发送 /newbot 指令，按提示创建机器人，最终你会获得一个 HTTP API 令牌。
  • 获取Chat ID ：给你新建的Bot发送一条消息（如 /start ）。然后，在浏览器中访问这个URL： https://api.telegram.org/bot<你的Bot令牌>/getUpdates 。在返回的JSON中，找到 message.chat.id 字段的值，这就是你的Chat ID。
  • 在Uptime Kuma中配置 ：
    • 进入“设置” -> “通知”。
    • 点击“添加通知”，类型选择“Telegram”。
    • 填写“Bot令牌”和“Chat ID”。
    • 可以自定义通知模板，默认模板已经包含了监控项名称、状态、时间等信息，非常清晰。

2. Webhook告警（集成企业微信/钉钉/飞书等） ： 对于国内团队，集成企业微信、钉钉或飞书是更常见的选择。这些平台通常都支持通用的Webhook接入。

  • 以企业微信为例 ：
    • 在企业微信中创建一个群聊，在群聊中添加“群机器人”，即可获得一个Webhook URL，格式如： https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxxxxxxx 。
    • 在Uptime Kuma中，“添加通知”，类型选择“Webhook”。
    • URL ：填写上面获得的Webhook URL。
    • 请求体（Body） ：这是关键。你需要根据企业微信机器人要求的JSON格式来构造。例如： 
      {
  "msgtype": "markdown",
  "markdown": {
    "content": "**<monitor-name>**\n> 状态: **<status>**\n> 时间: `<time>`\n> 消息: `<msg>`"
  }
}
    • Uptime Kuma的Webhook支持模板变量，如 <monitor-name> , <status> , <time> , <msg> 等，它们会在发送时被替换为实际值。
    • 请求头（Headers） ：通常需要设置 Content-Type: application/json 。

实操心得 ：配置Webhook时，最容易出错的地方就是请求体的格式。强烈建议先使用Postman或 curl 命令测试你的Webhook URL和请求体，确保能成功发送消息到目标平台，然后再填入Uptime Kuma中。Uptime Kuma的Webhook设置界面下方有一个“测试”按钮，一定要用。

5.2 告警策略与降噪设计

告警泛滥会导致“狼来了”效应，最终重要的告警也被忽略。合理的告警策略至关重要。

1. 设置维护期（Maintenance Period） ： 对于计划内的维护（如系统升级、数据迁移），你可以为特定的监控项设置维护期。在维护期内，该监控项的检查会暂停，不会触发告警。

  • 操作 ：在监控项详情页，点击“更多” -> “计划维护期”。可以设置一次性或周期性的维护时段。

2. 利用“依赖项（Dependency）”功能 ： 这是Uptime Kuma一个非常强大的功能。例如，你监控了一个前端API ( api.service.com )，而这个API依赖一个后端的用户服务 ( user-service.internal )。你可以将API监控项设置为“依赖”于用户服务监控项。

  • 效果 ：当用户服务宕机时，API服务必然不可用。此时，Uptime Kuma只会发送用户服务宕机的告警，而不会发送API服务的告警，因为你已经知道根本原因。这极大地减少了告警噪音。

3. 配置告警延迟与重试 ： 在添加或编辑监控项时，注意“高级选项”。

  • 最大重试次数 ：不要设置为0。建议设为1或2。单次检查失败可能是网络抖动，重试一次可以避免误报。
  • 发送通知前允许的失败次数 ：这个值应该大于等于“最大重试次数”。例如，重试1次，那么总共会检查2次（初始1次+重试1次）。你可以设置“允许失败次数”为2，这意味着连续2次检查都失败才发告警。这提供了额外的缓冲，对抗间歇性故障。

4. 分级别通知 ： Uptime Kuma允许你为同一个监控项配置多个通知渠道，并可以设置“启用”和“禁用”条件。虽然不能像专业监控系统那样做复杂的路由，但你可以通过创建两个相同的监控项（指向同一个URL）来实现简单分级：

  • 监控项A（关键告警） ：心跳间隔短（如30秒），配置给值班电话/短信渠道。
  • 监控项B（一般告警） ：心跳间隔长（如5分钟），配置给Telegram/邮件渠道。 这样，非核心服务的故障只会触发一般告警，只有核心服务故障才会升级到电话告警。

6. 高级配置、运维与故障排查

6.1 数据持久化与备份策略

即使使用了PVC，数据安全也不能完全依赖底层存储。你需要有自己的备份方案。

1. 备份Uptime Kuma数据 ： Uptime Kuma的数据（配置、监控历史、事件）默认存储在 /app/data 目录下。在Kubernetes中，这个目录被PVC挂载。备份的本质就是备份这个目录下的文件。

  • 手动备份 ：你可以使用 kubectl cp 命令将数据拷贝到本地。 
    kubectl cp monitoring/<pod-name>:/app/data ./uptime-kuma-backup -c uptime-kuma
    （注意替换 <pod-name> 为实际的Pod名称， -c 指定容器名，如果Chart默认容器名不是 uptime-kuma ，请查看Deployment定义）
  • 自动化备份 ：更可靠的方式是结合CronJob和云存储。创建一个Kubernetes CronJob，定期执行以下操作：
    1. 使用 kubectl exec 在Pod内执行 sqlite3 命令导出数据库（如果使用SQLite）。
    2. 或者直接用 kubectl cp 将整个 /app/data 目录拷贝到备份Pod。
    3. 将打包的备份文件上传到S3、OSS或NFS等持久化存储中。

2. 恢复数据 ：

  • 如果PVC损坏或需要迁移，你可以通过反向操作恢复。
  • 将备份文件拷贝到新Pod的 /app/data 目录。
  • 重要 ：恢复操作时，必须确保Uptime Kuma的Pod是停止状态，避免数据写入冲突。可以先缩容Deployment到0个副本，执行恢复，再扩容回1。

3. 考虑使用外部数据库 ： 对于数据安全性要求极高的生产环境，可以考虑在 values.yaml 中配置使用外部的MySQL或PostgreSQL。这样，数据库的备份、高可用方案可以沿用你现有的数据库运维体系，更为成熟可靠。

6.2 性能调优与资源监控

1. 监控Uptime Kuma自身 ： 一个监控系统本身必须是健康的。你可以用Uptime Kuma监控它自己的健康端点，但这存在“自指”的矛盾。更好的方法是：

  • 使用Kubernetes原生监控 ：通过Prometheus和Grafana监控Uptime Kuma Pod的资源使用情况（CPU、内存）、就绪状态和重启次数。
  • 部署一个独立的、更基础的监控 ：用一个极其简单的HTTP探针（甚至可以部署在集群外），来检查Uptime Kuma的Ingress访问是否正常。这作为最底层的保障。

2. 调整资源限制 ： 根据实际运行情况调整 values.yaml 中的 resources.limits 。如果监控端点数量很多（上千个），且检查频率高，Uptime Kuma可能会消耗更多CPU和内存。通过以下命令观察：

kubectl top pod -n monitoring

如果发现内存使用持续接近限制，或CPU使用率经常很高，就需要适当调高 limits ，并同时调整 requests 以保证调度质量。

3. 优化检查频率与超时 ：

  • 非关键业务端点，适当降低检查频率（如5分钟或10分钟一次）。
  • 根据被监控服务的实际响应时间，合理设置“超时时间”。设置过短会导致误报（服务实际正常但检查超时），设置过长则意味着故障发现延迟。通常可以设置为服务P99响应时间的2-3倍。

6.3 常见问题与故障排查实录

即使部署顺利，运行过程中也可能遇到问题。这里记录几个典型场景和排查思路。

问题1：Pod一直处于 CrashLoopBackOff 状态。

  • 排查步骤 ：
    1. 查看Pod日志 ：这是第一步，也是最重要的一步。 
      kubectl logs -n monitoring <pod-name> --previous # 查看上次崩溃的日志
kubectl logs -n monitoring <pod-name> -f # 查看当前Pod日志并持续输出
    2. 常见原因 ：
      • 权限问题 ：Pod无法写入挂载的PVC。检查PVC的 accessMode 是否为 ReadWriteOnce ，以及Pod运行的节点是否有权限访问该存储卷。查看日志中是否有“Permission denied”错误。
      • 数据库连接失败 ：如果你配置了外部数据库，检查数据库地址、端口、用户名密码是否正确，数据库实例是否可访问，以及目标数据库和用户是否已创建。日志通常会明确报出连接错误。
      • 镜像拉取失败 ：网络问题或镜像标签不存在。检查 kubectl describe pod <pod-name> 中 Events 部分的信息。
      • 配置错误 ： values.yaml 中存在语法错误或无效值。使用 helm template 命令渲染YAML进行预检查： helm template my-uptime-kuma dirsigler/uptime-kuma -f my-values.yaml --namespace monitoring > output.yaml ，然后检查 output.yaml 文件是否合法。

问题2：通过Ingress访问，页面样式丢失或API请求404。

  • 排查步骤 ：
    1. 确认Ingress配置 ：检查 kubectl get ingress -n monitoring 的输出，确保 HOSTS 和 ADDRESS 字段正确。
    2. 检查Ingress控制器日志 ：查看Nginx Ingress Controller或Traefik的日志，看是否有路由错误。
    3. 检查Uptime Kuma反向代理设置 ： 这是最常见的原因 。你必须确保在Uptime Kuma的Web设置中，“反向代理/URL前缀”字段填写了你通过Ingress访问的完整地址（包括 https:// ）。这个设置保存在数据库里，如果没配或配错，Uptime Kuma生成的静态资源路径和API路径就会错误。
    4. 检查Ingress注解 ：如果你使用了类似 nginx.ingress.kubernetes.io/rewrite-target 的注解，确保重写规则正确，没有“吃掉”必要的路径前缀。

问题3：告警通知没有发送。

  • 排查步骤 ：
    1. 测试通知渠道 ：在Uptime Kuma的“通知”设置中，每个配置好的通知渠道都有一个“测试”按钮。务必先使用它测试，确保配置正确。
    2. 检查监控项的通知列表 ：确认告警的监控项确实关联了你期望的通知渠道。一个监控项可以关联多个渠道。
    3. 查看Uptime Kuma应用日志 ：通知发送失败通常会在应用日志中留下记录。使用 kubectl logs 查看，搜索“notification”、“webhook”、“telegram”等关键词。
    4. 检查网络策略 ：如果你的集群使用了NetworkPolicy，确保Uptime Kuma Pod有权限访问外网（Telegram API、企业微信API等）或集群内的Webhook接收端。
    5. 检查通知频率限制 ：Uptime Kuma有内置的告警频率限制，防止轰炸。对于持续宕机的服务，它不会每分钟都发一条告警。这是正常行为。

问题4：监控大量端点时，Pod内存持续增长。

  • 分析与解决 ： Uptime Kuma会将监控状态和历史数据保存在内存中以提供快速查询。监控项越多，历史保留时间越长，内存占用就越大。
    1. 调整数据保留策略 ：在Uptime Kuma的“设置” -> “通用”中，可以找到“事件保留天数”和“状态页面历史记录天数”等选项。适当减少这些天数可以显著降低内存和数据库压力。
    2. 增加资源限制 ：这是最直接的应对。根据监控，逐步调高Deployment中内存的 limits 和 requests 。
    3. 考虑水平拆分 ：如果监控规模极大（数万个端点），单一的Uptime Kuma实例可能成为瓶颈。这时可以考虑部署多个Uptime Kuma实例，通过标签或命名空间划分监控责任域。但这需要更复杂的运维，且 dirsigler/uptime-kuma-helm 这个Chart本身是单实例设计，多实例部署需要额外的协调（如共享数据库、避免监控任务重复）。对于绝大多数场景，优化配置和增加资源已足够。
Logo
亚马逊云科技技术品牌专区

更多推荐

open-code-review Codex 插件教程：对话式调用评审技能指南

本文是一份面向新手的 **open-code-review Codex 插件教程**，教你在 Codex 中通过对话式方式调用 open-code-review 的 AI 代码评审技能。open-code-review 是阿里巴巴开源的 AI 代码评审工具，采用"确定性流水线 + LLM Agent"混合架构，内置多语言评审规则（NPE、线程安全、XSS、SQL 注入等），可在 Codex 里用一

avatar 亚马逊云科技技术品牌专区

OBS Studio 完整指南：免费开源录屏与直播软件从零上手

想做一场像模像样的直播，或者把屏幕内容录成教程视频，但一想到商用软件的订阅费就有些犹豫？其实你不需要花一分钱。OBS Studio 是一款免费开源的直播与录屏软件，支持 Windows、macOS 和 Linux，采集、混音、编码、推流、录制，一条流水线全包了。## 先搞清楚 OBS Studio 是什么OBS Studio 是一个"场景化"的采集合成工具：你把摄像头、窗口、浏览器、图片、

avatar 亚马逊云科技技术品牌专区

如何用MediaCrawler爬取小红书抖音数据？7大平台爬虫从安装到实战完整指南

MediaCrawler 是一个支持小红书、抖音、快手、B站、微博、百度贴吧、知乎的开源自媒体数据采集工具。它能按关键词、按帖子、按创作者主页三种方式抓取笔记/视频内容、评论甚至二级评论，并把结果存成 JSON、CSV、Excel 或数据库。适合做市场调研、竞品监控、内容选题的运营人员，以及想要现成爬虫框架而不想从零写 JS 逆向的开发者。## 从一次"手动抄数据"说起想象这个场景：你负责

avatar 亚马逊云科技技术品牌专区