Configurations recommandées pour les clients Apache Kafka
Voici les configurations recommandées pour l’utilisation d’Azure Event Hubs à partir d’applications clientes Apache Kafka.
Propriétés de configuration de client Java
Configurations de producteur et de consommateur
| Propriété | Valeurs recommandées | Plage autorisée | Notes |
|---|---|---|---|
metadata.max.age.ms |
180000 (approximation) | < 240000 | Peut être abaissé pour récupérer les modifications de métadonnées plus tôt. |
connections.max.idle.ms |
180000 | < 240000 | Azure ferme le TCP entrant inactif > 240 000 ms, ce qui peut entraîner un envoi sur des connexions mortes (affichées comme des lots arrivés à expiration en raison du délai d’expiration d’envoi). |
Configurations du producteur uniquement
Les configurations de producteur se trouvent ici.
| Propriété | Valeurs recommandées | Plage autorisée | Notes |
|---|---|---|---|
max.request.size |
1000000 | < 1046528 | Le service ferme les connexions si les demandes envoyées dépassent 1 046 528 octets. Cette valeur doit être modifiée et provoquera des problèmes dans les scénarios de production à haut débit. |
retries |
> 0 | Peut nécessiter une augmentation de la valeur delivery.timeout.ms, voir la documentation. | |
request.timeout.ms |
30000 60000 | > 20000 | La valeur d’Event Hubs en interne sera au minimum de 20 000 ms par défaut. Bien que des demandes avec des valeurs de délai d’expiration inférieures soient acceptées, le comportement du client n’est pas garanti. Assurez-vous que la valeur de request.timeout.ms correspond au moins à la valeur recommandée de 60 000, et que la valeur de session.timeout.ms correspond au moins à la valeur recommandée de 30 000. Des valeurs trop basses pour ces paramètres peuvent occasionner des délais d’attente pour les consommateurs, entraînant des rééquilibrages (et donc des délais d’attente supplémentaires entraînant davantage de rééquilibrages, etc.). |
metadata.max.idle.ms |
180000 | > 5000 | Contrôle la durée pendant laquelle le producteur met en cache les métadonnées pour une rubrique inactive. Si le temps écoulé depuis la dernière production d’une rubrique dépasse la durée d’inactivité des métadonnées, les métadonnées de la rubrique sont oubliées et l’accès suivant à celles-ci force une demande d’extraction des métadonnées. |
linger.ms |
> 0 | Pour les scénarios à haut débit, la valeur de linger doit être égale à la valeur tolérable la plus élevée pour tirer parti du traitement par lot. | |
delivery.timeout.ms |
Définissez la valeur en fonction de la formule (request.timeout.ms + linger.ms) * retries. |
||
compression.type |
none |
Compression actuellement non prise en charge. |
Configurations de consommateur uniquement.
Les configurations de consommateur se trouvent ici.
| Propriété | Valeurs recommandées | Plage autorisée | Notes |
|---|---|---|---|
heartbeat.interval.ms |
3000 | 3000 est la valeur par défaut qui ne doit pas être modifiée. | |
session.timeout.ms |
30000 | 6000 300000 | Commencez par 30000, et augmentez si vous constatez des rééquilibrages fréquents en raison de pulsations manquées. Assurez-vous que la valeur de request.timeout.ms correspond au moins à la valeur recommandée de 60 000, et que la valeur de session.timeout.ms correspond au moins à la valeur recommandée de 30 000. Des valeurs trop basses pour ces paramètres peuvent occasionner des délais d’attente pour les consommateurs, entraînant des rééquilibrages (et donc des délais d’attente supplémentaires entraînant davantage de rééquilibrages, etc.). |
max.poll.interval.ms |
300 000 (par défaut) | >session.timeout.ms | Utilisé pour rééquilibrer le délai d’expiration, donc cela ne doit pas être défini trop bas. Doit être supérieur à session.timeout.ms. |
Propriétés de configuration de librdkafka
Le fichier de configuration librdkafka principal (link) contient des descriptions étendues des propriétés ci-dessous.
Configurations de producteur et de consommateur
| Propriété | Valeurs recommandées | Plage autorisée | Notes |
|---|---|---|---|
socket.keepalive.enable |
true | Nécessaire si la connexion est censée être inactive. Azure va fermer le TCP inactif entrant > 240 000 ms. | |
metadata.max.age.ms |
180000 | < 240000 | Peut être abaissé pour récupérer les modifications de métadonnées plus tôt. |
Configurations du producteur uniquement
| Propriété | Valeurs recommandées | Plage autorisée | Notes |
|---|---|---|---|
retries |
2 | Valeur par défaut : 2147483647. | |
request.timeout.ms |
30000 60000 | > 20000 | La valeur d’Event Hubs en interne sera au minimum de 20 000 ms par défaut. La valeur par défaut de librdkafka est 5000, ce qui peut être problématique. Si des demandes avec des valeurs de délai d’expiration inférieures sont acceptées, le comportement du client n’est pas garanti. |
partitioner |
consistent_random |
Consultez la documentation de librdkafka | consistent_random est la valeur par défaut et la meilleure. Dans la plupart des cas, les clés vides et NULL sont gérées de façon idéale. |
compression.codec |
none |
Compression actuellement non prise en charge. |
Configurations de consommateur uniquement.
| Propriété | Valeurs recommandées | Plage autorisée | Notes |
|---|---|---|---|
heartbeat.interval.ms |
3000 | 3000 est la valeur par défaut qui ne doit pas être modifiée. | |
session.timeout.ms |
30000 | 6000 300000 | Commencez par 30000, et augmentez si vous constatez des rééquilibrages fréquents en raison de pulsations manquées. |
max.poll.interval.ms |
300 000 (par défaut) | >session.timeout.ms | Utilisé pour rééquilibrer le délai d’expiration, donc cela ne doit pas être défini trop bas. Doit être supérieur à session.timeout.ms. |
Autres remarques
Consultez le tableau suivant des scénarios d’erreur courantes liées à la configuration.
| Symptômes | Problème | Solution |
|---|---|---|
| Échecs de validation de décalage en raison du rééquilibrage | Votre consommateur attend trop longtemps entre les appels à poll(), et le service éjecte le consommateur du groupe. | Vous disposez de plusieurs options :
|
| Exceptions réseau à un débit de production élevé | Utilisez-vous le client Java + valeur de max.request.size par défaut ? Vos demandes sont peut-être trop volumineuses. | Consultez les configurations Java ci-dessus. |
Étapes suivantes
Pour connaître les quotas et limites de tous les services Azure, consultez Abonnement Azure et limites, quotas et contraintes de service.