『Blog』NeZha Monitoring 从一到无穷大

Preview

NeZha Monitoring Dashboard - Default Theme

简介

哪吒监控 是一个开源、轻量的服务器和网站监控、运维工具，它具备以下特点：

实时监控：支持同时监控多个服务器的系统状态，监控网页、端口、SSL证书状态等，并可配置故障、流量等状态报警。多种通知方式（Telegram、邮件、微信等）可供选择。
轻量运维：支持在线SSH，支持流量循环监控，支持设置定时任务、服务器批量执行任务。

先决条件

在下一节的速通攻略中，我们将介绍一种哪吒监控系统敏捷部署方案。面板节点使用 Cloudflare CDN + NGINX 反向代理 + HTTPS 域名架构，实现在线访问功能。开始操作前请确保你已具备如下先决条件：

准备一台或多台 VPS
VPS 需要放行 8008 和 5555 端口。其中，8008 是面板端口，5555 用于传输被控节点的资源状态。
选择一台 VPS 作为面板节点
在 Cloudflare 中解析两条 A 记录指向这个节点。其中一条用于 CDN 连接。在添加记录时，不要开启“小云朵”。Cloudflare 支持且默认开启 CDN WebSocket。
对于面板节点而言，单核 512MB 内存的服务器配置就足以满足大多数使用场景。
需要额外注意面板节点 80 和 443 端口的放行和占用情况。我们后续会使用 certbot 申请免费域名证书，请确保端口处于空闲状态。
一个用于 OAuth2.0 授权的 GitHub 账号

Get started

Setup

在一切开始前，我们假设（定义）如下变量：

面板 CDN 域名：如 cdn.happy.live。一切从外来流量访问这个域名。
面板直连域名：如 dash.happy.live。仅供 NeZha Monitoring 内部节点通信使用。

将你解析的域名同等替换即可。之后的操作以 Ubuntu20.04 为例。

GitHub OAuth2.0 应用申请

访问 New OAuth Application，注册一个新的 OAuth 应用：

Item	Value
Application name	随便写，比如 `NeZha Monitoring Dashboard`
Homepage URL	填 HTTPS 架构域名，比如 `https://cdn.happy.live`
Authorization callback URL	同上，填写 NeZha 的`redirect_uri`，`https://cdn.happy.live/oauth2/callback`

注册完成后，New 一个 Client secrets ，并记下 Client ID 和 Client secrets后面会用到。

拉起面板节点

SSH 连上面板节点，执行以下命令安装引导脚本<documentation>

1
curl -L https://raw.githubusercontent.com/naiba/nezha/master/script/install.sh  -o nezha.sh && chmod +x nezha.sh && sudo ./nezha.sh

等待Docker安装完毕后，选择安装监控面板，分别输入以下值：

Item	Action
OAuth提供商	回车选用默认配置，GitHub
Client ID	Client ID of your OAuth APP
Client Secret	Client Secret of your OAuth APP
用户名	Your GitHub username
站点标题	随便写
访问端口	回车选用默认配置，8008
Agent的通信端口	回车选用默认配置，5555

输入完成后，等待拉取镜像，安装结束后，如果一切正常，此时你可以访问 IP+端口号，如:

http://your-server-ip:8008，注意此时只能通过 HTTP 架构访问。

配置面板节点

申请证书

安装 certbot

1
2
sudo apt update
sudo apt install certbot

如果已运行 NGINX 请先停止它再运行脚本。如果其他进程占用了 80/443 端口，也会影响证书申请。
1
nginx -s stop
安装证书
-d 后接证书绑定域名，也即，从 Cloudflare 解析到面板节点的 CDN 域名。
1
sudo certbot certonly --standalone --register-unsafely-without-email -d [你的面板CDN域名]

检查证书路径

在默认情况下，证书文件 .pem 将被发送到以下路径：/etc/letsencrypt/live/[domain]/

1
2
3
4
# 证书文件路径
ssl_certificate: /etc/letsencrypt/live/[domain]/fullchain.pem 
# 私钥文件路径
ssl_certificate_key: /etc/letsencrypt/live/[domain]/privkey.pem 

配置 NGINX 反代

开始后续步骤前确保 80,443 端口空闲且 NGINX 服务处于未激活状态

1
2
3
4
5
6
7
8
# 查看 80 端口占用
lsof -i:80
# 查看 443 端口占用
lsof -i:443
# 关闭 NGINX 服务
sudo systemctl stop nginx
# 杀死占用 80/443 端口的游离进程
kill -9 [PID]

编排 NGINX 配置，在 http 配置组中添加如下 server 代理规则，修改 server_name、ssl_certificate 以及 ssl_certificate_key 字段，其他配置不动。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    listen 80;

    # 修改为你的 CDN 域名
    server_name DOMAIN; 

    # 修改证书路径
    ssl_certificate /etc/letsencrypt/live/DOMAIN/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/DOMAIN/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8008;
        proxy_set_header Host $http_host;
        proxy_set_header Upgrade $http_upgrade;
    }
    location ~ ^/(ws|terminal/.+)$  {
        proxy_pass http://127.0.0.1:8008;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
        proxy_set_header Host $http_host;
    }
}

检查 NGINX 配置文件是否配置正确
1
nginx -t
重启 NGINX，读入新的配置
1
sudo systemctl start nginx
检查 NGINX 运行状态
1
sudo systemctl status nginx

NGINX 启动后，访问 HTTPS 架构的面板 CDN 域名，如果一切正常，你将会看到和先前步骤中直接访问 http://ip:8008 一样的面板界面。

🐞 注意！我们一直在使用「面板 CDN 域名」作指代，但目前为止，我们仍没有为该条 A 纪录开启 Cloudflare CDN 。

