Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

InfluxDB

Elija esta acción si desea consultar la telemetría del dispositivo para conocer las tendencias operativas o monitorizar los datos de series temporales en tiempo real. Puede utilizar el procesamiento por lotes del lado del cliente o del lado del servidor para combinar varios puntos en una sola solicitud de escritura. AWS IoT Core convierte cada mensaje al protocolo de línea InfluxDB y lo escribe en la base de datos y la tabla especificadas. Para obtener más información sobre el formato, consulte el protocolo de línea InfluxDB en la documentación. InfluxData Para obtener información sobre los clústeres gestionados, consulte Amazon Timestream for InfluxDB.

Requisitos previos

Esta acción de regla tiene los siguientes requisitos previos:

Destino de acción de InfluxDB

Antes de poder utilizar la acción de la regla InfluxDB, debe crear un destino de acción de InfluxDB. El destino define los parámetros de conexión de su instancia de InfluxDB. AWS IoT Core luego valida la propiedad del punto final.

Crear un destino

Utilice la CreateTopicRuleDestination API para crear un destino de 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"
    }
  }
}

Parámetros de destino

Validación de la propiedad del terminal

Al crear un destino de acción de InfluxDB, AWS IoT Core valida la propiedad del punto final autenticándose en la API de InfluxDB con las credenciales que proporcionó:

Una respuesta correcta (2xx) establece el estado del destino en. ENABLED En caso de error, AWS IoT Core establece el estado enERROR. Para volver a intentar la validación, llame UpdateTopicRuleDestination con el estado establecido en. IN_PROGRESS

Mapeo terminológico de InfluxDB

Los siguientes términos difieren entre InfluxDB V2 y V3.

Parameters

Al crear una AWS IoT regla con la acción InfluxDB, debe especificar la siguiente información:

Agrupación en lotes

La acción InfluxDB admite dos modos de procesamiento por lotes.

Client-side procesamiento por lotes

Su dispositivo IoT agrupa los datos de series temporales como una matriz JSON y los publica como un único mensaje MQTT. Con el procesamiento por lotes del lado del cliente, cada elemento de la matriz se convierte en un punto de protocolo de línea en una sola solicitud de escritura. No necesita ninguna configuración adicional.

Server-side procesamiento por lotes

Utilice el procesamiento por lotes del lado del servidor para agrupar los mensajes individuales antes de escribirlos en InfluxDB. Configure el procesamiento por lotes del lado del servidor mediante el parámetro. batchConfig El lote se vacía cuando se alcanza primero cualquier límite (maxBatchSizemaxBatchOpenMs, omaxBatchSizeBytes) configurado.

La acción de InfluxDB se mide en función del tamaño de la carga útil saliente en incrementos de 5 KiB. Line-protocol los errores de conversión también se miden.

Per-element plantillas para cargas útiles de matrices

Cuando sus dispositivos de IoT envían datos de series temporales por lotes como una matriz JSON, puede usar las «plantillas de sustitución por elemento» para resolver los valores de cada elemento individual de la matriz. Esto dirige cada punto de datos a una tabla diferente o aplica etiquetas específicas de cada elemento. Para obtener más información, consulte Per-element sustitución de cargas útiles de matriz en AWS IoT reglas.

Sintaxis de dos plantillas de sustitución

Utilice los valores @{...} in tableName y tag para resolver la expresión en cada elemento de la matriz de forma individual.

Ejemplo

Dada la siguiente carga útil del dispositivo (matriz JSON):

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

Y la siguiente configuración de acciones:

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

La salida de protocolo de línea resultante contiene dos puntos:

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

Restricciones

Contenido del registro de InfluxDB

Para cada registro del resultado de la consulta posterior a SQL, el punto de protocolo de línea de InfluxDB resultante contiene los siguientes componentes:

Conversión de tipos de datos

AWS IoT Core convierte los valores JSON en los tipos de protocolo de línea InfluxDB de la siguiente manera:

Restricciones de denominación

Claves reservadas

Las siguientes claves de carga útil se eliminan del conjunto de campos durante la conversión de protocolo de línea:

Acciones de error

Si la acción de InfluxDB falla, se activa la acción de error configurada.

