人就是有点奇怪,有了第一台服务器之后就想要第二台,有了1h2的就想要2h4g的服务器,反正永远也得不到满足 :)。最近双十一又来了,才发现现在服务器价格又降了,之前99的1h2g1m服务器现在只要43,而且宽带还升到5M了,虽然仅限于新用户。哎果真是早买早享受,晚买享折扣了。赶紧入手一台再说吧。


到后面慢慢发现随着自己入手的服务器数量变多了,有的快要到期了有的才刚入手,管理就渐渐变成了一个问题了。最尴尬就是,直接忘记自己配置 SSH 端口号,不过这还算是好的了,SSH 端口可以扫出来,但是我直接把登录密码也给忘记了,就十分难受了。突然想登录上去,却发现死活记不得密码是多少了,真就是过于麻烦。

监控需求

为了解决我的痛点,最好能整一套监控设施,可以让我方便快捷了解各个服务器的基本信息。之前在网络调研过一些内容,大部分都在说“elasticsearch”+“loki”+“prometheus”,“graylog”之类的方案,反正都是挺麻烦了,而且“elasticsearch”还是 Java 搞的,比较占内存是真的吃不消(小鸡太垃圾了),因此我一直都没功夫管它们,大部分时间就让它们一直在吃灰。


之前听说过探针,在许多VPS飞机场都能见到,此外一些大厂也提供“status”查看,例如 cloudflarestatus,就可以看到其服务运行情况。看到一位学长用的是“nezha”探针,因此我就选择它作为我的监控平台。

探针原理

探针涉及到服务器状态“信息”的收集和发布,其关键点就在于如何收集这些信息。生活中常见的就有,老师想要收集一下每个班的学生健康状况,于是将任务分配给各个班长。班长这个时候可以选择:1)每个人询问一遍,然后汇总;2)让每个人自己填问卷上报给班长。一般情况下,选择2)才是普遍采用的方法。


探针收集信息的方法也就无非是“pull”和“push”这两种,要么向每个服务器“pull”拉去信息,要么每个服务器向我“push”推送信息。结合实际情况,显然“push”才是最适合我们的情况,因为它只需要一台“中心”服务器即可,其它“agent”只需要能访问到这台“中心”服务器即可。

确定了采用“push”模式,自然还要觉得一下采用何种“protocol”来传输数据,简单一点就是“HTTP”直接推送即可,高效一点就用“RPC”的方式。这里哪吒监控采用的自然是,“push”模式下的“grpc”推送信息。

了解上述内容,我们就知道如何部署探针了。


哪吒监控部署

哪吒监控是由 Go 编写,因此非常容易到处部署,以下仅仅介绍比较重要的内容,其它繁杂无意义的内容不做说明。

Dashboard 控制端

服务端要对外提供 web 页面和 grpc 推送接收端,因此需要开放两个端口。由于我使用的是 Docker 部署,因此我只需要开放“grpc”对应的端口即可,web 端口通过“traefik”进行反向代理,提供域名与证书服务。


修改后的配置文件

debug: false
httpport: 80
grpcport: 1234
oauth2:
  type: "github" #Oauth2 登录接入类型,gitee/github
  admin: "000" #管理员列表,半角逗号隔开
  clientid: "111" # 在 https://github.com/settings/developers 创建,无需审核 Callback 填 http(s)://域名或IP/oauth2/callback
  clientsecret: "222"
site:
  brand: "梦之针"
  cookiename: "nz-db" #浏览器 Cookie 字段名,可不改
  theme: "default"

备注:由于我使用的是“docker config”挂载上去的配置文件,因此无法通过后台修改此配置文件,同时我也觉得后台不应该修改用户手动创建的配置文件(虽然自动创建修改配置文件能减轻用户负担,但是不太看哈好这样的做法)。

部署完成后就可以正常打开“tz.dreamer2q.wang”页面了。

备注(关于github认证):由于管理后台公开在外面,因此需要一定的手段来区分“管理员”和“普通用户”,这里简单的来说就是搞一个用户提醒,现在监控服务不需要搞这么麻烦,只需要利用到现有的账号体系即可,这里的 github 使用最简单和轻松(最松基本没啥限制),登录只是次要的其核心的通过“oauth”确认管理员用户。


Agent 客户端

相比于 dashboard,agent 一般要求是安装“简单”且“傻瓜”这样才是最友好的,最好是全自动化的。
好在“nezha-agent”基本满足这个要求,只需要在管理后台复制“安装命令”进行安装即可,能解决大部分问题。但是对于一些其它终端例如,路由器、群晖等自动安装脚步就无非正常使用了。这个时候就需要你自己手动安装,配置好“启动项”,还需要确保“agent”被“kill”后还能自动启动。如果熟悉这套流程还好,但是像我就不太熟悉,但是我可以选择使用“容器”,以上这些问题只需要启动一个后台运行“agent”容器即可解决问题。

一般普通的路由器是没有 docker 的,需要定制固件,或者使用别人打包好的固件

Docker 下的 agent 客户端

由于项目没有提供“agent”打包镜像,因此需要我们自己进行 docker 打包发布。

FROM alpine

WORKDIR / # 工作目录

COPY nezha-agent agent

ENTRYPOINT ["/agent"]

进入到agent目录下面,通过

docker build -t dreamer2q/nezha-agent:0.11.3 .

来完成打包过程,之后就可以通过具有“docker”的环境部署“agent”节点即可。之后就可以推送到“hub.docker.com”上面了,这里我已经推送了当前最新的“agent”版本:0.11.3。


接下来的事情就很简单了,只需要通过“docker run”即可启动一个“agent”容器。需要注意的是,请把“网络”设置成本机“host”的模式,这样才可以正常监控主机的网络使用情况。

docker run --name=agent \
                     --net=host -d dreamer2q/nezha-agent:0.11.3 \
           -p "password" -s "server:port"

这里通过“--net=host”指定容器使用主机网络,如果发现其它监控数据不正常可能需要给予容器更多的权限,这里我暂时没有遇到,因此不理会。


总结

哪吒监控还可以做到挺多东西的,比如说“报警”,“远程管理”还是挺方便的。这次探针的部署,可以让我更好的看到自己管理的设备运行情况,目前还在探索使用中,后续应该会把推送功能配置好。不过收获更多的是还是关于“消息”推送的思考,如何将“消息”从一方传递到另一方?中心服务器如果挂的怎么办?这种方法真的是最优解没?中心服务器可以上“serverless”吗?等等。这些问题还需要我慢慢在实践中体会与反思。

Last modification:November 8th, 2021 at 01:04 pm
要饭啦~