通过

使用指标监视排队引入

  • 项目

在排队引入过程中，Azure 数据资源管理器会根据可配置的引入批处理策略对传入的小数据块进行批处理，以此优化数据引入来实现较高的吞吐量。 批处理策略允许设置密封某个批的触发条件（数据大小、Blob 数量或已经过的时间）。 然后以最佳方式引入这些批，以快速获得查询结果。

本文将介绍如何在 Microsoft Azure 门户中使用指标来监视向 Azure 数据资源管理器进行的排队引入。

批处理阶段

本部分所述的阶段适用于所有批处理引入。 对于 Azure 事件网格、Azure 事件中心、Azure IoT 中心和 Cosmos DB 引入，在数据排队等待引入之前，数据连接会从外部源获取数据并重新排列初始数据。

排队引入分阶段进行：

  1. 批处理管理器侦听引入消息的队列并处理请求。
  2. 批处理管理器通过获取它接收到的小型流入数据块并基于引入批处理策略对这些 URL 进行批处理，以此优化引入吞吐量。
  3. 引入管理器将引入命令发送到 Azure 数据资源管理器存储引擎 。
  4. Azure 数据资源管理器存储引擎存储引入的数据，使其可供查询。

Azure 数据资源管理器提供一组 Azure Monitor 引入指标，使你可以在排队引入过程的各个阶段和组件中监视数据引入。

Azure 数据资源管理器引入指标提供以下方面的详细信息：

  • 排队引入的结果。
  • 引入的数据量。
  • 排队引入的延迟，以及发生延迟的位置。
  • 批处理过程本身。
  • 对于事件中心、事件网格和 IoT 中心引入：收到的事件数。

本文将介绍如何使用 Microsoft Azure 门户中的引入指标来监视向 Azure 数据资源管理器进行的排队引入。

先决条件

使用 Azure Monitor 指标资源管理器创建指标图表

下面是有关如何使用 Azure Monitor 指标的一般说明，在后续部分我们将实现这些指标。 执行以下步骤，使用 Azure 门户中的 Azure Monitor 指标资源管理器创建指标图表：

  1. 登录到 Azure 门户并导航到 Azure 数据资源管理器群集的概述页。

  2. 在左侧导航栏中选择“指标”打开指标窗格。

  3. 打开指标窗格右上方的“时间选取器”面板，将“时间范围”更改为要分析的时间 。 在本文中，我们将分析过去 48 小时内向 Azure 数据资源管理器进行的数据引入。

  4. 选择一个范围和指标命名空间 ：

    • “范围”是指你的 Azure 数据资源管理器群集的名称。 在以下示例中，我们将使用名为 demo11 的群集。
    • “指标命名空间”应设置为“Kusto 群集标准指标”。 这是包含 Azure 数据资源管理器指标的命名空间。

    显示如何在 Azure 门户中选择指标设置的屏幕截图。

  5. 选择指标名称和相关的“聚合”值 。

对于本文中的某些示例，我们将为具有维度的指标选择“添加筛选器”和“应用拆分” 。 我们还将使用“添加指标”在同一图表中绘制其他指标，并使用“+ 新建图表”在一个视图中查看多个图表 。

每次添加新指标都要重复步骤 4 和 5。

注意

若要详细了解如何使用指标来监视 Azure 数据资源管理器以及如何使用指标窗格，请参阅使用指标监视 Azure 数据资源管理器性能、运行状况和使用情况。

本文将介绍可以使用哪些指标来跟踪排队引入，以及如何使用这些指标。

查看引入结果

“引入结果”指标提供有关已成功引入的源和无法引入的源总数的信息。

在此示例中，我们将使用此指标查看引入尝试结果，并使用状态信息来帮助排查任何失败尝试的原因。

  1. 在 Azure Monitor 的“指标”窗格中，选择“添加指标” 。
  2. 选择“引入结果”作为“指标”值，选择“总和”作为“聚合”值。 做出这种选择后，将在一个图表行中显示一段时间内的引入结果。
  3. 选择图表上方的“应用拆分”按钮，然后选择“状态”以按引入结果的状态将图表细分。 选择拆分值后，在拆分选择器外部单击以将其关闭。

