日誌
作爲一個java開發，我在自己熟悉的範圍內聊一下自己對日誌的理解以及實踐。日誌的作用：顧名思義就是記錄程序的運行軌跡，記錄可能需要用跟蹤、排查的點的信息，或者作爲另一種數據存儲，用來做報表統計之用（比如訂單打單量、慢sql等）。
日誌記錄的載體可以是多種多樣的：數據庫、普通文件、索引引擎等。小應用時記錄在當前項目所在的磁盤即可，但是項目分模塊、跨服務器時，日誌的分散將造成問題排查、數據統計的困難，怎麼辦？這個時候日誌就需要統一收集。
我現在所做的應用便是這樣的情況，所以對日誌做了統一的收集。通過java界內廣泛應用的log4j，實現一個我們自己的appender，將需要的數據異步通過http請求發送給elastic。這個elastic便是一種索引管理引擎，能夠分佈式保存索引，並提供便捷、高性能的搜索支持。在展現時則通過kibana、grafana等視圖，前者偏向於日誌內容搜索，後者偏向於日誌內容統計。
在跨服務器、跨應用時還會碰到一個問題，就是同一個請求或任務鏈路的日誌怎麼串起來，我們現在的做法，是在請求或者任務之初產生一個id(cluId),在後面的任務、請求傳遞過程中一直保持這個id，在寫日誌的時候把這個id也寫入，解決了這個問題。
問題3，當日志請求非常多，來不及寫時怎麼處理？我們的做法是應用裏維護一個隊列，將數據維護在leveldb中，在發送出去後再進行清理，這爲日誌推送提供了流量控制以及容錯支持。
問題4，如果要對現有的日誌數據進行加工，以便於統計分析，這個怎麼做？我們把問題3的方案改造一下，應用不直接請求elastic，而是請求一個我們提供的服務，在我們提供的服務裏對日誌信息進行修改，再請求elastic，這就實現了對日誌處理的切面抽取；可以統一進行管理。
實踐細節
elastic：
版本是2.4.1，使用了4個實例，部署成集羣
採用手動指定master的方式：node.master:true
寫日誌時的文件名加上日誌後綴-yyyy-MM-dd,方便運維
我本地實驗採用的配置：
discovery.zen.minimum_master_nodes:2 服務器要配置5
gateway.recover_after_nodes:1 在整個集羣重啓後，只有n個節點啓動後才進行初始化恢復
node.max_local_storage_nodes:1 一個服務不允許起多個實例
action.destructive_requires_name:true