Datalog-云监控快速启动指南-全-

Datalog 云监控快速启动指南（全）

原文：annas-archive.org/md5/d2ceee72c3f9450445e7ec58b5927d4f

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

监控软件应用程序曾经是一个事后思考的问题——当发生故障时，才会设置监控来检查软件功能或软件系统运行所在基础设施的状态。监控从未是全面的，监控基础设施是自然生长起来的。第一代监控工具仅设计用于满足这种简单、反应性的监控推出方式。

公共云作为计算平台的广泛使用、将应用程序部署为微服务的持续趋势以及提供软件即服务（SaaS）并实现24x7可用性，使得软件系统的操作变得比以往更加复杂。主动监控成为 DevOps 文化的核心部分，因为逐步迭代和渐进式地推出监控已经不再是一个选项，用户期望软件系统始终可用。现在，软件系统在设计时便考虑到了可观察性，以便能够暴露其工作原理并进行有效监控。系统和应用程序日志都会被汇总并分析，以便获取操作洞察。

现在有大量的监控应用程序可供选择，以满足这些新的监控需求，既有本地部署的解决方案，也有基于 SaaS 的解决方案。一些工具专注于监控的特定领域，而其他工具则试图满足所有类型的监控需求。通常需要使用三到四种不同的监控应用程序来覆盖监控的各个方面。Datadog，一种 SaaS 监控解决方案，正作为一个监控平台崭露头角，企业可以使用它来构建全面的监控基础设施。本书旨在向各种受众介绍 Datadog，并帮助您将其作为一种主动的监控解决方案进行部署。

本书的适用对象

本书适合 DevOps 工程师、站点可靠性工程师（SREs）、IT 生产工程师和系统管理员，他们需要了解 Datadog 作为一个全面的 SaaS 监控平台所提供的功能，以便将这些功能推出并将 Datadog 与其他应用程序集成。对于软件开发人员来说，本书也很有帮助，可以帮助他们理解现代监控工具的工作原理，并相应地对他们的应用程序进行微调。

本书是一本关于监控的入门级书籍，也是一本监控技术指南，除了关注 Datadog 的功能外，本书还将对任何有兴趣了解更多软件应用程序监控的人有所帮助。然而，以下背景将帮助您更好地理解本书的内容，并充分利用书中的示例来获得实际操作经验：

• 具备公共云的工作知识，并有云资源配置的经验

• 具备 Linux 或 Windows 操作系统的工作知识，尤其是前者

• 在生产环境中支持软件系统和处理生产问题的工作经验

本书内容简介

第一章，监控简介，介绍了业界标准的监控术语，并定义了实际应用中不同类型的监控。本章还概述了当前流行的监控工具和平台。

第二章，部署 Datadog 代理，讨论了 Datadog 代理的工作原理及其在 Datadog 监控平台中的作用。并提供了安装 Datadog 代理的过程和示例步骤。

第三章，Datadog 仪表板，介绍了 Datadog 用户和管理员使用的 Datadog 仪表板。本章描述了 Datadog UI 的各种功能，这些功能是 Datadog 的常规用户日常使用的。

第四章，账户管理，解释了 Datadog 用户在维护账户时会执行的各种管理任务。

第五章，指标、事件和标签，描述了指标和标签，这是 Datadog 用于发布、监控状态和组织数据与资源的两个重要概念。本章还涵盖了监控事件。

第六章，基础设施监控，详细讲解了 Datadog 在基础设施监控方面的工作，这是监控的重要类别。本章还描述了不同的基础设施类型和组件，以及 Datadog 发布的相关指标组。

第七章，监视器和警报，介绍了监视器和警报，这是任何监控工具的核心部分。本章详细探讨了这些概念在 Datadog 中的实现方式。

第八章，与平台组件集成，详细描述了将 Datadog 与其他基础设施和软件组件集成的多种方式，并提供了示例。

第九章，使用 Datadog REST API，介绍了 Datadog REST API，该 API 用于以编程方式访问 Datadog。本章描述了典型的使用案例，详细解释了如何使用 Datadog API，并附有教程。

第十章，使用监控标准，探讨了将监控工具与应用程序集成的行业标准。本章通过示例讨论了三种集成标准：SNMP、JMX 和 StatsD。

第十一章，与 Datadog 集成，介绍了一些常用的官方和社区开发的编程库，这些库可用于将应用程序直接与 Datadog 集成。

第十二章，容器监控，讨论了 Datadog 在 Docker 和 Kubernetes 环境中可用的容器监控工具。

第十三章，使用 Datadog 管理日志，介绍了日志管理提供的标准日志聚合、索引和搜索功能，这是 Datadog 平台最近新增的功能。

第十四章，杂项监控主题，讨论了 Datadog 平台上一些新的功能，如 APM、安全监控、可观察性和合成监控，该平台持续增长。

为了充分利用本书的内容

对公共云或裸金属基础设施的工作知识会有帮助。为了跟随本书中的示例，您需要具备 Linux 发行版和 Python 的工作经验。对于完全理解书中讨论的概念，您需要对生产环境中运行的软件系统有所了解。

如果您使用的是本书的电子版本，我们建议您手动输入代码，或通过 GitHub 仓库（下节提供链接）访问代码。这样可以帮助您避免与复制粘贴代码相关的潜在错误。

下载示例代码文件

您可以从 GitHub 下载本书的示例代码文件，网址为 https://github.com/PacktPublishing/Datadog-Cloud-Monitoring-Quick-Start-Guide。如果代码有更新，GitHub 上的现有仓库将会进行更新。

我们还提供了其他来自我们丰富的书籍和视频目录中的代码包，您可以在 github.com/PacktPublishing/ 查找。快去看看吧！

下载彩色图片

我们还提供了一个 PDF 文件，其中包含本书使用的截图/图表的彩色图像。您可以在此下载：www.packtpub.com/sites/default/files/downloads/9781800568730_ColorImages.pdf。

使用的约定

本书中使用了一些文本约定。

文本中的代码：表示文本中的代码词汇、数据库表名、文件夹名称、文件名、文件扩展名、路径名、虚拟 URL、用户输入和 Twitter 账号。例如：“主 Datadog Agent 配置文件 datadog.yaml 可以更新以满足您的特定监控需求。”

代码块的格式如下：

init_config:
instances:
    - url: "unix://var/run/docker.sock"
      new_tag_names: true

当我们希望引起您对某个代码块中特定部分的注意时，相关行或项目将以粗体显示：

usermod -a -G docker dd-agent

所有命令行输入或输出都按如下格式书写：

DOCKER_CONTENT_TRUST=1 docker run -d --name dd-agent -v /var/run/docker.sock:/var/run/docker.sock:ro -v /proc/:/host/proc/:ro -v /sys/fs/cgroup/:/host/sys/fs/cgroup:ro -e DD_API_KEY=<DATADOG_API_KEY> datadog/agent:7 

粗体：表示一个新术语、重要的词汇，或是你在屏幕上看到的文字。例如，菜单或对话框中的文字会以这种方式出现。以下是一个示例：“如果代理能够连接到后台，相应的主机将会在仪表板下的基础设施 | 主机映射和基础设施列表中列出。”

提示或重要说明

以这种方式出现。

联系我们

我们总是欢迎读者的反馈。

一般反馈：如果你对本书的任何方面有疑问，请在邮件主题中提及书名，并通过电子邮件联系我们：customercare@packtpub.com。

勘误：虽然我们已经尽力确保内容的准确性，但错误仍然可能发生。如果你在本书中发现了错误，我们将非常感激你向我们报告。请访问www.packtpub.com/support/errata，选择你的书籍，点击“勘误提交表格”链接，并填写相关详情。

盗版：如果你在互联网上发现任何我们作品的非法复制品，请将其位置或网站名称提供给我们。请通过版权@packt.com 联系，并附上材料的链接。

如果你有兴趣成为作者：如果你在某个领域有专长，并且有兴趣写书或为书籍贡献内容，请访问authors.packtpub.com。

评论

请留下评论。在阅读并使用本书后，为什么不在你购买本书的网站上留下评论呢？潜在读者可以参考并根据你的客观意见做出购买决策，我们 Packt 也能了解你对我们产品的看法，而我们的作者则可以看到你对其书籍的反馈。谢谢！

关于 Packt 的更多信息，请访问packt.com。

第一部分：开始使用 Datadog

本书的这一部分将通过讲解 Datadog 的核心功能以及如何使用它们，帮助你入门 Datadog。掌握这些信息后，你将能够在组织中推广使用 Datadog。你还将理解监控软件系统及其运行基础设施的基本概念，并能够将这些概念与 Datadog 的功能联系起来。

本节包括以下章节：

• 第一章，监控简介

• 第二章，部署 Datadog 代理

• 第三章，Datadog 仪表盘

• 第四章，帐户管理

• 第五章，指标、事件与标签

• 第六章，监控基础设施

• 第七章，监控与警报

第一章：监控简介

监控是一个广泛的领域，涉及许多工具和解决方案，它们满足该领域不同的需求。然而，仔细观察后会发现，这些产品有很多共同的特征。因此，在我们开始讨论 Datadog 作为监控工具之前，理解监控的核心理念和术语非常重要。

在本章中，我们将涵盖以下主题：

• 为什么要监控？

• 主动监控

• 监控用例

• 监控术语和流程

• 监控的类型

• 监控工具概览

技术要求

本章没有技术要求

为什么要监控？

监控是经营业务中的一个通用术语。在有效运营企业的一部分过程中，企业运营的各个要素会被衡量其健康状况和效果。这些测量结果会与企业目标进行比较。当这些工作周期性和系统性地进行时，就可以称之为监控。

监控可以是直接或间接的，也可以是自愿的或由某些法律强制的。成功的企业擅长通过使用各种指标来跟踪增长，并根据需要采取纠正措施，以调整他们的运营和目标。

之前的陈述是常识，适用于任何成功的运营，即使它是一次性事件。然而，我们已经提到了一些重要的关键词——指标、测量和目标。监控活动就是测量某些内容，并将结果与目标或指标进行比较。

虽然跟踪企业运营的各个方面很重要，但本书的重点是监控在生产中运行的软件应用系统。信息技术（IT）是运营企业的关键要素，它涉及到软件系统的运营。随着软件作为服务通过互联网提供（通常称为软件即服务或SaaS），大多数软件用户不需要在内部运行软件系统，因此他们无需监控它。

然而，SaaS 提供商需要监控他们为客户运行的软件系统。像银行和零售连锁等大型企业可能仍然需要在内部运行软件系统，因为云中可能没有所需的软件服务，或者出于安全性或隐私原因。

监控软件系统的主要关注点是检查其健康状况。通过跟踪软件系统的健康状况，可以判断系统是否可用，或者其健康状况是否在恶化。

如果能提前捕捉到软件系统恶化的状态，那么在发生停机之前修复潜在问题就可能成为可能，从而确保业务连续性。提供提前警告的这种主动监控方法是理想的监控方式。但这并非总是可行的。必须也有应对软件系统停机的相关流程。

运行在生产环境中的软件系统有三个主要组成部分：

• 应用软件：软件服务提供商构建的应用程序供客户使用，或者软件是为内部使用而在公司内部构建的。

• 第三方软件：现有的第三方软件，例如数据库和消息平台，被用来运行应用程序软件。这些软件可以通过 SaaS 服务订阅，或者在内部部署使用。

• 基础设施：通常指用于运行应用程序和第三方软件的网络、计算和存储基础设施。这可以是数据中心中的裸金属设备，也可以是通过 AWS、Azure 或 GCP 等公共云平台提供的服务。

虽然我们之前广泛讨论了软件系统的监控，但仔细看就会发现，监控之前提到的三个主要组成部分是其中的关键。使用相关度量标准所测量的信息对于每个类别都是不同的。

这三个组成部分的监控构成了核心监控。还有许多其他方面——包括系统内部的健康状况和外部的安全性——也需要纳入软件系统的监控当中。我们将在本章中简要介绍软件系统监控的所有主要方面，并在后续章节中介绍 Datadog 如何支持这些方面。

主动监控

从技术角度来看，监控并不是生产环境中运行的一个软件系统的组成部分。软件系统中的应用程序可以在没有任何监控工具的情况下运行。作为最佳实践，软件应用程序必须与监控工具解耦。

这种情况有时会导致将软件系统以最小或没有监控的状态投入生产，这最终会导致问题未被发现，或者在最糟糕的情况下，用户在使用软件服务时发现这些问题。由于以下原因，这种情况对业务来说是不利的：

• 生产环境中的问题会影响客户的业务连续性，通常还会产生与之相关的财务成本。

• 软件服务的计划外停机会给用户留下关于软件服务及其提供商的负面印象。

• 非计划停机会在业务层面造成混乱，处理和解决这些问题可能对每个相关方造成压力，并且对受影响的企业来说也是昂贵的。

在应对生产问题时采取的缓解措施之一是增加一些监控，以便捕捉并报告相同的问题给运维团队。通常，这种反应式方法会有机地增加监控覆盖范围，但并没有遵循监控策略。虽然这种方法有时能帮助捕捉问题，但不能保证有机增长的监控基础设施能够检查软件系统的健康状况并发出警告，从而采取主动的修复措施，以最小化未来的故障。

主动监控是指为软件系统推出监控解决方案，以报告软件系统组件及其运行基础设施的问题。这种报告有助于通过手动或自动采取缓解措施来避免即将发生的问题。后一种方法通常称为自我修复，这是监控的一个高度理想的终极目标，但实现起来困难。

主动监控策略的关键要素如下。

实施全面的监控解决方案

传统上，监控的重点一直是基础设施组件——计算、存储和网络。正如你将在本章稍后看到的，还有更多的监控方面需要完成这个清单。必须为软件系统实施所有相关类型的监控，以便捕捉并报告任何组件、软件或基础设施的问题。

设置警报以警告即将发生的问题

监控解决方案必须设计为预警软件系统中即将发生的问题。对于基础设施组件来说，这是容易的，因为可以轻松追踪内存使用、CPU 利用率和磁盘空间等指标，并在任何超出限制的使用情况下发出警报。

然而，在应用程序层面，满足这样的需求可能会很棘手。有时应用程序可能会在配置完美的基础设施上发生故障。为了解决这个问题，软件应用程序应该提供对其内部运行情况的洞察。在监控术语中，现在通常称为可观察性，稍后我们将在本书中看到如何在 Datadog 中实现这一点。

建立反馈回路

一个成熟的监控系统，能够预警即将发生的问题并帮助采取缓解措施，还不够好。这些警告还必须用于自动解决问题（例如，当现有虚拟主机的磁盘空间耗尽时，启动一个新虚拟机并分配足够的磁盘空间），或被反馈到应用程序或基础设施的重新设计中，以避免未来发生类似问题。

监控用例

监控应用程序的安装和配置是根据要监控的应用程序运行的位置进行的。在这里，我们将查看几个不同场景中监控如何推出的使用案例，以理解典型的配置。

数据中心中的所有内容

这是一个经典的监控场景，其中托管应用程序的基础设施和监控工具都位于一个或多个数据中心中。数据中心可能是由企业私有拥有，也可能是从数据中心提供商那里租用的托管设施。后一种选择通常称为共址（co-location）。

该图展示了软件应用和监控工具如何在同一个数据中心中运行。

图 1.1 – 单一数据中心

以下图示展示了软件应用和监控工具如何在两个数据中心中运行，这确保了软件系统的可用性：

图 1.2 – 在一个数据中心与多个数据中心

如果应用程序托管在多个数据中心中，且其中一个数据中心无法访问，监控系统能够发出警报。如果仅使用一个数据中心，则不可行，因为整个监控系统将与其监控的软件系统一起无法访问。

在数据中心中应用与云监控

这是一个新兴的场景，企业将其基础设施托管在数据中心，并使用像 Datadog 这样的云监控服务进行监控。在这种情况下，监控后端位于云端，其代理程序与应用系统一起在数据中心中运行。

图 1.3 – 在数据中心中应用与云监控

不需要监控监控系统本身，因为 SaaS 提供商会提供其状态。

完全云端

在完全云端的监控场景中，可能有两种不同的情况。在这两种情况下，运行软件系统的基础设施都会位于云端，通常是公共云平台，如 AWS。整个监控系统可以部署在相同的基础设施上，或者使用云监控服务，如 Datadog，在这种情况下，只有它的代理会与应用系统一同运行。

图 1.4 – 完全云端与内部监控

在完全云端的场景下，您需要设置监控系统，或利用由公共云提供商提供的监控服务，比如 AWS 的 CloudWatch，或者两者结合使用。

图 1.5 – 完全云端与云监控

在完全云化的第二种情况下，使用的是第三方 SaaS 监控服务，例如 Datadog。使用 SaaS 监控服务的主要吸引力在于其丰富的功能集、高可用性以及部署和维护监控时的最小开销。

使用云基础设施的额外优势之一是可以访问原生监控工具，例如 AWS 上的 CloudWatch。这些服务具有高度可靠性，可以通过多种方式增强监控，以完成以下任务：

• 监控通过标准监控工具难以监控的云资源

• 作为二级监控系统，主要用于覆盖基础设施监控

• 作为元监控工具监控其余的监控基础设施

我们在这里讨论的场景是经过简化的，以便解释核心概念。在现实生活中，监控解决方案会结合多个工具，一些工具可能是在本地部署的，另一些则可能是基于云的。当涉及到如此复杂的配置时，不丢失主动监控的主要目标是拥有一个可靠的监控系统的关键，这样可以帮助减少故障，并提供操作性洞察，从而有助于对应用系统进行微调。

监控术语和流程

现在，让我们来看一下文献和工具中最常用的监控术语。某些术语之间的差异微妙，您可能需要特别留意才能理解它们。

主机

在数据中心时代，主机通常指的是物理服务器。在监控领域，它通常指具有 IP 地址的设备。这涵盖了各种各样的设备和资源——裸金属机器、网络设备、物联网设备、虚拟机，甚至容器。

一些第一代监控工具，如 Nagios 和 Zenoss，是围绕主机概念构建的，这意味着在这些平台上执行的所有操作都必须与主机相关联。在 Datadog 等新一代监控工具中，这种限制已被放宽。

代理

代理是与应用软件系统一起运行的服务，帮助进行监控。它执行监控工具的各种任务，并将信息报告回监控后台。

代理安装在应用系统运行的主机上。它可以是直接在操作系统上运行的简单进程，也可以是微服务。Datadog 支持这两种选项，当应用软件以微服务方式部署时，代理也以微服务方式部署。

指标

监控中的指标是指某些信息的时间度量，这些信息能够提供被监控系统的工作状态的洞察。以下是一些常见的例子：

• 机器根分区上可用的磁盘空间

• 查看机器上的空闲内存

• SSL 证书到期前剩余的天数

这里需要注意的重要一点是，度量是有时间限制的，并且其值会变化。出于这个原因，根分区的总磁盘空间不被视为度量。

一个度量是定期测量的，用于生成时间序列数据。我们将看到，这些时间序列数据可以以多种方式使用——在仪表盘上绘制图表、分析趋势，以及设置监控。

监控工具生成了各种各样的度量，特别是与基础设施相关的度量。也可以选择生成自己的自定义度量：

• 监控工具提供运行脚本生成度量的选项。

• 应用程序可以将度量发布到监控工具。

• 监控工具或其他工具可能提供插件，用于生成与软件系统使用的第三方工具相关的度量。例如，Datadog 为大多数流行工具（如 NGINX）提供这样的集成。所以，如果你在应用栈中使用 NGINX，启用集成后，你就可以获得 NGINX 特定的度量。

启用/禁用状态

一个度量的测量值可以有一个范围，但启用或禁用是一个二进制状态。以下是一些示例：

• 一个进程是否运行

• 一个网站是否可用

• 一个主机是否可 ping

跟踪软件系统各个组件的启用/禁用状态是所有监控工具的核心，它们具备内置的功能来检查各种资源。

检查

检查是监控系统用来收集度量值的工具。当它定期执行时，会为该度量生成时间序列数据。

虽然标准基础设施级度量的时间序列数据在监控系统中是现成可用的，但可以实现自定义检查来生成需要一些脚本的自定义度量。

图 1.6 – 主动检查/拉模式

一个检查可以是主动的或被动的。主动检查由监控后端发起，用于收集度量值和启用/禁用状态信息，可以有也可以没有代理的帮助。这也被称为数据收集的拉取方法。

图 1.7 – 被动检查/推模式

一个被动检查将此类数据报告给监控后端，通常通过其自身的代理或一些自定义脚本。这也被称为数据收集的推送方法。

数据收集的主动/被动或拉/推模型在所有监控系统中都是标准的。该方法取决于监控系统收集的度量类型。你将在后续章节中看到，Datadog 支持这两种方法。

阈值

阈值是度量值可能范围内的固定值。例如，在一个总磁盘空间为 8 GB 的根分区上，可用磁盘空间可能是从 0 GB 到 8 GB 之间的任何值。这个特定情况下的阈值可以是 1 GB，它可以设置为指示根分区存储不足。

也可以定义多个阈值。在这个具体示例中，1 GB 可能是警告阈值，500 MB 可能是关键或高严重性阈值。

监视器

监视器查看为度量标准生成的时间序列数据，并且在值越过阈值时向警报接收者发出警报。监视器也可以设置为上/下状态，这种情况下，如果相关资源停机，它将向警报接收者发送警报。

警报

当关联检查确定度量值越过监视器设置的阈值时，监视器生成警报。监视器可以配置为通知警报接收者警报。

警报接收者

警报接收者是组织中注册接收监视器发送的警报的用户。警报接收者可以通过多个通信渠道接收到警报，例如电子邮件、短信和 Slack。

严重级别

警报根据其揭示的软件系统问题的严重性进行分类，并由适当的严重级别设置。对警报的响应与警报的严重级别相关联。

一个示例的严重级别集合可以包括 信息、警告 和 关键。例如，在根分区可用磁盘空间的示例中，当可用磁盘空间为 30%时，监视器可以配置为警告，并且在 20%时可以配置为关键警报。

正如您所看到的，为不断加重的严重性设置警报级别将提供捕捉问题并及时采取缓解措施的机会，这是积极监控的主要目标。请注意，在系统组件随时间退化的情况下，这种方法是可行的。

跟踪上/下状态的监视器将无法提供任何警告，因此应尽快启动相关服务来采取缓解措施。然而，在实际情况中，必须有多个监视器，这样至少其中一个监视器可以提前捕捉到潜在问题。例如，在根分区没有磁盘空间时，可能会停止某些服务，监视根分区的可用空间将有助于防止这些服务停止运行。

通知

作为电子邮件等通信平台特定警报的一部分发送出去的消息被称为通知。警报和通知之间有微妙的区别，但有时它们被视为相同。警报是监视系统内的一个状态，可以触发多个动作，如发送通知和更新监视仪表板的状态。

传统上，电子邮件分发组是发送通知的主要通信方式。目前，有更多复杂的选项，如聊天和短信，几乎所有监控平台都原生支持这些选项。此外，PagerDuty 等升级工具可以与现代监控工具如 Datadog 集成，根据严重性路由通知。

停机时间

监控系统的停机时间是指该监控系统在一定时间窗口内禁用警报功能的时段。通常，这种做法是为了临时停用警报，当基础设施或软件组件的变更正在进行时，监控该组件变得无关紧要。例如，当增加存储空间的维护任务进行时，跟踪磁盘驱动器可用空间的监控将受到影响。

如 Datadog 等监控平台支持这一功能。该功能的实际应用是避免从受影响的监控系统接收通知。通过将 CI/CD 管道与监控应用程序集成，停机时间可以自动安排，作为部署的先决条件。

事件

监控系统发布的事件通常会提供软件系统发生变化的详细信息。一些常见的示例如下：

• 进程重启

• 由于用户流量变化而进行微服务的部署或关闭

• 向基础设施添加新的主机

• 用户登录敏感资源

请注意，这些事件不需要立即采取行动，而是提供信息。这就是事件与警报的区别。警报是可操作的，而事件没有严重性级别，因此不可操作。事件会记录在监控系统中，并且在问题排查时是有价值的信息。

事故

当产品功能无法提供给用户时，这称为事故。事故发生在基础设施出现故障时，可能是硬件或软件问题，但也不一定。它也可能由于外部网络或互联网相关的访问问题而发生，尽管这种情况较为少见。

处理事故并进行缓解的过程本身就是一个独立领域，通常不被视为核心监控的一部分。然而，监控和事故管理因以下原因密切相关：

• 如果没有全面的监控，事故总是会发生，因为没有监控系统，就无法在问题导致故障之前进行缓解。

• 当然，根本原因分析（RCA）的行动项通常会包括实施更多监控任务，这是一种典型的反应性策略（或者说没有反应性策略），必须避免这种情况。

值班

由监控系统发送的关键警报由值班团队响应。尽管实际需求可能会根据被监控应用程序的服务级别协议（SLA）要求有所不同，但值班团队通常是 24 小时全天候待命的。

在成熟的服务工程组织中，将提供三个级别的支持，问题从 L1 升到 L3：

• L1 支持团队由了解应用程序的产品支持人员组成，能够使用运行手册来响应问题。

• L2 支持团队由站点可靠性工程师（SREs）组成，他们可能也依赖运行手册，但他们还能够进行故障排查和修复基础设施和软件组件。

• L3 支持团队通常由设计并构建生产环境中的基础设施和软件系统的 DevOps 和软件工程师组成。通常，只有在处理未知问题时，这个团队才会介入。

运行手册

运行手册为值班支持人员提供响应警报通知的步骤。步骤可能并不总是提供解决报告问题的方法，有时仅仅是将问题升级到工程联系人，以便进一步调查。

监控类型

监控有不同的类型。与软件系统相关的所有监控类型都必须实施，才能使其成为一个全面的解决方案。另一个需要考虑的方面是推出某种类型的监控的业务需求。例如，如果软件服务的客户坚持要求确保他们订阅的应用程序的安全性，那么软件提供商就必须推出安全监控。

（本节讨论的监控类型最初出现在我发表的文章《主动监控》中，文章发布于DevOps.com网站。）

图 1.8 – 监控类型

现在让我们详细探讨这些监控类型。

基础设施监控

运行应用系统的基础设施由多个组件组成：服务器、存储设备、负载均衡器等。检查这些设备的健康状况是监控的最基本要求。流行的监控平台提供了开箱即用的支持此功能。除了为这些度量设置合适的阈值以便触发警报外，几乎不需要其他定制。

平台监控

一个应用系统通常是由多个第三方工具构建的，以下是一些示例：

• 数据库，包括关系型数据库（MySQL，Postgres）和 NoSQL 数据库（MongoDB，Couchbase，Cassandra）数据存储

• 全文搜索引擎（Elasticsearch）

• 大数据平台（Hadoop，Spark）

• 消息传递系统（RabbitMQ）

• 内存对象缓存系统（Memcached，Redis）

• BI 和报告工具（MicroStrategy，Tableau）

检查这些应用组件的健康状况也很重要。大多数这些工具提供了一个接口，主要通过 REST API，可以利用它在主监控平台上实现插件。

应用监控

拥有健康的基础设施和平台并不足以保证应用程序正确运行。最近部署的有缺陷的代码、第三方组件问题或与外部系统的不兼容更改，都可能导致应用失败。可以实现应用层检查来检测这些问题。如前所述，功能性或集成测试能够在测试/预发布环境中发现这些问题，并且在生产环境中也应该实现相应的检查。

实现应用层监控可以通过在应用中构建钩子或 API 端点来简化。通常，提高应用的可观测性是关键。

监控通常是事后考虑的，应用的设计阶段往往忽视了这种工具的需求。DevOps 团队参与设计评审可以提升系统的可操作性。规划生产环境中的应用层监控是 DevOps 可以提供建议的一个方面。

业务监控

应用系统在生产环境中运行，以实现特定的业务目标。你可能有一个在健康基础设施上完美运行的应用，但业务可能仍未达到其目标。在最早的机会提供反馈给业务非常重要，这样可以采取纠正措施，进而触发应用功能的增强和/或业务运作方式的改善。

这些努力应该仅仅作为更加复杂的基于 BI 的数据分析方法的补充，后者可以提供更深入的业务状态洞察。业务级监控可以基于数据仓库中现有的事务数据和 BI 系统生成的数据聚合。

应用层监控和业务层监控都是公司特定的，必须为这些监控需求开发插件。从监控平台访问标准信息源（如数据库和 REST API）实现一个框架，可以最大程度地减少每次都需要从零开始构建插件的需求。

最后一公里监控

在与应用程序运行的相同公有云或数据中心环境中部署的监控平台，无法检查最终用户体验。为了解决这个问题，市场上有多个 SaaS 产品，例如 Catchpoint 和 Apica。这些服务由实际的基础设施支持，用于监控特定地理位置的应用。例如，如果你想知道你的移动应用在芝加哥的 iPhone 上的表现，便可以通过服务提供商在芝加哥的测试基础设施进行跟踪。

在这些工具上设置警报，若应用无法从外部访问或出现性能问题时，通知站点可靠性工程团队。

日志聚合

在生产环境中，操作系统、平台组件和应用程序会在各种日志文件中记录大量信息。当出现问题时，这些信息会引起关注，否则通常会被忽略。传统的监控工具如 Nagios 除了在某些模式下发出警报外，无法处理不断变化的日志文件。

日志聚合工具的出现，如 Splunk，改变了这一局面。通过聚合和索引日志，可以检测到之前可能被忽略的问题。可以根据索引日志数据中的信息设置警报。例如，Splunk 提供了自定义查询语言，可以搜索索引以获取操作洞察。通过这些工具提供的 API，警报功能实际上可以与主要的监控平台集成。

为了充分利用这些工具的聚合和索引功能，应用程序或脚本可以生成结构化数据输出，这些输出稍后会被日志聚合工具索引。

元监控

确保监控基础设施本身正常运行非常重要。在部署期间禁用警报并忘记稍后启用它，是操作中常见的疏忽之一。这类错误很难监控，只有在部署过程中改进才能解决这些问题。

让我们看一看在元监控中使用的几种流行方法：

Ping 主机

如果有多个监控应用程序实例在运行，或者有一个备用节点，则可以实施交叉检查，以验证用于监控的主机的可用性。在 AWS 中，可以使用 CloudWatch 监控 EC2 节点的可用性。

监控健康检查

检查监控 UI 的可用性以及监控工具日志文件中的活动，以确保监控系统本身是完全正常运行的，并且它继续在生产环境中监视问题。如果使用了日志聚合工具，跟踪应用程序的日志文件将是检查日志文件中是否有任何活动的最有效方法。通过使用标准关键字，如Error和Exception，同一索引也可以查询潜在的问题。

非核心监控

到目前为止讨论的监控类型构成了核心监控解决方案的组成部分。在综合解决方案中，你会看到大多数这些监控类别。还有一些高度专业化的监控类型，在特定的业务情况下会成为重要组成部分。

安全监控

安全监控是一个庞大的领域，并且有专门的工具可供使用，如SIEM工具。然而，这种情况正在慢慢改变，包括 Datadog 在内的通用监控工具开始提供安全功能，以在市场中保持竞争力。安全监控通常包括以下几个方面：

• 应用系统，包括基础设施，由于其状态变化而导致的脆弱性

• 基础设施组件相对于已知问题的脆弱性

• 监控攻击并捕捉安全漏洞

如您所见，这些目标可能并不完全由我们迄今为止讨论的核心监控概念所涵盖，我们将需要引入一组新的术语和概念来更好地理解这些内容，稍后在书中我们将详细讨论这些内容。

应用性能监控（APM）

正如其名称所示，APM 帮助精细调整应用程序的性能。这是通过改进对应用系统的可观察性来实现的，从而使各个组件的互操作性变得更加明显。尽管这些监控工具最初是作为专用 APM 解决方案推出的，但如今它们已经提供全栈监控，因此也可以用于通用监控。

监控工具概述

在本节中，您将深入了解市场上所有流行的监控工具，帮助您更好地评估 Datadog。

市场上有很多监控工具，从开源、免费软件到许可和基于云的产品应有尽有。尽管许多工具（如 Datadog）是通用应用程序，涵盖我们之前讨论的各种监控类型，但一些工具，如 Splunk 和 AppDynamics，则解决了非常专业的监控问题。

在规划监控解决方案时，DevOps 架构师面临的一个挑战是评估现有工具，以便推出主动监控解决方案。在这方面，正如我们在本书中所看到的，Datadog 凭借其核心监控功能以及提供一些非核心功能（如安全监控）而脱颖而出，是最好的通用监控工具之一。

为了给市场上大量种类繁多的监控工具带来一些结构，它们根据实际运行的位置被分为三大类。其中一些应用程序同时提供本地部署和 SaaS 解决方案。

我们将简要了解除了 Datadog 之外，市场上还有哪些其他监控应用程序。其中一些应用程序与 Datadog 竞争，而其余的则可能是补充解决方案，用于完善推出主动监控所需的工具组合。

本地工具

这一类监控应用程序必须部署在您的基础设施上，与应用系统一起运行。其中一些工具也可能作为 SaaS 提供，我们将在需要时提到这一点。

这里的目标是向新手介绍监控生态系统的全貌，并展示其多样性。

Nagios

Nagios 是一款流行的第一代监控应用，广泛用于监控系统和网络基础设施。Nagios 是通用的开源软件，提供免费和许可版本。它是一款高度灵活的软件，支持通过广泛可用的数百个插件进行扩展。此外，编写插件并部署以满足定制监控需求也相对容易。

Zabbix

Zabbix 是另一款流行的第一代开源免费监控应用。它是类似于 Nagios 的通用监控应用。

TICK Stack

TICK 代表 Telegraf、InfluxDB、Chronograf 和 Kapacitor。这些开源软件组件构成了一个高度分布的监控应用栈，是一款受欢迎的新一代监控平台。与第一代监控工具基本是单体软件不同，下一代平台被分为多个组件，使其更加灵活和高度可扩展。TICK Stack 的核心组件执行以下任务：

• Telegraf：生成度量时间序列数据。

• InfluxDB：存储时间序列监控数据，以便以多种方式进行消费。

• Chronograf：为度量时间序列数据提供 UI。

• Kapacitor：为度量时间序列数据设置监控。

Prometheus

Prometheus 是一款流行的新一代开源监控工具，通过拉取目标系统收集度量值。基本上，监控系统依赖于使用主动检查或拉取方法收集数据，正如我们前面所讨论的。基于 Prometheus 的监控具有以下组件：

• Prometheus 服务器 拉取并存储时间序列监控数据。

• Alertmanager 处理警报并与其他通信平台集成，特别是像 PagerDuty 和 OpsGenie 这样的升级工具。

• Node exporter 是一个代理程序，它查询操作系统的各种度量，并通过 HTTP 暴露它们供其他服务使用。

• Grafana 并非 Prometheus 工具集的一部分，但它是与 Prometheus 一起使用的最流行的数据可视化工具。

ELK Stack

ELK Stack 是目前最流行的日志聚合和索引系统之一。ELK 代表 Elasticsearch、Logstash 和 Kibana。每个组件在栈中的功能如下：

• Elasticsearch：这是搜索和分析引擎。

• Logstash：Logstash 聚合并索引日志以供 Elasticsearch 使用。

• Kibana：这是用户与栈进行交互的 UI 可视化工具。

ELK Stack 组件是开源软件，并提供免费版本。栈的 SaaS 版本也可以通过多个供应商作为许可软件服务提供。

Splunk

Splunk 是在日志聚合类别中开创性的许可软件，具有较大的安装基础。

Zenoss

Zenoss 是类似 Nagios 和 Zabbix 的第一代监控应用。

Cacti

Cacti 是一个第一代监控工具，主要以网络监控而闻名。它的特点包括自动网络发现和网络地图绘制。

Sensu

Sensu 是一个现代监控平台，认识到基础设施在不同层面的动态特性。使用 Sensu，监控需求可以作为代码来实现。这个特点使得它在竞争激烈的监控产品市场中脱颖而出。

Sysdig

Sysdig 平台提供了现代监控系统的标准监控功能。它专注于微服务和安全性，使其成为一个重要的产品值得考虑。

AppDynamics

AppDynamics 主要作为应用性能监控（APM）平台而闻名。然而，它的当前版本也涵盖了标准的监控功能。然而，这类工具通常是作为更通用的监控平台的附加功能。

SaaS 解决方案

大多数新一代监控工具，如 Datadog，主要作为云中的监控服务提供。这意味着监控解决方案的后端托管在云端，但其代理服务必须在本地运行，以收集指标数据并将其发送到后端。有些工具既可以在本地使用，也可以作为云服务提供。

Sumo Logic

Sumo Logic是一个主要用于日志聚合和搜索的 SaaS 服务。然而，其令人印象深刻的安全相关功能也可以用作安全信息与事件管理（SIEM）平台。

New Relic

尽管最初主要作为一个 APM 平台，像 AppDynamics 一样，它也支持标准的监控功能。

Dynatrace

Dynatrace 与 AppDynamics 和 New Relic 一样，也是 APM 领域的主要参与者。除了具有标准的 APM 功能外，它还将自己定位为一个由 AI 驱动的工具，能够关联监控事件并标记异常活动。

Catchpoint

Catchpoint 是一个最终用户体验监控或最后一公里监控解决方案。按设计，这样的服务需要由第三方提供，因为相关的指标必须接近最终用户所在的位置进行测量。

这种类型的监控产品有多个供应商。Apica 和 Pingdom 是该领域的其他知名厂商。

云原生工具

像 AWS、Azure 和 GCP 这样的流行公有云平台提供了大量的服务，监控只是其中之一。实际上，有多个服务可以用于监控目的。例如，AWS 提供 CloudWatch，主要是一个基础设施和平台监控服务，还有像 GuardDuty 这样的服务提供先进的安全监控选项。

尽管 Google Operations 和 Azure Monitor 是功能齐全的监控平台，但云原生监控服务在相关云平台以外的通用监控解决方案中尚未得到广泛应用。

然而，当涉及到监控特定于云的计算、存储或网络服务时，云原生的监控工具可能更为合适。在这种情况下，可以使用主监控平台提供的集成功能，将监控集中到一个地方。

AWS CloudWatch

AWS CloudWatch 提供 AWS 上云服务的基础设施级别监控。它可以作为独立的平台来增强主监控系统，或与主监控系统集成。

Google 操作

