容器化和微服務，讓世界花枝招展，又支離破碎。一個典型的運行在容器雲之上的微服務架構的應用，一般是由多種服務和基礎設施的支撐而來的。這對運維工做提出一個很大的挑戰 —— 一個應用後端的衆多系統，到底是怎樣的工做情況？後端
事實上，全部構成這一應用的微服務以及支撐這一應用的全部基礎設施，都會有各自的日誌、指標數據，以及構建在上游的監控、日誌系統。各處分散的數據和系統，會給支持團隊形成極大的負擔，也最終成爲開發運維工做的攔路虎。服務器
以前的經驗中，能夠把自家應用的各類業務、技術指標經過 Zabbix 或者 influxDB 進行存儲，經由 Grafana 的插件系統進行整合展現，目前流行的容器雲支撐系統 Kubernetes，也可以經過 influxDB 在 Grafana 上展現 Heapster 蒐集到的數據。指標的事情解決了，下面天然就是日誌了。微信
Grafana 也提供了針對 Elasticsearch 的數據源插件。下面用 Kubernetes 中正在運行的日誌收集實例來展現 Grafana 對 ES 的支持。架構
創建數據源
首先是創建一個 Elasticsearch 類型的數據源。這裏使用了一個 Kubernetes 集羣的 ES 日誌。Type 部分選擇 Elasticsearch，而後填寫 URL 地址、認證方式。Index name 填寫 logstash-*。大體如圖所示。運維
點擊下面的 Test & Save，測試成功後完成數據源設置。微服務
Access 通常來講都是選擇 Proxy，也就是服務器間通訊。測試
創建指標
接下來進入展現環節。利用新建的 ES 數據源，來創建展現單元。spa
曲線圖
首先創建一個 Graph Panel，數據源選擇上面新建的 ES。.net
Query 一欄須要按照 Lucene 語法進行查詢。這裏咱們選擇 kubernetes.container_name: "jenkins"，也就是容器名稱爲 「jenkins」 的日誌項。插件
其餘能夠保持缺省便可。
配置結束以後，稍等幾秒鐘，就會出現數據點。
日誌表格
我的感受上面的的數字在日誌來講用處並不大，咱們的目的仍是在同一界面下查看日誌。
創建一個 Table Panel。配置數據源爲 ES。Metric 選擇 Raw Document。
通過短暫等候，上面表格會出現一堆的 JSON 文本，咱們要經過 Options 來進行展示配置。
在 Columns 中咱們簡單的新加兩列：」kubernetes.container_name」 和 「log」，就會以表格的形式把這兩列展現出來。
告一段落
至此，Grafana 就成爲一個集成了衆多來源的運維入口。通過進一步的加工和配置（其實很是大量很是瑣碎），僅從這一個入口就可以完成不少的平常巡檢任務；更重要的是，由於數據的統一展現，在業務、服務和基礎設施之間創建了直觀的聯繫，爲事故的處理甚至預測，提供了更多的便利條件。
本文分享自微信公衆號 - 僞架構師（fake-architect）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。