文/赵杰
2015.11.04
1. 前言
服务端日志你有多重视?
我们没有日志
有日志,但基本不去控制需要输出的内容
经常微调日志,只输出我们想看和有用的
经常监控日志,一方面帮助日志微调,一方面及早发现程序的问题
只做到第1点的,你可以洗洗去睡了。很多公司都有做到第2点和第3点,这些公司的服务端程序基本已经跑了很长时间了,已比较稳定,确实无需花太多时间去关注。如果一个新产品,在上线初期,我觉得就有必要做到第4点。
日志怎么看?
都说了,我们没有日志
线上日志逐个tail+grep
编写脚本,下载某个时间范围内的全部日志到本地再搜索
tail+grep或者把日志下载下来再搜索,可以应付不多的主机和应用不多的部署场景。但对于多机多应用部署就不合适了。这里的多机多应用指的是同一种应用被部署到几台服务器上,每台服务器上又部署着不同的多个应用。可以想象,这种场景下,为了监控或者搜索某段日志,需要登陆多台服务器,执行多个tail -F和grep命令。一方面这很被动。另一方面,效率非常低,数次操作下来,程序员的心情也会变糟(我还要去维护宇宙和平的好嘛)。
这篇文章讲的就是如何解决分布式系统的日志管理问题。先给大家看看最终的效果:
单个屏幕上所有服务器的日志实时滚动着显示。每条日志开头还标明日志的来源(下图)。
实现这种效果的原理是后台跑着一个程序,这个程序负责汇总所有日志到一个本地文件中。只要执行tail -f这个文件就可以做到监控日志了。因为所有日志都汇总在一个文件里了,所以做日志搜索的时候只要针对这一个文件搜索就可以了。
能够汇总日志文件的工具名字叫Logstash,即本文的介绍重点。它使用JRuby编写,开源,主流,免费,使用简单(宇宙和平使者必备单品)。
2. Logstash部署架构
Logstash的理念很简单,它只做3件事情:
Collect:数据输入
Enrich:数据加工,如过滤,改写等
Transport:数据输出
别看它只做3件事,但通过组合输入和输出,可以变幻出多种架构实现多种需求。这里只抛出用以解决日志汇总需求的部署架构图