Featured image of post 『Blog』NeZha Monitoring 从一到无穷大

『Blog』NeZha Monitoring 从一到无穷大

哪吒监控敏捷部署

Preview

NeZha Monitoring Dashboard - Default Theme

简介

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

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

先决条件

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

  1. 准备一台或多台 VPS

    VPS 需要放行 8008 和 5555 端口。其中,8008 是面板端口,5555 用于传输被控节点的资源状态。

  2. 选择一台 VPS 作为面板节点

    在 Cloudflare 中解析两条 A 记录指向这个节点。其中一条用于 CDN 连接。在添加记录时,不要开启“小云朵”。Cloudflare 支持且默认开启 CDN WebSocket。

    对于面板节点而言,单核 512MB 内存的服务器配置就足以满足大多数使用场景。

    需要额外注意面板节点 80 和 443 端口的放行和占用情况。我们后续会使用 certbot 申请免费域名证书,请确保端口处于空闲状态。

  3. 一个用于 OAuth2.0 授权的 GitHub 账号

Get started

Setup

在一切开始前,我们假设(定义)如下变量:

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

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

GitHub OAuth2.0 应用申请

访问 New OAuth Application,注册一个新的 OAuth 应用:

ItemValue
Application name随便写,比如 NeZha Monitoring Dashboard
Homepage URL填 HTTPS 架构域名,比如 https://cdn.happy.live
Authorization callback URL同上,填写 NeZha 的redirect_urihttps://cdn.happy.live/oauth2/callback

注册完成后,New 一个 Client secrets ,并记下 Client IDClient 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安装完毕后,选择安装监控面板,分别输入以下值:

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

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

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

配置面板节点

申请证书

  1. 安装 certbot

    1
    2
    
    sudo apt update
    sudo apt install certbot
    
  2. 如果已运行 NGINX 请先停止它再运行脚本。如果其他进程占用了 80/443 端口,也会影响证书申请。

    1
    
    nginx -s stop
    
  3. 安装证书

    -d 后接证书绑定域名,也即,从 Cloudflare 解析到面板节点的 CDN 域名。

    1
    
    sudo certbot certonly --standalone --register-unsafely-without-email -d [你的面板CDN域名]
    
  4. 检查证书路径

    在默认情况下,证书文件 .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]
  1. 编排 NGINX 配置,在 http 配置组中添加如下 server 代理规则,修改 server_namessl_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;
        }
    }
    
  2. 检查 NGINX 配置文件是否配置正确

    1
    
    nginx -t
    
  3. 重启 NGINX,读入新的配置

    1
    
    sudo systemctl start nginx
    
  4. 检查 NGINX 运行状态

    1
    
    sudo systemctl status nginx
    

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

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

绑定面板服务器域名

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

添加被控节点

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

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

NeZha Dashboard
image-20230617233735311

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

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

Enable CDN

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

image-20230617234443457

Result

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

Advanced

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

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

以下是相关的基础概念:

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

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

  1. VPS / EC2 实例,只有单个 IPv4 的云服务器实例。这些实例由庞大的独立服务器集群虚拟化并分割出来。如果您直接管理多台物理机,那么 NeZha 不适合用作资源探针。
  2. 若干台服务器,数量 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: 细说,这个一句话讲不清楚!

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

  1. 游客:直接访问面板且还未登录的用户。
  2. 管理员:已被添加到面板的 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 之后,会发生以下两种情况:

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

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

Reference

Licensed under CC BY-NC-SA 4.0
  views
You will to enjoy grander sight / By climing to a greater height.
Built with Hugo
Theme Stack designed by Jimmy