一、故障背景与场景还原
很多做物联网相关开发的朋友都有过这样的经历：好不容易搭好设备数据采集的管道，把各种传感器、智能设备的实时数据传到AWS上，结果突然发现数据要么存不进去，要么自己的服务想读数据时被系统拦下来，急得抓耳挠腮。我自己之前就碰到过一个典型的生产场景：某智能工厂的温湿度传感器集群，每天会产生近百万条环境数据，原本用AWS IoT Analytics做数据存储和分析，用来监控车间环境是否符合生产标准，结果某天早上运维告警说“数据写入成功率跌到10%以下”，而且负责拉取历史数据做报表的内部服务，连IoT Analytics的存储桶都访问不了。
这种故障如果处理不及时，会直接影响生产决策——比如车间温度超标没及时发现，可能导致产品质量问题；历史数据拿不到，就没法做趋势分析优化生产流程。接下来我就把这次排查的全过程拆解开，一步步说清楚怎么解决。
二、数据持久化失败的排查与解决
数据持久化失败，简单说就是“设备传过来的数据，没被系统存到硬盘里”，大部分时候不是硬件坏了，是中间某个配置出了问题。我们分两步查。
2.1 先确认数据管道的“每一步有没有通”
AWS IoT Analytics的数据流是个流水线：设备先把数据发到AWS IoT Core，再通过规则（Rule）把数据转发给IoT Analytics的通道（Channel），然后通道里的数据会按规则整理成数据集（Dataset），最后存到对应的存储里。哪一步断了，数据都存不进去。
这里我给大家一个排查工具——AWS CloudWatch的日志查询，所有中间步骤的异常都会记在这里。我当时用的查询命令是这样的（技术栈：AWS CLI）：
# 查询近24小时内IoT Analytics相关的错误日志
aws logs filter-log-events \
--log-group-name /aws/iotanalytics \
--start-time $(date -d '24 hours ago' +%s)000 \
--filter-pattern 'ERROR'
我当时跑这个命令后，输出里有一条特别显眼的错误：Failed to put records to channel: channel=my-factory-env-channel, error=400 Bad Request: Invalid timestamp format。意思是说，发给通道的数据里，时间戳的格式不对，系统认不出来。
为什么会出这个问题？我之前改设备数据格式的时候，把原来的时间戳字段从ISO格式（比如2024-05-20T12:34:56Z）改成了毫秒级的数字（比如1716189296000），但IoT Analytics通道的配置里，我没改时间戳的格式规则，系统还是按ISO格式解析，结果就出错了。
解决这个问题的方法是更新通道的时间戳配置，具体操作是登录AWS IoT Analytics控制台，找到对应的通道，编辑它的“Timestamp configuration”，把原来的ISO 8601改成Milliseconds since epoch，然后重新测试数据写入。改完之后再查日志，错误就消失了，写入成功率很快回到了99%以上。
2.2 再确认存储资源有没有配额限制
除了格式问题，还有一种常见的持久化失败原因是“资源不够用”——比如你给IoT Analytics分配的存储配额用完了，系统就会拒绝写入新数据。
怎么查配额？还是用AWS CLI，命令如下（技术栈：AWS CLI）：
# 查询当前账号下IoT Analytics的存储使用情况
aws iotanalytics describe-datastore \
--datastore-name my-factory-env-datastore
我当时输出的结果里，有个StorageCapacity字段，显示我之前设置的配额是100GB，而UsedStorage已经到了99.8GB，几乎满了。这时候系统就会限制写入。
解决方法有两个：一是临时扩容配额，二是清理旧数据。如果是生产环境，建议先扩容再清理旧数据，避免中断业务。扩容的操作是在IoT Analytics控制台找到对应的存储（Datastore），编辑它的存储配额，改成更大的数值（比如500GB），或者直接开启自动扩容。清理旧数据可以用IoT Analytics的生命周期规则（Lifecycle policy），设置超过90天的数据自动删除，这样就能长期保证存储够用。
三、存储访问权限问题的排查与解决
数据能存进去了，接下来可能碰到的问题是“自己的服务读不到数据”，这就是访问权限的问题。权限问题的核心是“谁能访问，能访问什么”，我们分两类情况排查。
3.1 内部服务访问IoT Analytics的权限问题
我当时碰到的情况是：一个用Node.js写的报表服务，部署在EC2上，想拉取IoT Analytics里的历史数据生成日报，结果报错AccessDenied。
首先要明确：EC2实例要访问AWS的服务，需要通过IAM角色（IAM Role）来授权，不能直接写密钥。我当时先检查了EC2实例关联的IAM角色，发现这个角色的权限策略里，只给了iotanalytics:GetDatasetContent的权限，但IoT Analytics的数据集内容是存在S3存储桶里的，拉取数据还需要访问S3的权限。
这时候我需要给这个IAM角色添加S3的访问权限，具体的策略配置如下（技术栈：AWS IAM）：
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::aws-iotanalytics-datastore-*", // 所有IoT Analytics的S3存储桶
"arn:aws:s3:::aws-iotanalytics-datastore-*/*" // 存储桶里的所有对象
]
}
]
}
把这个策略附加到EC2的IAM角色上之后，报表服务就能正常拉取数据了。这里要注意一个细节：不要给过于宽泛的权限，比如不要写"Action": "s3:*"，只给需要的权限，避免安全风险。
3.2 外部设备访问IoT Analytics的权限问题
还有一种常见的权限问题是“外部设备能不能访问IoT Analytics”，比如你想让现场的电脑直接拉取数据做临时分析。这时候需要给外部用户创建IAM用户（IAM User），然后给这个用户分配对应的权限。
我当时给现场的运维人员创建了一个IAM用户，然后给他附加了一个只允许读取特定数据集的策略，配置如下（技术栈：AWS IAM）：
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iotanalytics:GetDatasetContent",
"Resource": "arn:aws:iotanalytics:us-east-1:123456789012:dataset/my-factory-env-dataset" // 只允许访问这个数据集
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::aws-iotanalytics-datastore-123456789012", // 只允许访问这个S3桶
"arn:aws:s3:::aws-iotanalytics-datastore-123456789012/*"
]
}
]
}
创建好IAM用户之后，把访问密钥（Access Key）和密钥（Secret Key）发给运维人员，他们就可以用这些凭证访问指定的数据集了。这里要注意：IAM用户的密钥一定要妥善保管，不要泄露，建议定期更换。
四、应用场景、优缺点与注意事项
4.1 应用场景
这次故障涉及的场景是智能工厂的环境数据监控，除此之外，AWS IoT Analytics还适用于很多其他物联网场景：比如智能家居的设备数据统计、智能物流的位置数据追踪、智能农业的土壤湿度监测、智能医疗的设备运行数据监控等等。只要是需要收集、存储、分析大量设备数据的场景，都可以用AWS IoT Analytics。
4.2 技术优缺点
优点
- 全托管服务：不需要自己搭建服务器、维护数据库，AWS会帮你搞定底层的基础设施，你只需要关注数据本身。
- 高可扩展性：可以轻松处理从每天几条到每天几百万条的设备数据，不会因为数据量变大而崩溃。
- 集成性好：可以和AWS的其他服务无缝对接，比如CloudWatch监控、S3存储、Lambda函数、Glue数据分析等等，不需要自己做复杂的集成开发。
缺点
- 配置复杂：很多新手刚接触的时候，会被各种概念（通道、数据集、存储、规则）搞晕，配置的时候很容易出错。
- 成本不透明：如果没有合理设置配额和生命周期规则，数据量变大之后，费用会涨得很快，很多用户一开始没注意，月底看到账单吓一跳。
- 灵活性有限：如果需要做非常复杂的自定义数据分析，AWS IoT Analytics的内置功能可能不够用，需要结合其他服务。
4.3 注意事项
- 提前规划时间戳格式：在设计设备数据格式的时候，就要确定好时间戳的格式，尽量和IoT Analytics支持的格式保持一致，避免后期修改带来的麻烦。
- 合理设置配额和生命周期规则：根据自己的数据量，提前设置好存储配额，并且给超过一定时间的数据设置自动删除规则，既可以节省成本，又可以避免存储满了导致写入失败。
- 遵循最小权限原则：给不同的用户和服务分配权限的时候，只给他们需要的权限，不要给过于宽泛的权限，避免安全风险。
- 做好监控告警：给IoT Analytics的写入成功率、存储使用率、权限访问情况设置CloudWatch告警，一旦出现异常，能第一时间收到通知，及时处理。
五、文章总结
这次排查故障的过程，让我对AWS IoT Analytics的整个数据流和权限体系有了更深入的理解。数据持久化失败的核心原因，要么是数据本身有问题（比如格式不对），要么是资源不够用（比如存储满了）；访问权限问题的核心原因，要么是IAM角色或用户的权限配置不对，要么是权限覆盖的范围不够（比如只给了IoT Analytics的权限，没给S3的权限）。
解决这类故障的思路其实很简单：先一步步排查数据的流转过程，看哪一步出了问题；再检查权限配置，看有没有覆盖到需要访问的资源。只要掌握了这个思路，大部分类似的故障都能快速解决。
最后提醒大家，在使用AWS IoT Analytics的时候，一定要提前做好规划，配置好监控和告警，这样就能避免很多不必要的故障，让你的物联网数据系统运行得更稳定。
评论
围绕“AWS IoT Analytics数据存储故障排查：解决数据持久化失败与存储访问权限问题”参与讨论