>[info] elk 可以帮我们解决哪些问题，为何而生? **待解决的痛点：** 1. 大量不同种类的日志成为了运维人员的负担，不方便管理。 2. 单个日志文件巨大，无法使用常用的文本工具分析，检索困难。 3. 日志分布在多台不同的服务器上，业务一旦出现故障，需要一台台查看日志。 ***** **为什么要做日志分析平台？** 随着业务量的增长，每天业务服务器将会产生上亿条的日志，单个日志文件达几个GB，这时我们发现用Linux自带工 具，cat grep awk 分析越来越力不从心了，而且除了服务器日志，还有程序报错日志，分布在不同的服务器，查阅繁琐。 ***** **以前不用 elk 的做法：** 最开始我些项目的时候，都习惯用php的error\_log函数来把日志写到log文件中，后来项目有了高可用的要求，我们 就进行了分布式部署web，这样我们还是用error\_log函数这样的方式来记录log的话，那么就有N台机子的N个log目 录，这个时候查找log起来非常麻烦，不知道问题用户出错log是写在哪一台服务器上的，后来，想到一个办法，干脆 把log直接写到数据库中去，这样做，虽然解决了查找异常信息便利性的问题了，但存在两个缺陷： 1. log记录好多，表不够用啊，又得分库分表了。 2. 连接db，如果是数据库异常，那边log就丢失了，那么为了解决log丢失的问题，那么还得先将log写在本地，然后 等db连通了后，再将log同步到db，这样的处理办法，感觉是越搞越复杂。 ***** **现在用 elk 做法：** 好在现在有了ELK这样的方案，可以解决以上存在的烦恼，首先是，使用elasticsearch来存储日志信息，对一般系统 来说可以理解为可以存储无限条数据，因为elasticsearch有良好的扩展性，然后是有一个logstash，可以把理解为数 据接口，为elasticsearch对接外面过来的log数据，它对接的渠道，有kafka，有log文件，有redis等等，足够兼容N 多log形式，最后还有一个部分就是kibana，它主要用来做数据展现，log那么多数据都存放在elasticsearch中，我们 得看看log是什么样子的吧，这个kibana就是为了让我们看log数据的，但还有一个更重要的功能是，可以图表形式来 对log数据进行直观的展现。 >[] 日志对于任何的系统来讲都是极其重要的组成部分，通常日志分散在不同的设备上，对于一个大型应用来讲， 应用程序有可能分布在几十甚至上百台应用服务器上。如果对应用日志不进行统一的收集，对于这种分布式部 署的应用日志就非常不方便开发人员或者运维人员查询，同时分散的日志也不便于管理，因此构建一个统一的 日志管理系统就十分有必要。