>[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數據進行直觀的展現。 >[] 日志對于任何的系統來講都是極其重要的組成部分，通常日志分散在不同的設備上，對于一個大型應用來講， 應用程序有可能分布在幾十甚至上百臺應用服務器上。如果對應用日志不進行統一的收集，對于這種分布式部 署的應用日志就非常不方便開發人員或者運維人員查詢，同時分散的日志也不便于管理，因此構建一個統一的 日志管理系統就十分有必要。