这个在 GCP（前称 Stackdriver）上提供的监控服务是一个全栈的、基于 API 的监控平台，同时还提供日志聚合和 APM 特性。

Azure Monitor

Azure Monitor 也是一个全栈的监控平台，类似于 GCP 上的操作。

企业级监控解决方案

尽管它们严格来说不属于用于实施主动监控的监控工具类别，但在大型企业中也使用了其他监控解决方案，以满足如 ITIL 合规性等多样化的需求。为了完整呈现此概述，我们来看看一些相关的解决方案：

• IBM Tivoli Netcool/OMNIbus：一个用于监控大型复杂网络和 IT 域的 SLM 系统，广泛应用于大型 IBM 系统中。

• Oracle Enterprise Manager Grid Control：一款系统管理软件，提供集中化的监控、管理和生命周期管理功能，适用于整个 Oracle IT 基础设施，包括非 Oracle 技术。通常出现在大型 Oracle 硬件和软件系统中。

• HPE Oneview：惠普企业集成的 IT 解决方案，用于系统管理、监控和软件定义基础设施。广泛应用于大型 HP、TANDEM 和 HPE 安装环境中。

总结

本章中，您了解了监控软件系统的重要性及其对业务运营的重要作用。您还了解了各种类型的监控、监控的实际应用案例、市场上流行的监控工具，最重要的是，掌握了所有监控工具中使用的核心监控概念和术语。

本章提供了关于监控概念、工具和市场的全面概述，下一章将专门介绍 Datadog，并提供有关其代理的详细信息，该代理需要安装在您的基础设施上才能开始使用 Datadog。

第二章：部署 Datadog 代理

在上一章中，我们学习了监控工具的基石是帮助检查生产系统健康状况的一组指标。监控工具的主要任务是定期收集度量值作为时间序列数据，并根据为每个指标设置的阈值对问题进行警报。

监控工具常用的收集数据的方法是将代理进程运行在软件应用程序所在的地方，无论是裸金属服务器、虚拟机还是容器。这将使监控代理能够通过查询软件应用程序及其运行的基础设施直接收集度量值。

Datadog 通过多种方式收集这些数据，像其他监控工具一样，它也提供了一个代理。该代理从本地环境收集监控数据，并将其上传到 Datadog 的云端 SaaS 后端。在本章中，我们将学习如何配置 Datadog 代理以在生产环境中运行。

本章将涵盖以下主题：

• 安装 Datadog 代理

• 代理组件

• 作为容器的代理

• 部署代理 – 使用案例

• 高级代理配置

技术要求

要尝试本书中提到的示例，您需要具备以下工具和资源：

• 一个带有 Bash shell 的 Ubuntu 18.04 环境。Datadog 代理可以安装在多种操作系统上，Ubuntu 仅作为示例环境。

• 一个 Datadog 账户和一个具有管理员级别权限的用户。

• Docker

安装 Datadog 代理

Datadog 代理可以通过多种方式进行配置，以便监控基础设施和运行环境中的进程，包括微服务。它可以在主机级别和作为微服务运行，实际配置通常取决于应用软件的部署方式。

运行时配置

有多种方式可以在运行时环境中部署 Datadog 代理来收集事件和数据，这些配置在很大程度上取决于应用程序的部署方式。例如，如果所有应用程序都直接在主机上运行，那么 Datadog 代理也会直接在主机上运行。我们来看一下常见的运行时配置。

Datadog 代理可以在本地以三种不同的方式进行配置，如下图所示。在所有情况下，代理除了收集特定于应用程序的指标外，还会收集基础设施健康状况的数据：

• 作为主机上的服务监控应用进程：在这种情况下，Datadog 代理服务监控一个或多个在同一主机上运行的应用进程或服务：

图 2.1 – Datadog 代理作为主机上的服务监控服务

• 作为宿主机上的服务，监控应用容器：在这种情况下，软件应用作为容器部署在 Docker 宿主机上，Datadog Agent 直接在宿主机上运行，监控容器和应用的健康状况：

图 2.2 – Datadog Agent 作为宿主机上的服务，监控微服务

• 作为 Docker 宿主机上的容器，监控应用容器：在这种配置下，Datadog Agent 和应用程序都作为容器运行在 Docker 宿主机上：

图 2.3 – Datadog Agent 作为微服务，监控其他微服务

真实环境中的配置可能会更复杂，但这些基本配置提供了关于如何部署 Datadog Agent 以收集监控数据的核心思路：

图 2.4 – Datadog Agent 与其 SaaS 后端通信

在这三种配置及其变体中，Datadog Agent 应能通过公司网络和互联网连接到 Datadog SaaS 后端，上传本地收集的指标。因此，配置公司网络防火墙以允许 Datadog Agent 发送流量是其正常运行的前提条件。尽管在大多数环境中，默认允许这种网络访问，但在一些限制性环境中，需要适当配置网络，才能顺利部署 Datadog。

一般来说，如果应用软件以微服务方式部署，最好将 Datadog Agent 也作为微服务进行部署。同样，在非微服务环境下，Datadog Agent 会直接在宿主机上运行。如果将 Agent 部署为微服务，维护任务（如版本升级）会非常简便，这也是在兼容环境中首选的方法。

安装 Agent 的步骤

Datadog 支持多种客户端平台，Agent 可以在这些平台上运行，例如 Windows、Kubernetes、Docker 以及所有流行的 Linux 发行版，如 Ubuntu、CentOS 和 Red Hat Enterprise Linux。作为示例，我们将讨论如何在 Ubuntu 宿主机上安装 Agent。在其他操作系统上，步骤类似，但会根据平台差异做适当调整。

在安装 Agent 之前，您需要注册 Datadog 账户。Datadog 允许您免费试用其大部分功能，试用期为 2 周。获得账户后，您将获得该账户的API 密钥。安装 Agent 时，必须指定 API 密钥，这样 Datadog 的 SaaS 后端就能将 Agent 流量与客户账户相关联。

对于示例步骤，我们将使用 Datadog 代理 7. 旧版本也受支持，特定版本的步骤可以在官方文档中找到。

在 Linux 发行版中，安装步骤只需要执行一个可以从命令行执行的命令。要获取该命令，可以在 Datadog 仪表盘上按照以下步骤操作：

1. 点击集成主菜单，然后选择代理:

   图 2.5 – 获取安装步骤的代理菜单

2. 在左侧面板中，可以选择目标操作系统以查看可以用于在该平台上安装代理的命令：

图 2.6 – 目标平台特定的安装步骤

如你所见，对于 Ubuntu，我们有一个类似这样的命令：

DD_AGENT_MAJOR_VERSION=7 DD_API_KEY=<DATADOG_API_KEY> bash -c "$(curl -L https://s3.amazonaws.com/dd-agent/scripts/install_script.sh)"

基本上，这个命令设置了两个环境变量，分别指向要安装的 Datadog 代理版本和 API 密钥，下载安装脚本并执行它。

将 Datadog 代理直接安装在主机上就是这么简单。稍后我们将看到如何将其部署为容器。

一旦代理成功安装，它将尝试连接到 Datadog 后端。如果代理能够连接到后端，对应的主机将显示在仪表盘的基础设施 | 主机地图和基础设施列表下。这是快速验证代理是否正常工作的一个方法。

在 Linux 平台上，与安装过程相关的日志可在 dd_agent.log 日志文件中找到，该文件位于运行安装脚本的当前目录。如果安装过程失败，它会提供有关出错原因的提示。代理日志文件位于 /var/log/datadog 目录下。

如前所述，安装 Datadog 代理的步骤可以通过导航到集成 | 代理窗口获取。支持的操作系统和平台列在左侧面板中，点击所需的操作系统后，可以获得步骤，如 图 2.6 中的 Ubuntu 所示。

代理组件

Datadog 代理是由多个组件进程组成的服务，每个进程执行特定的任务。让我们详细了解这些组件，以便理解 Datadog 代理的工作原理。

在 Ubuntu 系统上，Datadog 代理服务的名称为datadog-agent。可以像其他服务一样，使用系统命令服务检查和维护此服务的运行状态。

/etc/datadog-agent 目录包含与在该机器上运行的 Datadog 代理相关的所有配置文件。YAML 格式的 /etc/datadog-agent/datadog.yaml 文件是主要的配置文件。如果对该文件进行了任何更改，需要重新启动 Datadog 服务才能使这些更改生效。

/etc/datadog-agent/conf.d/ 目录包含与在该主机上运行的集成相关的配置文件。我们将在第九章《与平台组件集成》中看到集成的配置要求以及如何安装这些集成，本章专门讨论 Datadog 与云平台应用程序的集成。

Datadog Agent 服务主要有三个组件：

• Collector（收集器）：顾名思义，收集器每 15 秒收集一次系统指标。其他类型的指标收集频率可能不同，Datadog 文档提供了相关信息。

• Forwarder（转发器）：本地收集的指标通过 HTTPS 发送到 Datadog 后端。为了优化通信，收集到的指标会先缓存在内存中，然后再发送到后端。

• 默认情况下是 8125。StatsD 是许多监控工具提供的流行接口，用于与外部系统集成。DogStatsD 是 Datadog 提供的 StatsD 实现，并作为 Datadog Agent 的一个组件可用。本书后面将展示如何使用 StatsD 来实现轻量但非常有效的集成。

除了这三个组件外，还可以通过在 datadog.yaml 文件中指定它们来启动可选进程：

• APM agent（APM 代理）：此进程支持 APM 功能，如果使用 APM 功能，则应运行该进程。

• Process agent（进程代理）：为了收集主机上运行的实时进程的详细信息，需要启用 Datadog Agent 的该组件。

• Agent UI：Datadog Agent 还提供了一个 UI 组件，该组件直接运行在 Datadog Agent 所在的主机上。这不是一种常用的选项，主机信息通常通过主仪表板查阅，仪表板能提供对基础设施及其上运行的应用程序的完整洞察。然而，这个 UI 组件可用于临时用途，例如在 macOS 和 Windows 等消费平台上的故障排除。

作为容器的 Agent

如前所述，Datadog Agent 可以作为容器安装在 Docker 主机上。尽管实际选项可能有所不同，以下是一个示例命令，说明如何将 Datadog Agent 作为容器启动：

DOCKER_CONTENT_TRUST=1 docker run -d --name dd-agent -v /var/run/docker.sock:/var/run/docker.sock:ro -v /proc/:/host/proc/:ro -v /sys/fs/cgroup/:/host/sys/fs/cgroup:ro -e DD_API_KEY=<DATADOG_API_KEY> datadog/agent:7 

本示例中，Datadog Agent 7 的 Docker 镜像是从 Docker Hub 拉取的。

当代理安装在主机上时，您已经看到datadog.yaml用于设置配置项。在 Docker 镜像中，这个选项是不可直接使用的。然而，任何自定义更改都可以通过设置相应的环境变量来完成。例如，在这个示例中，api_key通过传递DD_API_KEY环境变量来设置。在 Kubernetes 集群中，Datadog Agent 作为 DaemonSet 安装，该配置确保代理容器部署在集群中的所有节点上。DD_API_KEY被指定为 Kubernetes 密钥。Datadog 提供了多个模板，用于创建 Kubernetes 清单，这些清单可以用于在您的集群中部署 Datadog。kubectl用于配置和部署 Datadog Agent。

部署代理 – 使用案例

在本章开始时，我们探讨了多种运行 Datadog Agent 的运行时配置。在本节中，我们将探索一些实际案例，展示这些选项的应用。

所有主机上

这是一个经典配置，其中 Datadog Agent 和应用软件都直接运行在主机上。主机可以是裸机或虚拟机。每个主机上都会运行一个代理，将事件和度量数据报告到 Datadog 后台。

部署可以使用以下自动化或半自动化方法完成。在实际生产环境中，手动在主机上安装 Datadog Agent 可能不切实际，或者无法扩展：

• Datadog Agent 可以嵌入到用于启动裸机或创建虚拟机的机器镜像中。例如，在 AWS 中，可以在Amazon 机器镜像（AMI）中预安装并预配置代理，以适应目标环境。

• 使用像 Ansible 这样的编排和配置管理工具，在多个机器上并行部署代理，以便操作任务能够扩展。

在公共云环境中，首选的方法始终是使用机器镜像，因为可以通过自动扩展等功能按需启动和关闭主机。在这种情况下，像使用 Ansible 这样的半自动化方法不可行。然而，Ansible 可以用于生成机器镜像和相关的配置任务。

主机上的代理监控容器

直接在主机上运行 Datadog Agent 简单灵活，且在某些操作需求下可能很有意义。Datadog Agent 可以像之前讨论的那样进行部署，但需要额外的配置更改，使代理能够发现并监控在主机上运行的容器。

容器本质上是短暂的，这种动态性也必须在监控中考虑。Datadog Agent 使用自动发现功能来识别和监控容器。

启动监控主机上运行的容器的最简单方法是启用 Docker 集成。尽管在不同的操作系统平台上启用的具体步骤可能略有不同，但以下在 Ubuntu 18.04 上启用的示例提供了所涉及的一般步骤：

1. 在 Datadog UI 中，导航到集成|集成，然后搜索 Docker：

   图 2.7 – 搜索 Docker 集成

2. 在 Docker 图标下，点击安装链接，完成后端的安装步骤。

3. 要获取主机端的配置步骤，即容器运行的地方，请点击 Docker 图标上的配置链接。点击后会打开一个包含所有所需信息的窗口，如下图所示：

图 2.8 – 启用 Docker 集成的步骤

在配置选项卡中提供的步骤会在主机上执行，以完成主机上的容器监控。我们很快就会看到如何执行。通过此集成提供的 Docker 专用指标列在指标选项卡中。

以下是在每个 Docker 主机上执行的步骤：

1. 将用户dd-agent添加到docker操作系统组：

   usermod -a -G docker dd-agent
   

2. 在/etc/datadog-agent/conf.d/docker.d/conf.yaml.example下会有一个示例配置文件。将该文件复制或重命名为conf.yaml，并添加以下设置：

   init_config:
   instances:
       - url: "unix://var/run/docker.sock"
         new_tag_names: true
   

3. 重启 Datadog Agent：

   service datadog-agent restart
   

   要验证 Docker 集成是否在主机上工作，可以从基础设施主菜单中查找容器仪表板，如下图所示：

   

   图 2.9 – Docker 容器的自动发现

   在容器仪表板上，通过在筛选条件字段中输入主机名来搜索特定主机，如前面的截图所示。

4. 启用 Docker 集成后，可以使用以docker.*为前缀的 Docker 专用指标。这些 Docker 指标可以在docker.containers.running指标中查找，当 Docker 集成启用时，用于查找i-021b5a51fbdfe237b主机上正在运行的容器数量。为此，请在图表字段中导航到docker.containers.running，在筛选字段中输入主机名。

   在 Docker 集成页面的指标选项卡下列出了完整的 Docker 专用指标，如下图所示：

   

   图 2.11 – Docker 指标列表

   启用 Docker 集成将只提供 Docker 专用指标。此示例中的特定应用程序 Redis 可能也会发布指标。要启用此功能，您需要执行与我们在启用 Docker 时所见的类似步骤。

5. 在主机上，示例配置文件 /etc/datadog-agent/conf.d/redisdb.d/conf.yaml.example 可以重命名或复制到 /etc/datadog-agent/conf.d/redisdb.d/conf.yaml，然后重启 Datadog Agent 完成配置。

   如果集成成功，你将能够查询到 redis.* 中的相关指标。

   如果某些步骤失败，无法通过前述方法直接验证主机上集成的启用情况。检查这一点的一种方式是通过运行以下命令查看 Datadog Agent 状态的输出：

   sudo datadog-agent status 
   

6. 在输出中，查找相关的集成。在本示例中，我们查看了 Docker 和 Redis，输出中会提到这些内容：

   docker
       ------
         Instance ID: docker [OK]
         Configuration Source: file:/etc/datadog-agent/conf.d/docker.d/conf.yaml
         Total Runs: 1
         Metric Samples: Last Run: 21, Total: 21
         Events: Last Run: 0, Total: 0
         Service Checks: Last Run: 1, Total: 1
         Average Execution Time : 63ms
         Last Execution Date : 2020-08-28 07:52:01.000000 UTC
         Last Successful Execution Date : 2020-08-28 07:52:01.000000 UTC
       redisdb (3.0.0)
       ---------------
         Instance ID: redisdb:fbcb8b58205c97ee [OK]
         Configuration Source: file:/etc/datadog-agent/conf.d/redisdb.d/conf.yaml
         Total Runs: 1
         Metric Samples: Last Run: 33, Total: 33
         Events: Last Run: 0, Total: 0
         Service Checks: Last Run: 1, Total: 1
         Average Execution Time : 91ms
         Last Execution Date : 2020-08-28 07:52:08.000000 UTC
         Last Successful Execution Date : 2020-08-28 07:52:08.000000 UTC
         metadata:
           version.major: 2
           version.minor: 8
           version.patch: 23
           version.raw: 2.8.23
           version.scheme: semver
   

如果出现问题，你会在相关部分看到错误信息。

部署策略包括将 Datadog Agent 和与你的环境相关的配置文件集成到机器镜像中，例如 AWS 中的 AMI。为了将来自主机上运行的容器的所有相关指标发布到 Datadog，需要一个定制的 Datadog Agent 配置文件和与各种集成相关的配置文件，类似于我们在示例中看到的配置。

作为容器运行的代理

这是在软件应用程序部署为容器时运行代理的首选配置。代理可以作为容器部署在 Docker 主机上，或作为服务部署在 Kubernetes 集群中。我们之前讨论过这些场景中的代理部署方式。

由于 Datadog Agent 是以容器形式部署的，因此不需要将其包含在用于启动 Docker 节点的机器镜像中。这提供了操作灵活性，因为在推出或升级使用的 Datadog Agent 时，无需更新机器镜像。

高级代理配置

主 Datadog 代理配置文件 datadog.yaml 可以根据你的具体监控需求进行更新。默认情况下，文件中只设置了 api_key。在实际环境中使用的 datadog.yaml 文件会有更多的配置选项。

接下来我们将介绍一些通常用于微调监控基础设施的重要配置项：

• proxy：如果出站流量需要通过代理访问互联网，则需要配置此选项。支持 http、https 和 no_proxy 的典型代理设置。

• hostname：如果需要使用特定的主机名进行报告，可以通过此选项进行设置。默认情况下，主机名是通过操作系统级别的工具自动检测的。

• tags：一个非常重要的选项，始终用于标记代理报告的指标。可以指定多个键值对。

• collect_ec2_tags：启用此选项后，可以将 AWS EC2 节点标签作为主机标签收集。

• config_providers：要启用来自特定 Docker 镜像的容器自动发现，必须在此提供相关的配置。

• docker_labels_as_tags和docker_env_as_tags：这些配置项可用于提取 Docker 标签和环境变量，并将其作为与相关容器收集的指标的标签。

  使用kubernetes_pod_labels_as_tags和kubernetes_pod_annotations_as_tags，Kubernetes 也可以提供类似的标签选项。

最佳实践

正如你所看到的，安装和配置 Datadog Agent 有多种方式，对于初次接触 Datadog 的人来说，可能会感到不知所措，不知道如何高效地部署和调优 Agent 以满足监控需求。然而，有一些明显的最佳实践，我们在这里总结如下：

• 如果 Agent 安装在主机上，计划将其包含在用于启动或启动主机的机器镜像中。

• 设置 Ansible 剧本或类似工具，以便对主机上的 Datadog Agent 进行临时更改。对于一些复杂的基础设施环境，尤其是在使用裸金属服务器的情况下，不推荐这种做法，因此可能需要进行一些现场更改。

• 当需要监控容器时，计划将 Agent 也作为容器进行部署。

• 计划通过适当配置 Agent，收集来自底层基础设施组件（如 Docker 和 Kubernetes）的标签。

概述

Datadog Agent 可以用于监控构建在各种云平台和操作系统上的经典环境和基于微服务的环境。为了将监控指标收集并发布到其 SaaS 后台，必须在本地环境中运行 Agent。Agent 可以直接在主机机器上运行，也可以作为 Docker 主机上的容器运行，或者作为微服务编排框架（如 Kubernetes）中的服务运行。本章介绍了部署 Datadog Agent 的各种配置选项及典型使用案例。

在下一章，我们将查看 Datadog UI 的关键特性。尽管大多数更改可以通过 API 完成，但 Datadog UI 是一个便捷的工具，既适用于用户，也适用于管理员，帮助他们查看 Datadog 的后台，特别是自定义仪表板，它提供了对基础设施和应用软件系统状态的可视化洞察。

第三章：Datadog 仪表盘

在上一章中，我们了解了 Datadog 代理如何将监控指标上传到 Datadog 的 SaaS 后端。Datadog 仪表盘提供了一个极好的数据视图，可以通过常见的网页浏览器访问。管理员使用仪表盘执行多种任务 —— 管理用户账户及其权限、创建操作仪表盘、启用集成以及创建监控是常见的例子。仪表盘还提供了一个聊天窗口，供用户联系客户支持。

虽然仪表盘具有许多功能，但其中有些比其他的更重要，我们将在本章中详细研究这些功能。这些是重要的仪表盘功能：

• 基础设施列表

• 事件

• 指标浏览器

• 仪表盘

• 集成

• 监控

• 高级功能

技术要求

为了尝试本书中提到的示例，您需要拥有以下工具和资源：

• 一个运行 Ubuntu 18.04 环境并使用 Bash shell。示例也可能在其他 Linux 发行版上工作，但必须对 Ubuntu 特定的命令做适当的修改。

• 一个 Datadog 账户和具有管理员级别权限的用户。

• 一个 Datadog Agent 在主机级别或作为微服务运行，具体取决于示例，指向 Datadog 账户。

基础设施列表

一旦在主机上启动并运行代理，代理便开始向云端的 Datadog 后端报告。只要代理与后端之间的通信成功建立，主机将被添加到基础设施列表中。

基础设施列表位于 基础设施 主菜单下。最重要的包括 主机地图 和 基础设施列表：

图 3.1 – 基础设施菜单选项

主机地图 菜单中的每个块代表一个代理正在运行的主机。在以下截图中，绿色表示代理正在运行并能够与后端通信。橙色表示通信出现问题；然而，它也表明在过去的某个时刻，相关的代理曾经能够连接到后端：

图 3.2 – 一个主机地图示例

通过点击特定块，您可以查看相关主机的监控详情，例如主机名、在主机级别定义的标签、各种系统级别信息以及正在监控的服务列表，如以下截图所示：

图 3.3 – 主机地图中的主机详情

这个主机级别的深入功能可以查看各种系统信息，避免了登录到主机去查看这些细节。

如下图所示，此界面上有链接可以带你到不同的主机特定仪表板。例如，仪表板链接将打开一个仪表板，在该仪表板中你可以查看各种基础设施指标，如 CPU 使用率、负载平均值和磁盘使用情况。

基础设施列表提供主机的表格视图，如下图所示：

图 3.4 – 基础设施列表示例

该界面是主机列表的另一种视图，在提供特定主机监控信息方面，与主机地图没有太大区别。

你可以在基础设施菜单下查看更多选项，如容器和进程。顾名思义，可以在各自的仪表板中列出和搜索相关的运行时资源。

事件

大多数监控工具只专注于收集和报告时间序列指标数据。而 Datadog 除了报告这些数据，还会报告事件，这是其吸引人的特点之一。这些事件是系统级事件，例如 Datadog 代理的重启和新容器的部署：

图 3.5 – 事件仪表板示例

可以通过 Datadog UI 中的事件主菜单选项访问事件仪表板。使用此仪表板，你可以直接向事件流添加更新，也可以对已经发布的事件进行评论。这个灵感来自社交媒体的功能在需要与远程团队沟通或澄清一些系统维护生成的事件时非常有用。

仪表板上列出的事件可以通过多种选项进行过滤，包括搜索。此外，还有一个聚合相关事件的选项，这在简化事件列表时非常有用。

事件是主要菜单选项之一，使用它可以访问仪表板。

指标浏览器

通过指标浏览器仪表板，可以查看和搜索 Datadog 收集的指标，仪表板可以通过主指标菜单访问：

图 3.6 – 指标菜单选项

一旦在主机上运行的代理与 Datadog 后端连接，你就可以开始查看监控基础设施的各种指标。此功能是开箱即用的，无需特别配置：

图 3.7 – 使用指标浏览器查看主机的可用内存

基础设施的指标名称以system为前缀，Datadog 文档中列出了开箱即用的所有可用指标的完整列表。

在度量探索器仪表板中，度量名称在图表字段中指定。系统有一个自动搜索功能，会根据你输入的文本字符串拉取可能的度量名称。可以在此字段中指定多个度量。

在 host 中，指向主机名。通过添加 tags 条目到 Datadog 代理配置文件中，可以非常轻松地为度量添加标签。

作为 Datadog 用户，你将定期使用度量探索器，原因如下：

• 查找与特定基础设施资源或应用程序相关的度量时间序列数据。

• 除了查找度量数据，还可以为相关数据创建图表，以添加自定义仪表板。

• 故障排除问题涉及发布自定义度量和标签。如果这些自定义功能有效，那么通过该仪表板查询自定义度量和标签并验证其可用性将变得容易。

仪表板

Datadog 仪表板是一个可视化工具，用于跟踪和分析度量。它提供了一整套丰富的功能，可以用来构建自定义仪表板，除此之外，还可以使用现成的仪表板。

仪表板主菜单选项包含两个选项：仪表板列表和新建仪表板：

图 3.8 – 仪表板主菜单选项

仪表板列表菜单将列出所有按各种类别分组的仪表板。

在 Datadog 中可以创建两种类型的自定义仪表板：Timeboards 和 Screenboards：

图 3.9 – Datadog 仪表板类型

Timeboard 类型仪表板中的图表将共享相同的时间框架，因此它对于并排比较多个度量非常有用。此功能使得Timeboard类型仪表板在故障排除时非常有用。Screenboard仪表板没有时间限制，可以将不同的对象组合在一起。从这个意义上来说，Screenboard类型仪表板更适合用于构建传统的监控仪表板。

现在，让我们来看一下如何创建Timeboard类型的仪表板，以便解释仪表板的创建过程。

第一步是设置仪表板的名称和类型，如前图所示。

在下一步中，你应该会看到添加图表选项。点击它后，你将获得添加不同类型小部件的选项，如下图所示：

图 3.10 – Screenboard 类型仪表板的小部件

你需要的仪表板小部件可以从前面的列表中拖动到下方的仪表板区域。对于我们的示例仪表板，我们将使用一个时间序列小部件，这对于构建带有时间序列度量的仪表板非常有用。

在示例仪表板中，已为特定主机的 system.cpu.user 和 system.disk.free 指标添加了两个图表。

有几个选项可以帮助缩小您想要为图表实现的功能范围。在以下截图所示的图表中，可以选择任何可用的指标来绘制图表，并可以使用 Graph your data | from 下拉菜单中的选项进行过滤。在此示例中，已选择 system.cpu.user 指标，并将其过滤到单个 i-021b5a51fbdfe237b 主机：

图 3.11 – 配置仪表板图表

如前所述，有几个选项可以帮助创建仪表板小部件。如果在您的组织中设置监控仪表板是一个重要需求，并且每个可能的选项都有文档可供参考，那么这是您需要通过实践掌握的领域。

以下截图显示了示例仪表板上的两个图表。同样，您可以创建更多图表，使其成为针对特定用途的完整仪表板。在这种情况下，仪表板上显示的是 system.cpu.user 和 system.disk.free 系统指标的时间序列图：

图 3.12 – 示例仪表板上的图表

每个这样的图表都可以使用 Graph your data | Share 选项共享并嵌入到 Datadog UI 之外，如图 3.11所示。点击此选项后，您将获得如下图所示的共享选项：

图 3.13 – 共享图表

共享图表的配置选项不言自明。基本上，它将生成一个可以用来将图表嵌入网页的 JSON 代码片段。

主要集成菜单

集成主菜单选项下列出的选项很重要，您将经常使用它们：

图 3.14 – 集成主菜单选项

现在，让我们看看在主菜单项集成下可以使用的选项。

集成

如下图所示，在此标签下，Datadog 与第三方工具的集成已开箱即用，可以查看并进行搜索：

图 3.15 – NGINX 集成

例如，前面截图中显示的 NGINX 集成可以从仪表板安装。这只会在 Datadog 后端启用您的帐户集成。通常，基础设施方面需要完成额外的步骤，这些步骤将在仪表板中提供，如下图所示：

图 3.16 – NGINX 集成 – 配置

此外，该界面提供了通过此集成将可用的指标列表。以下截图展示了 NGINX 集成将发布的指标：

图 3.17 – NGINX 集成 – 指标

在运行 NGINX 的主机上，可以执行在基础设施端启用集成的步骤。完成所有集成设置要求后，特定于 NGINX 的前述指标将在这些机器中的每一台上可用，并且这些指标可以用于构建仪表板和监控。

APIs

在 集成 仪表板上的 APIs 标签下，您可以找到所有与 Datadog 集成应用所需的资源。Datadog 提供 API 和网关，以程序化方式与其后端进行交互，成熟的监控系统将利用这些选项与 Datadog 集成，以便添加可能无法开箱即用的自定义指标和功能：

图 3.18 – 集成访问资源

以下是可以用来以客户端身份程序化访问 Datadog 后端的主要资源：

• API 密钥：如您在上一章 Datadog 代理 中所看到的，API 密钥是将代理与您的账户相关联的信息，它是一个必须在 Datadog 代理配置文件中设置的配置项。

• 应用密钥：在执行 API 操作（如发布事件或指标）之前，脚本或应用程序需要通过 Datadog 后端进行身份验证。身份验证需要一个 API 密钥-应用密钥对，可以通过仪表板生成。

• 事件 API 邮件：这是一个邮件网关，事件可以发布到您的账户并显示在 事件 仪表板上。

• 客户端令牌：客户端令牌用于在 真实用户监控 (RUM) 设置中发布事件和传输来自 Web 或移动应用的日志。

代理

在 代理 标签下，您可以找到安装 Datadog 代理所需的所有信息，适用于目标平台。通常，页面上会提供安装代理的命令行。

嵌入

我们已经在 仪表板 部分了解了如何创建和共享一个新的仪表板。该仪表板可以通过相关的 JSON 代码嵌入到网页中。通过此选项，共享的仪表板可以按如下方式列出：

图 3.19 – 集成菜单中的嵌入选项

此外，可以使用 撤销 按钮从任何仪表板中撤销共享选项，如前面的截图所示。

我们已经查看了与集成相关的各种菜单选项。接下来，让我们探索监控选项。

监控

我们已经在第一章，“监控简介”中讨论了监控的基本概念。Datadog 提供了一个高级的监控实现，具有各种功能。监控可以通过仪表盘手动创建和维护。以下截图提供了该菜单项下的可用选项列表：

图 3.20 – 监控主菜单选项

我们将在第八章，“监控与警报”中更详细地讨论监控。在这里，我们将简要介绍可用的重要菜单选项：

• 管理监控：在此选项卡下，列出了所有可用的监控，用户可以从该列表中选择监控进行更新。

• 触发的监控：本质上，阈值设置在某个指标上，以定义监控，并且当阈值值达到时会触发。在此菜单下，列出了这些触发事件的列表。

• 新建监控：可以通过遵循此处提供的工作流程手动创建新的监控。尽管监控通常与指标相关，但 Datadog 提供了各种监控。我们将在第八章，“监控与警报”中更详细地讨论这一点。然而，在接下来的部分中，我们将学习如何设置一个简单的监控，帮助你了解基本概念。

• 管理停机时间：在停机窗口期间，即使监控达到阈值，也不会触发监控。停机的经典用途是在某些维护或部署活动期间静默监控。在此选项卡下，可以安排停机时间。

创建新的指标监控

在 Datadog 中，你可以设置多种监控，我们将在第八章，“监控与警报”中详细讲解所有内容。在这里，我们将学习如何创建一个基于指标的监控，这是最常见的一种监控。

从 Datadog UI 中选择监控 | 新建监控。选择指标作为选择监控类型选项。你将看到一个表单，用于配置新监控，以下截图展示了该表单（请注意，该表单未完全提供）：

图 3.21 – 配置新监控

本质上，示例监控跟踪的是/dev/xvda1存储设备上的可用空闲磁盘空间，该设备是i-021b5a51fbdfe237b主机的根分区。当空闲磁盘空间达到 1 GB 时，它将发送警告消息；当空闲空间降至 0.5 GB 时，它将发送严重警告消息。这些警报被配置为发送到一个电子邮件地址。

要完成此操作，请执行以下步骤：

1. 在选择检测方法下，选择阈值警报。

2. 在定义度量下，选择system.disk.free作为度量，并在from字段中选择所需的主机和设备。

3. 在设置警报条件下，可以指定警报阈值和警告阈值。配置这些阈值，当度量值低于阈值时触发警报。

4. 在说明发生了什么下，你可以提供警报消息的模板，当度量值达到任意阈值时，系统会发送该消息。

5. 在通知你的团队字段中，可以指定警报接收人的电子邮件地址。

我们已经浏览了你可以在 Datadog UI 中使用的所有常见选项。界面提供了更多选项，可以使用 Datadog 提供的所有功能。在接下来的部分，我们还将简要介绍你可以通过 Datadog UI 访问的高级功能。

高级功能

在 Datadog 仪表板中有比我们到目前为止看到的更多菜单选项。不过，这些是你将定期使用的核心功能，特别是如果你是负责维护 Datadog 帐户的 DevOps 工程师。让我们来看一下其中的一些，并了解每个选项具体涵盖的内容：

• Watchdog：Watchdog 是一种算法特性，它查看可用的度量数据，寻找任何不规则的模式。可以使用此选项创建监控器，提醒你注意这些异常。

• 应用性能监控（APM）：APM 是一个附加功能，如果您的帐户有相应许可证，则可以使用此功能。

• 笔记本：笔记本是一个按时间顺序收集的文本和图表集合。它用于记录具有高度可视化数据的特定问题，以图表形式呈现。

• 日志：此选项提供了访问附加功能日志管理的权限。

• 安全：可以从此菜单访问安全监控选项。我们将在第十四章中更详细地讨论此内容，其他监控话题。

• 用户体验监控：合成测试允许你以模拟的方式监控用户体验（UX）。此监控选项允许你通过不同的方法来监控用户体验。我们将在第十三章中讨论此功能，使用 Datadog 管理日志。

• 真实用户监控：RUM通过应用程序中嵌入的探针直接衡量实际的用户体验。这是一种我们在第一章中讨论过的最后一公里监控类型，监控简介。我们已经查看了与 Datadog 重要功能相关的 Datadog 仪表盘上可用的关键菜单选项。熟悉这些菜单选项非常重要，因为仪表盘是用户将定期用来与 Datadog 应用程序交互的主要界面。

总结

在本章中，我们查看了 Datadog 仪表盘菜单选项，这些选项是用户与 Datadog 后台交互的核心。仪表盘上有许多可用的功能，如监控的创建和维护，可以实现自动化。然而，Datadog 的仪表盘功能是业内最好的之一，创建自定义的运营和管理报告仪表盘非常简单。我们在这里讨论的功能可以由 Datadog 用户，尤其是管理员，定期使用。

在下一章，我们将学习如何管理您的 Datadog 账户。同样，仪表盘是管理员用于此目的的主要界面。

第四章：账户管理

在上一章中，我们介绍了 Datadog 用户界面的主要功能。账户管理功能也是用户界面的一部分，但由于账户管理是管理性质的功能，并不是所有 Datadog 用户都会访问这些功能，因此需要单独讨论。

Datadog 支持单点登录（SSO），并提供基于密钥的 API 支持。它还支持在客户账户中创建多个组织，用于构建隔离的监控环境，有时是为了满足分离开发和生产账户的合规要求，或隔离由 SaaS 提供商托管的客户端账户。

当创建用户时，可以首先通过使用现成的默认角色来设置该用户的权限，也可以通过管理员设置的自定义角色来精细设置。在 Datadog 账户中，可以创建多个组织来分组或划分需要监控的环境。虽然 Datadog 提供了本地身份验证系统供用户登录，但它也支持 SSO。可以为 Datadog 用户创建 API 和应用程序密钥对，并且密钥对可以用于以编程方式访问 Datadog。

本章涵盖了在 Datadog UI 上提供的所有账户管理功能，具体包括以下内容：

• 管理用户

• 使用角色授予自定义访问权限

• 设置组织

• 实现单点登录（SSO）

• 管理 API 和应用程序密钥

• 跟踪使用情况

技术要求

本章没有技术要求。

管理用户

在 Datadog 部署到一个主要涉及部署代理的环境中后，用户可以获得对 Datadog 接口的访问，这些接口提供有关基础设施和应用软件系统的洞察。虽然用户可以通过 API 访问 Datadog，但他们主要通过 UI 来查看可用的信息。

用户可以通过电子邮件发送邀请来添加，可以通过 Datadog 仪表板的主菜单项团队完成此操作。

以下截图是一个团队窗口的示例：

图 4.1– 主菜单团队窗口

用户可以通过团队窗口底部提供的表单进行邀请，如下所示：

图 4.2 – 团队窗口中的邀请用户表单

此外，还可以通过在团队窗口中使用邀请用户选项来完成：

图 4.3 – 邀请用户对话框

当邀请用户加入团队时，必须为该用户分配一个或多个角色。

这是可用的角色：

• Datadog 管理员角色：顾名思义，具有此角色的用户是管理员，用户可以管理其他用户，并访问账单信息。

• Datadog 标准角色：拥有此角色的用户可以完全访问 Datadog 的各种功能。

• Datadog 只读角色：顾名思义，拥有此角色的用户可以仅以只读方式访问各种功能。通常，这种访问权限会分配给许多 Datadog 组织中的用户，这些用户负责覆盖生产环境。

正如你在本节中所看到的，用户的访问权限可以通过一个或多个预定义角色进行授予。如果预定义角色无法满足访问控制需求，可以通过角色更精细地定义用户访问权限。接下来我们将展示如何实现这一点。

使用角色授予自定义访问权限

每个角色都会授予用户一组权限，具体如下截图所示：

图 4.4 – 标准用户角色中的权限

虽然在大多数访问管理用例中，分配一个或多个预定义角色可能已经足够，但用户可以通过自定义角色分配更具体的权限。

自定义角色可以由管理员设置，并在此之后分配给用户。

以下是创建自定义角色时需要遵循的几个步骤：

