Log.IO的使用场景和改造思路

实时日志浏览,通俗点来说就是跑到服务器上tail -f xxxx,然后盯着屏幕,看着它不断的打日志。当应用被部署在一台服务器的时候,tail一下的确也可以解决问题了,但是随着应用部署的服务器数量越来越多,服务器上的各类日志数量的不断增长,势必就会造成日志文件的浏览非常的不便。频繁切换终端的窗口,切换切换着甚至自己都忘记究竟在哪台服务器上,看的是那份日志文件了。

今天看到一篇有关于log.io的文章,上传送门《想实时 tail 多台机器上面的日志?试试 Log.io 或者 Sumo Logic 的新功能》,突然发现这个软件正好就能解决小型团队最容易碰到的实时日志浏览的问题

Log.IO能做什么

这个软件的功能非常简单,对的,非常简单!不像Zabbix一样具备非常多的隐藏技能,安装过程非常简单.

npm install -g log.io --user "root"
//启动server
log.io-server
//修改一下配置,主要改服务器信息和日志路径
vi ~/.log.io/harvester.conf
//启动采集器
log.io-harvester
//访问页面
 http://localhost:28778
Log.IO的使用场景和改造思路_第1张图片
Paste_Image.png

他就提供了一个看实时日志的界面(原谅我突然就开启了吐槽模式,你这会不会也太简单了一点),不过总的来说,问题还是能解决的,左侧的菜单思路是节点->应用名这样的模式,这个倒是挺正派的,一个节点底下会有多份不同的日志(话说作者不知道有没考虑过给节点分个组呢),右侧的就是应用了,勾选的日志信息都会在这里展现出来,其实单服务器的话倒是没什么问题,但是多服务器,刷日志又刷的快的情况下,这个界面就会看的眼花缭乱了。

Log.IO源码分析

站在巨人的肩膀上(有现成的就拿来抄)的思想是我一直所坚持的(这才是生产力啊!ヽ( )ノ),先看整体架构,直接上官方架构图

Log.IO的使用场景和改造思路_第2张图片
Paste_Image.png

做法是通过Harvester进行日志采集,通过TCP送到Server,然后Server通过WebSocket送到web页面上面。

Harvester的运转方式

  • 记录指定日志文件的Current Position,然后监控日志文件的变化(NodeJS本身就挺多这样的库的),每当发生Change事件之后,往下读文件
  • 把变更的文件通过一定的格式采用TCP协议送到Server端
+log|web_server|my_server01|info|this is log messages

Server的运作方式

Server在接受到Harvester送来的的信息之后,把字符串变成LogObject、LogStream、LogNode等一系列对象

通过Socket.IO这个库把日志信息往外送,Socket.IO这个库倒是挺简单易用的,上个官网例子

var io = require('socket.io')(80);
var cfg = require('./config.json');
var tw = require('node-tweet-stream')(cfg);
tw.track('socket.io');
tw.track('javascript');
tw.on('tweet', function(tweet){
  io.emit('tweet', tweet);
});

Web

Web的开发上倒是挺中规中矩的,采用比较流行的Express,然后通过WebSocket接收完数据之后就把对应的数据显示在页面上

一些想法

Log.IO这个应用代码量非常的少,这种易读性使得这个程序非常适合拿来改造(比起读Kibana那界面的原源码,这简直就是天堂T_T),所以,不由的就产生了一些想法

对Harvester的一些想法

按照Harvester的运作方式来看,我认为完全可以不采用log.io的Harvester,而直接采用类似Rsyslog这样的大多数操作系统上都存在的日志收集工具就可以了,免去Agent部署升级的烦恼。不然还不知道会不会碰上Agent性能不稳定搞挂服务器呢

对Server的一些想法

既然是WebSocket,那么是不是可以采用类似在Nginx上加WebSocket扩展之类的做法来把Server替换掉呢?

log.io是不是能够集成到ELK这类日志搜索软件里面,作为辅助功能存在呢?日志先送到ES或者是一些其他地方,然后再通过一些Transfer程序把日志送到Server

对Web的一些想法

Web这种操作上的东西,应各业务场景(个人品味。。。)不同会有比较大的差别,假如是我设计这个功能的原型,我会希望页面上能有这样的功能。

  • 实时日志按照时间分屏展示;
  • 能够在界面上输入关键字,然后对关键字日志高亮,方便排查问题;
  • 再多一个业务模块的分组,方便对整组业务模块的服务器进行过滤;
  • 根据提供的关键字信息,只展示具备关键字的日志行(类似tail -f xxx|grep 这样的功能);

你可能感兴趣的:(Log.IO的使用场景和改造思路)