监控 on GenshinMinecraftの小小藏身地

NodeGet Static Bucket 功能 & 方便主题搭建

Sun, 17 May 2026 00:00:00 +0000

NodeGet Static Bucket 功能 & 方便主题搭建

前言

Hi，这里是 GenshinMinecraft

官方文档：https://nodeget.com
Telegram 频道：@NodeGetProject
Telegram 讨论组：@NodegetGroup
前端 Dashboard 仓库：NodeSeekDev/NodeGet-board
前端 Status Board 仓库：NodeSeekDev/NodeGet-StatusShow
Nodeseek 社区：https://nodeseek.com

之前有非常多的 NodeGet Status Show 的搭建教程，不论是 Docker，CloudFlare Pages，或者是各路教程部署

都有一个共同缺点，太麻烦了

所以我们在 v0.2.x 引入了 Static Bucket 功能

简介

Static Bucket 功能可以被理解成本地的一个极其简易的 HTTP 服务器，可以简单类比 Cloudflare Pages

他会在本地 ./static 目录下维护文件夹 (可配置)，具体目录如下:

./static/status_show(Static Bucket Path)

它提供了基于 JSON-RPC 的 API，可以自定义挂载的目录，甚至你可以嵌套

./static/status_show(Static Bucket Path)/
./static/status_show/SomeOtherThings/

类似这样

还可以将其挂载到 / 目录，访问 NodeGet 提供的端口就可以直接访问 Status Show 面板

甚至甚至，你可以直接把它当作 WebDAV 服务器，连接到 /nodeget/static-webdav/{name}，username 是 TokenKey，password 是 TokenSecret，配合优秀 Token 权限系统，完全可以作为文件管理使用

意义

这样做的意义是什么？很简单:

你可以同时使用多个主题，都可以连接到同一个后端（甚至你可以做到每次访问随机换一个主题）
不止可以存放主题，还可以存放任何静态数据（比如我的博客目前就跑在 NodeGet Status Bucket 上）
官方 Dashboard 已经更新，可以编写管理

我们适配了一个按钮，类似:

如果你的 NodeGet Dashboard 已经连接上了后端，并且版本已经更新到 v0.2.x

点击上面的按钮就可以快捷部署官方 Status Show 展示面板，不再需要麻烦的 Pages 等

如果你很喜欢一个使用了符合最新规范的主题，直接输入他面板的链接，就可以直接下载他的主题 ~~(扒下他的衣服，给自己穿上)~~

主题开发者必读

如果你是一位主题开发者，也欢迎内嵌类似这样的按钮

请查阅 https://nodeget.com/dev/theme/ 文档

NodeGet Status Show 搭建

Thu, 30 Apr 2026 00:00:00 +0000

NodeGet Status Show 搭建

Hi，这里是 GenshinMinecraft，NodeGet 后端已经没啥大改动了，所以临危受命来写写前端展示面板的搭建指南

官方文档：https://nodeget.com
设计 Intro：https://www.nodeseek.com/post-704497-1
Telegram 频道：@NodeGetProject
Telegram 讨论组：@NodegetGroup
前端 Dashboard 仓库：NodeSeekDev/NodeGet-board
前端 Status Board 仓库：NodeSeekDev/NodeGet-StatusShow
Nodeseek 社区：https://nodeseek.com

现在是 26.4.30 22:37，明天就要发版，我已疲弊，此诚危急存亡之秋也

问题不大，这就来了

简介

NodeGet 的不仅是前后端分离，其前端也在正常情况下 (官方想让你这么用的情况下) 分为两个部分:

Dashboard: 用于持有 SuperToken，以最高权限管理所有设置
StatusShow: 持有一个极度受限的 Token，对公众展示。也就是日差意义上的探针展示界面，所有人只要可以访问都可以查看到该界面，但无法修改任何东西

在一些其他项目 (如 Komari) 中，其实具有这两个概念，但是已经被弱化了。我记得 Komari 中 Web /admin 就是其管理面板，而根目录则为展示界面

但是在本项目，最正常最被推荐的方式是:

用 Server 连接到官方提供的 Dashboard 中进行日常的管理和配置 (纯静态纯本地，我们无法也不可能收集到任何信息)
然后使用你自己的域名提供 StatusShow 服务，可以自定义为各种主题

本文介绍的是 StatusShow 的搭建，假设你已经搭建好了自己的 NodeGet 服务，并且在 Cloudflare 有自己的域名，拥有 Github 账户

请注意：本文使用 Cloudflare Pages，部署的是官方前端展示界面，如有第三方展示界面请查看对应 Readme

创建 Token

首先来到你的 Dashboard，来到左侧 Token -> 创建 Token

对于一般的情况 (使用官方 StatusShow)，使用预设的 Visitor 权限模版即可

这个预设的 Token 提供了以下权限:

对于所有 Agents

可以读取所有 Dynamic / Static / Dynamic Summary 数据
可以读取所有 Kv 中所有 Namespaces 下以 metadata_ 开头的 Key (这不会造成什么安全性问题，并未给出列出所有 Namespaces 的权限，只能依据 Agent UUID 来读取，并且一般只有 Agent Namespace 才有该字段)
读取所有 Agent UUID

预设的模版权限给的非常之小，如果第三方前端提供者提供了额外的展示项，请根据其指示配置

随后创建 Token

你应该会看到一个这样的界面，复制其以备用

一键部署

点击此处以一键部署:

以 Cloudflare 为例，点击按钮后，选择你的帐号

修改一下名称，点开高级设置，按照下面的规则添加环境变量

SITE_NAME = 狼牙的探针
SITE_LOGO = https://example.com/logo.png
SITE_FOOTER = Powered by NodeGet
SITE_1=name = "master-1",backend_url="wss://m1.example.com",token="abc123"
SITE_2=name = "master-2",backend_url="wss://m2.example.com",token="xyz789"

SITE_n 是主控，值用 key=“value” 拿逗号串起来，值里要塞引号或反斜杠的话用 \" 和 \\ 转义

从 SITE_1 开始连续往上数，中间断了就停，所以加新主控接着 SITE_3 SITE_4 就行

一个 SITE_n 都没设的话脚本啥也不干，直接用仓库里那份 config.json 运行

可以只有一个 SITE 不强制 SITE_2 SITE_3 之类的

随后即可正常部署，部署成功右上角访问

手动上传

修改 Config

前往 https://github.com/NodeSeekDev/NodeGet-StatusShow/releases 下载最新构建

打开这个压缩包，解压并修改 config.json 文件

{
  "site_name": "GM LOVE NodeGet",
  "site_logo": "",
  "theme_name": "default",
  "theme_repo": "",
  "theme_config": {
    "footer": "Powered by NodeGet"
  },
  "site_tokens": [
    {
      "name": "master server node 1",
      "backend_url": "wss://we-love-open-source.trycloudflare.com",
      "token": "P6R8Fkxxxxx:Ntt0NcLTkZVMtbb1bxxxxxxxxx"
    }
  ]
}

重点修改 site_name / backend_url / token 字段

需要注意的是，backend_url 在一般情况下应该为 wss 协议头，即为 TLS 加密的 WebSocket，并且强力建议部署于 CDN 后侧，这不仅是为了安全，也是浏览器的硬性要求

修改完后打包回该压缩文件

创建 Cloudflare Pages

转到 Cloudflare Dashboard，计算 -> Workers 和 Pages -> 创建应用程序

Upload Your Static Files

直接将刚才修改后的压缩文件拖入框中

然后修改为自己喜欢的 Pages 域名前缀，部署即可

部署成功后，在主面板直接跳转到部署的网站即可

绑定域名

老生常谈，来到刚才的面板 设置 -> 域和路由 -> 添加 -> 自定义域

输入域名后，添加即可

最终成果

PS: 这只是对外展示的面板，真正管理面板功能更多，我自己是挺喜欢的。

NodeGet NS 探针 Intro

Tue, 28 Apr 2026 00:00:00 +0000

NodeGet NS 探针 Intro

Hi，这里是 GenshinMinecraft，有幸参与这次的 NodeGet 探针项目的后端开发

官网 & 文档: https://nodeget.com/
Github Repo: https://github.com/NodeSeekDev/NodeGet
其他前端、频道、群组等暂未公开

老实说，我也不知道五月一日是否可以发第一个 Release

开始写这篇文章是 2026.4.27 22:49 分，刚刚我还问酒神：

一些琐事

关于我

我在论坛看到了有很多人期待 NodeGet 的正式出场，我也看到了有人对我的质疑：https://www.nodeseek.com/post-704190-1

这不重要，我自认为有条件，有这个技术能力去写好这个探针项目：

写过 komari-agent-rs
有些许 Rust 经验
有充足的时间

这就够了

关于项目组

我还是感觉这个项目组成员非常奇特

酒神在整个团队中成员分配类似于测试 + 项目经理的组合，感谢他测试后提出的 Bugs

后端有，且仅有我一个人主力开发，说实话很累，正式发布后，请积极贡献 / Review 代码，提交 Bugs

前端由多位开发者共同并行，效率很高，值得称赞

