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, vedere il protocollo di linea InfluxDB nella documentazione. InfluxData Per informazioni sui cluster gestiti, consulta Amazon Timestream per InfluxDB.

Prerequisiti

Questa azione basata sulla regola ha 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.

Creazione di 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à degli 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 della terminologia 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 raggruppamento in batch

Il tuo dispositivo IoT raggruppa i dati delle serie temporali come un 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 una configurazione aggiuntiva.

Server-side raggruppamento in batch

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 con incrementi di 5 KiB. Line-protocol Anche gli errori di conversione vengono misurati.

Per-element modelli per i payload degli array

Quando i tuoi 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 i modelli.

Sintassi di due modelli di sostituzione

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

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 delle azioni:

{
  "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 del protocollo di linea InfluxDB risultante contiene questi componenti:

Conversione dei tipi di dati

AWS IoT Core converte i valori JSON nei 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 su un singolo recordtableName. Message-scope i modelli di sostituzione (${...}) sono supportati nelle azioni 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 ha failedActionfailedResource, e. errorMessage

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

Gli errori rieseguibili (503) vengono ritentati con un backoff esponenziale. Per una risposta HTTP 401, AWS IoT Core ricarica il token da e riprova la richiesta una volta. AWS Secrets Manager Non-retryable gli errori (404, 422) attivano immediatamente l'azione di errore. Per i limiti dei tentativi, vedi 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"
        }
      }
    ]
  }
}

Esempio di payload:

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

Esempio di payload (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 raggruppamento 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 di azione delle regole

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 abiliti sia il batching lato client (payload di array JSON) che il batching lato server (), tieni presente che il batch lato server potrebbe riordinare i punti da un payload in batch sul lato client. batchConfig Il Rules Engine accumula punti da più messaggi in arrivo in un unico batch sul lato server. Poiché i messaggi arrivano in modo asincrono da dispositivi o argomenti diversi, i punti ordinati all'interno del payload originale del client possono essere interlacciati con i punti provenienti da altri messaggi in fase di 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 al devices/deviceA/telemetry 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 devices/deviceB/telemetry al tempo T+10ms:

[
  {"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 riga risultante (scrittura in batch sul 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

Nota che i punti non sono più nell'ordine in cui sono apparsi all'interno del payload di ciascun cliente. 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 ciascun messaggio. InfluxDB utilizza il campo timestamp per inserire ogni punto sulla timeline, quindi il riordino non influisce sulla correttezza della query. Tuttavia, se la tua applicazione si basa sulla semantica dell'ordine di scrittura (ad esempio, la gestione dei conflitti tra i tipi di campo o la deduplicazione delle vittorie all'ultima scrittura entro lo stesso millisecondo), tieni presente che l'ordine di scrittura effettivo potrebbe differire dall'ordine di pubblicazione.