借助 Elastic 可观测性解决方案监测基础架构和微服务

基础架构和软件领域的发展趋势改变了我们构建软件以及运行软件的方式。因此，我们已开始将基础架构视为代码，这有助于降低成本以及更快地将产品推向市场。借助这些新的架构，我们还能够在类生产环境部署中更快完成软件测试，并且通常可以实现更稳定、可复制的部署模式。然而，与这些改进相对的是环境的复杂性增加，特别是在有效监测新基础架构方面。 

在这篇博客中，我们将讨论监测整个应用程序堆栈（包括定制应用程序、服务以及用于运行它们的基础架构）的“必备工具”。我们还会展示 Elastic 可观测性解决方案和 Elastic Stack 如何满足这些需求，以及如何帮助您构建理想的监测平台，从而提高可观测性并减少中断时间。准备就绪后，您可以在 Elastic Cloud 中开始免费试用或从我们的网站下载最新版本，然后开始使用。

不断发展的架构：容器和微服务发展历程

我们是如何取得今日的成就？基础架构软件领域正在飞速发展。从硬件的角度来看，我们已经从使用实体机转变为使用各种虚拟化工具（或虚拟机监控程序）。在这之后，我们见证了公共云基础架构的兴起，使我们得以将服务器以及网络的维护和配置任务外包，从而有助于加快实现价值的速度。我仍然记得在过去，如果要配置新的服务器，我们必须等待数周的时间，在等待期间，项目也不得不暂停。也许今天仍有人这样做，但这一问题早已解决。如今，容器平台（诸如 Docker 和 Kubernetes 等容器编排程序）已成为许多组织的首选平台。当然，其中许多组织也在裸机主机上运用虚拟化技术。

沿着这条时间轴，从软件方面来看，我们已经从构建整体架构，发展为将软件架构分解为多个层（表示层、应用层、数据层等）。之后，面向服务的体系结构 (SOA) 成为主导的设计模式，它们依次演变为具有不同特点的形式：Web 服务，事件驱动型架构，当然还有其最新形式，即微服务。如今，如果想构建一个新应用程序，那么它很可能会基于微服务，而微服务则可能在云中 Kubernetes 上的 Pod 中运行。现在，您所在的组织很可能已经制定一项或多项计划，目的是将旧的整体架构分解为很多微服务，并使用编排程序来部署这些微服务。

因此，应用程序集现在有更多的组件需要监测，并且我们的监测工具需要跟踪不断移动的应用程序，在这个过程中，容器出现和消失的速率很高。如果要对当今的软件环境进行监测，必须采用一种全新的方法。

基础架构监测：当今软件环境复杂性所提出的要求 

谈及当今的部署环境，我们有许多方面需要考虑。无论是本地部署数据中心、公共云基础架构还是混合架构，我们都可用于运行应用程序和服务。当今任何一个典型环境中都具备一个编排层（例如 Kubernetes），用于实现应用程序的自动部署和扩展。我们已经有可用于运行应用程序的事物，例如容器、虚拟机或裸机。在开发应用程序时，我们容易对第三方系统产生依赖，例如外部服务、数据库或我们所在组织中其他团队编写的组件。当然，还要考虑应用程序本身，包括内部组件和最终用户体验。

为确保应用程序正常运行，我们需要监测其中所有不同组件。这些组件会产生大量监测数据，不仅包括日志和指标，还包括 APM 和运行时间数据。 

为实现对此类部署的全方位监测，我们希望监测解决方案能够满足以下要求：