请不要忽视前端的开发工作，在我看来前端在这个项目中占的份额可不小。特别是新功能适配，各种高端图表渲染等，特别好看！

前端还有各种可拓展功能，可能第三方前端（真的有人会写一个如此复杂的第三方前端吗）适配有点困难，也欢迎和我们开发成员讨论

关于 AI

都 2026 年了，大家也都不是什么不开明的人，项目用 AI 已经不足为怪了

大胆承认，本项目的 API（也就是和用户交互的主要地方）有 75% 左右都是 AI 代工的；API 部分主要占整个项目的 40% 左右，掐指一算就是 30% 的地方用到了 AI Agent

每一行我都 Review 了，这请放心。核心内部逻辑，特别是有关 Token 鉴权部分，全都是手写的👋（有的时候还不如 AI 写的呢）

哦对了，这篇 Intro 百分百纯人工，不会稳稳地将你接住的！

正文

说了这么多，开始吧

本文的主要目的不是教你安装 NodeGet 探针项目，而是介绍 NodeGet 探针项目的主要设计理念、与其他同类项目的区别等

相反的，本文的一些东西可能是你不喜欢 NodeGet 探针的原因，所以这也算一个避坑指南

写 NodeGet 从来不是为了取代 Komari/Nezha 等项目，相比之下，探针只是其中一个非常小的功能罢了…

技术栈

后端开发语言是 Rust，不是为了什么 RIIR 或者炫技，只是为了跨平台与高性能，除了 rquickjs 外无其他语言依赖

通信协议选择了 WebSocket + JSON-RPC 2.0，这是一套比较常见的微服务技术栈，同时也兼容了 HTTP POST，都可以调用，基本无区别

数据库选择了我最熟悉的 PostgreSql 和最广泛的 SqLite，前者对应大量 Agent 的服务，后者适合小型部署

需要说明的是，其实整个 Server 整体占用并不会很低（特别是数据库储存），由于需要大量数据库操作，个人推荐 2C2G 20GB 可用空间以上的机器部署

不是说什么 0.1C32M 机器无法部署 Server（当然 Agent 可行），只不过你部署下来真不一定能用…

Token 系统

NodeGet 的亮点之一，所有的 CRUD 操作都应该提供一个有效的 Token，也就是常说的 Api Key / 校验令牌 等，但是为了方便，本项目统称 Token

本项目有且仅有一个超级用户 Token，即 SuperToken，在初始化数据库时会生成，它可以跳过所有的权限限制，请不要外泄

表达方式

一个 Token 可以有两种表达方式:

TOKEN_KEY:TOKEN_SECRET: 用 : 分割，Token Key 明文储存，Token Secret 加密，不可指定，自动生成随机字符串
Username|Password: 用 | 分割，Username 明文储存，Password 加密，可以指定，也可以为空

这两种在语义上完全相同，需要提供 Token 的地方，这两种格式都可以被接受，指代同一个 Token 时，具有相同的效力

今后，你会持续遇到这样的 Token

设计方案

一个 Token 最重要的就是其中规定的 TokenLimit，该结构体下面是 Vec 与 Vec，具体解释如下：

Scope 的意义是作用域，它代表了这个 Token 可以生效的范围

Permission 的意义是具有的权限，在指定的 Scope 下，具有的权力

比如一个类似下面的结构体：

{
  "scopes": [
    {
      "agent_uuid": "53f125b6-e7aa-447f-a27c-085a53a36462"
    },
    {
      "agent_uuid": "3e6f227f-56e3-4ca0-a12f-04014ebeebe7"
    }
  ],
  "permissions": [
    {
      "dynamic_monitoring": {
        "read": "cpu"
      }
    }
  ]
}

这代表的意义是：

这个 Token 可以读取 UUID 为 53..62 与 3e..e7 的 Agent 的 DynamicMonitoring Data 中 cpu 字段

在鉴权时，使用的是覆盖的思想，不论结构体怎么写，在实际鉴权都是可以正确匹配的，比如下面的结构体和上面的虽然看起来不同，但是鉴权时完全一致：

[
  {
    "scopes": [
      {
        "agent_uuid": "53f125b6-e7aa-447f-a27c-085a53a36462"
      }
    ],
    "permissions": [
      {
        "dynamic_monitoring": {
          "read": "cpu"
        }
      }
    ]
  },
  {
    "scopes": [
      {
        "agent_uuid": "3e6f227f-56e3-4ca0-a12f-04014ebeebe7"
      }
    ],
    "permissions": [
      {
        "dynamic_monitoring": {
          "read": "cpu"
        }
      }
    ]
  }
]

由于这里不是开发者文档，只是给普通用户做一个简介，所以细节请移步文档

监控系统

本项目的主要功能之一，属于大众理解的探针部分

本项目有三个表，或者说记录项：

StaticMonitoringData: 静态信息，采集后一般不会变化（CPU 型号、系统版本、GPU 型号等），每个 Agent 只储存一条，不会储存历史记录
DynamicMonitoringData: 动态信息，随系统实时变化（CPU 使用率、内存、磁盘、网络等），储存历史记录，并且数据量较大，储存周期不建议超过 1Day，记录非常详尽，比如各核心、各网卡、各硬盘记录
DynamicMonitoringSummaryData: 动态摘要信息，储存历史记录，数据量较小，用于长期储存，可以 90Days+ 而不占用过多空间，足够日常展示折线图，

第一个用于基本系统信息获取，第二个用于需要精细统计的附属功能 / 需要查看精确负载的用户，第三个用于长期储存。三个记录项目相对是独立的，但也有互通的部分

查询

这部分很有意思，我觉得这个设计很像 SQL 语法的 WHERE

你可以构建一个 DataQueryField，提供类似于 cpu / ram / load 这样的字段，来定向获取你需要的信息，而不是一股脑地全返回给你。这样不仅对数据库是压力，解析序列化也是压力

你还可以搭配 QueryCondition 使用，它可以筛选你需要查询的时间范围 / 指定 Agent / 查询数量等，如果你有一点点的 SQL 基础，那这就是 WHERE 语句

我们将其与 Token 系统紧密结合起来，特定的 Token 可以被指定只能查询特定 Agent 的特定字段，这都随你而定

Task 系统

Task 系统设计为用户提交给 Server，由 Server 下发给 Agent 去执行的逻辑

你可以理解为：用户想让 Agent 干啥就干啥的系统

大部分小功能（针对于 Agent 的）都集成在了这里，比如 ping / tcp_ping / http_ping 和在线终端等功能

Ping 实现

Ping 实现可以用户定时 Ping 等，目前已经实现了 ICMP Ping（需要特权）/ Tcp Ping / Http Ping（GET 请求）

主要目的是用于在前端展示网络情况等，算是比较常规的功能

Terminal & Execite 实现

Terminal 也就是常说的 WebShell / WebSSH / 在线终端，他可以获得一个等同于运行 Agent 的用户（一般是 Root）的 Shell

所以，这很危险，请你慎重选择是否开启该功能

该功能实现很有意思，Server 提供了一个双向的 WebSocket 转发通道，用于给用户和 Agent 实现全双工的数据转发，不仅仅是 Terminal，其他的实现也可以依赖这个通道（预计在后续的版本中添加支持）

请注意，Agent 所连接到的 Terminal Server 不一定是来自 NodeGet 的 Server，他可以是任意一个可以转发流量的 WebSocket 隧道，所以可以接到外部项目，同时也带来了一定的安全问题

类似的，还有 execute，可以直接执行命令，而不是终端实现

Agent 配置文件读取与修改

如果开启 read_config / edit_config，则 Server 可以读取/修改 Agent 的配置文件，危险度非常高，有需要才建议开启

安全性与查询

其实，理论上如果拥有了 edit_config / execute / terminal 三者之一，都可以做到完全控制 Agent

每一个 Task 都可以自由地控制开/关，对于不同的 Server（Agent 连接到多 Server 情况下）可以设置不同的权限

同样的，每个 Token 都可以指定对特定 Agent 特定 Task 的控制权限

查询和监控系统类似，都是提供类似 WHERE 的 QueryCondition

Cron 系统

定时任务，探针必备

有两种 Cron 任务：对于 Agent，你可以定时下发 Task；对于 Server，你可以定时执行 JS Worker / 清理数据库等等操作

表达式采用秒级的 Cron 表达式，比如 0 0 * * * *，具有六个有效字段

每秒读取一次 Cron，然后按照表达式执行，不再赘述

KV 系统

这，才是自由度高的开始

我们结合数据库实现了一个 Key-Value 数据库系统，你可以存储/读取任意类型的 Json 数据

后续介绍的所有系统，都会强依赖 KV 系统

如果你曾使用过 Cloudflare 的 Workers KV，那你应该很容易理解

该系统分为一个个 Namespaces，每个 Namespace 中 Key 唯一，调用者可以通过 Namespace + Key 查询到 Key 所对应的 Value，这个 Value 可以是任何 Json 数据

我们定义了一些特殊的 Namespaces 与其中的 Keys，用于前端展示需求，以及一些 Agent 详情等，移步文档

很简单很普通，但是他就是后续系统的基石

