Configurações recomendadas para clientes Apache Kafka
Aqui estão as configurações recomendadas para usar Hubs de Eventos do Azure de aplicativos cliente Apache Kafka.
Propriedade | Valores recomendados | Intervalo permitido | Observações |
---|---|---|---|
metadata.max.age.ms |
180000 (aproximado) | < 240000 | Pode ser rebaixado para buscar alterações de metadados mais cedo. |
connections.max.idle.ms |
180000 | < 240000 | O Azure fecha o TCP (Protocolo de Controle de Transmissão) de entrada ocioso > em 240.000 ms, o que pode resultar no envio de conexões inativas (mostradas como lotes expirados devido ao tempo limite de envio). |
Configurações de produtor podem ser encontradas aqui.
Propriedade | Valores recomendados | Intervalo permitido | Observações |
---|---|---|---|
max.request.size |
1.000.000 | < 1046528 | O serviço fecha conexões se solicitações maiores que 1.046.528 bytes forem enviadas. Esse valor deve ser alterado e causa problemas em cenários de produção de alta taxa de transferência. |
retries |
> 0 | Pode exigir o aumento do valor delivery.timeout.ms, consulte a documentação. | |
request.timeout.ms |
30000 .. 60000 | > 20000 | Os Hubs de Eventos usam internamente como padrão um mínimo de 20.000 ms. Embora as solicitações com valores de tempo-de-tempo mais baixos sejam aceitas, o comportamento do cliente não é garantido. Verifique se o request.timeout.ms tem no mínimo o valor recomendado de 60000 e o session.timeout.ms tem no mínimo o valor recomendado de 30000. Ter essas configurações com valores muito baixos pode fazer com que os consumidores atinjam o tempo limite, o que causa redistribuições (que fazem com que mais tempos limites sejam atingidos, o que causa mais redistribuições e assim por diante). |
metadata.max.idle.ms |
180000 | > 5000 | Controla por quanto tempo o produtor armazena em cache os metadados de um tópico ocioso. Se o tempo decorrido desde que um tópico foi produzido pela última vez exceder a duração ociosa de metadados, os metadados do tópico serão esquecidos e o próximo acesso a ele forçará uma solicitação de busca de metadados. |
linger.ms |
> 0 | Para cenários de alta taxa de transferência, o valor persistente deve ser igual ao valor mais alto tolerável para aproveitar o envio em lote. | |
delivery.timeout.ms |
Defina conforme a fórmula (request.timeout.ms + linger.ms ) * retries . |
||
compression.type |
uncompressed, gzip |
No momento, apenas a compactação gzip é suportada. |
Configurações de consumidor podem ser encontradas aqui.
Propriedade | Valores recomendados | Intervalo permitido | Observações |
---|---|---|---|
heartbeat.interval.ms |
3000 | 3000 é o valor padrão e não deve ser alterado. | |
session.timeout.ms |
30000 | 6000 .. 300000 | Comece com 30000 e aumente se houver reequilíbrio frequente devido a pulsações perdidas. Verifique se o request.timeout.ms tem no mínimo o valor recomendado de 60000 e o session.timeout.ms tem no mínimo o valor recomendado de 30000. Ter essas configurações com valores muito baixos pode fazer com que os consumidores atinjam o tempo limite, o que causa redistribuições (que fazem com que mais tempos limites sejam atingidos, o que causa mais redistribuições e assim por diante). |
max.poll.interval.ms |
300000 (padrão) | >session.timeout.ms | Usado para tempo limite de rebalanceamento, portanto, não deve ser definido muito baixo. Precisa ser maior que session.timeout.ms. |
O arquivo de configuração principal librdkafka
(link) contém descrições estendidas para as propriedades descritas nas seções a seguir.
Propriedade | Valores recomendados | Intervalo permitido | Observações |
---|---|---|---|
socket.keepalive.enable |
verdadeiro | Necessário se for esperado que a conexão esteja ociosa. O Azure fecha a ociosidade TCP de entrada de > 240.000 ms. | |
metadata.max.age.ms |
~180000 | < 240000 | Pode ser rebaixado para buscar alterações de metadados mais cedo. |
Propriedade | Valores recomendados | Intervalo permitido | Observações |
---|---|---|---|
retries |
> 0 | O padrão é 2147483647. | |
request.timeout.ms |
30000 .. 60000 | > 20000 | Os Hubs de Eventos usam internamente como padrão um mínimo de 20.000 ms. librdkafka o valor padrão é 5000, o que pode ser problemático. Embora as solicitações com valores de tempo-de-tempo mais baixos sejam aceitas, o comportamento do cliente não é garantido. |
partitioner |
consistent_random |
Confira a documentação do librdkafka | consistent_random é padrão e melhor. Chaves vazias e nulas são manipuladas idealmente para a maioria dos casos. |
compression.codec |
none, gzip |
No momento, apenas a compactação gzip é suportada. |
Propriedade | Valores recomendados | Intervalo permitido | Observações |
---|---|---|---|
heartbeat.interval.ms |
3000 | 3000 é o valor padrão e não deve ser alterado. | |
session.timeout.ms |
30000 | 6000 .. 300000 | Comece com 30000 e aumente se houver reequilíbrio frequente devido a pulsações perdidas. |
max.poll.interval.ms |
300000 (padrão) | >session.timeout.ms | Usado para tempo limite de rebalanceamento, portanto, não deve ser definido muito baixo. Precisa ser maior que session.timeout.ms. |
Confira a tabela a seguir de cenários de erro comuns relacionados à configuração.
Sintomas | Problema | Solução |
---|---|---|
Falhas de confirmação de deslocamento devido ao reequilíbrio | Seu consumidor está esperando muito tempo entre chamadas para poll() e o serviço está expulsando o consumidor do grupo. | Você tem várias opções:
|
Exceções de rede com taxa de transferência de alta produtividade | Se você estiver usando o cliente Java + max.request.size padrão, suas solicitações podem ser muito grandes. | Consulte as configurações do Java mencionadas anteriormente. |
Consulte Limites, cotas e restrições de assinatura e serviço do Azure para cotas e limites de todos os serviços do Azure.