• 支持从主机到应用程序的完整基础架构和应用程序集。
• 可轻松从不同来源（例如虚拟机、容器、编排程序、云平台，数据库等）采集数据（特点通常表现为可以与监测解决方案提供的其他系统集成）。
• 既能处理随着基础架构向容器化过渡而动态特征日益明显的部署，又能处理旧式传统基础架构。
• 提供强大的工具，便于我们了解运行数据以及进行数据交互；根据组织中每个人（从 DevOps 团队到产品和业务负责人）的需求，构建优化视图。
• 若有任何问题，请与我们联系。 Alerting 是所有监测解决方案的基础程序块之一，应完全涵盖所有基础架构。
• 针对日志和指标，提供可靠的长期存储工具，以便用于历史数据分析或满足法规要求。该存储解决方案还应能够以完全可控的粒度和保留率，对数据的生命周期进行管理。
• 提供完整的基础架构和应用程序可观测性。通常情况下，大多数监测工具都是专门用于处理一种类型的数据：许多受欢迎的时序数据库 (TSDB) 仅适用于处理指标。但是，任何典型的部署环境都会产生各种数据：日志、指标、APM 和可用性数据。这些数据流让我们能够从不同的视角了解环境的运行情况。既然如此，那么为何要区别对待这些数据，并维护具有不同学习曲线、许可模型或支持级别的工具呢？
• 将以上所有优势整合到一个全面的监测解决方案。

该列表的内容可以归结为两个核心要求：基础架构监测解决方案应该能够从基础架构的所有组件获取运行数据，并且使运行数据具备可操作性。

用于监测基础架构的 Elastic Stack (ELK Stack)

若要有效监测当今的基础架构，必须具备持续改进的增强型监测能力，这就需要有快捷、可靠且灵活的解决方案。我们来看看 Elastic 如何满足这些要求。

采集日志及指标

Elastic 提供集成工具，用于从数百个平台和服务中采集日志和指标数据。这些集成工具不仅为添加新的数据源提供了一种简单的方法，还随附开箱即用的资产，比如仪表板、多个可视化视图以及预生成的管道，这些资产具有可从日志中提取特定字段等功能。Elastic 提供 Metricbeat 和 Filebeat，用于将日志和指标数据传输到 Elastic Stack。对于 Metricbeat 和 Filebeat 支持的所有集成工具，Kibana 中都有简单易懂的说明。

如果希望将可观测性（或许是安全性）覆盖范围扩展到其他领域，您会发现有更多的采集器和代理需要管理。配置和管理一组代理可能变得很复杂，尤其是在大型企业环境中：您需要管理代理部署、更新配置文件和管理数据（许多团队已经在做）。我们希望改善这种现状。在版本 7.8 中，我们增加了两个新组件：Elastic 代理和 Fleet 在向 Elastic 发送运行数据方面作出了重大改进。

• Elastic 代理是用于收集日志、指标和其他类型数据的单个代理。相较于需要手动维护的独立集成工具，它更易于安装和管理。
• Fleet 是一种新的 Kibana 应用，可帮助您完成两件事：快速实现所选平台和服务的集成，以及集中管理整个 Elastic 代理组。

您现有的监测工具性能如何？如果您正在使用诸如 Stackdriver、Azure Monitor 之类的本地云监测服务，或正在使用诸如 Prometheus 或 statsd 之类的工具，并决定将指标数据与日志及其他数据整合在一起，Elastic 也能为这些高级监测工具提供专用集成工具，让您在保留现有工具（例如，prometheus 导出程序）的同时，仍然能够存储指标以及其他运行数据，从而获得更高的可观测性。

我前面提到，在向容器化部署转变时，必须重新考虑我们如何从总体上监测系统。对于设计用于处理物理主机/虚拟机以及静态基础架构的传统监测工具来说，这一点尤其适用。就容器而言，传统的方法已无法满足需求，因为事物不断发展和变化，容器不断变换，服务部署更加频繁，并且它们的 IP 地址也不稳定、不可靠，许多监测工具对此束手无策。在容器中运行应用程序时，容器实际上就成为了监测系统的移动目标，因此，必须自动检测这些环境中出现的变化，例如刚刚部署的服务、扩展的实例或完成的升级。好消息是 Metricbea t和 Filebeat 都具有自动发现功能，可以跟踪部署、检测任何变化，并且可以灵活调整配置以便在服务开始运行时就加以监测。 

通过 Elastic 集成工具收集的所有数据均符合 Elastic Common Schema (ECS) 的要求，并且所有 Elastic 可观测性和安全性解决方案也都参考了该标准。ECS 与现有的其他数据模型有何不同？ECS 经过优化设计，旨在使其在用于 Elasticsearch 时实现效用最大化。它是一种开源工具，整合了全球社区的各种资源。从一开始，它就考虑了各种用例，例如基础架构指标和日志、APM、安全性以及许多其他类型的数据。ECS 可比喻为用于所有 Elastic 解决方案的“结缔组织”。针对不同的数据流，ECS 能够以统一的方式实现关联、可视化以及分析。 

