在微服务日趋流行的今天,应用数量是直线上升,同时为了达到高可用、大流量等还会同一应用部署多个实例。这样一来,想要查看分散在各个主机上的日志,就要在不同的主机控制台之间来回切换,并且要记住每个应用及不同实例所在的主机,就没那么愉快了。
打着提升程序员的幸福指数的旗号,Spider出现了。
Spider/ˈspaɪdər/ ,蜘蛛。憧憬它可以像蜘蛛一样,把所有的主机节点织成一张蜘蛛网,我们可以像蜘蛛侠一样,在任意一个结点上可达全部结点。它使用web方式提供全网的日志访问。
先来个GIF动态图,直观感受下,小心它会循环播放,不要认为你能看到结尾。
控制台
如果是当前浏览的是主节点,进入当前结点的控制台,因为在主机页面进入的是首页。
主机
这里会显示整个蜘蛛网上的所有结点,可以点击对应的结点进入控制台。如果带有主节点标识,就会进入首页。
应用
这里的应用其实就是对应一个目录,不同目录表示不同的应用。如果你知道具体目录并且你愿意,你可以一级一级点进去,否则可以使用搜索功能(这里会优先展示目录,及不包含日期的日志文件,因为我觉得你可能更希望看到最新的日志)。
搜索功能会实时响应你的输入,如果展示出了搜索目标,如果是目录点击进入,或者进入对应的主机控制台通过tail -f 显示对应的文件内容,你可以使用Ctrl+c 结束当前命令,执行任何你想执行并且操作系统支持的命令。这即满足了网络浏览日志的便捷性,又提供了命令行操作的强大功能。
如果你想要下载日志,点击对应的链接即可,在控制台内也可以使用sz命令发送到本地。
把想要对外提供访问的目录,以只读方式挂载到Docker容器内。一个Docker容器视为蜘蛛网上的一个结点,结点并不与主机完全一一对应,理论上同一台主机上可以运行多个结点,但是没必要。所有结点向主结点推送文件信息(不包含文件内容);
主要技术
- Docker
容器化技术,便于权限管理、资源控制,方便部署。 - Nodejs
轻量,快速。单个节点上内存消耗百兆左右,CPU几乎无消耗。 - WebSocket
全双工长连接。服务端可以随时推送新数据,并且可以分批推送,页面实时展示。避免文件数量过大之后,出现请求时间过长导致页面白屏或者出现错误。
为什么要设置主结点
主结点就是蜘蛛所在的结点,也就是我们想要在哪里查看所有的日志。如果当前结点坏了,蜘蛛可以爬到另外一个结点,让其成为主结点。任意结点都可以成为主结点,但是没必要同时成为主结点(理论上支持),因为避免不必要的资源浪费。当然单机版部署也是支持的。页面显示的只是当前结点内的文件信息。有主结点的情况下,所有的结点上也可以查看当前结点内的文件信息。
推送时效
使用实时增量,周期全量的方式维护文件信息。
-
实时增量
所有结点新增的日志文件近乎实时可以在前端展示。利用Nodejs的文件监控功能,实时发现文件系统的变动,把新增的文件信息实时推送到主结点,服务端通过websocket技术推送到前端。 - 周期全量
所有结点通过固定的周期频率,将本机上的所有文件信息(如果太多会分批)推送到主结点上。页面会固定周期告诉主结点你该给我推送最新文件信息了。 主结点会记录文件的到达时间,每次向页面推送时会排除到达时间在三个周期以前的文件(毕竟网络不可靠,我给他三次机会如果三个周期内没有再次到达,就认为这个结点离网了);这样虽然页面有时可能会存在已经离网的文件,但是对日志查看来说并没有多大影响。
如果大家有这方面的烦恼,希望可以给你提供一种解决思路。如果我们理解我这个实现原理,我们不仅仅可以用来日志的收集,其他任何需要在不同主机上操作文件的动作都可以完成。可以举一反三,实现自己的需求。
相应的源码已经托管在github上,大家可以自由Fork修改。
热门评论
您好,多台机器是否是需要全部安装才可以