使用 AWS IoT Core Rule Action 将遥测数据直接写入 InfluxDB
内容提要
AWS IoT Core 新增 InfluxDB 规则操作，可将设备 JSON 遥测数据直接转换为 line protocol 写入 InfluxDB，无需 Lambda。文章演示用 AWS CLI 和 curl 配置实例、token、IAM 角色、destination 与规则，并介绍用 @{…} 模板按数组元素写入不同 measurement、批处理配置及成本对比。采用 Basic Ingest 可显著降低消息与写入成本。
延伸解读
模板语法差异决定数据拆分方式
文章强调 ${…} 与 @{…} 的求值对象不同：前者针对整条消息求值一次，后者针对数组中的每个元素求值一次，且只能用于 tableName 和 tag 值。这意味着若设备把多个指标放在同一数组上报，用 @{metric} 就能自动拆成多个 measurement，而无需在 SQL 中展开。但被 @{…} 引用的字段不会再进入 field set，因此示例中每个 measurement 只剩 value 一个字段，设计 schema 时需留意这一副作用。
Basic Ingest 是成本下降的关键
成本对比显示，同样 1 亿请求，传统 Topic 经规则到 Lambda 写入约 153.3 美元，改用 InfluxDB action 后约 130 美元，主要省去 Lambda 费用；若再走 Basic Ingest，则免去 messaging 计费，合计约 30 美元。文章还指出服务端批处理 100 条/批可把 actions 费用压到约 0.3 美元，总成本约 15.3 美元。可见成本优化主要来自绕过 broker 和减少 action 调用次数，而非单纯替换写入组件。
部署前需关注的连接与权限限制
该规则操作通过公网端点连接 InfluxDB，不提供 VPC 内部连接路径，实例必须启用公网可访问性，且仅支持 443、8443、8086、8181 端口，不支持明文 HTTP。IAM 角色只需读取 Secrets Manager 中的 token，而 token 本身需具备写 bucket 和读用户权限，因为 IoT Core 校验端点时会调用 /api/v2/me。destination 验证失败时，文章建议检查安全组、端点和 token，并可手动将状态改回 IN_PROGRESS 重新触发。
消息语义与格式约束影响可靠性设计
文章提醒，Basic Ingest topic 不能被订阅，QoS 1 的 PUBACK 只表示消息到达规则引擎，并不代表 action 成功；payload 仅支持 JSON，二进制或 Protobuf 需先在 SQL 中 decode()。此外 timestamp 必须由 payload 提供整数 Unix epoch，IoT Core 不生成时间戳。因此对写入可靠性有要求的场景，应配置 errorAction 将失败信息写入 CloudWatch Logs，并借助 failures 数组中的 failedAc
Q&A
AWS IoT Core 的 InfluxDB 规则操作有什么作用？
它允许 AWS IoT Core 规则引擎将设备上报的 JSON 遥测数据直接转换为 InfluxDB line protocol 并写入 InfluxDB，无需通过 Lambda 函数进行格式转换和写入。
如何将一条消息中的多个指标写入不同的 measurement？
在规则操作的 tableName 和 tag 值中使用 @{…} 模板，按数组中的每个元素解析字段值。例如 tableName 设为 "@{metric}"，tags 中设置 "sensor_id": "@{sensor_id}"，即可将不同 metric 写入对应的 measurement。
配置 InfluxDB 规则操作时，destination 需要哪些关键参数？
创建 topic rule destination 时需指定 influxDBConfiguration，包括 endpoint（InfluxDB 端点 URL）、influxDBVersion（V2 或 V3）、secretId（存储 token 的 Secrets Manager ARN）和 secretType（如 SecretString）。
使用 Basic Ingest 发布测试消息有什么好处和注意事项？
好处是消息直接进入指定规则，不经过 MQTT broker，可显著降低消息成本。注意事项包括：topic 格式为 $aws/rules/<ruleName>/<后缀>；纯 Basic Ingest 规则可省略 SQL 的 FROM 子句；Basic Ingest topic 不能被订阅；QoS 1 的 PUBACK 只表示消息到达规则引擎，不代表 action 成功；payload 只支持 JSON。
服务端批处理如何配置？有哪些参数？
通过规则操作中的 batchConfig 配置，参数包括 maxBatchSize（1–500）、maxBatchOpenMs（5–1000）和 maxBatchSizeBytes（100–131072），还可设置 batchAcrossTopics。当任一条件先达到时，规则引擎提交当前批次。客户端批处理和服务端批处理可同时启用。
相比传统 Lambda 方案，使用 InfluxDB 规则操作能节省多少成本？
以 1 亿请求为例，传统 Topic→规则→Lambda 写入方案月成本约 $153.3；使用 Topic→规则→InfluxDB action 约 $130；采用 Basic Ingest 后降至约 $30；若再启用服务端批处理（100/批），可进一步降至约 $15.3。
InfluxDB 规则操作对数据映射和类型转换有什么要求？
line protocol 的 measurement 来自 tableName，tags 来自 tags 参数，fields 来自 payload 中剩余的属性（排除 tag、tableName 引用的 key 和 timestamp），timestamp 来自 payload 的 timestamp 字段。payload 必须包含整数 Unix epoch 时间戳，key 名区分大小写，且 IoT Core 不生成时间戳。
