現在使用的比較常用的日誌分析系統有splunk和elk，splunk功能齊全，處理能力強，但是是商用專案，而且收費高。elk則是splunk專案的乙個開源實現，elk是elasticsearch（es）、logstash、kibana上個專案結合。es就是基於lucene的儲存，索引的搜尋引擎；logstash是提供輸入輸出及轉化處理外掛程式的日誌標準化管道；kibana提供視覺化和查詢統計的使用者介面。往往這些開源專案並不是適合每乙個公司的業務，業務不同，對開源專案擴充套件也就不同，logstash進行日誌採集時，在agent端並不適合做資料清洗，資料清洗往往是經常變化的，而且agent一般占用的資源必須要受到一定限制否則會影響業務系統。我們可以將日誌的採集採用一些開源系統重新進行組合，因為日誌採集的業務特性，可以採用es+kafka進行初步的儲存查詢。首先以http協議收集日誌為例，
將整個日誌儲存查詢總體分為四個層處理：
第一層：日誌採集層；
主要處理日誌採集的過程，針對生成的日誌不同，大體上分成三大部分：
（1）、日誌通過http協議彙總到伺服器端，一般是web端，或者ios、android移動端通過http 請求上報日誌，這部分日誌採集的agent暴露在公網上，可能會存在一些惡意上報垃圾日誌，這部分日誌是需要進行許可權驗證的，例如：在上報的日誌中帶上token的驗證，驗證不成功直接丟棄，成功則將log存入到kafka對應的topic中。
（2）、伺服器上的文字日誌，這部分日誌一般是業務系統儲存的log檔案，由於存在的是伺服器端，一般不需要進行token驗證，就可以直接採用logstash或者rsyslog進行彙總到kafka中去。
（3）、非文字日誌，需要自己進行開發的自定義agent 採集相關日誌傳送到kafka中，如監控某乙個 radis、mysql等元件。此類日誌和（2）相同，一般不是暴露在公網上，不需要進行token驗證。
第二層：kafka
（1）、kafka的主要作用乙個方面主要是為防止採集量大於日誌清洗、儲存的能力，這樣會造成日誌系統處理不及時，或者造成系統宕機，引起日誌丟失。kafka是apache開源的hadoop生態圈中的分布式訊息佇列，其擴充套件性、和效能是非常強大的。加入訊息佇列在遇到日誌高峰期，不能及時處理的日誌儲存在kafka中，不影響後面的日誌清洗的系統，同時通過分析kafka 中日誌佇列的處理情況能夠，對日誌清洗層能力進行擴充套件和縮減。
（2）、另一方面就是方便系統解耦 ，使用kafka也方便擴充套件，如果要對日誌進行一些實時統計處理，則採用storm-kafka直接訂閱相關的topic就能夠將日誌資料匯入到storm集群中進行實時統計分析。
第三層：日誌清洗層；
將所有的日誌清洗和統計的邏輯歸於這一層進行處理。
第四層：日誌儲存層；
將日誌存入到es進行索引建立和查詢。
官方文件：
同時也可以採用cdh、ambari等集群管理工具安裝 kafka，這裡不再贅述，ambari離線安裝文件：
oracle儲存查詢
查詢表空間情況 select a.tablespace name 表空間名 total 表空間大小 free 表空間剩餘大小 total free 表空間使用大小 total 1024 1024 1024 表空間大小 g free 1024 1024 1024 表空間剩餘大小 g total fre...
聊聊資料儲存查詢
這裡我沒有說出是資料庫的操作，但是一般來說，我們都是採用資料庫。對於資料庫儲存，我想先說說幾類優化。1 sql語句優化 說sql語句優化，這個內容比較大，我記得還有專門說sql優化的文件，網上可以自己搜尋，因為每一種資料庫有自己特性，優化語句不一樣。通用的就是建立索引，查詢時盡量有索引。少用in.2...
儲存查詢條件的物件
1 2 3 宣告 儲存查詢條件的物件 4 5 var tabindex window.parent.ctab.tabs gettabindex window.parent.ctab.tabs getselected 獲取當前頁籤的序號 6 var tabtitle window.parent.cta...