如果问我在一台刚装好的 openEuler 服务器上最优先部署什么我会毫不犹豫地说监控。不是业务也不是各种中间件而是一套能真实反映机器状态的监控服务。Coolmonitor 这个名字可能不像 Prometheus、Zabbix 那么出圈但它在轻量化场景下非常好用特别适合直接跑在华为 openEuler 上。这篇文章完全从实操出发记录我如何把 Coolmonitor 监控服务从零搭起来包括环境准备、服务部署、指标与告警配置以及几个必须注意的坑。如果你手头只有一到几十台服务器不想维护一堆采集器和独立数据库那这套方案值得一试。我会尽量把每个关键步骤的原理解释清楚而不是只丢给你一串命令。1. 项目概述与需求拆解1.1 这套监控服务到底解决什么问题先说一个很现实的场景你维护一台或者十几台 openEuler 服务器想知道 CPU 有没有被打满、内存是不是长期吃紧、磁盘什么时候会被日志写满。如果每次都靠登录服务器敲top、df -h去手动看不仅效率低而且根本扛不住异常突发。Coolmonitor 要解决的就是这个“日常巡检”和“异常感知”的问题。它不像 Prometheus Grafana 那套组合需要在监控端部署时序数据库、采集器、接入层再在面板上配一堆数据源。Coolmonitor 更像一个把采集、存储、展示、告警都揉在一起的轻量服务部署完之后打开浏览器就能看到当前机器的核心指标也能提前给微信、钉钉或者 Webhook 推送告警。对中小型团队和个人开发者来说这种“一个进程搞定”的监控形态反而比大而全的监控平台更容易落地也没有一堆组件要维护。1.2 为什么用华为 openEuler 作为底座openEuler 这几年在服务器领域的活跃度非常高系统本身基于 Linux 内核演进很多操作习惯和 CentOS 接近但包管理、内核版本、安全特性上做了不少优化。我第一次从 CentOS 切到 openEuler 时最直观的感受是yum/dnf 的命令基本通用官方软件源里的包版本比较新对 Python 生态的支持也相当友好。Coolmonitor 是 Python 实现的监控服务核心依赖无非是 psutil、Flask、SQLite 这类常规组件在 openEuler 上完全不需要特殊适配。更重要的是openEuler 对国产硬件和云场景的兼容性做得比较透如果你后续需要把监控服务迁移到鲲鹏这类 ARM 环境基本不用改代码。这也是我选择它作为演示系统的原因之一先把一个轻量监控服务跑通后面的扩展空间会大很多。1.3 Coolmonitor 的工作原理与总体架构Coolmonitor 的架构并不复杂整体可以分成四层。第一层是采集层它通过读取系统的/proc、/sys以及调用操作系统的统计接口拿到 CPU、内存、磁盘、网络、负载这类指标。第二层是存储层默认采用 SQLite 保存历史数据不需要单独部署数据库。第三层是 Web 展示层负责把采集到的数据渲染成趋势图。第四层是告警引擎按配置好的阈值规则做比对触发后通过邮件、Webhook 等渠道发送通知。这里有一个很关键的取舍Coolmonitor 没有采用“中心化 海量被监控端”的重型架构更适合一台服务器直接跑一个实例通过 agent 方式批量上报。如果你有几十台机器要统一监控也可以把 Coolmonitor 部署在一台管理机上其他节点装轻量采集 agent数据上报到管理机。部署前想清楚这个拓扑后面配置起来会更顺手。2. 环境准备与基础配置2.1 确认 openEuler 系统信息与硬件资源开始安装之前先确认系统的基础状态避免装到一半才发现资源不够。登录服务器后我会依次执行这几条命令cat /etc/os-release uname -r nproc free -h df -h重点看三个信息系统版本、CPU 核数、可用内存和磁盘空间。Coolmonitor 本身不是很吃资源默认的采集周期下512MB 内存加 1 核 CPU 也能跑但如果磁盘空间太小SQLite 数据库会很快膨胀尤其是你设置的保留周期越长空间占用越明显。我建议至少给/opt或者专门的数据目录预留 5GB 以上空间存放监控历史数据和日志。如果系统刚装完还可以顺手更新一下内核和安全补丁。这里提醒一句在有业务运行的情况下不要贸然重启内核先确认系统处于可维护窗口内再操作。2.2 配置 yum 软件源在线安装与离线环境两种思路openEuler 默认自带的软件源基本可用不过在国内服务器上我更习惯把源切到访问速度更快的镜像源尤其是刚开机准备装大量依赖时。配置方式很简单先把系统自带的 repo 文件备份再替换为镜像源地址。以某镜像站为例先备份mv /etc/yum.repos.d/openEuler.repo /etc/yum.repos.d/openEuler.repo.bak然后写入新的 repo 配置下面是常用的一小段示例[openEuler-base] nameopenEuler-base baseurlhttps://mirrors.example.com/openEuler/${releasever}/baseos/$basearch/ enabled1 gpgcheck0这里的mirrors.example.com要替换成你实际使用的镜像地址不同镜像站的路径命名会略有差异。配置完成后执行dnf clean all dnf makecache dnf update -y如果你处于内网隔离环境没有办法直接访问外网镜像那就走离线思路找一台同样架构、同样系统版本的联网机器把需要的 rpm 包用dnf download拉到本地再通过yum localinstall或者搭建本地 yum 仓库的方式安装。实际操作中离线安装最大的坑是依赖不全建议直接下载带依赖的包集合或者在联网机上把依赖一次性拉取完整。2.3 安装 Python 与编译工具链Coolmonitor 依赖 Python 3openEuler 的默认源里已经带好了 Python 3但别急着直接用因为很多 Python 扩展在安装时都需要头文件和编译工具。我的习惯是先把整套编译链装齐避免后面踩坑。dnf install -y python3 python3-devel python3-pip git gcc gcc-c make dnf install -y openssl-devel libffi-devel sqlite-devel这几个包的作用分别是python3-devel提供 Python 头文件sqlite-devel保证 Python 能编译出 SQLite 支持openssl-devel和libffi-devel是很多 Python 扩展的底层依赖。Coolmonitor 这类采集监控工具经常用到 psutil而 psutil 在部分环境下需要从源码编译没有编译链会直接报错。装完之后顺手升级一下 pip 并配置国内 PyPI 镜像会明显提高依赖安装速度pip3 install --upgrade pip pip3 config set global.index-url https://pypi.example.com/simple这里的镜像地址同样按你实际可用的 PyPI 镜像填。这个步骤不是必须的但在国内服务器上不换源的话下载依赖可能非常煎熬。3. 安装 Coolmonitor 监控服务3.1 获取安装包与目录规划Coolmonitor 的部署方式有很多种源码包和 Git 仓库都可以。我习惯把服务相关文件统一放在/opt/coolmonitor下数据单独放在/var/lib/coolmonitor日志放在/var/log/coolmonitor这样后续做备份和权限控制都比较清晰。先创建目录结构mkdir -p /opt/coolmonitor mkdir -p /var/lib/coolmonitor mkdir -p /var/log/coolmonitor然后把 Coolmonitor 的源码包解压到/opt/coolmonitor或者直接git clone从官方仓库拉取代码。如果你用的是发布包记得留意压缩包里的目录层级别把二级目录直接当成项目根目录。我第一次部署时就是把目录搞错了导致后面配置文件路径一直找不到浪费了不少时间。拿到源码后直接进入项目目录查看说明文件重点看requirements.txt、配置模板和启动入口三个文件。3.2 创建虚拟环境并安装 Python 依赖虽然系统 Python 可不可以用可以但我强烈建议用虚拟环境隔离尤其是同一台机器上还有别的 Python 项目时。虚拟环境能让 Coolmonitor 的依赖不会污染系统环境也不容易被其他项目的版本调整破坏。cd /opt/coolmonitor python3 -m venv venv source venv/bin/activate pip install -r requirements.txt这一步如果卡在某个包上通常是 PyPI 源太慢或者缺编译依赖。换到国内镜像源之后绝大多数包都能顺利用 wheel 直接安装。遇到需要源码编译的包检查一下python3-devel和gcc是否已经装好再做一次重试。依赖装完后命令行工具会出现 Coolmonitor 的入口命令例如coolmonitor或python3 manage.py具体看项目版本。先用--help确认可用的子命令别急着启动。3.3 初始化数据库与调整核心配置Coolmonitor 默认使用 SQLite 作为存储所以需要先执行初始化命令例如coolmonitor migrate或者项目文档里的类似命令。执行成功后会生成一个.db文件所有历史监控数据都会写入这里。初始化完成后再打开配置文件config.yaml这是整个服务最核心的部分。我提供一个最小可用的配置模板server: host: 0.0.0.0 port: 8899 secret_key: your-super-secret-key storage: db_path: /var/lib/coolmonitor/coolmonitor.db retention_days: 30 agent: enabled: true bind: 0.0.0.0 interval: 15 log: file: /var/log/coolmonitor/coolmonitor.log level: INFO这里有几个参数务必重视。server.host如果写成127.0.0.1就只能本机访问外部通过 Nginx 反代时其实更安全直接暴露公网时才考虑0.0.0.0。storage.retention_days控制历史数据保留天数30 天对大多数场景足够了太长会让 SQLite 文件快速膨胀。agent.interval控制采集指标的时间间隔15 秒比较均衡如果你的机器数量很多可以适当调大到 30 秒降低性能开销。配置改完以后建议先手动启动一次服务观察前台日志是否正常确认没问题再交给 systemd。3.4 使用 systemd 守护进程并设置开机自启手动启动服务只适合验证真正生产环境还是得交给 systemd 来管理。它可以确保服务在崩溃后自动重启也能开机自启让整个监控服务不依赖人工登录。在/etc/systemd/system/下新建coolmonitor.service[Unit] DescriptionCoolmonitor Monitoring Service Afternetwork.target [Service] Typesimple WorkingDirectory/opt/coolmonitor ExecStart/opt/coolmonitor/venv/bin/coolmonitor start Restarton-failure RestartSec5 Userroot [Install] WantedBymulti-user.target这里我用了Userroot方便读取系统指标和监控系统进程。如果你对权限隔离有要求可以创建专用用户但要确保该用户有读取/proc、/sys以及部分系统命令的权限否则采集数据会出现空洞。然后执行systemctl daemon-reload systemctl enable --now coolmonitor systemctl status coolmonitor看到active (running)就说明服务已经起来了。用ss -lntp | grep 8899确认端口在监听。3.5 通过 Nginx 反向代理并添加访问认证Coolmonitor 的服务本身是一个 Web 服务但如果直接裸奔到公网除了美观问题更重要的是安全。我建议在它前面加一层 Nginx只通过 80/443 端口对外提供服务并且加上简单的 Basic Auth 认证。安装 Nginxdnf install -y nginx生成认证密码文件dnf install -y httpd-tools htpasswd -c /etc/nginx/.coolmonitor_passwd admin然后配置 Nginx 站点。在/etc/nginx/conf.d/coolmonitor.conf里写server { listen 80; server_name monitor.example.com; auth_basic Coolmonitor Access; auth_basic_user_file /etc/nginx/.coolmonitor_passwd; location / { proxy_pass http://127.0.0.1:8899; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }这里有一个很容易踩的坑如果 Coolmonitor 监听的地址是127.0.0.1Nginx 才能通过proxy_pass http://127.0.0.1:8899访问如果监听的是0.0.0.0那就直接走端口转发了。配置完 Nginx 后检查语法nginx -t systemctl restart nginx最后别忘了在系统防火墙中放行 Nginx 对外端口firewall-cmd --permanent --add-port80/tcp firewall-cmd --permanent --add-port443/tcp firewall-cmd --reload到这一步Coolmonitor 已经可以通过浏览器访问了输入刚才设置的账号密码就能看到监控面板。4. 监控指标配置与告警通知4.1 添加被监控服务器与数据采集方式Coolmonitor 在单机模式下默认监控本机指标但在实际使用中我们往往需要把几台服务器统一纳入监控。这时候有两种方式一是通过 agent 采集二是通过 SSH 方式远程采集。我推荐 agent 方式因为 SSH 方式需要在管理机和被监控机之间频繁建立连接安全性更可控而且不会占用被监控机的额外账号权限。在被监控服务器上安装 agent 后在管理机的配置文件里加入节点信息nodes: - name: node01 address: 192.168.1.101 agent_port: 9100 - name: node02 address: 192.168.1.102 agent_port: 9100添加完节点后重启 Coolmonitorsystemctl restart coolmonitor正常情况下Coolmonitor 的面板里很快就能看到新节点的心跳数据。如果一直没有数据优先检查被监控机的 agent 端口是否被防火墙拦截以及代理端口监听是否正常。4.2 常用监控指标与合理阈值设置Coolmonitor 默认会采集 CPU、内存、磁盘、网络、系统负载这几大类指标。对于每项指标我建议不要照抄网上的阈值而是结合你的业务特征来定。下面这张表是我在自己的环境中常用的一组初始值指标警告阈值严重阈值说明CPU 使用率80% 持续 5 分钟95% 持续 3 分钟避免瞬时峰值误报内存使用率85%95%关注是否触发 swap根分区磁盘空间剩余空间低于 20%剩余空间低于 10%监控根分区容易踩到日志写满的雷磁盘 IO 使用率80%部分环境建议忽略机械盘与 SSD 表现差异大系统负载核数的 1 倍核数的 2 倍结合nproc判断关键 TCP 端口连接失败连续 2 次探测失败适合监控业务端口阈值配置在config.yaml中大致的写法是alerts: cpu_percent: warn: 80 crit: 95 duration: 300 disk_free_percent: warn: 20 crit: 10注意duration参数很关键。它表示指标持续超过阈值多久后才会触发告警能够有效过滤掉瞬时尖峰。比如 CPU 在某个瞬间飙到 99%但几秒钟又回落如果设置 5 分钟持续判断就不会收到一条让人白紧张的告警。4.3 告警通知邮件、Webhook 与群机器人告警如果不能及时送到人手里监控的价值就少了一大半。Coolmonitor 常用两种通知渠道邮件和 Webhook。邮件适合传统企业配置 SMTP 即可Webhook 适合对接钉钉、企业微信这类群机器人。我个人更推荐 Webhook因为它可以直接把告警信息推到群里不需要进邮箱就能看到。邮件配置示例notify: email: smtp_host: smtp.example.com smtp_port: 465 smtp_user: monitorexample.com smtp_password: your-password to: - opsexample.comWebhook 配置示例notify: webhook: - name: dingtalk url: https://oapi.dingtalk.com/robot/send?access_tokenxxxx template: coolmonitorWebhook 的原理很简单Coolmonitor 在触发告警时向配置的 URL 发送一个 POST 请求内容包含告警名称、节点、当前值、阈值、触发时间等信息。钉钉、企业微信机器人本质上都是提供一个标准 Webhook 地址你把地址填进去就能收到消息。配置完以后一定要做一次测试。最稳妥的方式是临时把某个阈值调到极低比如把根分区磁盘空间告警阈值改成剩余空间低于 99%让服务在几秒内必然触发再观察通知是否送达。测试完记得把阈值改回来不然你的手机晚上会响个不停。4.4 避免告警轰炸连续触发、静默与恢复通知新手最容易犯的错误是把告警配置得过于敏感结果收到几条告警后发现是虚惊慢慢就不再关注监控消息了。我踩过这个坑之后养成了一套告警规则设计习惯。首先是设置“连续 N 次采集到异常才告警”相当于给告警加了去抖逻辑。其次是“同一告警在静默时间内只推送一次”比如 1 小时内相同节点的同一指标只通知一次防止每次轮询都触发。最后是“恢复通知”当指标回到正常范围后主动发一条恢复消息这样团队能闭环地知道故障已经解除。配置示例alerts: silence_minutes: 60 notify_recovery: true合理利用这三板斧之后监控群才能保持安静告警来了才真正有人重视。5. 常见问题与排查技巧实录5.1 依赖安装反复失败先排查 pip 源和编译环境Coolmonitor 安装过程中最常出现的问题集中在 Python 依赖安装阶段。症状一般是pip install卡住不动或者某个包编译时报gcc、Python.h not found之类的错误。遇到这种问题先别急着反复重试。第一步检查 pip 源用的是什么镜像如果默认源是官方 PyPI换成国内镜像会快很多。第二步检查系统是否已经安装python3-devel、gcc、openssl-devel这些基础包缺什么就装什么。第三步查看完整的报错日志很多包编译失败是因为某个底层库不在系统里而真正的报错信息往往藏在最后几行不要只看第一屏。如果你在离线环境安装建议提前把所有依赖包下载打包。这里有一个小事可以降低你的痛苦在联网机器上建一个虚拟环境执行 pip download 时把依赖一次性拉全再拷贝到目标机器安装要比一个个 rpm 去找依赖省事得多。5.2 服务已启动但页面打不开从端口、防火墙到 SELinux明明systemctl status coolmonitor显示服务在跑浏览器就是打不开这个问题的排查顺序很重要。我会按下面三步来走。第一步看监听地址ss -lntp | grep 8899如果只监听了127.0.0.1:8899那你从外部直接访问 IP 的 8899 端口肯定不行。这不是异常而是配置了本机回环监听需要通过 Nginx 代理访问。如果确实要让外部直接访问就把配置里的server.host改成0.0.0.0。第二步看防火墙firewall-cmd --list-all确认 80、443 或者 8899 端口是否放行。很多时候你明明加了端口却忘了加--permanent导致重启后规则丢失。第三步看 SELinux。openEuler 开启了 SELinux 的系统上Nginx 去代理一个本机端口可能会被 SELinux 策略拦掉。出现这种情况时用ausearch -m avc -ts recent查看拒绝日志或者临时允许 Nginx 发起网络连接setsebool -P httpd_can_network_connect 1这一步要谨慎不要随便把 SELinux 关闭先确认是不是它的原因再动策略。5.3 监控数据不刷新图表出现空洞服务运行没问题但监控图表上突然出现一段空洞这时候优先怀疑的不是 Coolmonitor而是系统权限和采集任务中断。第一类是权限问题。如果 Coolmonitor 使用普通用户运行而该用户没有权限读取某些/proc文件或执行iostat类命令采集到的指标就会是空值。我建议在验证阶段使用 root 用户跑通之后要降权的话再逐项确认采集功能是否完整。第二类是数据目录空间满或 SQLite 被锁。监控服务持续运行时间长了如果日志和数据库放在同一个分区一旦被其他文件占满空间SQLite 会写入失败。观察日志里有没有database is locked或disk I/O error这类问题十有八九是磁盘空间或者文件权限引起的。第三类可能更隐蔽系统时间跳变。如果你用 NTP 同步时间时出现了大的时间跳变图表的横坐标会异常甚至出现数据点无法写入的情况。检查系统时间是否同步正常必要时重启一次 Coolmonitor让它重新对齐时间。5.4 顺带提一个 openEuler 下常做的升级操作很多人在配监控之前会先做一波系统安全加固比如把 OpenSSH 离线升级到 10.5p1 这种较高版本。这个操作本身不难但我想提醒一句无论升级什么系统组件都别在远程连接的会话里直接重启服务除非你已经确认本地控制台或者带外管理可用。升级 OpenSSH 时一旦把 sshd 配置搞坏当前连接断开后可能就再也进不去了监控服务自然也就没人维护了。如果是离线升级建议先把新版本的 rpm 包和依赖包全部准备好再在脚本里加上回滚方案。安全加固是好事但稳定性同样重要。把这层基础打牢了Coolmonitor 的监控服务才能真正稳定地跑下去。最后分享一个小经验整个 Coolmonitor 部署过程走下来我最想强调的一点是监控服务本身也要被监控。以前我把 Coolmonitor 和业务放在同一块磁盘上结果业务日志把磁盘空间写满监控数据库也跟着遭殃最后连报警都没发出来。后来我把 Coolmonitor 的数据库目录单独挂到另一块盘上同时给业务日志加了 logrotate才彻底避免了这种“监控自己先挂”的窘境。另外配置文件和数据目录记得定期备份哪怕只是用 tar 打包放到另一台机器也能在意外事故后快速恢复一套可用的监控环境。先把自己兜住再去盯别人这才是监控系统该有的样子。