安全性与 CRUD

安全性上，Token 系统同样也和 KV 系统有机结合了起来

你可以为 Token 配置他在某个 Namespace 下对于某个 Key 的 CRUD 权限，并且支持通配符。比如以 abc* 为 Key 权限的 Token 可以读取以 abc 开头的所有 Key

我们为 KV 提供了非常多的方法用于 CRUD，就是设计成一个简易的数据库，用于方便地存储其他功能需要的数据

JS Worker

呼呼，终于到了自由度系统的重头戏

你可以把它理解成 Cloudflare Workers 的本地实现版，可以在其中运行任意自定义 JS 脚本

我们以 quickjs 为地基，向上拓展了一大堆功能：

onCall: 正常调用时执行的函数
onRoute：可以注册一个 HTTP URL，然后用第三方程序（甚至浏览器）去调用，就是 Cloudflare Workers 的功能
onCron：Cron 调用时执行的函数
onInlineCall：Js Workers 之间可以互相调度，获取对方的返回值，约等于将其他 Worker 当作函数来调用
具有完整的 fetch() 函数支持，由 aws llrt 提供，内部调用第三方 API / WebHook 完全可行
内置 nodeget() 函数用于调用本地 RPC，可以用该函数方便地调用（对于一个天天写 Fake Agent 的我来说，这玩意直接就能模拟成为一个 Agent 上报虚假数据）
… 太多了看文档吧

一些我个人遇见可以设想到的功能：

TG Bot 可以完全运行于 JS Worker
可以将 NodeGet 的 Agent 的信息上报到其他的探针系统，模拟成为他们的真实 Agent
可以将其他探针系统的 Agent 上报信息翻译到 NodeGet，作为 NodeGet 的模拟探针（使用 onRoute 注册路由实现）
实现一个基于 KV 的图床（已经完全实现，https://www.nodeseek.com/post-677408-1）

我们鼓励个人用户使用 AI 编写 JS Worker 来丰富他们自己的探针系统，但请注意安全性问题

官方也会维护一个仓库用于存放由官方认证的 JS Worker 脚本，类似于插件商店，预计是会有一个 Deploy On NodeGet 这样的按钮，可以一键安装

安全性与 CRUD

JS Worker 有一个表用于储存 Worker 的运行结果，每一个 Worker（除 onRoute 返回 Response 结构体外）都应返回一个可以被序列化为 Json 的 String，可以是运行状态，运行结果，当然也可以为空。

查询条件和前文所述差不多，详情请看文档

安全方面，inlineCall 时，被 Call 的 Worker 可以知道 Caller 的 Name，用于做一个小鉴权

Token 也与其该系统紧密结合起来，完全可控

小结

NodeGet 的各大系统基本如下：

Token：权限控制，安全性基石，所有系统都与其深度绑定
监控：探针主要部分
Task：Server 给 Agent 的任务
Cron：定时任务
KV：数据库，拓展性的基础
JS Worker：拓展性的实现，运行任意脚本

前面也提到过了，我之前参与过 Komari Agent 的第三方开发，所以这一次 NodeGet，有大量功能借鉴了 Komari 的设计理念，实现逻辑，谢谢他们

很多东西不可能在这里说完，这只是对普通用户的一个小简介，同时也为不知道什么时候才能发布的 NodeGet 预热下

26.4.28 0:36

Komari 从入门到入土

Sat, 13 Sep 2025 00:00:00 +0000

Komari 从入门到入土

<-前往本博客获取更好阅读体验->

请务必务必前往博客，并在电脑端查看文章以获得最好体验，论坛平台对 Markdown 支持有限: https://genmin.icu/p/komari-intro

前言

Komari 是一款轻量级的自托管服务器监控工具，旨在提供简单、高效的服务器性能监控解决方案。它支持通过 Web 界面查看服务器状态，并通过轻量级 Agent 收集数据。

简单来说就是探针监控，算是最近比较热门的探针服务了

由于一些问题太过小白，遂有本文

请注意，以下是你寻找帮助的渠道，从前往后尝试: (详情请看本博客古老文章)

Why Komari

所以，为什么选择 Komari 而不是 Nezha、Beszel、Akile Monitor 呢？

老实说我完全没有需要监控服务的需求，为 Komari 开发各种奇奇怪怪的东西以及为 Komari 写这篇文章也是完全出于兴趣

作为一个监控服务，其实还是有很多优点的:

开发者活跃: 包括在 Maintainers、主题开发者、Agent 开发者以及 7788 的社区开发者，在目前都还在积极活跃。所以比一些比较烂尾的项目好多了 (对比的是 Akile Monitor，主仓库已 9 月没更新)
轻量化: 当然吹的是本人开发的 komari-monitor-rs，作为一个 Agent 可以保证是同类中最低占用的
… 挺多的

现在的功能是越来越多了，流量统计、到期日设置等均已实现

安装主控

首先，你需要一台机器来安装主控，不论是 ClawRun 这类容器云服务、还是 VPS、抑或是实体机都好…

并且该节均使用 Linux 安装主控，其他系统自行研究

对于安装方式的选择，我不建议所有人都使用 一键脚本 来安装环境，不论是小白还是希望规范化自己机器的环境的大佬，但我仍会介绍该种方式

一键脚本安装

一键脚本适用于 systemd 发行版，且架构需要为 amd64 / x86 / arm64 / riscv64 其一

若你的 Linux 为现代且主流的版本即可直接使用 (Ubuntu / Debian 等)

1
2
3

curl -fsSL https://raw.githubusercontent.com/komari-monitor/komari/main/install-komari.sh -o install-komari.sh
chmod +x install-komari.sh
sudo ./install-komari.sh

若机器环境无法访问到 Github，可以尝试下面的命令:

curl -fsSL https://ghfast.top/https://raw.githubusercontent.com/komari-monitor/komari/main/install-komari.sh -o install-komari.sh
sed -i 's|https://github.com|https://ghfast.top/https://github.com|g' install-komari.sh
chmod +x install-komari.sh
sudo ./install-komari.sh

全新安装，在此处选择 1 并回车即可:

到了这一步，即可进行下一步

Docker 安装

Docker 环境

这需要你安装 Docker 环境，这里不再赘述，只给出相关一键脚本:

# 下载并执行Docker官方安装脚本
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh

# 启动Docker服务
sudo systemctl start docker
sudo systemctl enable docker

Docker 创建容器

创造新的文件夹以存放数据:

`1`	`mkdir -p /opt/komari/data`

创建新的容器:

docker run -d \
  -p 25774:25774 \
  --restart=always \
  -v /opt/komari/data:/app/data \
  --name komari \
  ghcr.io/komari-monitor/komari:latest

若机器环境无法访问到 Github，可以尝试下面的命令:

docker run -d \
  -p 25774:25774 \
  --restart=always \
  -v /opt/komari/data:/app/data \
  --name komari \
  ghcr.linkos.org/komari-monitor/komari:latest

你可以使用自己的数据目录，建议存放到 /opt/komari，这同样也是官方一键脚本使用的，可以将上面命令的 /opt/komari 改为其他路径

如果你需要监听其他端口，可以将第一个 25774 改为你需要的端口

获取账号密码

若成功创建 Docker 容器，即可通过以下命令输出的日志来获取随机生成的账号密码:

`1`	`docker logs komari`

总流程图

二进制 Binary 安装

一些极度的小白就不要尝试了

初始化环境

找个文件夹放 Binary 与数据，这里还是以 /opt/komari 举例:

1
2

mkdir -p /opt/komari
cd /opt/komari

下载 Binary

从 Release 获取对应系统、架构的 Binary 下载链接:

比如我是 Linux Arm64，复制出来下载链接长这样:

`1`	`https://github.com/komari-monitor/komari/releases/download/1.0.7/komari-linux-arm64`

若机器环境无法访问到 Github，可以尝试在链接前加 https://ghfast.top/

随后使用 wget / cUrl 下载即可:

1
2
3

# 任选一个即可
wget -O ./komari [PASTE UR LINK HERE]
curl -o ./komari [PASTE UR LINK HERE]

给 Binary 添加可执行权限:

`1`	`chmod +x ./komari`

初次执行

在 Binary 所在目录执行:

`1`	`./komari server -l 0.0.0.0:25774`

待到输出如图即可 Ctrl-C 直接停止:

保存好展示的随机生成的账号密码

保活服务

这同样需要系统使用 SystemD，若不是，请自行寻找方法

cat <<EOF > /etc/systemd/system/komari.service
[Unit]
Description=Komari Monitoring Service
After=network.target

[Service]
ExecStart=/opt/komari/komari server -l 0.0.0.0:25774
WorkingDirectory=/opt/komari
Restart=always
User=root

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable komari --now

这是三条命令，直接执行即可，默认直接启动并打开开机自启 (记得替换必要的路径、端口等参数)

随后即可用 systemctl 管理该服务:

开机自启：systemctl enable komari
启动服务：systemctl start komari
服务状态：systemctl status komari

初次登录到 Komari

更改用户名和密码

在左侧栏中找到 账户，先修改用户名，后修改密码