指标信息现在已按状态拆分，我们可以看到已拆分为三行的引入结果的状态信息：

  1. 蓝色表示成功的引入操作。
  2. 橙色表示由于“找不到实体”而失败的引入操作。
  3. 紫色表示由于“错误的请求”而失败的引入操作。

Azure 门户中“指标”窗格的屏幕截图，其中显示了按总和聚合并按状态拆分的引入结果的图表。

查看引入结果的图表时，请注意以下事项：

  • 使用事件中心或 IoT 中心引入时，数据连接组件中有一个事件预聚合。 在此引入阶段，会将事件视为要引入的单个源。 因此，在预先聚合后，某些事件将显示为单个的引入结果。
  • 在内部重试暂时性故障的次数有限。 每个暂时性故障都报告为暂时性的引入结果。 正因如此，单个引入可能会导致多个引入结果。
  • 图表中的引入错误按错误代码的类别列出。 若要按类别查看引入错误代码的完整列表并想要更好地了解可能的错误原因，请参阅 Azure 数据资源管理器中的引入错误代码。
  • 若要获取有关引入错误的更多详细信息，可以设置失败引入诊断日志。 但必须考虑到，生成日志会导致创建额外的资源，从而增大 COGS（所售货物成本）。

查看引入的数据量

“已处理的 Blob 数”、“已接收的 Blob 数”和“已删除的 Blob 数”指标提供有关引入组件在排队引入阶段已处理、已接收和已删除的 Blob 的数量的信息。

在此示例中，我们将使用这些指标来查看有多少数据通过了引入管道，引入组件接收了多少数据，以及有多少数据已删除。

已处理的 blob 数

  1. 在 Azure Monitor 的“指标”窗格中，选择“添加指标” 。
  2. 选择“已处理的 Blob 数”作为“指标”值，选择“总和”作为“聚合”值。
  3. 选择“应用拆分”按钮，然后选择“组件类型”以按不同的引入组件将图表细分。
  4. 若要专注于群集中的特定数据库，请选择图表上方的“添加筛选器”按钮，然后选择绘制图表时要包含的数据库值。 在此示例中，我们通过选择“数据库”作为“属性”，选择“=”作为“运算符”，并在“值”下拉列表中选择“GitHub”，来针对发送到 GitHub 数据库的 Blob 进行筛选。 选择筛选值后，在筛选选择器外部单击以将其关闭。

现在，图表将显示一段时间内在每个引入组件中处理的、已发送到 GitHub 数据库的 Blob 数。

Azure 门户中“指标”窗格的屏幕截图，其中显示了 GitHub 数据库中已处理的 Blob 数（已按总和聚合并已按组件类型拆分）的图表。

  • 可以看到，在 2 月 13 日当天的一段时间内，引入到 GitHub 数据库的 Blob 数量有所下降。 另外可以看到，在每个组件中处理的 Blob 数相似，这意味着，在“数据连接”组件中处理的所有数据，几乎也都在“批处理管理器”、“引入管理器”和“Azure 数据资源管理器存储引擎”组件中成功处理 。 此数据现在可供查询。

接收的 blob 数

为了更好地了解每个组件接收的 Blob 数与每个组件成功处理的 Blob 数之间的关系，让我们添加一个新图表：

  1. 选择“+ 新图表”。
  2. 为“范围”、“指标命名空间”和“聚合”选择与前面相同的值，然后选择“已接收的 Blob 数”指标 。
  3. 选择“应用拆分”按钮，然后选择“组件类型”以按组件类型拆分“已接收的 Blob 数”指标 。
  4. 选择“添加筛选器”按钮并设置与前面相同的值，以便仅筛选发送到 GitHub 数据库的 Blob。

