Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

InfluxDB

Wählen Sie diese Aktion, wenn Sie die Gerätetelemetrie nach Betriebstrends abfragen oder Zeitreihendaten in Echtzeit überwachen möchten. Sie können clientseitiges oder serverseitiges Batching verwenden, um mehrere Punkte in einer Schreibanforderung zu kombinieren. AWS IoT Core konvertiert jede Nachricht in das InfluxDB-Leitungsprotokoll und schreibt sie in die angegebene Datenbank und Tabelle. Weitere Informationen zum Format finden Sie in der Dokumentation unter InfluxDB-Leitungsprotokoll. InfluxData Informationen zu verwalteten Clustern finden Sie unter Amazon Timestream for InfluxDB.

Voraussetzungen

Diese Regelaktion hat die folgenden Voraussetzungen:

Ziel der InfluxDB-Aktion

Bevor Sie die InfluxDB-Regelaktion verwenden können, müssen Sie ein InfluxDB-Aktionsziel erstellen. Das Ziel definiert die Verbindungsparameter für Ihre InfluxDB-Instanz. AWS IoT Core validiert dann den Besitz des Endpunkts.

Ein Ziel erstellen

Verwenden Sie die CreateTopicRuleDestination API, um ein InfluxDB-Ziel zu erstellen:

{
  "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"
    }
  }
}

Zielparameter

Überprüfung des Besitzes am Endpunkt

Wenn Sie ein InfluxDB-Aktionsziel erstellen, AWS IoT Core validiert es den Besitz des Endpoints, indem es sich anhand der von Ihnen angegebenen Anmeldeinformationen gegenüber der InfluxDB-API authentifiziert:

Eine erfolgreiche Antwort (2xx) setzt den Zielstatus auf. ENABLED AWS IoT Core Setzt den Status im Fehlerfall aufERROR. Um die Überprüfung erneut zu versuchen, rufen Sie UpdateTopicRuleDestination mit dem Status auf anIN_PROGRESS.

Zuordnung der InfluxDB-Terminologie

Die folgenden Begriffe unterscheiden sich zwischen InfluxDB V2 und V3.

Parameters

Wenn Sie eine AWS IoT Regel mit der InfluxDB-Aktion erstellen, müssen Sie die folgenden Informationen angeben:

Stapelverarbeitung

Die InfluxDB-Aktion unterstützt zwei Batching-Modi.

Client-side Stapelverarbeitung

Ihr IoT-Gerät stapelt Zeitreihendaten als JSON-Array und veröffentlicht sie als einzelne MQTT-Nachricht. Beim clientseitigen Batching wird jedes Array-Element in einer einzigen Schreibanforderung zu einem Zeilenprotokollpunkt. Sie benötigen keine zusätzliche Konfiguration.

Server-side Stapelverarbeitung

Verwenden Sie serverseitiges Batching, um einzelne Nachrichten zu gruppieren, bevor Sie sie in InfluxDB schreiben. Konfigurieren Sie das serverseitige Batching mithilfe des Parameters. batchConfig Der Stapel wird geleert, wenn ein konfiguriertes Limit (maxBatchSizemaxBatchOpenMs, odermaxBatchSizeBytes) zuerst erreicht wird.

Die InfluxDB-Aktion wird auf der Grundlage der Größe der ausgehenden Nutzdaten in Schritten von 5 KiB gemessen. Line-protocol Konvertierungsfehler werden ebenfalls gemessen.

Per-element Vorlagen für Array-Nutzlasten

Wenn Ihre IoT-Geräte gestapelte Zeitreihendaten als JSON-Array senden, können Sie die „Vorlagen für die Ersetzung pro Element“ verwenden, um Werte aus jedem einzelnen Array-Element aufzulösen. Dadurch wird jeder Datenpunkt an eine andere Tabelle weitergeleitet oder elementspezifische Tags angewendet. Weitere Informationen finden Sie unter Per-element Vorlagen.

Syntax von zwei Vorlagen für Substitutionen

Verwenden Sie @{...} in tableName - und Tag-Werte, um den Ausdruck für jedes Array-Element einzeln aufzulösen.

Beispiel

Angesichts der folgenden Gerätenutzlast (JSON-Array):

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

Und die folgende Aktionskonfiguration:

{
  "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"
  }
}

Die resultierende Line-Protocol-Ausgabe enthält zwei Punkte:

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

Einschränkungen

Inhalt des InfluxDB-Datensatzes

Für jeden Datensatz im Post-SQL-Abfrageergebnis enthält der resultierende InfluxDB-Zeilenprotokollpunkt die folgenden Komponenten:

Datentypkonvertierung

AWS IoT Core konvertiert JSON-Werte wie folgt in InfluxDB-Zeilenprotokolltypen:

Einschränkungen bei der Benennung

Reservierte Schlüssel

Die folgenden Nutzdatenschlüssel werden bei der Konvertierung des Leitungsprotokolls aus dem Feldsatz entfernt:

Fehleraktionen

Wenn die InfluxDB-Aktion fehlschlägt, wird die konfigurierte Fehleraktion ausgelöst.