请注意，修改用户名并不需要重新登陆，而修改密码需要以新密码登录 (刷新后)

更改基础信息

在左侧栏中找到 设置-站点，修改站点名称以及描述

最好打开跨域请求开关，并关闭私有模式，这对以后的基于 Komari 的 API 服务非常有帮助 (当然并不强制)

设置反向代理与 CDN

初次登录 Komari 主要是为了验证服务以及建立，接下来我们需要根据自己需求来配置，这非常个性化，不要尝试直接套用本文参数

请应用在生产环境用户仔细阅读该篇，目前大部分的配置问题都来源于反代或 CDN 配置错误

下面的步骤是可选的，但建议做

在可选择的情况下，我的推荐度 (上者推荐度高):

Komari 监听 80 端口 + CDN 80
非常规端口实现 CDN 代理
任意端口与 Cloudflare Tunnels 联动
在 80 端口反代 25774 的 Komari + CDN 80
其他方案

在 80 端口反代 25774 的 Komari

若你的 80 端口还需要运行其他的服务，则可以通过反向代理实现

由于 Komari 需要大文件上传以及 Websocket 支持，所以较难配置

如果你是直接运行 Nginx 等核心的用户，相信你不会需要该教程，直接移步 Komari Doc

如果你使用 1Panel / BTPanel 等服务，自行研究配置即可

Komari 直接监听 80 端口

若你的服务器 80 端口不被其他服务所占用，直接让 Komari 服务监听于 80 端口即可

通过更改部署命令，可以实现该效果，详情请见上文

CloudFlare CDN

Cloudflare CDN 是使用最广泛的 CDN，所以用来举例，其他 CDN 自行研究

为什么推荐使用 CDN？

因为探针服务特殊性，需要全世界各地的 Agent 连接并最好需要双栈服务，CDN 是最简单的方式

普通 80 端口直接 CDN 代理

在 DNS 处直接添加解析，并打开小黄云即可

默认情况下，Cloudflare 会打开 Websocket 开关，并配置好证书，所以不需要其他操作

最后访问域名查看效果

非常规端口实现 CDN 代理

Cloudflare 支持非常用端口的代理，配置还算简单

对于不想使用反向代理，或反向代理不会配置的用户来说是最好的选择

用常规方法解析到 IP 并打开小黄云后，来到 域名-规则-创建规则-源服务器规则:

名称随意填写，选择 自定义筛选表达式，规则写成 主机名-等于-[你的 Komari 使用的域名]:

最后的重定向端口写成 Komari 服务的端口即可 (默认为 25774):

默认情况下，Cloudflare 会打开 Websocket 开关，并配置好证书，所以不需要其他操作

最后保存，访问域名查看效果

任意端口与 Cloudflare Tunnels 联动

Cloudflare Tunnels 类似于内网穿透服务，若你的机器没有公网 IP 或者 CF 回源困难可尝试

在 Cloudflare 账户主页找到 Zero Trust:

左侧栏目 网络-Tunnels-新建隧道:

选择 Cloudflared:

名字随便起，根据自己系统和架构选择，然后执行 Cloudflare 所提供的命令即可:

按照如图配置你的域名、本地的 Komari 服务链接:

默认情况下，Cloudflare 会打开 Websocket 开关，并配置好证书，所以不需要其他操作

最后保存，访问域名查看效果

为被监控机安装 Agent

选择 Agent

Agent 有官方与第三方之分，目前较为主流的第三方 Agent 为本人编写的 komari-monitor-rs ~~(有点吹牛逼了哈)~~

本文的第三方 Agent 会以 komari-monitor-rs 为例

官方 Agent 优点:

都是官方的了，当然最适配 Komari
兼容性较好

komari-monitor-rs 优点:

占用小: 不论是可执行文件大小、还是运行时的 CPU / 内存占用，都是比官方的不止低了一点
支持虚假倍率: 简单来说就是把本机的信息都翻倍然后传输到主控，可以伪装高性能机器 ~~(拳打太湖之光)~~
Prebuilt 架构多: 由于 Rust 语言的特性，可以轻松地交叉编译，覆盖了可以编译通过的所有架构。官方仅仅提供了 Linux / Darwin / Windows / FreeBSD 的 amd64 / x86 / arm / arm64 的架构支持
获取机器信息方式优雅: 说实话这个有点牵强，但我举例下就知道了:
- 官方在 Agent 使用了大量平台特化与命令执行的方式来获取信息，并且依赖于第三方软件包
- 第三方 Agent 使用了健全第三方库，并保证了最小体积，不会擅自执行外部命令
- 比如有关网络信息获取，官方 Agent 直接执行了 vnstat 命令以获取，并解析其输出。我个人不认为这是一个正确的方式来获取系统信息。而第三方 Agent 则使用了系统级库，直接读取网卡信息

所以，你需要根据自己需要来选择 Agent:

若你是纯纯的小白，请使用官方 Agent
若你不希望依赖第三方软件，请尝试使用第三方 Agent
若你的机器环境较为恶劣，可用的资源较少，请尝试使用第三方 Agent
若你的机器架构较为少见，官方无 Prebuilt 的情况下，请使用第三方 Agent (不论是官方还是第三方，均不建议自行编译)
若你需要虚假倍率的功能，请务必使用第三方 Agent
若你是一个极客，并且知道自己在做什么，请务必使用第三方 Agent

在后台创建新的服务器

如图，在 后台-服务器-添加节点，输入自己想要的服务器名称，随后添加节点即可

成功后，会在后台展示一个带有联合国旗帜的图标。在没有任何数据传输到 Komari 之前，这是正常的

官方 Agent

一键脚本安装

官方 Agent 提供了方便的一键脚本，并与 Komari 主控绑定在一起

点击服务器右侧的类似下载一样的图标，即可获取自动安装的一键脚本:

首先选择你需要的系统，目前仅支持 Linux 和 Windows 主流架构一键脚本安装

这里有很多选项，我们来一一解释一下:

禁用远程控制: 如果你不需要使用到网页终端 (俗称 WebSSH) 功能，请禁用它以更安全
禁用自动更新: 在一些需要稳定的场景下，可以禁用自动更新，但长期不更新可能有安全隐患以及有可能无法连接至更高版本的主控
忽略不安全证书: 若服务端已配置 HTTPs，该选项才有效，否则无效。可以忽略与主控通信的证书，安全性自己保证
包含缓冲区内存: 这里需要一些计算机常识，内存一般分为三部分: 使用中-已缓存-可用
- 虽然但是拿的是 Win 任务管理器举例
- 使用中的部分，是应用程序真正在使用的部分，该部分无论如何都会被统计
- 已缓存部分，可以被随时清理出来用来供给应用程序使用，这个选项有关的就是这里
- 可用的部分，可以供给应用程序使用
- 若开启该选项，则会统计 使用中的部分+已缓存部分 的内存总量，反之为 使用中的部分
- 若你不知道或不想了解这是什么，请关闭该开关
Github 代理: 若你的网络环境无法直接访问 Github，请打开该选项，不建议更改 Github 代理·链接
安装目录 与 服务名称: 顾名思义，若需要自定义可使用
只监测特定网卡 或 排除特定网卡: 这两个选其一即可，可以根据网卡名来获取网络信息，以 , 分割。若你不知道这选项有何用，请保持关闭
只监测特定挂载点: 该选项关于磁盘获取，若仅需要监测特定挂载点，可使用，以 ; 分割。若你不知道这选项有何用，请保持关闭
网络统计月重置日: 若不需要使用流量监控服务，可关闭。每个月的第一天清零流量统计

配置完后，下方会生成一个可执行的一键命令，在被控机器上运行即可:

手动安装

获取 Token

在 Komari 中，一个服务器对应一个 Token，这是主控与被控端通信的重要令牌

可以在后台，点击服务器条目右侧第三个铅笔按钮 编辑信息 来查看:

每一个服务器的 Token 都是独一无二的，下文需要使用

下载 Binary

找个文件夹放 Binary 与数据，这里还是以 /opt/komari 举例:

1
2

mkdir -p /opt/komari
cd /opt/komari

从 Release 获取对应系统、架构的 Binary 下载链接:

比如我是 Linux Arm64，复制出来下载链接长这样:

`1`	`https://github.com/komari-monitor/komari-agent/releases/download/1.0.72/komari-agent-linux-arm64`

若机器环境无法访问到 Github，可以尝试在链接前加 https://ghfast.top/

随后使用 wget / cUrl 下载即可:

1
2
3

# 任选一个即可
wget -O ./komari-agent [PASTE UR LINK HERE]
curl -o ./komari-agent [PASTE UR LINK HERE]

给 Binary 添加可执行权限:

`1`	`chmod +x ./komari-agent`

在 Binary 所在目录执行可执行文件，获取帮助信息:

`1`	`./komari-agent --help`

成功输出即表示下载成功

构建执行命令

对于官方 Agent，至少需要提供 2 个参数以正常运行，即主控地址 和 Token

`1`	`./komari-agent -e http://192.168.31.2:25774 -t RSe6wsEcF7xTKblV`

请按照上面的格式，替换主端的 URL 以及上面获取的 Token

