大多数情况下，日志消息会被写入文件中。这并不是说写入文件是存储日志的唯一方式，也不代表这是最有效的方式。然而，由于大多数团队都在以某种形式使用基于文件的日志，因此暂且认为你的情况也是如此。基于上面的假设，我们也确定了应该应对的第一件事。容器希望我们将日志发送到stdout和stderr，只有转发到标准输出的日志条目才能通过docker logs命令获取，而且设计用于处理容器日志的工具也希望如此。它们会假设条目没有写入文件，而是发送到了标准输出。即使不使用容器，我们相信stdout和stderr也是服务应该记录日志的地方，然而，这就是另外一回事了。现在，我们将专注于容器，并假设你把日志输出到stdout和stderr，如果没有，大多数日志库会允许你将日志记录目标更改为标准输出和标准错误。
大多数情况下，我们不关心日志中写的是什么。当一切运作良好时，不需要花费宝贵的时间浏览日志。日志并不是用来打发时间的小说，也不是用来增长知识的技术书籍，日志是在某些地方出错的时候用来提供有价值的信息。
情况似乎很简单。我们将信息写入日志中，大多数时候我们会忽略这些日志，当出现问题时，会立刻查询它们并找出问题的原因。至少，这正是许多人所希望的。现实远比这些更复杂。除了最简单的系统外，调试过程要复杂得多。应用程序和服务几乎总是相互关联的，通常不太容易知道是哪一个导致了问题。虽然问题表现在一个应用程序中，但调查原因往往表明是在另一个应用程序上。例如，服务可能未实例化。花时间读日志后，可能会发现原因在数据库中，该服务无法连接到它并且无法启动。知道了症状，但还不知道原因，我们需要切换到数据库日志来查找原因。用这个简单的例子，我们知道了只看一个地方的日志是不够的。
随着在集群上运行分布式服务，情况的复杂度呈指数级增长。哪个服务实例会发生故障？它运行在哪个服务器上？发起请求的上游服务是什么？罪魁祸首所在节点的内存和硬盘使用情况如何？正如你可能已经猜到的那样，要找到问题根源，查找、收集和过滤信息往往非常复杂。系统越大，难度就越大。即使是单体应用程序，事情也很容易失控。
如果采用微服务的方式，那么这些问题会成倍增加。除了最简单和最小的系统外，集中式日志都是必需的。相反，当出现问题时，许多人一开始从一台服务器跑到另一台服务器，从一个文件跳到另一个文件，就像一只无头鸡——没有方向地跑来跑去。我们倾向于接受日志给我们带来的混乱，并将其视为自己专业性的一部分。
在集中式日志中寻求什么呢？集中式日志带来的诸多好处中，最重要的有如下几点。
● 一种解析数据并近乎实时地将其发送到中心数据库的方法。(www.xing528.com)
● 数据库处理近乎实时数据查询和分析的能力。
● 通过过滤后的图表、看板等对数据进行可视化呈现。
我们已经选择了能够满足所有这些要求（甚至更多）的工具。ELK栈（ElasticSearch、LogStash和Kibana）可以做到这一切。正如我们探索过的所有其他工具一样，这个栈可以很容易扩展以满足我们设定的特殊需求。
现在我们对于想要完成的工作有一个模糊的概念，并且有工具可以完成它们，下面探讨一些可用的日志策略。我们将从最常用的场景开始，慢慢地转向采用更复杂也更有效的方式来定制日志策略。
废话不多说，现在我们创建用来集中式日志记录以及稍后用于监控的环境。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