Azure 门户中“指标”窗格的屏幕截图，其中显示了 GitHub 数据库中已处理的 Blob 数（已按总和聚合且已按组件类型拆分）的图表，以及 GitHub 数据库中已接收的 Blob 数（已按总和聚合且已按组件类型拆分）的图表。

  • 比较这些图表，可以看到，每个组件接收的 Blob 数与每个组件处理的 Blob 数非常接近。 这种比较结果表明，在引入过程中未删除任何 Blob。

已删除的 Blob 数

若要确定在引入期间是否删除了 Blob，应分析“已删除的 Blob 数”指标。 此指标显示在引入期间删除了多少个 Blob，可帮助你检测在特定的引入组件上进行处理时是否出现了问题。 对于删除的每个 Blob，你还会获得一个“引入结果”指标，其中提供了有关失败原因的详细信息。

查看引入延迟

“阶段延迟”和“发现延迟”指标监视引入过程中的延迟，并告知你在 Azure 数据资源管理器中或者在数据抵达 Azure 数据资源管理器以供引入之前是否发生了长时间的延迟 。

  • “阶段延迟”是指从 Azure 数据资源管理器发现消息到引入组件收到其要处理的内容的时间跨度。
  • “发现延迟”用于具有数据连接的引入管道（例如事件中心、IoT 中心和事件网格）。 此指标提供有关从数据排队到 Azure 数据资源管理器数据连接执行发现的时间跨度的信息。 此时间跨度处于 Azure 数据资源管理器的上游，因此它不包含在仅度量 Azure 数据资源管理器中的延迟的“阶段延迟”指标中。

注意

根据默认批处理策略，默认批处理时间为五分钟。 因此，如果批未由其他触发器密封，则该批将在五分钟后密封。

如果在数据可供查询之前发生了长时间的延迟，分析“阶段延迟”和“发现延迟”可帮助了解这种长时间延迟是起因于 Azure 数据资源管理器中的长时间延迟，还是发生在 Azure 数据资源管理器的上游 。 当延迟发生于 Azure 数据资源管理器本身时，你还可以检测导致长时间延迟的特定组件。

阶段延迟（预览版）

首先让我们看看排队引入的阶段延迟。 有关每个阶段的说明，请参阅批处理阶段。

  1. 在 Azure Monitor 的“指标”窗格中，选择“添加指标” 。
  2. 选择“阶段延迟”作为“指标”值，选择“平均值”作为“聚合”值。
  3. 选择“应用拆分”按钮，然后选择“组件类型”以按不同的引入组件将图表细分。
  4. 选择“添加筛选器”按钮，并针对发送到 GitHub 数据库的数据进行筛选。 选择筛选值后，在筛选选择器外部单击以将其关闭。 现在，图表将显示一段时间内，在每个组件中通过引入发送到 GitHub 数据库的引入操作的延迟：

Azure 门户中“指标”窗格的屏幕截图，其中显示了 GitHub 数据库中引入操作的阶段延迟（已按平均值聚合并按组件类型拆分）的图表。

在此图表中可以获得以下信息：

  • “事件中心数据连接”组件的延迟大约为 0 秒。 这是合理的，因为“阶段延迟”只度量从 Azure 数据资源管理器发现消息开始算起的延迟。
  • 引入过程中花费的最长时间（大约 5 分钟）从“批处理管理器”组件收到数据开始，到“引入管理器”组件收到数据为止 。 在此示例中，我们对 GitHub 数据库使用了默认批处理策略。 如前所述，默认批处理策略的延迟时间限制为 5 分钟，因此这很有可能表明，几乎所有的数据都已及时进行了批处理，排队引入的大部分延迟时间都是由批处理本身造成的。
  • 图表中的存储引擎延迟表示数据存储到 Azure 数据资源管理器存储引擎并可供查询之前的延迟。 可以看到，从 Azure 数据资源管理器发现数据开始到数据可供查询为止的平均总延迟为 5.2 分钟。

发现延迟

