在这最后一章中，我们将讨论向您的监控添加警报的好处，从而了解您可以采取哪些后续步骤来监控您的容器。此外，我们将介绍一些不同的场景，以及哪种类型的监控适合每种场景:
- 常见问题(性能、可用性等)以及哪种类型的监控最适合您的情况。
- 就您收集的指标发出警报有什么好处，有哪些选择？
为了了解您可能希望为基于容器的应用实现哪种类型的监控，我们应该研究几个不同的示例配置，基于容器的应用可以部署到这些配置中。首先，让我们提醒自己关于宠物、牛、鸡和雪花。
回到第 1 章Docker 监控介绍，我们谈到了宠物、牛、鸡和雪花；在那一章中，我们描述了每个术语在应用于现代云部署时的含义。在这里，我们将更详细地讨论如何将这些术语应用于您的容器。
对于被视为宠物的容器，您将比在指定主机上运行单个或少量固定容器的可能性更大。
这些容器中的每一个都可以被认为是单点故障；如果其中任何一个发生故障，都很可能导致应用出错。更糟糕的是，如果主机因为任何原因停机，您的整个应用都将离线。
对于我们使用 Docker 的大多数第一步，这是一种典型的部署方法，无论如何都不应该被认为是不好的、不被认可的或不被推荐的；只要你意识到的局限性，你就会没事。
这种模式也可以用来描述大多数开发环境，因为您会根据需要不断检查它的运行状况和调整。
您很可能将机器托管在本地计算机或托管服务上，如数字海洋(https://www.digitalocean.com/)。
对于大部分生产或业务关键型部署，您的目标应该是启动您的容器，其配置允许它们在故障后自动恢复，或者，当需要更多容量时，启动额外的容器，然后在扩展事件结束时终止。
您很可能会使用基于公共云的服务，如下所示:
- 亚马逊 EC2 容器服务:https://aws.amazon.com/ecs/
- 谷歌容器引擎:https://cloud.google.com/container-engine/
- joyentTriton:https://www . joyent . com/blog/understance-Triton-containers/
或者，您将在自己的服务器上使用 Docker 友好和集群感知的操作系统进行托管，如下所示:
只要您可以将流量路由到容器，您就不会太在意容器在主机集群中的启动位置。为了向群集添加更多容量，您将在需要时启动其他主机，并在不需要时从群集中删除它们，以节省成本。
不仅仅是你可能会使用容器来启动，处理数据，然后终止。这可以在任何时候发生，从一天一次到一分钟几次。您将使用分布式计划程序，如下所示:
- kubrines 由谷歌:t1【http://kubrines . io/发布
- 阿帕奇 月份： http://mesos.apache.org/
因此，您的集群中将有大量的容器启动和终止；只要您的数据被正确处理并传递回您的应用，您肯定不会关心容器在哪里启动，甚至不会关心流量如何路由到它。
像黄牛部分描述的集群一样，主机将自动添加和删除，可能是为了响应计划的高峰，如月末报告或季节性销售等。
我希望你从第一章中带走的一件事是，如果你有任何服务器或服务，你认为是雪花，那么你应该做些什么来尽快淘汰它们。
幸运的是，由于应用容器化的工作方式，您应该永远无法使用 Docker 创建雪花，因为您的容器化环境应该总是可复制的，要么是因为您有 Docker 文件(每个人都做备份，对吗？)或者您有一个容器映像的工作副本，因为您已经使用内置工具将容器作为一个整体导出。
有时可能无法使用 Docker 文件创建容器。相反，您可以使用 export 命令备份或迁移容器。有关导出容器的更多信息，请参见以下网址:
https://docs.docker.com/reference/commandline/export/
如果你发现自己处于这种境地，让我第一个祝贺你，在任何问题出现之前，通过将你的雪花提升为宠物甚至牛来减轻未来的灾难。
还在跑雪花？
如果您发现自己仍在运行雪花服务器或服务，我再怎么强调也不为过，您应该考虑尽快记录、迁移或更新雪花。监控一个你可能无法恢复的服务是没有意义的。请记住如果你真的需要运行旧技术，有一些容器，比如 PHP4。
您正在使用 Docker Hub 的官方容器运行个人 WordPress 网站；容器已经使用 Docker Compose 文件启动，就像我们在本书中多次使用的文件一样。
您将 Docker Compose 文件存储在 GitHub 存储库中，并且可以拍摄主机的快照作为备份。因为这是您自己的博客，所以您可以在单个基于云的主机上运行它。
合适的监控如下:
- Docker 统计
- Docker 顶
- Docker 日志
- 顾问
- 西斯迪格
由于您运行的是作为备份的单个主机，因此您并不真正需要将日志文件运送到中央位置，因为主机的可能性很小；像容器一样，它的主机将在线几个月甚至几年。
您不太可能需要深入挖掘容器的历史性能统计数据，因为大多数调优和故障排除都是在出现问题时实时完成的。
使用建议的监控工具，您将能够实时了解容器内发生的情况，并获得关于消耗过多内存和 CPU 的进程的足够信息，以及来自容器内的任何错误消息。
您可能希望启用一个服务，如 Pingdom(https://www.pingdom.com/)或正常运行机器人(http://uptimerobot.com/)。这些服务每隔几分钟轮询您的网站，以确保您配置它们的网址，检查它是否在特定时间内加载或根本不加载。如果他们检测到页面加载的任何减速或失败，他们可以配置为发送初始警报，通知您存在潜在问题，例如提到的两个服务都有免费层。
您正在运行一个定制的电子商务应用，该应用需要高度可用，并且在您的高峰期也可以扩展。您正在使用公共云服务及其附带的工具集来启动容器并将流量路由到它们。
合适的监控如下:
- 卡迪西亚+普罗米修斯
- 扎比克斯
- Sysdig Cloud
- 新遗迹服务器监控
- Datadog
- ELK +日志包
- 日志条目
- 冷淡地
在这种情况下，企业不仅需要收到有关容器和主机故障的通知，还需要将您的监控数据和日志远离主机服务器，以便您可以正确地查看历史信息。您可能还需要将 PCI 合规性或内部审计的日志保留一段固定的时间。
根据您的预算，您可以通过在基础架构的某个地方托管自己的监控(Zabbix 和 Prometheus)和中央日志(ELK)栈来实现这一点。
您还可以选择运行一些不同的第三方工具，例如将监控性能的工具(例如 Sysdig Cloud 或 Datadog)与中央日志服务(例如 Log Entries 或 Loggly)相结合。
如果合适，您还可以运行自托管和第三方工具的组合。
虽然自托管选项似乎是最节省预算的选项，但需要考虑以下一些因素:
- 您的监控需要远离您的应用。将您的监控安装在与应用相同的主机上是没有意义的；如果主机出现故障，什么会提醒您？
- 您的监控需要高度可用；你有这样做的基础设施吗？如果您的应用需要高可用性，那么您的监控也需要高可用性。
- 你需要有足够的能力。您是否有能力存储一个月、六个月或一年前的日志文件和指标？
如果您将不得不投资于上述任何一个选项，那么在投资基础架构和管理您自己的监控解决方案的成本与使用提供上述选项即服务的第三方之间进行权衡是值得的。
如果您使用的是纯容器操作系统，如 CoreOS 或 RancherOS，那么您需要选择一个其代理或收集器可以从容器中执行的服务，因为您将无法直接在操作系统上安装代理二进制文件。
您还需要确保您的主机配置为在启动时启动代理/收集器。这将确保一旦主机加入集群(通常是当容器开始在主机上弹出时)，它就已经在向您选择的监控服务发送指标。
每次从前端应用调用 API 时，应用都会启动一个容器；容器从数据库中获取用户输入，对其进行处理，然后将结果传递回前端应用。一旦数据被成功处理，容器就被终止。您正在使用分布式调度系统来启动容器。
合适的监控如下:
- 扎比克斯
- Sysdig Cloud
- Datadog
- ELK +日志包
- 日志条目
- 冷淡地
在这种情况下，您很可能不想监视诸如中央处理器和内存利用率之类的事情。毕竟，这些容器应该只存在几分钟，而且您的调度程序会在主机上启动容器，主机上有足够的容量来执行任务。
相反，您可能希望保留一条记录来验证容器是否按预期启动和终止。您还需要确保在容器处于活动状态时记录容器中的STDOUT和STDERR，因为一旦容器被终止，您将无法取回这些消息。
使用前面列出的工具，您应该能够构建一些非常有用的查询来详细了解短期流程的执行情况。
例如，您将能够获得容器的平均寿命，因为您知道容器启动的时间和终止的时间；知道了这一点，你就可以设置一个触发器来提醒你是否有任何容器存在的时间超过了你的预期。
我们在本书中看到的许多工具至少提供了一些基本的警报功能；百万美元的问题是你应该启用它吗？
这在很大程度上取决于您正在运行的应用的类型以及容器是如何部署的。正如我们在本章中已经多次提到的，您永远不应该真正拥有雪花容器；这给我们留下了宠物、牛和鸡。
如前一节所述，您可能不需要担心在配置为运行小鸡的集群上获得内存、中央处理器和硬盘性能的警报。
你的容器不应该长到经历任何真正的问题；但是，如果出现任何意外的峰值，您的调度程序可能会有足够的智能将您的容器分发到当时拥有最多可用资源的主机。
您需要知道是否有任何容器的运行时间超过了您的预期；例如，通常不超过 60 秒的容器中的进程在 5 分钟后仍在运行。
这不仅意味着存在潜在的问题，还意味着您发现自己运行的主机只包含陈旧的容器。
当设置牛或宠物的提醒时，你有几个选项。
您将更希望收到基于主机和容器的 CPU 和 RAM 利用率的警报，因为这可能表明潜在的问题，可能会导致应用速度变慢并导致业务损失。
如前所述，如果您的应用开始提供意想不到的内容，您可能还希望得到提醒。例如，一个主机和一个容器会很高兴地坐在那里处理一个应用错误。
您可以使用 Pingdom、Zabbix 或 New Relic 等服务加载页面并检查页脚中的内容；如果此内容缺失，则可以发送警报。
根据您的基础架构的流动性，在黄牛配置中，您可能希望在容器上下旋转时收到警报，因为这将指示高流量/事务的时段。
发送警报因工具而异，例如，当容器的 CPU 负载超过 5、或主机负载超过 10 时，警报可以简单到发送电子邮件通知您在网络运营中心 ( NOC )发出声音警报有问题。
对于那些需要一个随叫随到的团队来获得警报的人来说，我们所介绍的大多数软件都有某种级别的集成警报聚合服务，例如寻呼机职责(https://www.pagerduty.com)。
这些聚合服务要么拦截您的警报电子邮件，要么允许服务对其进行 API 调用。当被触发时，它们可以被配置为拨打电话、发送短信，如果在可定义的时间内没有标记警报，甚至可以升级为二级呼叫技术人员。
我想不出有什么情况你不应该考虑启用警报，毕竟，在你的最终用户之前知道任何可能影响你的应用的事情总是最好的。
您启用了多少警报实际上取决于您使用容器的目的；但是，我建议您定期查看所有警报，并积极调整您的配置。
您最不希望看到的是产生太多误报的配置或过于焦虑的配置，因为您不希望收到您的警报的团队对您正在生成的警报变得不敏感。
例如，如果因为计划的作业而每 30 分钟触发一次关键的 CPU 警报，那么您可能需要检查警报的敏感性，否则工程师很容易不加思考就简单地取消关键警报，因为“此警报每半小时出现一次，几分钟后就会恢复正常”，而此时您的整个应用可能没有响应。
虽然 Docker 是建立在成熟的技术之上的，比如 Linux 容器 ( LXC ，但是这些传统上很难配置和管理，尤其是非系统管理员。
Docker 消除了几乎所有的进入障碍，允许每个有少量命令行经验的人启动和管理他们自己的基于容器的应用。
这迫使许多支持工具也降低了进入门槛。曾经需要仔细规划部署的软件，如我们在本书中介绍的一些监控工具，现在可以在几分钟内部署和配置，而不是几个小时。
Docker 也是一项移动非常快的技术；虽然它已经被认为可以生产了，但新的功能正在被添加，现有的功能通过定期更新得到了改进。
截至目前，2015 年，Docker Engine 已经发布了 11 个版本；其中，只有 6 个是修复 bug 的小更新，其余都是大更新。每个版本的详细信息可以在项目的变更日志中找到，该日志可以在https://github.com/docker/docker/blob/master/CHANGELOG.md找到。
由于 Docker 的发展速度，您还需要更新您部署的任何监控工具，这一点非常重要。这不仅是为了跟上新功能，也是为了确保您不会因为 Docker 工作方式的变化而丢失任何功能。
这种更新监控客户端/工具的态度对于一些管理员来说可能有点改变，他们过去可能会在服务器上配置监控代理，然后不再考虑它。
正如本章所讨论的，Docker 是一种快速移动的技术。这本书在制作的同时，从 1.7 到 1.9 已经发布了三个主要版本；随着每个版本的发布，Docker 变得更加稳定和强大。
在这一章中，我们研究了实现本书前几章中讨论的技术的不同方法。到目前为止，您应该已经知道了对于您的应用和使用 Docker 部署应用的方式，哪种方法适合监控您的容器和主机。
无论您选择哪种方法，重要的是您要及时了解 Docker 的发展以及新出现的监控技术，以下链接是让您随时了解情况的良好起点:
- Docker 工程博客:http://blog.docker.com/category/engineering/
- 推特上的 docker:https://twitter.com/docker
- Reddit 上的 docker:https://www.reddit.com/r/docker
- 栈溢出的记录者:http://stackoverflow.com/questions/tagged/docker
Docker 项目受到开发人员、系统管理员甚至企业公司欢迎的原因之一是，它能够快速移动，同时添加更多功能，并非常令人印象深刻地保持其易用性和灵活性。
在接下来的 12 个月里，这项技术将会更加普及；确保您从容器中捕获有用的性能指标和日志的重要性将变得更加关键，我希望这本书能帮助您开始监控 Docker 的旅程。