在我们的项目中，我们使用 ELK 堆栈将日志存储在一个集中的位置。但是我注意到最近版本的 ElasticSearch 支持各种聚合。此外，Kibana 4 支持很好的图形方式来构建图表。即使是最新版本的 grafana 现在也可以使用 Elastic Search 2 数据源。
那么，这一切是否意味着 ELK 堆栈现在可以用于存储系统内部收集的计量信息，或者它仍然不能被视为现有解决方案的重要竞争对手：石墨、流入数据库等。如果是这样，是否有人在生产中使用 ELK 进行计量？你能分享你的经验吗？
只是为了澄清这些概念，我认为计量数据可以聚合并显示在“随时间”的图表中，而不是主要用例正在搜索的常规日志消息。
非常感谢提前
是的，您可以使用Elasticsearch来存储和分析时间序列数据。
更准确地说，这取决于您的用例。例如，在我的用例中（金融工具价格变动历史数据，正在开发中）我能够每秒插入 40.000 个文档（约 125 个字节的文档，每个文档有 11 个字段 - 1 个时间戳、字符串和小数，这意味着5MB/s 的有用数据）每天 14 小时，在由企业 SAN（由旋转磁盘支持，而不是 SSD！）支持的单个节点（具有 192GB 内存的大型现代服务器）上。我去存储多达1TB 的数据，但我预测 2-4TB 也可以在单个节点上工作。
所有这些都是默认配置文件设置，除了 30GB 的 ES_HEAP_SIZE。我怀疑通过一些调整可以在该硬件上获得显着更好的写入性能（例如，我觉得奇怪的是 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有助于处理多个索引，并且是普遍推荐的最佳实践。