剩余的参数请通过 ./komari-agent --help 获取，与上文一键脚本安装时的参数解析相差不大，查看即可

随后先在本地测试执行命令，保证其可以连接到主控，若输出类似下方即算完成:

即可 Ctrl-C 直接停止

保活

这同样需要系统使用 SystemD，若不是，请自行寻找方法

cat <<EOF > /etc/systemd/system/komari-agent.service
[Unit]
Description=Komari Monitoring Agent Service
After=network.target

[Service]
ExecStart=/opt/komari/komari-agent -e http://192.168.31.2:25774 -t RSe6wsEcF7xTKblV
WorkingDirectory=/opt/komari
Restart=always
User=root

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable komari --now

请自行替换其中的执行命令、执行目录

这是三条命令，直接执行即可，默认直接启动并打开开机自启 (记得替换必要的路径、端口等参数)

随后即可用 systemctl 管理该服务:

开机自启：systemctl enable komari-agent
启动服务：systemctl start komari-agent
服务状态：systemctl status komari-agent

第三方 Agent

还是以 komari-monitor-rs 举例

获取 Token

在 Komari 中，一个服务器对应一个 Token，这是主控与被控端通信的重要令牌

可以在后台，点击服务器条目右侧第三个铅笔按钮 编辑信息 来查看:

一键脚本

当然，我们也有一键脚本:

交互式

该脚本会逐步询问你有关 Agent 连接的信息

wget -O setup-client-rs.sh "https://ghfast.top/https://raw.githubusercontent.com/GenshinMinecraft/komari-monitor-rs/refs/heads/main/install.sh" && chmod +x setup-client-rs.sh && sudo bash ./setup-client-rs.sh

传入参数式

该脚本也可以类似官方 Agent 的脚本一样传入参数

`1`	`bash install.sh --http-server "http://your.server:port" --ws-server "ws://your.server:port" --token "your_token" [--terminal]`

需要注意与官方 Agent 不同的一点是，官方的 Websocket URL 是从 HTTP URL 推导出来的，而第三方 Agent 可以自定义，所以你需要同时写

当然也支持 HTTPs 与 WSs，更改协议头即可

--terminal 为可选参数，若打开则启用 Terminal 功能 (WebSSH)

手动安装

下载 Binary

找个文件夹放 Binary 与数据，这里还是以 /opt/komari 举例:

1
2

mkdir -p /opt/komari
cd /opt/komari

从 Release 获取对应系统、架构的 Binary 下载链接

需要注意的是，如果你的系统使用的并非 GlibC 运行库，请下载带有 musl 后缀的文件

后缀有 musl 字样的可以在任何 Linux 系统下运行

后缀有 gnu 字样的仅可以在较新的，通用的，带有 Glibc 的 Linux 系统下运行，占用会小一些

比如我是 Linux Arm64，复制出来下载链接长这样:

`1`	`https://github.com/GenshinMinecraft/komari-monitor-rs/releases/download/latest/komari-monitor-rs-linux-aarch64-gnu`

若机器环境无法访问到 Github，可以尝试在链接前加 https://ghfast.top/

随后使用 wget / cUrl 下载即可:

1
2
3

# 任选一个即可
wget -O ./komari-agent-rs [PASTE UR LINK HERE]
curl -o ./komari-agent-rs [PASTE UR LINK HERE]

给 Binary 添加可执行权限:

`1`	`chmod +x ./komari-agent-rs`

在 Binary 所在目录执行可执行文件，获取帮助信息:

`1`	`./komari-agent-rs --help`

成功输出即表示下载成功:

构建执行命令

对于第三方 Agent，至少需要提供 3 个参数以正常运行，即主控 HTTP 地址、主控 WS 地址 和 Token

`1`	`./komari-agent-rs --http-server "http://192.168.31.2:25774" --ws-server "ws://192.168.31.2:25774" -t "RSe6wsEcF7xTKblV"`

请按照上面的格式，替换主端的 URL 以及上面获取的 Token

剩余的参数请通过 ./komari-agent-rs --help 获取:

--terminal: 开启 Terminal 功能 (WebSSH)，默认关闭以保证安全性
--terminal-entry <COMMAND>: Terminal 的可执行文件，默认在 Linux 下为 bash
--fake <F64>: 虚假倍率，主要功能之一，可接受小数点
--realtime-info-interval <MS>: 每隔多少 ms 上传一次信息，默认为 1000 ms
--ignore-unsafe-cert: 忽略通信证书验证

随后先在本地测试执行命令，保证其可以连接到主控，若输出类似下方即算完成:

即可 Ctrl-C 直接停止

保活

这同样需要系统使用 SystemD，若不是，请自行寻找方法

cat <<EOF > /etc/systemd/system/komari-agent-rs.service
[Unit]
Description=Komari Monitoring Agent Service
After=network.target

[Service]
ExecStart=/opt/komari/komari-agent-rs --http-server "http://192.168.31.2:25774" --ws-server "ws://192.168.31.2:25774" -t "RSe6wsEcF7xTKblV"
WorkingDirectory=/opt/komari
Restart=always
User=root

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable komari --now

请自行替换其中的执行命令、执行目录

这是三条命令，直接执行即可，默认直接启动并打开开机自启 (记得替换必要的路径、端口等参数)

随后即可用 systemctl 管理该服务:

开机自启：systemctl enable komari-agent-rs
启动服务：systemctl start komari-agent-rs
服务状态：systemctl status komari-agent-rs

安装之后

恭喜你，你已经完全设置了一个生产环境下的 Komari，接下来的操作是可选的，但能让你使用的体验大幅提高

安装主题

说到监控服务，界面美观是肯定需要的

若你以及看烦了官方的主题，开发者也提供了众多的主题给你使用:

https://komari-document.pages.dev/community/theme.html

展示的主题分别为 PurCarte 与 Mochi

我们以 Mochi 为例，展示如何安装主题:

来到主题的 Github Release，下载最新的主题包 (.zip 格式):

随后来到 Komari 后台 设置-主题管理-上传主题-上传 zip 文件，成功后即可在主题列表切换到新主题:

一些主题还有丰富的可配置项目:

效果如图:

更换壁纸

默认的背景太单调了，确实

与众多的监控服务类似，Komari 提供了前端嵌入代码的方式，所以我们可以轻易地改变壁纸:

在后台 设置-站点-自定义-自定义头部 下，填入如下代码并保存:

    <style>
      body {
        /* 背景图片地址,替换成你喜欢的 */
        background-image: url("https://img.genmin.icu/117610969_p0.jpg");
        background-size: cover;
        background-position: center center;
        background-repeat: no-repeat;
        background-attachment: fixed;
      }
      .layout {
        background-color: transparent;
      }
    </style>

效果如图:

配置延迟监测

Komari 一大亮点即为支持延迟监测

选择 Ping 方式

Komari 现在支持三种 Ping 方式:

ICMP Ping: 最普通的，使用 ICMP 的 Ping
TCPing: 发送包到握手成功建立连接的延迟，需要 TCP 端口
Http Ping: 发送请求到收到回复的延迟，简单的可以理解为网页首页加载时间，这需要被测服务器有 HTTP 服务

一般来说，对于同一个服务器，ICMP Ping < TCPing < Http Ping

若你不清楚这三个的区别，请选择 ICMP Ping

选择 Ping 服务器

Ping 的目标地址可以是任何地址，不论是内网还是外网

比较常用的检测方式为测试到国内各个省份三网的 ICMP Ping 延迟

对于该种方式，可以到 https://tcping.wuxie.de/ 去寻找需要的地区的服务器

我们以 河南移动 为例:

它提供了 IPv4 / IPv6 的检测地址，我们可以用 ICMP Ping / TCPing 来测试该网站提供的所有地址，但不可使用 Http Ping

对于河南移动，我们可以这样设置:

ICMP Ping v4: 111.7.88.239 / v4-ha-cm.oojj.de
ICMP Ping v6: 2409:8c44:b00:ff2f:3::7d0 / v6-ha-cm.oojj.de
TCPing v4: 111.7.88.239:80 / v4-ha-cm.oojj.de:80
TCPing v6: [2409:8c44:b00:ff2f:3::7d0]:80 / v6-ha-cm.oojj.de:80

当然，也不一定需要这里的地址，任何地址都是接受的

创建 Ping 任务

来到 Komari 后台 延迟监测-添加

名称可自定义，比如我想监测 河南移动 V4，即可将这个作为名字

类型即为你选择的 Ping 方式，目标即为上面确定的地址

请注意，这两个选项必须匹配，比如 ICMP Ping 必须为单独的一个域名或者地址，不能带端口和协议头

随后可以选择服务器，可以为多个服务器同时配置监测服务:

随后填写间隔时间，不建议小于 30 sec，有可能会导致数据库过大 (特别是多服务器、多监测点、保存时间长的环境)

最终设置结果如图:

保存即可

等待一定时间后，即可在主页的特定服务器下找到延迟监测结果:

关于结果保存

默认情况下，Komari 会保存 24 Hours 内的所有 Agent、所有监测点的上报数据

这会导致 Komari 数据库非常大

