本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

InfluxDB

當您想要查詢裝置遙測以取得操作趨勢或即時監控時間序列資料時，請選擇此動作。您可以使用用戶端或伺服器端批次，將多個點合併在一個寫入請求中。 會將每個訊息 AWS IoT Core 轉換為 InfluxDB 線路通訊協定，並將其寫入指定的資料庫和資料表。如需 格式的詳細資訊，請參閱 InfluxData 文件中的 InfluxDB 行通訊協定。 InfluxData 如需受管叢集的資訊，請參閱 Amazon Timestream for InfluxDB。

先決條件

此規則動作具有下列先決條件：

InfluxDB 動作目的地

您必須先建立 InfluxDB 動作目的地，才能使用 InfluxDB 規則動作。目的地會定義 InfluxDB 執行個體的連線參數。 AWS IoT Core 然後驗證端點擁有權。

建立目的地

使用 CreateTopicRuleDestination API 建立 InfluxDB 目的地：

{
  "destinationConfiguration": {
    "influxDBConfiguration": {
      "endpoint": "https://my-instance.timestream-influxdb.us-west-2.amazonaws.com:8086",
      "influxDBVersion": "V2",
      "secretId": "arn:aws:secretsmanager:us-west-2:111122223333:secret:my-influxdb-credentials-AbCdEf"
    }
  }
}

目的地參數

端點擁有權驗證

當您建立 InfluxDB 動作目的地時， 會使用您提供的登入資料，針對 InfluxDB API 驗證 AWS IoT Core 端點擁有權：

成功回應 (2xx) 會將目的地狀態設定為 ENABLED。失敗時， 會將狀態 AWS IoT Core 設定為 ERROR。若要重試驗證，請呼叫 UpdateTopicRuleDestination 狀態設為 IN_PROGRESS。

InfluxDB 術語映射

下列術語在 InfluxDB V2 和 V3 之間不同。

Parameters

當您使用 InfluxDB 動作建立 AWS IoT 規則時，您必須指定下列資訊：

批次處理

InfluxDB 動作支援兩種批次模式。

用戶端批次處理

您的 IoT 裝置會將時間序列資料批次處理為 JSON 陣列，並將其發佈為單一 MQTT 訊息。透過用戶端批次處理，每個陣列元素會在單一寫入請求中成為一個明細協定點。您不需要額外的組態。

伺服器端批次處理

在將個別訊息寫入 InfluxDB 之前，使用伺服器端批次處理來分組個別訊息。使用 batchConfig 參數設定伺服器端批次處理。批次會在先達到任何設定的限制 (maxBatchOpenMs、 maxBatchSize或 maxBatchSizeBytes) 時排清。

InfluxDB 動作是根據傳出承載大小計量，以 5 KiB 遞增。也會測量線路通訊協定轉換失敗。

陣列承載的每個元素範本

當您的 IoT 裝置以 JSON 陣列傳送批次時間序列資料時，您可以使用「每個元素替換範本」來解析每個個別陣列元素的值。這會將每個資料點路由到不同的資料表，或套用元素特定的標籤。如需詳細資訊，請參閱每個元素範本。

兩個替代範本的語法

使用 @{...} tableName和 標籤值，個別解析每個陣列元素的表達式。

範例

