用於存儲計量數據的ELK堆棧

在我們的項目中，我們使用ELK堆棧將日誌存儲在一個集中的地方。不過，我注意到最近版本的ElasticSearch支持各種聚合。另外Kibana 4支持很好的圖形方式來構建圖形。即使最新版本的Grafana現在也可以使用Elastic Search 2數據源。用於存儲計量數據的ELK堆棧

因此，這是否意味着ELK堆棧現在可以用於存儲系統內部收集的計量信息，或者仍然不能被視爲現有解決方案的嚴重競爭對手：石墨，influx db等等。如果是這樣，有沒有人使用ELK進行生產計量？你能分享你的經驗嗎？

爲了澄清這些概念，我將計量數據視爲可以聚合的東西，並且在圖表中顯示「隨着時間的推移」，而不是主要用例搜索的常規日誌消息。

感謝很多提前

來源

2016-05-09 Mark Bramnik

當然，你可以使用這種方式。這就是Kibana的目的：隨着時間的推移顯示彙總的數據。此外，請注意Kibana現在帶有一個名爲Timelion的插件，這是一種更簡單的方法（單線程）爲時間序列創建圖形：https://www.elastic.co/blog/timelion-timeline –

非常感謝，避風港聽說過插件 - 看起來很棒！ –

是的，你可以使用Elasticsearch存儲和分析時間序列數據。

更確切地說 - 這取決於您的使用案例。對於例如在我的使用情況（金融工具價格剔歷史數據，發展）我能得到插入/秒40.000文件（〜125字節的文件各有11場 - 1個時間戳，字符串和小數，這意味着有用的數據）爲14小時/天的5MB/S，A 單個節點上（大現代服務器具有192GB RAM）的企業SAN的支持（這是通過旋轉磁盤支持，不是SSD！）。我去存儲高達1TB的數據，但我預測有2-4TB也可以在單個節點上工作。

所有這些都與默認配置文件設置，除了ES_HEAP_SIZE 30GB。我懷疑它有可能通過一些調整在硬件上獲得明顯更好的寫入性能（例如，我發現iostat報告器件利用率爲25-30％，就好像Elastic是封頂它/保留I/O帶寬讀取或合併...但它也可能是％util是SAN設備的一個不可實現的度量標準。）

查詢性能也很好 - 只要您用時間限制結果數據集，查詢/ Kibana圖形就會快速返回和/或其他領域。

在這種情況下，你會不使用Logstash加載數據，但大批量直接進入Elasticsearch的批量插入。 https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-bulk.html

您還需要定義的映射https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping.html確保彈性，只要你想它分析你的數據（數字，日期等）創建索引的通緝級別等。這個用例

其他推薦的做法是使用一個單獨的索引每個天（或每月取決於您的插入率/周），並確保指數與只是足夠的碎片容納創建1天的數據（默認情況下，使用5個分片創建新索引，分片的性能在分片增長超過一定大小後開始降低 - 通常爲幾十GB，但對於您的用例可能會有所不同 - 您需要測量/實驗）。

使用Elasticsearch 別名https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-aliases.html幫助處理多個索引，並且是一般推薦的最佳實踐。

來源

2016-05-10 09:05:26

非常感謝您通過實際數字獲得的寶貴答案。 –

用於存儲計量數據的ELK堆棧

回答

相關問題