1. 进入仪表盘上的角色页面（直接链接：app.datadoghq.com/access/roles）。

2. 在页面的右上角，点击新建角色链接：

   图 4.5 – 创建新的自定义角色

3. 在名称字段中输入角色名称，从权限表格中选择要添加到角色的权限，然后点击保存按钮创建角色。

   重要说明

   现有的自定义角色也可以按照类似的步骤进行更新。

在本节中，我们已经看到如果预定义角色无法满足访问控制需求，可以通过自定义角色精细地定义用户访问权限。资源和用户可以在 Datadog 账户下按组织分组，接下来我们将展示如何配置这一点。

设置组织

在同一个 Datadog 账户中，可以设置多个组织。此多组织功能默认未启用，您必须向客户支持请求启用。多个子组织在需要为部分基础设施和其上运行的应用程序进行隔离监控时非常有用：

• 开发和生产的专用环境：在访问监控信息时，涵盖生产和非生产环境的信息在访问者和所需权限上可能非常不同。监控的重点通常是跟踪生产中的系统，并且相关信息的访问权限受到严格控制。尽管可以使用角色来细致控制访问，但一个简单且安全的方式是将监控划分为多个组织。

• 为客户提供专用监控：为了满足隐私合规要求，监控基础设施可能需要被隔离。如果有此需求，并且应用系统运行在托管基础设施上，则托管服务提供商应为托管基础设施及其上运行的软件系统提供专用监控。多组织功能提供了逻辑上的监控隔离，可以用来在同一个由托管供应商管理的 Datadog 帐户下，为每个客户推出专用监控。

一个组织可以与子域绑定，以便更好地识别。你需要通过客户支持启用此功能。一旦启用，你可以通过特定的 URL 访问一个组织，例如prod.datadoghq.com。在这种情况下，子域“prod”指向一个组织。

现在，让我们看看如何设置一个组织：

1. 在客户支持启用多组织功能后，你将能够看到新组织功能，如下图所示：

   图 4.6 – 新组织选项已启用

2. 点击选项生产环境，以便使用这个新组织监控所有与生产相关的资源：

   图 4.7 – 创建新组织

3. Datadog UI 将在创建新组织时切换到该组织。你可以通过点击切换组织部分下的相应标签，来在组织间切换，如下图所示：

图 4.8 – 切换组织

当前活动的组织会显示在同一菜单的顶部。

如果用户是 Datadog 帐户中多个组织的成员，则该用户可以在 Datadog 仪表板上切换不同的组织。

对于许多公司来说，SSO是满足公司或安全合规要求的必要条件。Datadog 支持多种 SSO 方法和提供商，我们将在接下来的部分详细介绍。

实施单点登录（SSO）

和其他流行的 SaaS 应用一样，Datadog 也可以设置为使用 SSO，允许用户使用第三方平台（如 Google）或内部认证平台（如Active Directory或轻量级目录访问协议（LDAP））的现有凭据登录 Datadog UI。

Datadog 使用安全声明标记语言（SAML）来实施 SSO 的第三方身份验证。

让我们看一下 Datadog 提供的几个关键单点登录功能：

• 可以使用行业标准的身份验证平台和提供商来实施 SSO，如 Active Directory、LDAP、Google、AuthO和Okta。

• 通过将 SAML 属性映射到 Datadog 用户角色，认证用户可以被授予相应的权限。

• Datadog 支持 Just-in-Time 用户预配，避免需要预先创建用户的要求。用户在首次登录时将被创建。可以为 JIT 用户设置默认用户角色，并根据此设置设置新用户的权限。

尽管细节可能有所不同，基于 SAML 的 SSO 设置通常需要以下通用步骤：

1. 在第三方端设置第三方 SSO 提供者作为 SAML 身份提供者（IdP）。完成此设置后，下载 IdP 元数据文件。

2. 使用配置 SAML 菜单选项在 Datadog UI 上，主要通过上传上一步创建的 IdP 元数据来配置 SSO：

   图 4.9 – 配置 SAML 菜单选项

3. 如果需要，从第三方应用启用 Datadog 的 SAML 认证。

4. 根据以下用户登录工作流之一验证认证设置：

   Identity Provider (IdP)-initiated: 在这种情况下，登录由身份提供者即第三方平台发起。选择此选项后，Datadog 用户可以通过第三方提供的仪表板发起登录流程，用户已经登录到第三方平台。

   Service Provider (SP)-initiated: Datadog 用户将使用 Datadog URL，如 app.datadoghq.com/account/login 来启动登录流程，这将将用户带到第三方平台进行身份验证。

现在让我们看看如何使用 Google 作为 IdP 提供者配置 SSO：

1. Google 提供了生成 Datadog IdP 元数据的步骤。请按照 Google 管理应用中提供的步骤support.google.com/a/answer/7553768生成并下载 IdP 元数据文件。

2. 在 Datadog UI 中，从配置 SAML 页面上传 IdP 元数据文件，如下截屏所示：

   图 4.10 – 上传 IdP 元数据文件

3. 一旦上传并加载了 IdP 元数据文件，点击启用按钮以启用 SAML，如下截屏所示：

   图 4.11 – 启用单点登录

4. 如果在上一步成功启用，您将看到可以用来登录 Datadog 的单点登录 URL。如果尚未登录，该链接将首先带您到 SAML 提供者，然后重定向到 Datadog UI。

5. 为了使上述工作流成功，用户需要事先在 Datadog 中设置好。Datadog 提供了一种名为即时配置（Just-in-Time Provisioning）的选项，本质上是从白名单域创建用户。这样可以避免在 Datadog 中显式配置用户的要求。配置可以通过以下截图进行：

图 4.12 – 即时配置（Just-in-Time Provisioning）

在前面的示例中，kurianinc.us是被列入白名单的域。任何使用该域并由 SSO 提供商认证的用户，都可以访问 Datadog，而无需事先在 Datadog 中创建该用户。该用户将在首次成功登录时创建。

与 Datadog 用户关联的密钥对跟踪该用户的所有帐户和访问信息，是通过编程方式访问 Datadog 的重要资源。让我们在接下来的部分中看看这些密钥对是如何管理和使用的。

管理 API 和应用程序密钥

当用户使用自己的凭证或 SSO 平台进行身份验证登录 Datadog UI 时，密钥对用于程序化访问场景中的身份验证，例如从程序发布指标或使用 Terraform 配置 Datadog 资源。在这两种情况下，过程独立于 Datadog 环境运行，并且必须进行身份验证。

API 密钥与组织相关联，应用程序密钥与用户帐户相关联。

密钥可以从集成 | API页面进行设置：

图 4.13 – API 页面

一旦密钥对可用，就可以在以下 Python 代码片段中看到如何进行身份验证：

from datadog import initialize, api
options = {
    'api_key': '<DD_API_KEY>',
    'app_key': '<DD_APPLICATION_KEY>'
}
initialize(**options)

还有其他不太常用的选项可以间接访问 Datadog 以获取信息和发布指标：

• @dtdg.co电子邮件帐户，用于通过发送电子邮件发布事件。

• 客户端令牌：客户端令牌用于对 Web 和移动应用进行仪表化，以便它们将日志和事件发送到 Datadog 后台。这主要用于衡量最后一公里的用户体验。

Datadog 提供了多种选项来跟踪您对 Datadog 服务的使用情况，让我们在下一部分中看看与此相关的重要功能。

使用情况跟踪

与其他 SaaS 服务一样，Datadog 的使用通常具有弹性，因为它通常部署在公共云中的基础设施上。

重要提示

请注意，Datadog 也可以在传统的裸金属环境中部署，但这种使用案例正在变得越来越少见。

由于计费与按需使用挂钩，因此管理员跟踪使用模式非常重要：

1. 使用计划与使用菜单选项，在您的用户资料下查看您订阅的计划的详细信息，以及 Datadog 作为服务的使用情况，如下图所示：

   图 4.14 – 计划与使用菜单

2. 点击计划与使用选项，你可以进入主页面，在此页面中查看和更新订阅计划、使用情况、账单和组织的详细信息。查看该页面上所有可用选项的截图如下：

   图 4.15 – 计划与使用页面，包含计划的详细信息

3. 在使用标签下，可以查看 Datadog 使用情况的详细信息，如下图所示：

   图 4.16 – 计划与使用页面上的使用标签

   从此页面，你可以查看 Datadog 在特定时间段内监控了多少台机器，这与账单有关系。此外，你还可以了解 Datadog 监控了多少个容器：

   • 在账单历史标签下，顾名思义，可以查看和下载账单历史及相关收据。

   • 在Multi-Org标签下，你可以查看汇总的使用情况和相关趋势。如果你将 Datadog 的使用分割到多个组织中，这将非常有用。例如，如果你导航到Multi-Org 使用 | 长期趋势，你可以看到如以下截图所示的各种使用情况：

图 4.17 – Multi-Org 标签下的整体使用趋势图表

1. 在Multi-Org 使用 | 月度使用情况标签下，你还可以查看按组织分类的逐项使用概况，如下图所示：

图 4.18 – 单个组织使用概况

我们已经查看了多个用于管理公司 Datadog 帐户及其 Datadog 用户的功能和选项，现在让我们来看一下管理 Datadog 帐户的最佳实践。

最佳实践

以下是一些与管理帐户和用户相关的最佳实践：

• 考虑为隔离生产监控与非生产基础设施上的监控、以及开发和测试新监控功能的各种监控环境而创建多个组织。这样可以保持生产监控的整洁与安全，防止任何意外的修改。

• 为生产监控创建自定义用户角色。使用预定义的用户角色可能会赋予用户比所需更多的权限。始终使用最小权限策略，并记住，监控通常是只读的，除非实现了自动问题解决。

• 为 Datadog 用户推出 SSO（单点登录）功能。

• 使用通过服务账户进行身份验证的主要程序访问，而不是通过真实用户进行身份验证，因为真实用户可能离开公司，删除用户密钥可能会破坏你的程序。

概览

账户和用户管理是一项管理任务，普通用户通常不会涉及，除非是执行诸如创建应用密钥之类的任务。多组织功能可以用于将账户划分为逻辑单元，我们查看了这些功能在不同场景下的应用。Datadog 支持使用 SAML 的行业标准 SSO 选项，我们学习了如何实现这些选项。有多种方法可用于编程访问，主要机制是使用密钥对，我们介绍了生成密钥对的步骤。可以通过自定义用户角色来实现对 Datadog 的细粒度访问，我们也学习了如何为用户配置这些角色的步骤。

这是本书第一部分的最后一章，概述了监控的一般情况，并特别介绍了 Datadog 以及如何开始使用它。在本书的后续部分和章节中，我们将详细讨论 Datadog 中监控功能的实现和使用。在下一章中，我们将进一步了解指标、事件和标签——Datadog 依赖的三个重要概念。

第五章：指标、事件和标签

在本书的第一部分，我们讨论了一般的监控概念以及如何开始使用 Datadog，包括安装 Agent 和浏览 Datadog UI 的主菜单选项，Datadog UI 是终端用户可用的主要界面。在第一章中，我们还讨论了作为所有现代监控应用程序中的核心概念的指标，指标用于衡量软件系统的健康状况和状态。此外，我们还讨论了标签作为一种分组和过滤指标数据及其他监控信息（如 Datadog 生成的事件）的手段。

在本章中，我们将详细探讨 Datadog heavily 依赖的两个重要构件——指标和标签的实现方式。指标是用于报告 Datadog 中监控信息的基本实体。Datadog 还使用标签来组织指标和其他类型的监控信息，如事件和警报。讨论指标和标签是非常重要的，因为对指标进行适当的标签化对于从典型 Datadog 账户中可用的大量指标时间序列数据中提取有意义的信息至关重要。

虽然指标是任何监控系统中的核心概念，帮助持续衡量系统的健康状况，但事件捕获的是系统中发生的某个事件。进程崩溃、服务重启和容器重新分配都是系统事件的例子。指标是在特定时间间隔内进行测量的，并且与其相关联的是一个数值，而事件本质上不是周期性的，仅提供状态信息。标签可以用于组织、分组和仅搜索与指标一起使用的事件。

在本章中，我们将详细讨论指标、事件和标签。具体来说，我们将涵盖以下主题：

• 理解 Datadog 中的指标

• 标记 Datadog 资源

• 定义自定义指标

• 监控事件流

• 搜索事件

• 事件通知

• 生成事件

• 最佳实践

技术要求

要尝试本书中提到的示例，您需要具备以下工具和资源：

• 一个 Datadog 账户和具有管理员级别权限的用户。

• 一个运行在主机级别或作为微服务的 Datadog Agent，具体取决于示例，指向 Datadog 账户。

理解 Datadog 中的指标

软件系统及其运行的基础设施的健康状况由一组指标及其阈值定义。例如，在基础设施层面，如果机器上的 CPU 使用率低于70%，则对于特定用例可能被视为健康。当所有用于监控环境的指标报告的值都在正常范围内时，整个环境可以被视为健康。通过在监控中为这些指标设置相关的阈值，可以将问题报告为警报。Datadog 提供了定义基于指标的监控和警报的功能。

我们在第二章《部署 Datadog Agent》和第三章《Datadog Dashboard》中看到，已发布的指标可以在 Datadog UI 的指标浏览器中使用标签进行查看和过滤，如以下示例所示：

1. 导航到指标 | 指标浏览器以打开指标浏览器窗口：

   图 5.1 – 指标浏览器

2. 在docker.cpu.usage中。

3. 在docker.cpu.usage中，对于运行在主机上的特定容器来说意义最大，除非你有兴趣监控一台或多台机器上容器的平均或总 CPU 使用率。

4. 通过指定标签主机和container_name，你可以轻松地将范围缩小到特定的容器。你还可以看到，基于你在左侧窗格中选择的指标和过滤条件，右侧窗口呈现了一个时间序列图。

上述示例演示了指标和标签如何协同工作，从 Datadog 发布的大量时间序列指标数据中提取洞察。Datadog 实现的指标远比我们在第一章《监控简介》中讨论的基本概念要复杂得多；让我们来看看在 Datadog 中定义的与指标相关的一些概念。

指标数据

指标数据值是某一时刻的指标度量。例如，system.memory.free 指标跟踪主机上可用的空闲内存。Datadog 测量该指标并定期报告该值，这个值即为指标数据值。这样的一系列测量将生成一个时间序列数据流，如图 5.1所示。

刷新时间间隔

Datadog 在此时间窗口内处理接收到的指标值，并根据指标类型进行处理。

指标类型

主要的指标类型是计数、速率和仪表，它们在如何处理指标数据点以发布为指标值方面有所不同：

• 计数：在刷新时间间隔内接收到的指标数据相加，作为指标值返回。

• 速率：在刷新时间间隔内接收到的指标数据总和除以该间隔中的秒数，作为指标值返回。

• 仪表：在刷新时间间隔内接收到的最新值作为指标值返回。

指标单位

指标类型是一组相似的度量单位。例如，字节组是一种存储和内存度量类型，包含位、字节、千字节、兆字节、吉比特等单位。时间组包含从纳秒到一周的单位。有关指标单位的完整列表，请参阅 Datadog 文档 (docs.datadoghq.com/developers/metrics/units/)。

查询

一个查询返回来自时间序列指标数据集的值，基于给定的筛选条件和时间窗口。例如，system.memory.free 指标的时间序列数据将会报告给所有运行 Datadog Agent 的机器。

如果你只想在过去一小时内监控特定主机的指标，可以使用 Datadog 定义的 host 标签来缩小范围，指定一个特定的主机，同时你还可以指定时间范围。指定查询参数的方式取决于你使用的界面。例如，你已经看到如何在 Datadog 仪表盘上的 Metrics Explorer 窗口中运行查询，在那里这些参数是通过可视化方式指定的。

Datadog 在查询中识别以下部分：

• host 标签将范围设置为单一主机。

• system.disk.free 会为同一主机生成多个时间序列数据集，因为每个磁盘会生成一个数据集，并且通常一台主机会有多个磁盘。假设你有兴趣监控所有 Web 主机的总磁盘空间。如果这些主机使用自定义标签（如 host_type，值为 web）被标记为 Web 主机，则可以用它来设置范围，host 标签则可用于分组。

• system.cpu.*、system.load.* 和 system.mem.*

  B. system.disk.*

  C. system.disk.directory.* 模式

  D. system.processes.* 模式

Datadog UI 上的 集成 页面提供了通过这些集成可用的所有指标的完整列表。与指标关联的元数据可以查看，并且一些设置可以在 Metrics Summary 窗口中编辑：

• 转到 Metrics | Metrics Summary，列出了所有指标。可以通过指标名称或与之关联的标签搜索特定的指标。查看以下屏幕截图，了解如何搜索 Redis 指标：

图 5.2 – 在 Metrics Summary 界面中搜索 Redis 指标

• 可以通过点击任何感兴趣的指标来查看该指标的元数据。在以下屏幕截图中，提供了 redis.mem.used 指标的汇总：

图 5.3 – redis.mem.used 指标汇总

使用该窗口上的 Edit 按钮，可以更改指标的描述和刷新时间间隔。它还提供了源主机和可用于筛选的标签。在这一部分中，我们了解了 Datadog 中如何实现指标的概念，并且它们如何在仪表盘上以不同方式呈现。在接下来的部分中，我们将讨论标签，这是与指标和其他资源一起使用的构造。

标签化 Datadog 资源

在本章的前几节中，我们已经提到过标签作为分组和过滤指标的手段。虽然标签的使用与其他系统中的关键字、标签或话题标签类似，但了解标签是如何应用到指标中的非常重要。标签也可以应用于其他 Datadog 资源，例如事件和监控。不过，我们将在接下来的部分集中讨论如何在处理指标时使用标签。

定义标签

以下是定义标签的主要规则和最佳实践：

• 标签应以字母开头，且可以包含以下字符：字母数字、下划线、连字符、冒号、句点和斜杠。

• 标签应该使用小写字母。如果使用大写字母，它们会被自动转换为小写。自动转换大小写可能会造成混淆，因此建议仅使用小写字母定义标签。

• 标签最长可以有 200 个字符。

• 标签的常见格式是 <KEY>:<VALUE>，这种格式准备好在查询的不同部分中使用，正如我们之前所看到的那样。Datadog 对某些标签保留了特定的关键字，例如 host、process 和 env，这些标签具有特殊含义，使用时应符合相关含义。

标签化方法

Datadog 提供了多种标签化指标的方法。然而，以下两种方法是最常见的：

• 来自 Datadog Agent 配置文件

• 从集成的配置文件中

这两种方法都是在 Datadog Agent 层面执行的。标签也可以通过 Datadog UI、使用 Datadog API 或作为 DogStatsD 集成的一部分来设置。

在 Datadog Agent 配置文件 datadog.yml 中，可以使用配置项 tags 来添加标签，如下所示：

tags: ["KEY1:VALUE1", "KEY2:VALUE2"]

这里有一种替代方法：

tags:
    - "KEY1:VALUE1"
    - "KEY2:VALUE2"

后者的语法在配置文件中更受推荐，因为它具有更好的可读性。

自定义主机标签

我们已经遇到过系统定义的 host 标签，它在过滤指标数据时非常有用。它默认基于 Datadog Agent 运行的机器的主机名进行设置，但可以通过在 datadog.yml 中设置 hostname 配置项进行自定义。

标签化集成指标

集成生成一个已发布的指标列表，并可以通过为集成配置 tags 配置项来为这些指标打标签：

tags:
    - "KEY1:VALUE1"
    - "KEY2:VALUE2"

例如，对于 Redis 集成，此更改在 /etc/datadog-agent/conf.d/redisdb.d/config.yaml 中完成。

除了从配置文件应用的标签外，一些集成还通过继承源应用程序和平台的标签来提供标签。最好的例子是 Datadog 集成从相关 AWS 服务中提取 AWS 标签。

来自微服务的标签

如果 Datadog Agent 部署在容器化环境中，Docker 和 Kubernetes 等相关应用程序的标签会自动收集。可以通过设置以下环境变量提取更多标签：

• DD_TAGS：可以使用此环境变量设置主机级标签。

• DD_DOCKER_LABELS_AS_TAGS：将 Docker 标签发布为标签。

• DD_DOCKER_ENV_AS_TAGS：将 Docker 环境变量发布为标签。

• DD_KUBERNETES_POD_LABELS_AS_TAGS：将 Pod 标签发布为标签。

使用标签进行过滤

在 Datadog 帐户中，某个度量的时间序列数据可以来自多个来源。例如，对于system.disk.free度量，同一主机可能会有多个时间序列数据流，因为该数据系列是为主机上的每个磁盘生成的。因此，数据可能需要以在大多数情况下有意义的方式进行分组，我们已经看到如何在Metrics Explorer和查询中使用标签来过滤数据并提取逻辑分组的度量数据。

标签的使用不仅限于过滤度量。这些标签也可以应用于其他 Datadog 资源，用于过滤和分组，就像对度量数据的处理一样。以下是可以被标记的主要 Datadog 资源：

• 事件

• 仪表盘

• 基础设施：主要是主机、容器和进程

• 监控

在 Datadog 中，标签的使用非常广泛，前面的列表仅涵盖了重要的资源。当某个特定资源类型（例如事件）的数量非常大时，没有标签的帮助，几乎无法追踪到特定实例。例如，关联到某种特定主机类型的事件可以通过适当地标记这些事件来提取。

无论何时需要查找某些信息的子集时，标签都用作搜索相关资源和度量数据的关键字。这意味着已发布到 Datadog 的监控数据必须做好标签，以便能够轻松提取该数据的子集。

Datadog 及其提供的各种第三方产品集成生成了我们在实际工作中使用的大部分度量。在接下来的部分中，我们将讨论自定义度量及其如何发布到 Datadog。

定义自定义度量

你已经看到，通过这些方法可以定义度量，并生成相关的时间序列数据：

• 通过启用核心基础设施集成，安装 Datadog 代理

• 通过启用 Datadog 提供的平台和应用集成

可以通过在相关配置文件中定义自定义标签，将其与前述的度量集合关联起来。某些集成还提供从源应用程序和平台继承标签的功能。

除了开箱即用或可以轻松启用的这组度量，Datadog 还提供了多种选项来定义自定义度量和标签。这是 Datadog 成为一个强大的监控平台的原因之一，它可以根据你的具体需求进行微调。

自定义度量需要设置以下属性：

• 名称：名称不得超过 200 个字符，应以字母开头，并且只能包含字母、数字、下划线和句点。与标签不同，指标名称是区分大小写的。

• 值和时间戳：指标值将与时间戳一起发布。

• 指标类型：如前所述，主要的指标类型有计数、速率和仪表。

• 间隔：这设置了指标的刷新时间间隔。

• 标签：专门为此指标设置的标签。

提交自定义指标有多种方式：

• Datadog Agent 检查：Datadog Agent 可以配置为运行自定义脚本作为检查，并且可以利用该接口发布自定义指标。我们将在第八章中进一步了解如何实现自定义检查，与平台组件集成。

• Datadog REST API：可以使用 Datadog 提供的 REST API 查看、创建和管理 Datadog 资源。自定义指标和标签也可以通过这种方式进行处理。当 Datadog 不与需要监控的软硬件系统紧密集成时，这种方式特别有用。我们将在第九章中学习如何使用 Datadog REST API，使用 Datadog REST API。

• DogStatsD：这是 Datadog 实现的 StatsD 接口，用于发布监控指标。我们将在第十章中进一步讨论这一内容，与监控标准一起工作。

• PowerShell：提供一个选项，从微软平台提交指标。

Datadog UI 有一个事件流仪表盘，我们将看到事件是如何在仪表盘上列出的，以及发布了哪些事件详情。在大规模环境中，事件流的数量可能相当大，你可能需要搜索感兴趣的事件。虽然大多数事件仅提供信息，但对于某些类别的事件，比如重要服务的停止，接收通知可能是有意义的。事件通常是由 Datadog 生成的，但 Datadog 也提供了生成自定义事件的功能，作为集成选项。

让我们看看 Datadog 是如何通过其事件流仪表盘开箱即用地处理事件的。

监控事件流

由 Datadog 生成或由应用程序发布的事件，提供了应用系统中发生的活动日志，特别是在基础设施和系统层面，例如主机出现一次性问题或服务重启。在 Datadog UI 中，事件流仪表盘列出了最新的事件，可以按如下方式查看。

点击事件菜单并在显示字段中选择一个时间窗口，以查看特定时间段内的事件。事件流仪表盘将如下所示：

图 5.4 – 事件流仪表盘

事件流中列出的事件已被分类，可以在仪表盘上按如下方式进行过滤：

• 按来源：在仪表盘的左侧窗格中，FROM 部分列出了事件的来源。

• 按优先级：在仪表盘的左侧窗格中，PRIORITY 部分列出了事件的优先级。

• 按严重性：在仪表盘的左侧窗格中，STATUS 部分列出了事件的严重性。

通过选择此处描述的一个或多个事件类型，可以在事件流仪表盘上筛选显示您需要查看的特定事件。如果仪表盘上选中了聚合相关事件选项，则相关事件将被聚合，如下图所示：

图 5.5 – 事件流仪表盘上的聚合相关事件选项

在接下来的部分，我们将看到如何在事件流仪表盘上定位特定的事件。

搜索事件

在一个大规模环境中，Datadog Agent 运行在数百台主机上，监控着运行在这些主机上的各种微服务和应用程序，每分钟都会有大量事件发布到事件流仪表盘。在这种情况下，手动查看事件流是不可行的，必须使用标准搜索方法来定位感兴趣的事件。Datadog 提供了多种搜索和筛选选项，以获取正确的事件集合。

如我们在前一部分所见，您可以在显示字段中指定一个时间窗口，仅查看特定时间段的事件。如以下截图所示，可以通过多种方式指定时间窗口：

图 5.6 – 过滤事件的时间窗口选项

时间可以按如下方式指定：

• 通过选择过去的固定时间段（分钟、小时或天）。

• 通过输入自定义时间窗口，如截图所示；此选项可以使用 Unix 时间戳。

提供了一个全文搜索选项，您可以使用它通过关键词查找事件。在以下示例中，使用了 ntp 关键词来列出仅相关的事件：

图 5.7 – 使用关键词搜索事件

可以保存关键词搜索以便将来使用。点击关键词搜索框中的向下箭头查看保存选项，如下图所示：

图 5.8 – 保存事件的关键词搜索

虽然上一个示例进行了简单的全文搜索，但 Datadog 查询语言可以用于进行更复杂的搜索，您可以使用以下一些重要的构造：

• sources:<source_name_1>，<source_name_2>：在这种情况下，搜索将针对来自 source_name_1 或 source_name_2 的事件进行。

  同样，你也可以在查询中指定标签、主机、状态（错误、警告或成功）和优先级（低或正常）作为筛选条件。

• 可以使用 OR、AND 和 NOT 布尔运算符来组合基本搜索条件。以下是一些示例：

  ntp OR nagios 将搜索包含 ntp 或 nagios 关键字的事件。

  tags:region:us-west-2 AND environment:production 将搜索标记为 region:us-west-2 和 environment:production 的事件。

  * NOT "ntp" 将列出所有不包含 ntp 关键字的事件。

现在我们来看看如何接收事件通知。

事件通知

监控事件的常规方式是通过事件流仪表板进行搜索，特别是在基础设施或应用系统出现问题时，寻找一些线索来查明根本原因。事件在主动监控方面的作用有限，因为你只能在问题发生后才知道情况。然而，通知他人关于某些事件可能会很有用。此外，通过通知 Datadog 支持团队，也可以基于事件提交支持工单。

使用事件旁边的 添加评论 链接可以像以下示例一样发送通知：

图 5.9 – 事件通知

如图所示，事件通知可以发送到个人邮件、所有人和Datadog 支持。如果选择 所有人，组织中所有的 Datadog 用户将会收到事件通知。如果选择 Datadog 支持，将创建一个支持工单。

事件流与以下集成进行了集成，通过这些集成，事件详情可以转发到相关工具：

• @slack-<slack_account>-<slack-channel>。

• @webhook_name。(webhook_name 必须在 Datadog 中进行配置才能生效，我们将在第九章，使用 Datadog REST API 中看到如何操作。)

• @pagerduty，事件详情可以作为警报转发到 PagerDuty。

在接下来的部分，我们将了解如何创建自定义事件并将其添加到事件流中。

生成事件

到目前为止，我们已经讨论了如何查看、搜索和提升由 Datadog 生成的事件。与指标和标签一样，Datadog 也可以创建自定义事件。此功能的主要用途是将事件流仪表板作为 站点可靠性工程 (SRE) 和生产工程团队的沟通中心。

一个常见的场景是在受 Datadog 监控的环境中进行部署。在部署过程中，多个服务和进程将被重启，并且会产生大量事件。将部署作为事件发布，并附带详细信息，可能有助于缓解其他监控环境但没有积极参与部署过程的团队的担忧。

事件可以从事件流仪表板发布为状态更新。请看以下示例：

图 5.10 – 发布自定义事件

与创建和管理其他 Datadog 资源一样，事件也可以通过 Datadog API 程序化生成。这使得独立程序能够将事件发布到事件流。在前面的例子中，状态更新直接发布在事件流仪表板上。在更自动化的环境中，部署编排过程、Jenkins 作业或Ansible playbook可以使用 API 实现相同的操作。

发布事件的 API 地址为api.datadoghq.com/api/v1/events，其有效载荷中的主要属性如下：

• alert_type：值可以是 error、warning、info 或 success。

• priority：值可以是 normal 或 low。

• source_type_name：可用源的列表请见docs.datadoghq.com/integrations/faq/list-of-api-source-attribute-value/。

• tags：应用于事件的标签，用于过滤和分组。

• text：事件正文。

• title：事件标题。

我们将在第九章，使用 Datadog REST API 中详细学习如何使用 Datadog API。我们将在那里通过一个例子展示如何使用 Datadog API 向事件流发布事件。

现在，让我们来看看在 Datadog 中定义和使用指标、事件和标签的最佳实践。

最佳实践

以下是与创建和维护指标和标签相关的最佳实践：

• 确保启用了通过各种集成提供的所有标签。这主要涉及从源平台（如公共云服务、Docker 和 Kubernetes）继承标签。当复杂应用程序是你环境的一部分时，拥有更多标签有助于提高可追溯性。

• 从 Datadog Agent 和集成中添加更多标签，以便轻松划分你的指标数据，并高效追踪环境、服务和所有者。

• 为你的自定义指标使用带有句点的命名空间结构，这样可以方便地进行分组和定位——例如，mycompany.app1.role1.*。

• 根据指南格式化指标和标签的名称和值。如果其格式不符合规范，Datadog 会默默地对名称和值进行更改。这些更改后的名称可能会导致混淆，因为它们与预期的值不同。

• 如果发生某些事件，且从监控警报中无法立即获取足够的信息，请查询事件流以寻找线索。

• 从仪表盘发布可能有助于某些正在进行的活动的自定义消息，例如部署，特别是当你在分布式团队环境中工作时。

• 如果自动化过程对 Datadog 监控的资源有影响，考虑从自动化过程中发布事件到事件流。

• 使用通知选项向 Datadog 支持团队提交工单，若某个事件需要他们进一步调查。

总结

指标是现代监控系统的核心，Datadog 也不例外。Datadog 提供了丰富的选项来生成和使用指标。尽管标签在所有 Datadog 资源中都有通用用途，但它们的主要作用是对大量的指标数据进行分组和筛选。

在本章中，我们学习了如何定义指标和标签，以及如何通过标签对指标和其他资源进行分组和搜索。除了 Datadog 定义的指标和标签之外，还有多种方法可以添加自定义的指标和标签，其中一些方法在本章中已经讨论过。

事件是 Datadog 监控的基础设施或应用系统中的活动。Datadog 会捕获并在事件流仪表板上列出这些事件。可以通过多种方式搜索事件，包括使用关键词和标签。事件还可以转发到不同的渠道，如电子邮件、Slack 和 PagerDuty。

在下一章中，我们将了解如何在 Datadog 中管理监控事件。我们还将学习如何搜索这些事件，以及如何发布自定义事件。

第六章：监控基础设施

在上一章中，我们了解了在软件系统中发生的事件，这些事件对于监控非常有用，并且它们在 Datadog 中的处理方式。指标和事件与标签结合后，为 Datadog 用户提供了一套丰富的数据，并可以用来对信息进行分组和过滤，以满足多种监控需求。

在第一章，监控简介中，我们了解了构成全面、主动监控过程的不同类型监控。基础设施监控是其中的一种基本监控类型，主要关注监控应用系统运行的计算、存储和网络基础设施。所有主要的监控应用都提供开箱即用的基础设施监控功能。而在许多组织中，监控的范围有时仅限于此类型的监控。Datadog 为基础设施监控提供了出色的支持，我们将在本章学习这些内容。我们将具体探讨以下主题：

• 主机清单

• 列出容器

• 查看系统进程

• 监控无服务器计算资源

技术要求

若要尝试本书中提到的示例，你需要安装以下工具并确保资源可用：

• 一个 Datadog 账户和一个具有管理员权限的用户。

• 在主机级别或作为微服务运行的 Datadog Agent，具体取决于示例，指向 Datadog 账户。

主机清单

在 Datadog 中，有两个界面提供主机列表：主机地图和基础设施列表。这些界面上列出的每个主机上都将运行 Datadog Agent。该主机可以是裸金属机器，也可以是已在公共云服务（如 AWS 或 Azure）中配置的虚拟机（VM）。

让我们首先看看主机地图功能。要访问该界面，请在 Datadog 仪表板上导航至基础设施 | 主机地图。你将看到一个类似于以下内容的仪表板：

图 6.1 – 示例主机地图

仪表板上的每个六边形图标代表 Datadog 监控的基础设施中的一个主机。主机的 CPU 利用率（以百分比表示）通过颜色编码表示，较低的使用率用绿色表示，较高的使用率用橙色表示。仪表板右下角的图例提供了颜色编码的详细信息。图例中提供的齿轮按钮可以用来根据个人喜好自定义颜色编码。

六边形的大小可以与某个度量的值相关联。在此情况下，属于某主机的六边形大小将与该主机报告的度量值成正比。要在主机图中的六边形中使用百分比 CPU 利用率作为大小度量，请从仪表板右上角的填充方式与大小方式下拉菜单中选择该度量。生成的主机图将如下所示：

图 6.2 – 使用大小选项的主机图

如您所见，六边形对于那些 CPU 利用率较低的主机来说较小。任何由主机发布的其他度量都可以用于此目的。

主机图仪表板上列出的主机可以通过可用标签进行筛选和分组。使用标签搜索特定主机集通常非常有用。例如，在故障排除时，如果基础设施中有成百上千的主机，缩小搜索范围到少数主机会更为方便。

让我们来看看使用标签筛选主机时可用的选项。

通过在按标签筛选字段中选择一个或多个标签，仅会列出相关的主机，如下所示：

图 6.3 – 启用过滤器的主机图

在此案例中，metadata_platform:linux标签被用作筛选器，以仅查看 Linux 主机。

通过在按标签分组主机字段中选择一个或多个标签，主机可以在主机图仪表板上按簇列出，如下所示：

图 6.4 – 主机图与分组主机

在此情况下，用于分组主机的标签是metadata_platform。在此处，我们可以看到五台 Linux 主机被分组在一起，而单独的 Mac (darwin) 主机则与 Linux 组分开显示。

重要说明

按标签分组主机选项仅使用标签的键，而按标签筛选选项还需要标签的值。

如您所见，已经有多种方式可以在主机图仪表板上列出和定位主机。如果您想查看特定主机，可以点击它，这将打开另一个窗口，显示该主机的放大版，并包含特定主机的详细信息：

图 6.5 – 主机图，放大显示主机详细信息

此界面提供了主机级别的信息和与之相关资源的链接，便于您收集主机的所有详细信息，无论是在静态情况下还是在运行时。

可以从主机仪表板中查看以下资源的详细信息：

• 应用：列出了有关已为该主机实施的集成的详细信息链接，形状为六边形。

• 代理：代理的版本。

• 系统：此处提供了操作系统级别的详细信息，可以深入多层次查看。

• 容器：如果主机上运行着容器，相关信息将在此显示。

• 指标：最近发布的主机级指标列在此处。

• host 标签指向主机名称，默认情况下可用，更多host级别的标签可以在 Datadog 代理配置文件中使用tags选项进行设置。

在此界面的顶部，提供了主机名称和主机别名。此外，以下与主机相关的仪表板链接也可在同一位置找到：

• 仪表板：这是一个特定于主机的仪表板，包含有关重要主机级指标的图表。我们将很快查看这个仪表板。

• 网络：网络性能监控的仪表板。启用此功能需要在 Datadog 代理中进行配置。

• 进程：如果启用了 Datadog 代理中的实时进程功能，则此仪表板将显示主机上正在运行的进程的详细信息。我们将在系统进程部分详细查看。

• 容器：此链接将引导您到显示主机上运行的容器的仪表板。

现在，让我们来看看可以从主机图放大窗口访问的一些详细仪表板。

通过导航到应用 | 代理，您可以弹出一个列出 Datadog 代理特定指标的仪表板，如下图所示：

图 6.6– Datadog 代理特定指标

datadog_agent. 类别的指标对于监控应用系统不直接有用，但它可以提供有关 Datadog 代理在特定主机上运行状况的洞察。

通过导航到应用 | 系统，您将看到一个包含关于主机核心基础设施指标的图表的仪表板，例如 CPU 使用率、负载平均值、磁盘使用率和延迟、内存可用性和使用情况，以及网络流量。以下截图展示了这样的示例仪表板：

图 6.7 – 带有系统指标的主机仪表板

我们已经看到，在图 6.5中的应用部分列出的块链接与在该主机上运行的集成相关。除了我们刚才查看的常见链接，如代理和系统外，其余的链接将取决于在主机上启用了哪些集成。例如，在图 6.5中，显式启用了docker和redisdb。点击docker，将弹出一个包含 Docker 特定指标图表的仪表板，如下图所示：

图 6.8 – Docker 指标仪表板

通过导航到应用 | 系统，我们可以看到如何查看包含系统级别指标的主机仪表板，正如图 6.7所示。

通过点击查看主机： | 仪表板链接，在主机缩放窗口中可以以更好的方式查看系统指标。此仪表板为每个系统指标类别提供图表，便于检查某一时间范围内的指标。接下来，我们来看看这些系统指标中哪些构成了基础设施监控的核心内容。

