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 supervisar los datos de series temporales en tiempo real. Puede usar el procesamiento por lotes del lado del cliente o del lado del servidor para combinar varios puntos en una solicitud de escritura. AWS IoT Core convierte cada mensaje al protocolo de línea de InfluxDB y lo escribe en la base de datos y tabla especificadas. Para obtener más información sobre el formato, consulte el protocolo de línea de InfluxDB en la documentación. InfluxData Para obtener información sobre los clústeres administrados, consulte Amazon Timestream para InfluxDB.

Requisitos previos

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

Destino de la acción de InfluxDB

Antes de poder utilizar la acción de la regla de InfluxDB, debe crear un destino de acción de InfluxDB. El destino define los parámetros de conexión para 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 de IoT agrupa datos de series temporales en lotes en forma de 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 única 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 configurado (maxBatchSizemaxBatchOpenMs, omaxBatchSizeBytes).

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 para cada elemento. Para obtener más información, consulte Per-element las plantillas.

Sintaxis de dos plantillas de sustitución

Utilice @{...} los valores de tableName entrada y etiqueta para resolver la expresión con respecto a 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 acción:

{
  "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 del 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 tipos de protocolo de línea de 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 protocolos de línea:

Acciones de error

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

Uso de 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 (${...}) se admiten en las acciones de error tableName ytags.

Resultado de la acción de error

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

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

Los errores reintentables (503) se reintentan con un retroceso exponencial. Para obtener una respuesta HTTP 401, AWS IoT Core vuelve a cargar el token desde AWS Secrets Manager y vuelve a intentar la solicitud 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 reglamentaria de 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"
        }
      }
    ]
  }
}

Carga útil de muestra:

{
  "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 del resultado puede variar; los campos no se ordenan 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"
  }
}

Carga útil de muestra (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 reglas

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)

Al habilitar tanto el procesamiento por lotes del lado del cliente (cargas útiles de matrices JSON) como el procesamiento por lotes del lado del servidor (), tenga en cuenta que el lote del lado del servidor puede reordenar los puntos de una carga por lotes del lado del cliente. batchConfig El motor de reglas acumula puntos de varios mensajes entrantes en un único lote del lado del servidor. Como los mensajes llegan de forma asincrónica desde diferentes dispositivos o temas, los puntos que se ordenaron dentro de la carga útil original del cliente pueden intercalarse con los puntos de otros mensajes en la escritura final.

Configuración de la acción:

{
  "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 500 ms por lotes (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 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 en cada carga útil de 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 utiliza 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 las consultas. Sin embargo, si su aplicación se basa en la semántica del orden de escritura (por ejemplo, gestionar los conflictos entre tipos de campo o la deduplicación de la última escritura gana en el mismo milisegundo), tenga en cuenta que el orden de escritura efectivo puede diferir del orden de publicación.