在我们的项目中，我们使用ELK堆栈将日志存储在集中位置。但是，我注意到，ElasticSearch的最新版本支持各种聚合。此外，Kibana 4支持不错的图形方式来构建图形。现在，即使是最新版本的grafana也可以与Elastic Search 2数据源一起使用。
因此，这是否意味着ELK堆栈现在可以用于存储系统内部收集的计量信息，还是不能认为它是现有解决方案（石墨，流入db等）的重要竞争对手。如果是这样，是否有人在生产中使用ELK进行计量？您能否分享您的经验？
只是为了澄清概念，我将计量数据视为可以汇总的数据，并在“随时间推移”图中显示，而不是在主要用例正在搜索的常规日志消息中显示。
在此先多谢
是的，您可以使用 Elasticsearch 来存储和分析 时间序列 数据。
更准确地说- 这取决于您的用例* 。对于 例如 在 我的使用情况下 （金融工具价格剔历史数据， 在发展中 ）我能够得到 40.000文件插入/秒 （ 〜125页字节的文件 各有11场- 1个时间戳，字符串和小数，这意味着 5MB / S的有用数据 ） 每天14小时 ，在由公司SAN（ 由旋转磁盘 而不是SSD进行 备份 ）支持的 单个节点 （具有192GB ram的大型现代服务器）上。我去存储了多达 1TB的数据 ，但是我预测拥有2-4TB 的数据 也可以在单个节点上工作。 ***
所有这些都是 默认的配置文件设置 ，但ES_HEAP_SIZE为30GB。我怀疑通过一些调整可以在该硬件上获得显着更好的写入性能（例如，我发现iostat将设备使用率报告为25％至30％很奇怪，好像Elastic正在对其进行限制/保留I / O带宽以进行读取）或合并…，但也可能是％util是SAN设备的不可靠指标。
查询性能也很好-只要您使用时间和/或其他字段限制结果数据集，查询/ Kibana图就可以快速返回。
在这种情况下，您将 不会使用Logstash加载数据 ，而是 将大批量的大批量插入 直接插入到Elasticsearch中。https://www.elastic.co/guide/zh- CN/elasticsearch/reference/current/docs- bulk.html
您还需要 定义一个映射 https://www.elastic.co/guide/zh- CN/elasticsearch/reference/current/mapping.html，以确保Elastic可以根据需要解析数据（数字，日期等）。创建所需的索引级别等。
用于该用途的情况下，其他推荐的做法是 使用一个单独的索引的每一天 （或月/周取决于你插入率），并确保 指数与创建 刚好 足够的碎片保持1天的数据中（默认情况下，新的索引如果使用5个分片创建分片，并且分片增长到一定大小（通常为几十GB，但是对于您的用例可能有所不同，则需要进行测量/实验），分片的性能就会开始下降。
使用Elasticsearch 别名 https://www.elastic.co/guide/zh- CN/elasticsearch/reference/current/indices- aliases.html有助于处理多个索引，并且是通常推荐的最佳实践。