InfluxDB als Fehleraktion verwenden

Sie können die InfluxDB-Aktion als Fehleraktion für jede Regel konfigurieren. Die gesamte Nutzlast wird tableName als ein Datensatz in einen einzigen Datensatz geschrieben. Message-scope Substitutionsvorlagen (${...}) werden in den Fehleraktionen und unterstützt. tableName tags

Ausgabe der Fehleraktion

Wenn die Fehleraktion ausgelöst wird, enthält die Ausgabe-Nutzlast:ruleName,topic,cloudwatchTraceId, clientIdsourceIp, base64OriginalPayload (Base64-encoded Originalnachricht) und ein failures Array, in dem jeder Eintrag failedActionfailedResource, und errorMessage enthält.

Beim serverseitigen Batching verwendet payloadsWithMetadata die Payload Folgendes: Ein Eintrag für jede einzelne eingehende MQTT-Nachricht. Die Werte jedes Fehlers beziehen sich auf die affectedIds id Werte dieser Nachrichteneinträge; es handelt sich nicht um Punktindizes. Ein clientseitiges JSON-Array ist eine eingehende Nachricht, obwohl es mehrere InfluxDB-Punkte erzeugt. Das vollständige Payload-Format finden Sie unter. Fehleraktionen beim Stapeln

Wiederholbare Fehler (503) werden mit exponentiellem Backoff wiederholt. AWS IoT Core Lädt bei einer HTTP 401-Antwort das Token erneut von und versucht die Anfrage einmal erneut. AWS Secrets Manager Non-retryable Fehler (404, 422) lösen die Fehleraktion sofort aus. Die Grenzwerte für Wiederholungsversuche finden Sie unter AWS IoT Core Dienstkontingente.

Beispiele

Aktion der InfluxDB-Regel

{
  "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"
        }
      }
    ]
  }
}

Beispiel für eine Nutzlast:

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

Resultierendes Leitungsprotokoll:

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

Die Reihenfolge der Felder in der Ausgabe kann variieren — die Felder sind nicht alphabetisch sortiert.

Client-batched Array-Nutzlast mit Vorlagen pro Element

{
  "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"
  }
}

Beispiel-Nutzlast (veröffentlicht unter): 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}
]

Resultierendes Leitungsprotokoll:

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

Server-side Batching mit InfluxDB

Um einer InfluxDB-Aktion serverseitiges Batching hinzuzufügen, nehmen Sie Folgendes in die Aktionskonfiguration auf: batchConfig

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

IAM-Richtlinie für die Rolle „Regelaktion“

Vertrauensrichtlinie:

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

Richtlinien zur Genehmigung:

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

Kombiniertes clientseitiges und serverseitiges Batching (Neuanordnung von Punkten)

Wenn Sie sowohl das clientseitige Batching (JSON-Array-Payloads) als auch das serverseitige Batching () aktivieren, beachten Sie, dass das serverseitige Batch möglicherweise Punkte batchConfig aus einer clientseitigen Batch-Payload neu anordnet. Die Rules Engine sammelt Punkte aus mehreren eingehenden Nachrichten in einem einzigen serverseitigen Batch. Da Nachrichten asynchron von verschiedenen Geräten oder Themen ankommen, können Punkte, die innerhalb der ursprünglichen Client-Nutzlast angeordnet waren, beim letzten Schreibvorgang mit Punkten aus anderen Nachrichten verschachtelt werden.

Konfiguration der Aktion:

{
  "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
    }
  }
}

Gerät A veröffentlicht devices/deviceA/telemetry an zum Zeitpunkt 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}
]

Gerät B veröffentlicht devices/deviceB/telemetry an zum Zeitpunkt T+10 ms:

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

Beide Nachrichten kommen innerhalb des Batchfensters von 500 ms an (maxBatchOpenMs), sodass die Rules Engine alle fünf Punkte zu einem einzigen serverseitigen Batch zusammenfasst.

Das resultierende Zeilenprotokoll (serverseitiges Batch-Schreiben):

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

Beachten Sie, dass die Punkte nicht mehr in der Reihenfolge angeordnet sind, in der sie in den einzelnen Client-Nutzdaten erschienen sind. Die drei Punkte von Gerät A (Zeitstempel 1700000000000, 1700000000100, 1700000000200) sind mit den beiden Punkten von Gerät B (Zeitstempel 1700000000050, 1700000000150) verschachtelt. Der serverseitige Batch garantiert nicht die ursprüngliche Reihenfolge in jeder Nachricht. InfluxDB verwendet das Zeitstempelfeld, um jeden Punkt auf der Timeline zu platzieren, sodass die Neuanordnung die Richtigkeit der Abfrage nicht beeinträchtigt. Wenn Ihre Anwendung jedoch auf Semantik der Schreibreihenfolge angewiesen ist (z. B. die Behandlung von Feldtypkonflikten oder die Deduplizierung bei Last-Write-Wins innerhalb derselben Millisekunde), beachten Sie, dass die effektive Schreibreihenfolge von der Veröffentlichungsreihenfolge abweichen kann.