对于每一类系统指标，主机仪表板上都提供了一个小部件，并绘制了相关的指标图表。通过使用右上角可用的菜单选项，可以进一步深入查看这些小部件。

点击左侧按钮，可以以全屏模式查看该小部件，并提供更多选项。中间按钮会弹出一个与管理图表相关的菜单。右侧按钮提供图表中使用的指标的详细信息。以下是这些菜单的截图，其中中间按钮被高亮显示：

图 6.9 – 小部件常见菜单选项

现在，让我们看一下主机仪表板上可用的主要小部件。

CPU 使用情况

通过将鼠标悬停在CPU 使用情况图表上，可以在仪表板上显示相关指标，如下图所示：

图 6.10 – CPU 使用情况指标

这些是主要的 CPU 使用情况相关指标及其含义：

• system.cpu.idle：CPU 花费时间处于空闲状态的百分比。

• system.cpu.system：CPU 花费时间运行内核的百分比。

• system.cpu.iowait：CPU 花费时间等待 I/O 操作完成的百分比。

• system.cpu.user：CPU 花费时间运行用户空间中的进程的百分比。

通过跟踪这些指标，你将对主机的 CPU 使用情况有一个整体的了解，通过在这些指标上建立监控，可以使这些指标的跟踪实现自动化。

负载平均值

运行某些基于 UNIX 的操作系统（如 Linux 或 macOS）的主机负载，是通过运行在主机上的并发进程数量来衡量的。通常，负载会跟踪过去 1 分钟、5 分钟和 15 分钟的平均值。因此，UNIX 命令如 uptime 返回的就是负载平均值的三个测量值，如以下示例所示：

$ uptime
12:18  up 2 days,  3:29, 4 users, load averages: 1.45 1.71 1.76

主机的负载平均值数据在负载平均值图表上进行绘制，该图表位于主机仪表板上，如下图所示：

图 6.11 – 主机仪表板上的负载平均值图表

通过将鼠标悬停在图表上，可以显示 1 分钟、5 分钟和 15 分钟负载的平均值，如前面的截图所示。此类别中的重要指标如下，所有指标名称都有自文档说明：

• System.load.1：过去 1 分钟的平均负载

• System.load.5：过去 5 分钟的平均负载

• System.load.15：过去 15 分钟的平均负载

在本节中，我们查看了与系统负载相关的指标。现在，让我们来看交换内存指标。

可用交换空间

Linux 主机上的交换空间允许将内存中不活跃的页面移动到磁盘，以腾出 RAM 空间。以下系统指标在主机仪表板上的图表中绘制：

• system.swap.free：空闲交换空间的大小，以字节为单位

• system.swap.used：已使用的交换空间大小，以字节为单位

交换空间相关的指标可以在仪表板上查看，如下方截图所示：

图 6.12 – 可用交换空间

除了在此图表中使用的指标外，Datadog 还发布了更多与交换空间相关的指标，这些指标也可以用于自定义图表和监控。

磁盘延迟

存储设备的磁盘延迟由处理 I/O 请求的延迟决定，其中还包括队列中的等待时间。这个值由 system.io.await 指标跟踪：

图 6.13 – 磁盘延迟小部件的全屏模式

此指标值针对主机上的每个存储设备进行报告。在前面的截图中，提供了此小部件的全屏模式的示例视图。

内存细分

虽然 Datadog 发布了与主机上可用内存及其使用情况相关的多项指标，但此小部件仅显示两个指标：system.memory.usable 和 system.memory.total 与 system.memory.usable 的差值，后者提供了保留内存的估算值：

图 6.14 – 内存细分小部件的全屏视图

这些是静态指标，不提供有关主机内存动态使用情况的信息。现在，让我们来看一下此类别中一些重要的指标：

• system.mem.cached：缓存中使用的 RAM 量，以字节为单位

• system.mem.free：空闲 RAM 量，以字节为单位

• system.mem.paged：用于分页的物理内存量，以字节为单位

• system.mem.used：已使用的 RAM 量，以字节为单位

在本节中，我们已查看了与内存相关的重要指标。在下一节中，我们将看看如何使用相关指标监控磁盘存储使用情况。

磁盘使用情况

跟踪附加到主机的磁盘存储使用情况是基础设施监控中最常见的方面之一。这个小部件使用system.disk.in_use指标来绘制每个设备的磁盘使用情况，该指标表示设备上已使用的磁盘空间占总可用空间的比例：

图 6.15 – 磁盘使用情况小部件

Datadog 发布了几个与磁盘相关的指标。重要的指标如下：

• system.disk.free：设备上空闲的磁盘空间（以字节为单位）

• system.disk.total：设备上磁盘空间的总量（以字节为单位）

• system.disk.used：设备上已使用的磁盘空间（以字节为单位）

• system.fs.inodes.free：设备上空闲的inodes数量

• system.fs.inodes.total：设备上inodes的总数

• system.fs.inodes.used：设备上已使用的inodes数量

• system.fs.inodes.in_use：设备上已使用的inodes占总可用的比例

在本节中，我们了解了帮助我们监控存储磁盘使用情况的各种指标。在下一节中，我们将回顾用于监控网络流量的指标。

网络流量

主机的入站和出站网络流量分别通过system.net.bytes_rcvd和system.net.bytes_sent指标进行跟踪。以下截图显示了在主机仪表板上可用的网络流量小部件：

图 6.16 – 网络流量小部件全屏模式

与其他系统指标类别一样，Datadog 发布了几个与网络相关的指标，这些指标可以与图表和监控一起使用。网络指标的完整列表可以参考docs.datadoghq.com/integrations/network/。

到目前为止，我们已经查看了你可以使用的多个选项，用于深入了解主机各个组件的状态，从主机地图界面开始。可以通过在 Datadog 仪表板上导航到基础设施 | 基础设施列表来查看主机列表。

以下截图展示了基础设施列表界面的示例：

图 6.17 – 示例基础设施列表界面

与主机地图相比，基础设施列表是一个更简单的界面，并以表格形式列出主机。点击特定的主机会带你到该主机的仪表板，我们在本节前面已经详细讨论过。

虽然主机，无论是裸机还是虚拟机，以前是承载应用系统的基础设施构建块，但继续将应用程序作为微服务进行部署意味着容器也是基础设施的重要构建块。

在下一节中，我们将了解 Datadog 如何帮助您监控环境中运行的容器。

列出容器

微服务是通过在不同主机上运行一个或多个容器来部署的。如果这些主机上运行了 Datadog 代理，并且已配置为检测这些容器，Datadog 将在容器仪表盘上列出它们。有关发现主机上运行的容器所需的 Datadog 代理配置更改，请参考第二章，部署 Datadog 代理。

要访问容器仪表盘，您可以导航至基础设施 | 容器。在这里，您将能够看到如下截图所示的仪表盘：

图 6.18 – 容器仪表盘

所有 Datadog 代理在主机上发现的容器都会列在此仪表盘上。在左侧面板的主机部分下，列出了容器主机。通过从该列表中选择特定主机，您可以仅显示该主机上运行的容器：

图 6.19 – NGINX 容器的详细信息

点击容器列表项将带您进入一个详细的界面，其中提供了容器的运行时详细信息，如主机名称、用于创建容器的 Docker 镜像和容器上的 Datadog 标签。前面的截图显示了一个示例容器的详细信息。

查看在主机上运行的进程是部署应用程序、确保应用程序正常工作或检查主机健康状况等基本系统管理任务之一。Datadog 使这项任务变得更加容易。我们将在下一节中讨论此功能。

查看系统进程

查看主机上运行的进程的传统方法是登录到该机器并使用ps等命令列出进程，适用于类 UNIX 操作系统。在更倾向于使用弹性和不可变基础设施的环境中，这类手动步骤通常不被推荐或不鼓励。在这种情况下，查看主机上运行的进程选项非常有用。此外，将进程列在一个地方使得比较两个或更多主机的运行时环境变得更加容易。

要访问进程仪表盘，请在 Datadog 仪表盘上导航至基础设施 | 进程。您将看到类似于以下截图所示的界面：

图 6.20 – 进程列表

这个仪表盘与我们在上一部分看到的容器仪表盘类似。在左侧窗格中，有搜索和过滤选项，你可以使用它们来定位需要深入查看的进程。点击进程列表后，你可以查看其详情，如下图所示：

图 6.21 – 进程详情

关于进程的信息，如进程名、进程 ID（PID）以及启动进程的用户，可以在详细页面上查看。这个示例中提供的进程详情可以直接在主机上查询，方法如下：

$ ps -ef |grep redis
999      14296 14273  0 03:28 ?        00:00:11 redis-server *:6379

默认情况下，Datadog 代理不会报告主机上运行的进程，因此你需要启用此功能。为此，请将以下选项添加到datadog-agent.yml的 Datadog 代理配置文件中，并重启代理服务：

process_config:
    enabled: 'true'

通常，这个配置选项是可用的，但在代理配置文件中已被注释掉，所以你只需取消注释这些行并重启代理。

到目前为止，我们提到过真实和虚拟机以及容器作为基础设施的构建块。在接下来的部分，我们将看到 Datadog 如何帮助监控无服务器计算环境。

监控无服务器计算资源

当前的趋势是完全避免任何形式的基础设施，转而使用无服务器计算环境，在这种情况下，公共云供应商提供平台来创建、运行和监控应用程序。不要与云中的任何托管服务混淆。这里没有主机的概念（因此得名无服务器）；相反，应用程序运行在云服务商提供的计算沙箱中。

最受欢迎的无服务器计算服务之一是 AWS Lambda。Lambda 函数运行应用程序代码，实际上，你可以把它看作是一个微服务。通过安装 AWS 集成并进行一些针对 Lambda 的额外配置，可以从 Datadog 监控 Lambda 函数。

以下步骤概述了设置 Datadog 以监控 Lambda 函数的过程：

1. 在 Datadog 中安装 AWS 集成。

2. 在你的 AWS 账户上安装 Datadog 转发器 Lambda 函数。

3. 如果需要将任何与应用监控相关的信息发布到 Datadog，请对 Lambda 函数进行监控。

进行此配置的详细步骤可以参考docs.datadoghq.com/serverless/。

导航到基础设施 | 无服务器以进入无服务器仪表盘，在这里所有的Lambda函数都可以进行监控，如下图所示：

图 6.22 – 用于无服务器计算的 AWS Lambda 函数

请注意，在这种情况下不需要传统的代理，但被称为Datadog Forwarder的 Lambda 函数能够为基于 Lambda 的无服务器计算执行此任务。

最佳实践

以下是进行基础设施监控时应遵循的最佳实践：

• Datadog 提供了大量的度量指标，涵盖了计算、存储和网络监控的各个方面。确保你只关注每个类别中的重要度量。

• 容器正成为托管现代应用程序的基础设施核心构件。如果使用了微服务，监控容器并获取可以用来优化应用程序性能和可用性的见解就变得非常重要。

• 汇总进程将使比较运行时环境变得更加容易，并且必须启用该功能。

• 尽管在无服务器计算中没有需要管理的基础设施，但 Datadog 提供了监控应用程序功能的选项，应该启用这些选项来跟踪相关的度量标准。

摘要

在涉及主机的传统计算场景中，基础设施监控是监控的核心。主机包括裸金属和虚拟机。随着微服务的广泛使用，容器已成为构建基础设施的重要元素。Datadog 提供支持主机和容器级监控的功能。Datadog 汇总主机进程的功能使得比较主机级别的运行时环境变得容易。尽管没有涉及基础设施，Datadog 仍然可以用于监控无服务器计算资源，如 AWS Lambda 函数。在本章中，你了解了如何使用 Datadog 监控运行软件应用程序系统的基础设施的各个组件。这些基础设施组件可以位于传统数据中心或公共云中，也可以是虚拟机或容器。

尽管有用的度量可以发布到 Datadog 或由它生成，但如果不使用监控和警报，它们的价值有限。在下一章中，我们将学习如何在 Datadog 中设置监控和警报。

第七章：监控和警报

在上一章中，我们学习了如何使用 Datadog 监控基础设施。现代的基于云的基础设施比基于数据中心的裸机计算、存储和网络基础设施更加复杂和虚拟。Datadog 旨在与以云为中心的基础设施一起工作，并且能够满足大多数基础设施监控需求，无论是裸机还是公有云基础设施。

任何监控应用程序的核心需求之一是通知你正在发生的问题。理想情况下，应该在问题导致服务中断之前就被通知。在之前的章节中，我们讨论了度量标准以及它们如何生成、查看和在仪表盘上绘制。度量标准的一个重要用途是预测即将发生的问题。例如，通过跟踪存储设备上的system.disk.free度量标准，可以轻松在它达到某个阈值时发出通知。将system.disk.total度量标准结合到这个公式中，还可以按百分比跟踪可用存储。

监控通常跟踪度量标准的时间序列值，当度量标准值在指定时间窗口内超出阈值时，会发送通知。它发送的通知称为警告或警报通知。这些通知通常被称为警报。警告和严重状态的阈值在监控中设置。例如，从之前提到的磁盘存储度量标准中，可以计算出可用存储的百分比。警告阈值可以设置为 30%，而严重阈值可以设置为 20%。

本章中，我们将详细学习监控和警报以及它们在 Datadog 中的实现方式。具体来说，我们将覆盖以下主题：

• 设置监控

• 管理监控

• 分发通知

• 配置停机时间

技术要求

为了尝试本书中提到的示例，你需要安装以下工具并准备好相关资源：

• 一个 Datadog 账户和一个具有管理员权限的用户。

• 根据示例，Datadog Agent 在主机级别运行或作为微服务，指向 Datadog 账户。

设置监控

在通用的监控系统中，监控通常与度量标准或事件相关联，Datadog 覆盖了这些以及更多内容。根据 Datadog 中定义的数据源，有多种监控类型。以下是一些最重要的类型：

• 度量标准：如本章开始时提到的，度量标准是用于构建监控的最常见信息类型。度量标准类型的监控基于为度量值设置的用户定义阈值。

• 事件：监控 Datadog 跟踪的系统事件。

• 主机：检查主机上的 Datadog 代理是否已报告到 Datadog 软件即服务 (SaaS) 后端。

• 实时进程：此监控器检查操作系统级别的一组进程是否在一个或一组主机上运行。

• 进程检查：此监控器检查 Datadog 跟踪的进程是否在一个或一组主机上运行。

• 网络：这些监控器检查 TCP/HTTP 端点的状态。

• 自定义检查：这些监控器基于 Datadog 代理运行的自定义检查。

现在，我们将了解这些类型的监控器是如何创建的，以及需要在 Datadog 代理端支持它们的什么样的仪器设置。

要创建一个新的监控器，在 Datadog 仪表盘中，导航到 Monitors | New Monitor，如以下截图所示：

图 7.1 – 新监控器菜单项

它会提供选择监控器类型的选项，如 图 7.2 所示。在此示例中，我们将创建一个度量类型的监控器：

图 7.2 – 选择度量类型的监控器

单击此选项后，您将进入一个详细的表单，其中提供创建监控器所需的所有信息。由于设置监控器时有多个选项可用，因此此表单相当长。我们将在接下来的截图中查看它：

图 7.3 – 新监控器表单 – 选择检测方法和度量标准

第一步是选择检测方法。如 图 7.3 所示，选择了 阈值告警 作为检测方法。这是常用的检测方法，其中度量值与静态阈值进行比较，从而触发告警。

以下列表突出了其他可用的检测方法：

• 变更告警：此方法将当前的度量值与时间序列中的过去值进行比较。

• 异常检测：此方法根据过去的行为检测度量时间序列数据中的任何异常。

• 异常值告警：当组内某成员的行为异常时会触发告警。例如，集群中特定主机的内存使用量增加。

• 预测告警：这与阈值告警类似；然而，预测的度量值与静态阈值进行比较。

选择监控器类型非常重要，因为监控器的行为和使用在很大程度上取决于监控器的类型。

重要说明

请注意，只有阈值告警是您可以在其他监控系统中找到的标准方法，其它方法都是 Datadog 特有的。通常，在通用监控系统中实现这些检测方法需要一些自定义设置，而 Datadog 则开箱即用地支持这些方法。

在第二步中，选择用于监视器的度量标准，并使用标签添加过滤条件以定义监视器的范围。让我们逐一查看这一部分的每个字段，以了解所有可用选项：

• 度量标准：在此选择用于监视器的度量标准。它应该是 Datadog 代理报告的度量标准之一。

• host和device_name标签，监视器专门为主机上的磁盘分区定义。

• 排除：在此处可以选择标签，以明确排除更多实体。

如果过滤条件（从多个主机和设备的system.disk.free值中设置），将选择聚合函数之一，如average（平均值）、maximum（最大值）、minimum（最小值）或sum（总和），用于指定可用于度量值比较的值。选择正确的聚合函数和标签进行分组非常重要。如果过滤条件已经只返回一个值，那么此设置将不相关。

由此监视器触发的警报可以配置为简单警报或多源警报（在图 7.3中，选择了简单警报）。当监视器的范围是单一源时，例如主机上的存储设备，选择简单警报。如果涉及多个源并且选择了监视器的简单警报选项，则会为所有源发送聚合警报通知；如果选择多源警报选项，则会针对每个源单独发送警报通知。

在表单的这一部分，之前提到的配置都在编辑标签下完成。通过点击源标签，可以查看您在底层 Datadog 定义语言中所做的配置，如下所示：

avg:system.disk.free{device_name:xvda1,host:i-021b5a51fbdfe237b}

在此表单的第三部分，主要设置监视器的阈值和相关配置，如下图所示：

图 7.4 – 新建监视器表单 – 设置警报条件

在 Datadog 术语中，警报表示一个关键状态，警告被称为警告。在示例监视器中，我们正在构建警报阈值，该阈值设置为 0.5 GB，警告阈值设置为 1 GB。这意味着当磁盘上的空闲空间降至 1 GB 时，您将收到警告通知；当磁盘上的空闲空间降至 0.5 GB 时，您将收到一个关键状态的通知。警告和警报状态不仅在监视器触发的通知内容上有所不同，而且对警报的响应也可以进行不同的配置。稍后当我们学习如何配置警报通知时，我们将看到如何完成此操作。

让我们看看在表单这一部分中可以设置的其他选项。

在这一部分的顶部，在第一行本身，您可以配置以下三个项目：

• 高于、或等于、低于 或 低于或等于。在我们的示例中，我们需要选择 低于，因为监控的目标是检查磁盘上的可用存储是否低于已设定的某个阈值。

• 1 分钟 到 1 天，还有一个自定义选项。此时间窗口中的度量值将根据事件设置的性质进行检查。

• 平均而言、至少一次、始终 或 总计。正如选项所示，基于此设置，将检查指定时间窗口中的度量值是否存在潜在问题、警告或告警。

当相关条件不再满足时，监控器会被标记为从警告或告警状态恢复。然而，您可以使用告警恢复阈值和警告恢复阈值来添加特定于恢复的可选阈值。

数据窗口可以选择为需要或不需要。如果选择需要，则监控器将等待完整的数据窗口，以运行检查。如果预期源将定期报告度量值，则必须选择此选项。如果期望根据监控器上指定的数据窗口中的可用数据点来运行检查，则选择不需要。

除了警告和告警通知外，监控器还可以报告缺失的数据。如果选择通知选项，则当度量值在指定时间窗口内未报告时，监控器将发送通知。当预期源在正常操作条件下报告度量值时选择此选项，而无数据警告表示 Datadog 监控的应用系统存在问题。如果监控器中选择的源预期不会定期报告度量值，则选择不通知选项。无数据警告可以设置为在指定的时间窗口后自动解决。通常，这个设置为从不，除非有特殊情况需要自动解决。

使用延迟评估选项，可以将用于评估监控器中设置的各种阈值的度量值延迟指定秒数。例如，如果指定了 60 秒的评估延迟，则在 10:00 时，监控器的检查将在 9:54 到 9:59 报告的数据上进行，数据窗口为 5 分钟。在公共云环境中，Datadog 建议使用最长 15 分钟的延迟，以可靠地确保度量值可用。

根据为监控器设置的阈值，实时状态将在表单顶部进行绘制，以下截图展示了示例监控器如何显示其确定的状态：

图 7.5 – 新监控器表单 – 阈值图表

图表的浅黄色区域表示警告阈值范围，浅紫色区域表示临界（警报）阈值。蓝色粗线在这些区域上方，跟踪度量值的当前值，当然，它远高于危险区。通过交互式构建新监控时，这张图表对于设置实际的阈值非常有帮助。

在新监控表单的第四部分中，当监控触发警告或临界（警报）状态时，需要发送的通知。它以模板形式呈现，如下截图所示：

图 7.6 – 新监控表单 – 通知模板

通知可以有标题和正文，就像电子邮件一样。模板变量和条件语句也可以用于使它们动态化。以下截图显示了实际通知模板的可能样式：

图 7.7 – 新监控表单 – 示例通知

在图 7.7中显示的示例通知中，可以看到如何在通知消息中使用模板、标签变量和条件语句。通过使用is_warning和is_alert消息，可以发送特定于警告或警报的消息。我们来看看一些可以在消息中使用的重要变量和条件语句：

• Value：这是将触发警报的度量值。

• threshold：这是触发警报的阈值，用于与度量值进行比较。

• warn_threshold：这与阈值类似，但用于触发警告。

• last_triggered_at：这是警报触发的时间，采用 UTC 时间。

如果通知消息中的TAG_KEY.name。点击使用消息模板变量帮助链接，了解可以使用哪些标签。

使用条件语句时，可以根据触发的警报类型发送自定义通知。在图 7.7中的示例消息模板中，可以看到消息的一部分是针对警告或警报的。以下是可以在消息模板中使用的主要条件语句列表：

• is_alert：当通知由警报触发时使用此字段。

• is_warning：当通知是由警告触发时使用。

• is_no_data：当通知因报告没有度量数据而触发时使用此字段。

• is_recovery：当警告、警报或无数据状态恢复为正常时，触发通知时使用此字段。

请参考 Datadog 文档，了解完整的模板变量集及其使用方法，网址为docs.datadoghq.com/monitors/notifications。

通知消息也可以进行格式化，Markdown 格式的详细信息可以通过表单上的Markdown 格式帮助链接查看。

通知的接收者可以使用*@*进行指定，如示例模板中所示。通常，*@*后面会跟着电子邮件地址或分发列表。可以通过点击表单底部的测试通知按钮来测试通知消息，如图 7.9所示。你应该看到一个弹出窗口，可以选择一个或多个测试场景，测试消息将根据选定的场景发送给接收者。

你可以为新监控器添加标签，以便后续搜索和分组监控器。通过在标签字段中输入标签键和值，标签monitor-type及其值infra已被添加到示例监控器中。

必须使用如果监控器未解决则重新通知选项，以便在没有采取任何措施解决触发告警的应用系统状态时升级问题。如果选择了重新通知选项，则必须向监控器添加附加的消息模板，如下图所示：

图 7.8 – 新监控器表单 – 告警升级模板

在新监控器表单的最后部分，如图 7.9所示，配置了通知规则：

图 7.9 – 新监控器表单 – 通知团队并保存监控器

在第 4节的消息模板中由*@*指定的收件人列表会自动显示在这一部分，反之亦然。

可以配置监控器，在监控器定义本身发生更改时通知告警接收者，使用当此告警被修改时通知告警接收者选项。

还可以使用仅限创建者或管理员编辑此监控器选项来限制对监控器的编辑权限。

我们在前面的示例中构建的监控器是一个度量类型的监控器，这是所有监控平台（包括 Datadog）上最常见的监控器类型。这些监控器的创建方式相似，因此我们不会逐一查看设置其余监控器类型所需的每个步骤。

让我们来看看其他监控器类型的主要特性，以及它们可能有用的场景：

• host标签。

• 事件：在此监控器类型中，Datadog 提供基于关键字的事件搜索，时间窗口内的事件，并允许你根据搜索结果中的事件数量设置警告和告警阈值。如果可以根据发布到 Datadog 的事件描述来跟踪问题，则设置事件监控器会很有用。

• &&)，或者（||），和非（!）。例如，如果 a、b 和 c 是现有的监控器，你可以使用以下条件创建一个复合监控器：

  ( a || b ) && !c
  

  当 a 或 b 触发且 c 不触发时，此监控器将触发。

• sshd 和警报阈值 below 1 足以设置监控器。

• process.up；但它更有条理。要使用这种类型的监控器监控的进程，必须在 Datadog 代理端的 conf.d/process.yaml 文件中定义。

• conf.d/tcp_check.d/conf.yaml 文件中的定义了 TCP 检查，HTTP 检查则在 conf.d/http_check.d/conf.yaml 文件中定义。HTTP 检查还涵盖了 HTTPS URL 的 SSL 证书相关验证。

  网络检查返回 OK、WARN 或 CRITICAL。设置阈值，以确定需要连续返回多少个此类状态代码，才能触发警告或警报。

• 集成：如 Docker 和 NGINX 等第三方应用程序提供与 Datadog 的集成，这些集成开箱即用，只需在需要时启用。启用并由 Datadog 代理配置后，这些集成将把特定领域的度量指标和状态检查结果发布到 Datadog，并且这些结果将可供此类型的监控器使用。

  创建这种类型的监控器时，可以使用集成特定的度量指标或状态检查作为监控器跟踪的信息源。

• 自定义检查：当无法使用 Datadog 代理报告的各种信息（无论是否进行配置更改）或通过集成来检查某一状态时，可以编写自定义脚本并与 Datadog 代理一起部署。我们将在第八章《与平台组件集成》中讨论如何做到这一点的详细信息。

  这种监控器类型类似于集成监控器，其中选择了一个自定义检查作为状态检查。

• 看门狗：看门狗监控器会报告由 Datadog 监控的系统中的任何异常活动。Datadog 提供了各种问题场景，涵盖计算基础设施和集成。

我们已经详细讲解了如何设置新监控器，并回顾了能够满足您所有可能需求的不同类型的监控器。在下一部分中，我们将学习如何在大规模环境中维护这些监控器，并且可能需要一些自动化。

管理监控器

通过在 Datadog 仪表板上导航至 Monitors | Manage Monitors，您可以列出所有现有的监控器，如下截图所示：

图 7.10 – 监控器列表

如图 7.10所示，有多种选项可以静音或解决监控器。通过静音监控器，您可以停止监控器触发警告或警报。此外，监控器可以在不等待底层问题解决和状态在 Datadog 中反映的情况下标记为已解决。

除了明显的编辑和删除选项外，还可以使用克隆选项来克隆一个监控器，如下图所示，并且可以对其进行修改，创建一个新的监控器，该监控器可以使用源监控器的一些功能：

图 7.11 – 克隆监控器

监控器的定义可以导出为 JSON 格式，并可以作为备份或模板保存在源代码控制系统中，以便以后派生出类似的监控器。

要导出定义，打开监控器的编辑窗口，并使用表单底部的导出监控器按钮。一个窗口将弹出，如下图所示，你可以使用复制按钮复制代码：

图 7.12 – 将监控器导出为 JSON

在新监控器工作流中，使用从 JSON 导入监控器选项，可以从 JSON 创建一个新的监控器。此选项提供一个文本框，可以在其中输入监控器的 JSON 格式定义。如果成功，它将带你进入预填充了 JSON 中详细信息的新监控器表单。在保存监控器之前，可以进行额外的修改。使用此方法创建的任何新监控器的 JSON 是通过修改从类似监控器导出的 JSON 来开发的。

之前，我们已经了解了如何通过在消息模板中添加@符号，将警报通知转发到电子邮件地址和分发列表中。在接下来的章节中，我们将探讨如何将通知分发到广泛的通信平台。

分发通知

让我们回顾一下本章讨论的一些概念，以重申相关的工作流程。当监控器跟踪的系统中的某个阈值或状态达到时，监控器会触发警告或告警。关于此状态变化的通知，从正常到警告或告警，然后恢复到正常，可以发送到不同的通信平台，如电子邮件、Slack、Jira 和 PagerDuty。这些通知也可以发布到任何支持 Webhooks 的系统。

我们已经了解了，只需在个人或群组电子邮件地址前加上@，通知就可以转发给他们。最好将这些通知转发到群组邮箱或分发列表中，因为它们必须由团队中的某个人处理。

与其他工具的集成可以促进警报通知的分发和升级，以便进行系统跟踪并解决问题。我们来看看一些重要的工具：

• Jira：Atlassian 的 Jira 是一款流行的问题跟踪工具。通过启用此集成，每次监控器生成警报通知时，都可以为其创建一个 Jira 工单。此外，Jira 工单的创建过程会在 Datadog 中作为事件进行跟踪。

• PagerDuty：像 PagerDuty 这样的工具被支持团队用来系统地升级问题。需要将警报通知分发到正确的资源，以便对相关问题进行分类，如果该人员不可用，则必须通知其他资源，或者将问题升级。PagerDuty 擅长处理这类任务，并且可以配置以满足复杂的升级需求。

• Slack：类似 IRC 的团队通信平台，如Slack，非常流行，并且覆盖了许多曾由电子邮件处理的消息传递需求。一旦集成，许多 Datadog 任务，如静音监控，可以从 Slack 渠道启动。这些选项除了将警报通知转发到 Slack 渠道的核心功能外，还可以使用。

• Webhooks：虽然 Datadog 支持与流行的缺陷跟踪和通信平台，如 PagerDuty、Jira 和 Slack 的集成，但它也提供了一个使用Webhooks的自定义集成选项。如果在警报通知模板中指定，Webhook 将把警报相关的 JSON 数据发布到目标应用程序。由该应用程序决定如何消费警报数据并根据这些数据采取行动。在第八章，《与平台组件集成》中，我们将详细学习如何在 Datadog 中设置 Webhooks，以便与其他应用程序集成。

监控工具可以通过已配置的集成渠道发送大量通知，有时可能需要静音监控，例如在维护或部署期间。在下一节中，你将学习如何实现这一点。

配置停机时间

使用 Datadog 提供的选项，可以在预定时间段内静音一组监控。通常，当你对计算基础设施进行更改或部署代码时，需要此类停机时间。在这些更改完成并且受影响的环境稳定之前，监控生产中的软件系统可能没有太大意义。此外，通过禁用监控，你可以避免根据现有集成接收电子邮件、短信，甚至电话的警报通知。

要安排停机时间，请导航到监控 | 管理停机时间，你将看到一个表单，如下图所示，其中将列出现有的调度：

图 7.13 – 管理监控停机时间

通过点击安排停机时间按钮，你可以添加新的停机时间安排，如下所示：

图 7.14 – 安排新的停机时间

以下选项可用于安排停机时间：

• 停机时间可以为所有监控或通过名称或标签标识的监控组定义。

• 停机可以是一次性的，也可以是定期的。定期停机在一些服务会周期性不可用时非常有用，例如一些在周末关闭的应用程序。

• 可以像警报通知一样指定通知消息模板和接收人列表，用于发送有关停机的通知。

我们已经看过了配置监控停机的过程，本章到此结束。接下来，让我们看看与设置和维护监控及警报相关的最佳实践。

最佳实践

现在，让我们回顾一下与监控和警报相关的最佳实践：

• 定义一个全面的监控列表，涵盖 Datadog 监控的软件系统的各个方面。

• 你可能只使用 Datadog 来处理某一部分的监控需求，在这种情况下，确保所定义的监控涵盖你关注的领域。

• 为了避免警报疲劳，确保所有警报通知都是可操作的，并且修复步骤已经在通知本身或运行手册中记录。继续微调阈值和数据窗口大小，直到你开始收到可靠的警报通知。如果监控过于敏感，可能会产生噪声。

• 如果任何微调都不足以减少监控发送过多警报的情况，考虑删除该监控，并计划以其他合理的方式监控相关场景。

• 将监控与公司选择的事故跟踪、升级和团队沟通工具集成。电子邮件通知必须作为备用，并且这些通知必须发送给用户组而不是个人。电子邮件警报还应该作为历史记录，用作事后分析（或根本原因分析或RCA）和第三方审计的证据，例如那些要求SOC 2 Type 2 合规的审计。

• 通过导出 JSON 定义并将其保存在源代码管理系统（如 Git）中，以代码的形式备份监控。尽可能通过在 Terraform、Ansible 或 Datadog 的 JSON 格式中定义监控，来将监控保存在代码库中。

• 在进行维护时，普及停机功能并实践它。如果没有这个，警报通知可能会变得恼人，而且监控系统本身的可信度可能会受到影响。

总结

在这一章中，你已经学会了如何基于 Datadog 中有关软件系统和基础设施的各种信息创建新的 Datadog 监控器。此外，我们还学习了如何通过现有的选项手动维护这些监控器，或者将其作为代码进行维护。我们探讨了将监控器与通信工具集成的不同方法，以便广泛分发警报通知。最后，你学会了如何在维护和停机期间有效地使用停机时间功能。

我们已经在使用或监控 Datadog 时讨论了多个第三方工具。在下一章中，我们将学习这些集成如何在 Datadog 中使用，以及如何推出自定义集成。

第二部分：扩展 Datadog

Datadog 提供了许多开箱即用的标准监控功能，这些功能在成功安装代理到应用环境后即可立即使用。然而，要推出一个全面的监控解决方案，Datadog 需要通过添加自定义指标和功能来扩展。Datadog 平台提供了多种集成选项，以便扩展平台并实现高级监控需求。本书的这一部分详细探讨了所有这些选项。

本节包含以下章节：

• 第八章**，与平台组件集成

• 第九章**，使用 Datadog REST API

• 第十章**，与监控标准合作

• 第十一章**，与 Datadog 集成

第八章：与平台组件集成

在上一章中，我们学习了监视器和警报，它们是监控基础设施的关键要素，对于对生产环境中的软件系统进行 24 小时全天候监控至关重要。在书中的早期章节，我们看到如何通过 Datadog 来监控基础设施资源，基础设施资源是任何运行软件系统的计算环境的基本构建块。

在第一章中，监控简介，我们讨论了各种类型的监控，并简要提到了平台监控，平台监控是监控用于构建应用程序软件运行计算平台的软件和云计算组件。在公共云环境中，基础设施和平台组件之间存在重叠，因为计算、存储和网络组件在这些环境中是软件定义的，并且出于监控目的，它们可以被视为平台组件，如MySQL 数据库或RabbitMQ消息系统。

然而，区分基础设施资源和平台组件并不困难。云平台本质上是在基础设施资源之上运行的软件层，应用程序要么运行它们，要么在运行时使用它们。通常，基础设施资源是托管在公共云中的，而平台组件则由第三方软件供应商或开源社区提供，应用程序由其他公司构建。请注意，像 AWS 这样的流行公共云提供商也提供可以替代平台组件的服务。AWS 上的示例包括关系数据库服务（RDS）、Amazon MQ和弹性 Kubernetes 服务（EKS）。

我们在之前的第六章，基础设施监控中了解到，大多数基础设施监控由 Datadog 开箱即用，且配置要求极少。虽然大多数基础设施资源的功能是标准化的，但平台组件则不能简单地这样说，因为平台组件本质上是执行特定任务集的软件应用程序，其监控要求依赖于特性。

Datadog 通过两种方式解决平台监控问题：

• 提供与流行平台软件组件的集成。通过这些现成的集成，用户只需启用所需的集成，以便监控他们应用程序中使用的平台组件。

• 提供运行自定义检查的选项，这些检查可以用来监控可能没有现成集成的的平台组件。

本章将介绍使用 Datadog 中可用的集成选项进行平台监控的详细信息，如上所述。具体来说，我们将涵盖以下主题：

• 配置集成

• 标记集成

• 审查支持的集成

• 实施自定义检查

技术要求

若要尝试本书中提到的示例，您需要安装以下工具并确保有可用的资源：

• 一个安装了 Bash shell 的 Ubuntu 18.04 环境。虽然这些示例可能在其他 Linux 发行版上也能运行，但需要对特定于 Ubuntu 的命令进行适当的修改。

• 一个 Datadog 帐户和一个具有管理员权限的用户。

• 在主机级别运行的 Datadog 代理，或者根据示例作为微服务运行，指向 Datadog 帐户。

配置集成

Datadog 提供了与大多数流行平台组件的集成，需要根据需要启用这些集成。我们将通过一个示例查看启用集成的一般步骤。

可用的集成列在集成仪表板上，如下截图所示，可以直接从主菜单访问：

图 8.1 – 可用集成列表

如你所见，在图 8.1中，第三方软件组件列在集成仪表板上。可以使用该仪表板顶部的搜索选项筛选出已安装的集成。此外，还可以通过关键词查找可用的集成。

通过点击特定的集成列表项，可以查看与该集成相关的所有详细信息。例如，以下截图提供了与 NGINX（一款流行的 Web 服务器）集成的相关信息：

图 8.2 – NGINX 集成概览

从该仪表板中，我们可以获得启用集成后将发布的所有度量指标的完整列表。此外，这个特定的集成还提供了一些监控器，这是一个可选功能。使用集成的主要目的是获取与平台组件相关的度量指标，这些指标可以用于定制的监控器、仪表板以及其他 Datadog 资源。

配置集成需要两个主要步骤：

1. 安装集成：可以通过点击可用的安装按钮来安装集成，以下截图展示了 NGINX 集成的安装界面：

   图 8.3 – 安装集成

   当你将光标悬停在可用集成上时，安装按钮将显示出来。

2. 配置集成：集成的配置是将集成部署到 Datadog 帐户中的关键步骤。配置步骤可以在集成的配置标签下找到（见图 8.2）。这些步骤依赖于平台组件，并且可能需要在 Datadog 监控基础设施中进行更改。例如，如果某个组件运行在主机上（如 NGINX Web 服务器），则需要在运行该主机上的 Datadog 代理配置中进行更改。

现在让我们看看如何为特定的 NGINX 实例配置 NGINX 集成，这将展示配置任何集成的一般步骤。

第一步是启用你帐户中的集成，这可以通过点击集成列表中的 安装 按钮来完成，如 图 8.3 所示。

在这个示例中，我们将尝试为运行在 AWS EC2 主机上的开源版本 NGINX 实例启用集成，该主机运行的是 Ubuntu 16.04 Linux 发行版。请注意，实际的配置步骤也会根据平台组件和 Datadog agent 所运行的操作系统而有所不同，这些步骤仅适用于前述环境：

