如何选择正确的数据库存储系统指标|微服务运维实战

在DevOps 2.0 Toolkit中，反对像Nagios（https：//www.nagios.org/）和Icinga（https：//www.icinga.org/）这样的“传统”监控工具。相反，对于日志和系统指标，选择使用Elasticsearch。在第9章中重申了使用Elasticsearch作为日志解决方案的选择。可以将其扩展到用于存储指标么？当然可以。应该这样做吗？应该将其作为存储系统指标的地方吗？有更好的解决方案吗？

如果用作存储系统指标的数据库，Elasticsearch最大的问题在于它不是时间序列类型的数据库。Elasticsearch能够以非结构化的方式进行自由文本搜索和存储数据，从而使得存储日志受益匪浅。但是，对于系统指标，我们可能会使用不同类型的数据存储，可能需要一个时间序列数据库。

时间序列数据库是围绕优化存储和检索时间序列数据的方式而设计的。它们的一个最大好处是以非常紧凑的格式存储信息，使其能够管理大量的数据。如果对基于时间数据的存储需求与其他类型的数据库（包括Elasticsearch）进行比较，就会发现时间序列数据库的效率更高。换句话说，如果数据是基于时间的指标，那么请使用专为这些数据设计的数据库。

大多数（如果不是全部的话）时间序列数据库的最大问题是分布式存储。通过副本来运行它们是不太可能的，或者说是一个挑战。说白了，这样的数据库被设计为只运行一个实例。幸运的是，通常不需要在这些数据库中存储长期数据，并且可以定期清理它们。一方面，如果长期存储是必须的，那么解决方案应该是将聚合的数据导出到其他类型的数据库，比如Elasticsearch中，特别是在涉及复制和分片的时候。但是，在你应得“疯狂”并开始导出数据之前，请确保你确实需要这样做。时间序列数据库可以轻松地在单个实例中存储大量信息。你不需要因为容量的原因去扩展它们。另一方面，如果数据库发生故障，Swarm就会重新安排它，并且只会丢失几秒钟的信息。这种情况不应该是一场灾难，因为我们处理的是聚合数据，而不是单条交易。(www.xing528.com)

InfluxDB（https：//www.influxdata．com/）是最重要的时间序列数据库之一，Prometheus（https：//prometheus.io/）是一种常用的替代方案。除了表明将使用后者外，我们将跳过这两种产品的比较。这两种解决方案都是监控解决方案的可靠选择，Prometheus具有我们不应忽视的潜在优势。社区计划将以Prometheus格式原生地公开Docker指标。撰写这篇文章的时候，还没有固定的日期，但我们会尽最大努力围绕该计划设计系统。如果你想亲自监控进度，则请查看Docker issue 27307（https：//github．com/docker/docker/issues/27307）。我们将以这样一种方式使用Prometheus，一旦Docker原生指标可用，就可以切换过去。

让我们开始行动并创建本章中使用的集群。