根據下列裝置承載 (JSON 陣列）：

[
  {"measurement_type": "temperature", "room": "kitchen", "timestamp": 1700000000000, "value": 23.5},
  {"measurement_type": "humidity", "room": "bedroom", "timestamp": 1700000001000, "value": 60.1}
]

以及下列動作組態：

{
  "influxDB": {
    "destinationArn": "arn:aws:iot:us-west-2:111122223333:ruledestination/influxdb/abc123",
    "roleArn": "arn:aws:iam::111122223333:role/iot-influxdb-role",
    "databaseName": "sensor_data",
    "tableName": "@{measurement_type}",
    "tags": {
      "room": "@{room}"
    },
    "timestampUnit": "ms"
  }
}

產生的明細協定輸出包含兩個點：

temperature,room=kitchen value=23.5 1700000000000
humidity,room=bedroom value=60.1 1700000001000

限制

InfluxDB 記錄內容

對於 Post-SQL 查詢結果中的每個記錄，產生的 InfluxDB Line-protocol 點包含下列元件：

資料類型轉換

AWS IoT Core 將 JSON 值轉換為 InfluxDB 行通訊協定類型，如下所示：

命名限制

預留金鑰

下列承載金鑰會在明細協定轉換期間從欄位集分割：

錯誤動作

如果 InfluxDB 動作失敗，則會觸發設定的錯誤動作。

使用 InfluxDB 做為錯誤動作

您可以將 InfluxDB 動作設定為任何規則的錯誤動作。整個承載會寫入單一tableName記錄。錯誤動作的 tableName和 支援訊息範圍替代範本 (${...})tags。

錯誤動作輸出

觸發錯誤動作時，輸出承載包含：ruleName、topic、cloudwatchTraceId、sourceIp、、 clientIdbase64OriginalPayload(Base64 編碼的原始訊息），以及每個項目都有 failedAction、 failedResource和 的failures陣列errorMessage。

透過伺服器端批次處理，承載會使用 payloadsWithMetadata，每個不同的傳入 MQTT 訊息各有一個項目。每個失敗affectedIds的值都是指這些訊息項目id的值；它們不是點索引。用戶端 JSON 陣列是一種傳入訊息，即使它會產生多個 InfluxDB 點。如需完整的承載格式，請參閱 批次處理的錯誤動作。

可重試錯誤 (503) 會以指數退避重試。對於 HTTP 401 回應， 會從 AWS IoT Core 重新載入字符 AWS Secrets Manager ，並重試一次請求。不可重試的錯誤 (404、422) 會立即觸發錯誤動作。如需重試限制，請參閱AWS IoT Core 服務配額。

範例

InfluxDB 規則動作

{
  "topicRulePayload": {
    "sql": "SELECT * FROM 'devices/+/telemetry'",
    "ruleDisabled": false,
    "awsIotSqlVersion": "2016-03-23",
    "actions": [
      {
        "influxDB": {
          "destinationArn": "arn:aws:iot:us-west-2:111122223333:ruledestination/influxdb/a1b2c3d4",
          "roleArn": "arn:aws:iam::111122223333:role/iot-influxdb-role",
          "organization": "my-org",
          "databaseName": "sensor_data",
          "tableName": "device_metrics",
          "tags": {
            "device_id": "${clientid()}",
            "location": "building-a"
          },
          "timestampUnit": "ms"
        }
      }
    ]
  }
}

範例承載：

{
  "timestamp": 1700000000000,
  "temperature": 23.5,
  "humidity": 60.1,
  "pressure": 1013.25,
  "battery_level": 87
}

產生的線路通訊協定：

device_metrics,device_id=myDevice123,location=building-a temperature=23.5,humidity=60.1,pressure=1013.25,battery_level=87i 1700000000000

輸出中的欄位順序可能不同 — 欄位不會按字母順序排序。

具有每個元素範本的用戶端批次陣列承載

{
  "influxDB": {
    "destinationArn": "arn:aws:iot:us-west-2:111122223333:ruledestination/influxdb/a1b2c3d4",
    "roleArn": "arn:aws:iam::111122223333:role/iot-influxdb-role",
    "organization": "my-org",
    "databaseName": "sensor_data",
    "tableName": "@{measurement_type}",
    "tags": {
      "sensor_id": "@{sensor_id}",
      "location": "${topic(2)}"
    },
    "timestampUnit": "ns"
  }
}

範例承載 （發佈至 devices/floor3/telemetry)：

[
  {"measurement_type": "temperature", "sensor_id": "sensor-42", "timestamp": 1700000000000000000, "value": 23.5},
  {"measurement_type": "humidity", "sensor_id": "sensor-42", "timestamp": 1700000001000000000, "value": 60.1},
  {"measurement_type": "pressure", "sensor_id": "sensor-43", "timestamp": 1700000002000000000, "value": 1013.25}
]

產生的線路通訊協定：

temperature,location=floor3,sensor_id=sensor-42 value=23.5 1700000000000000000
humidity,location=floor3,sensor_id=sensor-42 value=60.1 1700000001000000000
pressure,location=floor3,sensor_id=sensor-43 value=1013.25 1700000002000000000

使用 InfluxDB 的伺服器端批次處理

若要將伺服器端批次新增至任何 InfluxDB 動作，請在動作組態batchConfig中包含 ：

"batchConfig": {
  "maxBatchSize": 50,
  "maxBatchOpenMs": 1000,
  "maxBatchSizeBytes": 65536,
  "batchAcrossTopics": false
}

規則動作角色的 IAM 政策

信任政策：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {"Service": "iot.amazonaws.com"},
      "Action": "sts:AssumeRole"
    }
  ]
}