Elastic 已经部署 ECS；另外，我们看到越来越多的公司也在采用 ECS，并且根据各自的用例，通过其特定于域的架构对 ECS 进行了扩充。有些组织甚至在跨团队项目中将 ECS 用作通用数据模型。看到这些公司采用 Elastic 解决方案来打破数据竖井 (silo) 并且使各团队凝聚起来，我们非常高兴！

存储日志和指标

说到存储数据，Elasticsearch 最为大众所熟知的特点就是可以作为日志存储系统。这一点并不意外：日志记录几乎是 Elasticsearch 的第一个用例。但随着时间的推移，我们看到许多用户将时序数据与日志一起存储，这很有意义。如果您要存储基础架构和应用日志，那么，何不同时存储可告知您何时查看日志的指标呢？

早期，我们开始在将 Elasticsearch 打造为时序数据存储系统方面进行投资，通过引入列式存储功能来实现此类用例。之后，我们引入了聚合框架，通过该框架可实现在不同的维度对指标分组和筛选。为了提高处理数字和地理数据的能力，我们引入了 BKD 树以及许多其他功能来有效管理时序数据，其中包括如下功能：数据汇总，使您可以降低历史数据的粒度层次（即“缩小取样功能”）；以及索引生命周期管理，使您可以针对数据的不同阶段，灵活控制保留期限，例如 hot（热）阶段、warm（温）阶段、cold（冷）阶段和 delete（删除）阶段。

使监测数据具备可操作性性

可视化

假设我们已经开始采集数据，现在日志和指标正在通过流式处理传输至 Elastic。我们要做的第一件事就是用有意义的方式来查看这些数据。用户在使用某些监测工具时，需要自己创建或搜索数据可视化视图，但是我们认为此类视图至关重要，因此，Elastic 为每个受支持的集成工具提供预生成的可视化视图和仪表板。这意味着，开始收集日志或指标后，您就可以快速提取仪表板，立即查看系统和服务的情况。 

组成预定义仪表板的所有可视化视图都可以重复使用，也就是说，您可以从中选择您认为特别有用的视图并根据特定需求构建定制仪表板，从而整合以及匹配来自不同集成工具的数据，进而获得您所提出问题的答案。此外，您还可以创建定制下拉菜单用于筛选数据，或者创建向下钻取图表 (drilldowns) 以便在不丢失上下文的情况下从一个仪表板导航到另一个仪表板，这样可以使系统非常整洁且有条理，因为这样做确实有助于简化故障排除的工作流。

除了仪表板和可视化视图之外，Elastic 还提供适用于日志、指标和可用性数据的精选应用，所有这些应用都旨在提高整个基础架构的可见性。

通过 Metrics 应用就可以全面了解整个基础架构的情况。如果您有分布于多个地理位置的数据中心，如果您需要在多云环境中运行 Kubernetes，或者如果在当前系统设置下所有数据都混在一起，您都无需担心。针对您所有的资源，Metrics 应用可提供一个统一的管理视图 (pane of glass)。在这个视图中，您可以按照基础架构提供商、地理区域或几乎任何您可能用来区分过渡环境和生产环境的定制标签字段，对资源进行分组。通过这个视图，您可以查看更详细的指标并检查任何资源的日志、应用程序性能或运行时间信息。实现上述功能的前提是：Elastic 可作为适用于所有运行数据的单一数据存储系统，让我们可以构建精心设计的视图，将它们链接在一起以实现更简单的导航，还可以简化基础架构监测流程。 

Metrics 应用还提供了一个指标浏览器，允许您将不同的指标叠加起来，查看它们之间是否存在任何相关性，这对于故障排除很有帮助。通过此应用，您还可以创建新的可视化视图或阈值告警。