以 10 台被控机、每台机器三个地区的三网监测点 (共 9 个)、每 60 sec 测试一次、数据保存 7 天 这样的环境为例，需要使用约 181 MB 的硬盘空间

所以，你应该合理分配数据库保存时间、监测点数量、以及测试时间

关于数据库保存时间，可以在 Komari 后台 设置-通用-历史记录-Ping 数据保存时间 来设置:

如果你恰巧财力雄厚，服务器磁盘大且不担心性能下降问题，7 Days = 168 Hours 是一个不错的选择

当然我们贴心的 Komari 也给我们在 延迟监测 界面配上了预计的数据库使用量

请不要尝试设置类似于 每秒监测 的东西，不仅对自己磁盘有较大的读写负担，而且还有可能引起性能下降等问题

配置 OAuth 登录

OAuth 可使用第三方账号登录到 Komari，而不用输入 Komari 的账号密码

本文以 Github OAuth 为例，这需要你拥有一个 Github 账户

获取 Callback URL

来到 Komari 后台 设置-登录-单点登录，服务商选择 Github:

下方有生成的 Callback 回调 URL，请复制备用

Github 设置

来到 Github Developers Settings，登陆账号后点击 New OAuth APP:

名字、网址等自己填写，然后 Authorization callback URL 处填写上面复制的 Callback 回调 URL

如图所示，填写完成后，点击 Register application 即可

此处的 Client ID 复制保存:

然后点击 Generate a new client secret，此处可能被要求验证 totp 或密码

输出的 Client Secret 请妥善保存，复制备用

配置 Komari

回到 Komari，将上面获取到的信息填写回后台并保存:

记得打开 启用单点登录 的开关

不要着急退出，还需要绑定账号

来到 Komari 后台 账户-单点登录-绑定外部账户:

授权后，回到该界面，看到自己的账户被绑定成功即可:

测试登录

右上角登出 Komari 后，即可尝试使用 Github 登录到 Komari:

跳转授权:

即可成功登录

关于 Callback 长期转圈

在主控网络无法访问到 Github 的情况下，授权 Github 后可能出现长期等待并返回如下错误:

`1`	`{"error":"Invalid state","status":"error"}`

请尝试令主控可以访问 Github，或者更换其他 OAuth 服务商

连接到 Komari Telegram Bot

目前，应该也是唯一的 Komari Telegram Bot 应该是我的 komari-tg-bot

我创建了一个公共服务位于 @komaritgbot，当然你也可以自己部署，但我不建议 (因为我根本没写文档，自行研究去吧)

请注意，该 Bot 不需要任何鉴权，你的所有服务器数据都是安全的，仅读取公开信息 ~~(除非你甚至不希望你的 Komari 面板 URL 出现在任何人面前)~~

要求

你至少需要达成以下要求才可使用本 Bot:

服务器部署在公网，并拥有良好的可访问性 (说白了就是公网可以看到你的 Komari 面板)
未开启私有模式 (本文的 初次登陆到 Komari - 更改基础信息 有提到)
Komari 主控版本高于 1.0.7 (若你是根据本文来安装的，大概率是的)

还有，服务器位于中国境内，通过香港代理访问各位的 Komari

连接

很简单，对 @komaritgbot 发送 /connect <你的服务器 URL> 即可:

URL 必须以 http(s) 开头，可以带端口，仅读取协议头、Host、端口部分，其他部分会忽略

当输出 成功读取 Komari 服务信息！ 与 Komari 信息后即为完成绑定

使用

可以通过 /help 指令获取所有帮助信息

获取总览信息

/total_status:

获取单台服务器信息

/status [服务器名称]:

PS: 服务器名称可以不写全，为第一个包含了传入字符串的服务器

若不提供 [服务器名称]，则为列表内第一个服务器

根据 ID 获取单台服务器信息

可以通过 /get_node_id 获取每个服务器对应的 ID，再通过 /status_id [id] 来获取信息:

同样地，若不提供 [id]，则为列表内第一个服务器

你还可以通过 Bot 消息下方的按钮来切换服务器或刷新

就这样

关于数据准确性

本人保证 @komaritgbot 获取的信息均从用户提供的 URL 中获取，不存在修改行为。

所有来自 @komaritgbot 的消息准确性请用户自行判断

配置通知

Komari 可以为服务器配置告警通知、临期通知、上下线通知等

配置通知渠道

Komari 提供了非常多的同时发送渠道，我建议使用 Telegram Bot 或者 @komaritgbot 提供的通知服务，这样查询与通知可以绑定在一个 Bot 内

Telergam Bot

这需要你的主控访问得了 Telegram 或者自建 Telegram API 代理 (这与本文无关)

来到 Komari 后台 设置-通知，打开通知总开关，通知渠道选择 telegram，并在下方填入你的 Bot 信息:

Telegram Bot Token: 创建 Bot 的方式本文不提，谷歌搜索 Telegram Bot 创建 即可获取该 Token
Chat ID: 对话 ID
- 若需要发送给 Telegram 用户，则为 用户 ID (可私聊 @nmnmfunbot 发送 /id 获取)
- 若发送到群组，则为群组 ID (需要 Bot 在群组内，群组 ID 可拉入 @nmnmfunbot 并在群组内发送 /id 获取)
请求端点: 若你的机器可以访问到 Telegram API，则无需理会；若无法访问，可谷歌搜索 反代 Telegram API

保存后，点击下方的 GO 测试发送，并检查是否收到信息即可 ~~(为什么不是点击 Rust)~~

@komaritgbot 提供的通知服务

我推荐使用该种方式，可以将服务器状态查询与消息通知结合在一起，还不需要创建新的 Bot

在通过本文教程 安装之后-连接到 Komari Telegram Bot 绑定服务器后，发送 /generate_notification_token:

这可以获取到 Webhook 回调 URL，例如:

`1`	`https://komari-bot.c1oudf1are.eu.org/telegrambot/5965795367/f0f9344d-05ab-4d2a-99fb-d9162fdd0929/CHAT_ID`

来到 Komari 后台 设置-通知，打开通知总开关，通知渠道选择 webhook，并在下方填入你的信息，请记得将 method 改为 POST:

仅有 url 字段与 method 字段需要更改，其他保持不变

请替换从 Telegram Bot 中获取的 WebHook URL 中的 CHAT_ID:

若需要发送给 Telegram 用户，则为 用户 ID (可私聊 @nmnmfunbot 发送 /id 获取)
若发送到群组，则为群组的用户名 (类似 @komari_monitor) 或群组 ID (需要 Bot 在群组内，群组 ID 可拉入 @nmnmfunbot 并在群组内发送 /id 获取)

比如我要发给自己即为:

`1`	`https://komari-bot.c1oudf1are.eu.org/telegrambot/5965795367/f0f9344d-05ab-4d2a-99fb-d9162fdd0929/5965795367`

我要发送到 @komari_monitor 即为:

`1`	`https://komari-bot.c1oudf1are.eu.org/telegrambot/5965795367/f0f9344d-05ab-4d2a-99fb-d9162fdd0929/@komari_monitor`

保存后，点击下方的 GO 测试发送，并检查是否收到信息即可

配置通知项

离线通知

来到 Komari 后台 通知-离线通知，可以选择服务器批量进行修改:

需要启用掉线通知开关，宽限期 指的是当被控掉线后在该期限内重连的话不会发送掉线信息，默认 5min，可按照自己的需要调整

负载通知

来到 Komari 后台 通知-负载通知，可以选择服务器进行修改:

名称随意填写即可

监控项目可为 CPU / MEM / DISK / NET 等各项目，下面这么多空其实意思是:

在 间隔 (分钟) 内，若 监控项 的占用率超过 阈值 (%)，且持续时间高于 时间占比 * 间隔 (分钟)，则发送告警

请记得还要选择服务器，支持批量选择

如果不理解，保持默认不动即可

通用通知

来到 Komari 后台 通知-通用:

这里的解释都很清楚了，按需开启即可

计费

在 Komari 后台 服务器 中可以为每一台服务器设置费用、账单、到期日等，点击右侧第四个钱钱图标即可:

前三个项目为费用计算相关，按需填写和付费周期即可

到期时间与告警有关，若为长期可点击右侧按钮

自动续费建议开启，若过了到期时间，Agent仍然在线，可以直接在 原先的到期日期上 加上 付费周期 的时间

流量统计

在 Komari 后台 服务器 中可以为每一台服务器设置流量限制，点击右侧第三个铅笔图标，找到 流量阈值 即可:

此处有很多统计方式:

这取决于服务商的流量统计，有的服务商仅 单向计费，也有的以 双向计费，请自行了解是哪一种

若在不了解的情况下，建议选择 总和

比如我设置了 1000 GB 总和，就会在首页显示:

远程控制

现有两种远程控制方式:

网页终端: 也就是 WebShell，与 SSH 基本无异
远程执行: 可批量执行，但无法交互

网页终端

在 Komari 后台 服务器 中可以连接到每一台服务器的终端 (除非其关闭了远程终端功能):

右侧第二个终端按钮:

请注意，这里等同于拥有了与运行 agent 用户同等的权力 (一般为 Root)，所以请自行保证安全性

远程执行

远程执行适用于多服务器执行同一个命令

在 Komari 后台 远程执行 中可以批量让服务器运行命令

请注意，这里等同于拥有了与运行 agent 用户同等的权力 (一般为 Root)，所以请自行保证安全性

卸载 Komari

卸载主控

一键脚本

若你是使用的一键脚本安装 Komari，直接使用一键脚本卸载即可:

1
2
3

curl -fsSL https://raw.githubusercontent.com/komari-monitor/komari/main/install-komari.sh -o install-komari.sh
chmod +x install-komari.sh
sudo ./install-komari.sh

若机器环境无法访问到 Github，可以尝试下面的命令:

curl -fsSL https://ghfast.top/https://raw.githubusercontent.com/komari-monitor/komari/main/install-komari.sh -o install-komari.sh
sed -i 's|https://github.com|https://ghfast.top/https://github.com|g' install-komari.sh
chmod +x install-komari.sh
sudo ./install-komari.sh

在选择界面选择 3 即可:

如果你已经确认你的数据不再被需要，可强制删除 /opt/komari 文件夹:

`1`	`rm -rf /opt/komari`

Docker

若你是使用的是 Docker 安装 Komari，可以按照如下方法卸载:

1
2

docker rm -f komari
docker image prune -a # 删除不被需要的镜像

如果你已经确认你的数据不再被需要，可强制删除 /opt/komari 文件夹 (如果根据本文安装，默认路径位于此):

`1`	`rm -rf /opt/komari`

二进制 Binary 安装

若你是使用的是 Binary 安装 Komari，可以按照如下方法卸载:

首先停止并删除 Komari 服务:

systemctl stop komari.service
systemctl disable komari.service
rm /etc/systemd/system/komari.service
systemctl daemon-reload

如果按照本文教程安装，则数据与 Binary 存放于 /opt/komari

如果你已经确认你的数据不再被需要，可强制删除 /opt/komari 文件夹:

`1`	`rm -rf /opt/komari`

卸载 Agent

官方 Agent

若使用本文的一键脚本 / Binary 安装方法，可以通过下面的方式卸载

执行 Bash 命令:

systemctl stop komari-agent.service
systemctl disable komari-agent.service
rm /etc/systemd/system/komari-agent.service
systemctl daemon-reload

若未更改，一键脚本安装目录位于 /opt/komari

如果你已经确认你的数据不再被需要，可强制删除 /opt/komari 文件夹:

`1`	`rm -rf /opt/komari`

第三方 Agent

一键脚本

若使用本文的一键脚本安装方法，可以通过下面的方式卸载

执行 Bash 命令:

systemctl stop komari-agent-rs.service
systemctl disable komari-agent-rs.service
rm /etc/systemd/system/komari-agent-rs.service
systemctl daemon-reload

若未更改，一键脚本安装目录位于 /usr/local/bin/komari-monitor-rs

如果你已经确认你的数据不再被需要，可强制删除 /usr/local/bin/komari-monitor-rs 文件:

`1`	`rm -rf /usr/local/bin/komari-monitor-rs`

Binary 安装

Binary 安装与一键脚本安装区别仅为安装路径的改变

执行 Bash 命令:

systemctl stop komari-agent-rs.service
systemctl disable komari-agent-rs.service
rm /etc/systemd/system/komari-agent-rs.service
systemctl daemon-reload

若未更改，一键脚本安装目录位于 /opt/komari

如果你已经确认你的数据不再被需要，可强制删除 /opt/komari 文件夹:

`1`	`rm -rf /opt/komari`

常见问题

我能否在 XX 设备 XX 系统上安装 Agent?

如果你在阅读完本文与文档之后提出该问题，则该设备 / 系统大概率不能以一键脚本或普通方式运行，请带着环境上网搜索或者来 Komari 群组提问

贡献到 Komari

Komari 需要新鲜血液，下面是你可以参与贡献的方式:

小结

我不需要一个监控服务，但我仍然为 Komari 开发了相关的周边项目

虽然 Komari 的问题还是有很多，开发者虽然并非 CS 出身但也足够保持活跃，不能算不是一个活跃的项目

鉴于翻遍全网没有任何一个 Komari 的全面教程，遂有本文

一个小插曲

在本文编写期间，我临时创建了一个 Komari 服务在本地

单单写这些文字就已经发现了 1 个 Typo 和 1 个安全性问题，所以 Komari 任重而道远啊

ESP8266 上 Komari Agent 使用教程

Sun, 07 Sep 2025 00:00:00 +0000

ESP8266 上 Komari Agent 使用教程

<-前往本博客获取更好阅读体验->

前言

又是一日闲来无事，想给 ESP8266 上个 Komari 监控

本来是想用 Rust 当嵌入式练手项目的，但无奈发现 esp8266-hal rust 已经停止维护

又因为不想再翻出来一块 esp32 或者 uno 3，所以只好用 Arduino C 写了

开源于: https://github.com/GenshinMinecraft/komari-agent-for-esp8266-arduinoc

使用

为了方便使用，我封装成了一个库，直接放入 .h 和 .cpp 到项目文件夹即可使用:

随后去 .cpp 文件定义一下 Komari 主控的地址、Token什么的:

需要注意的是，我没有写 TLS 兼容，所以只能连接到 HTTP 主控 (不强制 HTTPs 也可以)

在主文件 .ino 里面初始化并调用它:

#include "komari.h"
#include <ESP8266WiFi.h>

const char* ssid = "Demo";
const char* password = "Demo";

void setup() {
  Serial.begin(115200);
  Serial.println("\n--- ESP8266 监控客户端 ---");

  WiFi.begin(ssid, password);
  Serial.print("正在连接.");
  while (WiFi.status() != WL_CONNECTED) {
    delay(500);
    Serial.print(".");
  }
  Serial.println("\nWiFi 已连接");
  Serial.print("IP 地址: ");
  Serial.println(WiFi.localIP());

  if (setupKomari()) {
    Serial.println("[Komari] 初始化成功");
  } else {
    Serial.println("[Komari] 初始化失败");
  }
}

void loop() {
  agentPostOnce();
  
  Serial.println("Processing");

  delay(10);
}

setup() 函数中连接网络并初始化 Komari Agent，这里会发送 ESP8266 的 Basic Info

loop() 函数中，每次循环都会调用 agentPostOnce()，内部函数会以每秒一次的时间发送 Realtime Info 到 Komari 主控，如果不到一秒则不推送

Serial.println("Processing") 是模拟真实任务，你需要将你的业务逻辑代码放在这里，但最好保证他快速执行，否则 Websocket 会断开连接

最后的一点等待是必须的，否则 CPU 占用率会误判很高，但如果你的业务逻辑代码耗时很长，也可以去掉以检测到最精准的 CPU 占用率

就这样吧

结

能用就行，无聊的产物

效果如图:

第三方 Akile Monitor 监控端使用

Fri, 06 Dec 2024 00:00:00 +0000

第三方 Akile Monitor 监控端使用

本文由 GenshinMinecraft 进行编撰，首发于本博客

前言

又是一日闲来无事，看见了 Akile 出了自家的监控面板，本着能用现成项目改的东西就一定要写的原则，写了个第三方 Akile Monitor 监控端

与原版比较

既然是重写，那就必须有比原版好的地方

测试环境均为 Redmi Book Pro 15 锐龙版 + Arch Linux

空间占用

上为原版，下为重写的 Rust 版本

可见 Binary 的占用两者相差约 15 倍 ~~(其实我也不太知道原版作为一个监控端是怎么编译出来 24M 的)~~

内存占用

原版
重写的 Rust 版本

可见，原版占用约为 18MiB，重写的 Rust 版本占用约为 4MiB

两者相差约 4.5 倍，虽然这点内存对于一个正常的小鸡来说无伤大雅，但能少一点就少一点

PS: Arm64 架构内存更少，约 1.76MiB，

便于配置

原版的配置十分麻烦 (即使有一键脚本)，需要手动配置 client.json 来指定连接的主端

而使用重写的 Rust 版本，则只需要在命令行上设置即可，Demo:

`1`	`./ak_monitor_client_rs -s 192.168.111.1:3090 -a GenshinMinecraft`

功能更多

美观输出: 原版仅有最普通的控制台输出，而 Rust 版本则使用了丰富的 log 库来优化输出 ~~(虽然也没多少人看)~~
虚假倍率: 你是否想让你的小鸡拥有顶天立地的算力？虚假倍率来助你:
- 总物理内存
- 总 Swap 内存
- 已用物理内存
- 已用 Swap 内存
- 网络进出总量
- 网络进出速度
- Load 1 / 5 / 15
以上的这些都可以随心所欲地自定义倍率，拳打太湖之光，脚踢前沿
自定义间隔时间: 这个功能我觉得是没啥用的，但是还是加上了。也就是自定义数据上报的间隔
自动获取主机名: 懒得填写主机名？这功能能帮你自动获取主机的 Hostname
自动重连: 原版只要连不上主端，就会直接退出，Rust 版即使断连也会在五秒之后自动尝试重连