1. 确保 Datadog Agent 和 NGINX 服务都在主机上运行。可以通过以下方式在 Ubuntu 16.04 上进行检查：

   $ sudo service nginx status
   

2. 如果服务正常运行，你将看到类似于以下的状态：

   Active: active (running) since Mon 2021-01-04 03:50:39 UTC; 1min 7s ago
   $ sudo service datadog-agent status
   Active: active (running) since Sun 2021-01-03 21:12:26 UTC; 6h ago
   

   (这里只提供与服务状态相关的行，简洁起见。)

   让我们首先完成 NGINX 端所需的配置更改。

3. 检查需要用于集成的 NGINX 实例是否已安装 stub status 模块：

   $ nginx -V 2>&1| grep -o http_stub_status_module
   http_stub_status_module
   

4. 在 NGINX 配置目录 /etc/nginx/conf.d/ 下，创建一个新的文件 status.conf，并添加以下配置：

   server {
              listen 81;
              server_name localhost;
              access_log off;
                   allow 127.0.0.1;
                   deny all;
                    location /nginx_status {
         # Choose your status module
         # freely available with open source NGINX
         stub_status;
         # for open source NGINX < version 1.7.5
         # stub_status on;
         # available only with NGINX Plus
                # status;
                # ensures the version information can be retrieved
                server_tokens on;
     }
   }
   

5. 重新加载 NGINX 配置更改：

   $ sudo nginx -t && sudo nginx -s reload
   nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
   nginx: configuration file /etc/nginx/nginx.conf test is successful
   

6. 要完成配置更改，必须在 Datadog Agent 端也进行相应操作。接下来我们来做这个。对于 Datadog 支持的每个集成，都会在 /etc/datadog-agent/conf.d/ 目录下提供一个配置目录。对于 NGINX 集成，该目录为 nginx.d。通常，目录中会有一个示例配置文件，可以根据你的具体需求进行定制。为了简单起见，我们将复制该示例文件，文件中已包含实现此集成所需的基本配置，然后重启 Datadog Agent：

   $ sudo cp conf.yaml.example conf.yaml
   $ sudo service datadog-agent restart
   

7. 要检查集成是否正常工作，你可以查看 Datadog Agent 状态中的相关信息：

   $ sudo datadog-agent status
   Getting the status from the agent.
   nginx (3.8.0)
   -------------
         Instance ID: nginx:16eb944e0b242d7 [OK]
   Configuration Source: file:/etc/datadog-agent/conf.d/nginx.d/conf.yaml
         Total Runs: 5
         Metric Samples: Last Run: 7, Total: 35
         Events: Last Run: 0, Total: 0
         Service Checks: Last Run: 1, Total: 5
         Average Execution Time : 4ms
         Last Execution Date : 2021-01-04 04:00:29.000000 UTC
         Last Successful Execution Date : 2021-01-04 04:00:29.000000 UTC
         metadata:
           version.major: 1
           version.minor: 10
           version.patch: 3
           version.raw: 1.10.3 (Ubuntu)
           version.scheme: semver
   

(上述输出仅为与 NGINX 集成状态相关的摘录。)

当主机上的配置完成并且我们确认它正常工作后，可以预期在 Datadog UI 上看到相关的 NGINX 指标，用于监控和仪表盘。验证的最简单方法是搜索一些示例指标，确认 nginx.net.connections 被成功查找和定位：

图 8.4 – 在 Metrics Explorer 中查看 NGINX 指标

通过这种方式，可以查找集成支持的任何度量标准，这些度量标准在集成的仪表板的 Metrics 标签下有所文档记录。如果您希望查找从特定主机发布的度量标准以验证该主机的新集成部署，可以通过在 Over 字段中选择特定主机来过滤度量标准列表，正如前面的截图所示。

我们刚刚了解了如何推出基于代理的集成的通用步骤，以及如何验证它是否正常工作。在实际的生产环境中，通常会为多个平台组件启用多个此类集成，例如 NGINX。即使是同一个组件，也可以用于多个不同的用途。例如，NGINX 可以用作 HTTP 服务器，提供简单的 Web 应用程序服务，或者用作代理服务器，将 Web 流量引导到更复杂的计算环境，如运行 JVM 的主机集群或 Kubernetes 集群。在这种情况下，必须有一些方式来轻松区分度量标准的来源，而不依赖主机名，因为公共云环境中的主机寿命通常较短。我们已经在第五章《度量标准、事件与标签》中看到，度量标准是如何进行标签化以方便筛选和聚合的。我们将在下一节中回顾这一点，讨论如何在推出集成时使用。

给集成打标签

一个集成发布的度量标准可以在集成层面进行标签化，以便在 Datadog 资源中更好地展示这些度量标准，最终这些度量标准将在其中使用。我们将看到如何实现这一点，目的是实施最佳实践以提高效果。我们已经在第二章《部署 Datadog 代理》和第五章《度量标准、事件与标签》中了解到，可以通过在 datadog.yaml 文件中使用标签配置项来添加主机级的自定义标签。通过此选项添加的自定义标签将在该主机上运行的各种集成生成的所有度量标准中可用。标签选项也可以在集成层面使用，并且相关的标签将仅应用于特定集成的度量标准。

在上一节提到的使用 NGINX 执行不同角色的用例中，这种多层级标签方法将有助于筛选来自多个主机的 NGINX 度量标准。例如，在主机级别，可以通过标签 role:proxy-server 或 role:web-server 来标识其作为 Web 服务器或代理服务器，而在集成层面，可以应用更多标签，标明该组件的具体名称，例如 component:nginx。请注意，这种方法为跟踪平台组件的角色提供了灵活性，例如 HAProxy、NGINX 和 Apache，这些组件可能在整个应用系统中用于多种 HTTP 和代理服务角色。

现在，让我们看看我们刚才讨论的标签策略如何在上一节的示例案例中实现。

在 datadog.yaml 文件中，添加了以下标签：

tags:
    - role:proxy-server

在 conf.d/nginx.d/conf.yaml 文件中，添加了以下两个标签：

tags:
        - component:nginx
        - nginx-version:open-source

请注意，附加标签 nginx-version 将帮助识别使用的是哪种类型的 NGINX。为了开始将这些标签应用到指标，必须重启 Datadog Agent。之后，你可以像以下示例一样使用这些标签过滤指标。

在第一个示例中，如以下屏幕截图所示的 图 8.5，你可以看到一个集成指标 nginx.net.connections 被标记为主机级标签 proxy-server。请注意，所有主机级别的指标以及来自其他集成的指标都会以相同的方式进行标记。例如，一旦启用，系统级指标 system.mem.used 也会被标记为 role:proxy-server：

图 8.5 – 应用于集成指标的主机级标签

在下一个示例中，如 图 8.6 所示，集成级标签 component:nginx 和 nginx-version:open-source 仅用于过滤集成级指标。你不能使用这些标签来过滤主机级别的指标，例如 system.mem.used：

图 8.6 – 集成级标签

在过去的两个部分中，我们了解了如何启用集成的基础知识，以及如何标记集成发布的指标。通过这些基本的理解，我们将深入了解 Datadog 对第三方应用的支持，以及它们是如何集成和组织的。我们还将探讨一些重要的集成，这些集成将是我们在使用 Datadog 时最常用的，因为它们是用于构建各种软件应用系统的常见平台组件。

审查支持的集成

如前所述，Datadog 提供了许多第三方平台组件的集成。其中一些组件，如 Apache、NGINX、Docker、MySQL 等，比其他组件更为重要，因为它们在各种软件应用中广泛使用。在本节中，我们将探讨重要的集成，并重点介绍任何重要的要点。

Datadog 提供了三种不同的方式来集成平台组件：

• 基于 Agent 的：在我们前面看到的本章示例中，必须更新 Datadog Agent 配置以启用集成。这是因为平台组件（例如示例中的 NGINX）运行在主机上。它也可以作为微服务运行，但仍然需要一个 Agent 来监控该环境。本质上，在这种情况下，集成是由本地 Agent 管理的。Datadog Agent 配备了官方集成，并且这些集成是现成可用的，正如我们在 NGINX 示例中所看到的那样。还有更多由社区构建的集成，您可以在 GitHub 上的github.com/DataDog/integrations-extras查看。每个集成都有自己的 README 文件进行文档化。

• 基于爬虫的：软件平台并不总是仅通过在本地运行的组件来构建。有些服务可能是基于云的，Datadog 提供与流行服务（如 GitHub、Slack和PagerDuty）的集成。在这种情况下，Datadog 需要获取访问这些服务账户的凭证，并会爬取该账户以报告与给定服务账户相关的指标。

• 自定义集成：Datadog 提供了广泛的自定义集成选项，这些选项是通用的，而非特定于平台组件的集成。通过 Datadog Agent 运行自定义检查是集成没有官方支持或支持不足的平台组件的最简单方式。稍后我们将在本节的示例中看到如何实现这一点。以下是可以用于推出自定义集成的其他选项。

• 使用 Datadog API：使用 Datadog 进行监控的主要吸引力之一是其广泛的 REST API 支持。尽管您需要一支熟练的团队来通过 Datadog API 推出集成，但拥有此选项使得您的监控基础设施具有可扩展性和灵活性。

• 构建您自己的集成：Datadog 提供了一个开发工具包，允许您按照 Datadog 的规范构建自己的集成。详细信息可以在docs.datadoghq.com/developers/integrations/new_check_howto中查看。

• 使用 StatsD 发布指标：我们将在第十章中详细介绍这一通用集成选项，与监控标准一起工作。

现在让我们来看一些与 Datadog Agent 一起提供并且用户可以启用和使用的重要集成：

• 与公共云的集成：Datadog 支持与主要公共云平台（如AWS、Azure和GCP）以及这些平台上提供的各个服务进行集成。这些基于爬虫的集成需要访问您的公共云账户，可以通过不同的方式提供访问权限。

• 微服务资源：Docker 和 Kubernetes 是构建微服务基础架构中的关键组件。Datadog 支持这两个平台组件及相关产品的集成。

• 代理和 HTTP 服务：Apache、Tomcat、NGINX、HAProxy、Microsoft IIS 和 Memcached 在这一类别中非常流行，并且这些组件都有相关的集成可用。

• 消息服务：流行的消息软件和云服务，如 RabbitMQ、IBM MQ、Apache Active MQ 和 Amazon MQ，都得到了支持。

• 关系数据库管理系统 (RDBMS)：几乎所有流行的 关系数据库管理系统（RDBMS），如 Oracle、SQL Server、MySQL、PostgreSQL 和 IBM DB2，都得到了支持。监控数据库是一个重要需求，因为数据库在许多软件应用中是核心。通过这些集成，可以提供多种指标，用于监控数据库的工作状态和性能。

• NoSQL 和大数据：由于灵活性和可扩展性，NoSQL 数据库在大数据和云应用中被广泛使用。像 Redis、Couchbase、Cassandra、MongoDB、Hadoop 以及来自这一类别的相关产品，均受到 Datadog 的支持。

• 监控工具：在部署全面的监控解决方案时，通常会使用多个监控工具。在这种情况下，Datadog 将是其中一个服务平台，凭借其优越的用户界面和仪表盘功能，它是聚合其他监控系统输入的一个良好平台。Datadog 还提供与其他监控工具的集成，以促进这一整合。目前，支持 Catchpoint、Elasticsearch、Nagios、New Relic、Pingdom、Prometheus、Splunk 和 Sumo Logic 等监控应用的集成。

如果 Datadog 提供的集成无法满足重要的自定义需求，你可以通过实现自定义检查来扩展 Datadog 以满足这些需求。在接下来的章节中，你将学习如何使用一个简单的 Python 脚本来实现一个示例自定义检查，该脚本将发布一个自定义指标。

实现自定义检查

如果现有的集成功能不足，或者某个平台组件根本没有集成，可以使用自定义检查来监控该组件。Datadog API 也可以用来向 Datadog 报告自定义生成的指标。我们将通过一个示例来探讨这个选项。

在 Datadog 中实现发布自定义指标的检查过程是简单的，我们可以通过以下示例来学习这个过程。

继续本章前面部分关于 NGINX 的示例，我们将通过将自定义度量指标添加到 Datadog 来扩展该集成。这个自定义度量指标kurian.nginx.error_log.size跟踪 NGINX 错误日志文件的大小。最好以与你的公司或部门相关的命名空间开头度量指标名称，如本示例所示，以便轻松过滤自定义度量指标。

手动情况下，可以通过在任何 UNIX 兼容的 Shell 上运行ls -al命令来收集文件大小信息。也可以从 Datadog 自定义检查中运行相同的命令，并解析输出以获得所需的结果。

我们称这个自定义检查为custom_nginx。配置步骤大体上与我们之前为启用 NGINX 集成所做的相同。在这种情况下，必须创建配置目录和相关资源：

1. 创建一个配置目录，并为检查设置配置文件：

   $ cd /etc/datadog-agent/conf.d
   $ sudo mkdir custom_nginx.d
   

2. 在新目录中创建一个custom_nginx.yaml文件，并将以下内容保存到其中：

   instances: [{}]
   $ sudo chown -R dd-agent:dd-agent custom_nginx.d
   

3. 安装 Python 脚本到/etc/datadog-agent/checks.d目录：

   将以下脚本保存为custom_nginx.py。请注意命名约定很重要，因为这就是 Datadog Agent 将自定义检查与脚本关联的方式：

   # Based on the sample code provided in Datadog documentation.
   try:
       from datadog_checks.base import AgentCheck
   except ImportError:
       from checks import AgentCheck
   # Value set on __version__ will be shown in the Agent status page
   __version__ = "v1.0"
   from datadog_checks.base.utils.subprocess_output import get_subprocess_output
   class NginxErrorCheck(AgentCheck):
       def check(self, instance):
           file_info err, retcode = get_subprocess_output(["ls", "-al","/var/log/nginx/error.log"], self.log, raise_on_empty_output=True)
           file_size = file_info.split(" ")[4];
           self.gauge("kurian.nginx.error_log.size", file_size,tags=['component:nginx'])
   

   除了脚本的模板要求外，它还执行以下任务：

   A. 在/var/log/nginx/error.log文件上运行ls -al命令

   B. 从命令输出中解析文件大小

   C. 将文件大小作为度量值报告给 Datadog，并应用component:nginx标签

4. 重启 Datadog Agent 以启用自定义检查。要检查是否成功运行，可以运行status check命令并查找与自定义检查相关的状态：

         $ sudo datadog-agent status
   
        Running Checks
     ==============
   
       custom_nginx (1.0.0)
       --------------------
         Instance ID: custom_nginx:d884b5186b651429 [OK]
         Configuration Source: file:/etc/datadog-agent/conf.d/custom_nginx.d/custom_nginx.yaml
         Total Runs: 1
         Metric Samples: Last Run: 1, Total: 1
         Events: Last Run: 0, Total: 0
         Service Checks: Last Run: 0, Total: 0
         Average Execution Time : 2ms
         Last Execution Date : 2021-01-04 10:03:18.000000 UTC
         Last Successful Execution Date : 2021-01-04 10:03:18.000000 UTC
   

5. 一旦你验证了服务器端自定义检查的工作情况，你就可以预期在 Datadog UI 上看到自定义度量指标，并可以像以下截图所示那样进行验证：

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/dtl-cld-mnt-qkstgd/img/Figure_8.8_B16483.jpg)

图 8.7 – 在 Metrics Explorer 中查找自定义度量指标

自定义检查通常会经过此序列，使用不同的方法来收集它支持的相关自定义度量指标的值。默认情况下，检查每 15 秒运行一次，这一行为可以通过设置配置项min_collection_interval进行控制。

使用自定义命名空间定义度量指标还有其他优点。自定义检查将被识别为主机仪表盘上的应用程序，如以下截图所示，其中使用命名空间标识了自定义检查及其生成的度量指标：

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/dtl-cld-mnt-qkstgd/img/Figure_8.8_B16483.jpg)

图 8.8 – 自定义检查列为应用程序

仪表盘还会将 NGINX 集成跟踪为主机仪表盘上的应用程序之一。

现在让我们在接下来的部分中回顾一下与本章所涵盖的主题相关的最佳实践。

最佳实践

在 Datadog 提供的集成和其提供的自定义集成接口之间，你有很多可用的选择，因此最好遵循最佳实践，而不是实现一个虽然可行但不够优化的方案：

• 完全探索所有 Datadog 提供的集成，并检查是否可以通过这些集成满足监控需求。在监控的上下文中，自定义代码和配置的开发成本高，易出错，且难以部署和维护，因此你应该将编写自定义代码作为最后的手段。

• 如果没有现成的 Datadog 支持的集成，请检查社区维护的庞大集成库。

• 如果你需要调整一个社区维护的集成使其适合你的需求，考虑参与该项目并公开提交更改，因为这样可以帮助获得 Datadog 社区的有价值反馈。

• 在开始使用标签和自定义指标进行集成之前，先制定命名策略。对指标进行系统化命名并使用合适的命名空间，有助于轻松地组织和聚合它们。

• 将用于启用和实现集成的自定义代码和配置保存在源代码控制系统中作为备份，并且可以选择将其作为自动化配置 Datadog 资源的源，使用如 Terraform 和 Ansible 等工具。这个最佳实践不仅适用于集成；每当自定义代码和配置参与设置任何内容时，都应遵循这一原则。

• 在公有云环境中，启用集成所需的主机级配置必须内嵌到机器镜像中。例如，在 AWS 中，这些配置和自定义代码以及 Datadog Agent 软件可以作为相关 AMI 的一部分进行部署，用于创建主机。

总结

我们已经探讨了 Datadog 提供的集成以及自行实现集成的选项。一个监控大规模生产环境的 Datadog 环境通常会使用现成集成和自定义检查的组合。虽然在 Datadog 中推出自定义检查非常简单，但建议你考虑实施这些检查的总成本。在本章中，你已经学习了如何选择合适的集成并进行配置。此外，你还学习了如何在缺少现成集成的情况下进行自定义检查。

在继续讨论如何扩展 Datadog 以超越其现成功能的过程中，下一章我们将探讨如何使用 Datadog API 来访问 Datadog 功能，并利用这些功能来实现自定义集成。

第九章：使用 Datadog REST API

在上一章中，您学习了如何通过 Datadog 支持的集成和自定义检查将平台组件，主要由第三方软件产品和云服务组成，集成到 Datadog 中。这些集成的主要目标是通过 Datadog 监控应用栈中使用的第三方工具。Datadog 的集成也可以反向进行。工具和脚本可以使用 Datadog 的 HTTP REST API 以编程方式访问 Datadog 平台。例如，如果您需要从应用程序向 Datadog 发布一个指标值或事件，可以使用相关的 REST API 来完成。

Datadog REST API 集是一个全面的编程接口，用于访问 Datadog 监控平台。这些 API 可用于发布自定义指标、创建监控器和仪表板、标记各种资源、管理日志以及创建和管理用户和角色。本质上，您可以在 Datadog UI 中执行的任何操作，以及在代理级别进行配置更改的操作，都可以通过这些 API 完成。

在本章中，您将通过教程学习如何使用命令行工具和编程语言操作 Datadog API。具体来说，以下主题将被涵盖：

• 脚本化 Datadog

• 审查 Datadog API

• 使用 Datadog API 进行编程

技术要求

要尝试本书中的示例，您需要安装以下工具并确保资源可用：

• 拥有 API 密钥的 Datadog 帐户

• 风格，请全面检查

• Python 2.7 或 Python 3.8 或更高版本

脚本化 Datadog

本节中，您将学习如何使用 curl 命令行工具调用 Datadog API，并了解如何在 Python 中使用这些 API。访问 Datadog 平台进行编程操作的一个重要前提是设置用户访问权限。虽然在访问 Datadog UI 时，通过专用用户凭证或 SAML 进行身份验证，但使用 Datadog API 时则需使用一对应用密钥和 API 密钥。让我们来看看这些密钥是如何设置的。

通过导航至Team | Applications Keys，您可以在Application Keys页面创建一对新的应用密钥，如下图所示：

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/dtl-cld-mnt-qkstgd/img/Figure_9.1_B16483.jpg)

图 9.1 – 生成应用密钥

点击New Key按钮并为其提供新名称即可创建一个新的密钥。新生成的密钥将在相同的Application Keys页面中列出。您可以通过点击前表中列出的特定密钥来查看和复制该密钥，如下图所示：

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/dtl-cld-mnt-qkstgd/img/Figure_9.2_B16483.jpg)

图 9.2 – 查看应用密钥

通过在 Datadog 仪表板中导航至Integrations | APIs，您可以进入 API 页面，在那里可以创建新的 API 密钥或复制现有的 API 密钥，如下图所示：

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/dtl-cld-mnt-qkstgd/img/Figure_9.3_B16483.jpg)

图 9.3 API 密钥页面

通过在新 API 密钥字段中提供名称并点击创建 API 密钥按钮，可以生成新的密钥。生成的密钥会如前述截图所示列出。

应用程序密钥是唯一的，属于设置它的 Datadog 组织。API 密钥与 Datadog 用户绑定，因此它继承了相关的权限。为了从程序中进行身份验证，必须使用应用程序密钥和 API 密钥，分别标识组织和用户。我们将在示例程序中看到如何使用应用程序和 API 密钥对，进一步说明密钥的使用。

可以通过像 curl 这样的命令行工具调用 Datadog API，作为临时 shell 脚本的一部分，或者使用如'Python'、'Go'和'Java'等编程语言调用。在本节中，你将学习如何从 curl 和 Python 发起 API 调用。

curl

在以下示例中，我们将看到如何使用简单的curl API 调用来查询 Datadog 监控的主机。如你所见，JSON 输出是冗长的，通常用于自动化处理，而非手动查看：

$ curl -s -X GET https://app.datadoghq.com/api/v1/hosts -H "Content-Type: application/json" -H "DD-API-KEY: cd5bc9603bc23a2d97beb118b75f7b11" -H "DD-APPLICATION-KEY: 21f769cbd8f78e158ad65b5879a36594c77eb076" |python -m json.tool
            "metrics": {
                "cpu": 15.446295,
                "iowait": 0,
                "load": 1.0077666
            },
            "mute_timeout": null,
            "name": "thomass-mbp-2.lan",
            "sources": [
                "agent"
            ],
            "tags_by_source": {
                "Datadog": [
                    "host:thomass-mbp-2.lan"
                ]
            },
            "up": true
        }
    ],
    "total_matching": 1,
    "total_returned": 1
}

(这里只提供了输出的一部分，完整版本可以在本章的 GitHub 仓库中找到。)

输出内容冗长，前面的代码仅为其一部分。结果提供了关于 Datadog 代理运行的主机的详细信息。

尽管这是一个简单的 API 调用，但从这个示例中，你可以学到关于 Datadog API 和 curl 的多种内容，因此我们将一一解析。

不仅命令行工具 curl 需要在本地环境中安装，通常是在操作系统的某些 Unix shell 中，还必须确保 Python 可用。需要 Python 是因为 API 调用的输出会被传递到 Python 模块json.tool，该模块用于格式化输出，使其更易读。因此，在这种情况下，Python 是可选的，但你需要 Python 来运行其他示例程序。

让我们逐一看看curl调用中的每个部分：

• 传递给 curl 的-s开关可以让工具在执行过程中不输出关于自身工作的消息。这是在输出需要被另一个工具或代码解析时的好做法，避免与 API 调用的结果混合。

• -X GET是使用的 HTTP 动词或方法，curl 的-X选项用于指定这一点。GET方法允许读取资源，当从任何工具（包括 curl）发起 REST API 调用时，GET是默认方法。因此，在这种情况下，没有必要使用-X GET，因为GET是默认动词。其他重要的方法包括POST（用于创建新资源）、PUT（用于更新资源）和DELETE（用于删除现有资源）。我们将在本章中看到这些方法的使用；请注意，POST和PUT可以互换使用。

• app.datadoghq.com 是访问 Datadog 后端的 URL。

• /api/v1/hosts 是用于列出主机的 API 端点。API 端点对应于可以通过 REST API 访问的资源。与 API 端点一起使用的 HTTP 方法确定操作的性质。（这些约定并不总是严格遵循。）例如，GET返回有关现有主机的详细信息，而POST或PUT调用可以用于对相同资源进行一些更改。

• curl 的-H选项允许您作为 API 调用的一部分传递 HTTP 头部。在这个例子中，传递了三个这样的头部Content-Type，DD-API-KEY和DD-APPLICATION-KEY。实际上，头部可以被视为 API 调用的输入。使用POST和PUT方法时，可以使用 curl 的-d选项将数据作为输入传递给调用（类似于为 Web 表单传递输入），但是在GET调用中，头部是唯一的选择。在这种情况下，Content-Type告诉 API 以 JSON 格式返回结果。

• 如名称所示，头部DD-API-KEY和DD-APPLICATION-KEY用于指定用于身份验证的 API 密钥和应用程序密钥对。本示例中使用的密钥是在本节中先前生成的密钥。

• python -m json.tool用于格式化 API 调用的 JSON 输出，以提高可读性。请注意，这不是 API 调用的一部分。管道符号（在 Unix shell 术语中称为管道）用于组合这两个命令以生成前面的输出。

现在，让我们使用不同的选项集合进行相同的 API 调用，以说明使用curl与 Datadog REST API 的用法：

$ curl -i https://app.datadoghq.com/api/v1/hosts  -H "DD-API-KEY: cd5bc9603bc23a2d97beb118b75f7b11" -H "DD-APPLICATION-KEY: 21f769cbd8f78e158ad65b5879a36594c77eb076"
HTTP/2 200 
date: Sun, 24 Jan 2021 22:48:05 GMT
content-type: application/json
content-length: 2687
vary: Accept-Encoding
pragma: no-cache
cache-control: no-cache
set-cookie: DD-PSHARD=134; Max-Age=604800; Path=/; expires=Sun, 31-Jan-2021 22:48:05 GMT; secure; HttpOnly
x-dd-version: 35.3760712
x-dd-debug: V1SoipvPhHDSfl6sDy+rFcFwnEIiS7Q6PT
TTTi5csh65nTApZwN4YpC1c2B8H0Qt
x-content-type-options: nosniff
strict-transport-security: max-age=15724800;
content-security-policy: frame-ancestors 'self'; report-uri https://api.datadoghq.com/csp-report
x-frame-options: SAMEORIGIN

在这个curl调用的版本中，输出没有格式化，但是非常有用的curl选项-i被使用。它会在结果中添加头信息，可以用来更好地处理输出。输出的第一行中重要的头信息是 HTTP 状态码HTTP/2 200。在自动化脚本中查看 HTTP 状态码是重要的，以便在 REST API 调用失败时采取适当的操作。200系列状态码指示 API 调用成功。查看 API 调用结果头部的信息对于使您的脚本更加健壮是很重要的。300系列状态码与 URL 重定向相关，400系列状态码指示客户端调用问题，如错误的 URL 和身份验证问题，而500系列状态码指示服务器端问题。总的来说，查看 API 调用结果头部中的信息对于使您的脚本更加健壮是很重要的。

现在让我们看看如何使用curl进行POST API 调用，这将对资源进行某些更改。在下面的示例中，通过编程方式静音所选主机，以防止发送任何警报通知：

$ curl -i -X POST https://app.datadoghq.com/api/v1/host/thomass-mbp-2.lan/mute  -H "DD-API-KEY: cd5bc9603bc23a2d97beb118b75f7b11" -H "DD-APPLICATION-KEY: 21f769cbd8f78e158ad65b5879a36594c77eb076" -d @mute.json
HTTP/2 200 
date: Mon, 25 Jan 2021 01:21:59 GMT
content-type: application/json
content-length: 74
vary: Accept-Encoding
pragma: no-cache
cache-control: no-cache
set-cookie: DD-PSHARD=134; Max-Age=604800; Path=/; expires=Mon, 01-Feb-2021 01:21:59 GMT; secure; HttpOnly
x-dd-version: 35.3760712
x-dd-debug: HbtaOKlJ6OCrx9tMXO6ivMTrEM+g0c93H
Dp08trmOmgdHozC5J+vn10F0H4WPjCU
x-content-type-options: nosniff
strict-transport-security: max-age=15724800;
content-security-policy: frame-ancestors 'self'; report-uri https://api.datadoghq.com/csp-report
x-frame-options: SAMEORIGIN
{"action":"Muted","downtime_id":1114831177,"hostname":"thomass-mbp-2.lan"}

以下是需要从前面的示例中注意的新要点：

• 使用curl选项-X作为 API 调用方法的POST。

• API 端点 /api/v1/host/thomass-mbp-2.lan/mute 包含主机名，该主机名将在 API 调用中被更改，并执行相应操作。

• 输入通过 curl 选项 -d 提供。@ 符号表示它前面的字符串是一个文件名，输入必须从该文件中读取。如果没有 @ 修饰符，字符串将被视为字面量输入。请查看示例程序中使用的输入文件 mute.json 的内容：

  {
    "action": "Muted",
    "end": 1893456000,
    "message": "Muting my host using curl"
  }
  

  输入参数是特定于 API 端点的，必须提供所需的信息。

• 来自 Datadog 后端的 JSON 消息是输出的最后部分。虽然它能提供 API 调用结果的一些提示，但其成功与否必须结合 HTTP 状态码来判断，正如你在之前的示例中所学到的：

  HTTP/2 200 
  {"action":"Muted","downtime_id":1114831177,"hostname":"thomass-mbp-2.lan"}
  

如果你在 Datadog UI 中查看相同的主机，你可以验证它是否被静音，如下图所示：

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/dtl-cld-mnt-qkstgd/img/Figure_9.4_B16483.jpg)

图 9.4 – 主机被程序化静音

curl 是一个非常有用的工具，可以从脚本中调用 Datadog API。然而，对于更强大的自动化，你需要使用 Python 等编程语言。

Python

现在，让我们看看如何通过 Python 调用 Datadog REST API。尽管 curl 工具不可忽视，但在严肃的自动化项目中，通常会使用 Python 等功能全面的编程语言来构建用于生产的程序。同样，Go、Java 和 Ruby 等其他编程语言也得到了 Datadog 的支持，Datadog 为 REST API 提供了特定语言的包装器。

在下面的示例 Python 程序中，一个自定义事件被发布到 Datadog 后端：

# post-event.py
from datadog import initialize, api
options = {
    "api_key": "cd5bc9603bc23a2d97beb118b75f7b11",
    "app_key": "21f769cbd8f78e158ad65b5879a36594c77eb076",
}
initialize(**options)
title = "Event from Datadog tutorial book"
text = "Hello World! My test program finally worked and posted an event!"
tags = ["application:pymonitor"]
api.Event.create(title=title, text=text, tags=tags)

测试程序是不言自明的。所有需要的输入都已在其中硬编码，包括用于用户身份验证的密钥对。在实际生产中使用的程序中，密钥的使用会被参数化，以提高灵活性和安全性。程序中预期的异常将被处理，以增强健壮性。

你需要在本地环境中安装 Python 和 Datadog 客户端库才能运行该程序。Datadog 客户端库可以作为 Python 模块使用 pip 工具安装，pip 通常与 Python 一起安装：

$ pip install datadog

上面的示例 Python 代码可以保存为 post-event.py，并可以通过以下方式使用 Python 调用来运行：

$ python post-event.py

该程序的成功执行可以通过 Datadog UI 的 事件 仪表板验证，如下图所示：

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/dtl-cld-mnt-qkstgd/img/Figure_9.5_B16483.jpg)

图 9.5 – Python 程序发布的事件

注意程序提供的标题、正文和标签信息是如何转换为新发布事件的相应属性的。

通过这些示例，你学习了如何使用 curl 和 Python 调用 Datadog API 的基础知识。在下一部分，你将概览一些重要的 API，这些 API 可用于将应用程序与 Datadog 集成。

查看 Datadog APIs

在本节中，我们将讨论可以使用 REST API 访问和管理的主要 Datadog 功能。正如前面提到的，您在 Datadog UI 上可以做的任何事情都可以通过 Datadog APIs 的代码完成。在高度自动化的环境中，这个选项非常方便，因为所有与监控相关的活动都可以集中在 Datadog 平台上。如果应用程序不直接支持集成，那么使用 REST APIs 进行自定义集成是可行的最佳选择之一。（也有特殊情况下可以使用 StatsD 和 JMX 等监控标准，我们将在下一章节《使用监控标准》中讨论如何使用这些标准。）

让我们来看看 Datadog APIs 的广泛分类。

公共云集成

通过与主要公共云平台 AWS、Azure 和 GCP 集成，Datadog 可以在没有任何代理的情况下导入基础设施信息。相关的配置更改可以使用 Datadog APIs 程序化地完成。

典型用例可能是提供一个需要与 Datadog 集成的新公共云账户。在成熟的环境中，使用 Terraform 或 自定义脚本 或两者结合的工具自动进行公共云资源的配置，而 Datadog APIs 则可作为基础设施配置过程中添加 Datadog 集成支持的有用工具。

仪表板

您可以通过 Datadog UI 执行的仪表板任务也可以使用 APIs 完成。以下是覆盖仪表板整个生命周期的一些重要 API 终点：

• 创建一个仪表板

• 列出现有仪表板

• 获取关于仪表板的详细信息

• 更新和删除现有仪表板

• 发送邀请与其他用户共享仪表板

• 撤销仪表板共享

停机时间

停机是为了阻止监视器发送警报通知。如前所述，这类配置在某些操作原因（如将代码推送到生产环境时）是必要的。停机的生命周期，从计划到取消，可以使用相关 APIs 进行管理。

事件

在上一节中，您看到可以通过 API 调用将事件发布到 Datadog 事件流。APIs 也可用于获取事件的详细信息以及使用标签等过滤器查询事件。

主机

使用 APIs 可以收集关于由 Datadog 监控的主机的详细信息，以下是一些重要的细节：

• 活跃主机的总数

• 所有由 Datadog 监控的主机的详细信息

• 关于静音/取消静音主机的详细信息

指标

使用 Datadog APIs，可以执行以下与指标相关的任务：

• 将指标数据发布到 Datadog 后端

• 查询已发布到 Datadog 后端的指标数据

发布和查询指标数据的 API 被广泛用于与 Datadog 的集成。由于 Datadog 拥有出色的图表、仪表盘和监控管理功能，因此将监控数据以时间序列数据的形式展示在 Datadog 平台上非常具有吸引力。

在下一节中，您将学习如何将自定义指标数据发布到 Datadog，并稍后使用它来构建有用的监控器。

监控器

监控器观察指标数据，并根据设定的阈值进行检查和通知。监控器的整个生命周期可以通过 API 进行管理，包括以下任务：

• 监控器的生命周期阶段，例如创建、更新和删除监控器

• 获取监控器的详细信息

• 搜索监控器

• 静音监控器

在下一节中，您将学习如何使用一些特定的 API 端点来管理监控器。

主机标签

您已经了解到，标签是 Datadog 中用于组织和筛选信息（尤其是指标数据）的重要资源类型。Datadog 提供了优秀的 API 支持来应用和管理主机级别的标签。以下是主要的 API 端点：

• 添加、更新和删除主机级别的标签。

• 列出在主机级别定义的标签。

一般来说，Datadog API 端点用于管理资源时，提供了将标签应用于资源的选项。此外，标签还可以作为查询这些资源时的筛选选项之一。您将在下一节的示例程序中学习如何做到这一点。

本节仅涵盖了重要资源和相关 API 端点。要获取 Datadog API 的最完整和最新信息，起点是官方的 Datadog API 页面：docs.datadoghq.com/api/。

下一节是一个教程，通过使用示例 Python 程序进一步解释 Datadog API 的使用。

使用 Datadog API 编程

在本节教程中，您将学习如何发布自定义指标，并使用该自定义指标以编程方式设置监控器。您还将学习如何将事件发布到 Datadog 事件流，并使用关键字搜索事件流。然后，您将基于新创建的自定义指标设置一个监控器。您还将了解这些事件、创建自定义指标和监控器的过程是如何发布到事件流中的。最后，您将学习如何使用已知标签查询事件流，以帮助程序化地定位先前发布到事件流中的事件。

问题

在本教程中，假设您正在维护一个电子商务网站，并需要按小时监控业务的表现，管理层可能对这些数据感兴趣。有一个自定义程序用来查询公司订单管理系统中的每小时订单数据，并将指标数据发布到 Datadog，且该程序计划每小时运行一次。

一旦度量数据可用，就可以在 Datadog 中用于构建监控和仪表盘。此外，每当自定义程序的每小时运行完成时，它将发布一个事件到 Datadog 事件流，表示每小时作业的完成。这可以确保如果调度作业出现问题，你可以从事件流中获得详细信息。

发布度量数据和事件

以下 Python 程序将发布订单的每小时计数和相关事件到 Datadog 平台：

# post-metric-and-event.py
import sys
import time
from datadog import initialize, api
options = {
    "api_key": "cd5bc9603bc23a2d97beb118b75f7b11",
    "app_key": "21f769cbd8f78e158ad65b5879a36594c77eb076",
}
initialize(**options)
# Get the hourly count as a parameter.
orders_count=int(sys.argv[1])
ts=time.time()
tag_list=["product:cute-game1","fulfillment_type:download"]
# Post metric data
api.Metric.send(
   metric='mycompany.orders.hourly_count', 
   points=(ts,orders_count),
   tags=tag_list)
# Set event info for posting
title = "Posted hourly sales count"
text = "Hourly sales count has been queried from order fulfillment system and posted to Datadog for tracking.\nHourly Count: "+sys.argv[1]
# Post event
api.Event.create(title=title, text=text, tags=tag_list)
The Python code provided here can be saved in a file named post-metric-and-event.py and it could be executed as follows from a UNIX shell with Python installed:
$ python post-metric-and-event.py SALES_ORDERS_COUNT 

让我们仔细看看这个程序。第一部分与身份验证和应用客户端初始化相关，这些内容你已经在第一个 Python 示例程序中见过。orders_count 值作为参数传入这个程序，该值在命令行中显示为 SALES_ORDERS_COUNT,，在程序执行时应该用一个真实的数字来替换。在实际应用中，另一个程序会估算出这个数字并将其传递给这个 Python 程序。销售订单数量也可以在 Python 程序中进行估算，这种情况下就不需要将 orders_count 作为参数传入。

当前的时间戳存储在一个变量中，并在稍后的时间序列度量数据发布中使用，如下所示：

ts=time.time()

