Foire aux questions sur Event Streams
Ce document contient des informations sur les questions ou problèmes courants rencontrés par les utilisateurs du service IBM® Event Streams for IBM Cloud®. Il répond aux questions ou fournit des instructions permettant de résoudre les problèmes sans avoir à créer un ticket de demande de service.
Comment utiliser des API Kafka pour créer et supprimer des rubriques ?
Si vous utilisez la version 0.11 ou une version ultérieure du client Kafka, ou la version 0.10.2.0 ou une version ultérieure de Kafka Streams, vous pouvez employer des API pour créer et supprimer des rubriques. Certaines restrictions s'appliquent aux paramètres autorisés lors de la création des rubriques. Actuellement, vous ne pouvez modifier que les paramètres suivants :
- cleanup.policy
-
Défini sur
delete(par défaut),compactoudelete,compact - retention.ms
-
La durée de conservation par défaut est de 24 heures. La durée minimale est d'une heure et la durée maximale de 30 jours. Spécifiez cette valeur comme un nombre d'heures.
Remarque : Dans le plan Enterprise, vous pouvez le définir sur n'importe quelle valeur.
- retention.bytes
-
Taille maximale que peut atteindre une partition (constituée de segments de journaux) avant suppression des anciens segments de journaux afin de libérer de l'espace.
Remarque : Entreprise : valeur comprise entre 100 Kio et 2 Tio. Standard : valeur comprise entre 100 Kio et 1 Gio.
- segment.bytes
-
Taille du fichier de segments du journal.
Remarque : Entreprise : valeur comprise entre 100 Kio et 2 Tio. Standard : valeur comprise entre 100 Kio et 512 Mio.
- segment.index.bytes
-
La taille de l'index qui met en correspondance des décalages et des positions de fichier.
Remarque : Entreprise : valeur comprise entre 100 Kio et 1 Tio. Standard : valeur comprise entre 100 KiB et 100 Mio.
- segment.ms
-
La période de temps après laquelle Kafka force le journal reprendre l'enregistrement par écrasement des segments les plus anciens même si le fichier de segments n'est pas plein.
Remarque : Définis sur n'importe quelle valeur comprise entre 5 minutes et 30 jours.
Consultez l'exemple suivant de paramètres de valeur par défaut.
Details for topic testit
Topic name Internal? Partition count Replication factor
testit false 1 3
Partition details for topic testit
Partition ID Leader Replicas In-sync
0 1 [1 5 0] [1 5 0]
Configuration parameters for topic testit
Name Value
cleanup.policy delete
min.insync.replicas 2
segment.bytes 536870912
retention.ms 86400000
segment.ms 604800000
retention.bytes 1073741824
segment.index.bytes 10485760
Quelle est la durée que Event Streams définit dans la fenêtre de conservation des journaux pour la rubrique Décalages consommateur ?
Event Streams conserve les décalages consommateur pendant 7 jours. Cela correspond à la configuration Kafka offsets.retention.minutes.
La conservation des décalages s'effectue au niveau du système. Vous ne pouvez donc pas la définir au niveau d'une rubrique spécifique. Les groupes de consommateurs n'obtiennent que 7 jours de décalages stockés, même en utilisant une rubrique dont la durée de conservation a été augmentée jusqu'au maximum de 30 jours.
La rubrique interne Kafka __consumer_offsets est visible en lecture seule sur le plan Enterpise. Nous vous conseillons vivement de ne tenter en aucune manière de gérer cette rubrique. Vous ne pouvez pas accéder à la rubrique __consumer_offsets de quelque façon que ce soit sur le plan Standard.
Comment puis-je nettoyer un groupe de consommateurs sans consommateurs ?
Une fois que les consommateurs ont quitté un groupe, ce dernier continue à exister uniquement s'il contient des positions. Les positions des consommateurs sont supprimées après 7 jours d'inactivité. Par conséquent, un groupe de consommateurs est supprimé lorsque la dernière position validée pour ce groupe arrive à expiration.
Si vous souhaitez supprimer explicitement un groupe à un moment précis, vous pouvez utiliser l'API deleteConsumerGroups() ou la commande ibmcloud es group-delete
Pendant combien de temps les messages sont-ils conservés ?
Par défaut, les messages sont conservés dans Kafka pendant 24 heures maximum et chaque partition ne peut pas dépasser 1 Go. Si le plafond de 1 Go est atteint, les messages les plus anciens sont supprimés pour que la limite soit respectée.
Vous pouvez modifier la durée de conservation des messages lorsque vous créez une rubrique à l'aide de l'interface utilisateur ou de l'API d'administration. La limite de temps a un minimum d'une heure et un maximum de 30 jours.
Pour obtenir des informations sur les restrictions concernant les paramètres autorisés lorsque vous créez des rubriques à l'aide d'un client Kafka ou de Kafka Streams, voir Comment utiliser des API Kafka pour créer et supprimer des rubriques ?
Quel est le comportement en disponibilité de Event Streams ?
Si vous écrivez des applications Event Streams, ces informations vous expliquent le comportement normal en disponibilité de Event Streams et ce que vos applications sont censées traiter.
API
Dans le cadre du fonctionnement normal de Event Streams, les noeuds des clusters Kafka sont parfois redémarrés. Dans certains cas, vos applications sont conscientes de la réaffectation des ressources par le cluster. Ecrivez vos applications de telle sorte qu'elles soient résilientes face à ces changements et qu'elles puissent se reconnecter et reprendre leur fonctionnement.
Quelle est la taille de message maximale de Event Streams ?
La taille de message maximale de Event Streams est 1 Mo, qui est la valeur par défaut Kafka.
Quels sont les paramètres de réplication de Event Streams ?
Event Streams est configuré de manière à offrir une forte disponibilité et durabilité. Les paramètres de configuration suivants s'appliquent à toutes les rubriques et ne sont pas modifiables :
- replication.factor = 3
- min.insync.replicas = 2
Quelles sont les restrictions et les valeurs par défaut pour les rubriques et les partitions ?
- Les noms de rubrique sont limités à un maximum de 200 caractères.
- Le nombre par défaut de partitions pour une rubrique est un.
- Chaque espace IBM Cloud est soumis à une limite de 100 partitions. Si vous voulez créer des partitions supplémentaires, vous devez utiliser un nouvel espace IBM Cloud.
Comment vérifier le type de plan Event Streams mis à disposition ?
Pour confirmer le type de plan Event Streams que vous avez approvisionné (Lite, Standard ou Enterprise), procédez comme suit :
- Dans la console IBM Cloud, accédez à l'instance du plan Event Streams que vous voulez vérifier.
- Cliquez sur l'onglet Plan dans le panneau de navigation de gauche. La section relative à votre plan actuel indique votre type de plan.
Puis-je modifier mon plan Event Streams en utilisant la console IBM Cloud ?
Oui, mais uniquement si vous vous passez du plan Lite au plan Standard.
-
Dans la console IBM Cloud, accédez à l'instance du plan Lite Event Streams que vous voulez changer.
-
Cliquez sur l'onglet Plan dans le panneau de navigation de gauche.
-
Dans la section Changer de plan de tarification, cochez la case Standard. Cliquez sur Upgrade.
Attendez quelques minutes pour que la limite de mise en cache passe de 1 partition (plan Lite) à 100 partitions (plan Standard).
Sachez toutefois que cette option ne fonctionne pas actuellement dans la console IBM Cloud pour toute autre combinaison de plans. Par exemple, si vous essayez une combinaison de plans différente, vous verrez un message d'erreur comme celui-ci :
Could not find VCAP::CloudController::ServicePlan with guid: ibm.eventstreams.standard
Quelles sont les différences entre le plan Standard de Event Streams et le plan Enterprise de Event Streams ?
Pour en savoir plus sur les différents plans de Event Streams, voir Choix d'un plan.
Comment doit-on traiter les reprises après incident ?
Actuellement, il est de la responsabilité de l'utilisateur de gérer sa propre reprise après incident pour Event Streams. Les données Event Streams peuvent être répliquées entre une instance Event Streams dans un emplacement (région) et une autre instance dans un autre emplacement. Cependant, l'utilisateur est responsable de mettre à disposition une instance Event Streams à distance et de gérer la réplication.
Il est conseillé d'utiliser un outil comme Kafka MirrorMaker pour répliquer les données entre les clusters. Pour plus d'informations sur l'exécution de MirrorMaker, voir Event Streams référentiel kafka-mirrormaker. Pour un exemple de processus de reprise, voir Utilisation de la mise en miroir dans un scénario de reprise après incident.
L'utilisateur est également responsable de la sauvegarde des données de la charge de message. Bien que ces données soient répliquées sur plusieurs courtiers Kafka au sein d'un cluster, ce qui évite la majorité des pannes, cette réplication ne couvre pas les pannes qui se produisent au niveau de l'emplacement. Il est recommandé aux utilisateurs de sauvegarder les noms des rubriques et les données de configuration de ces rubriques.
Si vous avez configuré votre instance Event Streams dans une région à zones multiples, un incident régional est très improbable. Il est toutefois recommandé aux utilisateurs de prévoir une telle circonstance. Si l'instance d'un utilisateur n'est plus disponible en raison d'un incident (et qu'une instance de reprise après incident distante n'est pas déjà configurée), l'utilisateur doit envisager de configurer une nouvelle instance dans une nouvelle région et de restaurer les rubriques et les données de la sauvegarde, le cas échéant. Les applications peuvent ensuite être pointées vers la nouvelle instance.