Usar InfluxDB como acción de error

Puede configurar la acción de InfluxDB como una acción de error para cualquier regla. Toda la carga útil se escribe en un único registrotableName. Message-scope las plantillas de sustitución (${...}) son compatibles con la acción de error tableName ytags.

Resultado de la acción de error

Cuando se activa la acción de error, la carga útil de salida contiene: ruleNametopic,cloudwatchTraceId,clientId,sourceIp, base64OriginalPayload (mensaje Base64-encoded original) y una failures matriz en la que cada entrada tiene failedActionfailedResource, yerrorMessage.

Con el procesamiento por lotes del lado del servidor, la carga utilizapayloadsWithMetadata, con una entrada para cada mensaje MQTT entrante distinto. affectedIdsLos valores de cada error se refieren a los id valores de esas entradas de mensajes; no son índices puntuales. Una matriz JSON del lado del cliente es un mensaje entrante aunque produzca varios puntos de InfluxDB. Para ver el formato completo de la carga útil, consulte. Acciones de error al procesar por lotes

Los errores que se pueden volver a intentar (503) se vuelven a intentar con un retroceso exponencial. Para obtener una respuesta HTTP 401, AWS IoT Core recarga el token desde AWS Secrets Manager la solicitud y vuelve a intentarlo una vez. Non-retryable los errores (404, 422) activan la acción de error inmediatamente. Para conocer los límites de reintentos, consulta las cuotas AWS IoT Core de servicio.

Ejemplos

Acción de la regla 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"
        }
      }
    ]
  }
}

Ejemplo de carga útil:

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

Protocolo de línea resultante:

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

El orden de los campos en la salida puede variar; los campos no están ordenados alfabéticamente.

Client-batched carga útil de matriz con plantillas por 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"
  }
}

Ejemplo de carga útil (publicada en): 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}
]

Protocolo de línea resultante:

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 procesamiento por lotes con InfluxDB

Para añadir el procesamiento por lotes del lado del servidor a cualquier acción de InfluxDB, incluya en la configuración de la acción: batchConfig

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

Política de IAM para la función de acción de la regla

Política de confianza:

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

Política de permisos

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

Procesamiento por lotes combinado del lado del cliente y del lado del servidor (reordenamiento de puntos)

Si habilita el procesamiento por lotes del lado del cliente (cargas útiles de matriz JSON) y el procesamiento por lotes del lado del servidor (), tenga en cuenta que el lote del lado del servidor puede reordenar los puntos batchConfig de una carga útil del lado del cliente. El motor de reglas acumula los puntos de varios mensajes entrantes en un único lote del lado del servidor. Como los mensajes llegan de forma asíncrona desde distintos dispositivos o temas, los puntos que estaban ordenados dentro de la carga útil original del cliente pueden intercalarse con los puntos de otros mensajes al escribirlos finalmente.

Configuración de acciones:

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

El dispositivo A publica devices/deviceA/telemetry en el 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}
]

El dispositivo B publica devices/deviceB/telemetry en el momento T+10 ms:

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

Ambos mensajes llegan dentro del intervalo de lotes de 500 ms (maxBatchOpenMs), por lo que el motor de reglas combina los cinco puntos en un único lote del lado del servidor.

Protocolo de línea resultante (escritura por lotes en el lado del servidor):

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

Observe que los puntos ya no están en el orden en que aparecían dentro de la carga útil de cada cliente. Los tres puntos del dispositivo A (marcas de tiempo 1700000000000, 1700000000100, 1700000000200) se intercalan con los dos puntos del dispositivo B (marcas de tiempo 1700000000050, 1700000000150). El lote del servidor no garantiza el pedido original de cada mensaje. InfluxDB usa el campo de marca de tiempo para colocar cada punto en la línea de tiempo, por lo que el reordenamiento no afecta a la exactitud de la consulta. Sin embargo, si su aplicación se basa en la semántica del orden de escritura (por ejemplo, gestiona los conflictos de tipos de campo o la deduplicación de la última escritura en el mismo milisegundo), tenga en cuenta que el orden de escritura efectivo puede diferir del orden de publicación.