如何選擇合適的工具取決於你正在做的事情。
應用程序是會表達的，而時序數據就是它們的語言之一。DevOps，雲計算和容器技術改變了我們編寫和運行應用的方式。基於一些列開源項目，InfluxData 及其社區正在致力於提供一套現代化且靈活的監控工具包。
在過去的十年中，容器，虛擬機，雲計算改變了一切。這些變化發生快速，我們需要能夠應對這種變化速度的環境，應用程序也需要以一種更便於維護的方式繼續演進。因此，我們需要理解應用的行為，準備好應對故障，進而改進應用。現在我們已經擁有了相應的工具和技術，只需要將它們集成起來去理解應用如何運行，基礎設施如何演進，並最終理解系統故障進而提升性能。
監控日誌
我們一直在讀日誌，也有一些工具能幫助我們理解應用行為。我們做這些是因為：
我們必須信任某些東西。光靠屏幕上的信息，我們是沒法理解應用行為的。我們需要知道用戶如何使用應用，出現了多少異常。可以跟蹤的指標有很多，把它們結合起來才能在我們的系統中建立信任。
我們希望能預測未來。 我們希望將預測建立在我們識別出的各類指標和行為上，這樣就能夠判斷我們自身是否在成長，有多少成長，在未來還能夠成長多快。有了這些信息，我們可以設計一個方案，或許還能預測一些不太好的事件。
日誌樣例
系統監控組使用一個叫“tail”的強大命令來讀日誌。通常，我們的應用通過這種方式表達。至於日誌，有一個基礎或者說正常狀態。如果日誌在正常狀態下持續輸出，那麼沒問題。如果日誌輸出地過快或者過慢，那麼就有問題了，需要採取糾正措施。
日誌並不是理解應用最聰明的方式，但卻是最常見的，人人都在用這種方式監控應用。我們現在肯定可以做的更好，不過這個涉及到日誌的特性。
日誌是描述性的，包含大量信息。將它們保存在數據庫中的代價太大。由於日誌通常是純文本格式，它們並不容易索引。這意味著引擎必須努力去理解日誌間的關係並且支持搜索信息。如果你有很多日誌，或者正在用日誌記錄應用中發生的一切，你需要一個很好的系統來支持。這很難，但也不是不可能。
有很多工具和服務能夠將日誌結合並且計算出正在發生的事件，比如 Logstash，Kibana，Elasticsearch，NewRelic，CloudWatch，Graphite 等等。它們中有些是以服務形式提供，有些是開源項目，有些兩種形式兼有。關鍵一點是有很多的選擇。
選擇日誌監控工具
如何選擇合適的工具取決於你正在做的事情。有一些場景你需要日誌來與人辯論或者僅僅用於存檔。既然日誌包含正在發生的事件的詳細信息，你就可以將日誌用於這些場景。當出現一個異常時，你可以斷定它的類型。日誌更多是用來獲取這樣的信息的。
然而，在一些其他的場景中，你僅僅想知道應用是如何運行的，比如說日誌是變多了還是變少了，異常在時間上又是如何分佈的。你並不需要知道究竟發生了什麼事，它們為什麼發生 -- 你只需要知道應用在行為上有改變就行了。另一方面，你每天同時也在使用時序數據來幫助理解系統行為。時序數據並沒有日誌那麼詳細 -- 它們是另一種語言。比如說，CPU、內存的使用率就是時序數據。
你不能僅僅使用時序數據而不使用日誌，因為有些問題必須藉助日誌才能解決。我並不是要在這裡辯論日誌和時序數據誰更好，因為你很可能兩種都需要，它們都有價值。不僅僅兩種你都需要，實際上日誌就是時序數據的一種形式。如果你用時間序列和值來簡化日誌，我們可以做一些計算，日誌也會更容易索引。
你實際上是在將日誌轉換成時序數據。想象一下你的應用中有多少登錄，多少異常，或者如果你是一家金融公司，有多少筆交易，這些都是時序數據，因為它們是時間點上的一個值，一次登錄。它們是時間上的一個分佈。這就是時序數據的含義。日誌就是可以這樣被轉換的。這不是一個整數或者一個值，而是從不同角度看的一個日誌。
簡單說，你可以將日誌簡化為僅僅一個值以及對應的時間點，你可以將這些時間點進行聚合，比較等等。如果花 10 分鐘思考一下你的應用，你能拿到很多時序數據。
另外，所有你能從服務器獲得並且使用的資源都是時序數據。你可以使用應用數據統計來可視化它們，進而理解突增的異常率是怎樣導致內存使用率上升的。
作為開發者，我們知道，5 年前我們做的所有事情如今會顯得很複雜。我們現在的目標是將事情簡化。簡單的事情更容易解釋給別人也容易維護。對於時序數據，我就是這樣做的：一個值和一個時間，值是一個數字。有了這種模型，你可以做一些計算，聚合它們，創建一個圖表，用代價不那麼高昂的方式從應用中提取信息。然而，與 Cassandra，MySQL，MongoDB 這些傳統的通用工具相比，InfluxDB 更適合用來處理這類數據，因為它專門為持續查詢，保留策略等特定場景提供了功能特性，而不是一套序列和壓縮的優化特性。
使用 InfluxDB 作為日誌存儲
InfluxDB 是一個時序數據庫。你可以將應用或服務器產生的所有信息推送到這個數據庫。它是一個在 Windows 和 Mac 上都可以下載的 Go 二進制文件，很容易安裝和啟動。InfluxDB 使用 InfluxQL 表達。這意味著你可以使用與 SQL 很相似的語言來查詢這個數據庫，而 SQL 你已經很熟悉了，不需要學習另一個新語言。這裡是選擇 InfluxDB 的一些理由的總結。
容易上手
熟悉的查詢語法
無外部依賴
開源
水平可擴展
一套結合緊密的時序數據平臺的成員
InfluxDB 擁有很大的用戶群和社區。結合以下討論的 InfluxData 平臺的其他組件，InfluxDB 創建了一個全棧監控系統，同時支持非常規時序數據（非固定時間間隔發生的事件）和常規時序數據（固定時間間隔的事件指標），如下。
在 InfluxData，我們做了一系列基準測試來展示為什麼你需要選擇合適的時序數據庫而不是你喜歡的那類數據庫。InfluxDB 和其他可對比的數據庫間的寫性能差異很大。基準測試通常有傾向性，但是我們會通過獨立測試嘗試將它們變得更客觀。參考 InfluxDB 與 Elasticsearch, MongoDB，Cassandra 和 OpenTSDB 的對比基準測試。
搭建現代化監控系統
InfluxData 擁有一套全棧的開源項目 -- Telegraf (https://www.influxdata.com/time-series-platform/telegraf/)，InfluxDB (https://www.influxdata.com/time-series-platform/influxdb/) ，Chronograf (https://www.influxdata.com/time-series-platform/chronograf/) 和 Kapacitor (https://www.influxdata.com/time-series-platform/kapacitor/)。 它們在一起構成 TICK 棧。
構建監控或事件系統的完整棧
Telegraf 是服務端的一個指標採集和數據發送代理，它是一個可以下載和啟動的 Go 二進制文件，使用起來非常簡單。你可以在每個服務器上安裝一個 Telegraf，將它配置為從所在服務器上採集信息。Telegraf 對各類指標，事件，運行它所在的容器或系統的日誌，從第三方 API 拉取的指標甚至通過 StatsD 和 Kafka 消費者服務監聽到的指標都提供了集成。Telegraf 是插件化的，並提供輸入和輸出插件，輸出插件可以將指標發送至各類數據倉庫，服務，消息隊列，比如 InfluxDB，Graphite，OpenTSDB，Datadog，Librato，Kafka，MQTT，NSQ 等等。如果你已經有一個監控系統，並且正在尋找一個強大的採集器，你可以使用 Telegraf。
InfluxDB 是存儲引擎，可作為所有帶有大量時間戳數據使用場景的數據倉庫，包括 DevOps 監控，日誌數據，應用指標，物聯網（IoT）傳感器數據以及實時分析數據。所有來自 Telegraf 的指標都可以被髮送至 InfluxDB。InfluxDB 可以被配置為僅僅保留特定時長的數據，從系統中自動過期並刪除不再需要的數據，這樣可以節省機器的存儲空間。InfluxDB 還提供了一個類似 SQL 的查詢語言來進行數據交互。
Chronograf 是 InfluxData 平臺 TICK 棧的用戶接口組件，在 Chronograf 上可以看到所有存儲在 InfluxDB 的數據，這樣就能構建健壯的查詢和告警。Chronograf 使用簡單，包含一些模板和庫讓你能夠迅速構建帶有實時可視化數據的儀表盤。你也可以在 Chronograf 上管理 InfluxDB 和 Kapacitor。如果你不打算使用 Chronograf，還有其他實現 InfluxDB 輸出插件的項目，包括 Grafana。
Kapacitor 是 TICK 棧的本地實時流式數據處理引擎，可以被配置為基於監聽到的指標，對正在發生的事件提前採取措施。它可以同時處理來自 InfluxDB 的流式數據和批數據。Kapacitor 允許嵌入自定義邏輯或者用戶定義的函數來處理動態閾值告警，對指標進行模式匹配，計算概率統計異常，以及基於告警執行類似動態負載均衡的特定動作。你可以發送 Kapacitor 告警到兼容的 事件管理集成組件，包括 HipChat，OpsGenie，Alerta，Sensu，PagerDuty，Slack 等等。比如，Kapacitor 可以發送一條消息到 PagerDuty，如果夜裡發生了問題你可以被通知到，或者發送一條消息到 Slack。
啟動 InfluxDB 並運行整個 TICK 棧是相當簡單的。你可以運行二進制文件或者 Docker 容器，這樣一個監控系統就正常運轉了。但是一個監控系統真正的目標是當基礎設施出問題或者應用宕機時通知你。如果你的監控系統和服務器一起宕掉了，那麼它就沒有正常工作。所以你需要信任你的監控系統。你需要將它與應用以及基礎設施解耦，這樣你能 100% 確定當應用和服務器宕掉時監控系統仍然能正常工作。你需要知道這不是一個簡單的目標，也不僅僅意味著一些 Docker 運行命令。
閱讀更多 運維猿 的文章
