Introduction or Why Should I Bother

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介:

   日志管理通常是被认为一件即痛苦又黑暗的经历。确实,熟知良好的日志管理将会是一个缓慢而不断进化的过程。新的系统管理人员,在遇到问题时,总是被告知“去查看日志吧”。这时,在日志和事件数据中,通过简单系统命令的组合,如cat、tail、grep(还包括sed、awk、perl)等,诊断并确定出问题所在。他们将会成为命令行下的专家,熟知正则表达式的功夫:如从混杂的日志事件中查询(searching)、解析(parsing)、剥离(stripping)、处理(manipulating)、提取(extracting)数据。我强烈建议所有的系统管理人员都应该学习掌握这些强大而实用的技巧。

   不幸的是,这样简单的解决方案(仅靠系统命令)并不能扩展。在多数情况下,你将面对多台主机和日志文件的多样来源。你将面对几十、几百、甚至上千台的主机,并在物理端、虚拟端、云端运行着多种相互通信的应用和跨地区跨网络结构的服务。在当今世界,来自于单一应用、服务或主机的日志已越来越不能够诊断复杂的多层次(multi-tier)事件。

   为了解决这种分歧(gap),日志管理必须发展至集中化,选择使用的工具也扩展至包括配置应用(applications)生成中心日志,配置服务(如rsyslog、syslog-ng)生成集中传输的系统日志输出。然后,事件(events)开始流入,并建立接收这些数据的专门的日志服务器,消耗越来越多的存储空间。

   但这还远没有结束,问题将从过少的信息量转变为过多的信息量和过少的实质内容。你将需要筛选百万或者数十亿行的日志,而这些日志又将在不同时区、不同格式、甚至不同语言下产生。这样,从不断增长的日志数据流中找到需要的数据将变得急剧的困难,同时找出与其他事件的关联将更加困难,故不断增长的日志事件的收集将弊大于利。

   为了解决这个新问题,你必须扩展你的日志管理解决方案,以包括对日志更好的语法分析、更灵活的存储机制,还得不带可搜索和索引技术。从当初对日志文件进行简单的grep操作,到进阶为不依靠外力的主要项目(project)。这个项目在精力和费用同等代价的情况下,实现了多个解决方案的迭代融合。


简介(Introducing LogStash)

为了避免走上这条路,即伴随着高成本投入和潜在的发展困境,你可以开始尝试LogStash。LogStash提供了一套整合的框架,包括日志收集、集中化、语法分析、存储和搜索等。

   LogStash是开源免费的,由美国的开发者兼Dreamhost的日志霸主(Logging Czar)Jordan Sissel开发。安装简单,高性能,可扩展,易于二次开发。

   LogStash拥有丰富多样的输入机制:可以从TCP/UDP、文件、Syslog、微软日志事件(Microsoft Windows EventLogs)、输入(STDIN)和其它来源等获得输入信息。结果就是,在你的环境下,很少有机会不能从LogStash提取日志,或发送日志至LogStash。

   当上述日志到达LogStash服务器时,将提供一个大集合的过滤器,允许你对这些事件进行修改、操作和转化。你可以从日志事件中提取你所需要的信息,并赋予其上下文内容(context)。LogStash使得查询这些事件变得简单,也使得利用日志数据产生结论并做决定变得容易。

   最后,当输出数据时,LogStash依然支持大量的输出方式,包括TCP/UDP、邮件(email)、文件、HTTP、Nagios和其他大量的网络在线服务。你可以将LogStash和度量引擎(metrics engines)、报警工具(alerting tools)、画图套件(graphing suites)、存储器(storage destinations)等进行整合,甚至可以建立自己的日志输出的整合方式。


LogStash设计及架构(LogStash design and architecture)

   LogStash是由JRuby语言编写的,并运行在Java虚拟机(JVM)上。它的架构简单,并是基于消息的(message-based)。不同于分离的代理端(agent)和服务器端(server),LogStash可配置一个简单的代理端,通过与其他开源组件的结合,以实现不同的功能。

   在LogStash的生态系统中,存在四个组件:

       Shipper:发送事件(event)至LogStash;远程代理端只需要运行这个组件即可;

       Broker and Indexer:接收事件,并对事件建立索引;

       Search and Storage:允许存储和搜索事件;

       Web Interface:基于Web的前端界面

   LogStash服务器端独立运行以上一个或者多个组件,以便于分离组件和对LogStash进行扩展。

   在多数情况下,你一般需要运行两大类LogStash主机:

       一类主机运行LogStash代理端作为事件的转发者(shipper),将应用、服务和主机的日志发送至中心LogStash服务器。这类主机将只需要运行LogStash代理程序(即shipper);

       另一类主机,即是中心LogStash服务器,可运行包括代理(Broker)、索引器(Indexer)、搜索和存储(Search and Storage)、Web界面(Web Interface)等的集合,以对日志进行接收、处理和存储。