如果使用包含数据连接的引入，你可能想要估算 Azure 数据资源管理器上游在一段时间内的延迟，因为长时间的延迟也可能发生在 Azure 数据资源管理器获取要引入的数据之前。 为此，可以使用“发现延迟”指标。

  1. 选择“+ 新图表”。
  2. 选择“发现延迟”作为“指标”值，选择“平均值”作为“聚合”值。
  3. 选择“应用拆分”按钮，然后选择“组件类型”以按不同的数据连接组件类型将图表细分。 选择拆分值后，在拆分选择器外部单击以将其关闭。

Azure 门户中“指标”窗格的屏幕截图，其中显示了 GitHub 数据库中引入操作的发现延迟（已按平均值聚合并按组件类型拆分）的图表。

  • 可以看到，在大部分持续时间内，发现延迟接近 0 秒，这表明 Azure 数据资源管理器在数据排队后就立即获取了数据。 300 毫秒左右的峰值大约出现在 2 月 13 日 14:00，表明此时 Azure 数据资源管理器群集在数据排队后的大约 300 毫秒收到了数据。

了解批处理过程

在排队引入流的第二阶段，批处理管理器组件会根据引入批处理策略对它接收的数据进行批处理，以优化引入吞吐量。

下面的一组指标可帮助你了解引入过程中如何对数据进行批处理：

  • 已处理的批数：已为引入而完成的批数。
  • 批大小：要引入的聚合批中未压缩数据的估计大小。
  • 批持续时间：每个批从其打开的那一刻起，到批密封为止的持续时间。
  • 批 Blob 计数：已为引入而完成的批中的 Blob 数。

已处理批处理

首先，让我们通过查看“已处理的批数”指标来获取批处理过程的整体视图。

  1. 在 Azure Monitor 的“指标”窗格中，选择“添加指标” 。
  2. 选择“已处理的批数”作为“指标”值，选择“总和”作为“聚合”值。
  3. 选择“应用拆分”按钮，然后选择“批处理类型”以根据密封批的原因将图表细分。 有关批处理类型的完整列表，请参阅批处理类型。
  4. 选择“添加筛选器”按钮，并针对发送到 GitHub 数据库的批进行筛选。 选择筛选值后，在筛选选择器外部单击以将其关闭。

图表将显示一段时间内发送到 GitHub 数据库的、包含数据的密封批数（已按“批处理类型”拆分） 。

Azure 门户中“指标”窗格的屏幕截图，其中显示了 GitHub 数据库中已为引入而处理的批数（已按总和聚合并按批处理类型拆分）的图表。

  • 可以看到，在一段时间内的每个时间单位处理了 2-4 批，所有批已按照阶段延迟 部分中估算的时间进行密封，从中可以看出，根据默认批处理策略对数据进行批处理大约花费了 5 分钟。

批持续时间、大小和 Blob 计数

现在让我们进一步特征化已处理的批。

  1. 选择每个图表对应的“+ 添加图表”按钮，以便为“指标”值“批持续时间”、“批大小”和“批 Blob 计数”创建更多的图表 。
  2. 使用“平均值”作为“聚合”值。
  3. 与前面的示例中一样，选择“添加筛选器”按钮，并针对发送到 GitHub 数据库的数据进行筛选。

Azure 门户中“指标”窗格的屏幕截图，其中显示了 GitHub 数据库中引入操作的“批 Blob 计数”、“批持续时间”和“批大小”指标（已按平均值聚合并按批处理类型拆分）的图表。

从“批持续时间”、“批大小”和“批 Blob 计数”图表中，我们可以得出一些见解 ：

  • 平均批持续时间为五分钟（根据默认批处理策略）。 查看总引入延迟时应该考虑到这一点。

  • 在“批大小”图表中，可以看到一段时间内批的平均大小约为 200-500 MB。 要引入的数据的最佳大小为 1 GB 未压缩数据，默认批处理策略也将此大小定义为密封条件。 由于在一段时间内要批处理的数据没有 1 GB，因此我们看不到任何按大小密封的批。

  • 在一段时间内，批中的平均 Blob 数约为 160 个 Blob，然后减少至 60-120 个 Blob。 根据默认批处理策略，当 Blob 计数为 1000 个 Blob 时，一个批便可以密封了。 由于我们尚未达到这个数字，因此看不到按计数密封的批。

