我们只涉及ELK协议栈可以做的事情的表面。ElasticSearch是一个非常强大的数据库，可以轻松扩展并存储大量数据。LogStash提供了几乎无限的可能性，允许我们将任何数据源用作输入（在我们的例子中是syslog），将其转换为我们认为有用的任何形式，并输出到许多不同的目的地中（在我们的例子中为ElasticSearch）。当有需要时，你可以使用Kibana来查看系统生成的日志。最后，LogSpout让这一切成为可能，它能确保集群中运行的任何容器产生的所有日志都被收集并发送给LogStash。
本章的目标是探索处理大量日志的潜在解决方案，并让你了解如何从Swarm集群内运行的服务中收集日志。你知道了关于logging的一切吗？可能没有。不过，我希望你有一个很好的基础来更进一步地探讨这个主题。
即使你选择使用不同的工具，这个过程仍然是一样的。使用工具从你的服务中收集日志，将它们发送到某个数据库，并在需要时使用UI来浏览它们。
现在有了只提供部分信息的日志，我们需要找到问题的原因。日志通常是不够的。我们需要来自系统的指标，也许服务使用的内存比集群提供的要多，也许系统响应的时间太久，或者服务中可能有内存泄漏，这些东西很难通过日志找到。(www.xing528.com)
我们不仅需要了解系统的当前指标，还需要了解它过去的表现。即使我们有这些指标，也需要一个能够在发生问题时通知我们的进程。查看日志和指标虽然可以给我们提供用来调试问题的大量信息，但首先我们需要知道问题的存在。我们需要一个进程，当出现问题或者在实际问题发生之前通知我们。即使有了这样的系统，也应该更进一步，尽量防患于未然。这种预防通常可以自动化，毕竟，当其中一些问题可以由系统自动修复时，为什么还要手动修复所有问题？最终目标是建立一个自我修复系统，只有当意外事件发生时，才需要人工干预。
我们面前的度量标准、通知、自我修复系统和其他待处理任务的内容对于一个章节来说太多了，所以我们一步一步做。目前，我们已经完成了日志部分，接下来将讨论收集指标的不同方法，并使用它们来监控集群以及在其中运行的服务。
一如既往，我们将以销毁结束本章：
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
