部署结束后，页面可以直接打开，地址是 https://localhost:8888/，默认用户名和密码都是 admin。界面能看到监控面板、实例列表和一些配置选项，能简单完成对单个 PostgreSQL 实例的查看和基本操作。体验起来挺顺手，启动后就能看见数据。
接下来把经历说清楚点，别光看界面就跑。一般人用这个东西最常走的路就是用 Docker 和 Docker Compose 把演示环境拉起来。把项目里给的 docker-compose 文件下载到本地一个文件夹，然后在那个目录里敲一句 docker-compose up -d，系统会去拉几个镜像，带起 temboard 的 server、agent，再加一个演示用的 PostgreSQL 实例和一些配套的服务。等容器都跑起来了，打开浏览器访问上面那个地址，登录进去就能看到监控面板，基本功能能随手试试：添加实例、看实时指标、翻历史图表，整个流程体验是比较顺滑的。
别忽视启动过程里的细节，遇到问题多半不是 temBoard 本身，而是容器没有起来或端口没通。用 docker ps 看容器状态，看到 temboard_server、temboard_agent、postgres 这些名字就对了；要是想看日志，用 docker-compose logs -f 服务名，能直观看到报错信息。还有个常见点：有时网络或防火墙挡住了 agent 和 server 之间的通信，导致数据不上报，这种情况下先排查容器间网络和宿主机防火墙规则，比盲改配置快多了。
说说容器里会有什么。正常的 demo 包含 temboard server 进程负责网页展示和控制逻辑，agent 进程部署在被监控的数据库那台机器上，负责采集本机的指标并上报给 server，还有个示例的 PostgreSQL 数据库用来给你演示查询、指标和告警。除此之外，演示里常常会挂一些持久化或缓存用的卷，这样重启容器后不会丢数据。把 server 和 agent 分成两端好处也很明显：展示和控制聚焦在 server，把采集的工作放在 agent，这样一台 server 能管理好几台被监控的主机，扩展起来省事儿。
temBoard 这个项目本身是开源的，用 Python 跟前端 JavaScript 做的，跟 PostgreSQL 的协议能直接交互，代码放在 GitHub（
https://github.com/dalibo/temboard），想看源码、配置样例、或者想定位问题的同学可以去翻。官方也有安装和配置指南，生产环境的安装步骤写在文档站（
https://temboard.readthedocs.io/en/latest/server_install/），那里面把证书、持久化、用户认证这些需要认真做的地方列得比较清楚。
如果把它搬到真实环境里，有几件事需要提前安排好。agent 要在被监控主机上有合适的权限，能访问 PostgreSQL 的监控接口并能正常连接到数据库，否则采集的数据会残缺不全。server 端的 SSL、管理员账号和密码也得处理好，演示里用 admin/admin 只是为了上手方便，真用到生产上必须改掉。再提醒一句，Docker Compose 方式适合做概念验证，但生产环境里不要把敏感信息直接写进明文的 compose 文件，最好把密码、证书等用更安全的方式管理。
还有些操作细节值得注意。把 demo 环境跑起来后，提议第一件事是登录界面把默认密码改掉，顺手在 UI 里添加一个实例试试能不能看到 cpu、内存、连接数这些基本指标；如果看不到，先看 agent 是否能连上 PostgreSQL，看看 postgres 的监听地址、账号权限和防火墙规则。想做持久化的话，把容器的卷映射到宿主机目录或用专门的存储方案，保证指标、配置和日志不会随容器重建而丢失。证书管理上，生产环境里最好用正式的证书链而不是自签名，server 和 agent 之间的通信也提议走加密通道。
如果你只是想试一把，按前面说的把 compose 拉下来，docker-compose up -d 等容器跑稳定，浏览器打开 https://localhost:8888/ 登进去，改掉 admin 密码，然后把示例实例加到面板里看指标，来回点点，体验是不复杂的。想把它真正用到生产，那就按文档一步步把存储、证书和账号策略都配置到位，不急于一步到位，分阶段把安全和高可用做好，问题更容易定位。
操作中会遇到各种小坑，但大多数都能靠看日志和检查网络配置解决。等一切配置妥当，你在面板里看到实时波动、历史曲线、告警触发——那种把数据库状态可视化的感觉就出来了，挺有成就感的。
- 最新
- 最热
只看作者