As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # InfluxDB Escolha essa ação quando quiser consultar a telemetria do dispositivo em busca de tendências operacionais ou monitorar dados de séries temporais em tempo real. Você pode usar o batching do lado do cliente ou do lado do servidor para combinar vários pontos em uma solicitação de gravação. AWS IoT Core converte cada mensagem no protocolo de linha InfluxDB e a grava no banco de dados e na tabela especificados. Para obter mais informações sobre o formato, consulte o protocolo de linha [ InfluxDB ](https://docs.influxdata.com/influxdb3/enterprise/reference/line-protocol/) na InfluxData documentação. Para obter informações sobre clusters gerenciados, consulte [ Amazon Timestream for InfluxDB. ](https://docs.aws.amazon.com/timestream/latest/developerguide/influxdb3.html) **Topics** + [Pré-requisitos](#influxdb-rule-action-prerequisites) + [Destino da ação do InfluxDB](#influxdb-action-destination) + [Mapeamento de terminologia do InfluxDB](#influxdb-terminology-mapping) + [Parâmetros](#influxdb-rule-action-parameters) + [Agrupamento em lotes](#influxdb-rule-action-batching) + [Per-element modelos para cargas úteis de matriz](#influxdb-per-element-templates) + [Conteúdo de gravação do InfluxDB](#influxdb-record-content) + [Ações de erro](#influxdb-error-actions) + [Exemplos](#influxdb-rule-action-examples) ## Pré-requisitos Essa ação de regra tem os seguintes pré-requisitos: + **Um destino de ação do InfluxDB ** — Crie um destino de ação do InfluxDB que especifique o endpoint, a versão e as credenciais para sua instância do InfluxDB. AWS IoT Core valida a propriedade do endpoint antes de enviar tráfego. Consulte [Destino da ação do InfluxDB](#influxdb-action-destination). + **Uma função do IAM ** que AWS IoT pode assumir a gravação em seus bancos de dados do InfluxDB e realizar a `GetSecretValue` operação no segredo que armazena suas credenciais do InfluxDB. Para obter mais informações, consulte [Concedendo um AWS IoT regule o acesso que ele requer](iot-create-role.md). + **Credenciais do InfluxDB armazenadas em AWS Secrets Manager** — Para o InfluxDB V3, o Amazon Timestream for InfluxDB provisiona automaticamente um segredo do Secrets Manager quando você cria o cluster InfluxDB. O segredo contém as credenciais do cluster. Para o InfluxDB V2, gere um All Access ou um token de API personalizado a partir da sua instância do InfluxDB. Armazene o valor do token como um segredo de texto simples em. AWS Secrets Manager Para obter mais informações sobre a criação de tokens, consulte [ Criar um token ](https://docs.influxdata.com/influxdb/v2/admin/tokens/create-token/) na InfluxData documentação. Em tempo de execução, a ação da regra chama `secretsmanager:GetSecretValue` para recuperar essas credenciais antes da autenticação em seu endpoint InfluxDB. + **Carimbo de data/hora na carga da mensagem ** — Cada objeto na carga útil da mensagem deve conter uma chave chamada `timestamp` (com distinção entre maiúsculas e minúsculas) com um valor inteiro de época do Unix. A unidade de carimbo de data/hora também pode ser definida na definição da regra de IoT. AWS IoT Core não gera carimbos de data/hora para a ação do InfluxDB, exceto quando o InfluxDB é usado como uma ação de erro. **nota** Um alias como `ts` ou `time` não pode ser usado em vez de`timestamp`. + **Conectividade HTTPS ** — Sua instância do InfluxDB deve ser acessada por HTTPS. AWS IoT Core As portas de saída suportadas são: 443, 8443, 8086 (porta padrão para InfluxDB V2) e 8181 (porta padrão para InfluxDB V3). + **JSON-format payload ** — A ação do InfluxDB processa somente cargas JSON. Se seus dispositivos publicarem dados binários ou Protobuf, use a [`decode()`](binary-payloads.md#binary-payloads-protobuf) função em sua regra SQL para converter em JSON antes que a ação seja executada. ## Destino da ação do InfluxDB Antes de usar a ação de regra do InfluxDB, você deve criar um destino de ação do InfluxDB. O destino define os parâmetros de conexão para sua instância do InfluxDB. AWS IoT Core em seguida, valida a propriedade do endpoint. ### Criando um destino Use a `CreateTopicRuleDestination` API para criar um destino do 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 | Parâmetro | Tipo | Obrigatório | Descrição | | --- | --- | --- | --- | | endpoint | String | Sim | O URL do endpoint HTTPS da sua instância do InfluxDB. Não há suporte para HTTP. Portas suportadas: 443, 8086, 8181, 8443. | | influxDBVersion | String | Sim | A versão InfluxDB. Valores válidos: V2, V3. | | secretId | String | Sim | O nome ou ARN do AWS Secrets Manager segredo que contém seu token InfluxDB. | | secretType | String | Não | O tipo de valor secreto. Valores válidos: SecretString, SecretBinary. | | secretKey | String | Não | A chave dentro do JSON secreto que contém o token de autenticação. Exigido somente quando o segredo é um objeto JSON com várias chaves. | ### Validação da propriedade do endpoint Quando você cria um destino de ação do InfluxDB, AWS IoT Core valida a propriedade do endpoint autenticando-se na API do InfluxDB usando as credenciais que você forneceu: + **InfluxDB V2**: AWS IoT Core chama o endpoint. `/api/v2/me` + **InfluxDB V3**: AWS IoT Core chama o endpoint () do banco de dados da lista. `GET /api/v3/configure/database` Uma resposta bem-sucedida (2xx) define o status de destino como`ENABLED`. Em caso de falha, AWS IoT Core define o status como`ERROR`. Para tentar novamente a validação, ligue `UpdateTopicRuleDestination` com o status definido como. `IN_PROGRESS` ## Mapeamento de terminologia do InfluxDB Os termos a seguir diferem entre o InfluxDB V2 e V3. | AWS IoT Core parâmetro | Termo InfluxDB V2 | Termo InfluxDB V3 | | --- | --- | --- | | databaseName | Bucket | Banco de dados | | tableName | Medição | Tabela | **nota** Se você estiver migrando da ação de regra do Amazon Timestream, o `dimensions` parâmetro é mapeado para tags na ação do InfluxDB e os atributos do resultado da consulta são mapeados para campos. ## Parâmetros Ao criar uma AWS IoT regra com a ação InfluxDB, você deve especificar as seguintes informações: `destinationArn` O ARN do destino da ação do InfluxDB. Consulte [Destino da ação do InfluxDB](#influxdb-action-destination). Compatível com [modelos de substituição](iot-substitution-templates.md): Não `roleArn` O ARN da função do IAM que concede AWS IoT permissão para acessar o segredo do Secrets Manager. Consulte [Pré-requisitos](#influxdb-rule-action-prerequisites). Compatível com [modelos de substituição](iot-substitution-templates.md): Não `databaseName` O nome do banco de dados InfluxDB (chamado de * bucket * no InfluxDB v2 ou banco de * dados no InfluxDB v3) * no qual gravar registros. Suporta modelos [ de substituição](iot-substitution-templates.md): Não. Para rotear dados para bancos de dados diferentes, crie ações de regra separadas para cada banco de dados. `tableName` O nome da tabela (chamada de * medição * no InfluxDB v2 ou * tabela no InfluxDB v3) * na qual gravar registros. Compatível com [modelos de substituição](iot-substitution-templates.md): Sim. `organization` O nome da organização InfluxDB. Necessário para o InfluxDB v2. Se você incluir esse parâmetro para o InfluxDB v3, ele será ignorado. Suporta modelos [ de substituição](iot-substitution-templates.md): Não. `tags` Metadados para cada ponto, especificados como um mapa. Cada chave de mapa é um nome de tag, e cada valor de mapa é o valor de tag correspondente. As tags são indexadas para o desempenho da consulta. + No InfluxDB V3, cada nome de tag deve ser exclusivo em uma tabela e não pode duplicar um nome de campo. + Os valores das tags suportam modelos de substituição por elemento e escopo de mensagem. `timestampUnit` A precisão do valor do carimbo de data/hora na carga útil. Valores válidos: `s` (segundos) \| `ms` (milissegundos) \| `us` (microssegundos) \| `ns` (nanossegundos). Padrão: `ms`. Suporta modelos [ de substituição](iot-substitution-templates.md): Não. `batchConfig` Configuração de Server-side lote (opcional). Para obter mais informações, consulte [Agrupamento em lotes](#influxdb-rule-action-batching). + `maxBatchSize`— Número máximo de pontos em cada lote. Intervalo válido: 1—500. + `maxBatchOpenMs`— Tempo máximo em milissegundos para manter um lote aberto. Intervalo válido: 5—1.000. + `maxBatchSizeBytes`— Tamanho total máximo em bytes antes da descarga. Intervalo válido: 100—131.072. + `batchAcrossTopics` – Booleano. Quando`true`, o lote inclui pontos de mensagens sobre diferentes tópicos. Padrão: `false`. ## Agrupamento em lotes A ação do InfluxDB suporta dois modos de lote. ### Client-side dosagem Seu dispositivo de IoT agrupa dados de séries temporais como uma matriz JSON e os publica como uma única mensagem MQTT. Com o agrupamento em lote do lado do cliente, cada elemento da matriz se torna um ponto de protocolo de linha em uma única solicitação de gravação. Você não precisa de configuração adicional. ### Server-side dosagem Use o batching do lado do servidor para agrupar mensagens individuais antes de gravá-las no InfluxDB. Configure o agrupamento em lotes do lado do servidor usando o parâmetro. `batchConfig` O lote é liberado quando qualquer limite configurado (`maxBatchSize`,`maxBatchOpenMs`, ou`maxBatchSizeBytes`) é atingido primeiro. **nota** Tanto o lote do lado do servidor quanto o do lado do cliente (cargas da matriz JSON) podem ser configurados ao mesmo tempo. A ação do InfluxDB é medida com base no tamanho da carga útil de saída em incrementos de 5 KiB. Line-protocol as falhas de conversão também são medidas. ## Per-element modelos para cargas úteis de matriz Quando seus dispositivos de IoT enviam dados de séries temporais em lote como uma matriz JSON, você pode usar os ** “modelos de substituição por elemento” ** para resolver os valores de cada elemento de matriz individual. Isso encaminha cada ponto de dados para uma tabela diferente ou aplica tags específicas do elemento. Para obter mais informações, consulte [ Per-element modelos](https://docs.aws.amazon.com/iot/latest/developerguide/per-element-templates.html). ### Sintaxe de dois [modelos de substituição](iot-substitution-templates.md) + `${expression}`— Resolve no escopo da mensagem, em relação à mensagem recebida do dispositivo. Avaliado uma vez para cada mensagem; o mesmo valor se aplica a cada ponto na matriz. + `@{expression}`— Resolve no escopo do elemento, em relação a um elemento individual da carga produzida pela instrução SQL SELECT da regra. Re-evaluated para cada elemento da matriz, para que cada ponto possa obter um valor diferente. Para obter mais informações, consulte a [`@{expression}` referência](https://docs.aws.amazon.com/iot/latest/developerguide/per-element-expression.html). Use valores `@{...}` de entrada `tableName` e tag para resolver a expressão em cada elemento da matriz individualmente. ### Exemplo Dada a seguinte carga útil do dispositivo (matriz JSON): ``` [ {"measurement_type": "temperature", "room": "kitchen", "timestamp": 1700000000000, "value": 23.5}, {"measurement_type": "humidity", "room": "bedroom", "timestamp": 1700000001000, "value": 60.1} ] ``` E a seguinte configuração de ação: ``` { "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" } } ``` A saída do protocolo de linha resultante contém dois pontos: ``` temperature,room=kitchen value=23.5 1700000000000 humidity,room=bedroom value=60.1 1700000001000 ``` **nota** Um campo referenciado por `@{...}` é removido do conjunto de campos do protocolo de linha, portanto, ele também não aparece como um campo. Neste exemplo, `measurement_type` se torna o nome da tabela e `room` se torna uma tag, portanto, nenhum deles aparece no conjunto de campos — `value` é o único campo. ### Restrições + `@{...}`é suportado somente na configuração da ação do InfluxDB (`tableName`e nos valores das tags). + Você não pode usar `@{...}` em regras SQL (SELECT/WHEREcláusulas), definições de ações de erro ou qualquer outra ação de regra. + Somente referências de campo são suportadas internamente`@{...}`. As funções não são suportadas. + Cada valor suporta no máximo um `@{...}` marcador. Vários marcadores em um único valor produzem uma exceção de API. + Você não pode misturar `${...}` e `@{...}` ter o mesmo valor. A mistura produz uma exceção de API. + Um único objeto JSON é tratado como uma matriz de um elemento. ## Conteúdo de gravação do InfluxDB Para cada registro no resultado da consulta pós-SQL, o ponto de protocolo de linha do InfluxDB resultante contém esses componentes: | Componente | Fonte | | --- | --- | | Tabela | O valor tableName do parâmetro | | Tags | Os pares de valores-chave do parâmetro tags | | Campos | Atributos de carga útil restantes não usados como tags, nome da tabela ou carimbo de data/hora | | Timestamp | A timestamp chave extraída da carga | ### Conversão de tipo de dados AWS IoT Core converte valores JSON em tipos de protocolo de linha InfluxDB da seguinte forma: | Tipo JSON | Tipo de protocolo de linha | Exemplo | | --- | --- | --- | | Inteiro (−2⎯ ³ a 2⎯ ³−1) | Número inteiro assinado (isufixo) | 42 → 42i | | Inteiro (2³ a 2−1) | Número inteiro sem sinal (sufixo) u | 9223372036854775808 → 9223372036854775808u | | Inteiro externo (−2⎯ ³ a 2−1) | Rejeitado (ação de erro acionada) | — | | Flutuante/decimal | IEEE-754 flutuação de 64 bits | 23.5 → 23.5 | | Booleano | t ou f | true → t | | String | Cadeia de caracteres citada | "active" → "active" | | Null | Omitido (não escrito) | — | | Objeto ou matriz | Cadeia de caracteres JSON compactada (espaço em branco removido) | {"a":1} → "{\\"a\\":1}" | ### Restrições de nomeação + As chaves de campo e as chaves de tag não podem estar vazias nem começar com um sublinhado (`_`). + No InfluxDB V3, o nome da tabela e a chave da tag devem começar com uma letra ou dígito. + Vírgulas, sinais de igual e espaços nas teclas de campo, chaves de tag e valores de tag são escapados automaticamente. + Medidas: vírgulas e espaços são escapados automaticamente. + As tags são classificadas alfabeticamente por chave antes da serialização para melhorar o desempenho da ingestão. + Os valores de tag vazios são omitidos da saída. ### Chaves reservadas As seguintes chaves de carga útil são retiradas do conjunto de campos durante a conversão do protocolo de linha: + `timestamp`— Usado como carimbo de data/hora do ponto. + Chaves referenciadas por `tableName` (via `${...}` ou`@{...}`) — Usadas como nome da tabela. + Chaves referenciadas pelo valor da tag (via `${...}` ou`@{...}`) — Usadas como valores da tag. ## Ações de erro Se a ação do InfluxDB falhar, a ação de erro configurada será acionada. ### Usando o InfluxDB como uma ação de erro Você pode configurar a ação do InfluxDB como uma ação de erro para qualquer regra. Toda a carga útil é gravada em um único `tableName` registro. Message-scope modelos de substituição (`${...}`) são suportados na ação de erro `tableName` e. `tags` ### Saída da ação de erro Quando a ação de erro é acionada, a carga útil de saída contém: `ruleName` `topic``cloudwatchTraceId`,`clientId`,`sourceIp`,, `base64OriginalPayload` (mensagem Base64-encoded original) e uma `failures` matriz em que cada entrada tem `failedAction``failedResource`, e. `errorMessage` Com o batching do lado do servidor, a carga útil usa`payloadsWithMetadata`, com uma entrada para cada mensagem MQTT de entrada distinta. `affectedIds`Os valores de cada falha se referem aos `id` valores dessas entradas de mensagem; eles não são índices de pontos. Uma matriz JSON do lado do cliente é uma mensagem de entrada, embora produza vários pontos do InfluxDB. Para obter o formato completo da carga útil, consulte[Ações de erro para agrupamento em lote](http_batching.md#batching_errors). | Cenário de falha | Description | | --- | --- | | Destino DESATIVADO ou ERRO | O destino da ação do InfluxDB não está habilitado. Verifique se a validação da propriedade do endpoint foi bem-sucedida. | | ARN de destino inválido | O destino especificado não existe. | | ARN de função inválido | A função do IAM não existe ou não tem permissões. | | Falha na recuperação secreta | O segredo ou configurado secretKey não existe, ou a função de ação da regra não pode recuperar ou descriptografar o segredo. | | Carimbo de data/hora ausente | A carga não contém uma timestamp chave. Cada objeto na carga deve incluir um timestamp campo com um valor inteiro de época do Unix. | | Valor de carimbo de data/hora inválido | O valor do carimbo de data/hora não é um número inteiro (por exemplo, uma string, float ou data). ISO-8601 O valor deve ser uma época inteira do Unix na unidade especificada por. timestampUnit | | Carga útil inválida (sem campos) | A carga não contém campos válidos para o protocolo de linha após a remoção das chaves reservadas. | | Chave de campo inválida | Uma chave de campo está vazia ou começa com\_. | | O lote do cliente contém um ponto inválido | Um ou mais elementos em uma matriz JSON falharam na validação do protocolo de linha. | | Tags e campos excedem o limite de colunas | As teclas combinadas de tag e campo excedem a contagem máxima de colunas (250). | | Falha de conexão | AWS IoT Core não foi possível se conectar ao endpoint do InfluxDB. | | Falha na autenticação | O token InfluxDB é inválido ou expirou. Atualize o segredo em AWS Secrets Manager. | | Recurso não encontrado | O banco de dados, tabela ou organização especificado não existe no InfluxDB. | | Conflito de tipo de campo | Um ou mais campos entram em conflito com o esquema existente. A gravação em lote inteira falha. | | Erro no servidor InfluxDB | Ocorreu um erro interno no InfluxDB. | | Serviço InfluxDB indisponível | O InfluxDB está temporariamente indisponível. O Mecanismo de Regras tenta novamente com um recuo exponencial. | **Importante** Um conflito de tipo de campo em qualquer ponto de um lote faz com que toda a gravação do lote falhe. O InfluxDB não confirma pontos parcialmente — ou todos os pontos são bem-sucedidos ou toda a gravação é rejeitada. Erros que podem ser repetidos (503) são repetidos com recuo exponencial. Para uma resposta HTTP 401, AWS IoT Core recarrega o token AWS Secrets Manager e repete a solicitação uma vez. Non-retryable erros (404, 422) acionam a ação de erro imediatamente. Para limites de repetição, consulte cotas [AWS IoT Core](https://docs.aws.amazon.com/general/latest/gr/iot-core.html#limits_iot) de serviço. ## Exemplos ### Ação de regra do 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 da amostra: ** ``` { "timestamp": 1700000000000, "temperature": 23.5, "humidity": 60.1, "pressure": 1013.25, "battery_level": 87 } ``` **Protocolo de linha resultante: ** ``` device_metrics,device_id=myDevice123,location=building-a temperature=23.5,humidity=60.1,pressure=1013.25,battery_level=87i 1700000000000 ``` A ordem dos campos na saída pode variar — os campos não são classificados alfabeticamente. ### Client-batched carga útil de matriz com modelos 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 amostra (publicada em`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 linha 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 dosagem com InfluxDB Para adicionar lotes do lado do servidor a qualquer ação do InfluxDB, inclua na configuração da ação: `batchConfig` ``` "batchConfig": { "maxBatchSize": 50, "maxBatchOpenMs": 1000, "maxBatchSizeBytes": 65536, "batchAcrossTopics": false } ``` ### Política do IAM para a função de ação de regras **Política de confiança: ** ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": {"Service": "iot.amazonaws.com"}, "Action": "sts:AssumeRole" } ] } ``` **Política de permissão**: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "secretsmanager:GetSecretValue", "Resource": "arn:aws:secretsmanager:us-west-2:111122223333:secret:my-influxdb-secret-a1b2c3" } ] } ``` ### Combinação de lotes do lado do cliente e do lado do servidor (reordenação de pontos) Ao habilitar o lote do lado do cliente (cargas da matriz JSON) e o lote do lado do servidor (`batchConfig`), esteja ciente de que o lote do lado do servidor pode reordenar pontos de uma carga em lote do lado do cliente. O Mecanismo de Regras acumula pontos de várias mensagens recebidas em um único lote do lado do servidor. Como as mensagens chegam de forma assíncrona de diferentes dispositivos ou tópicos, os pontos que foram ordenados dentro da carga útil original do cliente podem ser intercalados com pontos de outras mensagens na gravação final. Configuração da ação: ``` { "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 } } } ``` O dispositivo A publica `devices/deviceA/telemetry` no 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} ] ``` O dispositivo B publica até `devices/deviceB/telemetry` no momento T\+10ms: ``` [ {"measurement_type": "temperature", "floor": "3", "timestamp": 1700000000050, "value": 21.8}, {"measurement_type": "humidity", "floor": "3", "timestamp": 1700000000150, "value": 62.3} ] ``` Ambas as mensagens chegam dentro da janela de lote de 500 ms (`maxBatchOpenMs`), então o Mecanismo de Regras combina todos os cinco pontos em um único lote do lado do servidor. Protocolo de linha resultante (gravação em lote no lado do 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 os pontos não estão mais na ordem em que apareceram na carga útil de cada cliente. Os três pontos do Dispositivo A (timestamps 1700000000000, 1700000000100, 1700000000200) são intercalados com os dois pontos do Dispositivo B (timestamps 1700000000050, 1700000000150). O lote do lado do servidor não garante o pedido original em cada mensagem. O InfluxDB usa o campo timestamp para colocar cada ponto na linha do tempo, portanto, a reordenação não afeta a correção da consulta. No entanto, se seu aplicativo depende da semântica de ordem de gravação (por exemplo, lidar com conflitos de tipo de campo ou desduplicação de última gravação ganha no mesmo milissegundo), esteja ciente de que a ordem de gravação efetiva pode ser diferente da ordem de publicação.