Logs 应用基本上是整个基础架构的 tail -f 日志文件。它整合了所有日志流，并在一个视图中显示实时日志和历史日志。在后台，日志与指标之间建立起关联，这使得在调查问题时，更容易跟踪线索。在此应用中，您可以查看每个日志行的详细信息，还可以查看在该日志行写入数据前后发生的情况。就像 Kibana 中的所有其他可观测性应用一样，它的作用远不止是只读视图。它还支持通过告警和机器学习，对任何可疑情况进行分析并采取相应措施。

Alerting

Alerting 基本上是所有监测用例的基础程序块之一，因为它可以帮助检测整个基础架构中的任何问题并作出响应。借助 Elastic 中新的告警框架，现在，我们可以提供针对不同数据流进行了优化的多种类型的告警。 

• 指标告警可针对任何类型的部署（物理或容器化）轻松配置，这也意味着，这些告警可自动覆盖新创建的资源。您可以借助筛选器，控制告警要覆盖基础架构的哪些部分。此外，您还可以对告警进行一次配置，让其根据您选择的字段自动拆分，例如，针对每个主机发出告警，或针对每个主机上的每个磁盘发出告警。

• 日志告警针对日志数据进行了优化，使您可以基于可匹配某个短语的字段或基于某个字段的日志记录频率创建告警。

所有的告警都可以从 Kibana 中的某个集中位置统一创建和管理，但同时也会嵌入到各自所属的应用中，这使得它们在日常操作中非常易于使用。

机器学习及异常检测

如今，基础架构所产生的运行数据的数量庞大且在不断增长，这使得几乎不可能手动分析不同的数据流。事实上，对于那些正在寻找解决方案以实现问题检测自动化的组织来说，这逐渐成为一个严重的问题。因此，新式监测解决方案的重要组成部分就是能够在不良情况发生之前，自动检测部署环境中的任何异常行为。

好消息是，运行数据传输到 Elasticsearch 之后，就可以立即进行分析。用于异常检测的预定义机器学习作业已经针对日志和指标进行了优化，并且可以根据需要与 Kibana 应用集成。例如，它们可以自动检测出基础架构的日志生成速率是否存在异常，或者查找模式并根据类别自动将日志分组。

Elastic 的机器学习功能不仅仅局限于异常检测。您可以在涉及基础架构数据的大量用例中使用其他算法，如分类、离群值检测等。

借助 Elastic Stack 实现更大价值

由于所有内容都是 Elastic 中的另一个索引，您可以使用 Elastic 的任何功能处理监测数据。通过 Kibana 中的各种可视化视图，您可以构建对组织中每个人都有意义的视图，例如使用 Lens 和 TSVB（以前称为“时序可视化生成器”，一种用于构建可批注指标和可视化直方图的强大工具）构建灵活、密集并且对您的工程团队很有价值的仪表板，或者是使用 Canvas 构建实时信息图表，可将复杂数据转化为对业务负责人很有价值的趋势信息。 

您可以使用熟悉的查询语言（如 SQL 或 PromQL）从 UI 或 API 访问存储在 Elastic 中的所有内容。PromQL 的应用日益广泛，并且借助我们的 Prometheus 集成工具，您可以将 PromQL 查询的结果写入 Elastic。如果您不想存储原始指标，而仅对已处理的数据感兴趣，那么，此工具尤其有用。

您还可以将基础架构监测与安全性相结合。可观测性与安全性之间的界限正逐渐消失，因为在本质上，我们用于监测基础架构的数据，与我们用于保护基础架构安全的数据也有关联，两者使用的是相同的数据。正如可观测性解决方案一样，Elastic 安全性解决方案也建立在 Elastic Stack 的基础之上，并且可使您轻松检测和阻止基础架构中的安全威胁。

结论

在这篇博客中，我们列出了对于新式监测解决方案的需求，并展示了 Elastic 如何满足这些需求。Elastic 可观测性解决方案及 Elastic Stack 可以帮助您构建理想的监测平台，您和您的团队可以通过这个平台安全地采集所有运行数据并成功地完成数据交互。

但还是请您亲自试用，而非仅听我们的一面之词。  在 Elastic Cloud 的免费试用版中快速部署一个集群，或从我们的网站下载最新版本，然后告诉我们您的想法。