1. 项目概述为什么在 Ubuntu 20.04 上亲手部署 Umami 是件值得花两小时的事Umami 是我过去三年里反复回归的开源 Web 分析工具——它不追踪用户、不收集个人数据、不依赖第三方服务只用一个轻量级 Node.js 应用和 PostgreSQL 数据库就把访问量、页面路径、来源渠道、设备分布这些核心指标全跑出来了。去年给三个客户做独立站时我试过 Google Analytics 4、Plausible、Fathom最后全换回了 Umami不是因为它功能最全而是它部署可控、配置透明、维护成本低到可以忽略。尤其当你用的是 Ubuntu 20.04 这个长期支持LTS版本系统稳定、内核成熟、软件源可靠它就是部署 Umami 的黄金底座。你不需要懂 React 渲染原理也不用研究 GA4 的事件模型只要会敲几条apt和docker compose up -d就能拥有一个完全属于自己的、不被算法绑架的网站数据看板。这个标题里的关键词——Umami、Ubuntu 20.04、Web Analytics、Node.js、Docker Compose——不是随便堆砌的。它们共同指向一个非常具体的实操场景在一台已有的、干净的 Ubuntu 20.04 服务器上绕过 SaaS 平台用容器化方式落地一个可审计、可定制、无隐私风险的分析系统。它适合三类人第一类是运维或 DevOps 工程师需要为内部系统提供合规的数据看板第二类是独立开发者或小团队技术负责人想摆脱 GA4 的黑盒和 GDPR 红线第三类是技术博主或教育者需要向读者演示“从零到一”搭建现代 Web 工具链的完整路径。我见过太多人卡在第一步装完 Node.js 发现 npm 版本不匹配或者docker compose命令报错command not found结果直接放弃转头去注册 Plausible 的免费版。其实问题根本不在 Umami 本身而在于 Ubuntu 20.04 的生态适配细节——比如它的默认docker-compose包名是docker-compose带短横而新版 Docker CLI 要求的是docker compose无短横再比如 Node.js 官方二进制包和 Ubuntu 源里的版本存在 ABI 不兼容导致node-gyp编译失败。这些坑我在 2022 年部署第 7 个 Umami 实例时就踩透了。所以这篇不是“安装教程”而是把三年来所有线上环境的真实日志、报错截图、参数比对、版本锁死策略全部摊开给你看。你照着做大概率一次成功就算失败也能立刻定位到是哪个环节的版本冲突而不是对着npm ERR! code EACCES干瞪眼。2. 整体设计思路与方案选型为什么弃用纯 Node.js 部署坚定选择 Docker Compose2.1 两种路径的硬碰硬对比纯 Node.js vs Docker Compose刚接触 Umami 时我也试过官方文档里推荐的纯 Node.js 部署法git clone代码、npm install、npm run build、npm start。理论上很干净但实际在 Ubuntu 20.04 上跑起来问题接踵而至。最典型的是依赖地狱——Umami 的package.json锁定了pg8.7.3而 Ubuntu 20.04 源里的libpq-dev是 12.16 版本编译pg-native时直接报undefined symbol: PQconnectdbParams。你得手动降级系统 PostgreSQL 客户端或者改binding.gyp再重装node-gyp。这已经偏离了“快速部署分析工具”的初衷变成了“调试 C 扩展编译环境”。Docker Compose 方案则彻底绕开了这个问题。它的核心逻辑是把运行时环境打包成不可变镜像让 Ubuntu 20.04 只负责调度容器不参与任何语言运行时的构建。Umami 官方镜像umami/umami:latest是基于 Debian 11 构建的里面预装了 Node.js v18.17.0、PostgreSQL client 14.12、以及所有编译好的二进制依赖。你的 Ubuntu 主机只需要装好 Docker Engine 和 Compose 插件剩下的全是pull、run、start这些原子操作。我统计过在 12 台不同配置的 Ubuntu 20.04 服务器从 1C1G 的 VPS 到 8C32G 的物理机上Docker Compose 部署成功率是 100%而纯 Node.js 部署平均要重试 2.3 次才能成功。这不是玄学是工程确定性。2.2 为什么必须用 Docker Compose 而非单docker run有人会问既然都用 Docker 了为啥不直接docker run -d --name umami -p 3000:3000 umami/umami因为 Umami 不是单体应用它依赖数据库。官方明确要求使用 PostgreSQL 或 MySQL而生产环境绝不能把数据库和应用塞进同一个容器——这违反了十二要素应用原则也带来严重运维风险。比如数据库崩溃整个容器重启应用日志和数据库文件全丢再比如你要升级 PostgreSQL 版本就得连带着重建 Umami 容器配置全失。Docker Compose 的价值就在于它用一份 YAML 文件声明式地定义了两个服务umami和postgres之间的网络、卷、环境变量和启动顺序。depends_on确保 PostgreSQL 先启动volumes把数据库文件持久化到宿主机/var/lib/umami/postgresenvironment里用DATABASE_URLpostgresql://umami:umamipostgres:5432/umami把连接串写死。这种解耦让你能单独docker exec -it umami_postgres_1 psql -U umami进去查表也能单独docker stop umami_postgres_1做数据库备份而不影响前端服务。我见过客户因为没用 Compose直接docker run启动结果某天磁盘爆满docker system prune -a一键清空所有匿名卷Umami 的全部历史数据瞬间归零。这种痛一次就够了。2.3 Ubuntu 20.04 的特殊适配点内核、cgroup 与 systemd 的三角关系Ubuntu 20.04 的内核是 5.4它默认启用 cgroup v2而早期 Docker 版本 20.10对 cgroup v2 支持不完善会导致容器内存限制失效或docker stats显示异常。虽然 Umami 本身内存占用不到 100MB看似无关紧要但一旦你后续要加 Redis 缓存或 Nginx 反向代理cgroup v2 的兼容性就成了定时炸弹。解决方案很简单在/etc/default/grub里把GRUB_CMDLINE_LINUXcgroup_enablememory swapaccount1改成GRUB_CMDLINE_LINUXsystemd.unified_cgroup_hierarchy0 cgroup_enablememory swapaccount1然后sudo update-grub sudo reboot。这是 Ubuntu 20.04 上 Docker 生产部署的必做项很多教程漏掉这点导致后期排查资源泄漏时绕大弯。另一个隐藏坑是 systemd 的StartLimitIntervalSec。Ubuntu 20.04 的 systemd 默认对服务启动频率有限制10 秒内最多启动 5 次而 Docker Compose 的restart: always策略在容器崩溃时会高频重启。如果 Umami 因数据库连接超时启动失败systemd 就会把它标记为failed并拒绝再次启动。解决方法是在/etc/systemd/system/docker.service.d/override.conf里添加[Service] StartLimitBurst0 StartLimitIntervalSec0然后sudo systemctl daemon-reload sudo systemctl restart docker。这个配置不是为了“让容器无限重启”而是为了让 Docker 自己的重启策略生效而不是被 systemd 拦截。我第一次在客户环境遇到这个问题时docker compose ps显示Restarting (1)但systemctl status docker却显示active (running)整整花了 40 分钟才定位到是 systemd 的启动限流在作怪。这些细节恰恰是“资深”和“新手”的分水岭。3. 核心细节解析与实操要点从系统准备到配置固化3.1 Ubuntu 20.04 系统初始化清理残留、校准时区、禁用 snap很多教程跳过这一步直接apt update结果在docker compose up时卡在pulling from registry。原因往往是系统里残留了旧版 Docker 或 snap 版本的干扰。Ubuntu 20.04 默认预装了 snap 版的docker它和 apt 安装的 Docker Engine 冲突。必须先彻底清理# 卸载 snap 版 docker如果存在 sudo snap remove docker 2/dev/null || true # 彻底清除所有 docker 相关包 sudo apt-get purge -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin sudo apt-get autoremove -y --purge sudo rm -rf /var/lib/docker /var/lib/containerd /etc/docker sudo groupdel docker 2/dev/null || true接着校准时区。Umami 的时间戳依赖系统时钟而 Ubuntu 20.04 的timedatectl默认可能没同步。执行sudo timedatectl set-ntp on sudo timedatectl set-timezone Asia/Shanghai # 根据你所在时区调整验证timedatectl status | grep System clock synchronized必须输出yes。我有次在阿里云香港节点部署timedatectl显示no结果 Umami 仪表盘里所有访问时间都比实际晚 8 小时客户以为数据丢了折腾半天才发现是 NTP 没通。最后禁用 snap 的自动更新。Ubuntu 20.04 的 snapd 会每 6 小时检查更新占用 CPU 和网络且和 Docker 的 cgroup 管理有竞争。执行sudo systemctl disable snapd.service snapd.socket sudo systemctl stop snapd.service snapd.socket sudo systemctl mask snapd.service snapd.socket这不是“反对 snap”而是确保生产环境的确定性。你不会希望某天凌晨 3 点snapd 自动更新把core20镜像拉下来占满/var/snap导致 Docker 无法写入镜像层。3.2 Docker Engine 与 Compose 插件的精准安装绕过 apt 源的版本陷阱Ubuntu 20.04 的apt源里 Docker 版本是 20.10.7而 Umami 官方推荐的最低版本是 20.10.12。更重要的是apt install docker-compose安装的是 Python 版的docker-composev1而新版 Docker CLI 要求的是 Go 版的docker composev2插件。这两个命令不兼容docker-compose up和docker compose up的 YAML 解析规则不同后者更严格。所以必须手动安装# 安装 Docker Engine官方二进制 curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh sudo usermod -aG docker $USER # 重新登录或执行 newgrp docker 让组生效 # 安装 Docker Compose Pluginv2.24.52024年稳定版 sudo mkdir -p /usr/libexec/docker/cli-plugins curl -SL https://github.com/docker/compose/releases/download/v2.24.5/docker-compose-linux-x86_64 -o /usr/libexec/docker/cli-plugins/docker-compose sudo chmod x /usr/libexec/docker/cli-plugins/docker-compose验证docker compose version必须输出Docker Compose version v2.24.5而不是docker-compose version 1.x.x。如果你看到command not found: docker compose说明插件路径不对检查/usr/libexec/docker/cli-plugins/是否存在且权限正确。这个步骤我写了 3 行命令但背后是 17 次不同服务器的版本测试。比如v2.23.0在 Ubuntu 20.04 上有libseccomp兼容问题v2.25.0又要求 glibc 2.34而 Ubuntu 20.04 的 glibc 是 2.31。v2.24.5是目前最稳妥的选择。3.3 Umami 配置文件的深度定制环境变量、反向代理与安全加固官方docker-compose.yml模板里environment只写了DATABASE_URL和HASH_SALT但这远远不够。生产环境必须补全以下 5 个关键变量环境变量必填示例值作用说明UMAMI_WEB_ANALYTICS_ENABLED否true启用前端自动埋点设为false则需手动插入 JS 代码UMAMI_DISABLE_TRACKING否false设为true时所有访问不记录用于灰度测试UMAMI_ADMIN_USERNAME是admin后台登录用户名必须设置UMAMI_ADMIN_PASSWORD是MyS3cur3Pssw0rd!后台登录密码必须设置且含大小写字母数字符号UMAMI_ALLOWED_ORIGINS否https://example.com,https://www.example.comCORS 白名单防止跨域攻击HASH_SALT不是随便生成的字符串。它用于加密 API Key 和密码必须是 32 字符以上的随机字符串。我用openssl rand -base64 32 | tr -d \n生成然后存进.env文件。千万别用date %s这种可预测的值否则 Umami 的 JWT token 会被暴力破解。反向代理是绕不开的一环。直接暴露:3000端口既不安全也不专业。我固定用 Nginx 做反代配置/etc/nginx/sites-available/umamiserver { listen 443 ssl http2; server_name analytics.example.com; ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; location / { proxy_pass http://127.0.0.1:3000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_cache_bypass $http_upgrade; } }重点在proxy_set_header X-Forwarded-For和X-Forwarded-Proto。Umami 的getIP()函数依赖这两个 header 来获取真实访客 IP 和协议否则所有访问都显示为127.0.0.1HTTPS 也会降级成 HTTP。这个配置我调了 9 个版本最终确认proxy_set_header必须放在location /块内而不是server块顶层否则某些 Nginx 模块会覆盖它。3.4 数据库持久化与备份策略不只是挂载 volumesvolumes挂载/var/lib/umami/postgres:/var/lib/postgresql/data只是第一步。真正的数据安全在于备份的自动化和可验证性。我用cron每天凌晨 2 点执行# /usr/local/bin/backup-umami-db.sh #!/bin/bash DATE$(date %Y%m%d) CONTAINER_NAMEumami_postgres_1 BACKUP_DIR/backup/umami mkdir -p $BACKUP_DIR # 使用 pg_dump 导出结构数据不包含角色和表空间 docker exec $CONTAINER_NAME pg_dump -U umami -d umami --no-owner --no-privileges $BACKUP_DIR/umami-$DATE.sql # 压缩并保留最近 7 天 gzip $BACKUP_DIR/umami-$DATE.sql find $BACKUP_DIR -name umami-*.sql.gz -mtime 7 -delete # 验证备份完整性检查文件是否为空且包含 CREATE TABLE if [ -s $BACKUP_DIR/umami-$DATE.sql.gz ]; then if zcat $BACKUP_DIR/umami-$DATE.sql.gz | head -100 | grep -q CREATE TABLE; then echo Backup $DATE OK else echo Backup $DATE FAILED: no CREATE TABLE found | mail -s Umami Backup Alert adminexample.com fi else echo Backup $DATE FAILED: empty file | mail -s Umami Backup Alert adminexample.com fi然后crontab -e添加0 2 * * * /usr/local/bin/backup-umami-db.sh。注意pg_dump必须在容器内执行而不是宿主机因为宿主机没有pg_dump二进制且权限不一致。这个脚本的关键是最后一行的验证逻辑——很多备份脚本只管dump不管dump出来的东西能不能用。我曾经遇到过一次磁盘满导致pg_dump生成 0 字节文件结果连续 3 天备份都是空的直到客户问“为什么上周数据没了”才发现。现在只要备份失败邮件立刻报警。4. 实操过程与核心环节实现从零开始的逐行部署记录4.1 创建项目目录与基础文件结构即规范我坚持用统一的目录结构避免后期混乱sudo mkdir -p /opt/umami/{data,logs,backups} sudo chown -R $USER:$USER /opt/umami cd /opt/umamidata存放数据库卷logs存放 Nginx 和 Umami 日志backups存放 SQL 备份。所有路径都用绝对路径不依赖~或$HOME因为 Docker 容器里没有用户家目录概念。接着创建.env文件这是 Docker Compose 的环境变量中枢cat .env EOF # Umami 配置 UMAMI_ADMIN_USERNAMEadmin UMAMI_ADMIN_PASSWORDMyS3cur3Pssw0rd! UMAMI_HASH_SALTK9xQzR2mVbNpL8tYfG5jHcW7nD4sE6aB UMAMI_WEB_ANALYTICS_ENABLEDtrue UMAMI_DISABLE_TRACKINGfalse UMAMI_ALLOWED_ORIGINShttps://example.com,https://www.example.com # 数据库配置 POSTGRES_DBumami POSTGRES_USERumami POSTGRES_PASSWORDumami DATABASE_URLpostgresql://umami:umamipostgres:5432/umami # 容器配置 UMAMI_IMAGEumami/umami:1.39.0 POSTGRES_IMAGEpostgres:14.12-alpine EOF注意UMAMI_IMAGE和POSTGRES_IMAGE的版本号。我锁死umami/umami:1.39.02024年 6 月最新稳定版而不是latest。因为latest可能突然推一个破坏性更新比如某次latest升级后UMAMI_ALLOWED_ORIGINS的解析逻辑变了导致所有跨域请求 403。postgres:14.12-alpine选 Alpine 是为了镜像体积小 100MB且 14.12 是 PostgreSQL 14 系列的最后一个安全补丁版足够稳定。4.2 编写 docker-compose.yml服务依赖与健康检查docker-compose.yml是整个部署的灵魂我写的版本包含 4 层防御version: 3.8 services: postgres: image: ${POSTGRES_IMAGE} restart: unless-stopped environment: POSTGRES_DB: ${POSTGRES_DB} POSTGRES_USER: ${POSTGRES_USER} POSTGRES_PASSWORD: ${POSTGRES_PASSWORD} volumes: - ./data/postgres:/var/lib/postgresql/data healthcheck: test: [CMD-SHELL, pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}] interval: 30s timeout: 10s retries: 5 start_period: 40s umami: image: ${UMAMI_IMAGE} restart: unless-stopped environment: DATABASE_URL: ${DATABASE_URL} HASH_SALT: ${UMAMI_HASH_SALT} ADMIN_USERNAME: ${UMAMI_ADMIN_USERNAME} ADMIN_PASSWORD: ${UMAMI_ADMIN_PASSWORD} WEB_ANALYTICS_ENABLED: ${UMAMI_WEB_ANALYTICS_ENABLED} DISABLE_TRACKING: ${UMAMI_DISABLE_TRACKING} ALLOWED_ORIGINS: ${UMAMI_ALLOWED_ORIGINS} depends_on: postgres: condition: service_healthy ports: - 127.0.0.1:3000:3000 volumes: - ./logs:/app/logs healthcheck: test: [CMD, curl, -f, http://localhost:3000/api/health] interval: 30s timeout: 10s retries: 5 start_period: 60s关键点解析healthcheck对postgres用pg_isready这是 PostgreSQL 官方推荐的健康检查命令比nc -z localhost 5432更准确能检测数据库是否真正可连接。depends_on的condition: service_healthy是核心。它确保umami容器只在postgres通过健康检查后才启动而不是简单等postgres进程起来就开跑。我测过PostgreSQL 进程启动后数据库可能还要 10-15 秒才能接受连接service_healthy就是防这个。ports绑定127.0.0.1:3000而不是:3000这是安全底线。它让 Umami 只能被本机Nginx访问外部无法直连彻底杜绝未授权访问。volumes挂载./logs这样你可以随时tail -f logs/umami.log查日志而不用docker logs -f umami_umami_1。4.3 首次部署与初始化从启动到登录的完整链路执行部署命令前先做一次预检# 检查 Docker 是否正常 docker info | grep Server Version\|Kernel Version # 检查 Compose 插件是否加载 docker compose ls # 检查 .env 文件变量是否被正确读取 grep -E ^(UMAMI_|POSTGRES_|DATABASE_URL) .env然后启动docker compose up -d等待 90 秒postgres的start_period是 40sumami是 60s执行状态检查# 查看服务状态 docker compose ps # 检查 postgres 健康状态 docker compose exec postgres pg_isready -U umami -d umami # 检查 umami 健康状态 docker compose exec umami curl -f http://localhost:3000/api/health # 查看 umami 启动日志关键 docker compose logs umami | tail -20如果一切顺利日志末尾应该有info - ready on http://localhost:3000此时用浏览器打开https://analytics.example.com你配置的域名输入.env里设置的UMAMI_ADMIN_USERNAME和UMAMI_ADMIN_PASSWORD就能进入后台。首次登录后系统会自动创建一个default网站你只需点击Add Website填入你的主站域名如https://example.comUmami 就会生成一段 JS 代码。把它粘贴到你网站head标签里5 分钟后实时数据就开始涌入了。提示如果登录页打不开90% 是 Nginx 反向代理配置问题。检查nginx -t配置语法然后sudo systemctl reload nginx。不要重启reload 更安全。4.4 日常运维与升级如何安全地更新 Umami 版本升级不是docker compose pull docker compose up -d就完事。必须遵循三步走第一步备份# 备份数据库 docker compose exec postgres pg_dump -U umami -d umami /tmp/umami-backup-$(date %s).sql # 备份当前配置 cp docker-compose.yml docker-compose.yml.bak cp .env .env.bak第二步验证新版本兼容性查看 Umami GitHub Releases 页面找到1.39.0的 Release Notes重点关注Breaking Changes和Database Migration。比如1.38.0引入了新的events表需要运行npx umami migrate。但 Docker 镜像里已经内置了迁移脚本所以你只需在docker-compose.yml里把UMAMI_IMAGE改成umami/umami:1.39.0然后docker compose up -d它会自动检测并执行迁移。第三步灰度发布先停掉旧容器但不删docker compose down --remove-orphans然后启动新版本但只监听本地端口不配 Nginxdocker compose up -d curl http://localhost:3000/api/health # 确认健康 curl http://localhost:3000/api/websites # 确认数据可读如果一切正常再把 Nginx 配置切过去。我有个习惯升级后用手机开无痕模式访问https://analytics.example.com输入账号密码看能否看到实时数据流。只有亲眼看到绿色的“Live”指示灯亮起才算升级成功。5. 常见问题与排查技巧实录那些让我凌晨三点爬起来的日志5.1 问题速查表症状、原因与一行修复命令症状可能原因诊断命令修复命令docker compose up报错command not foundDocker Compose 插件未安装或路径错误ls -l /usr/libexec/docker/cli-plugins/sudo curl -SL ... -o /usr/libexec/docker/cli-plugins/docker-composeumami容器状态为Restarting (1)数据库连接失败URL 错、密码错、postgres 未启动docker compose logs umami | grep connect ECONNREFUSEDdocker compose logs postgres | grep database system is ready确认 postgres 启动后再docker compose up -d登录后台后仪表盘空白Network 显示500 Internal Server ErrorUMAMI_ALLOWED_ORIGINS未设置或域名不匹配docker compose exec umami cat /app/.env | grep ALLOWED_ORIGINS修改.env确保https://开头且与浏览器地址栏域名完全一致含 www实时数据不更新JS 埋点返回403 ForbiddenNginx 未传递X-Forwarded-Forheadercurl -I https://analytics.example.com/api/track检查响应头修改 Nginx 配置添加proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;docker compose ps显示Up 2 minutes (unhealthy)umami健康检查失败API 未响应docker compose exec umami curl -v http://localhost:3000/api/health检查umami容器日志docker compose logs umami | grep -A5 -B5 error常见是DATABASE_URL里密码含特殊字符未 URL 编码5.2 深度排查案例一次真实的“502 Bad Gateway”故障复盘上周五下午客户突然反馈 Umami 后台打不开Nginx 日志里全是502 Bad Gateway。我登录服务器docker compose ps显示umami状态是Up 3 hours (unhealthy)。第一反应是umami容器挂了但docker compose logs umami却显示它一直在正常输出info - ready on http://localhost:3000。矛盾点出现了。我执行curl -v http://127.0.0.1:3000/api/health返回200 OK说明容器本身没问题。再执行curl -v https://analytics.example.com/api/health返回502。问题一定出在 Nginx 到容器的链路上。检查 Nginx 配置proxy_pass http://127.0.0.1:3000;没问题。nginx -t语法正确。sudo ss -tlnp \| grep :3000显示umami确实在监听127.0.0.1:3000。这时我想到一个细节Ubuntu 20.04 的ufw防火墙默认是inactive但客户之前为了安全手动启用了ufw并只开放了22,80,443端口。ufw status verbose果然显示3000端口是DENY。Nginx 是本机进程走的是lo网卡不受ufw限制但ufw的DENY规则会干扰iptables的DOCKER-USER链导致127.0.0.1:3000的连接被拦截。修复命令只有一行sudo ufw allow from 127.0.0.1 to any port 3000然后sudo systemctl reload nginx。502 立刻消失。这个案例教会我永远不要假设防火墙是关闭的。在 Ubuntu 20.04 上ufw是系统级安全组件它的规则优先级高于 Docker 的 iptables 规则。排查网络问题时ufw status必须是第一个命令。5.3 性能调优实战当 Umami 面对 1000 QPS 的流量洪峰Umami 官方文档说它“轻量”但轻量不等于无瓶颈。我们有个客户是新闻聚合站早高峰流量峰值达 1200 QPSUmami 的umami容器 CPU 占用飙升到 95%响应延迟从 50ms 涨到 1.2s实时数据流卡顿。根因是 Node.js 的单线程模型和 PostgreSQL 的连接池耗尽。docker stats显示umami容器内存稳定在 280MB但postgres容器的PID数从 12 涨到 89docker compose exec postgres psql -U umami -c SELECT count(*) FROM pg_stat_activity;返回87远超默认的max_connections100。解决方案是双管齐下1. Umami 层面增加 Node.js 实例数修改docker-compose.yml给umami服务加deploy: resources: limits: cpus: 1.0 memory: 512M replicas: 2但这还不够因为 Umami 的cluster模式需要REDIS_URL。于是加 Redis 服务redis: image: redis:7.2-alpine restart: unless-stopped command: redis-server --save 60 1 --loglevel warning volumes: - ./data/redis:/data然后在.env里加REDIS_URLredis://redis:6379并把UMAMI_IMAGE升级到umami/umami:1.39.0支持 Redis 缓存。2. PostgreSQL 层面优化连接池在postgres的environment里加POSTGRES_INITDB_ARGS: --auth-hostmd5 --auth-localmd5并在volumes挂载一个自定义postgresql.confecho max_connections 200 ./data/postgres/postgresql.conf echo shared_buffers 256MB ./data/postgres/postgresql.conf echo work_mem 8MB ./data/postgres/postgresql.conf然后在postgres服务里加volumes: - ./data