将已接收的事件数与发送以供引入的事件数进行比较

应用事件中心、IoT 中心或事件网格引入时，将 Azure 数据资源管理器接收的事件数与从事件源发送到 Azure 数据资源管理器的事件数进行比较可能很有帮助。 可以通过“已接收的事件数”、“已处理的事件数”和“已删除的事件数”指标进行这种比较 。

接收的事件数

  1. 在 Azure Monitor 的“指标”窗格中，选择“添加指标” 。
  2. 选择“已接收的事件数”作为“指标”值，选择“总和”作为“聚合”值。
  3. 选择图表上方的“添加筛选器”按钮，然后选择“属性”值“组件名称”以筛选群集上定义的特定数据连接收到的事件 。 在此示例中，我们针对 GitHubStreamingEvents 数据连接进行筛选。 选择筛选值后，在筛选选择器外部单击以将其关闭。

现在，图表将显示所选数据连接在一段时间内接收的事件数：

Azure 门户中“指标”窗格的屏幕截图，其中显示了一段时间内 GitHub 数据库中执行引入期间接收的事件（已聚合）的图表。

  • 在此图表中，GitHubStreamingEvents 数据连接在一段时间内的每个时间单位接收了大约 200-500 个事件。

已处理的事件数和已删除的事件数

若要查看 Azure 数据资源管理器是否删除了任何事件，请使用“已处理的事件数”和“已删除的事件数”指标 。

  1. 在已创建的图表中，选择“添加指标”。
  2. 选择“已处理的事件数”作为“指标”值，选择“总和”作为“聚合”值。
  3. 再次选择“添加指标”，然后选择“已删除的事件数”作为“指标”值，选择“总和”作为“聚合”值。

现在，图表将显示 GitHubStreamingEvents 数据连接在一段时间内已接收、已处理和已删除的事件数。

Azure 门户中“指标”窗格的屏幕截图，其中显示了一段时间内 GitHub 数据库中执行引入期间已接收、已处理和已删除的事件（已聚合）的图表。

  • 该数据连接成功处理了几乎所有的已接收事件。 删除了一个事件，该事件与我们在查看引入结果指标时看到的由于请求错误而失败的引入结果兼容。

将 Azure 数据资源管理器中接收的事件与事件中心的传出消息数进行比较

你可能还想通过比较“收到的事件数”和“传出消息数”指标，将收到的事件数与从事件中心发送到 Azure 数据资源管理器的事件数进行比较。

  1. 在已经为“已接收的事件数”创建的图表中，选择“添加指标” 。

  2. 选择“范围”，然后在“选择范围”对话框中，浏览并选择将数据发送到数据连接的事件中心的命名空间。

    屏幕截图显示了 Azure 门户中的“选择范围”对话框，其中显示了如何在事件中心命名空间列表中搜索 github4demo。

  3. 选择“应用”

  4. 选择“传出消息数”作为“指标”值，选择“总和”作为“聚合”值。

单击设置以外的位置以获取完整图表，该图表将 Azure 数据资源管理器数据连接处理的事件数与从事件中心发送的事件数进行比较。

Azure 门户中“指标”窗格的屏幕截图，其中显示了一段时间内在 GitHub 数据库中执行引入期间已接收、已处理和已删除的所有事件（已聚合）的图表。

  • 请注意，Azure 数据资源管理器数据连接已成功处理从事件中心发送的所有事件。
  • 如果在事件中心命名空间中有多个事件中心，则应按“实体名称”维度筛选“传出消息数”指标，以仅从事件中心命名空间中所需的事件中心获取数据。

注意

无法按使用者组监视传出消息。 “传出消息数”指标统计所有使用者组使用的消息总数。 因此，如果事件中心内有几个使用者组，则“传出消息数”的数量可能比“收到的事件数”多。

相关内容