160712131.jpg

这本书包含什么?(What's in the book?)

在这本书中,我将带领你们熟悉安装、部署、管理和扩展LogStash。为了达到这个目的,我将介绍你进入Example.com(一个虚拟网站),在那里你将作为一名系统管理人员开始新的工作。你负责的第一个项目就是开发一套新的日志管理方案。

   我们将会教你如何:

       安装和部署LogStash;

       从Shipper端转发事件(即日志)至中心LogStash服务器;

       使用多种技术过滤进入的事件;

       输出这个事件至可选择的可用目的地;

       使用LogStash的Kibana进行web前端展示;

       当环境发展时扩容LogStash运行结构;

       快速简单的延伸LogStash以交付额外的功能。

   在本书结束时,你应该拥有一套可部署在自己环境下的实用而有效的日志管理方案。


LogStash资源(LogStash resources)

LogStash官网:http://www.logstash.net/

   LogStash指南:http://cookbook.logstash.net/

   GitHub上的LogStash源代码:https://github.com/logstash/logstash/

   作者Jordan Sissel的主页:http://www.semicomplete.com/


如何获得帮助(Getting help with LogStash)

   LogStash的开发者Jordan Sissel有一句使得获取帮助变得容易的格言:如果一个新手体验不好,这将是LogStash的bug(If a newbie has a bad time, it's a bug in LogStash)。所以即使通过邮件列表(mailing list)或者IRC寻求帮助遇到麻烦,你也可以通过LogStash社区获得友好并有益的支持。

   LogStash文档:http://logstash.net/docs/1.2.2/

   LogStash指南:http://cookbook.logstash.net/

   LogStash用户邮件列表:https://groups.google.com/forum/?fromgroups#!forum/logstash-users

   LogStash Bug追踪:https://logstash.jira.com/secure/Dashboard.jspa

   Freenode上的IRC频道:#logstash


温馨提醒(A mild warning)

LogStash是一个年轻的产品,还处于周期的开发环境下,将会定期的改变、添加、更新或者弃用某些特性。我建议你们在Jira支持站点(https://logstash.jira.com/secure/Dashboard.jspa)或GitHub上跟随我们的开发进度,回顾每个版本发布时的chang日志以了解所做的修改。LogStash通常向后兼容(backwards compatible),同时问题(issue)出现后能被告知,则可节省不必要的排错(troubleshooting)精力。










本文转自 xxrenzhe11 51CTO博客,原文链接:http://blog.51cto.com/xxrenzhe/1343968,如需转载请自行联系原作者
相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
4月前
|
前端开发 JavaScript 算法
shouldComponentUpdate 是做什么的?
shouldComponentUpdate 是做什么的?
115 0
《Towards A Fault-Tolerant Speaker Verification System A Regularization Approach To Reduce The Condition Number》电子版地址
Towards A Fault-Tolerant Speaker Verification System: A Regularization Approach To Reduce The Condition Number
81 0
《Towards A Fault-Tolerant Speaker Verification System A Regularization Approach To Reduce The Condition Number》电子版地址
|
机器学习/深度学习 算法
Data Structures and Algorithms (English) - 7-28 Review of Programming Contest Rules(30 分)
Data Structures and Algorithms (English) - 7-28 Review of Programming Contest Rules(30 分)
199 0
Data Structures and Algorithms (English) - 7-28 Review of Programming Contest Rules(30 分)
|
Java
HDU - 2018 Multi-University Training Contest 1 - 1001: Maximum Multiple
HDU - 2018 Multi-University Training Contest 1 - 1001: Maximum Multiple
93 0
Multiple Origin composition test - Opportunity Creation case
Sent: Wednesday, 3 December, 2014 2:48 PM 结论是:如果gateway系统上针对一个odata service维护了多个mark成default的backend system,在creation的case下,runtime时候gateway只会向第一个 Default system发起请求。
Multiple Origin composition test - Opportunity Creation case
|
JavaScript 安全 前端开发
What Is ElectronJS and Why Should You Use It?
In this three-part tutorial, we will explore how to create a fully functional invoice application using ElectronJS and ApsaraDB for MongoDB.
2648 0
What Is ElectronJS and Why Should You Use It?
|
开发工具 计算机视觉