ts 存储与当前时间相关的 Unix 时间戳，它与度量值一起传递：

tag_list=["product:cute-game1","fulfillment_type:download"]

tag_list 设置了一个标签数组，这些标签会应用到发布到 Datadog 的度量数据上。

以下是将度量数据发布到 Datadog 的 API 调用：

api.Metric.send(
   metric='mycompany.orders.hourly_count', 
   points=(ts,orders_count),
   tags=tag_list)

metric 应该是度量的名称，且不需要显式创建——只要带有数据点进行发布即可。points 必须是一个元组，包含时间戳和一个标量值，表示该时间点的度量值。

度量值必须是一个数字，这就是为什么在示例程序中，orders_count 从命令行传入的值被转换为整数的原因：

orders_count=int(sys.argv[1]) 

程序的第二部分是设置事件的文本并将其发布到 Datadog。在执行完这个程序后，结果可以在 Datadog 用户界面上进行验证。

可以使用 Metrics Explorer 查找度量和度量时间序列数据，如下图所示：

图 9.6 – 在 Metrics Explorer 中列出的自定义度量

在 mycompany.orders.hourly_count 中可以查找到相关信息。应用于自定义度量的标签可以在 Over 字段中查看。如果对不同的产品和履约类型跟踪相同的度量，可以通过为标签应用适当的值轻松区分这些度量。

发布的事件可以在 Events stream 仪表盘中查看，如下图所示：

图 9.7 – 发布到事件流的自定义事件

你可以通过视觉方式验证程序发布的详细信息是否按预期出现在事件流中。如果由于某种原因每小时销售数量的聚合失败，这种状态也可以发布到事件流中，对于那些需要处理故障的人员来说，这将是一个重要的信息。

创建监控

让我们尝试使用刚创建的自定义指标程序化地设置监控。管理层可能需要知道每小时订单数是否低于100。在这种简单的场景下，可以设置监控来触发警报：

# create-monitor.py
from datadog import initialize, api

options = {
    "api_key": "cd5bc9603bc23a2d97beb118b75f7b11",
    "app_key": "21f769cbd8f78e158ad65b5879a36594c77eb076",
}
initialize(**options)
tag_list=["product:cute-game1"]
# Create a new monitor
monitor_options = {
   "notify_no_data": True,
   "no_data_timeframe": 20
}
api.Monitor.create(
    type="metric alert",
    query="avg(last_5m):avg:mycompany.orders.hourly_count{*} < 100",
    name="Hourly order count fell below 100",
    message="The order count dropped dramatically during the last hour. Check if everything is alright, including infrastructure",
    tags=tag_list,
    options=monitor_options
)

这个 Python 程序的第一部分类似于你之前看到的 Python 程序。该程序中需要关注的主要内容是调用api.Monitor.create。这个 API 接受几个选项，可以精细配置监控。为了清晰起见，本示例只使用了必需的参数。

如果程序成功执行，新的监控将会在 Datadog UI 的Monitors仪表盘中列出。

为了生成触发警报的数据，可以多次运行post-metric-and-event.py程序，销售量低于100。等待 5 分钟后，你会看到新创建的监控变为红色，表示监控处于临界状态，如下图所示：

图 9.8 – 监控 "每小时订单数降至 100 以下" 触发警报

程序化创建监控通常是某些配置过程的一部分，其中新配置的资源必须使用相关的指标数据进行监控。

查询事件流

作为将自定义指标值发布到 Datadog 后端的一部分，脚本还将事件发布到事件流中。我们已验证该事件来自fulfillment_type:download，且时间不超过500秒：

# query-events.py 
import time
import json
from datadog import initialize, api
options = {
    "api_key": "cd5bc9603bc23a2d97beb118b75f7b11",
    "app_key": "21f769cbd8f78e158ad65b5879a36594c77eb076",
}
initialize(**options)
end_time = time.time()
start_time = end_time - 500
result = api.Event.query (
    start=start_time,
    end=end_time,
    priority="normal",
    tags=["fulfillment_type:download"],
    unaggregated=True
)
print (json.dumps(result, sort_keys=True, indent=4))

该脚本不言自明：start和end，API api.Event.query的两个参数，设置了要考虑的事件时间范围，进一步的筛选是通过标签fulfillment_type:download来完成的，这是之前发布的自定义事件上应用的标签之一。基本上，这个程序将能够定位由自定义事件发布的最近事件。

程序的最后一行以一种易于阅读的格式打印结果，格式如下：

$ python query-events.py 
{
    "events": [
        {
            "alert_type": "info", 
            "comments": [], 
            "date_happened": 1611721000, 
            "device_name": null, 
            "host": "thomass-mbp-2.lan", 
            "id": 5829380167378283872, 
            "is_aggregate": false, 
            "priority": "normal", 
            "resource": "/api/v1/events/5829380167378283872", 
            "source": "My Apps", 
            "tags": [
                "fulfillment_type:download", 
                "product:cute-game2"
            ], 
            "text": "Hourly sales count has been queried from order fulfillment system and posted to Datadog for tracking.\nHourly Count: 300", 
            "title": "Posted hourly sales count", 
            "url": "/event/event?id=5829380167378283872"
        }
    ]
}

如输出所示，JSON 结果包含了该事件的所有属性，可以在Events仪表盘上查看，甚至更多。通常，像这样的程序将是另一个自动化的一部分，在这个自动化中，事件将被查询，用于跟踪定时程序的状态，该程序将每小时销售订单估算数据作为指标发布到 Datadog 平台。

尽管我们在本节中看到的示例很简单，但它们可以轻松扩展为实现各种集成和自动化需求的有用程序。

接下来，让我们来看一下使用 Datadog API 的最佳实践。

最佳实践

我们回顾了 Datadog API，并学习了如何通过 curl 和 Python 调用它们的基础知识。现在，让我们看看使用 API 来自动化监控任务的最佳实践：

• 如前所述，在编写自己的代码之前，尽量多利用现有的集成功能使用 Datadog API。主要原因是，长期维护自定义代码通常成本较高。

• 如果您必须编写使用 API 的代码，请从一开始就将其维护在源代码控制系统中。

• 正如我们在示例程序中看到的，考虑从其他内部系统中提取有用的监控信息，并使用 API 将其作为指标和事件发布到 Datadog 平台。Datadog 是一个优秀的平台，可以从不同来源汇总信息，应该被充分利用，以扩展组织的整体监控能力。

• 可以使用 API 从 Datadog 中提取数据，并将其加载到流行的报告工具中，以满足定制的报告需求。同样的方法也可以用于通过编程方式将与基础设施相关的状态发布到其他内部系统。

总结

在本章中，您主要学习了如何使用 curl 和 Python 与 Datadog 平台进行交互，利用 Datadog API。此外，我们还了解了 Datadog 提供的主要 API 类别。这里需要记住的重要一点是，几乎所有您在 Datadog UI 上能做的事情，都可以通过使用适当的 API 以编程方式完成。

我们将继续研究 Datadog 的集成选项，在下一章中，您将专门学习一些所有主要监控应用程序（包括 Datadog）所实施的重要监控标准。

第十章：使用监控标准

你已经看到 Datadog 提供的集成和 REST API 在扩展 Datadog 功能方面的实用性。本章将探讨更多可用于扩展这些功能的选项，这些选项本质上是监控领域标准的实现，以及如何使用它们来部署自定义的监控需求。

本章涵盖的主题包括：

• 使用 SNMP 监控网络

• 使用 JMX 消费应用程序指标

• 使用 DogStatsD 接口

技术要求

要尝试本书中提到的示例，你需要安装以下工具并准备好相关资源：

• 带有 Bash shell 的Ubuntu 18.04环境。示例可能也适用于其他 Linux 发行版，但需要对特定于 Ubuntu 的命令做出相应更改。

• 具有管理员级别访问权限的 Datadog 账户。

• Datadog 代理运行在主机级别或作为微服务，具体取决于示例，指向 Datadog 账户。

• curl。

• Python 2.7，Python 3.8或更高版本

使用 SNMP 监控网络

简单网络管理协议（SNMP）是一种用于管理网络设备的协议。它已被用来跟踪网络中的设备及其性能，供应商也将其作为发布相关数据的标准。即使在公共云环境中，网络监控的需求几乎为零，在大规模操作环境中，设置一个同机房连接客户或内部管理一些物理网络设备始终是可能的。将这些设备接入现有的 Datadog 平台可能会很方便，而不是为此推出另一个监控解决方案。

在启用了 SNMP 的设备上，代理从设备收集性能指标并将其存储在snmpwalk中，snmpwalk是一个流行的命令行工具，用于扫描设备以获取此类数据。Datadog 与 SNMP 集成，可以配置代理扫描多个网络设备以收集指标。

由于网络设备并不容易找到，特别是在云环境中，我们将运行 SNMP 服务在虚拟机上，并使用snmpwalk查看指标。此外，启用 Datadog 中的 SNMP 集成的步骤也将通过该环境进行说明。

你需要一台 Ubuntu 主机来尝试以下的 SNMP 教程。这些步骤是在运行Ubuntu 18.04的 AWS EC2 节点上测试的：

1. 安装 SNMP 包：

   $ sudo apt-get install snmpd snmp snmp-mibs-downloader
   

2. 编辑/etc/snmp/snmp.conf并注释掉mibs的配置。

3. 重启 SNMP 守护进程：

   $ sudo /etc/init.d/snmpd restart
   

4. 这些步骤足以让 SNMP 服务在本地启动并运行，你可以使用snmpwalk扫描该服务：

$ snmpwalk -mALL -v2c -cpublic localhost  2>/dev/null
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-TC::linux
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (346799) 0:57:47.99
SNMPv2-MIB::sysContact.0 = STRING: Me <me@example.org>
SNMPv2-MIB::sysName.0 = STRING: ip-172-31-31-12
SNMPv2-MIB::sysLocation.0 = STRING: Sitting on the Dock of the Bay
SNMPv2-MIB::sysServices.0 = INTEGER: 72
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (2) 0:00:00.02
SNMPv2-MIB::sysORID.1 = OID: SNMP-MPD-MIB::snmpMPDCompliance
SNMPv2-MIB::sysORID.2 = OID: SNMP-USER-BASED-SM-MIB::usmMIBCompliance
SNMPv2-MIB::sysORUpTime.1 = Timeticks: (1) 0:00:00.01
HOST-RESOURCES-MIB::hrSystemUptime.0 = Timeticks: (760881) 2:06:48.81
HOST-RESOURCES-MIB::hrSystemDate.0 = STRING: 2021-1-31,6:53:37.0,+0:0
HOST-RESOURCES-MIB::hrSystemInitialLoadDevice.0 = INTEGER: 393216
HOST-RESOURCES-MIB::hrSystemNumUsers.0 = Gauge32: 1
HOST-RESOURCES-MIB::hrSystemProcesses.0 = Gauge32: 103
HOST-RESOURCES-MIB::hrSystemMaxProcesses.0 = INTEGER: 0

(此输出仅为摘录。)

如示例输出所示，扫描结果中可以获取不同的系统性能度量。我们来看看 snmpwalk 使用的命令行选项。启用 Datadog SNMP 集成时也需要类似的信息：

• -mALL 选项指示 snmpwalk 查看所有可用的 MIB。在 Ubuntu 主机上，这些文件存储在 /usr/share/snmp/mibs 目录下。

• -v2c 指定将使用的 SNMP 协议版本。共有三个版本，在 Datadog 中默认为 v2，与此处使用的版本相同。

• -cpublic 表示扫描所使用的社区字符串是 public。在 SNMP 协议的 v1 和 v2 版本中，社区字符串类似于密码。在 v3 中，社区字符串被凭证认证取代。

现在，我们来看一下如何配置 Datadog 中的 SNMP 集成，以访问在 Ubuntu 主机上运行的 SNMP 服务：

1. 通过复制示例文件来设置 conf.yaml：

   $ cd /etc/datadog-agent/conf.d/snmp.d
   $ cp conf.yaml.example conf.yaml
   

2. 编辑 conf.yaml 并启用以下设置：在 instances 部分，将 ip_address 指向 127.0.0.1，即本地主机。

3. 将 community_string 设置为 public。

4. 添加两个自定义标签，以便轻松跟踪 SNMP 集成发布的度量：

   tags:
          - integration:snmp
          - metrics-type:ubuntu-snmp
   

5. 重新启动 Datadog 代理，以使这些更改生效。检查状态并通过运行以下命令验证 Datadog 代理是否可以本地查询 SNMP 服务：

$ sudo datadog-agent status
    snmp (3.5.3)
    ------------
      Instance ID: snmp:98597c6009cbe92e [OK]
      Configuration Source: file:/etc/datadog-agent/conf.d/snmp.d/conf.yaml
      Total Runs: 96
      Metric Samples: Last Run: 2, Total: 192
      Events: Last Run: 0, Total: 0
      Service Checks: Last Run: 1, Total: 96
      Average Execution Time : 7ms
      Last Execution Date : 2021-01-31 08:16:21.000000 UTC
      Last Successful Execution Date : 2021-01-31 08:16:21.000000 UTC

通过此集成发布到 Datadog 的度量可以在Metrics Explorer中查看，如下截图所示：

图 10.1 – 从 SNMP 集成中查看度量

可以在 SNMP 集成配置文件的 instances 部分指定多个网络设备，并且可以使用适当的标签区分这些度量。Datadog 代理可以配置为扫描整个网络子网，查找支持 SNMP 的设备。有关详细信息和配置，请参考官方文档 docs.datadoghq.com/network_performance_monitoring/devices/setup。

在接下来的部分，我们将讨论JMX，这是一个与 Java 应用程序监控相关的重要领域，您将了解 Datadog 如何与其集成。

使用 JMX 消费应用程序度量

Java 管理扩展 (JMX) 是一种 Java 技术，Java 应用程序可以使用它发布其操作统计信息。JMX 具有额外的功能，可以帮助管理应用程序整体，但我们这里只关注其暴露应用程序度量的能力，这些度量可用于监控。Datadog 提供对这些度量的收集支持。

通常，可以使用符合 JMX 标准的客户端应用程序，如JConsole，来消费 JMX 发布的指标并查看它们。由于 Java 应用程序通常使用 JMX 发布操作性指标，大多数现代监控平台都提供与 JMX 集成的选项，Datadog 也不例外。

推出应用级别的监控本身就很具挑战性，因为它依赖于发布自定义指标来跟踪应用程序的健康状况和性能。由于应用程序和监控工具需要做一些定制化工作才能发布和消费自定义指标，因此这类工作并不容易实现，因此在许多组织中，监控通常仅限于基础设施和平台监控功能，这些功能是开箱即用的。对于 Java 应用程序而言，使用 JMX 发布指标要比为监控构建 API 接口容易得多。Datadog 通过为流行的基于 Java 的平台组件，如Cassandra 和 Tomcat，提供特定的 JMX 集成，简化了 JMX 的使用，这些组件通过 JMX 发布操作性指标，此外还提供了通用的 JMX 集成。你将在本节中通过示例了解这两种特性。

Cassandra 作为一个 Java 应用程序

Apache Cassandra 是一个高可扩展性的 NoSQL 数据库系统，可以管理跨多个数据中心和云区域的结构化和非结构化数据。它可以在普通硬件上运行，并具有高度的韧性设计。

在生产环境中，Cassandra 运行在一个由多台机器组成的集群中，这些机器可能跨越多个数据中心以保证可靠性。为了演示其 JMX 特性，我们将在单节点上运行它，使用可以从cassandra.apache.org/download/下载的二进制tarball安装包，你还可以从该网址下载最新的稳定版本：

1. 选择的 tarball 可以通过以下示例命令下载：

   $ curl -OL https://apache.claz.org/cassandra/3.11.9/apache-cassandra-3.11.9-bin.tar.gz
   

2. 解压 tarball 并切换到解压后的目录：

   $ tar xzf apache-cassandra-3.11.9-bin.tar.gz
   $ cd apache-cassandra-3.11.9
   

3. 确保环境中可用Java 8。如果没有，安装它。在 Ubuntu 主机上，可以通过安装包来完成，方法如下：

   $ sudo apt install openjdk-8-jre-headless -y
   

4. 如下所示启动 Cassandra 服务：

$ bin/cassandra

如果一切顺利，且此实例不打算与应用程序一起使用，那基本就是这样了。你可以使用此服务来测试 Datadog 的 JMX 支持。

现在，让我们看看 Cassandra 的运行时细节和相应的 nodetool，你还可以查看日志以排查问题：

$ bin/nodetool status
Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address    Load       Tokens       Owns (effective)  Host ID                               Rack
UN  127.0.0.1  70.71 KiB  256          100.0%            03262478-23a3-4bd4-97f1-bc2c837ad650  rack1
      $ tail -f logs/system.log
INFO  [main] 2021-01-29 06:05:27,118 CassandraDaemon.java:650 - Startup complete
INFO  [OptionalTasks:1] 2021-01-29 06:05:36,893 CassandraRoleManager.java:372 - Created default superuser role 'cassandra'

这里需要注意的一点是 Cassandra Java 应用程序的启动方式，启用了 JMX。如果查看 Java 命令行，可以找到以下选项：

• -Dcassandra.jmx.local.port=7199：此选项指定 JMX 服务在哪个端口上对客户端应用程序可用，供监控工具等消费数据。稍后您将看到，这个端口在客户端配置中使用，以便客户端应用程序能够定位该服务。

• -Dcom.sun.management.jmxremote.authenticate=false：此选项指示 JMX 服务是否可以远程访问。

• -Dcom.sun.management.jmxremote.password.file=/etc/cassandra/jmxremote.password：这是认证信息。

在本节中，我们已经查看了如何配置 Datadog 通过 JMX 接口获取应用程序指标，以 Cassandra 为例。下一节将介绍更多关于基于 JMX 的集成内容。

使用 Cassandra 集成

我们已经看到 Cassandra 服务启动时启用了 JMX 服务，并且该服务在端口 7199 上可用。Datadog 在此基础上提供了与 Cassandra 的集成，利用 JMX 接口提供的监控信息。

要启用 Cassandra 集成，需要按照以下标准步骤进行操作：

1. 在 Cassandra 主机上，还应该运行一个 Datadog Agent。在 /etc/datadog-agent/conf.d/cassandra.d 目录下，使用示例配置文件设置 Cassandra 集成的配置文件：

   $ cp conf.yaml.example conf.yaml
   

   从示例中复制的配置文件适用于启用集成。请注意，端口 7199 和配置文件中指定的用于收集数据的指标与 JMX 兼容。此外，从配置文件中的以下设置可以清楚地看出该集成的性质：

   init_config:
     ## @param is_jmx - boolean - required
     ## Whether or not this file is a configuration for a JMX integration
     #
     is_jmx: true
   

2. 设置好配置文件后，重启 Datadog Agent 服务：

   $ sudo service datadog-agent restart
   

3. 检查 Cassandra 集成的状态，特别是在 JMXFetch 部分下列出的状态：

$ sudo datadog-agent status
========
JMXFetch
========
  Initialized checks
  ==================
    cassandra
      instance_name : cassandra-localhost-7199
      message : <no value>
      metric_count : 230
      service_check_count : 0
      status : OK

通过该集成获取的指标可以在 指标浏览器 中查看。例如，查看如何从 JMX 接口获取的一个指标在 指标浏览器 中查找并绘制图表：

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/dtl-cld-mnt-qkstgd/img/Figure_10.2_B16483.jpg)

图 10.2 – 在指标浏览器中列出的 Cassandra 指标

在这种情况下，您无需了解 JMX 即可消费通过 JMX 接口发布的监控数据。

访问 Cassandra JMX 接口

Datadog 还可以配置为通过通用 JMX 集成从 Cassandra JMX 接口获取指标，而不是之前使用的专用 Cassandra 集成。Datadog 使用这种通用方法从没有 Datadog 集成的第三方应用程序中获取 JMX 指标。如果您的 Java 应用程序通过 JMX 发布应用程序指标，这种方法也适用：

1. 在启用通用 JMX 集成之前，通过将 /etc/datadog-agent/conf.d/cassandra.d 中的 conf.yaml 配置文件重命名为 conf.yaml.BAK 来禁用 Cassandra 集成。

2. 根据示例文件 conf.yaml.example 创建 conf.yaml 配置文件，该文件位于 /etc/datadog-agent/conf.d/jmx.d。

   你可以验证配置文件中指定的 JMX 端口是否为 7199：

   instances:
     -
       ## @param host - string - optional - default: localhost
       ## JMX host to connect to.
       #
       host: localhost
       ## @param port - integer - required
       ## JMX port to connect to.
       #
       port: 7199
   

3. 将这些标签添加到配置文件中，以便你以后可以使用它们来过滤指标：

                tags:
                    - integration:jmx
                    - metrics-type:default
   

4. 重启 Datadog Agent 以启用 JMX 集成：

   $ sudo service datadog-agent restart
   

5. 检查 JMXFetch 的状态，确保集成按预期工作：

$ sudo datadog-agent status
========
JMXFetch
========
  Initialized checks
  ==================
    jmx
      instance_name : jmx-localhost-7199
      message : <no value>
      metric_count : 27
      service_check_count : 0
      status : OK
  Failed checks
  =============
    no checks

请注意，在前面的示例中提到的 Cassandra 是在 JMXFetch 状态下，而这次是 jmx 状态。

在 JMX 集成正常工作的情况下，你可以在指标浏览器中查找任何默认的 JMX 指标，如下图所示：

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/dtl-cld-mnt-qkstgd/img/Figure_10.3_B16483.jpg)

图 10.3 – Cassandra JMX 接口的默认指标

要从 JMX 接口收集特定于应用程序的指标，这些指标应在 JMX 集成的配置文件中显式指定，如下所示：

 conf:
  - include:
      domain: org.apache.cassandra.db
      type:
         - Caches

这只是可用指标的示例集。Cassandra 发布了大量指标，你可以在 /etc/datadog-agent/conf.d/cassandra.d/metrics.yaml 中查找。需要注意的是，为了让 Datadog 从 JMX 接口收集应用程序指标，必须在配置文件中明确指示这些指标，就像在示例中所做的那样。

此外，将 metrics-type 标签的值设置为 cassandra，以便轻松过滤由 Datadog 从此示例中收集的指标。像往常一样，进行这些配置更改后，你需要重启 Datadog Agent，才能使更改生效。

你将能够在指标浏览器中查找由 Datadog 收集的新指标，如下图所示：

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/dtl-cld-mnt-qkstgd/img/Figure_10.4_B16483.jpg)

图 10.4 – Cassandra 特定的应用程序指标

Datadog 与 JMX 的集成细节可以在官方文档中找到：docs.datadoghq.com/integrations/java。如果你计划为你的 Java 应用程序配置 Datadog 以消费指标，这是一个很好的起点。

在下一节中，你将了解 StatsD，这是一种流行的监控标准，以及 Datadog 如何支持它。

使用 DogStatsD 接口

StatsD 是一个开源项目，用于发布应用程序指标，最初由照片共享网站 Flickr 构想。它经历了多个实现，最新版本是一个 Node.js 应用程序。StatsD 的代码和文档可以在 github.com/statsd/statsd 找到。

StatsD 服务通常运行在端口 8125 上，并监听通过 UDP 或 TCP 发送的统计数据。默认情况下，StatsD 监听 UDP 端口，并将聚合数据发送到图表和监控应用程序，如 Graphite。Datadog 将此服务捆绑为 DogStatsD，并且它作为一个 UDP 服务默认运行在端口 8125，即 Datadog Agent 运行的地方。

可以通过在运行 Datadog Agent 的主机上执行 datadog-agent status 命令来检查 DogStatsD 服务的状态，其输出如下所示：

=========
DogStatsD
=========
  Event Packets: 0
  Event Parse Errors: 0
  Metric Packets: 5,107,230
  Metric Parse Errors: 0
  Service Check Packets: 0
  Service Check Parse Errors: 0
  Udp Bytes: 329,993,779
  Udp Packet Reading Errors: 0
  Udp Packets: 5,107,231
  Uds Bytes: 0
  Uds Origin Detection Errors: 0
  Uds Packet Reading Errors: 0
  Uds Packets: 0

前面的步骤描述了如何从 Java 应用程序访问 JMX 指标。尽管某些应用程序（如 Cassandra）提供了访问 JMX 指标的应用程序特定集成，但这种通用集成足以从任何 Java 应用程序中获取 JMX 指标。

发布指标

自定义指标值可以通过多种方式发布到 Datadog 后端，以便在监控和仪表板中使用。例如，可以将任意的指标值发送到本地主机上运行的 DogStatsD 服务，如以下示例所示：

$ echo "testdogstatsd:2|c" | nc -u -w0 127.0.0.1 8125

发送到 DogStatsD 服务的测试指标值将由 Datadog 作为后端应用程序进行处理，并且该指标值可以在Metrics Explorer中查找，如下图所示：

图 10.5 – 在 Metrics Explorer 中查找通过 DogStatsD 发送的指标值

可以通过 DogStatsD 接口将各种类型的指标值（如 count、gauge、set 和 histogram）发布到 Datadog 后端。以下 Python 代码示例演示了如何发布这样的时间序列数据集：

# post-metric-dogstatsd.py 
import time
import random
from datadog import initialize, statsd
options = {
    'statsd_host':'127.0.0.1',
    'statsd_port':8125
}
initialize(**options)
while(1):
  # Get a random number to mimic the outdoor temperature.
  temp = random.randrange(50,70)
  statsd.gauge('statsd_test.outdoor_temp', temp, tags=["metric-source:dogstatsd"]
  )
  time.sleep(10)

该程序基本上会在 50 和 70 之间选择一个随机数，并将其作为户外温度发布，标签为 metric-source:dogstatsd。它将在无限循环中运行，每次发布指标时等待 10 秒，模拟时间序列数据集。

这里需要注意的重要一点是，发布数据不需要身份验证。只要 Datadog Agent 运行的主机上的 DogStatsD 服务端口（默认是 8125）是开放的，前面的示例程序就可以发布指标。虽然这提供了灵活性，但如果 Datadog Agent 运行的网络没有进行加固，也可能成为安全漏洞。

可以通过指标名称和标签（如果需要）在 Metrics Explorer 中查找发布到 Datadog 后端的数据，如下图所示：

图 10.6 – 通过 DogStatsD 接口发布的时间序列指标值

StatsD 是一个用于发布度量数据的通用接口。然而，由 Datadog 实现的 DogStatsD 扩展了对 Datadog 特定资源（如事件和服务检查）的支持。如果 DogStatsD 被用作将状态和更新发布到 Datadog 后端的中心，特别是在你的应用程序使用 DogStatsD 作为主要通道将监控信息发布到 Datadog 后端时，这些附加功能将非常有用。

发布事件

向 Datadog 事件流发布事件很简单，以下 Python 程序进行了说明：

# post-event-dogstatsd.py 
from datadog import initialize, statsd
options = {
    'statsd_host':'127.0.0.1',
    'statsd_port':8125
}
initialize(**options)
title = "An event testing DogStatsD API"
text = "The DogStatsD API works fine! Just wanted to confirm it."
tags = ["event-source:dogstatsd-test"]
statsd.event(title, text, alert_type='info', tags=tags)

该程序将向事件流发布事件，如下图所示：

Figure 10.7 – DogStatsD 集成发布的事件

如果你希望保持 StatsD 接口的通用性，以便其他兼容的监控应用程序也能从中获取度量数据，最好仅将其用于发布符合 StatsD 标准的度量数据。对于发布 Datadog 特定资源，最好使用 Datadog API。

你已经了解了三种不同的监控标准，它们虽然差异很大，但都是非常强大的选项，可以用于部署全面的监控解决方案。接下来，让我们看看与它们相关的最佳实践。

最佳实践

现在，让我们看看如何利用监控标准和 Datadog 提供的支持来实现最佳实践：

• 在使用 SNMP 集成监控网络设备时，你必须处理的度量数据数量可能会让人不知所措。因此，识别出几个关键的度量数据，能够跟踪性能并主动识别问题，并使用这些数据来实施监控是非常重要的。

• JMX 可以用来操作应用程序的工作方式，而这些操作不应该在监控基础设施端实现，因为监控本质上是一个只读活动。换句话说，监控应用程序通常不会主动采取任何纠正措施，因为监控不被认为是应用程序系统的一部分，而且监控工具的不可用不应妨碍它所监控的主应用程序的正常工作。

• StatsD 仅设计用于处理可由 Datadog 等应用程序消费的度量数据。如果你的环境中有多个监控工具，且 Datadog 只是其中之一，最好仅通过 DogStatsD 发布度量数据，以保持在多个系统之间移动数据的灵活性。

• 由于 DogStatsD 除了访问服务端口外不需要任何认证，因此运行 DogStatsD 的环境（如主机或容器）应该得到充分的安全保护，以防止未经授权的信息发布。

摘要

在本章中，你已经学习了三种重要的监控标准：SNMP、JMX 和 StatsD，它们有助于将网络设备和自定义应用程序集成到 Datadog 中。由于这些是通用标准，它们得到了大多数流行监控工具的支持。使用这些标准的一般模式是坚持使用标准功能，而不是使用扩展，因为前者的方法能够使你的监控与其他监控工具兼容。

在下一章，本书集成部分的最后一章，我们将讨论如何直接从自定义应用程序处理中集成。可以使用官方和社区开发的编程库，将应用程序直接与 Datadog 进行集成。我们将探讨如何使用这些库以及 Datadog REST API 来将自定义应用程序与 Datadog 集成。

第十一章：与 Datadog 集成

在上一章中，您了解了一些重要的监控标准以及它们如何在 Datadog 中实现，目的是扩展 Datadog 监控平台的功能。到目前为止，在本书的这一部分，我们一直只关注于扩展专注于 Datadog 的组织的监控能力。与 Datadog 的集成是双向的——除了向 Datadog 填充与监控相关的数据以便与各种 Datadog 功能一起使用外，Datadog 中的信息也可以被其他内部应用程序利用。

要在应用程序之间推出此类通用集成，应该提供丰富的 API 集合。我们已经看到，Datadog REST API 是一个全面的编程接口，其他应用程序可以利用它来访问 Datadog 平台，发布和提取信息。我们还介绍了 DogStatsD 作为一种向 Datadog 平台发布信息的方法，并且我们将进一步了解如何从其他应用程序使用该接口。我们还将回顾其他方法，这些方法主要是社区驱动的努力，并非官方与 Datadog 产品套件一起发布，但在推出自定义集成时非常有用。

在本章中，您将学习关于 Datadog 集成的常用库，并具体涵盖以下主题：

• 使用客户端库

• 评估社区项目

• 开发集成

技术要求

要实现本章中的示例，您需要安装以下工具的环境：

• Datadog 代理

• pip3

• Python 2.7（可选）

• Datadog 开发工具包

• Git 客户端

使用客户端库

在本节中，我们将看两类不同的客户端库——第一类是 Datadog REST API 的封装库，第二类是本地的 DogStatsD 客户端库。这两类库都适用于流行的编程语言，如 C++、Java、Python、Java 和 Go。

Datadog 为大多数编程语言提供了这两类库。尽管许多社区库在官方 Datadog 网站上有列出，但我们只关注那些正在积极维护的库。

基于 REST API 的客户端库

基本的 Datadog 客户端库是 REST API 集合，而特定编程语言的库本质上是 REST API 上的封装，便于 API 的使用。在本节中，我们将探讨一些重要的特定编程语言的客户端库，并且在相关的地方，我们也会展示示例代码。

Datadog Python 库

我们已经在 *第九章**《使用 Datadog API》中看到过这个库的实际应用。这款官方库支持 REST API 和 DogStatsD，可以通过编程方式与 Datadog 进行交互。

该库可以通过 Python 安装工具 pip 安装到您的 Python 环境中，安装方法如下：

$ pip install datadog

代码可以在 GitHub 上找到，网址是 github.com/DataDog/datadogpy，并且该库也可以从源代码安装。要执行此操作，克隆代码库到本地环境中，并按如下方式运行设置程序：

$ git clone https://github.com/DataDog/datadogpy.git
$ cd datadogpy
$ python setup.py install

安装后，可以通过导入 API 模块在程序中执行 REST API 特定的调用，也可以通过将 statsd 模块导入 Python 环境来执行 DogStatsD 特定的调用。

Datadog 的 Python API 客户端

这是一个官方的 Python 库，映射了所有公共 Datadog REST API 的集合。它可以在 GitHub 上找到，网址是 github.com/DataDog/datadog-api-client-python。使用 pip，可以按如下方式在兼容的 Python 环境中安装该库：

$ pip3 install datadog-api-client

目前，该客户端仅与 Python 3.6 及以上版本兼容。

Datadog 的 Java 客户端

在开发企业级应用程序时，Java 是最流行的编程语言之一。因此，如果 Java 应用程序需要直接与 Datadog 集成，这个官方 Java 客户端库（它是 Datadog REST API 的封装）是默认选择。

与该客户端库相关的代码库可以在 GitHub 上找到，网址是 github.com/DataDog/datadog-api-client-java。请查阅那里提供的文档，以了解如何使用 Maven 和 Gradle 等构建工具，在 Java 开发环境中构建和安装此 Java 库。

Datadog 的 Go API 客户端

Go 是一种现代的编译型语言，它具有快速的执行速度，但又具备像 Python 这样的解释型语言的灵活性。虽然它是一种通用编程语言，但在系统编程中非常流行，并且被广泛用于在 DevOps 领域构建命令行接口（CLI）工具。例如，最新版本的 Datadog Agent 部分就是用 Go 开发的。

Datadog REST API 的官方 Go 客户端库在 GitHub 上维护，网址是 github.com/DataDog/datadog-api-client-go。构建和安装该库的详细信息也可以在该位置找到。

Datadog 的 Node.js 客户端

Node.js 平台用于在服务器端运行 JavaScript，且在开发基于 Web 浏览器的用户界面时非常流行。Datadog 并没有提供官方的客户端库来支持这个平台，但可以使用由 Brett Langdon 提供的 node-dogapi 代码库，GitHub 上的链接为 github.com/brettlangdon/node-dogapi。该代码库最近没有更新，其与 Datadog API 的兼容性需要验证，以确保符合预期的使用要求。

WebService-DataDog – 一个 Perl 客户端

在 Python 广泛使用之前，Perl 曾是构建系统工具的默认脚本语言，尤其是在处理日志和文本数据方面。这个由 Jennifer Pinkham 维护的 Perl 客户端库最近没有更新，但对于 Perl 爱好者来说，仍然值得一试。代码库可在 GitHub 上找到，链接为 github.com/jpinkham/webservice-datadog，并附有如何安装相关 Perl 模块的步骤说明。

Ruby 客户端用于 Datadog API

Ruby 是一种脚本语言，主要用于构建 Web 应用程序，特别是结合 Ruby on Rails 开发框架使用。然而，它和 Python、PHP、Perl 一样，都是通用编程语言。Datadog 为 Ruby 提供了一个官方客户端库，这是在 Datadog REST API 之上的抽象层。

代码库可以在 GitHub 上找到，链接为 github.com/DataDog/dogapi-rb，附有安装库的步骤和如何在 Ruby 中使用 Datadog API 的代码示例。

DogStatsD 客户端库

如在 第十章 中提到的，与监控标准一起工作，DogStatsD 是监控标准 StatsD 的一种实现。因此，任何通用的 StatsD 实现都可以与 Datadog Agent 提供的 DogStatsD 接口一起使用。这里回顾的社区库利用了这一特性，从而为目标编程语言提供了一个封装。

C++ DataDog StatsD 客户端

使用这个库，指标和事件可以通过 StatsD 接口发布到 Datadog 后端。代码库可以在 GitHub 上找到，链接为 github.com/BoardiesITSolutions/cpp-datadogstatsd。

代码可以被构建成适用于目标操作系统的共享库，通常是 Linux 发行版。一些 Windows 平台也得到支持。需要发布指标数据和事件的自定义应用程序可以动态链接到这个共享库。

Java DogStatsD 客户端

对于Java，Datadog 提供了一个官方的 DogStatsD 客户端库，地址为github.com/DataDog/java-dogstatsd-client在 GitHub 上。它比标准的 StatsD 库支持更多功能，标准 StatsD 库仅限于发布度量数据。使用 Java DogStatsD 客户端，你还可以维护事件和服务检查。

可以通过 Maven 导入特定版本的客户端 JAR 文件到你的项目中，具体配置如下所示：

<dependency>
    <groupId>com.datadoghq</groupId>
    <artifactId>java-dogstatsd-client</artifactId>
    <version>2.11.0</version>
</dependency>

可以从 Java 应用程序调用 StatsD API，并在添加了前述配置到 Maven 设置之后构建。

C#的 DogStatsD 客户端

C#是像 Java 和C++一样的通用编程语言，是最初由微软推广的.NET应用开发框架的一部分。它在 Windows 平台和多个 Linux 发行版上得到支持。此库由 Datadog 维护，源代码仓库可以在 GitHub 上找到，地址为github.com/DataDog/dogstatsd-csharp-client。

这个流行的客户端库可以通过NuGet上的软件包或通过 GitHub 上的源代码进行安装。与其他官方 DogStatsD 客户端库一样，除了标准的度量指标支持外，它还支持事件和服务检查。安装和库使用的详细信息可以在 GitHub 上的代码仓库中找到。

datadog-go

datadog-go是一个为 Go 编程语言提供的 DogStatsD 客户端库，由 Datadog 在 GitHub 上的github.com/DataDog/datadog-go进行维护。与其他官方的 DogStatsD 客户端库一样，它除了支持度量指标外，还支持事件和服务检查。

该库正式支持Go版本1.12及以上。安装和使用该库的详细信息可以在 GitHub 上的代码仓库中找到。

dogstatsd-ruby

dogstatsd-ruby是一个为 Ruby 编程语言提供的 DogStatsD 客户端库，由 Datadog 在 GitHub 上的github.com/DataDog/dogstatsd-ruby进行维护。与其他官方的 DogStatsD 客户端库一样，它也支持事件和服务检查，除了度量指标外。

该库的安装和使用的详细信息可以在 GitHub 上的代码仓库中找到。完整的 API 文档可以在www.rubydoc.info/github/DataDog/dogstatsd-ruby/master/Datadog/Statsd查阅。

社区版 DogStatsD 客户端库