許可政策：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "arn:aws:secretsmanager:us-west-2:111122223333:secret:my-influxdb-secret-a1b2c3"
    }
  ]
}

合併用戶端和伺服器端批次處理 （點重新排序）

當您同時啟用用戶端批次處理 (JSON 陣列承載） 和伺服器端批次處理 (batchConfig) 時，請注意伺服器端批次可能會從用戶端批次處理承載重新排序點。規則引擎會將來自多個傳入訊息的點累積到單一伺服器端批次。由於訊息從不同的裝置或主題非同步到達，因此在原始用戶端承載中排序的點可能會與最終寫入中其他訊息的點交錯。

動作組態：

{
  "influxDB": {
    "destinationArn": "arn:aws:iot:us-west-2:111122223333:ruledestination/influxdb/abc123",
    "roleArn": "arn:aws:iam::111122223333:role/iot-influxdb-role",
    "databaseName": "sensor_data",
    "tableName": "@{measurement_type}",
    "tags": {
      "device_id": "${topic(2)}",
      "floor": "@{floor}"
    },
    "timestampUnit": "ms",
    "batchConfig": {
      "maxBatchSize": 100,
      "maxBatchOpenMs": 500,
      "maxBatchSizeBytes": 65536,
      "batchAcrossTopics": true
    }
  }
}

裝置 A devices/deviceA/telemetry會在時間 T 發佈至 ：

[
  {"measurement_type": "temperature", "floor": "1", "timestamp": 1700000000000, "value": 22.1},
  {"measurement_type": "temperature", "floor": "2", "timestamp": 1700000000100, "value": 23.4},
  {"measurement_type": "humidity", "floor": "1", "timestamp": 1700000000200, "value": 55.0}
]

裝置 B 在 T+10ms devices/deviceB/telemetry 時發佈至 ：

[
  {"measurement_type": "temperature", "floor": "3", "timestamp": 1700000000050, "value": 21.8},
  {"measurement_type": "humidity", "floor": "3", "timestamp": 1700000000150, "value": 62.3}
]

這兩個訊息會在 500ms 批次時段 (maxBatchOpenMs) 內送達，因此規則引擎會將所有五個點合併為單一伺服器端批次。

產生的線路通訊協定 （伺服器端批次寫入）：

temperature,device_id=deviceB,floor=3 value=21.8 1700000000050
temperature,device_id=deviceA,floor=1 value=22.1 1700000000000
temperature,device_id=deviceA,floor=2 value=23.4 1700000000100
humidity,device_id=deviceB,floor=3 value=62.3 1700000000150
humidity,device_id=deviceA,floor=1 value=55.0 1700000000200

請注意，這些點不再依照每個用戶端承載中顯示的順序顯示。裝置 A 的三個點 （時間戳記 1700000000000、1700000000100、1700000000200) 會與裝置 B 的兩個點 （時間戳記 1700000000050、1700000000150) 交錯。伺服器端批次不保證每個訊息中的原始排序。InfluxDB 使用時間戳記欄位將每個點放置在時間軸上，因此重新排序不會影響查詢正確性。不過，如果您的應用程式依賴寫入順序語意 （例如，在相同毫秒內處理欄位類型衝突或last-write-wins重複資料刪除），請注意，有效的寫入順序可能與發佈順序不同。