监控并缓解流量限制,以减少 Azure 时序见解 Gen1 中的延迟

注释

时序见解服务将于 2024 年 7 月 7 日停用。 请考虑尽快将现有环境迁移到备用解决方案。 关于废弃和迁移的详细信息,请访问我们的 文档

谨慎

这是一篇 Gen1 文章。

当传入数据量超过您的环境配置时,Azure 时序见解中可能会出现延迟或限流。

可以根据要分析的数据量,适当地配置环境,从而避免延迟和限制。

以下情况下,您最有可能遇到延迟和限流:

  • 添加一个事件源,其中包含可能会超出您分配的入口速率的旧数据(Azure 时序见解需要进行追赶)。
  • 将较多事件源添加到一个环境中,导致其他事件出现激增(可能超过环境容量)。
  • 将大量历史事件推送到一个事件源,导致延迟(Azure 时序洞察需要同步)。
  • 将引用数据和遥测结合,导致事件大小较大。 允许的最大数据包大小为 32 KB;大于 32 KB 的数据包会被截断。

视频

了解 Azure 时序见解数据入口行为以及如何对其进行规划。

使用警报监视延迟和限流

警报有助于诊断并缓解环境中出现的延迟问题。

  1. 在 Azure 门户中,选择 Azure 时序见解环境。 然后选择“警报” 。

    向 Azure 时序见解环境添加警报

  2. 选择“+ 新建警报规则”。 然后将显示“创建规则” 面板。 在“条件” 下选择“添加” 。

    添加警报窗格

  3. 接下来,配置信号逻辑的确切条件。

    配置信号逻辑

    在此处,可以使用以下一些条件配置警报:

    度量 说明
    入口收到的字节数 从事件源读取的原始字节数。 原始计数通常包括属性名称和值。
    入口接收到无效消息 从所有 Azure 事件中心或 Azure IoT 中心事件源读取的无效消息的计数。
    入口收到的消息 从所有事件中心或 IoT 中心的事件源读取的消息数量。
    入口存储的字节数 已存储且可用于查询的事件的总大小。 仅根据属性值计算大小。
    入口存储事件       已存储并可供查询的扁平化事件计数。    
    入口收到消息时间延迟      消息在事件源中排队的时间与消息在入口中处理之间的时间差(以秒为单位)。    
    入口接收消息计数滞后      上次排队的消息在事件源分区中的序列号与在入口中进行处理的消息的序列号之间的差异。    

    选择“完成” 。

  4. 配置所需的信号逻辑后,直观地查看所选的警报规则。

    延迟视图和图表

节流和流量入口管理

  • 如果你受到速率限制,将记录一个“入口收到消息时间延迟”值,以通知你 Azure 时序见解环境的时间比消息实际到达事件源的时间晚多少秒(不包括大约为 30 到 60 秒的索引时间)。

    入口接收消息数量滞后也应该有一个值,以便于确定你落后了多少条消息。 若要赶上来,最容易的方式是增加环境的容量,使之达到能够克服此差异的规模。

    例如,如果 S1 环境显示有 5,000,000 条消息的延迟,那么你可以将环境的大小增加到 6 个单元,以便在大约一天的时间内赶上进度。 甚至可以增加更多,这样追赶速度会更快。 在一开始预配某个环境时,尤其是在将其连接到某个事件源,而该事件源中已经有事件时,或者在批量上传大量历史数据时,追赶期是常见的现象。

  • 另一种方法是将“入口已存储事件”警报设置为在 2 小时内达到略低于总环境容量的阈值。 此警报有助于了解是否持续达到容量要求,指示很可能存在延迟。

    例如,如果预配了三个 S1 单位(或每分钟入口容量为 2100 个事件),则可以将“入口存储的事件数”警报设置为在 2 小时内 = 1900 个事件。 如果因不断超过该阈值而触发警报,很可能是由于预配不足。

  • 如果怀疑自己被限流,可以将“入口收到的消息数”和事件源发送的消息数相比较。 如果传入到您的事件中心的消息数大于“入口接收的消息数”,则 Azure 时序见解很可能受到了限制。

改善性能

为了减少限制或降低延迟,提高环境容量是最佳的解决方法。

可以根据要分析的数据量,适当地配置环境,从而避免延迟和限制。 有关如何为环境添加容量的更多信息,请阅读缩放环境

后续步骤