【DevOps基础篇】容器化架构基础设施监控方案
@TOC
推荐超级课程：
当今，容器与生产环境是同义词，但这种新技术与监控其他基础设施组件并没有太大不同。
高级监控的实施和持续应用使工程师更容易诊断和解决问题。选择策略涉及理解技术要求、期望的结果和权衡。让我们首先看看在进入可能的实施之前要监视什么。
要监视什么
容器与传统流程无异，只是多了一些机制来将它们与其他流程隔离。这意味着您将需要像内存利用率和CPU使用率之类的常见指标。您还需要容器特定的指标，比如CPU限制（容器允许占用主机CPU的比例）和内存限制（容器允许占用主机内存的比例）。这四项指标提供了重要的利用率比例，它们可以提供关于何时扩展、扩展或缩减的信息。
但CPU和内存之外还有更多。考虑您的容器基础设施。如果您使用的是Kubernetes，则还需要集群本身的遥测数据。对于像DC/OS或Docker Swarm这样的系统也是如此。您还需要群集可分配内存和CPU的比率，以及其他编排特定的指标。这些比率告诉您何时扩展、扩展或缩减。
让我们进入容器一睹为快。 假设一个容器运行一个HTTP服务器。您需要收集标准指标，如请求计数以及对2xx、4xx、5xx和延迟的计数。 假设您有另一个容器用于离线处理作业。您需要收集指标，如已处理作业的数量、失败的作业或重试。
这些是应用层的指标，与基础设施层分开，无法从容器运行时收集。 相反，监控系统必须从进程本身拉取它们，或者进程必须将它们推送到监控系统。 良好的监控策略考虑了堆栈各层中不同需求的情况。
在堆栈中有来自多个层的非数字数据。 它可能是报错信息，比如“无法连接到数据库”，“容器重启”或“进程抖动”。通常这些信息以文本为基础的日志形式呈现，并倾向于包含真正有用的信息。一个好的监控解决方案会考虑到这些信息。
比较监控系统
良好的监控系统有一些共同之处。您可以通过考虑以下几点来确定哪个系统适合您：
- 添加测量工具到现有代码有多容易？
- 正在使用的语言库如何？
- 是否支持不同的数据类型？
- 配置不同数据的警报有多容易？
- 警报如何连接到值班团队？
- 可视化系统如何允许您探索数据？
- 您是否可以创建临时图表和/或保存的仪表板？
- 支持多少现有基础设施组件（尤其是容器编排）？
这些问题提供了一个强大的框架，用于评估遍及整个堆栈的遥测数据工作原理，以及可视化和警报。以下是在所有领域表现良好的容器监控的五个选择。
1. Datadog
Datadog使用代理方法从各种组件中提取指标。 它支持Docker、Kubernetes、DCOS、Docker Swarm等常见组件。Datadog提供了所有关键指标，并且很容易地与堆栈中的不同层集成。Datadog Web应用程序提供了仪表板和警报功能，代理是开源且高度可配置的。 工程师可以编写自定义集成来从基于文本的日志和自定义指标中生成事件。 Datadog还提供DogStatsD，一个向Datadog报告的StatsD服务器。这对于已经使用StatsD或正在寻找简单的应用层遥测解决方案的团队来说非常有用。
2. Prometheus
Prometheus是一个完整的开源监控解决方案，与其他解决方案不同之处在于它从组件中抓取数据。 没有代理，而是有一个集中的服务器，管理着通过某种服务发现注册的系统，从中抓取数据。 整个堆栈包括警报和可视化。Prometheus也完全是云原生的，因此可以预期更多的系统随着时间而与Prometheus对话。 该系统在收集文本数据方面表现不佳，因为它主要基于时间序列。还要记住，每个系统必须自己聚合数据。这将被转移到语言特定的库，例如用于JavaScript应用程序的NPM包或用于Ruby应用程序的Ruby gem。 Prometheus主要通过HTTP抓取数据，因此如果组件没有使用HTTP，则可能需要额外的基础设施。
考虑短寿命作业。您需要一个推送网关获取这些信息。 考虑一个长寿命的进程，处理队列中的作业。该进程可能会与一个推送网关集成，或者提供一个HTTP服务器用于抓取数据。
3. ELK（Elasticsearch、Logstash、Kibana）
ELK是一个灵活的开源解决方案，处理文本流和时间序列数据。 该堆栈由三个组件组成——Elasticsearch、Logstash和Kibana，每个负责数据管道中的不同阶段。这使得它更容易与各种基础设施组件集成而无需对其施加要求。
在大型环境中运行所有这些组件是设置这个方案的最大妥协，因为需要大量的维护和手动操作。扩展和维护Elasticsearch可能是一份全职工作。添加缓冲或队列机制（例如Kafka或Redis）是必须的以持久化数据。存档、警报、安全性——如果您想要一个生产级别的监控系统，所有这些都需要加入到堆栈中。
托管的ELK解决方案，例如Logz.io或Elastic Cloud，如果您想要节省资源，是一个不错的选择，因为它们将操作您的Elasticsearch集群并为您配置所有组件。将数据推送到集群是您的责任，然后就可以开始了。
4. Sysdig
Sysdig 是一个通用的监控解决方案，Sysdig Cloud提供了一个云托管的监控系统。 Sysdig CLI可以安装并运行在任何Linux系统上，以收集和分析特定时间窗口的数据。 Sysdig Cloud类似于Datadog的代理方法。该产品提供了Docker监控、利用智能Kubernetes、Mesos和Swarm集成进行警报和故障排除、以及可视化和警报。
5. 自行打造！
总是有自行打造解决方案的选择。 如果没有现有解决方案符合您的要求，或者付费解决方案过于昂贵，您可以选择这种方式。自行打造解决方案可能需要一些已经讨论过的组件。您需要一种在堆栈的多个层上收集和聚合时间序列数据的方式。 像Collected这样的工具处理基础设施数据。 像StatsD这样灵活的工具适用于应用层。数据必须存储用于分析、可视化和警报。 您可以选择像Graphite（以及托管变体）这样的工具来与StatsD一起使用。 InfluxDB是另一个常见的用于存储时间序列数据的选择。您还需要一种可视化数据和创建警报的方式。 也有不同的架构。一种方法是将所有东西推送到诸如Riemann之类的系统，该系统可以处理聚合、警报和数据转发。 自行打造解决方案需要在堆栈的各个层面进行仔细规划，并且比其他解决方案需要更多的维护。
如何选择
在工程方面，一切都是权衡，选择监控方法也不例外。 您必须考虑哪些方面最重要，比如实时日志流、时间序列数据可视化、现有集成或自定义集成的灵活性。 最终，您的解决方案应至少提供：
- CPU、内存、I/O等关键容器指标；
- 容器编排集成如Kubernetes、DC/OS或Docker Swarm；
- 与常见组件如Redis（不要为常见情况重复造轮子）的现成集成
- 时间序列可视化和警报功能。
总结
这里讨论的所有选择都由您决定哪种权衡组合适合您的团队。 请谨慎选择自制解决方案；您可能会制造更多问题而不是解决问题，而这正是您在监控系统中不需要的。尽快将监控系统投入生产。
强大的生产环境围绕一个完善的监控系统展开。 但您的工作并不止于此。您的监控系统可以使生产环境更安全，因此随着堆栈的演变，不断试验和改进它。