1. 项目概述一个现代化的服务器监控与探针解决方案最近在折腾服务器运维发现一个挺有意思的开源项目叫hanshuaikang/nezha。这名字挺特别直接音译过来就是“哪吒”听起来就有点“三头六臂”、神通广大的意思。实际上它也确实是一个功能相当全面的服务器监控和探针工具。简单来说它就像给你的服务器集群装上了一双“千里眼”和“顺风耳”让你能随时随地掌握每一台服务器的“健康状况”——CPU、内存、磁盘、网络流量这些基础指标自不必说还能监控服务进程、网站端口甚至集成告警通知。对于手里有几台、几十台甚至更多VPS、云主机或者物理服务器的开发者、运维或者站长来说这种工具简直是刚需。传统的监控方案比如 Zabbix、Prometheus Grafana功能固然强大但部署和配置的门槛相对较高对于轻量级应用或者个人用户来说显得有些“杀鸡用牛刀”。而一些轻量的单机监控脚本又缺乏统一的管理界面和聚合视图。nezha的出现正好填补了这个空白。它采用了一个非常清晰的架构一个统一的 Dashboard面板或称“面板端”和部署在各个被监控服务器上的 Agent探针或称“客户端”。Agent 负责采集数据并上报Dashboard 负责接收、存储、展示数据和发送告警。这种主从架构既保证了集中管理的便利性又通过分布式采集减轻了单点压力。我最初被它吸引是因为它的 Dashboard 界面非常清爽现代数据可视化做得不错而且支持多用户、多服务器分组权限管理也够用。更重要的是它的 Agent 非常轻量资源占用极小对生产环境的影响可以忽略不计。无论是想监控自己的博客服务器、游戏服务器还是一个小型的企业应用集群nezha都能提供一个快速上手的解决方案。接下来我就结合自己的部署和使用经验详细拆解一下这个项目的核心设计、实操要点以及那些官方文档可能没细说的“坑”。2. 架构设计与核心组件解析2.1 主从式监控模型Dashboard 与 Agent 的分工nezha的核心架构采用了经典的主从Master-Slave或服务端-客户端Server-Agent模型。理解这个模型是后续一切部署和配置的基础。Dashboard服务端/面板这是整个监控系统的“大脑”和“指挥中心”。它通常运行在一台独立的、网络可达的服务器上这台服务器本身也可以被监控。它的核心职责包括提供 Web 管理界面用户通过浏览器访问 Dashboard查看所有被监控服务器的状态、图表和历史数据。接收与存储数据监听一个特定的端口默认是8000或8888接收来自各个 Agent 定时上报的监控数据。这些数据会被存储在内置的数据库如 SQLite或你配置的外部数据库中。处理告警规则Dashboard 中定义了各种告警规则例如 CPU 使用率超过 80% 持续 5 分钟。它会持续评估接收到的数据一旦触发规则就通过集成的通知渠道如 Telegram Bot、钉钉、微信、邮件等发送告警信息。管理 Agent在 Dashboard 上添加服务器时会生成一个唯一的、包含连接密钥的 Agent 安装命令。这个密钥确保了只有授权的 Agent 才能向该 Dashboard 上报数据实现了简单的认证和安全控制。Agent客户端/探针这是部署在每一台需要被监控的服务器上的“侦察兵”。它的职责非常专一本地数据采集以很高的频率默认每秒采集所在服务器的各项指标包括系统负载、CPU 使用率、内存使用量、磁盘空间、磁盘 IO、网络流量进出、当前运行的进程列表等。服务状态探测根据 Dashboard 下发的配置定期探测指定的 TCP 端口或执行自定义的脚本来判断某个服务如 Nginx、MySQL、Redis或网站是否存活。数据上报将采集和探测到的数据通过 HTTPS 或 WebSocket 等加密通道定时默认每 60 秒上报到指定的 Dashboard 地址。执行任务可以接收来自 Dashboard 的指令执行一些预定义的任务例如重启某个服务。这种分离的架构好处很明显。Dashboard 可以集中精力做数据展示、分析和告警无需关心底层服务器的异构性。Agent 则极其轻量只负责采集和上报即使 Dashboard 短暂不可用Agent 也能在本地缓存数据待恢复后补报保证了数据的连续性。对于运维人员来说你只需要维护一个 Dashboard然后通过一条命令就能无限扩展被监控的节点。2.2 数据流与通信安全数据是如何安全地从 Agent 流向 Dashboard 的呢这里涉及两个关键点通信协议和认证方式。默认情况下nezha的 Dashboard 和 Agent 之间推荐使用TLS 加密通信。这意味着你需要为 Dashboard 配置一个域名并申请 SSL 证书可以使用 Let‘s Encrypt 的免费证书。这样做的好处是所有监控数据在传输过程中都是加密的防止被中间人窃听或篡改。特别是在 Agent 需要通过公网向 Dashboard 上报数据时TLS 是必须的。如果是在纯粹的、可信的内网环境中部署为了简化也可以使用 HTTP 明文通信但强烈不推荐因为监控数据中可能包含系统信息。认证机制靠的是“连接密钥”。当你在 Dashboard 上添加一台新服务器时系统会生成一个唯一的密钥Secret Key。这个密钥会被嵌入到 Agent 的启动命令或配置文件中。Agent 每次上报数据时都会携带这个密钥。Dashboard 端会验证密钥的有效性只有匹配的请求才会被接受。这相当于为你的监控系统设置了一道简单的门禁防止未经授权的服务器胡乱上报数据污染你的监控视图。注意这个密钥是每台服务器唯一的并且拥有该密钥的 Agent 就拥有了向对应服务器条目上报数据的权限。因此密钥需要妥善保管不应泄露。一旦怀疑泄露应在 Dashboard 上立即重置该服务器的密钥并更新所有相关 Agent 的配置。2.3 存储与可扩展性考量默认情况下nezha的 Dashboard 使用SQLite作为数据存储。SQLite 是一个单文件数据库无需单独部署数据库服务这对于个人用户或服务器数量不多例如少于50台的场景来说是极其方便和轻量的选择。所有监控数据、配置信息都存储在一个.db文件里备份和迁移都很简单。但是SQLite 在应对高并发写入大量 Agent 频繁上报和存储海量历史数据比如保存半年以上的秒级监控数据时性能可能会成为瓶颈。对于企业级应用或大规模监控场景nezha也支持切换到更强大的MySQL或PostgreSQL数据库。在项目规划初期你就需要根据预期的服务器规模和数据保留策略来做出选择。如果未来可能扩展到上百台服务器并需要长期存储数据进行分析那么一开始就使用 MySQL/PostgreSQL 是更稳妥的方案可以避免后期数据迁移的麻烦。对于绝大多数个人和小团队项目SQLite 足以胜任它的简单性是巨大的优势。3. 从零开始部署 Dashboard 服务端3.1 环境准备与依赖检查部署 Dashboard 首先需要一台服务器。这台服务器将成为你的监控中心因此它本身最好比较稳定并且有固定的公网 IP 或域名。配置上不需要很高1核1G内存的云主机就完全足够运行nezha的 Dashboard。系统方面主流的 Linux 发行版都可以比如 Ubuntu 20.04/22.04 LTS、CentOS 7/8、Debian 11 等。这里我以Ubuntu 22.04为例进行说明其他系统的命令略有差异但思路一致。首先通过 SSH 连接到你的 Dashboard 服务器进行基本的系统更新和依赖安装sudo apt update sudo apt upgrade -y sudo apt install -y curl wget git vim unzipnezha的 Dashboard 是一个 Go 语言编写的二进制文件理论上只需要下载对应的可执行文件即可运行。但为了便于管理和持久化运行我们通常会用到Docker或者systemd服务。Docker 方式更加隔离和方便是官方推荐的方式因此我们主要介绍 Docker 部署。确保你的系统已经安装了 Docker 和 Docker Compose# 安装 Docker curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh sudo systemctl enable docker sudo systemctl start docker # 安装 Docker Compose (v2) sudo curl -L https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose sudo chmod x /usr/local/bin/docker-compose3.2 使用 Docker Compose 一键部署Docker Compose 允许我们通过一个docker-compose.yml文件来定义和运行多个容器对于nezha这种可能涉及 Dashboard 和数据库如果不用 SQLite的服务来说管理起来非常清晰。首先创建一个工作目录并编写配置文件mkdir -p ~/nezha-dashboard cd ~/nezha-dashboard vim docker-compose.yml将以下内容写入docker-compose.yml文件。这里我们采用 SQLite 作为数据库并配置了持久化数据卷version: 3.8 services: nezha-dashboard: image: ghcr.io/naiba/nezha-dashboard:latest container_name: nezha-dashboard restart: always ports: - 8000:8000 # 将容器内的8000端口映射到宿主机的8000端口 volumes: - ./data:/data # 持久化存储 SQLite 数据库和配置文件 - ./resource:/resource # 可选用于存放自定义主题等资源文件 environment: - TZAsia/Shanghai # 设置时区 - DEBUGfalse # 生产环境建议关闭调试模式 # 注意更关键的数据库连接、密钥等配置需要通过环境变量或配置文件传入这里先搭建基础这个配置创建了一个名为nezha-dashboard的容器使用了官方的最新镜像并设置了自动重启。数据目录./data会被映射到容器内的/data这样即使容器被删除你的监控数据和配置也不会丢失。现在启动服务docker-compose up -d使用docker-compose logs -f可以查看实时日志确认服务是否正常启动。如果看到监听端口的日志说明基础容器运行成功了。3.3 关键配置详解环境变量与安全设置上面启动的只是一个“空壳”要让 Dashboard 真正工作起来必须提供关键的配置信息。nezhaDashboard 主要通过环境变量来配置。我们需要修改docker-compose.yml注入这些变量。一个生产环境可用的配置示例请务必修改以下所有尖括号 中的内容为你自己设定的值version: 3.8 services: nezha-dashboard: image: ghcr.io/naiba/nezha-dashboard:latest container_name: nezha-dashboard restart: always ports: - 8000:8000 volumes: - ./data:/data - ./resource:/resource environment: - TZAsia/Shanghai - DEBUGfalse # 数据库配置使用 SQLite - DB_TYPEsqlite - DB_SQLITE_FILE/data/nezha.db # Dashboard 访问密钥用于登录管理后台务必设置强密码 - DASHBOARD_USERNAME你的管理员用户名 - DASHBOARD_PASSWORD你的强密码 # JWT 签名密钥用于生成登录令牌务必使用长随机字符串 - JWT_SECRET一个非常长的随机字符串可用 openssl rand -base64 32 生成 # 服务监听地址和端口容器内 - HTTP_HOST0.0.0.0 - HTTP_PORT8000 # 站点标题 - SITE_TITLE我的哪吒监控面板 # 自定义公告支持 HTML - CUSTOM_NOTICEb欢迎使用监控系统/b 所有服务器运行状态将在此展示。参数解读与避坑指南DASHBOARD_USERNAME/PASSWORD这是你登录 Dashboard Web 界面的账号密码。千万不要使用默认值或弱密码否则你的监控面板将毫无安全可言。JWT_SECRET这是 JSON Web Token 的签名密钥用于保持用户的登录状态。如果这个密钥泄露或过于简单攻击者可能伪造登录凭证。务必使用一个足够长且随机的字符串。可以在服务器上运行openssl rand -base64 32来生成一个。DB_SQLITE_FILE指定了 SQLite 数据库文件的路径。我们通过卷映射./data:/data所以数据库文件实际保存在宿主机的~/nezha-dashboard/data/nezha.db。定期备份这个data目录就是备份了你的全部监控配置和历史数据。端口映射8000:8000意味着外部通过宿主机的 8000 端口访问服务。你可以根据情况修改前面的宿主端口比如8080:8000。更新完docker-compose.yml后需要重启容器使配置生效docker-compose down docker-compose up -d现在你应该可以通过http://你的服务器IP:8000访问到 Dashboard 的登录界面了。使用上面设置的用户名和密码登录。3.4 配置域名、SSL 与反向代理进阶直接通过 IP 和端口访问既不安全也不方便。最佳实践是绑定一个域名并配置 SSL 证书然后通过 Nginx 或 Caddy 等反向代理服务器来访问。为什么需要反向代理SSL 终止由 Nginx/Caddy 处理 HTTPS 加密解密减轻 Dashboard 容器的负担。端口管理可以用标准的 80/443 端口提供服务无需记忆特殊端口。负载均衡与缓存未来如果扩展可以方便地做负载均衡。统一入口可以在同一域名下通过路径如/nezha挂载多个服务。这里以Nginx为例假设你已有一个域名monitor.yourdomain.com并解析到了 Dashboard 服务器的 IP。首先安装 Nginx 并申请 SSL 证书以 Certbot 为例sudo apt install -y nginx certbot python3-certbot-nginx sudo certbot --nginx -d monitor.yourdomain.com按照 Certbot 的提示操作它会自动为你配置好 SSL。然后编辑 Nginx 的站点配置文件sudo vim /etc/nginx/sites-available/monitor.yourdomain.com添加如下配置server { listen 80; server_name monitor.yourdomain.com; # 将 HTTP 请求重定向到 HTTPS return 301 https://$server_name$request_uri; } server { listen 443 ssl http2; server_name monitor.yourdomain.com; # SSL 证书路径Certbot 会自动配置好 ssl_certificate /etc/letsencrypt/live/monitor.yourdomain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/monitor.yourdomain.com/privkey.pem; # 反向代理到本地的 Dashboard 容器 location / { proxy_pass http://127.0.0.1:8000; # 指向 docker-compose 映射的端口 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_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; # 支持 WebSocket proxy_read_timeout 300s; proxy_send_timeout 300s; } # 可选静态资源缓存 location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ { expires 1y; add_header Cache-Control public, immutable; proxy_pass http://127.0.0.1:8000; } }启用配置并测试sudo ln -s /etc/nginx/sites-available/monitor.yourdomain.com /etc/nginx/sites-enabled/ sudo nginx -t # 测试配置语法 sudo systemctl reload nginx # 重载 Nginx 配置现在你就可以通过https://monitor.yourdomain.com安全地访问你的nezhaDashboard 了。别忘了在 Dashboard 的环境变量或后续 Agent 配置中使用这个 HTTPS 地址作为上报地址。4. 在被监控服务器上部署 Agent4.1 获取 Agent 安装命令Dashboard 部署并配置好后下一步就是让被监控的服务器“报到”。所有操作都在 Dashboard 的 Web 界面中完成。使用之前设置的管理员账号密码登录 Dashboard。在左侧菜单找到“服务器”或“主机”选项点击进入。点击“添加服务器”或类似的按钮。在弹出的表单中填写这台服务器的备注名称如“美国 VPS - 博客站”选择分组可以新建分组如“生产环境”、“测试环境”。点击保存或添加后Dashboard 会为这台服务器生成一个唯一的连接密钥Secret Key并显示一条Agent 安装命令。这条安装命令是核心它通常长这样示例curl -L https://raw.githubusercontent.com/naiba/nezha/master/script/install.sh -o nezha.sh chmod x nezha.sh sudo ./nezha.sh install_agent 你的Dashboard域名或IP 生成的Secret Key这条命令做了以下几件事从 GitHub 下载官方的安装脚本nezha.sh。赋予脚本执行权限。以 root 权限运行脚本并传入两个关键参数Dashboard 的地址和该服务器独有的密钥。重要提示每个服务器对应的密钥都是唯一的。不要在多台服务器上使用同一个密钥否则数据会混乱。也不要将这条包含密钥的命令公开分享。4.2 执行安装与验证登录到你需要监控的目标服务器Agent 端将上一步获取的完整命令粘贴执行。脚本会自动完成以下工作检测当前系统的发行版支持 CentOS、Debian、Ubuntu、Alpine 等。根据系统安装必要的依赖如systemctl、curl等。下载对应系统架构amd64, arm64, armv7等的nezha-agent二进制文件。创建系统服务通常是nezha-agent.service并配置好启动参数包含 Dashboard 地址和密钥。启动 Agent 服务并设置为开机自启。安装完成后你可以通过以下命令检查 Agent 的运行状态systemctl status nezha-agent.service如果看到active (running)的字样说明 Agent 已经在运行并开始尝试连接 Dashboard。回到 Dashboard 的服务器列表页面稍等片刻最多一分钟你应该能看到新添加的服务器状态从“离线”变为“在线”并且开始有基础的系统信息如 IP、系统版本和实时监控图表CPU、内存等显示出来。4.3 Agent 的配置管理与高级参数安装脚本通常使用默认配置。但有时我们需要对 Agent 进行更精细的控制比如修改数据上报间隔、设置 HTTP 代理等。Agent 的配置文件通常位于/etc/nezha/agent.config或/opt/nezha/agent/config.conf具体路径安装脚本会有提示。一个典型的配置文件内容如下server: host: https://monitor.yourdomain.com # Dashboard 地址必须带协议头 port: 443 # 如果 Dashboard 在非标准端口需指定 tls: true # 是否启用 TLS通常为 true secret: your_server_secret_key_here # 密钥 agent: report_delay: 60 # 数据上报间隔单位秒。默认60太短会增加负载太长则监控不实时。 skip_conn: false # 是否跳过连接数监控某些系统可能不支持 skip_procs: false # 是否跳过进程监控 # 可以设置 HTTP 代理用于网络受限的环境 # http_proxy: http://your-proxy:port修改配置文件后需要重启 Agent 服务使其生效sudo systemctl restart nezha-agent.service实操心得report_delay是一个需要权衡的参数。对于需要快速响应的生产服务器保持默认的 60 秒是合理的。对于个人项目或不那么关键的服务器可以适当调大到 120 或 180 秒以减少网络请求和对 Dashboard 的压力。除非必要不建议低于 30 秒。5. Dashboard 功能深度使用与定制5.1 监控面板与图表解读当服务器上线后Dashboard 的主界面就是你的监控“仪表盘”。通常以卡片或列表形式展示所有服务器。点击任意服务器可以进入详情页。详情页通常包含以下几个核心板块概览Overview显示服务器的基础信息如主机名、操作系统、内核版本、上线时间、IP 地址等。资源监控ResourcesCPU显示总使用率以及每个核心的使用率曲线。可以清晰看到负载高峰。内存Memory显示已用、缓存、缓冲、空闲内存的比例和趋势。需要特别注意 Swap交换分区的使用率如果持续较高说明物理内存严重不足。磁盘Disk列出所有挂载点显示使用率和剩余空间。这里可以设置告警防止磁盘写满导致服务崩溃。网络Network显示每个网络接口的实时流入/流出带宽。对于按流量计费的云服务器监控这个非常有用。进程Processes实时显示消耗资源CPU、内存最多的前几个进程。这是快速定位“谁吃掉了我的资源”的利器。服务监控Services这里展示你配置的端口监控和脚本监控的结果。图表支持自定义时间范围查看历史趋势这对于分析性能瓶颈、排查历史问题至关重要。例如你可以查看过去24小时内 CPU 使用率的曲线找出规律性的高峰进而优化定时任务或扩容。5.2 服务与端口监控配置仅仅监控系统资源是不够的。我们更关心跑在服务器上的业务服务是否正常。nezha提供了两种服务监控方式端口监控和脚本监控。端口监控用于检查一个网络服务如 Web 服务器、数据库是否在监听指定端口。在服务器详情页或全局的“服务监控”页面点击添加。选择监控类型为“端口TCP”。填写显示名称如 “Nginx Web Service”。填写目标地址和端口。对于本机服务地址通常是127.0.0.1或localhost端口就是服务的监听端口如 Nginx 是80或443。设置检查间隔如 60 秒和超时时间。保存后nezha的 Agent 会定期尝试建立 TCP 连接到该地址端口。如果连接成功则标记为“正常”失败则标记为“异常”并可能触发告警。脚本监控这是更强大的功能用于执行自定义的 Shell 或 Python 脚本通过脚本的退出状态码Exit Code来判断服务状态。0 代表成功/正常非 0 代表失败/异常。在 Agent 所在服务器上编写一个检测脚本。例如检测 MySQL 是否可用的脚本check_mysql.sh#!/bin/bash # 尝试连接本地 MySQL执行一个简单查询 if mysql -h 127.0.0.1 -u root -pyour_password -e SELECT 1; /dev/null 21; then exit 0 # 成功 else exit 1 # 失败 fi安全警告脚本中如果包含密码务必设置严格的文件权限如chmod 700避免密码泄露。在 Dashboard 添加监控类型选择“脚本”。填写脚本在 Agent 服务器上的绝对路径如/usr/local/bin/check_mysql.sh。设置执行间隔和超时。Agent 会定期运行这个脚本并根据退出码更新监控状态。脚本监控的灵活性极高你可以检查任何东西数据库查询是否超时、特定文件是否存在、API 接口返回是否正确、证书是否即将过期等等。5.3 告警通知渠道集成监控的价值在于出现问题能及时知道。nezha内置了丰富的告警通知渠道。配置通知方式在 Dashboard 的设置中找到“通知设置”或“告警通道”。选择渠道支持 Telegram Bot、钉钉群机器人、企业微信机器人、飞书机器人、邮件SMTP、Webhook 等。选择你常用的一个进行配置。以 Telegram Bot 为例你需要先通过BotFather创建一个 Bot获取它的token。然后创建一个频道或群组将 Bot 拉进去并发送一条消息。最后通过一个特殊的 API (https://api.telegram.org/botyour_bot_token/getUpdates) 获取你频道的chat_id。将token和chat_id填入 Dashboard 的 Telegram 配置中即可。以 SMTP 邮件为例需要提供发件邮箱的 SMTP 服务器地址、端口、加密方式SSL/TLS、账号、密码以及收件人邮箱。设置告警规则在服务器或服务监控的配置中可以设置触发告警的条件。例如CPU 使用率 90% 持续 2 分钟内存使用率 85% 持续 2 分钟磁盘使用率 90%服务监控状态变为“异常”关联通知在告警规则中选择上一步配置好的通知渠道。当条件触发时Dashboard 就会通过你选择的方式发送告警信息。告警信息通常包含服务器名称、监控项、当前值、触发时间等帮助你快速定位问题。实操心得告警规则不宜设置得过于敏感否则容易产生“告警疲劳”导致真正的告警被忽略。建议从较宽松的阈值开始如 CPU 95%持续 5 分钟根据实际情况逐步调整。对于核心业务服务告警阈值可以设得紧一些对于非核心或测试环境可以设得松一些甚至只记录不通知。5.4 多用户与权限管理如果你是团队使用nezha支持多用户和简单的权限控制。创建用户在 Dashboard 的管理员设置中可以创建新用户。分配权限可以为用户分配两种主要角色管理员拥有所有权限可以管理服务器、监控项、告警规则、其他用户等。普通用户/查看者通常只能查看监控数据无法进行任何修改操作。你还可以进一步限制其只能查看特定分组的服务器。分组管理将服务器划分到不同的分组如“研发部”、“运维部”、“项目A”然后将分组权限授予相应用户。这样开发人员只能看到他们负责的项目服务器运维可以看到所有实现了简单的权限隔离。这个功能对于小团队协作非常有用避免了所有人都使用同一个管理员账户。6. 日常运维、问题排查与性能优化6.1 监控数据的维护与清理随着时间推移监控数据会不断累积。SQLite 数据库文件会越来越大可能影响 Dashboard 的查询性能。nezha本身没有自动清理历史数据的功能需要手动或通过计划任务处理。清理旧数据你可以直接连接到 SQLite 数据库删除早于某个时间点的记录。但操作数据库有风险建议先备份。# 进入 Dashboard 容器如果使用 Docker docker exec -it nezha-dashboard sh # 或者直接操作宿主机的数据库文件 sqlite3 /path/to/your/nezha.db # 在 sqlite 命令行中删除比如30天前的监控历史数据谨慎操作先确认表名 # DELETE FROM monitor_history WHERE created_at datetime(now, -30 days); # DELETE FROM system_monitor WHERE created_at datetime(now, -30 days); # .exit更安全的方式是编写一个清理脚本并通过crontab定期执行。或者定期将旧的数据库文件备份后新建一个空的数据库文件需要重新添加服务器和配置。备份数据最简单的备份就是定期复制整个data目录如果你用了 Docker 卷映射。可以写一个简单的脚本#!/bin/bash BACKUP_DIR/backup/nezha DATE$(date %Y%m%d_%H%M%S) cp -r /path/to/nezha-dashboard/data $BACKUP_DIR/data_$DATE # 可以配合 tar 压缩和 scp 传输到远程然后将此脚本加入 crontab每周或每天执行一次。6.2 常见问题与故障排查在实际使用中你可能会遇到以下问题1. Agent 显示“离线”检查网络连通性在 Agent 服务器上执行curl -v https://你的Dashboard地址看是否能正常访问。检查防火墙是否放行了 Dashboard 的端口通常是 443。检查密钥确认 Agent 配置文件中secret的值与 Dashboard 上该服务器显示的密钥完全一致没有多余空格或换行。检查 Agent 服务状态systemctl status nezha-agent.service查看是否运行正常journalctl -u nezha-agent.service -f查看实时日志通常会有连接错误的提示。检查时间同步确保 Dashboard 和 Agent 服务器的时间基本同步时差在几分钟内否则 TLS 证书验证可能失败。2. 监控数据不更新或延迟很大检查 Agent 上报间隔查看 Agent 配置文件中的report_delay设置。检查 Dashboard 负载登录 Dashboard 服务器查看 CPU、内存、磁盘 IO 是否过高。可以使用docker stats查看容器资源使用情况。检查网络延迟如果 Agent 和 Dashboard 跨国或跨运营商网络延迟和丢包可能导致上报超时。可以尝试适当增加 Agent 配置中的超时时间。3. 告警通知收不到检查通知渠道配置测试通知渠道是否配置正确。例如对于 Telegram Bot可以尝试用curl命令手动发送一条消息看是否能收到。检查告警规则确认告警规则的条件设置是否正确是否已经达到触发条件。查看 Dashboard 日志Dashboard 容器日志中可能会有发送告警失败的错误信息。4. 进程列表不显示或不全某些精简版的 Docker 镜像或特殊配置的系统中Agent 可能无法正确读取/proc下的进程信息。可以尝试在 Agent 配置中设置skip_procs: true跳过进程监控。6.3 性能优化与高可用思考对于大规模部署可以考虑以下优化Dashboard 性能如果监控节点很多数百台SQLite 可能成为瓶颈。考虑迁移到 MySQL/PostgreSQL。同时确保 Dashboard 服务器有足够的内存和 CPU。数据库优化定期清理历史数据对于 MySQL/PostgreSQL可以为时间字段创建索引以加速查询。Agent 资源占用nezha-agent本身非常轻量通常只占用几 MB 内存和极少的 CPU。但如果监控项特别是脚本监控非常多且执行频繁可能会增加负载。合理安排脚本的执行间隔。高可用方案nezha的 Dashboard 本身是单点。对于要求高可用的生产环境可以考虑以下思路冷备定期备份数据库和配置。当主 Dashboard 宕机时快速在另一台服务器上恢复。热备复杂可以尝试部署两个 Dashboard 实例共享同一个后端数据库MySQL/PostgreSQL。但需要解决 Agent 连接切换的问题可能需要一个负载均衡器或 DNS 轮询并且要处理可能的数据冲突。这不是官方支持的功能需要自行探索和测试。6.4 安全加固建议Dashboard 访问安全务必使用 HTTPS并设置强密码的登录账号。可以考虑通过 Nginx 配置额外的 HTTP 基础认证或者将 Dashboard 部署在内网通过 VPN 访问。Agent 密钥管理密钥相当于 Agent 的密码不要泄露。考虑使用配置管理工具如 Ansible来安全地分发和更新 Agent 配置。最小权限原则为 Agent 的运行创建一个专用的系统用户而不是直接使用 root。虽然安装脚本默认用 root 是为了方便但在安全要求高的环境可以手动调整。定期更新关注nezha项目的 GitHub 发布页定期更新 Dashboard 和 Agent 到新版本以获取功能更新和安全修复。nezha作为一个开源项目其简洁的设计和足够的灵活性使得它能够很好地适应从个人到中小团队的多种监控场景。它可能没有商业监控软件那样面面俱到的功能但“够用、好用、易部署”就是它最大的优势。通过合理的配置和持续的运维它能成为你服务器运维工作中一个非常得力的助手。