注释
时序见解服务将于 2024 年 7 月 7 日停用。 请考虑尽快将现有环境迁移到备用解决方案。 有关弃用和迁移的详细信息,请访问我们的 文档。
谨慎
这是一篇 Gen1 文章。
本文描述你可能会在 Azure 时序见解环境中遇到的问题。 本文将提供问题的潜在原因和解决方法。
视频
了解 Azure 时序洞察中的常见挑战和缓解措施
问题:不显示数据
如果 Azure Time Series Insights 资源管理器中未显示数据,请考虑以下常见原因。
原因 A:事件源数据不是 JSON 格式
Azure 时序见解仅支持 JSON 数据。 有关 JSON 示例,请参阅 支持的 JSON 形状。
原因 B:事件源密钥缺少所需的权限
对于 Azure IoT 中心内的某个 IoT 中心,需要提供具有“服务连接”权限的密钥。 选择 iothubowner 策略或 服务 策略。 两者都具有“服务连接”权限。
对于 Azure 事件中心内的某个事件中心,需要提供具有“侦听”权限的密钥。 读取和管理策略都将正常工作,因为它们都具有侦听权限。
原因 C:提供的使用者组并非 Azure 时序见解所独有
注册 IoT 中心或事件中心时,必须设置用于读取数据的使用者组。 不能共享此使用者组。 如果共享此使用者组,底层 IoT 中心或事件中心会随机自动断开某个读取者的连接。 请提供唯一的使用者组,供 Azure 时序见解从中读取。
原因 D:环境刚刚配置完成
在环境及其数据首次创建后的几分钟内,数据会显示在 Azure 时序见解资源管理器中。
问题:显示了一些数据,但缺失一些数据
如果仅显示了一部分数据,并且数据似乎滞后,请考虑以下可能的问题。
原因 A:环境受限制
在创建具有数据的事件源后预配环境时,限制是一个常见问题。 Azure IoT 中心和 Azure 事件中心将数据存储最长 7 天。 Azure 时序见解总是从事件源中最早的事件开始处理(即先进先出,FIFO)。
例如,如果某个事件源中有 500 万个事件,当你连接到 S1(单一单位 Azure 时序见解环境)时,Azure 时序见解每天会读取大约 100 万个事件。 Azure 时序洞察似乎遇到了 5 天的延迟。 但是,目前情况是环境被压制了。
如果事件源中有旧事件,可以通过以下两种方式之一来处理限制:
- 更改事件源的保留限制,以帮助删除不想要显示在 Azure 时序见解中的旧事件。
- 配置一个更大规模的环境,以增加旧事件的处理吞吐量。 在上面的示例中,如果在某一天将同一 S1 环境增大到 5 个单位,则环境在一天内就能赶上进度。 如果每天在稳定状态下生成 100 万个或更少的事件,在 Azure 时序见解赶上进度后,您可以将事件容量减少为一个单位。
强制的限制阈值基于环境的 SKU 类型和容量。 环境中的所有事件源都共享此容量。 如果您的 IoT 中心或事件中心的事件源推动的数据超过了规定的限制,您将会遇到限速和滞后的现象。
下图显示了一个 SKU 为 S1 且容量为 3 的 Azure 时序见解环境。 它每天可以引入 300 万个事件。
假设某个环境从事件中心引入消息。 每日流入速率大约为 67,000 条消息。 此速率相当于每分钟大约引入 46 条消息。
- 如果将每条事件中心消息压平为单个 Azure 时序见解事件,则不会发生节流。
- 如果将每条事件中心消息平展为 100 个 Azure 时序见解事件,则每分钟应引入 4,600 个事件。
容量为 3 的 S1 SKU 环境每分钟只能流入 2,100 个事件(每天 100 万个事件 = 每分钟 700 个事件,3 个单位 = 每分钟 2,100 个事件)。
若要大致了解平展逻辑的工作原理,请参阅 支持的 JSON 形状。
关于过度限流的建议解决方案
若要解决延迟问题,请增加环境的 SKU 容量。 有关详细信息,请阅读“缩放 Azure 时序见解配置”。
原因 B:历史数据的初始引入减慢了流入速度
如果连接现有事件源,则 IoT 中心或事件中心可能已包含数据。 环境将开始从事件源消息保留期的起始时间点拉取数据。 这是默认的处理方式,不能将其覆盖。 您可以启动限流。 节流可能需要一些时间才能与历史数据的处理同步。
针对大型初始引入的建议解决方法
解决滞后问题:
将 SKU 容量增大到允许的最大值(本例中为 10)。 增大容量后,数据流入进程就能更迅速地跟上。 增加容量需要付费。 若要观察赶上进度的速度,可以查看 Azure 时序见解资源管理器中的可用性图表。
消除滞后问题之后,将 SKU 容量降低至正常流入速率。
问题:数据之前显示,但如今不再显示
如果 Azure 时序见解不再摄入数据,但事件仍在流式传输到 IoT 中心或事件中心,请考虑以下可能的原因。
原因 A:重新生成了中心访问密钥,环境需要更新
如果创建事件源时提供的密钥不再有效,则会出现此问题。 你会在你的中心看到遥测数据,但不会在 Azure 时序见解中收到 Ingress 接收的消息。 如果不确定是否重新生成了密钥,可以在事件中心的活动日志中搜索“创建或更新命名空间授权规则”。对于 IoT 中心,请搜索“创建或更新 IoT 中心资源”。
若要用新密钥更新 Azure 时序见解环境,请在 Azure 门户中打开中心资源并复制新密钥。 转到你的 Azure 时序见解资源并选择“事件源”:
选择已停止从其引入的一个或多个事件源,粘贴新密钥,然后选择“保存”:
问题:事件源的时间戳属性名称设置不起作用
确保来自您的事件源的 JSON 字符串中的时间戳属性值格式为 yyyy-MM-ddTHH:mm:ss.FFFFFFFK。 下面是一个示例: 2008-04-12T12:53Z。
请注意,时间戳属性名称区分大小写。
使用 Azure 时序见解资源管理器是确保捕获时间戳属性名称并让其正常运行的最简单方法。 在 Azure 时序见解资源管理器中使用图表,并在输入时间戳属性名称之后选择一个时间段。 右键单击选定项,然后选择“浏览事件”。
第一个列标头应是时间戳属性名称。 在时间戳旁边会显示($ts)。
不会显示以下值:
- (abc):指示 Azure 时序见解正在以字符串的形式读取数据值。
- 日历图标:指示 Azure 时序见解正在读取日期时间值形式的数据值。
- #:指示 Azure 时序洞察正在读取整数形式的数据值。