国产监控夜莺 v4 来了,大幅降低部署维护难度
大家好,经过 2 个月的开发,夜莺 v4 来了,欢迎大家试用。本文为大家介绍一下开发 v4 的背景、最新模块组成、升级建议,同时演示一下单机快速部署的方式。如果朋友是第一次尝试夜莺,可以按照后面讲解的部署方式来搞,5 分钟搞定。
演进背景
v3 版本融入了很多运维平台的功能,组件变多,部署麻烦,不同的组件相互之间有调用关系,在做分布式部署的时候需要了解整体架构才能正确修改配置文件,对用户提出了较高的要求。很多 issue 和群里的讨论,都反映出了这个复杂性问题。
我们希望降低这个复杂度,所以,把众多服务端模块做了合并。这样原来组件之间的调用都变成了进程内部的方法调用,可靠性性能都会提升。
新的架构
模块合并之后,把时序存储抽离,总共只剩 3 个组件:server、prober、agentd。
服务端就是部署 server 模块,如果要集群部署,就搞 2 个机器,每个机器分别部署 server 模块即可。每个 server 会使用本机的 redis,所以,有几个 server 就部署几个 redis,redis 只需监听在 127.0.0.1,供本机的 server 使用即可。
prober 是个中心式探针,比如贵司有 2 个网络区域,每个网络区域可以部署一个 prober,用此 prober 采集监控本区域的数据库中间件。如果担心 prober 挂掉,每个区域可以部署多个 prober 做高可用。不同网络区域的 prober,有个配置要注意,即:report.region 字段,比如有 bj 和 gz 两个网络区域,每个网络区域分别部署了 2 台 prober,bj 的 2 台 prober,report.region 要设置为 bj,gz 的 2 台 prober,report.region 要设置为 gz。最后,在 server.yml 里修改 monapi.region 字段,配上 bj 和 gz。
如果网络是可以互联互通的,那就简单了,prober 和 server 混部即可,都放到中心。
agentd 是部署到所有目标机器的,采集目标机器的性能指标,在目标机器执行插件之类的,v4 版本的 agentd 与 server 之间通信只走了 server 的 rpc 端口,所以相比 v3,开通网络 acl 要变简单了。
升级建议
如果 v2、v3 已经玩得很溜了,并且满足贵司的需求,就不建议升级了。当然,如果新版本有些功能特别想要,那就只能升级了。
如果时序库是使用的 tsdb+index 这个方案,tsdb 进程不用动,可以复用 v3 的,但是 index 需要升级。tsdb+index 这俩模块的代码抽取到了 github.com/n9e/n9e-tsdb 中了,编译方法和二进制最新地址都可以在这个 repo 的 README 中找到。
server.yml 默认使用 m3 作为存储后端,所以,如果使用 tsdb+index 的方案,需要修改 server.yml,把 DataSource 改成使用 tsdb。
不过我个人建议大家尝试一下 m3db,容灾、扩容都做的很方便。
快速部署
这里我带着大家部署一个单机版本的夜莺 v4,请大家提前准备好 mysql、redis、nginx,单机部署,直接 yum 安装即可,非常简便。请找一台干净的机器测试!
1、下载二进制
2、初始化数据库,这里假设使用 root 账号,密码为 1234,如果不是这个账号密码,需要修改 /home/n9e/etc/mysql.yml
3、redis 请不要配置密码, 如果 redis 设置了密码,需要修改/home/n9e/etc/server.yml,把密码改对
4、下载前端静态资源文件,放到/home/n9e 下,请不要随意更换目录结构,否则还要自行修改 nginx.conf,徒增烦恼
5、覆盖 nginx.conf。如果静态资源文件不是放到/home/n9e 下的,就要先修改 nginx.conf 了
6、时序数据存储部署,这里选择使用单机版本的 m3db
7、最后一步,启动相关进程。即可访问 nginx 看效果了
默认用户是 root,密码是 root.2020,效果图如下:
如果搭建过程遇到问题,可以加小助手微信,注明“夜莺加群”,小助手将您拉入网友互助交流群。
版权声明: 本文为 InfoQ 作者【运维散兵】的原创文章。
原文链接:【http://xie.infoq.cn/article/38017304f1b9f57874a628947】。
本文遵守【CC-BY 4.0】协议,转载请保留原文出处及本版权声明。
评论