Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

InfluxDB

Scegli questa azione quando desideri interrogare la telemetria del dispositivo per verificare le tendenze operative o monitorare i dati di serie temporali in tempo reale. Puoi utilizzare il batching lato client o lato server per combinare più punti in un'unica richiesta di scrittura. AWS IoT Core converte ogni messaggio nel protocollo di linea InfluxDB e lo scrive nel database e nella tabella specificati. Per ulteriori informazioni sul formato, consulta il protocollo di linea InfluxDB nella documentazione. InfluxData Per informazioni sui cluster gestiti, consulta Amazon Timestream for InfluxDB.

Prerequisiti

L'azione di questa regola presenta i seguenti prerequisiti:

Destinazione dell’azione InfluxDB

Prima di poter utilizzare l'azione della regola InfluxDB, è necessario creare una destinazione dell'azione InfluxDB. La destinazione definisce i parametri di connessione per l'istanza InfluxDB. AWS IoT Core quindi convalida la proprietà dell'endpoint.

Creare una destinazione

Usa l'CreateTopicRuleDestinationAPI per creare una destinazione 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"
    }
  }
}

Parametri di destinazione

Convalida della proprietà degli endpoint

Quando crei una destinazione d'azione InfluxDB, AWS IoT Core convalida la proprietà dell'endpoint autenticandosi con l'API InfluxDB utilizzando le credenziali che hai fornito:

Una risposta riuscita (2xx) imposta lo stato della destinazione su. ENABLED In caso di errore, AWS IoT Core imposta lo stato su. ERROR Per riprovare la convalida, chiama UpdateTopicRuleDestination con lo stato impostato su. IN_PROGRESS

Mappatura terminologica di InfluxDB

I seguenti termini differiscono tra InfluxDB V2 e V3.

Parameters

Quando crei una AWS IoT regola con l'azione InfluxDB, devi specificare le seguenti informazioni:

Batching

L'azione InfluxDB supporta due modalità di batch.

Client-side dosaggio

Il tuo dispositivo IoT raggruppa i dati delle serie temporali come array JSON e li pubblica come un singolo messaggio MQTT. Con il batching lato client, ogni elemento dell'array diventa un punto di protocollo di linea in una singola richiesta di scrittura. Non è necessaria alcuna configurazione aggiuntiva.

Server-side dosaggio

Usa il batching lato server per raggruppare i singoli messaggi prima di scriverli su InfluxDB. Configura il batching lato server utilizzando il parametro. batchConfig Il batch viene svuotato quando viene raggiunto per primo un limite configurato (maxBatchSize,maxBatchOpenMs, omaxBatchSizeBytes).

L'azione InfluxDB viene misurata in base alla dimensione del payload in uscita in incrementi di 5 KB. Line-protocol vengono misurati anche gli errori di conversione.

Per-element modelli per payload di array

Quando i dispositivi IoT inviano dati di serie temporali in batch come array JSON, puoi utilizzare i «modelli di sostituzione per elemento» per risolvere i valori di ogni singolo elemento dell'array. Questo indirizza ogni punto dati a una tabella diversa o applica tag specifici dell'elemento. Per ulteriori informazioni, consulta Per-element sostituzione per i payload dell'array in AWS IoT rules.

Sintassi di due modelli di sostituzione

Utilizzate i valori @{...} in tableName e tag per risolvere singolarmente l'espressione rispetto a ciascun elemento dell'array.

Esempio

Dato il seguente payload del dispositivo (array JSON):

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

E la seguente configurazione di azione:

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

L'output del protocollo di linea risultante contiene due punti:

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

Restrizioni

Contenuto del record InfluxDB

Per ogni record nel risultato della query post-SQL, il punto di protocollo di linea InfluxDB risultante contiene questi componenti:

Conversione dei tipi di dati

AWS IoT Core converte i valori JSON in tipi di protocollo di linea InfluxDB come segue:

Restrizioni di denominazione

Chiavi riservate

Le seguenti chiavi di payload vengono rimosse dal campo impostato durante la conversione del protocollo di linea:

Azioni di errore

Se l'azione InfluxDB fallisce, viene attivata l'azione di errore configurata.

Utilizzo di InfluxDB come azione di errore

È possibile configurare l'azione InfluxDB come azione di errore per qualsiasi regola. L'intero payload viene scritto in un unico recordtableName. Message-scope i modelli di sostituzione (${...}) sono supportati nell'azione di errore e. tableName tags

Output dell'azione di errore

Quando viene attivata l'azione di errore, il payload di output contiene: ruleNametopic,,cloudwatchTraceId,clientId,sourceIp, base64OriginalPayload (messaggio Base64-encoded originale) e un failures array in cui ogni voce contiene failedActionfailedResource, e. errorMessage

Con il batching lato server, il payload utilizza una voce per ogni messaggio payloadsWithMetadata MQTT in ingresso distinto. affectedIdsI valori di ogni errore si riferiscono ai id valori di tali voci di messaggio; non sono indici di punti. Un array JSON lato client è un messaggio in entrata anche se produce più punti InfluxDB. Per il formato di payload completo, consulta. Azioni di errore per il batching

Gli errori rieseguibili (503) vengono ritentati con un backoff esponenziale. Per una risposta HTTP 401, AWS IoT Core ricarica il token da e ritenta la richiesta una volta. AWS Secrets Manager Non-retryable gli errori (404, 422) attivano immediatamente l'azione di errore. Per i limiti dei tentativi, consulta le quote di AWS IoT Core servizio.

Esempi

Azione della regola 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"
        }
      }
    ]
  }
}

Payload di esempio:

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

Protocollo di linea risultante:

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

L'ordine dei campi nell'output può variare: i campi non sono ordinati alfabeticamente.

Client-batched payload dell'array con modelli per elemento

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

Payload di esempio (pubblicato su): 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}
]

Protocollo di linea risultante:

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 batch con InfluxDB

Per aggiungere il batching lato server a qualsiasi azione InfluxDB, includi nella configurazione dell'azione: batchConfig

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

Politica IAM per il ruolo Rule Action

Politica di fiducia:

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

Politica di autorizzazione:

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

Batching combinato lato client e lato server (riordino dei punti)

Quando abilitate sia il batching lato client (payload dell'array JSON) che il batching lato server (), tenete presente che il batch lato server può riordinare i punti da un payload in batch lato client. batchConfig Il Rules Engine accumula punti da più messaggi in arrivo in un unico batch lato server. Poiché i messaggi arrivano in modo asincrono da dispositivi o argomenti diversi, i punti ordinati all'interno del payload del client originale possono essere interlacciati con i punti di altri messaggi durante la scrittura finale.

Configurazione dell'azione:

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

Il dispositivo A pubblica devices/deviceA/telemetry su al momento 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}
]

Il dispositivo B pubblica al devices/deviceB/telemetry momento T+10 ms:

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

Entrambi i messaggi arrivano entro la finestra batch di 500 ms (maxBatchOpenMs), quindi il Rules Engine combina tutti e cinque i punti in un unico batch lato server.

Protocollo di linea risultante (scrittura batch lato server):

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

Notate che i punti non sono più nell'ordine in cui sono apparsi all'interno di ogni payload del client. I tre punti del dispositivo A (timestamp 1700000000000, 1700000000100, 1700000000200) sono interlacciati con i due punti del dispositivo B (timestamp 1700000000050, 1700000000150). Il batch lato server non garantisce l'ordine originale all'interno di ogni messaggio. InfluxDB utilizza il campo timestamp per posizionare ogni punto sulla timeline, quindi il riordino non influisce sulla correttezza della query. Tuttavia, se l'applicazione si basa sulla semantica dell'ordine di scrittura (ad esempio, la gestione dei conflitti tra i tipi di campo o la deduplicazione dell'ultima scrittura entro lo stesso millisecondo), tieni presente che l'ordine di scrittura effettivo può differire dall'ordine di pubblicazione.