OneUptime 单机部署完全指南使用 Docker Compose 免费搭建开源可观测性平台【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime本文以 OneUptime 官方 Docker Compose 部署文档为主线面向希望在自有服务器上免费自托管 OneUptime 的开发者与运维人员完整覆盖系统选型、安装步骤、TLS/SSL 反向代理配置、生产就绪检查清单、更新与卸载等全部环节并结合仓库源码剖析npm start、npm run update、npm run down等命令背后的实际执行逻辑帮助读者在 Debian、Ubuntu 或 RHEL 上独立完成一套可长期运行的单机监控与可观测性平台。一、单机部署栈概览Compose 启动后你会得到什么OneUptime 是一套完整的开源监控与可观测性平台。使用 Docker Compose 部署时并不是启动一个服务而是拉起一组相互依赖的容器。以仓库根目录的 docker-compose.yml 与 docker-compose.base.yml 为证一次docker compose up至少会创建以下核心服务服务名镜像/说明职责postgrespostgres:15主关系型数据库存放项目、用户、监控配置等业务数据clickhouseclickhouse/clickhouse-server:26.7列式分析数据库承载遥测数据日志、Trace、指标等valkeyvalkey/valkey:9.1-alpine缓存与任务队列Redis 协议兼容详见后文缓存与队列小节apponeuptime/app:${APP_TAG}核心 API 服务同时消费后台与遥测任务队列ingressoneuptime/nginx:${APP_TAG}Nginx 网关统一对外暴露 HTTP/HTTPS 入口probe-1/probe-2oneuptime/probe:${APP_TAG}内置全球探针负责执行各类监控检查runneroneuptime/runner:${APP_TAG}AI/Runner 执行器支持代码修复等自动化能力从 docker-compose.yml 可以看到app、probe-1、runner、ingress都通过x-common-depends-on等待postgres、valkey、clickhouse三个基础服务健康检查通过后才启动ingress将${ONEUPTIME_HTTP_PORT}默认80映射到容器内7849端口、将${STATUS_PAGE_HTTPS_PORT}默认443映射到容器内7850端口同时为高并发场景预置了更宽的本地端口范围与tcp_tw_reuse内核参数。理解这套拓扑有助于排查后续部署中的端口冲突与依赖启动顺序问题。二、选择系统要求推荐配置与 Homelab 最低配置Docker Compose 单机部署方式下整个平台包含数据库、网关、探针都跑在同一台服务器上因此资源要求明显高于只部署单个组件的场景。官方文档根据用途与预算给出两档选型推荐系统要求追求最优性能16 GB 内存8 核 CPU400 GB 磁盘Ubuntu 22.04已安装 Docker 与 Docker Compose家庭环境 / 最低配置个人或实验用途8 GB 内存4 核 CPU20 GB 磁盘已安装 Docker 与 Docker Compose官方文档特别指出有用户甚至在树莓派RaspberryPi上跑过 OneUptime说明最低档仍有不小的下探空间。但需要结合源码理解磁盘要求为何偏高postgres与clickhouse分别挂载了独立命名卷见 docker-compose.base.yml 中的volumes: postgres:与clickhouse:遥测数据会长期累积同时Clickhouse/config.d/system-log-ttl.xml这类 TTL 策略只约束 ClickHouse 自身的系统日志不会替你清理业务数据。因此 20 GB 磁盘仅适合短期的个人实验长期运行请预留充足空间。三、部署前置条件开始部署前请确认服务器满足操作系统为 Debian、Ubuntu 或 RHEL 衍生发行版已安装 Docker 与 Docker Compose具备sudo权限后续拉取镜像、绑定 80/443 等低端口都需要。如果服务器尚未安装 Docker/Docker Compose/Node.js可以借助仓库根目录的 configure.sh 完成环境准备——它是npm run prerun实际调用的脚本会按发行版自动安装git、curl通过 nvm 安装 Node.js要求不低于 14.0.0安装 Docker要求不低于 20.0.0、Docker Compose 插件与模板渲染工具gomplate最后克隆仓库并生成config.env。这也解释了为什么官方推荐路径以npm start一键启动npm start本身就会先触发prerun钩子完成环境校验与配置文件生成。四、完整安装步骤两种方式任选其一方式一使用 npm 一键安装# 仅克隆 release 分支减少下载体积 git clone --depth 1 --single-branch --branch release https://github.com/OneUptime/oneuptime.git cd oneuptime # 复制环境配置模板 cp config.example.env config.env # 重要编辑 config.env 文件务必替换为随机密钥见下文生产就绪检查清单 # 启动整个平台 npm startnpm start并非简单的docker compose up。对照根目录 package.json 中的 scripts 定义其完整链路是触发prerun执行 configure.sh环境准备 生成config.env与SyncPackageVersions.js同步各子包版本号执行export $(grep -v ^# config.env | xargs)把config.env中所有非注释行加载为环境变量供 Docker Compose 插值使用执行docker compose up --remove-orphans -d后台启动全部容器--remove-orphans会清理不在当前 Compose 文件定义中的残留容器最后执行npm run status-check调用 Tests/Scripts/status-check.sh 检查各服务健康状态。方式二不使用 npm直接调用 Docker Compose若服务器没有 Node.js/npm或你更习惯直接控制容器编排可以跳过 npm 完全等价地执行# 读取 config.env 中的环境变量并后台启动全部服务 (export $(grep -v ^# config.env | xargs) docker compose up --remove-orphans -d) # 若因端口绑定权限不足改用 sudo 执行 sudo bash -c (export $(grep -v ^# config.env | xargs) docker compose up --remove-orphans -d)两种方式的底层命令完全一致区别仅在于npm start额外做了环境自检与状态检查。首次启动需要拉取多个镜像耗时取决于网络状况期间可另开终端用docker compose ps观察各容器是否进入 healthy 状态。五、访问 OneUptime 并注册账户部署完成后OneUptime 应运行在http://localhost打开浏览器访问该地址注册一个新账户即可开始使用。首任注册的管理员账户会拥有后续创建项目、添加监控的权限。注意此时仍是 HTTP 明文访问若要对外提供服务并启用 HTTPS请先完成下一节的 TLS/SSL 配置。六、配置 TLS/SSL 证书通过反向代理终止 HTTPS官方文档明确说明OneUptime 自身不负责签发或配置 SSL/TLS 证书证书的申请与终止由部署方自行完成。若需要 HTTPS 访问标准做法是在 OneUptime 前置一层反向代理使用 Nginx 或 Caddy 作为反向代理使用 Lets Encrypt 申请并续期证书将反向代理指向 OneUptime 服务器更新以下环境变量将HTTP_PROTOCOL设为https将HOST改为反向代理所在服务器的域名。这两项配置的作用可从 config.example.env 与 docker-compose.base.yml 中确认HOST与HTTP_PROTOCOL通过x-common-variables注入到所有服务平台内部据此生成正确的回调地址、Webhook 地址与页面链接如果HTTP_PROTOCOL仍为http而前面挂着 HTTPS 代理会出现页面已加密但站内链接仍是 http的混合内容问题。补充说明config.example.env中还预留了PROVISION_SSL开关注释指出当其为true时 OneUptime 可为HOST自动从 Lets Encrypt 申请证书但要求 80/443 端口可达且域名已解析到本机。这是平台内部配合LETS_ENCRYPT_ACCOUNT_KEY、LETS_ENCRYPT_NOTIFICATION_EMAIL的自动化路径若你选择在外部反向代理上终止 TLS则保持PROVISION_SSLfalse并自行管理证书两种方式按部署拓扑择一使用。反向代理场景下的额外调优项若反向代理会继续向X-Forwarded-For头部追加自身地址需要同步调整config.env中的TRUSTED_PROXY_HOPS。该变量的语义见 config.example.env 注释它表示 OneUptime 前方有几层由你自己运行的、会向X-Forwarded-For追加地址的代理。默认值1对应原生安装只有 OneUptime 自带的 Nginx 网关若前端再有 Nginx、Cloudflare、AWS ALB 等代理则应递增为2。设置过低会让所有访客看起来都来自代理地址设置过高则访客可伪造客户端 IP绕过状态页与公开面板的 IP 白名单和限流。七、生产就绪检查清单官方文档明确建议生产环境优先考虑 Kubernetes 而非 docker-compose 单机部署。仓库中提供了完整的 Helm Chart见 HelmChart/Public/oneuptime支持滚动更新、水平伸缩与云原生运维。如果仍坚持使用 docker-compose 承载生产流量请逐项核对以下清单。1. SSL/TLS必须启用 HTTPS参照上一节通过反向代理 Lets Encrypt 为对外域名启用 HTTPS并将HTTP_PROTOCOLhttps、HOST你的域名写入 config.env。裸 HTTP 下账号密码、探针密钥、Webhook 载荷都会明文传输属于生产环境不可接受的风险。2. Secrets替换全部默认密钥config.example.env中明确标注了# Secrets - PLEASE CHANGE THESE. Please change these to something random. All of these can be different values.模板里预置了如下占位密钥部署前必须替换为足够长的随机字符串各值可彼此不同密钥变量默认占位值用途ONEUPTIME_SECRETplease-change-this-to-random-value平台签名/加密主密钥REGISTER_PROBE_KEYplease-change-this-to-random-value探针注册密钥DATABASE_PASSWORDplease-change-this-to-random-valuePostgres 数据库密码CLICKHOUSE_PASSWORDplease-change-this-to-random-valueClickHouse 数据库密码VALKEY_PASSWORDplease-change-this-to-random-value缓存/队列密码ENCRYPTION_SECRETplease-change-this-to-random-value数据加密密钥GLOBAL_PROBE_1_KEY/GLOBAL_PROBE_2_KEYprobe-1-please-change-.../probe-2-please-change-...两个内置探针的认证密钥这些变量会通过x-common-runtime-variables注入所有运行容器见 docker-compose.base.yml任何一个保持默认值都等于把后门敞给扫描器。可用openssl rand -hex 32等工具生成随机串。3. 备份定期备份 Postgres 与 ClickHousepostgres与clickhouse的数据都写在命名卷中是唯一需要持久化的部分缓存Valkey为无状态服务可安全跳过。仓库根目录的 backup.sh 提供了现成的每日备份方案通过pg_dump --formatcustom生成压缩的自定义格式备份文件文件名形如db-{当月日期}.backup存放在DATABASE_BACKUP_DIRECTORY默认/Backups下并保留最近 30 天执行前需在config.env中正确填写DATABASE_BACKUP_*系列变量默认DATABASE_BACKUP_HOSTlocalhost、DATABASE_BACKUP_PORT5400——该端口正是 docker-compose.yml 中postgres对外映射的5400:5432专门用于备份访问建议通过 crontab 每天至少执行一次npm run backup对应 package.json 中的backup: bash backup.sh。对应的恢复脚本为仓库根目录的 restore.sh其使用DATABASE_RESTORE_*系列变量默认DATABASE_RESTORE_HOSThost.docker.internal且DATABASE_RESTORE_FILENAME必须与备份产出的db-*.backup文件名保持一致。4. 缓存与队列理解 Valkey 与 REDIS_* 的兼容关系valkey服务运行Valkey——Redis 7.2 的 BSD 许可分叉与 Redis 完全兼容线缆协议。这意味着平台通过VALKEY_*系列变量VALKEY_HOST、VALKEY_PORT、VALKEY_DB、VALKEY_USERNAME、VALKEY_PASSWORD等配置缓存与队列任何 Redis 协议服务器都可替代内置的 Valkey 容器——若已有托管的 Redis 服务只需把VALKEY_HOST指向它这些变量在13.0.0 之前名为REDIS_*。从源码看docker-compose.base.yml 通过VALKEY_HOST: ${VALKEY_HOST:-${REDIS_HOST}}这类回退语法同时兼容新旧变量名valkey 服务在网络别名中仍响应redis主机名aliases: [redis]且 package.json 中npm run update不会重写config.env。因此老版本遗留的REDIS_*配置无需任何修改即可继续工作升级不会破坏既有部署。5. 更新保持平台与依赖最新官方每天发布更新生产环境建议至少每周更新一次。更新命令如下git checkout release # 确保处于 release 分支 git pull npm run updatenpm run update在 package.json 中的定义是npm run prerun export $(grep -v ^# config.env | xargs) docker compose pull npm run start——即依次完成环境自检、拉取所有服务的最新镜像docker compose pull再走一遍npm start的启动与健康检查流程实现滚动式的原地升级。八、日志存储控制避免磁盘被探针与摄取日志写满在 Compose 默认配置中所有服务使用json-file日志驱动且各容器见 docker-compose.base.yml已统一设置了max-size: 1000m的单文件上限。官方文档特别提醒探针probe与遥测摄取ingest容器会产生大量日志仅靠单文件上限仍不足以防止存储被写满强烈建议在 Docker 守护进程层面进一步限制日志总量例如使用local日志驱动并配置max-size/max-file参数或为 json-file 驱动同时设置max-file。九、卸载 OneUptime当不再需要自托管实例时执行npm run down其底层调用docker compose down --remove-orphans见 package.json 中down: npm run stop会停止并删除 OneUptime 创建的所有容器、网络与卷。注意它不会删除config.env文件也不会删除克隆下来的仓库目录若需要彻底清除数据需在确认备份无误后手动删除 compose 命名卷docker volume rm oneuptime_postgres oneuptime_clickhouse等仓库还提供了交互式脚本 uninstall.shbash uninstall.sh会二次确认后执行docker compose down与docker compose rm适合需要更完整清理的场景。十、总结Docker Compose 是 OneUptime 门槛最低的自托管方案克隆 release 分支、配置config.env、npm start三步即可在本机获得完整的开源监控与可观测性平台。但生产使用必须补齐四件事——HTTPS 反向代理、随机密钥、数据库定期备份、每周例行更新若追求更高的可用性与弹性则应转向仓库自带的 Helm Chart 走 Kubernetes 部署路线。无论选择哪种方式config.example.env 中每一条变量的注释、docker-compose.base.yml 中每个服务的定义都是排障与调优时的第一手资料。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
OneUptime 单机部署完全指南：使用 Docker Compose 免费搭建开源可观测性平台
OneUptime 单机部署完全指南使用 Docker Compose 免费搭建开源可观测性平台【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime本文以 OneUptime 官方 Docker Compose 部署文档为主线面向希望在自有服务器上免费自托管 OneUptime 的开发者与运维人员完整覆盖系统选型、安装步骤、TLS/SSL 反向代理配置、生产就绪检查清单、更新与卸载等全部环节并结合仓库源码剖析npm start、npm run update、npm run down等命令背后的实际执行逻辑帮助读者在 Debian、Ubuntu 或 RHEL 上独立完成一套可长期运行的单机监控与可观测性平台。一、单机部署栈概览Compose 启动后你会得到什么OneUptime 是一套完整的开源监控与可观测性平台。使用 Docker Compose 部署时并不是启动一个服务而是拉起一组相互依赖的容器。以仓库根目录的 docker-compose.yml 与 docker-compose.base.yml 为证一次docker compose up至少会创建以下核心服务服务名镜像/说明职责postgrespostgres:15主关系型数据库存放项目、用户、监控配置等业务数据clickhouseclickhouse/clickhouse-server:26.7列式分析数据库承载遥测数据日志、Trace、指标等valkeyvalkey/valkey:9.1-alpine缓存与任务队列Redis 协议兼容详见后文缓存与队列小节apponeuptime/app:${APP_TAG}核心 API 服务同时消费后台与遥测任务队列ingressoneuptime/nginx:${APP_TAG}Nginx 网关统一对外暴露 HTTP/HTTPS 入口probe-1/probe-2oneuptime/probe:${APP_TAG}内置全球探针负责执行各类监控检查runneroneuptime/runner:${APP_TAG}AI/Runner 执行器支持代码修复等自动化能力从 docker-compose.yml 可以看到app、probe-1、runner、ingress都通过x-common-depends-on等待postgres、valkey、clickhouse三个基础服务健康检查通过后才启动ingress将${ONEUPTIME_HTTP_PORT}默认80映射到容器内7849端口、将${STATUS_PAGE_HTTPS_PORT}默认443映射到容器内7850端口同时为高并发场景预置了更宽的本地端口范围与tcp_tw_reuse内核参数。理解这套拓扑有助于排查后续部署中的端口冲突与依赖启动顺序问题。二、选择系统要求推荐配置与 Homelab 最低配置Docker Compose 单机部署方式下整个平台包含数据库、网关、探针都跑在同一台服务器上因此资源要求明显高于只部署单个组件的场景。官方文档根据用途与预算给出两档选型推荐系统要求追求最优性能16 GB 内存8 核 CPU400 GB 磁盘Ubuntu 22.04已安装 Docker 与 Docker Compose家庭环境 / 最低配置个人或实验用途8 GB 内存4 核 CPU20 GB 磁盘已安装 Docker 与 Docker Compose官方文档特别指出有用户甚至在树莓派RaspberryPi上跑过 OneUptime说明最低档仍有不小的下探空间。但需要结合源码理解磁盘要求为何偏高postgres与clickhouse分别挂载了独立命名卷见 docker-compose.base.yml 中的volumes: postgres:与clickhouse:遥测数据会长期累积同时Clickhouse/config.d/system-log-ttl.xml这类 TTL 策略只约束 ClickHouse 自身的系统日志不会替你清理业务数据。因此 20 GB 磁盘仅适合短期的个人实验长期运行请预留充足空间。三、部署前置条件开始部署前请确认服务器满足操作系统为 Debian、Ubuntu 或 RHEL 衍生发行版已安装 Docker 与 Docker Compose具备sudo权限后续拉取镜像、绑定 80/443 等低端口都需要。如果服务器尚未安装 Docker/Docker Compose/Node.js可以借助仓库根目录的 configure.sh 完成环境准备——它是npm run prerun实际调用的脚本会按发行版自动安装git、curl通过 nvm 安装 Node.js要求不低于 14.0.0安装 Docker要求不低于 20.0.0、Docker Compose 插件与模板渲染工具gomplate最后克隆仓库并生成config.env。这也解释了为什么官方推荐路径以npm start一键启动npm start本身就会先触发prerun钩子完成环境校验与配置文件生成。四、完整安装步骤两种方式任选其一方式一使用 npm 一键安装# 仅克隆 release 分支减少下载体积 git clone --depth 1 --single-branch --branch release https://github.com/OneUptime/oneuptime.git cd oneuptime # 复制环境配置模板 cp config.example.env config.env # 重要编辑 config.env 文件务必替换为随机密钥见下文生产就绪检查清单 # 启动整个平台 npm startnpm start并非简单的docker compose up。对照根目录 package.json 中的 scripts 定义其完整链路是触发prerun执行 configure.sh环境准备 生成config.env与SyncPackageVersions.js同步各子包版本号执行export $(grep -v ^# config.env | xargs)把config.env中所有非注释行加载为环境变量供 Docker Compose 插值使用执行docker compose up --remove-orphans -d后台启动全部容器--remove-orphans会清理不在当前 Compose 文件定义中的残留容器最后执行npm run status-check调用 Tests/Scripts/status-check.sh 检查各服务健康状态。方式二不使用 npm直接调用 Docker Compose若服务器没有 Node.js/npm或你更习惯直接控制容器编排可以跳过 npm 完全等价地执行# 读取 config.env 中的环境变量并后台启动全部服务 (export $(grep -v ^# config.env | xargs) docker compose up --remove-orphans -d) # 若因端口绑定权限不足改用 sudo 执行 sudo bash -c (export $(grep -v ^# config.env | xargs) docker compose up --remove-orphans -d)两种方式的底层命令完全一致区别仅在于npm start额外做了环境自检与状态检查。首次启动需要拉取多个镜像耗时取决于网络状况期间可另开终端用docker compose ps观察各容器是否进入 healthy 状态。五、访问 OneUptime 并注册账户部署完成后OneUptime 应运行在http://localhost打开浏览器访问该地址注册一个新账户即可开始使用。首任注册的管理员账户会拥有后续创建项目、添加监控的权限。注意此时仍是 HTTP 明文访问若要对外提供服务并启用 HTTPS请先完成下一节的 TLS/SSL 配置。六、配置 TLS/SSL 证书通过反向代理终止 HTTPS官方文档明确说明OneUptime 自身不负责签发或配置 SSL/TLS 证书证书的申请与终止由部署方自行完成。若需要 HTTPS 访问标准做法是在 OneUptime 前置一层反向代理使用 Nginx 或 Caddy 作为反向代理使用 Lets Encrypt 申请并续期证书将反向代理指向 OneUptime 服务器更新以下环境变量将HTTP_PROTOCOL设为https将HOST改为反向代理所在服务器的域名。这两项配置的作用可从 config.example.env 与 docker-compose.base.yml 中确认HOST与HTTP_PROTOCOL通过x-common-variables注入到所有服务平台内部据此生成正确的回调地址、Webhook 地址与页面链接如果HTTP_PROTOCOL仍为http而前面挂着 HTTPS 代理会出现页面已加密但站内链接仍是 http的混合内容问题。补充说明config.example.env中还预留了PROVISION_SSL开关注释指出当其为true时 OneUptime 可为HOST自动从 Lets Encrypt 申请证书但要求 80/443 端口可达且域名已解析到本机。这是平台内部配合LETS_ENCRYPT_ACCOUNT_KEY、LETS_ENCRYPT_NOTIFICATION_EMAIL的自动化路径若你选择在外部反向代理上终止 TLS则保持PROVISION_SSLfalse并自行管理证书两种方式按部署拓扑择一使用。反向代理场景下的额外调优项若反向代理会继续向X-Forwarded-For头部追加自身地址需要同步调整config.env中的TRUSTED_PROXY_HOPS。该变量的语义见 config.example.env 注释它表示 OneUptime 前方有几层由你自己运行的、会向X-Forwarded-For追加地址的代理。默认值1对应原生安装只有 OneUptime 自带的 Nginx 网关若前端再有 Nginx、Cloudflare、AWS ALB 等代理则应递增为2。设置过低会让所有访客看起来都来自代理地址设置过高则访客可伪造客户端 IP绕过状态页与公开面板的 IP 白名单和限流。七、生产就绪检查清单官方文档明确建议生产环境优先考虑 Kubernetes 而非 docker-compose 单机部署。仓库中提供了完整的 Helm Chart见 HelmChart/Public/oneuptime支持滚动更新、水平伸缩与云原生运维。如果仍坚持使用 docker-compose 承载生产流量请逐项核对以下清单。1. SSL/TLS必须启用 HTTPS参照上一节通过反向代理 Lets Encrypt 为对外域名启用 HTTPS并将HTTP_PROTOCOLhttps、HOST你的域名写入 config.env。裸 HTTP 下账号密码、探针密钥、Webhook 载荷都会明文传输属于生产环境不可接受的风险。2. Secrets替换全部默认密钥config.example.env中明确标注了# Secrets - PLEASE CHANGE THESE. Please change these to something random. All of these can be different values.模板里预置了如下占位密钥部署前必须替换为足够长的随机字符串各值可彼此不同密钥变量默认占位值用途ONEUPTIME_SECRETplease-change-this-to-random-value平台签名/加密主密钥REGISTER_PROBE_KEYplease-change-this-to-random-value探针注册密钥DATABASE_PASSWORDplease-change-this-to-random-valuePostgres 数据库密码CLICKHOUSE_PASSWORDplease-change-this-to-random-valueClickHouse 数据库密码VALKEY_PASSWORDplease-change-this-to-random-value缓存/队列密码ENCRYPTION_SECRETplease-change-this-to-random-value数据加密密钥GLOBAL_PROBE_1_KEY/GLOBAL_PROBE_2_KEYprobe-1-please-change-.../probe-2-please-change-...两个内置探针的认证密钥这些变量会通过x-common-runtime-variables注入所有运行容器见 docker-compose.base.yml任何一个保持默认值都等于把后门敞给扫描器。可用openssl rand -hex 32等工具生成随机串。3. 备份定期备份 Postgres 与 ClickHousepostgres与clickhouse的数据都写在命名卷中是唯一需要持久化的部分缓存Valkey为无状态服务可安全跳过。仓库根目录的 backup.sh 提供了现成的每日备份方案通过pg_dump --formatcustom生成压缩的自定义格式备份文件文件名形如db-{当月日期}.backup存放在DATABASE_BACKUP_DIRECTORY默认/Backups下并保留最近 30 天执行前需在config.env中正确填写DATABASE_BACKUP_*系列变量默认DATABASE_BACKUP_HOSTlocalhost、DATABASE_BACKUP_PORT5400——该端口正是 docker-compose.yml 中postgres对外映射的5400:5432专门用于备份访问建议通过 crontab 每天至少执行一次npm run backup对应 package.json 中的backup: bash backup.sh。对应的恢复脚本为仓库根目录的 restore.sh其使用DATABASE_RESTORE_*系列变量默认DATABASE_RESTORE_HOSThost.docker.internal且DATABASE_RESTORE_FILENAME必须与备份产出的db-*.backup文件名保持一致。4. 缓存与队列理解 Valkey 与 REDIS_* 的兼容关系valkey服务运行Valkey——Redis 7.2 的 BSD 许可分叉与 Redis 完全兼容线缆协议。这意味着平台通过VALKEY_*系列变量VALKEY_HOST、VALKEY_PORT、VALKEY_DB、VALKEY_USERNAME、VALKEY_PASSWORD等配置缓存与队列任何 Redis 协议服务器都可替代内置的 Valkey 容器——若已有托管的 Redis 服务只需把VALKEY_HOST指向它这些变量在13.0.0 之前名为REDIS_*。从源码看docker-compose.base.yml 通过VALKEY_HOST: ${VALKEY_HOST:-${REDIS_HOST}}这类回退语法同时兼容新旧变量名valkey 服务在网络别名中仍响应redis主机名aliases: [redis]且 package.json 中npm run update不会重写config.env。因此老版本遗留的REDIS_*配置无需任何修改即可继续工作升级不会破坏既有部署。5. 更新保持平台与依赖最新官方每天发布更新生产环境建议至少每周更新一次。更新命令如下git checkout release # 确保处于 release 分支 git pull npm run updatenpm run update在 package.json 中的定义是npm run prerun export $(grep -v ^# config.env | xargs) docker compose pull npm run start——即依次完成环境自检、拉取所有服务的最新镜像docker compose pull再走一遍npm start的启动与健康检查流程实现滚动式的原地升级。八、日志存储控制避免磁盘被探针与摄取日志写满在 Compose 默认配置中所有服务使用json-file日志驱动且各容器见 docker-compose.base.yml已统一设置了max-size: 1000m的单文件上限。官方文档特别提醒探针probe与遥测摄取ingest容器会产生大量日志仅靠单文件上限仍不足以防止存储被写满强烈建议在 Docker 守护进程层面进一步限制日志总量例如使用local日志驱动并配置max-size/max-file参数或为 json-file 驱动同时设置max-file。九、卸载 OneUptime当不再需要自托管实例时执行npm run down其底层调用docker compose down --remove-orphans见 package.json 中down: npm run stop会停止并删除 OneUptime 创建的所有容器、网络与卷。注意它不会删除config.env文件也不会删除克隆下来的仓库目录若需要彻底清除数据需在确认备份无误后手动删除 compose 命名卷docker volume rm oneuptime_postgres oneuptime_clickhouse等仓库还提供了交互式脚本 uninstall.shbash uninstall.sh会二次确认后执行docker compose down与docker compose rm适合需要更完整清理的场景。十、总结Docker Compose 是 OneUptime 门槛最低的自托管方案克隆 release 分支、配置config.env、npm start三步即可在本机获得完整的开源监控与可观测性平台。但生产使用必须补齐四件事——HTTPS 反向代理、随机密钥、数据库定期备份、每周例行更新若追求更高的可用性与弹性则应转向仓库自带的 Helm Chart 走 Kubernetes 部署路线。无论选择哪种方式config.example.env 中每一条变量的注释、docker-compose.base.yml 中每个服务的定义都是排障与调优时的第一手资料。【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址: https://gitcode.com/GitHub_Trending/on/oneuptime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考