安装

首先，请先来到本项目的 Action 界面: (下载要登录 Github 账户)

进入最新的自动构建，向下翻找:

在这里，请找到你的被控主机的系统与架构，并下载其压缩包

最后，解压并上传至被控主机，并赋予可执行权限即可:

`1`	`chmod +x ak_monitor_client_rs`

使用

可以通过 --help 参数输出以下的帮助信息:

Akile Monitor Rust Client

Usage: 

Options:
  -n, --name <NAME>                主机名，将展示在面板上，默认为本机 Hostname [default: GenArch]
  -s, --server <SERVER>            主端地址，需要 ip:port (Demo: 192.168.111.1:3000)
  -a, --auth-secret <AUTH_SECRET>  在主端设置的 Auth Secret
  -i, --interval <INTERVAL>        采集间隔，单位为毫秒 (不建议低于 1000ms 与高于 5000ms) [default: 1000]
  -f, --fake-times <FAKE_TIMES>    虚假倍率 (随手改一改，全世界算力都在你手上) [default: 1]
      --debug                      Debug 日志输出
      --tls                        开启 TLS 支持 (未支持)
  -h, --help                       Print help

--name： (非必须，建议设置) 主机名，将展示在面板上，默认为本机 Hostname
--server： (必须) 主端地址，需要 ip:port (Demo: 192.168.111.1:3000)
--auth-secret： (必须) 在主端设置的 Auth Secret
--interval： (非必须，不建议设置) 采集间隔，单位为毫秒 (不建议低于 1000ms 与高于 5000ms)
--fake-times： (非必须，不建议设置) 虚假倍率 (随手改一改，全世界算力都在你手上)
--debug： (非必须) Debug 日志输出
--tls： (非必须，未支持) 开启 TLS 支持
--help：查看帮助

最简单的使用方法:

下列例子均以 GenshinMinecraft 为 Auth Secret 连接至 192.168.111.1:3090 为例

连接，并自动获取主机名:

`1`	`./ak_monitor_client_rs -s 192.168.111.1:3090 -a GenshinMinecraft`

连接，并设置主机名为 GenArch:

`1`	`./ak_monitor_client_rs -s 192.168.111.1:3090 -a GenshinMinecraft -n GenArch`

连接，并设置设置虚假倍率为 2:

`1`	`./ak_monitor_client_rs -s 192.168.111.1:3090 -a GenshinMinecraft -f 2`

连接，并设置上报间隔时间为 2400ms:

`1`	`./ak_monitor_client_rs -s 192.168.111.1:3090 -a GenshinMinecraft -i 2400`

连接，并设置上报间隔时间为 2400ms，设置设置虚假倍率为 2，设置主机名为 GenArch:

`1`	`./ak_monitor_client_rs -s 192.168.111.1:3090 -a GenshinMinecraft -n GenArch -f 2 -i 2400`

保活

目前，大部分 Linux 发行版均已经使用 SystemD 作为 Pid 1，所以本文只使用 SystemD

用你喜欢的编辑器打开 /etc/systemd/system/akile_monitor_client.service

填入:

Description=Cloudflare Speedtest Slave
After=network.target

[Install]
WantedBy=multi-user.target

[Service]
Type=simple
ExecStart=/path/to/ak_monitor_client_rs -s 192.168.111.1:3090 -a GenshinMinecraft 
Restart=always

随后重载并开启本服务即可:

1
2

sudo systemctl daemon-reload
sudo systemctl enable --now akile_monitor_client

这样便完成了安装保活

结语

感谢你能看到这里，这是对一位开源工作者的最大之境，也希望本项目能帮到你

就这样吧 Thanks

使用 nezha-agent-rs

Wed, 31 Jul 2024 00:00:00 +0000

使用 nezha-agent-rs

本文由 High Ping Network 的小伙伴 GenshinMinecraft 进行编撰，首发于本博客

前言

nezha-agent-rs 是一个 Rust 编写的，用于连接 Nezha Panel 的监控，基于 Nezha 以及 Nezha Agent

写这个纯粹是为了好玩，只是想用 Rust 写个小项目来练习读取系统占用等情况，所以 nezha-agent-rs 这个项目就非常自然地产生了

相比于官方的 Agent，这一项目仅实现了首页面板的基础功能，如 CPU / RAM / 网速等，未实现如 Task / 终端等功能 (写来也是为了玩，其他功能懒得写咯)

带来的优点就是比官方 Agent 占用更小，约为 50% 的内存 (自测)，适合极低配置的设备使用

请注意: 虽然我自己正在一些性能低下的设备使用它，但由于各种原因我将不会长期维护它，没有必要还是请使用官方 Agent

下载

首先，请下载 nezha-agent-rs 的二进制文件，其位于本项目的 Action 栏下的 Artifacts 中

点击最新的 Action 编译，并在 Summary 下的 Artifacts 找到你所需的系统与架构对应的二进制压缩文件

请务必根据自己的系统以及架构选择，否则将不会运行成功

请注意，常见的架构有 musl 与 gnu 之分:

musl 适用于所有的 Linux 系统，其使用的是静态库，无需动态库的支持
gnu 适用于大部分 Linux 系统，其使用的是 Glibc，需要动态库的支持
常见的如 Ubuntu / Debian 等都可以选择 gnu，而 Openwrt / Alpine 等系统则必须选择 musl

总之，将其下载下来并上传到服务器目录即可

安装

首先为二进制文件添加可执行权限:

`1`	`chmod +x nezha-agent-rs`

然后将其移动到 PATH 中指定的目录，例如 /usr/bin:

`1`	`mv nezha-agent-rs /usr/bin/`

然后运行它:

`1`	`nezha-agent-rs --help`

如果不出意外，将会打印出帮助信息

运行

运行十分简单，仅需指定 -s 与 -p 参数即可，分别是主端 RPC 地址和密钥，如:

`1`	`nezha-agent-rs -s example.com:5555 -p 114514`

就这样，你已经成功运行了 nezha-agent-rs 了，请自行去 Nezha Panel 中查看:

保活

当然，nezha-agent-rs 需要长时间的运行，你也许需要使用各种奇技淫巧来为其设置服务等，当然这里不再赘述

也可以参考这一 Screen 教程来为其进行简单的配置

小结

还是那句话: 非必要请不要使用本项目，为了更稳定与简单，请使用官方 Agent！

欢迎加入 High Ping 大家庭:

Nodepanels-一个免费的双平台探针

Mon, 24 Jul 2023 00:00:00 +0000

Nodepanels-一个免费的双平台探针

本文由 High Ping Network 的小伙伴 GenshinMinecraft 进行编撰，首发于本博客

前言

探针是管理并查看服务器状态的重要工具，十分适合网站运维和服务器监视。

而免费且完全开源无限制的哪吒面板，就是其中的代表。

但是哪吒面板有诸多的缺点，例如需要自己搭建主端；维护难等问题。

所以就会出现Nodepanels这一新型探针，它有以下的优点

无需自己搭建主端
支持Linux/Windows一键脚本搭建探针端
免费版有5个服务器的额度
在线管理服务器（文件管理、性能测试等）
免费官方微信/QQ/Email/TeleGramBot告警通知
可以自定义分享服务器状态

所以说，Nodepanels非常适合服务器少，但是也有管理、监测需求的人！

你只需要以下的东西：

脑子和手
一个邮箱
用于挂探针（监测）的服务器（可选）

创建账号

进入到Nodepanels官网

注册一个账号

收完验证码后即可完成注册！

连接到服务器

登入面板，点击服务器列表左侧的添加服务器

按需选择Linux or Windows

Linux可以直接复制并在终端执行；

Windows可以使用cmd/powershell执行。

执行完成后，刷新界面，在服务器列表下能看见自己的服务器并且显示在线即为添加完成！

设置服务器（可选）

我们还可以在*Nodepanels中设置服务器

点击列表的右侧部分来进行对服务器的设置

也可以点击服务器名称，对服务器进行更加详细的监测与调试

这么多功能，就不一一详细讲解了，有需要的朋友可以自行研究这些功能！

设置告警（可选）

对于一些网站服务器来说，当遭遇攻击时更需要及时地提醒。

在顶部导航栏的设置-告警设置中，可以使用QQ/微信/邮箱/Telegram/Webhook多种方式进行提醒，只需要把右边的按钮打开即可

点击下面的添加规则，详尽地添加需要告警地条件以及需要告警的服务器，可以做到更有规则地管理

分享服务器状态

我们可以把服务器状态分享炫耀给朋友们看

在顶部导航栏的设置-分享设置中，可以对需要分享的服务器进行选择，还可以根据需要隐藏信息

然后就会生成一条分享连接，就可以分享给朋友查看啦！

顺便来炫耀一下我的服务器（偷笑）：GenshinMinecraft 的服务器

总结

Nodepanels基础的功能就这么多啦，作为日常的探针还是足足够用的。

对于一些比较懒（belike me）的人，或者是服务器较少的人来说就是不二之选！

有需要也可以付费支持，在此附上价格表：

欢迎加入 High Ping 大家庭: