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 protocole TCP (Transmission Control Protocol) inactif > 240 000 ms, ce qui peut entraîner l’envoi sur des connexions mortes (indiqués comme des lots expirés en raison du délai d’attente 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 requêtes supérieures à 1 046 528 octets sont envoyées. Cette valeur doit être modifiée et provoque des problèmes dans des scénarios de production à débit élevé. |
retries |
> 0 | Peut nécessiter une augmentation de delivery.timeout.ms valeur, consultez la documentation. | |
request.timeout.ms |
30000 60000 | > 20000 | Event Hubs est défini en interne sur un minimum de 20 000 ms. Si des demandes avec des valeurs de délai d’expiration inférieures sont 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 d’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 |
uncompressed, gzip |
Seule la compression gzip est actuellement 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, il ne doit donc pas être défini trop bas. Doit être supérieur à session.timeout.ms. |
Propriétés de configuration de librdkafka
Le fichier de configuration principal librdkafka (lien) contient des descriptions étendues des propriétés décrites dans les sections suivantes.
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 ferme 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 |
> 0 | Valeur par défaut : 2147483647. | |
request.timeout.ms |
30000 60000 | > 20000 | Event Hubs est défini en interne sur un minimum de 20 000 ms. 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, gzip |
Seule la compression gzip est actuellement 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, il ne doit donc 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 avez plusieurs options :
|
| Exceptions réseau à un débit de production élevé | Si vous utilisez le client Java + max.request.size par défaut, vos requêtes peuvent être trop volumineuses. | Consultez les configurations Java mentionnées précédemment. |
Étapes suivantes
Pour connaître les quotas et limites de tous les services Azure, consultez Abonnement Azure et limites, quotas et contraintes de service.