绑定面板服务器域名

从浏览器里访问面板 CDN 域名，OAuth 登录验证管理员身份，进入后台。填写【设置 – 未接入CDN的面板服务器域名/IP】顾名思义，填写解析到面板节点的另一条 A 纪录的域名。

添加被控节点

回到面板的【主机】页面，点击【添加服务器】，根据你的喜好填写名称、服务器分组、排序和备注，这些都是可选项。勾选「对游客隐藏」。

添加完毕后，点击服务器组件的编辑按钮，在弹出的窗口里找到【Linux 一键安装】的命令，复制它。

SSH 连上你的被控节点，粘贴并运行一键安装命令。回到 Dashboard 的主页，如果一切正常，你可以看到处于「非离线」状态的被控节点信息。

重复这个操作，面板添加配置 → 复制指令 → 在被控节点中运行指令 → 添加成功。

Enable CDN

返回 Cloudflare DNS 配置页面，点击面板 CDN 域名的那条记录旁边的“小云朵”图标。等待 CDN 配置生效，时间短则十几秒，时间长则十几分钟。在此期间，您可以通过“隐私模式”标签页访问 CDN 域名，或在本地 ping CDN 域名，总之就是等。

Result

有关 Get started 的迷思和执行细节可以参考下文的「Advanced」部分。本文还未提及 NeZha Monitoring 的一些高级特性和服务组件，你可以逐步精进，详见 官方文档。

Advanced

哪吒监控基本概念与叙事结构

NeZha Monitoring 主要由两个部分组成：面板节点和被控节点。任何服务器都可以同时作为面板和被控节点，可以在服务器 A 上部署面板，以展示包括节点 A 在内的多个被控节点的资源状态。

以下是相关的基础概念：

面板节点（Dashboard Node）：用于展示被控节点的资源状态。
被控节点（Agent Node）：定期向面板节点传输本机的资源状态。
资源状态：包括节点的 CPU、内存、网络 I/O 等常见资源信息。默认情况下，每两秒更新并推送一次。

通常情况下，我们只需要在几台服务器中选择一台用于部署监控面板。同时，我们需要注意以下几点：

VPS / EC2 实例，只有单个 IPv4 的云服务器实例。这些实例由庞大的独立服务器集群虚拟化并分割出来。如果您直接管理多台物理机，那么 NeZha 不适合用作资源探针。
若干台服务器，数量 10 或以内的云服务器实例（低配小鸡）。如果您管理的实例超过这个规模且节点之间有非常明显的协同关系，或是管理的实例数量破百甚至达到数万百万的级别，大佬您可以选择一些成熟的 k8s 企业级应用。

访问权限与授权等相关问题

NeZha Monitoring 通过 OAuth2.0 识别 admin 并给予其（管理后台）和（所有被控节点）的访问权限。

在本文速通攻略中我们使用 GitHub 作为授权服务器，此外还可以将 GitLab、JihuLab 以及 Gitee 作为授权方（v0.15.1）。

对于首次使用 NeZha Monitoring 且对 OAuth2.0 比较陌生的玩家可能会有以下一系列的迷思：

Q: 是不是所有人都可以访问我的 NeZha 面板？

A: 对，在浏览器输入网址就可以访问前端面板。只要你的域名到 NeZha service 之间的通路正常，任何人访问面板域名都可以看到 Dashboard font-page。

Q: 那是不是意味着所有人都可以访问后台？

A：当然不，只有注册到 NeZha 面板的管理员用户才能访问后台。

Q: 那么 NeZha 如何区分哪些用户是管理员呢？

A: 细说，这个一句话讲不清楚！

首先，我们需要定义「游客用户」和「管理员用户」两种角色。

游客：直接访问面板且还未登录的用户。
管理员：已被添加到面板的 Admin List 中的用户。

这里的 OAuth2.0 授权过程可以认为是 NeZha 向 GitHub 要了你的 username ，也即，前文我们所说的“授权”，其实指的是你允许 NeZha 获取你 GitHub 账号的数据。在这里，NeZha 只获取了你的 user-data，这包含了你的 GitHub username。

获取到你的 username 之后，NeZha 就可以比对你的 username 和注册到 Admin List 的 username，区分你是「游客」还是「管理员」。当然，GitHub username 是唯一的，这里不会出现“重名”的情况。

值得一提的是，NeZha 没有用户分级机制，也即，你要么是游客要么是管理员，不存在一个“普通用户”的中间态说法。

Q: 那我明白了，回到最初的那个问题，既然「所有人都可以访问我部署的面板」，那是不是意味着这些「游客」都可以看到我的被控节点状态？

A: 你这后半句有歧义啊，NeZha 没有设计特权机制（Privilege），所以没有“这些游客”或是“部分游客”的说法，也即，对于某个被控节点来说，要么所有的游客都可以看到它的资源状态，要么所有的游客都不行。

如果你走过前文的速通攻略，你会发现在添加被控节点的时候有个「对游客隐藏」的选项，如果勾选了，那么这个节点在我们直接访问站点且还未“以管理员身份登录”的情况下是不可见的。

上文说到 NeZha 没有用户分级机制，你要么是游客要么是管理员，NeZha 会阻止非管理员用户访问「对游客隐藏」的被控节点。

换句话说，在你授权 NeZha 获取到你的 username 之后，会发生以下两种情况：

你是管理员，开放管理后台和所有被控节点的访问权限
你是不是管理员，要么看到“空白页”，要么能看到「没有对游客隐藏」的被控节点的资源状态

也即，如果你已经意识到你没有该 NeZha 站点的管理员账号，你可以提前对自己说「我就来看看」。