虽然 Datadog 为流行的编程语言提供了由 Datadog 维护的 DogStatsD 客户端库，但与基于 REST API 的客户端库一样，社区也积极支持其他语言，如 Node.js 和 Perl。通常，基于社区的库是通用 StatsD 库的封装，并且仅支持指标。以下是一些值得注意的库：

• Node.js 的 Host-shots 客户端库：此库可以在 GitHub 上的 github.com/brightcove/hot-shots 找到。这是一个通用的客户端库，支持其他提供 StatsD 接口的监控工具。

• NodeDogStatsD：这是另一个 Node.js 客户端库，代码仓库和文档可以在 GitHub 上的 github.com/mrbar42/node-dogstatsd 找到。

• DataDog DogStatsD – 用于 DogStatsD 的 Perl 模块：使用此模块，可以从 Perl 程序向 Datadog 发布指标数据。代码和文档可以在 GitHub 上的 github.com/binary-com/dogstatsd-perl 找到。

要查看完整且最新的客户端库列表，请访问官方编译的 docs.datadoghq.com/developers/libraries/。

在本节中，你已经了解了两组可以与主要编程语言一起使用的客户端库，以访问 Datadog 资源。这些客户端库对于从头开始构建 Datadog 特定功能（例如程序或脚本）非常有用，作为与 Datadog SaaS 后端集成的一部分。在下一节中，我们将介绍一些提供良好集成功能或构建块的工具，用于开发这些集成。

评估社区项目

还有一些由其他公司和社区团体开发的工具，可以让你在 Datadog 相关的集成和自动化方面更加轻松。在本节中，我们将介绍一些在这一类别中非常有用的工具和框架。

Brightcove 的 dog-watcher

在一个大规模环境中，若有多个仪表板和监控项基于 Datadog 构建用于操作使用，维护它们可能会迅速变成一项重大工作。这个 Node.js 实用工具可以用来备份 Datadog 的仪表板和监控项，以 JSON 格式保存到 Git 仓库中。这样的备份也在重新创建相似资源到同一账户或其他地方时非常有用。

该工具需要作为 Node.js 服务运行。代码和配置运行的详细信息可以在 GitHub 上的 github.com/brightcove/dog-watcher 找到。它可以安排定期备份，或者在跟踪的 Datadog 资源发生变化时备份。

kennel

kennel 是一个用 Ruby 开发的工具，可以作为代码来管理 Datadog 监控、仪表盘和 服务水平对象（SLOs）。将各种基础设施资源作为代码进行管理是 DevOps 的一个原则，这个工具在实现这一目标中非常有用。该工具的代码和详细文档可以在 GitHub 上找到，地址是 github.com/grosser/kennel。

使用 Terraform 管理监控

Terraform 是一个通用工具，用于搭建和维护 基础设施即代码（IaC）。它可以通过在 Terraform 配置语言中定义监控来管理 Datadog 监控。

Terraform 通过将资源的当前状态与代码中的定义进行匹配，来维护它所管理的资源的状态。如果资源不存在，它将会被创建。

可以使用 Terraform 管理多种 Datadog 资源和集成，其中一些重要的资源如下：

• 用户

• 角色

• 指标

• 监控

• 仪表盘

• 停机时间

• 与公共云平台的集成

关于这些资源的标准 Terraform 文档可以在 registry.terraform.io/providers/DataDog/datadog/latest/docs 中找到。

Ansible 模块和集成

Ansible 是一个配置管理工具，由于其通用性，除了核心配置管理功能外，它在 DevOps 工程师中非常受欢迎。在基础设施管理方面，它与 Terraform 非常相似，直接支持 Datadog 资源。

一般来说，Ansible 提供了模块来支持某种类型的基础设施资源。目前，已经有 Ansible 模块可以发布事件和管理监控。通过这些模块，可以构建 Ansible playbooks 来管理 Datadog 账户中的事件和监控。

Datadog 还提供了一个官方的 Ansible 集成。它可以通过回调机制跟踪 Ansible playbook 的执行。然而，就公开到 Datadog 平台的信息而言，这个集成并不十分有用。

Datadog 提供了许多应用程序和公共云平台及服务的集成。如果您选择的第三方工具或需要通过 Datadog 监控的内部应用没有现成的集成，您可以开发一个自定义集成。我们将在下一节学习如何开发和部署自定义集成的基础知识。

开发集成

在 第八章，与平台组件集成，您学习了如何配置集成。Datadog 提供了许多与第三方应用程序集成的官方集成，这些应用程序被用于构建运行软件应用程序的云平台。使用官方集成的最大好处是，经过最少的配置后，该集成特定的指标将可以在仪表板、监视器和其他 Datadog 资源中使用。

Datadog 允许您构建自定义集成，使其像官方集成一样工作。这需要 DevOps 专业知识，特别是在 Python 编程方面的技能，而且学习 Datadog 提供的构建与 Datadog Agent 兼容的集成程序并不容易。然而，出于以下原因，构建集成可能是有意义的：

• 为内部应用程序构建集成：尽管是内部使用，但该应用程序可能会在生产环境中大规模部署，Datadog 集成有助于标准化该应用程序的监控需求。

• 为第三方应用程序构建集成：监控需求与上一使用案例中描述的内部应用程序类似，但尚无官方或社区级的集成，或者需求没有得到满足。

• 为面向外部使用的应用程序提供监控支持：您可能有一个面向外部用户的应用程序作为第三方软件，向 Datadog 提供集成可能是该应用程序监控支持策略的一部分。

在本节中，您将学习从头开始构建集成的步骤。构建一个完整的集成超出了本章的范围，但您将通过一些实践操作了解一般步骤。

先决条件

在本地开发环境中需要进行一些设置，以便开发、测试、构建、打包和部署集成：

• 安装 Python 3.8 及以上版本，Python 2.7 为可选项。

• 开发者工具包。可以使用 pip3 工具安装，方法如下：

  $ pip3 install "datadog-checks-dev[cli]"
  

  这将安装许多内容到本地 Python 3 环境中，如果一切顺利，输出将如下所示：

  Successfully installed PyYAML-5.3.1 Pygments-2.8.0 appdirs-1.4.4 atomicwrites-1.4.0 attrs-20.3.0 bcrypt-3.2.0 bleach-3.3.0 cached-property-1.5.2 certifi-2020.12.5 cffi-1.14.5 chardet-4.0.0 colorama-0.4.4 coverage-5.5 cryptography-3.4.6 datadog-checks-dev-9.0.0 distlib-0.3.1 distro-1.5.0 docker-4.4.4 docker-compose-1.28.5 dockerpty-0.4.1 docopt-0.6.2 docutils-0.16 filelock-3.0.12 idna-2.10 in-toto-1.0.1 iniconfig-1.1.1 iso8601-0.1.14 jsonschema-3.2.0 keyring-22.3.0 markdown-3.3.4 mock-4.0.3 packaging-20.9 paramiko-2.7.2 pathspec-0.8.1 pip-tools-5.5.0 pkginfo-1.7.0 pluggy-0.13.1 psutil-5.8.0 py-1.10.0 py-cpuinfo-7.0.0 pycparser-2.20 pygal-2.4.0 pygaljs-1.0.2 pynacl-1.4.0 pyparsing-2.4.7 pyperclip-1.8.2 pyrsistent-0.17.3 pytest-6.2.2 pytest-benchmark-3.2.3 pytest-cov-2.11.1 pytest-mock-3.5.1 python-dateutil-2.8.1 python-dotenv-0.15.0 readme-renderer-29.0 requests-2.25.1 requests-toolbelt-0.9.1 rfc3986-1.4.0 securesystemslib-0.20.0 semver-2.13.0 tenacity-6.3.1 texttable-1.6.3 toml-0.10.2 tox-3.22.0 tqdm-4.58.0 twine-3.3.0 urllib3-1.26.3 virtualenv-20.4.2 webencodings-0.5.1 websocket-client-0.57.0
  

• Docker，用于运行单元测试和集成测试。

• 如果集成需要通过部署 Datadog Agent 来进行测试，请确保已安装该 Agent。请注意，集成包可以部署到任何地方，因此 Datadog Agent 不需要在开发和测试集成兼容性的位置本地运行。

这里提供的命令和输出已在类 Unix 系统（如 Linux 或 Mac）上验证。也可以在 Windows 上进行开发；有关平台特定的操作，请参见官方文档。

设置工具链

integrations-extras 代码仓库需要从 GitHub 克隆到本地环境，以便为开发和构建集成提供所有框架。按照以下步骤进行设置：

1. 在你的主目录中创建一个开发工作目录：

   $ mkdir dd
   

2. 克隆 integrations-extras 仓库：

   $ cd dd
   $ git clone https://github.com/DataDog/integrations-extras.git
   

3. 将 integrations-extras 设置为默认仓库：

   $ cd integrations-extras
   $ ddev config set repo extras
   

接下来，我们将为集成设置一个专用文件夹。

创建集成文件夹

对于新集成，开发工具包可以创建整个目录结构，并填充模板文件。你可以尝试进行演练，以查看将要创建的目录结构和文件。

为了更好地描述这些步骤，假设你有一个名为 CityWeather 的应用，它随时提供特定城市的天气相关信息。集成的目标是将这些天气信息的一部分发布到 Datadog。

创建目录的演练可以按如下方式进行：

$ ddev create -n CityWeather

输出将显示框架中目录和文件的层次列表；为了简洁起见，这里没有提供。

可以通过运行相同的命令而不带 -n 选项来创建目录结构。尽管使用的名称包含混合字符，但顶级目录名称将全部小写。因此，你可以按如下方式进入新创建的目录：

$ cd cityweather

在该目录中，你将找到以下文件和目录：

• README.md：用于在 Git 中记录新集成的 README 文件。提供的模板具有正确的头部和格式，以确保文档标准化。

• manifest.json：描述集成和文件位置的清单文件。

• tests：用于配置和维护单元测试和集成测试的目录。

• metadata.csv：维护所有收集到的度量指标列表。

• tox.ini：现在，tox 用于运行测试。确保该配置文件中指定的 Python 版本与本地可用的 Python 版本匹配。例如，如果使用的是 Python 2.7 和 Python 3.9，该文件的内容将如下所示，并根据需要进行更改：

  [tox]
  minversion = 2.0
  skip_missing_interpreters = true
  basepython = py39
  envlist = py{27,39}
  [testenv]
  ensure_default_envdir = true
  envdir =
      py27: {toxworkdir}/py27
      py39: {toxworkdir}/py39
  dd_check_style = true
  usedevelop = true
  platform = linux|darwin|win32
  deps =
      datadog-checks-base[deps]>=6.6.0
      -rrequirements-dev.txt
  passenv =
      DOCKER*
      COMPOSE*
  commands =
      pip install -r requirements.in
      pytest -v {posargs}
  

现在，本地已经具备了开发集成的工具，接下来让我们尝试使用仓库中现有的集成来执行其余步骤。请注意，在这个仓库中大约有 100 个额外的集成，你可以通过构建相应的相关包来使用它们，接下来你将学到这个技巧。

为了测试和部署的实践目的，我们选择一个 Zabbix 集成。这是一个流行的本地监控工具，广泛应用于数据中心和云平台。许多正在迁移到 Datadog 的公司可能需要处理现有的 Zabbix 安装，更实用的策略是与 Zabbix 集成，而不是试图替代它，重点是为监控任何新基础设施推出 Datadog。在这种情况下，Datadog 和 Zabbix（或其他本地监控应用）将并行运行。

运行测试

对于集成开发的代码，可以借助 Docker 在本地运行单元测试和集成测试。对于 Zabbix 集成，Zabbix 将作为 Docker 上的微服务本地运行，并且测试将针对该实例运行。Zabbix 部署的详细信息提供在 docker-compose.yml 文件中。

按照以下步骤部署 Zabbix 并测试集成：

1. 切换到 Git 仓库的顶层目录。

2. 切换到 Zabbix 集成的目录：

   $ cd zabbix
   

3. 查找 docker-compose.yml 文件：

   $ cat tests/compose/docker-compose.yml 
   

   这里没有提供输出结果，以简洁为主。

4. 运行测试：

   $ ddev test zabbix
   

5. 输出信息较为详细，最后会以类似以下的消息结束，表示测试成功：

     py39: commands succeeded
     style: commands succeeded
     congratulations :)
   Passed!
   

接下来，让我们看看如何为集成构建配置文件。

构建配置文件

集成提供的示例配置文件 conf.yaml.example 是从 assets/configuration/spec.yaml 中的模板文件生成的。更改模板文件后，可以按如下方式生成示例配置文件：

$ ddev validate config --sync zabbix
Validating default configuration files...
Writing config file to `/Users/thomastheakanath/dd/integrations-extras/zabbix/datadog_checks/zabbix/data/conf.yaml.example`
All 2 configuration files are valid!

接下来，让我们看看如何将集成代码打包以便安装。

构建包

要部署集成，需要将其打包成 wheel 格式，这是一种用于打包和分发 Python 程序的格式。wheel 文件仅包含集成功能所需的文件，并不会包含构建集成所用的大多数源文件。可以按如下方式构建集成：

$ ddev release build zabbix
Building `zabbix`...
'build/lib' does not exist -- can't clean it
'build/bdist.macosx-10.13-x86_64' does not exist -- can't clean it
'build/scripts-3.9' does not exist -- can't clean it
warning: no previously-included files matching '__pycache__' found anywhere in distribution
Build done, artifact(s) in: /Users/thomastheakanath/dd/integrations-extras/zabbix/dist
Success!

wheel 文件可以在构建命令输出中提到的位置找到：

