微服务运维实战：优化日志策略，集中记录与监控实践

Defining Logging Strategy

今天的大多数软件都非常像埃及的金字塔，数百万块砖头堆在一起，没有完整的结构，只是由蛮力和成千上万个奴隶来完成。

——阿兰·凯

我们已经达到拥有完全运行的Swarm集群和定义好的持续部署流水线的水平，该流水线将在每次提交时更新我们的服务。现在可以花时间编写代码并将其推送到代码仓库，因为该过程的其余部分都是自动化的。最后可以把时间花在为我们工作的组织带来真正价值的任务上。我们可以投入时间为正在开发的服务提供新功能。然而，当出现问题时，就需要停止打磨新功能并去排查问题。

当发现问题时，我们倾向于做的第一件事就是检查日志。日志绝不是用于调试问题的唯一数据源，我们还需要很多指标（第10章将详细介绍）。但是，即使日志不是关注的唯一内容，它们通常也是一个良好的开端。

给《微服务运维实战（第一卷）》读者的说明

下面的内容与《微服务运维实战（第一卷）》中的内容相同。如果你对这些内容仍然印象深刻，请自由跳到Setting up LogStash and ElasticSearch作为日志记录数据库（#logging-es）的子章节。在我编写完2.0以来，我发现了一些更好的方法来处理日志，特别是在Swarm集群中。(www.xing528.com)

对DevOps实践和工具的探索引导，我们进行集群和扩展。因此，我们开发了一个系统，允许以一种简单而有效的方式将服务部署到集群。结果可能是在由许多服务器组成的集群上运行容器的数量不断增加。

监控一台服务器很容易，在单台服务器上监控许多服务会有一些困难。在许多台服务器上监控许多服务需要全新的思维方式和一套新的工具。当你开始拥抱微服务、容器和集群时，创建的服务及其实例的数量将开始急剧增加，构成集群的服务器也是如此。现在不能再登录节点上去查看日志，要看的话实在太多了。最重要的是，它们分布在许多台服务器中。前一天我们只在一台服务器上部署了两个服务实例，但明天可能会把八个实例部署到六台服务器上。

我们需要有关系统的历史和（近）实时信息，这些信息可以是日志、硬件利用率、健康检查、网络流量和其他内容的形式。存储历史数据的需求并不新鲜，并且已经被使用了很长时间。但是，信息传播的方向会随着时间的变化而变化。过去大多数解决方案都是基于集中式数据采集器，但现在由于服务和服务器都是非常动态的，所以我们倾向于将数据收集器分散化。

集群日志和监控所要做的就是，分散的数据采集器将信息发送到集中的解析服务和数据存储。有很多专门为这一需求而设计的产品，从本地部署到云解决方案，以及介于二者之间的产品。可以使用许多解决方案，如FluentD（http：//www.fluentd.org/）、Loggly（https：//www.loggly．com/）、GrayLog（https：//www.graylog.org/）、Splunk（http：//www.splunk．com/）和DataDog（https：//www.datadoghq．com/）。我通过选择ELK协议栈（ElasticSearch（https：//www.elastic.co/products/ elasticsearch）、LogStash（https：// ww w.elastic.co/products/logstash）和Kibana（https：//www.elastic.co/products/kib ana））向你展示这些概念，它的优势在于免费、文档充分、高效且使用广泛。ElasticSearch（https：//www.elastic.co/products/ elasticsearch）是实时搜索和分析的最佳数据库，它是分布式的、可扩展的、高可用的并提供了复杂的API。LogStash（https：//www.elastic.co/products/logstash）允许我们集中处理数据，它可以很容易扩展到自定义数据格式，并提供大量的可以满足几乎任何需求的插件。Kibana（https：//www.elastic.co/products/kibana）是一个分析和可视化平台，有直观的界面，位于ElasticSearch之上。

我们使用ELK协议栈并不意味着它是最好的解决方案。这都取决于具体用例和特定需求。我会介绍使用ELK协议栈进行集中式日志记录和监控的原理。一旦理解了这些原理，就可以在选择其他栈的时候运用这些原理。

我们切换了讨论问题的顺序，在讨论集中日志的需求之前先选择了工具，下面补救一下。