$ ls dist/*.whl
dist/datadog_zabbix-1.0.0-py2.py3-none-any.whl

接下来，让我们看看如何使用刚构建的包安装集成。

部署集成

如果 Datadog Agent 在本地运行，可以通过指向上一步中构建的 wheel 来安装它。wheel 文件必须复制到计划安装的其他位置。一旦 wheel 文件在本地可用，可以按如下方式安装：

$ sudo –u dd-agent datadog-agent integration install -w dist/datadog_zabbix-1.0.0-py2.py3-none-any.whl
For your security, only use this to install wheels containing an Agent integration and coming from a known source. The Agent cannot perform any verification on local wheels.
Processing  ./dist/datadog_zabbix-1.0.0-py2.py3-none-any.whl
Installing collected packages: datadog-zabbix
Successfully installed datadog-zabbix-1.0.0
Successfully copied configuration file conf.yaml.example
Successfully completed the installation of datadog-zabbix

这基本上会使集成可以供 Datadog Agent 使用，并作为官方集成与 Datadog Agent 一起启用。如果你检查 Datadog Agent 主目录下的 conf.d 目录，你可以看到 zabbix.d 列出如下：

$ ls zabbix.d
conf.yaml.example

与其他标准集成一样，要启用它，需要根据提供的示例文件创建conf.yaml，并重启 Datadog Agent 服务。

构建 Datadog 集成的完整流程在docs.datadoghq.com/developers/integrations/new_check_howto上有官方文档。请参考该文档以获取更详细的细节和更新。现在，让我们来看看与你刚才看到的主题相关的最佳实践。

最佳实践

客户端库的可用性以及构建自定义集成的选项为你提供了很大的灵活性，可以将 Datadog 与其他应用程序甚至批处理作业集成。然而，在开始使用这些选项之一或多个进行自动化或自定义时，你需要先了解一些最佳实践：

• 如果你能选择编程语言，建议选择更受支持和流行的语言，例如用于脚本的 Python 和用于企业应用的 Java。如果需要集成的应用主要运行在 Microsoft Windows 平台上，选择 C#是明智的。

• 选择一个官方维护的客户端库。这是显而易见的——你需要依赖一个能够跟上 Datadog 平台和 REST API 增强功能的库。

• 计划使用 Terraform 将 Datadog 资源管理为代码。Ansible 也可以提供帮助，但目前它对 Datadog 的支持有限。

• 如果你构建了一个集成，并且它有外部使用，请将其发布到 Datadog 的integrations-extras GitHub 仓库。其他人的使用可以帮助获得有价值的反馈和修复，使其更加健壮和实用。

遵循这些最佳实践和相关模式将帮助你选择正确的方法来实现集成需求。

总结

到现在为止，你应该已经了解了 Datadog 中针对各种使用场景提供的所有重要集成功能；让我们回顾一下本章具体讨论的内容。

针对流行编程语言的许多 Datadog 客户端库是可用的，既有官方维护的，也有社区层级的。有两种类型的客户端库——一种提供对 Datadog REST API 的语言封装，另一种通过与 StatsD 兼容的 DogStatsD 服务提供 Datadog 接口支持。此外，GitHub 上也有社区级的 Datadog 集成项目。

这里没有讨论其他类型的 Datadog 客户端库，例如APM和分布式追踪库，支持无服务器计算资源（如AWS Lambda）的库，以及专门针对 Datadog 日志管理功能的客户端库。这些库的使用方式与核心 API 和 DogStatsD 库的使用方式没有不同，如果你有相关的使用场景，应该查看这些库。

本章完成了本书的第三部分，扩展 Datadog。在本书的下一部分，你将学习 Datadog 实现的更高级的监控概念和功能。我们之前简要地看了微服务监控，接下来的章节中，你将深入了解微服务监控，特别是如何在 Kubernetes 编排的环境中进行监控。

第三部分：高级监控

Datadog 是一个综合监控平台，具有多个功能。书中的第二章和第三章介绍了高级监控工具中应有的核心监控功能。本部分的章节讲解了 Datadog 平台上更高级或非标准的监控功能。

本节包含以下章节：

• 第十二章，容器监控

• 第十三章，使用 Datadog 管理日志

• 第十四章，其他监控主题

第十二章：监控容器

容器监控在本书的早期已经简要介绍。然而，采用基于微服务的架构来构建应用程序，以及越来越多地使用容器来部署这些应用程序，要求有像本章这样专门的章节来讲解。监控应用程序正在努力支持这一领域的进展，而 Datadog 也在不断添加新特性。

在本章中，您将了解与监控容器相关的 Datadog 重要功能。具体来说，将涵盖以下主题：

• 收集 Docker 日志

• 监控 Kubernetes

• 使用实时容器

• 使用实时尾随查看日志

• 搜索容器数据

技术要求

要尝试本章中提到的示例，您需要在 Docker 或 Kubernetes 上部署 Datadog Agent 的环境。以下环境中开发了这些示例：

• Docker：Docker Desktop 3.2.2，在 MacBook Pro 上运行。任何具有最新版本 Docker 的环境都兼容。

• 在 MacBook Pro 上运行minikube v1.18.1。要尝试这些示例，可以使用任何拥有kubectl v1.20.0或更高版本的 Kubernetes 环境。

这些示例甚至可能适用于旧版本的 Docker 和 Kubernetes；我们鼓励您在它们各自的最新版本上尝试这些示例。

收集 Docker 日志

在第二章，部署 Datadog Agent，您学习了如何作为基础设施的一部分监控基于 Docker 的容器。通过适当配置 Datadog Agent，可以获取正在运行的 Docker 容器的信息、metrics.*指标组，并监控容器的健康状态。容器的应用日志通常写入stdout和stderr流。在本节中，我们来看看如何通过配置 Datadog Agent 及相应的 Docker 镜像来收集应用日志。

从容器收集日志的首选方法是将 Datadog Agent 作为容器在同一 Docker 主机上运行。尽管启动 Datadog Agent 容器的实际命令行可能会因目标操作系统的不同而略有不同，但在 Unix 类系统（如 macOS 或 Linux）上，命令将如下所示：

$ docker run -d --name datadog-agent \
           -e DD_API_KEY=DATADOG-API-KEY  \
           -e DD_LOGS_ENABLED=true \
           -e DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL=true \
           -e DD_CONTAINER_EXCLUDE="name:datadog-agent" \
           -v /var/run/docker.sock:/var/run/docker.sock:ro \
           -v /proc/:/host/proc/:ro \
           -v /opt/datadog-agent/run:/opt/datadog-agent/run:rw \
           -v /sys/fs/cgroup/:/host/sys/fs/cgroup:ro \
           gcr.io/datadoghq/agent:latest

请注意，DATADOG-API-KEY必须替换为与 Datadog 用户账户关联的有效 API 密钥。

成功运行 Datadog Agent 容器后，您应能够从命令行验证其状态，具体如下：

$ docker ps
CONTAINER ID        IMAGE                           COMMAND                   CREATED             STATUS                  PORTS                  NAMES
2689f209fc16        gcr.io/datadoghq/agent:latest   "/init"                  29 hours ago        Up 29 hours (healthy)   8125/udp, 8126/tcp     datadog-agent

主机上可能还会运行其他容器，但请寻找标签为datadog-agent的 Datadog Agent 容器。

要检查 Datadog Agent 服务是否能够从其他容器收集日志，您可以运行任何其他生成日志的容器。对于这里的示例，我们可以尝试运行一个 NGINX 容器，如下所示：

$ docker run -it --rm -d -p 8080:80 --name web nginx

该命令将运行一个标签为web的 NGINX 容器，这是我们稍后可以在 Datadog 仪表盘中用来定位此容器的名称。此外，容器端口将映射到 Docker 宿主机上的8080端口。

上述命令的输出在此未提供以简化说明，但您可以按照以下方式检查它是否正在运行：

$ docker ps 
CONTAINER ID        IMAGE                           COMMAND                   CREATED             STATUS                  PORTS                  NAMES
53cd9cae287d        nginx                           "/docker-entrypoint.…"   28 hours ago        Up 28 hours              0.0.0.0:8080->80/tcp   web
2689f209fc16        gcr.io/datadoghq/agent:latest   "/init"                  29 hours ago        Up 29 hours (healthy)   8125/udp, 8126/tcp     datadog-agent

查看容器的名称和端口映射；这使得您可以通过宿主机上的8080端口访问 NGINX 服务，即使该服务在容器中运行在80端口。

此外，您还可以通过浏览器使用 URL http://localhost:8080 访问 NGINX 服务（如果从远程主机访问服务，可以使用 IP 地址或CNAME替代 localhost）。也可以使用命令行工具如curl访问该服务。您需要这样做，以生成一些日志，查看 Datadog Agent 如何收集它们。

现在让我们看看如何通过 Datadog UI 查看日志。通过导航到基础设施 | 容器，您可以进入容器仪表盘，如下图所示：

图 12.1 – 列出容器

查找您想查看日志的容器名称。在此示例中，容器名称为web，您可以双击它以打开以下对话框。在下拉菜单中选择日志标签，如下图所示：

图 12.2 – 从容器收集的日志

如您所见，显示的日志可以按时间窗口进行筛选，比如示例中设置的过去 15 分钟。要生成新日志，只需通过 web 浏览器或curl访问 URL。

日志也可以在日志浏览器提供的更好的界面中查看。如图 12.2所示的对话框提供了一个链接，用于启动日志浏览器，如下图所示：

图 12.3 – 链接到日志浏览器

通过点击链接在日志浏览器中打开，如图 12.3所示，可以启动日志浏览器仪表盘，界面如下所示：

图 12.4 – 日志浏览器

该界面与行业标准的日志聚合工具非常相似，如Splunk、Sumo Logic和ELK Stack。

在此示例中，您已经学习了如何从容器捕获日志并通过运行 Datadog Agent（也是作为容器）在同一 Docker 宿主机上将其发布到 Datadog。如果您有自定义运行容器的 Docker 镜像的选项，则可以对镜像进行修改，以更好地捕获容器日志。在接下来的示例中，您将学习如何在容器上启用 NGINX 日志集成。

主要步骤是为日志收集给 Docker 镜像打标签，如下所示的Dockerfile所示，该文件用于构建在前面的示例中使用的 NGINX 镜像的自定义版本：

1. 在当前目录中创建如下所示的 Dockerfile，构建自定义版本的 NGINX 镜像，并使用它启动容器：

   $ cat Dockerfile
   FROM nginx:latest
   LABEL "com.datadoghq.ad.logs"='[{"source": "nginx", "service": "webapp-custom"}]'
   

2. 构建 Docker 镜像：

   $ docker build -t nginx-custom .
   

3. 验证 Docker 镜像是否成功构建：

   $ docker images|grep custom
   nginx-custom                                           latest              b8121cf4a3fe        29 minutes ago      133MB
   

4. 启动自定义构建的 NGINX 容器：

   $ docker run -it --rm -d -p 8080:80 --name web-custom nginx-custom
   59162bf7694cd146166c040263d73afea934eb8081c63875f17e28228
   48b4b16
   

5. 检查 NGINX 容器是否正在运行：

   $ docker ps | grep custom
   59162bf7694c        nginx-custom                    "/docker-entrypoint.…"   41 minutes ago      Up 41 minutes          0.0.0.0:8080->80/tcp   web-custom
   

6. 验证是否可以在 Docker 主机的端口8080上访问容器：

   $ curl -I http://localhost:8080
   HTTP/1.1 200 OK
   Server: nginx/1.19.8
   Date: Wed, 17 Mar 2021 05:55:45 GMT
   Content-Type: text/html
   Content-Length: 612
   Last-Modified: Tue, 09 Mar 2021 15:27:51 GMT
   Connection: keep-alive
   ETag: "604793f7-264"
   Accept-Ranges: bytes
   

如果所有前面的步骤都成功，您可以检查 Datadog 是否正在捕获日志。

为了验证日志是否已被收集，可以在 Datadog 容器仪表盘中查找容器日志，正如您之前所看到的那样：

1. 导航到基础设施 | 容器。

2. 双击nginx-custom容器。

3. 在日志标签下查找日志条目。

4. 另外，日志浏览器也可以用于搜索日志，正如您在前面的示例中所学到的那样。

您已经了解了如何使用 Datadog 监控运行在 Docker 主机上的容器的基础设施和应用程序级别，特别是在本节中如何收集来自容器的应用程序日志。Kubernetes 最近正在成为部署微服务的默认平台，在下一节中，您将学习如何使用 Datadog 监控运行在 Kubernetes 上的容器。

监控 Kubernetes

Docker 可以用于打包和运行微服务，您在前面的章节中已经看到了这些示例。然而，这只是微服务可用的打包解决方案之一。Kubernetes 是一个用于运行使用 Docker 等工具打包的微服务的平台。它提供了大量功能来编排和维护基于微服务的软件系统的部署。实际上，它可以被视为微服务的操作系统。

Kubernetes 环境可以在多种基础设施上设置，从用于测试目的的笔记本电脑到数据中心中几台机器的集群。然而，运行 Kubernetes 最流行的方式是使用公共云平台上提供的托管服务，如kubectl。在本节中，您将学习如何部署 Datadog 代理，以监控在 Kubernetes 环境中运行的容器。

为了测试这里提供的步骤，使用了基于minikube的 Kubernetes 环境，它在个人计算机上运行。关于如何设置minikube的详细信息可以在这里找到：minikube.sigs.k8s.io/docs/start/。这些部署 Datadog 的步骤适用于任何 Kubernetes 环境，您可以在任何地方尝试，无论底层 Kubernetes 基础设施如何。

监控 Kubernetes 包括两个部分：监控 Kubernetes 集群本身，以及监控由 Kubernetes 编排的容器中运行的微服务。前者是基础设施监控，后者是应用程序监控。要使 Datadog 能够访问相关的监控信息，必须将 Datadog Agent 安装为 Kubernetes 集群中的一个容器之一，由此定义 Kubernetes 资源以支持。

安装 Datadog Agent

Datadog Agent 安装为 Kubernetes 集群中所有节点上的 DaemonSet，以便收集并推送来自每个节点的日志、跟踪和指标至 Datadog 后端。在较大的环境中，实际实施可能会有所不同，因为 Kubernetes 平台及其运行的服务类型在实际场景中可能大不相同。让我们通过进行示例安装来查看一般步骤：

1. 下载用于创建 datadog-agent 的 ClusterRole 的示例 YAML 文件：

   $ wget https://raw.githubusercontent.com/DataDog/datadog-agent/master/Dockerfiles/manifests/rbac/clusterrole.yaml
   

2. 将以下代码片段添加到 clusterrole.yaml 文件的末尾。在最新版本的 Kubernetes 中可能不需要这样做：

   - apiGroups:  
     - "apps"
     resources:
     - deployments
     - replicasets
     - pods
     - nodes
     - services
     verbs:
     - list
     - get
     - watch
   

3. 为 datadog-agent 创建 ClusterRole：

   $ kubectl apply -f clusterrole.yaml
   $ kubectl get clusterroles |grep datadog-agent
   datadog-agent     2021-03-18T07:32:49Z
   

4. 下载用于为 datadog-agent 创建 ServiceAccount 的示例清单，然后进行配置：

   $ wget https://raw.githubusercontent.com/DataDog/datadog-agent/master/Dockerfiles/manifests/rbac/serviceaccount.yaml
   $ kubectl apply -f serviceaccount.yaml
   $ kubectl get serviceaccounts |grep datadog-agent
   datadog-agent   1         23h
   

5. 下载用于创建 ClusterRoleBinding datadog-agent 的示例 YAML 文件，它链接到先前步骤中设置的 ClusterRole 和 ServiceAccount 资源：

   $ wget https://raw.githubusercontent.com/DataDog/datadog-agent/master/Dockerfiles/manifests/rbac/clusterrolebinding.yaml
   $ kubectl apply -f clusterrolebinding.yaml
   $ kubectl get clusterrolebindings |grep datadog-agent
   datadog-agent     ClusterRole/datadog-agent           23h
   

6. 为 API 密钥创建一个秘密：

   $ kubectl create secret generic datadog-agent --from-literal api-key="API-KEY" --namespace="default"
   $ kubectl get secrets |grep datadog-agent
   datadog-agent       Opaque         1      26h
   

7. 下载一个适合您需求的 Datadog Agent 的示例清单。完整列表可在 docs.datadoghq.com/agent/kubernetes/?tab=daemonset 上找到。为了本示例部署的目的，使用支持启用日志和指标的清单：

   $ wget https://docs.datadoghq.com/resources/yaml/datadog-agent-logs.yaml
   

8. 更新示例 Datadog Agent 清单，进行以下更改。

   在 datadog-agent 密钥资源部分，使用有效 API 密钥的 base64 编码值更新 api-key 字段。可以以不同方式进行编码，并且有在线工具可用于这些方式。如果您的工作环境中有 openssl，可以在命令行上可靠地执行编码：

   $ echo -n 'API-KEY' | openssl base64
   Y2Q1YmM5NjAzYmMyM2EyZDk3YmViMTxyzajc1ZjdiMTE=
   

9. 在代理程序的容器部分添加以下环境变量：

   DD_KUBELET_TLS_VERIFY to false on all Kubernetes platforms, so it's optional.
   

10. 部署 Datadog Agent DaemonSet：

    $ kubectl apply -f datadog-agent-logs.yaml
    $ kubectl get daemonset
    NAME DESIRED  CURRENT READY UP-TO-DATE  AVAILABLE  NODE SELECTOR AGE
    datadog-agent 1   1    1    1   1       kubernetes.io/os=linux   25h
    

可以通过 Kubernetes 仪表板查找和验证之前步骤中创建的 Kubernetes 资源。例如，如果所有前面的步骤都成功，您将能够看到列出 datadog-agent Pod，并显示状态为 Running，如下所示的截图：

图 12.5 – 在 Kubernetes 仪表板上列出的 datadog-agent Pod

同样，可以在 Kubernetes 仪表板上查找与部署 Datadog Agent 相关的其他资源，并可以从那里管理它们。

在成功部署 Datadog Agent 后，您将能够在 Containers 仪表板上查看 Kubernetes 基础设施资源和在集群中运行的容器，如以下截图所示：

图 12.6 – Kubernetes 资源和容器

通过点击感兴趣的容器，可以在 Containers 仪表板上查看与该容器相关的日志和指标，如您在上一节中学习到的内容，包括访问 Log Explorer 仪表板的权限。

查看 Kubernetes 平台资源的选项，例如 Pods、Deployments、ReplicaSets、Services 和 Nodes，与 Kubernetes Dashboard 提供的选项类似。然而，通过 Datadog 跟踪这些资源，还可以选择使用 Datadog 来监控这些资源。

我们已经学习了如何通过与 Docker 和 Kubernetes 的集成，使用 Datadog 来监控实时容器。在接下来的部分中，您将了解在 Kubernetes 环境中有关该功能的更多信息。

使用实时容器

实时容器是 Datadog 的一项功能，它提供了对实时容器运行情况的洞察。如您所知，Kubernetes 已经成为编排容器的行业标准，这不仅限于 Docker。Docker 只是用于打包和运行微服务的工具之一。尽管 Docker 仍然是主导的容器化平台，但像 CoreOS rkt 这样的工具也可以与 Kubernetes 配合使用，而且这一趋势正在获得动力。

Kubernetes 是一个复杂的平台，因此除了监控其运行的容器之外，监控 Kubernetes 平台本身同样重要。尽管 Kubernetes Dashboard 等原生应用程序是手动监控 Kubernetes 集群的首选工具，Datadog 的平台监控功能有助于将监控整合到一个平台上并实现自动化。

当 Kubernetes 集群完全配置，以便 Datadog Agent 发布集群级别和应用程序级别信息时，Containers 仪表板将如 图 12.6 所示。通过点击容器和 Kubernetes 资源，您可以随时查看相关的实时信息。

要能够将从 Kubernetes 集群捕获的信息发布到 Datadog，需要对集群进行配置。上一节已经讨论过一些配置内容，但值得再次回顾一些未讨论或未详细说明的重要事项：

• Datadog Agent 容器应定义以下环境变量：

  - name: DD_ORCHESTRATOR_EXPLORER_ENABLED
      value: "true"
  

• Datadog Agent 的 ClusterRole 应该设置权限，以便实时容器能够收集 Kubernetes 资源的信息。这个要求在上一节中已经讨论过，涉及到 clusterrole.yaml 文件的设置。

• 进程代理容器必须设置以下环境变量才能运行：

  - name: DD_ORCHESTRATOR_EXPLORER_ENABLED
    value: "true"
  - name: DD_ORCHESTRATOR_CLUSTER_ID
    valueFrom:
      configMapKeyRef:
        name: datadog-cluster-id
        key: id
  

• 设置DD_CLUSTER_NAME环境变量，适用于agent和process-agent：

  - name: DD_CLUSTER_NAME
    value: "<YOUR_CLUSTER_NAME>"
  The cluster name can be obtained from the Kubernetes configuration file.
  

在容器仪表板上，还列出了有关各种 Kubernetes 资源的信息，如节点、服务、部署和 Pod。通常，这些详细信息是通过 Kubernetes 仪表板 UI 进行查询和管理的，但将它们显示在 Datadog 容器仪表板上会很方便，因为这样您可以在一个位置收集来自多个 Kubernetes 集群的信息。

在容器和日志浏览器仪表板的日志标签页中，您可能已经注意到实时日志选项。我们将在下一节中进一步介绍该功能的更多细节。

使用实时日志查看日志

Datadog 的tail会持续输出它跟踪的日志文件中的任何新增内容。使用实时日志的好处是，可以在一个仪表板上跟踪来自多个来源的相似日志文件的更新。

实时日志选项在容器仪表板上也可用，如下图所示：

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/dtl-cld-mnt-qkstgd/img/Figure_12.7_B16483.jpg)

图 12.7 – 使用实时日志选项实时查看日志

日志浏览器也有一个实时日志选项，如下图所示：

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/dtl-cld-mnt-qkstgd/img/Figure_12.8_B16483.jpg)

图 12.8 – 在日志浏览器中使用实时日志

在本节中，您已经了解了如何利用实时日志选项查看日志并定期报告它们。在下一节中，您将学习如何搜索从容器收集的大量日志，并利用这些洞察进行监控。

搜索容器数据

到目前为止，我们的重点一直是收集来自容器及其运行基础设施的信息，并将这些信息发布到 Datadog 后端。各种 Datadog 仪表板，尤其是实时容器和日志浏览器，为用户提供了这些信息。在一个实际环境中，Datadog 可能会发布大量监控信息，这样的海量数据可能会让人感到有些难以处理。解决方案是使用关键词和标签来搜索信息，您将在本节中学习如何做到这一点。

可以使用关键词在实时容器仪表板上搜索容器，搜索将与容器名称、ID 和镜像名称匹配。例如，在以下截图中，查找了容器 ID：

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/dtl-cld-mnt-qkstgd/img/Figure_12.9_B16483.jpg)

图 12.9 – 使用容器 ID 搜索容器

结果可以通过使用标签进一步筛选和/或分组。容器也可以仅通过标签来筛选，而无需使用关键词。

关键词搜索不仅仅是针对简单字符串的搜索。它可以通过使用布尔运算符，如AND、OR和NOT，进行复合查询。例如，apache OR nginx将返回在搜索支持的字段中（如容器名称字段）包含apache或nginx的容器列表。可以使用括号来创建更复杂的搜索构造。

与容器一样，Kubernetes 集群中的资源，如Pods、ReplicaSets、Deployments和Services，也可以通过关键词和标签在实时容器仪表板中进行搜索和筛选。

现在让我们在下一节中看看与容器监控相关的最佳实践。

最佳实践

以下是在使用 Datadog 监控容器时应遵循的一些最佳实践：

• 将 Datadog 代理作为容器运行，以便轻松发现应用容器并提供灵活性。即使由于某些原因可能需要在主机级别运行 Datadog 代理，将其作为容器在同一主机上运行也是可以接受的，考虑到它带来的操作优势。

• 在 Kubernetes 环境中，不要尝试通过 Docker 集成直接访问容器日志；而是应该在 Kubernetes 集群上安装 Datadog 代理并配置它以收集日志。

• 尽管可以使用kubectl和 Kubernetes Dashboard 查看 Kubernetes 集群资源，但将它们集成到 Datadog 中有助于提高它们的可用性和健康状态的可见性。

总结

本章中，你学习了如何利用 Datadog 结合 Docker 和 Kubernetes 的集成功能来监控容器。你还学会了在 Datadog 收集到容器信息和容器日志后，如何进行容器信息和日志的搜索。阅读本章并尝试其中提供的示例后，你已经为使用 Datadog 监控在 Docker 和 Kubernetes 环境中运行的容器做好了准备。

日志聚合、索引和搜索是监控中的一个主要领域，业内有许多重大举措，比如ELK Stack、Splunk和Sumo Logic。Datadog 也提供了解决方案，你将在下一章学习到相关内容。

第十三章：使用 Datadog 管理日志

操作系统、各个平台组件和应用服务生成的日志包含了大量关于基础设施状态以及其上运行的应用程序工作情况的信息。在中央存储库管理所有日志，并对其进行分析以获得运营洞察和监控数据，这是监控中的一个重要领域。它通常涉及日志的收集、聚合和索引。在第一章《监控概述》中，简要讨论了这种监控类型。在第十二章《监控容器》中，你学习了如何将容器中的日志发布到 Datadog，以便聚合和索引，从而便于搜索。

在这个领域，一些流行的监控产品包括 ELK Stack（Elasticsearch、Logstash 和 Kibana）、Splunk 和 Sumo Logic。现在，Datadog 也提供了这个功能，你在上一章中已经见过了其前端工具日志浏览器。

在本章中，我们将详细探讨 Datadog 的日志聚合和索引功能。具体来说，我们将关注以下主题：

• 收集日志

• 处理日志

• 归档日志

• 搜索日志

技术要求

若要尝试本书中提到的示例，你需要安装以下工具并具备相关资源：

• 一个具有管理员权限的 Datadog 帐户

• 在主机级别或根据示例作为微服务运行的 Datadog 代理，指向 Datadog 帐户

收集日志

任何日志管理应用程序的第一步是将日志收集到一个公共存储库中，以便稍后进行分析和归档保存。这项工作包括将日志文件从可用的机器和服务发送到公共存储库。

以下图表展示了收集和处理日志的工作流程，并将聚合后的信息呈现给最终用户。聚合后的信息可以作为指标发布，这些指标可用于设置监控。这与在传统监控应用程序中使用指标设置监控是相同的：

图 13.1 – 日志管理工作流程

在现代生产基础设施中，日志可能由多种来源生成，典型的来源包括以下几种：

• 公共云服务：公共云服务如 AWS S3 和 RDS 非常流行，尤其是在生产基础设施主要使用公共云服务构建的情况下。这些服务的日志可以通过相关的 Datadog 集成功能发送到 Datadog。

• 微服务：Datadog 为 Docker 和 Kubernetes 提供的集成功能可用于将这些日志发送到 Datadog。我们在上一章中已经看过如何实现这一操作。

• 主机：传统上，日志作为文件存储在主机上的磁盘位置，可能是裸金属或虚拟主机。可以配置 Datadog 代理将本地日志文件传输到 Datadog 后端。

现在，让我们来看一下 Datadog 如何收集和传输日志，了解上面总结的最常见用例的详细信息。

从公共云服务收集日志

Datadog 提供了与主要公共云平台（如 AWS、Azure 和 GCP）上提供的服务集成和日志收集方法。以下是可用的特定于云平台的方法：

• Cloudformation 和 Kinesis Firehose 基于的选项可以用于自动化收集 AWS 服务的日志。

• 在 Azure 上，收集日志的自动化是基于 Azure Event Hub 和 Azure Function 的。

• 在 GCP 上提供 Datadog 集成，可收集该平台上提供的服务的日志。

从容器传输日志

当容器在 Docker 上运行，而不在 Kubernetes 集群中时，可以通过配置 Datadog 代理和相关的 Docker 镜像，将容器的日志传输到 Datadog。主要要求是在同一主机上部署一个 Datadog 代理作为容器。你在上一章已经了解了如何做到这一点。第二步是为 Docker 镜像添加容器标签，以便 Datadog 代理可以自动发现这些日志。例如，NGINX Dockerfile 中的以下标签有助于 Datadog 代理收集从该镜像启动的 NGINX 容器的日志，并以 webapp 作为容器运行：

LABEL "com.datadoghq.ad.logs"='[{"source": "nginx", "service": "webapp"}]'

对 Docker 镜像进行工具化可能并不总是可行，因为某些镜像可能由第三方提供，或者进行此类更改在操作上不可行。在这种情况下，可以在 Datadog 代理的运行环境中指定环境变量 DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL，以收集该主机上运行的所有容器的日志。如果有任何日志需要排除在聚合之外，Datadog 提供了选项，可以在将这些日志发送进行处理之前将其过滤掉，稍后我们会在本节中讨论这个问题。

在 Kubernetes 集群中配置，将在该环境中运行的日志传输到 Datadog 后端的方式，类似于在 Docker 主机上的配置方式：

• Datadog 代理必须作为容器在集群中运行。

• 应用容器必须被注解，DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL 必须设置为 true，以便从集群中所有运行的容器中传送日志。例如，要启用 NGINX 容器的自动发现，必须在 Kubernetes 的部署描述中包含以下注解：

  template:
      metadata:
        annotations:
          ad.datadoghq.com/nginx.logs: '[{"source":"nginx","service":"webapp"}]'
  

接下来，我们来看看当 Datadog 代理在主机级别运行时，收集日志需要哪些配置。

从主机传输日志

可以通过 Datadog 为第三方应用提供的集成功能，将来自主机（Datadog Agent 运行所在的主机）的日志传送。如果没有可用的集成，则可以按照本节所述的自定义方法传送应用程序生成的日志：

在第一种情况中，应用程序如 NGINX 可用 Datadog 集成时，可以使用现有的配置文件来指定日志收集要求，如下例所示：

# in the config file conf.d/nginx.d/conf.yaml add the following configuration.
logs:
  - type: file
    service: webapp
    path: /var/log/nginx/access.log
    source: nginx
  - type: file
    service: webapp
    path: /var/log/nginx/error.log
    source: nginx

在前述示例场景中，日志文件 /var/log/nginx/access.log 和 /var/log/nginx/error.log 已配置为进行收集。如果需要直接从运行在端口上的服务收集日志，则日志类型将为 tcp 或 udp，并且必须用 port 替代 path 来指定端口。

在 Datadog Agent 配置中，默认情况下并未启用日志传输选项，需要在 datadog.yaml 文件中设置：logs_enabled: true。

如果应用程序没有现成的集成，需为该应用程序设置自定义配置文件以传输该应用生成的日志。以下是具体步骤：

• 在 conf.d 目录下，根据以下语法创建一个子目录，命名为 <CUSTOM_APP>.d/conf.d。

• 在新目录中，创建配置文件 conf.yaml，并为每个要收集的日志添加以下条目：

  logs:
    - type: file
      path: "</path/to/logfile>"
      service: "<CUSTOM_APP>"
      source: "<SOURCE_NAME>"
  

必须重新启动 Datadog Agent，以使这些配置更改生效。

日志过滤

如你所见，配置 Datadog Agent 或集成以从任何环境收集日志是相当简单的。然而，将日志中跟踪的所有信息传送到 Datadog 可能并非明智之举，原因有很多，以下是一些原因：

• 安全问题

• 由与客户的协议所施加的限制

• 法规要求

• 合规控制措施

因此，可能需要过滤掉日志中不用于监控、且不允许与更广泛的受众共享的信息。此外，这种过滤有助于减少存储使用量和传输到 Datadog 后端的数据量。

两个预定义规则 include_at_match 和 exclude_at_match 可以在收集阶段用于过滤日志。这些规则与正则表达式一起工作——如果日志条目与规则中使用的正则表达式匹配，则根据规则类型，日志将被包含或排除。

在下面的示例中，所有以字符串 k8s-log 开头的日志条目将被忽略：

logs:
  - type: file
    path: "</PATH/TO/LOGFILE>"
    service: "webapp"
    source: "nginx"
    log_processing_rules:
       - type: exclude_at_match
         name: exclude_k8s_nginx_log
         pattern: ^k8s-log

同一个日志文件允许多个 include_at_match 规则，这将导致 AND 条件。也就是说，必须同时满足两个规则，才能收集日志条目。

要实现 OR 规则，必须在同一表达式中使用 | 符号指定条件，如下例所示：

pattern:  ^warning | ^err

这将导致任何以warning或err开头的行被 Datadog 代理收集。

如您之前所见，过滤规则可以通过 Docker 运行时中的标签实现，也可以通过 Kubernetes 中的注释来实现。

从日志中清除敏感数据

聚合日志并将其展示给更广泛的受众时，常见的问题是日志中可能记录的敏感信息会不小心暴露，这会导致严重的安全和隐私问题。限制访问聚合日志的监控应用程序（如 Datadog 的日志管理界面）可能会影响其一般用途。更好的解决方案是在日志被传输到 Datadog 后端进行处理之前，从源头上清除日志中的敏感信息。

虽然您之前看到的过滤选项可以帮助避免收集包含敏感信息的完整日志条目，但它可能会遗漏日志中的某个重要细节，影响分析或监控。因此，对这些信息进行编辑是更好的选择，这样可以在日志中保留足够的操作细节。

用于清除信息的规则类型是mask_sequences。它与replace_placeholder选项一起工作，replace_placeholder决定了如何用占位符替换敏感信息，以表明日志条目中的信息已被遮蔽。

以下示例解释了如何同时使用这两个选项来实现所需的编辑效果，这种方法非常有效：

 log_processing_rules:
      - type: mask_sequences
        pattern: "^(User:.*), SSN:(.*), (.*)$"
        replace_placeholder: "${1}, SSN:[redacted], ${3}"

上述示例规则将把日志条目中包含 SSN 信息的字段替换为字符串SSN:[redacted]。这是通过将日志条目分为三部分，并使用replace_placeholder中提到的格式重新组装来完成的。pattern中的每个()构造中匹配的内容将作为编号变量在replace_placeholder中使用。

如前所述，这些规则必须在主机级别的datadog.yaml文件中添加，类似的规则可以通过 Docker 运行时中的标签实现，也可以在 Kubernetes 集群中通过注释实现。

您已经了解了 Datadog 如何从不同环境收集日志，并将其集中存储以进行处理，从而获得运营见解（如度量标准）并生成搜索索引。在接下来的章节中，我们将了解 Datadog 如何处理日志，并讨论该过程中涉及的资源。

处理日志

一旦日志被 Datadog 收集，它们将在日志浏览器中提供查看和搜索功能。Datadog 会自动处理结构化的 JSON 格式日志。未结构化的日志可以进一步处理并提取分析见解。Datadog 使用管道（Pipelines）和处理器（Processors）来处理传入的日志。

要查看可用的管道，请从主菜单中打开日志 | 配置菜单选项。管道列在管道标签下，如以下示例截图所示：

图 13.2 – 日志处理管道

管道可以接收日志的子集，并使用一组处理器按顺序执行以处理日志。根据当前使用的 Datadog 集成，提供了预定义的管道，并且如果相关日志被 Datadog 收集，则这些管道会被启用。也可以设置自定义管道以满足特定的索引要求。

在下图中，列出了Apache httpd示例集成管道中使用的处理器：

图 13.3 – 样本管道中的处理器列表

解析规则的详细信息以及从日志条目中解析出的结构化信息可以通过点击每个处理器旁边的查看图标来查看。例如，在Apache httpd管道中，Grok 解析器：解析 Apache httpd 日志处理器在处理后提取以下结构化信息：

{
  "http": {
    "status_code": 200,
    "auth": "frank",
    "method": "GET",
    "url": "/apache_pb.gif",
    "version": "1.0"
  },
  "network": {
    "bytes_written": 2326,
    "client": {
      "ip": "127.0.0.1"
    }
  },
  "date_access": 1468407336000
}

所有预定义的管道可以通过在主日志仪表板中的管道标签下点击浏览管道库链接来查看，如图 13.2所示。

可以基于查询生成基于日志的指标。要设置新指标，请导航至日志 | 生成指标 | 新指标。主要内容是提供一个查询，以便准确地定义新指标。以下是生成指标窗口的示例截图：

图 13.4 – 从日志生成新指标

默认情况下，Datadog 将所有处理过的日志跟踪到一个索引中。Datadog 提供了创建多个索引的选项，以便对索引数据进行更精细的控制。例如，可以根据被跟踪日志子集的重要性，设置不同的保留期。

在本节中，您已经了解了如何使用带处理器的管道从非结构化日志中提取信息。在下一节中，我们将探讨如何归档和按需检索由 Datadog 收集的日志。

归档日志

将日志集中存放在一个地方本身就为企业带来了显著的优势，因为集中存放的日志可以简化访问，并且来自多个来源的日志可以轻松地关联和分析。对于监控和报告汇总的信息，这样的方式已经足够，而且不需要保留旧日志。然而，出于合规性和未来审计的需要，企业可能需要保留日志更长时间。由于旧的、原始的日志不再需要用于当前使用，因此可以将这些日志归档，按需取回。

Datadog 提供了以公共云存储服务作为后端存储基础设施的存档选项。要为 Datadog 收集的日志子集设置存档，通常的步骤如下：

• 与云服务设置集成：此步骤需要与公共云存储服务进行集成：AWS S3、Azure 存储或Google Cloud Storage。

• 创建存储桶：这个存储桶将用来存储日志。

• 设置权限：设置存储桶的权限，使 Datadog 能够在其中存储和访问日志。

• 将日志路由到存储桶：在此步骤中，创建一个新的存档并将其指向前一步骤中设置的新存储桶。此选项可以在日志 | 存档标签下找到。

这些步骤在使用不同的公共云存储服务存储存档时有很大不同，相关的详细信息可以在docs.datadoghq.com/logs/archives的官方文档中找到。

当需要将存档日志加载回 Datadog 时，通常是由于需要进行某些审计或根本原因分析（这种事件在实际中很少发生），可以使用从存档恢复选项。导航到日志 | 从存档恢复。

在下一部分，我们将探索 Datadog 收集的日志如何进行搜索，这是一个受运维团队欢迎的重要工具。

搜索日志

要搜索日志，请导航至日志 | 搜索，搜索窗口应如以下截图所示：

图 13.5 – 搜索日志

搜索查询由error和"found error"组成。要构建复杂的搜索查询，可以使用以下boolean运算符将术语和序列结合起来：

• AND：两个术语必须都出现在所选的日志条目中。

• OR：其中一个术语必须出现在所选的日志条目中。

• - (排除)：术语后跟字符“-”，并且应排除在所选日志条目中。

可以使用内建的关键词，如host或source，作为搜索词，通过使用搜索字段中的自动完成功能。只需点击搜索字段，即可查看所有可用的术语，如以下截图所示：

图 13.6 – 搜索用途的内建关键词

特殊字符在搜索词中需要进行转义，可以通过在要转义的字符前加上\字符来实现。有关需要转义的特殊字符的完整列表，请查阅docs.datadoghq.com/logs/search_syntax的完整列表。

支持通配符*，并按其通常的含义使用。例如，service*将匹配所有以service开头的日志条目，*service将匹配所有以service结尾的日志条目。

成功的搜索可以保存以备未来使用。保存按钮位于搜索仪表盘的左上角，可以用来保存当前搜索，如下图所示：

图 13.7 – 保存搜索查询

保存的搜索可以列出并通过视图链接重新运行，如同在图 13.7中所示的截图。

你已经学习了如何通过日志浏览器（Log Explorer）仪表盘上的搜索界面搜索由 Datadog 汇总的日志，并了解如何使用关键词和运算符。此部分总结了本章的内容，接下来我们将探讨与 Datadog 日志管理相关的最佳实践和总结。

最佳实践

在日志管理中存在一些最佳实践模式。让我们来看一下如何利用相关的 Datadog 功能来实现这些模式：

• 计划收集尽可能多的日志。如果后来发现某些日志无用，最好停止收集它们。

• 尽可能地，特别是在你能控制格式的应用程序日志中，使日志格式便于解析。

• 考虑生成新的日志，用于从这些日志中生成指标。这样的努力在生成报告数据方面被证明是非常有用的。

• 确保在允许 Datadog 收集日志之前，敏感信息已经被删除。

• 实施日志中敏感信息的删除，而不是过滤掉日志条目。但是，过滤掉那些可能没有用的日志条目，以便 Datadog 处理的日志量尽可能最小。

• 创建一个搜索库并发布供大家使用。创建复杂查询比较困难，分享这些查询能提高团队的效率。

总结

在本章中，你已经学习了 Datadog 如何收集日志、处理这些日志，并提供对各种汇总信息以及原始日志的访问。Datadog 还支持将日志归档，并且兼容公共云存储服务。通过使用日志浏览器（Log Explorer），你可以搜索整个活动日志集，且有效的搜索可以保存以供未来使用。

在下一章，即本书的最后一章中，我们将讨论一些尚未涉及的高级 Datadog 功能。

第十四章：杂项监控主题

到目前为止，本书中已讨论了 Datadog 实现的核心监控功能。在本章中，您将了解一些最近才在 Datadog 监控平台上推出的监控功能。这些功能，尤其是应用性能监控（APM）、安全监控和合成监控，通常由专用应用程序处理。AppDynamics 是 APM 领域的一个例子，安全信息与事件管理（SIEM）应用程序用于安全监控，而 Catchpoint 是合成监控领域的专用监控应用程序。随着这些功能在 Datadog 平台上的推出，它正成为所有监控需求的一站式平台。

本章中，您将学习以下主题，具体包括：

• 应用性能监控（APM）

• 实现可观察性

• 合成监控

• 安全监控

技术要求

要尝试本书中提到的示例，您需要安装以下工具并提供资源：

• 一个带有 Bash Shell 的 Ubuntu 18.04 Linux 环境。可以使用其他 Linux 发行版，但需对任何特定于 Ubuntu 的命令进行适当的更改。

• 一个 Datadog 帐户和具有管理员级访问权限的用户。

• 在主机级别或作为微服务运行的 Datadog 代理，指向 Datadog 帐户，具体取决于示例。

• curl 和 wget。

应用性能监控（APM）

正如名称所示，APM 工具通过多种方法监控应用程序的性能。APM 本身就是一个广泛的领域，如前所述，专用产品会处理它。APM 还可以代表应用性能管理，这为 APM 的讨论增加了一些混淆。共识是，要作为应用性能管理解决方案，监控工具应具备处理由工具的监控功能发现的性能问题的功能。Datadog 仅使用 APM 这一缩写，我们将在这一框架下审查功能，而不太关注 APM 的扩展。

以下是标准 APM 解决方案的一般功能：

• 测量最终用户体验

• 将用户发起的应用工作流映射到底层基础设施

• 测量应用工作流的性能

• 跟踪代码与用户与应用程序交互的过程

• 提供分析和报告选项，以将所有前述功能关联起来，并在仪表板上呈现洞察。

如您所见，这些是广泛的领域，每个 APM 解决方案都有自己实现这些功能及更多功能的方式。您还将了解到，观察性和合成监控，这两个将在后续专门章节中讨论的主题，也与 APM 相关。在本节的剩余部分，我们将查看 Datadog 中可用的 APM 功能，并尽可能地将其与前面列表中提到的广泛类别相关联。

将跟踪数据发送到 Datadog

使用 Datadog APM 的一个主要步骤是配置应用程序以将应用程序跟踪发送到 Datadog 后端进行分析。执行此操作的详细步骤取决于用于构建应用程序的编程语言以及运行应用程序的应用程序服务器环境。由此生成的跟踪信息将发布到 Datadog 后端，该信息是衡量性能和构建由应用程序组成的各种服务的可追溯性的基础。

为了理解在 Datadog APM 中生成跟踪的应用程序操作步骤，我们来看一下如何为 Java 应用程序进行操作。我们可以使用Cassandra作为示例 Java 应用程序，该应用程序在第十章中介绍过，与监控标准合作。安装 Cassandra 的步骤已经在该章节中记录。在这里，您将学习如何为 Cassandra 应用程序启用跟踪：

1. 如果 Cassandra 服务正在运行，请停止该服务：

   $ bin/nodetool stopdaemon
   

2. 使用 wget 或 curl 下载 Datadog 跟踪的 Java 库：

   $ wget -O dd-java-agent.jar https://dtdg.co/latest-java-tracer
   

3. 在环境变量 JAVA_OPTS 中定义跟踪指令：

   $ export JVM_OPTS="-javaagent:/<PATH/TO>/dd-java-agent.jar -Ddd.service=cassandra"
   

4. 启动 Cassandra 服务：

   $ bin/cassandra
   

示例命令假设用户所在的目录是已解压的 Cassandra 安装包所在目录，例如 /home/ubuntu/apache-cassandra-3.11.10。请根据实际安装路径做适当调整。

在前面的示例步骤中，已经概述了如何为运行在主机级别的 Java 应用程序启用跟踪。为运行在 Docker 和 Kubernetes 运行时环境中的服务进行工具化的步骤也类似，但有些特定于相关平台的差异。同时请注意，这些步骤对于构建应用程序所使用的编程语言是唯一的。所有这些变体在官方文档中都有记录，从docs.datadoghq.com/tracing/开始。

一旦如上所述为应用程序启用了跟踪，您可以通过导航到 APM | Traces，在 APM 仪表板上查看这些跟踪，如下图所示：

图 14.1 – APM 跟踪仪表板

这些发布到 Datadog 后端的追踪提供了对应用程序特定请求、错误和延迟的深入可视化。应用程序的追踪可以与基础设施层面的指标、主机上运行的进程以及各种日志进行关联，从而帮助定位各层级的性能瓶颈。

分析应用程序

通过使用 Datadog APM 的连续分析器功能，可以通过深入到类、方法和行号，追踪资源使用和 I/O 瓶颈到应用程序代码。启用此功能也需要进行代码仪器化，我们可以通过 Cassandra 应用程序来尝试。

为应用程序添加分析工具的步骤与为追踪功能所做的类似。实际上，最新的追踪代理也支持分析，两者都可以通过以下命令行启用：

$ export JVM_OPTS="-javaagent:/home/ubuntu/dd-java-agent.jar -Ddd.service=cassandra -Ddd.profiling.enabled=true"
$ bin/cassandra

正如您在命令行中所看到的，环境变量dd.profiling.enabled被设置为true，以启用分析功能，除了追踪功能外。

通过导航到APM | Profiles，可以在连续分析器仪表板上查看与分析相关的报告，如下图所示：

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/dtl-cld-mnt-qkstgd/img/Figure_14.2_B16483.jpg)

图 14.2 – 连续分析器仪表板

此仪表板上列出的分析可以通过各种标签进行过滤，包括通常用于识别主机级别上运行的应用程序的服务名称。在微服务环境中，一个应用程序由多个服务组成，并且可以通过适当的标签化服务轻松跟踪这些属于该应用程序的服务。

通过点击仪表板上列出的一个分析，基于分析数据的性能指标和洞察可以查看，如下图所示：

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/dtl-cld-mnt-qkstgd/img/Figure_14.4_B16483.jpg)

图 14.3 – 应用程序分析详情

在前面的仪表板上，性能、分析、指标和运行时信息标签下，提供了大量关于应用程序的运行时信息，用于处理性能问题并对应用程序的性能和安全性进行微调。

服务地图

服务地图将提供运行时环境中服务的图示表示，例如主机或 Kubernetes 集群，并绘制出服务之间的交互。服务地图可以通过导航到APM | Service Map来访问，仪表板将显示服务标签页，如下图所示：

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/dtl-cld-mnt-qkstgd/img/Figure_14.4_B16483.jpg)

图 14.4 – 服务地图仪表板

Service Map 在微服务环境中（例如 Kubernetes 集群）将非常有用，用于理解应用程序各个组件之间的交互。通过为每个微服务启用跟踪和性能分析，可以构建应用系统的服务映射，这将为优化应用程序性能提供宝贵的见解。

在本节中，您已经了解了 Datadog 中如何通过为应用程序仪表化以生成跟踪和配置文件，并汇总这些输入以推断见解来实现各种 APM 功能。同时讨论了可观测性和合成监控，以及通常情况下的 APM，但我们将在单独的章节中讨论这些主题，因为这些主题足够通用，可以在更广泛的监控上下文中理解。

在下一节中，让我们讨论可观测性及其在 Datadog 中的实现。

实施可观测性

可观测性指的是使应用系统工作更透明和可测量的过程和方法。增强应用系统的可观测性将使其更适合监控。可观测性是应用系统本身的属性，而监控是利用该属性来满足操作需求的行为。

可观测性相对于监控词汇来说是一个比较新的概念，但它是从系统控制理论中重新解释而来。可观测性的概念由匈牙利裔美国工程师鲁道夫·E·卡尔曼引入，用于线性动态系统，它表明可观测性是从系统外部输出知识推断系统内部状态的好坏程度的度量。在监控的背景下，外部输出可以是各种指标、日志和跟踪。因此，具有可观测性特性的监控工具应该有助于生成和分析与应用系统工作透明性相关的各种输出，使用一组方法、过程和仪表板进行分析。这些特性将有助于增加监控工具监控的应用系统的可观测性。

虽然显而易见的是，添加可观察性对更好的监控至关重要，但你可能会好奇为什么可观察性是一个相对较新的监控术语。原因之一是，现代应用程序系统及其运行的基础设施现在远比以前复杂。过去那种单体应用程序仅在数据中心的少数裸金属机器上运行的时代已经一去不复返。现在的应用程序高度分布式，它们运行在公共云上，并由复杂的编排工具（如 Kubernetes 和 Spinnaker）进行管理。尽管现代应用程序系统更具前瞻性，灵活性和可扩展性大大提高，但应用程序系统复杂性的增加降低了整体可观察性。在这种情况下，必须采取有意的步骤来改善可观察性，这就是为什么商业监控工具现在都配备了此类功能的原因。

指标、日志和追踪通常被认为是可观察性的三大支柱。在本书中，你已经看到 Datadog 的功能主要集中在指标和标签上。Datadog 监控功能开箱即用地生成各种指标。Datadog 还提供创建自定义指标和标签的选项，这将增加对应用程序或基础设施组件工作情况的可见性。如在第十三章中所示，使用 Datadog 管理日志，Datadog 的日志管理功能在管理各种日志方面非常全面，包括来自 Docker 和 Kubernetes 等微服务平台的日志。在本章前面的 APM 部分，你也已经看到 Datadog 如何生成、收集和分析应用程序的追踪。

虽然 Datadog 拥有实现应用程序可观察性所需的所有基本组件，但这基本上是一个定制的工作，需要为每个应用程序系统单独完成。应用程序的引导和部署流程必须得到增强，以包括添加可观察性所需的仪器化步骤。让我们来看一下在 Datadog 中需要哪些仪器化操作：

• 添加平台组件级别的指标：通常通过使用 Datadog 提供的集成来完成。如果它能增加更多价值，可以考虑添加自定义指标并使用社区开发的集成。

• 添加应用程序指标：这是定制性质的，并且包括在开发过程中。就像单元测试是构建过程中的要求一样，也应将其作为新服务在构建或发布阶段获得批准的要求。

• 自动化日志管理：对构建和部署清单进行仪器化，比如 Dockerfiles 和 Kubernetes 部署脚本，以便将日志发布到 Datadog 的日志管理后端。必须在所有层级上自动化这一过程，因为如果手动完成，它是无法扩展的。

• 自动化生成跟踪和配置文件：增强构建和部署过程，自动生成跟踪和配置文件，这样这些数据就能方便地提供给 Datadog APM 服务进行分析并构建服务地图。APM 是实施可观察性的关键方面。

• 使用 Datadog 满足所有监控需求：如同本章之前所提到的，其他厂商也提供专用的日志管理和 APM 应用程序。使用 Datadog 的一个优势是，Datadog 不仅提供核心监控功能，还提供这两个功能。这为在单一平台上使用标签和相关结构关联各种指标、日志和跟踪数据提供了机会。如果操作得当，这将通过将所有信息集中在一个地方来增强应用程序的可观察性，而 Datadog 通常会在不同功能之间关联可用的监控信息。

很明显，Datadog 能够整合可观察性的三大支柱——指标、日志和跟踪——是该平台的一大优势。为了利用相关的现成功能，必须增强和工具化应用程序的构建和部署过程，以便日志和跟踪数据能自动且无缝地发布到 Datadog 后台。

在下一节中，我们将讨论合成监控，指的是通过请求和模拟用户体验的操作在生产环境中实时测试应用程序。

合成监控

在合成监控中，应用程序的使用是通过一个模拟的机器人用户进行的，收集到的模拟数据构成了可操作的步骤的基础，例如触发应用程序性能属性或应用程序本身可用性的警报。通常，以下是可以通过合成监控工具和方法监控的应用程序状态：

• 应用程序在各方面都可用。这可能涉及检查应用程序的多个 Web 或 API 端点。

• 应用程序的性能，即应用程序响应用户请求的速度。

• 应用程序能够按设计执行业务交易。

• 用于构建应用程序系统的第三方组件正在正常运行。

• 达到的应用程序性能是具有成本效益且在预算之内的。

这些方面大多与通过一系列指标衡量用户体验相关，这些指标的值是通过应用程序的机器人使用生成的。机器人访问可以是本地的，即应用程序托管的地方、数据中心或公共云，或者接近实际用户所在的位置。监控的后一种方式被称为“最后一公里监控”，这是我们在第一章《监控简介》中讨论的一种监控类型。现有专门的 SaaS 监控解决方案来满足最后一公里监控需求。借助 Datadog 的合成监控功能，也可以解决典型的最后一公里监控需求。

Datadog 的合成监控功能提供了多种检查，用于模拟最终用户的体验。这些测试从全球范围内 Datadog 管理的位置发起，您可以选择配置这些测试的来源位置。以下是使用 Datadog 的合成监控可以执行的检查类别：

• DNS：检查域名是否解析，并且在用户所在的地区解析速度如何

• ICMP：ping 启用了 ICMP 协议的主机，检查其可用性及从用户所在位置的访问情况

• 80），HTTPS（443），SSH（22），以及任何自定义端口

• HTTP/HTTPS：检查 Web 应用程序端点是否正常，并正确响应

• HTTP 工作流：通过串联 HTTP 请求验证涵盖完整交易的多请求工作流

• SSL：验证和检查与 HTTPS 端点相关的 SSL 证书的有效性及过期时间

现在，让我们看看这些检查中的一些是否可以在 Datadog 中进行配置。与合成监控相关的选项可以从主菜单 UX 监控 访问。导航到 UX 监控 | 新建测试，然后点击 开始 链接，您将看到如下截图所示的选项：

图 14.5 – 合成监控选项

让我们创建一个示例 TCP 测试，检查从巴黎和东京访问 SFTP 主机的情况。为此，需要提供 SFTP 服务器的公共 IP 地址或其域名来配置测试。由于 SFTP 服务在端口 22 上可用，因此可以在该端口进行检查。

点击 新建 API 测试，选择 TCP 标签页，进入可以配置 TCP 测试的表单。表单的第一部分如下面的截图所示，您可以在此输入测试的名称和 SFTP 服务器的信息：

图 14.6 – 创建合成 TCP 测试；服务器详细信息

使用表单中的 Test URL 链接，可以验证端口 22 上服务器的基本访问。然后，可以将来自特定区域的访问添加到测试中，如下截图所示：

图 14.7 – 创建合成 TCP 测试；选择访问位置

可以选择多个由 Datadog 管理的位置，如前面的截图所示。SFTP 服务器的访问将来自所选的位置。其余的选项与一般设置标准 Datadog 监控器的选项类似。

其他类型的 TCP 测试 – HTTP、DNS、SSL 和 ICMP – 可以通过选择 新建 API 测试 表单中的相关标签，按照类似的步骤进行配置。

在实际场景中，会配置多个类似的测试，以验证应用程序的各个组件和工作流程是否在用户所在地区可用。可用性状态仪表板将类似于以下截图所示，并且可以通过导航到 用户体验监控 | 合成测试 来访问：

图 14.8 – 合成监控仪表板

总体的正常运行时间状态将显示在此仪表板上，结果可以通过不同的条件进行筛选，例如测试来源区域。单个测试列在此仪表板底部，点击某个特定项目，可以查看和更新该测试的详细信息，如下截图所示：

图 14.9 – 合成 TCP 测试的详细信息

从此页面，可以暂停测试或根据需要临时运行测试，而无需等待下次计划运行。这些检查看似简单，但非常强大，因为通过这些设置，你可以像最终用户使用应用程序一样访问服务。

使用 浏览器测试，可以模拟用户在访问 Web 应用时使用的设备和浏览器。要创建 浏览器测试，请导航到 用户体验监控 | 新建测试 | 新建浏览器测试，你将看到新测试创建表单，如下截图所示：

图 14.10 – 模拟用于访问的浏览器和设备的合成测试

要完成此测试的创建，需要选择浏览器、设备和位置。根据你访问 Datadog 仪表板时所使用的浏览器，可能需要安装 Datadog 提供的浏览器插件，以便记录需要由测试模拟的网页工作流程。你将获得一个选项，录制工作流程并将其保存为创建测试的一部分。

一旦测试结果出来，你可以在仪表板上查看，如下示例截图所示：

![图 14.11 – 一个示例浏览器测试结果]

](https://github.com/OpenDocCN/freelearn-devops-pt4-zh/raw/master/docs/dtl-cld-mnt-qkstgd/img/Figure_14.11_B16483.jpg)

图 14.11 – 一个示例浏览器测试结果

如你所见，示例测试揭示了多个问题。你可以深入报告并查看每个问题的详细信息。像这样的测试结果对于微调 Web 应用程序非常有价值，因为你现在可以看到用户如何从特定的计算设备和浏览器组合访问应用程序。

合成监控本质上是模拟可以衡量的用户体验。这就是它被视为 APM 的一部分的原因，因为合成监控测试的输入可以用来优化应用程序，以获得更好的用户体验。在接下来的部分中，你将了解 Datadog 监控平台提供的安全监控功能。

安全监控

网络安全在云环境中变得更加重要和必要，因为应用程序需要通过互联网访问，并且在大多数情况下，应用程序本身托管在公有云中。在自己的数据中心运行应用程序并仅在私人网络中访问它不再是一个选项。暴露于外部攻击的基础设施和应用程序应该得到保护和加固。如今有一整套软件应用和服务，解决着各种网络安全问题。

另一个方面是满足安全性、隐私和合规性标准的要求，尤其是在应用程序面向医疗保健和金融行业时。合规性要求由适用于所在司法管辖区的法律规定，而安全标准则是客户的要求。合规性要求通常由该领域的第三方服务提供商进行审计，并且这些要求必须得到监控并记录为审计员的证据。

Datadog 的安全与合规性监控功能提供了多个选项，可以在组织中推出，以应对常见的网络安全和合规性要求。此外，Datadog 还具有作为多种监控类型统一平台的优势。通过结合来自基础设施和应用程序的日志和追踪的分析，以及强大的监控功能，如告警和事件管理，Datadog 还可以配置为 SIEM 平台。拥有 SIEM 工具通常是证明一个组织具备健全网络安全实践的要求。

现在，让我们回顾一下 Datadog 平台上当前可用的安全功能，并查看开始使用这些功能的一般步骤。可以从主安全菜单中访问这些安全选项，如下图所示：

图 14.12 – Datadog 安全与合规监控选项

启用安全功能的一般步骤如下：获取日志、定义安全规则、并根据安全规则从源信息中标记安全信号进行监控。运行时安全功能有助于通过监控系统级活动（如文件或进程的变化）来检测生产基础设施中的威胁，应用负载在其中运行。合规性检查功能有助于审计生产基础设施，确保其符合行业标准的安全规范，如支付卡行业（PCI）数据安全标准和互联网安全中心（CIS），这些标准帮助审计基础设施中的漏洞。

现在，让我们来看一下如何将信息输入 Datadog 进行安全分析，并利用这些洞察力来加强基础设施和应用程序的安全性。

日志来源

Datadog 可以从多种公有云平台和安全产品中获取日志，以查找安全威胁。下图列出了可以与 Datadog 集成的日志来源的一般类别：

图 14.13 – 用于安全分析的日志来源

以下是 Datadog 可以分析的四类日志来源，用于检测安全威胁：

• 公有云平台 – AWS、Azure 和 GCP

• 容器产品和服务，如Docker、Kubernetes和Amazon EKS

• 身份提供者 – Okta、Auth0、G Suite 和 Azure Active Directory。

• 安全产品，主要是AWS上的服务，和其他产品，如HashiCorp Vault

集成方法是针对每个产品特定的，通过选择前述仪表盘上列出的产品，可以查看安装过程。

定义安全规则

Datadog 提供了一些预定义规则，可以直接用于分析 Datadog 从上文提到的各种来源收集的日志。可以通过导航到安全 | 安全规则来访问安全规则仪表盘，仪表盘上列出了可用的规则，如下图所示：

图 14.14 – 安全规则仪表盘

这些规则可以在此仪表盘上启用或禁用。同时，可以通过使用新规则链接添加自定义规则。

监控安全信号

当基于活动的安全规则在日志中找到潜在威胁时，会创建一个安全信号。这类似于当指标值超过阈值时，监控生成警报。像警报一样，信号可以广播给多个受众。通过导航到安全 | 安全信号，这些信号也可以在安全信号仪表板上查看。

本节中我们对 Datadog 平台上的安全功能做了一个概览。这是一个仍在持续改进的领域，但它的整体发展方向非常鼓舞人心，尤其是在可用功能的易用性和与安全信息源集成的简便性方面。在下一节中，我们将探讨与本章所讨论主题相关的最佳实践。

最佳实践

你已经了解了 Datadog 平台上的高级监控、APM 和安全功能，现在让我们来看一下这些领域相关的最佳实践：

• 用于生成应用程序跟踪和进行 APM 性能分析的工具必须集成到构建和部署过程中。

• 为每个服务定义完整的应用程序指标，并将这些指标暴露出来，方便 Datadog 使用。

• 计划收集所有应用程序日志，并在需要时定义新的日志，以便轻松观察应用程序状态。

• 确定应用程序用户的地理位置，以便对合成测试进行微调。

• 发布受支持的设备和浏览器列表。根据合成监控报告中提供的信息，微调应用程序以确保与访问设备和浏览器的兼容性。

• 为了有效的安全监控，定义与组织相关的自定义安全规则。禁用可能生成虚假消息的现成规则。

这将引导我们进入总结部分。

总结

在本章中，你了解了 Datadog 平台上一些相对较新的监控功能，这些功能仍在不断发展。除了 APM 外，还讨论了可观察性和合成监控，但相关的工具和概念足够通用，可以应用于更广泛的监控场景。

本章结束时，本书也告一段落，接下来推荐的步骤是将 Datadog 部署到你的环境中，积累相关经验。Datadog 提供了覆盖几乎所有监控类型的功能，如基础设施监控、日志聚合与索引、最后一公里监控、APM 和安全监控，是市场上最全面的监控平台之一。它的一大亮点是，借助平台上的多种监控功能，能够统一监控，并且具备跨产品关联信息的能力。

我们祝愿你在使用 Datadog 部署主动监控时好运，Datadog 是这个目的的一个极佳选择。