Le service Oracle Cloud Infrastructure (OCI) Streaming représente une solution de messagerie entièrement gérée, évolutive et durable qui permet d’ingérer des flux de données continus et de grand volume que vous pouvez consommer et traiter en temps réel. Streaming est disponible dans toutes les régions Oracle Cloud Infrastructure prises en charge. Pour en obtenir une liste, consultez la page Régions et domaines de disponibilité.
Streaming est un service sans serveur qui décharge la gestion de l’infrastructure allant de la mise en réseau au stockage et à la configuration nécessaire pour diffuser vos données en continu. Vous n’avez pas à vous soucier de la mise en place de l’infrastructure, de la maintenance continue ou des correctifs de sécurité. Le service Streaming réplique de manière synchrone les données dans trois domaines de disponibilité, ce qui assure une haute disponibilité et la durabilité des données. Dans les régions ayant un seul domaine de disponibilité, les données sont reproduites dans trois domaines de défaillance.
Streaming facilite la collecte, le stockage et le traitement des données générées en temps réel à partir de centaines de sources. Le nombre de cas d’utilisation est presque illimité, allant de la messagerie au traitement de flux de données complexes. Voici quelques-unes des nombreuses utilisations possibles du service Streaming :
Vous pouvez commencer à utiliser Streaming comme suit :
Vous pouvez également utiliser les API Kafka pour produire et consommer à partir d’un flux. Pour plus d’informations, reportez-vous à la section Utilisation de Streaming avec Apache Kafka.
Le débit de Streaming est conçu pour évoluer sans limites en ajoutant des partitions à un flux. Cependant, il y a certaines limites à garder à l’esprit lors de l’utilisation de Streaming :
Streaming fournit une sémantique basée sur les flux. La sémantique des flux offre des garanties strictes d’ordonnancement par partition, de rejouabilité des messages, de curseurs côté client et d’échelle horizontale massive de débit. Les files d’attente n’offrent pas ces fonctionnalités. Les files d’attente peuvent être conçues pour fournir des garanties de commande si l’on utilise des files d’attente FIFO, mais uniquement au prix d’un surcoût important en termes de performances.
Un flux est un journal de messages cloisonné, en annexe seulement, dans lequel les applications des producteurs écrivent des données et dans lequel les applications des consommateurs lisent des données.
Un pool de flux est un regroupement que vous pouvez utiliser pour organiser et gérer les flux. Les pools de flux offrent une facilité opérationnelle en offrant la possibilité de partager les paramètres de configuration sur plusieurs flux. Par exemple, les utilisateurs peuvent partager des paramètres de sécurité tels que des clés de chiffrement personnalisées sur le pool de flux pour chiffrer les données de tous les flux à l’intérieur du pool. Un pool de flux vous permet également de créer un point de terminaison privé pour les flux en limitant l’accès Internet à tous les flux d’un pool de flux. Pour les clients utilisant la fonctionnalité de compatibilité Kafka de Streaming, le pool de flux sert de racine d’un cluster Kafka virtuel, permettant ainsi à chaque action sur ce cluster virtuel d’être étendue à ce pool de flux.
Une partition est une unité de débit de base qui permet une mise à l'échelle horizontale et un parallélisme de la production et de la consommation à partir d’un flux. Une partition offre une capacité d’entrée de données de 1 Mo/s et de sortie de données de 2 Mo/s. Lorsque vous créez un flux, vous spécifiez le nombre de partitions dont vous avez besoin en fonction des exigences de débit de votre application. Par exemple, si vous créez un flux avec 10 partitions, vous pouvez atteindre un débit de 10 Mo/s d’entrée et de 20 Mo/s de sortie. Si vous avez besoin de partitions dépassant les limites de service existantes, Streaming anticipe une utilisation minimale de 10 Go par heure (requêtes PUT et GET) pour chaque tranche de 50 partitions utilisées. Vous serez facturé pour l'utilisation minimale prévue même si l'utilisation réelle est inférieure à ce tarif.
Un message est une unité de données codées en base64 et stockées dans un flux. La taille maximale d’un message que vous pouvez produire sur une partition d’un flux est de 1 Mo.
Une clé est un identifiant utilisé pour regrouper les messages associés. Les messages ayant la même clé sont écrits sur la même partition. Streaming garantit que tout consommateur d’une partition donnée lira toujours les messages de cette partition exactement dans le même ordre qu’ils ont été écrits.
Un producteur est une application client qui peut écrire des messages sur un flux.
Un consommateur est une application client qui peut lire des messages à partir d’un ou plusieurs flux. Un groupe de consommateurs est un ensemble d’instances qui coordonne les messages de toutes les partitions d’un flux. À tout moment, les messages d’une partition spécifique ne peuvent être consommés que par un seul consommateur du groupe.
Un curseur est un pointeur vers un emplacement dans un flux. Cet emplacement peut être un pointeur vers un décalage ou un temps spécifique dans une partition, ou vers l’emplacement actuel d’un groupe.
Chaque message au sein d’une partition possède un identifiant appelé décalage. Les consommateurs peuvent lire les messages à partir d’un décalage spécifique et sont autorisés à lire à partir de n’importe quel point de décalage de leur choix. Les consommateurs peuvent également valider le dernier décalage traité afin de reprendre leur travail sans répéter ni manquer un message en cas d’arrêt et de redémarrage.
Streaming assure le cryptage des données par défaut, tant au repos qu’en transit. Le streaming est entièrement intégré à Oracle Cloud Infrastructure Identity and Access Management (IAM), qui vous permet d’utiliser les stratégies d’accès pour accorder de manière sélective des autorisations aux utilisateurs et groupes d’utilisateurs. Tout en utilisant les API REST, vous pouvez également PUT et GET en toute sécurité vos données à partir de Streaming via des points de terminaison SSL avec le protocole HTTPS. De plus, Streaming permet une isolation complète des données au niveau du locataire sans aucun problème de « voisinage bruyant ».
Les données Streaming sont cryptées au repos et en transit, tout en garantissant l’intégrité des messages. Vous pouvez laisser Oracle gérer le cryptage, ou utiliser Oracle Cloud Infrastructure Vault pour stocker et gérer en toute sécurité vos propres clés de cryptage si vous devez respecter des normes de conformité ou de sécurité spécifiques.
Vous pouvez modifier les paramètres de cryptage des données du pool de flux à tout moment si vous souhaitez passer de l’utilisation du « cryptage fourni par les clés Oracle » au « cryptage géré à l’aide de clés gérées par le client ». Streaming n’impose aucune restriction quant au nombre de fois que cette activité peut être effectuée.
Streaming est entièrement intégré à Oracle Cloud Infrastructure IAM. Chaque flux a un compartiment assigné. Les utilisateurs peuvent spécifier des stratégies de contrôle d’accès basées sur les rôles qui peuvent être utilisées pour décrire des règles précises au niveau de la location, du compartiment ou du flux unique.
La stratégie d'accès est spécifiée sous la forme "Autoriser <subject> à <verb> <resource-type> dans <location> où <conditions>".
L’authentification avec le protocole Kafka utilise des jetons d’authentification et le mécanisme SASL/PLAIN. Vous pouvez générer des jetons sur la page des détails de l’utilisateur de la console. Pour plus d’informations, consultez la section Utilisation des jetons d’authentification. Nous vous recommandons de créer un groupe/utilisateur dédié et d’accorder à ce groupe l’autorisation de gérer les flux dans le compartiment ou la location appropriés. Vous pouvez ensuite générer un jeton d’authentification pour l’utilisateur que vous avez créé et l’utiliser dans la configuration de votre client Kafka.
Les points de terminaison privés limitent l’accès à un réseau Cloud virtuel (VCN) spécifique au sein de votre location, de sorte que ses flux ne sont pas accessibles via Internet. Les points de terminaison privés associent une adresse IP privée dans un VCN au pool de flux, ce qui permet au trafic Streaming d’éviter de traverser Internet. Pour créer un point de terminaison privé pour Streaming, vous devez accéder à un VCN avec un sous-réseau privé lorsque vous créez le pool de flux. Pour plus d’informations, consultez les sections À propos des points de terminaison privés et VCN et sous-réseaux.
Vous pouvez écrire le contenu d’un flux directement dans un compartiment Object Storage, généralement pour conserver les données dans le flux pour un stockage à long terme. Cela peut être réalisé en utilisant Kafka Connect pour S3 avec Streaming. Pour plus d’informations, consultez l’article de blog Publication sur Object Storage à partir d’Oracle Streaming Service.
Vous pouvez ingérer des données à partir d’une table dans une instance Oracle Autonomous Transaction Processing. Pour plus d’informations, consultez l’article de blog Utilisation de Kafka Connect avec Oracle Streaming Service et Autonomous DB.
Vous pouvez utiliser les SDK Kafka pour produire et consommer des messages à partir de Streaming, et vous pouvez utiliser la prise en charge intégrée de Micronaut pour Kafka. Pour plus d’informations, consultez l’article de blog Messagerie facile avec le support Kafka de Micronaut et Oracle Streaming Service.
Pour plus d’informations, consultez l’article de blog Ingérer les données IoT des courtiers MQTT dans OCI-Oracle Streaming Service, OCI- Kafka Connect Harness et Oracle Kubernetes Engine.
Oracle GoldenGate for Big Data est désormais certifié pour s’intégrer à Streaming. Pour plus d’informations, consultez la section Connexion à Oracle Streaming Service dans la documentation Oracle GoldenGate for Big Data.
Vous devez utiliser Kafka JDBC Sink Connect pour transporter directement les données en streaming dans Oracle Autonomous Data Warehouse.
Streaming utilise une tarification simple à l’utilisation, qui garantit que vous ne payez que les ressources utilisées. Les dimensions de la tarification comprennent
Pour utiliser des partitions supérieures aux limites de service par défaut, l'utilisation minimale attendue est de 10 Go par heure (requêtes PUT et GET) pour 50 partitions. Si votre utilisation réelle est inférieure à l'utilisation minimale attendue, vous serez facturé pour l'utilisation minimale attendue.
Veuillez consulter la page produit Streaming pour connaître les dernières informations sur les prix.
Le modèle de tarification de Streaming de pointe garantit que vous ne payez que lorsque vous utilisez le service dans les limites de service par défaut. Si vous avez besoin de partitions dépassant les limites de service existantes, Streaming anticipe une utilisation minimale de 10 Go par heure (requêtes PUT et GET) pour chaque tranche de 50 partitions utilisées. Si l'utilisation réelle est inférieure à l'utilisation minimale prévue, elle vous sera facturée à l'utilisation minimale, à savoir 10 Go x 0,025 USD = 0,25 USD de l'heure toutes les 50 partitions.
Streaming ne facture pas de prix supplémentaire pour le transfert de données vers et hors du service. De plus, les utilisateurs peuvent tirer parti de la puissance de Service Connector Hub pour transférer des données vers et depuis Streaming sans serveur et sans frais supplémentaires.
Actuellement, Streaming ne fonctionne pas dans le volet gratuit.
Le service Identity and Access Management vous permet de contrôler qui a accès à vos ressources Cloud. Pour utiliser les ressources Oracle Cloud Infrastructure, vous devez obtenir le type d’accès requis dans une stratégie rédigée par un administrateur, que vous utilisiez la console ou l’API REST avec un SDK, une CLI ou d’autres outils. L’accès à la stratégie est spécifiée sous la forme suivante
Allow <subject> to <verb> <resource-type> in <location> where <conditions>
Les administrateurs d’une location peuvent utiliser la stratégie
Allow group StreamAdmins to manage streams in tenancy
qui permet à un groupe StreamAdmins spécifié tout faire en ce qui concerne le streaming, depuis la création, la mise à jour, la liste et la suppression des flux et des ressources qui y sont liées. Cependant, vous pouvez toujours spécifier des stratégies plus granulaires afin que seuls certains utilisateurs d’un groupe ne soient éligibles que pour un sous-ensemble d’activités qu’ils peuvent effectuer sur un flux donné. Si vous débutez dans le domaine des stratégies, consultez les sections Pour commencer avec les stratégies et Stratégies communes. Si vous souhaitez approfondir la rédaction de stratégies pour Streaming, consultez la section Détails du service Streaming dans la référence sur les stratégies IAM.
Vous pouvez provisionner un flux et tous ses composants associés tels que les stratégies IAM, les partitions, les paramètres de cryptage, etc., en utilisant Oracle Cloud infrastructure Resource Manager ou le fournisseur Terraform pour Oracle Cloud Infrastructure. Pour plus d’informations sur le fournisseur Terraform, consultez la rubrique Terraform pour le service Streaming.
Lorsque vous créez un flux, vous devez spécifier le nombre de partitions du flux. Le débit attendu de votre application peut vous aider à déterminer le nombre de partitions pour votre flux. Multipliez la taille moyenne des messages par le nombre maximal de messages écrits par seconde pour estimer votre débit attendu. Étant donné qu’une seule partition est limitée à un taux d’écriture de 1 Mo par seconde, un débit plus élevé nécessite des partitions supplémentaires pour éviter la limitation. Pour vous aider à gérer les pics d’application, nous vous recommandons d’allouer des partitions légèrement supérieures à votre débit maximal.
Vous créez des partitions lorsque vous créez un flux, que ce soit sur la console ou par programmation.
Interface utilisateur de la console :
Par programmation :
Création d’un flux
CreateStreamDetails streamDetails =
CreateStreamDetails.builder()
.compartmentId(compartmentId)
.name(streamName)
.partitions(partitions)
.build();
Un exemple plus détaillé est fourni avec le SDK.
Streaming gère les partitions en interne afin que vous n’ayez pas besoin de les gérer. Un utilisateur ne peut pas supprimer directement une partition. Lorsque vous supprimez un flux, toutes les partitions associées à ce flux sont supprimées.
Le débit d’un flux Oracle Cloud Infrastructure est défini par une partition. Une partition fournit 1 Mo par seconde d’entrée de données et 2 Mo par seconde de sortie de données.
Le débit d’un flux Oracle Cloud Infrastructure peut être augmenté en y ajoutant davantage de partitions. Il n’y a pas de limite supérieure théorique sur le nombre de partitions qu’un flux peut contenir. Toutefois, chaque location d’Oracle Cloud Infrastructure est assortie d’une limite de partition par défaut de 5 pour les comptes de type Universal Credits. Si vous avez besoin de plus de partitions, vous pouvez toujours demander une augmentation de vos limites de service.
Vous pouvez demander une augmentation de la limite de service en suivant ces étapes :
Voici quelques bonnes pratiques à garder à l’esprit lors de la création d’un flux :
Une fois qu’un flux est créé et est à l’état « Actif », vous pouvez commencer à produire des messages. Vous pouvez produire un flux en utilisant la console ou via l’API.
Pour la console : accédez à la section Service Streaming sur la console, située sous l’onglet Solutions et plateforme > Analytique tab. Si vous avez déjà créé des flux, sélectionnez un flux dans un compartiment et accédez à la page « Détails du flux ». Cliquez sur le bouton « Produire un message de test » sur la console. Cela attribuera au hasard une clé de partition au message et écrira sur une partition du flux. Vous pouvez afficher ce message dans la section Messages récents en cliquant sur le bouton Charger les messages.
Pour les API : vous pouvez utiliser les API Oracle Cloud Infrastructure Streaming ou Kafka pour produire un flux. Le message sera publié dans une partition du flux. S’il y a plus d’une partition, vous spécifiez une clé pour choisir à quelle partition envoyer le message, et si vous ne spécifiez pas de clé, Streaming en attribue une pour vous en générant un UUID et envoie le message à une partition aléatoire. Cela garantit que les messages sans clé sont uniformément répartis sur toutes les partitions. Cependant, nous vous recommandons de toujours spécifier une clé de message afin de pouvoir contrôler explicitement la stratégie de partitionnement de vos données.
Des exemples de production de messages dans un flux à l’aide de SDK Streaming se trouvent dans la documentation.
Lors de l’utilisation des API Oracle Cloud Infrastructure pour produire un message, la logique de partitionnement est contrôlée par Streaming. C’est ce qu’on appelle le partitionnement côté serveur. En tant qu’utilisateur, vous choisissez la partition à envoyer en fonction de la clé. La clé est hachée et la valeur résultante est utilisée pour déterminer le numéro de partition à laquelle envoyer le message. Les messages avec la même clé vont dans la même partition. Les messages avec des clés différentes peuvent aller vers des partitions différentes ou vers la même partition.
Cependant, si vous utilisez des API Kafka pour produire un flux, le partitionnement est contrôlé par le client Kafka et le partitionneur dans le client Kafka est responsable de la logique de partitionnement. C’est ce qu’on appelle le partitionnement côté client.
Pour garantir une distribution uniforme des messages, vous avez besoin d’une valeur efficace pour vos clés de message. Pour en créer un, tenez compte de la sélectivité et de la cardinalité de vos données en streaming.
Il faut toujours viser une haute cardinalité et une faible sélectivité.
Streaming garantit des lectures et des écritures linéaires à l’intérieur d’une partition. Si vous voulez vous assurer que les messages possédant la même valeur soient placés dans la même partition, vous devez utiliser la même clé pour ces messages.
Une partition fournit un débit d’entrée de données de 1 Mo/s et prend en charge jusqu’à 1000 messages PUT par seconde. Par conséquent, si la taille de l’enregistrement est inférieure à 1 Ko, le taux d’entrée de données réel d’une partition sera inférieur à 1 Mo/s, limité par le nombre maximal de messages PUT par seconde. Nous vous recommandons de produire des messages par lots pour les raisons suivantes :
La taille d’un lot de messages ne doit pas dépasser 1 Mo. Si cette limite est dépassée, le mécanisme de limitation est déclenché.
Vous pouvez utiliser la segmentation ou envoyer le message à l’aide d’Oracle Cloud Infrastructure Object Storage.
Lorsqu’un producteur produit à un débit supérieur à 1 Mo par seconde, la demande est limitée et une erreur 429, trop de demandes est renvoyée au client indiquant que trop de demandes par seconde et par partition sont reçues.
Un consommateur est une entité qui lit les messages d’un ou plusieurs flux. Cette entité peut exister seule ou faire partie d’un groupe de consommateurs. Pour consommer des messages, vous devez créer un curseur, puis utiliser ce curseur pour lire les messages. Un curseur pointe vers un emplacement dans un flux. Cet emplacement peut être un décalage ou un moment précis dans une partition ou l’emplacement actuel d’un groupe. Selon l'emplacement à partir duquel vous souhaitez lire, il existe différents types de curseurs : TRIM_HORIZON
, AT_OFFSET
, AFTER_OFFSET
, AT_TIME
et LATEST.
Pour plus d’informations, reportez-vous à la documentation sur la consommation de messages.
La méthode getLimit( ) de la classe GetMessagesRequest renvoie le nombre maximum de messages. Vous pouvez spécifier n’importe quelle valeur jusqu’à 10 000. Par défaut, le service renvoie autant de messages que possible. Tenez compte de la taille moyenne de vos messages pour éviter de dépasser le débit sur le flux. Les tailles de lot GetMessages du service Streaming sont basées sur la taille moyenne des messages produits sur le flux particulier.
Streaming fournit une sémantique de diffusion « au moins une fois » aux consommateurs. Nous recommandons que les applications grand public prennent en charge les doublons. Par exemple, lorsqu’une instance précédemment inactive du groupe de consommateurs rejoint le groupe et commence à consommer des messages qui n’ont pas été validés par l’instance précédemment affectée, il y a une chance de traiter les doublons.
On dit qu’un consommateur prend du retard si vous produisez plus vite que vous ne pouvez consommer. Pour déterminer si votre consommateur prend du retard, vous pouvez utiliser l’horodatage du message. Si le consommateur prend du retard, envisagez de créer un nouveau consommateur pour reprendre certaines des partitions du premier consommateur. Si vous êtes en retard sur une seule partition, il n’y a aucun moyen de récupérer ce retard.
Considérez les options suivantes :
Si vous voulez savoir combien de messages il reste à consommer dans une partition donnée, utilisez un curseur de type LATEST
, obtenez le décalage du message publié suivant et effectuez le delta avec le décalage que vous consommez actuellement. Comme nous n’avons pas de décalage dense, vous ne pouvez obtenir qu’une estimation approximative. Cependant, si votre producteur a cessé de produire, vous ne pouvez pas obtenir cette information car vous n’obtiendrez jamais la compensation du prochain message publié.
Il est possible de configurer des utilisateurs pour qu’ils utilisent des messages au sein d’un groupe. Les partitions de flux sont réparties entre les membres d’un groupe afin que les messages provenant d’une partition unique soient envoyés uniquement à un seul utilisateur. Les attributions de partition sont rééquilibrées lorsque les utilisateurs rejoignent ou quittent le groupe. Pour plus d’informations, reportez-vous à la documentation sur les Groupes de consommateurs.
Les groupes de consommateurs offrent les avantages suivants :
Il y a une limite de 50 groupes de consommateurs par flux. Les groupes de consommateurs sont éphémères. Ils disparaissent lorsqu’ils ne sont pas utilisés pendant la période de rétention du flux.
Les composants suivants du service Streaming ont des délais d’expiration :
Le rééquilibrage est le processus dans lequel un groupe d’instances, qui appartient au même groupe de consommateurs, se coordonne pour posséder un ensemble de partitions mutuellement exclusives qui appartient à un flux spécifique. À la fin d’une opération de rééquilibrage réussie pour un groupe de consommateurs, chaque partition du flux appartient à une ou plusieurs instances de consommateur au sein du groupe.
Lorsqu’une instance d’un groupe de consommateurs devient inactive parce qu’elle ne parvient pas à envoyer une pulsation pendant plus de 30 secondes ou parce que le processus est arrêté, une activité de rééquilibrage est déclenchée au sein du groupe de consommateurs. Cela permet de gérer les partitions précédemment consommées par l’instance inactive et de la réaffecter à une instance active. De même, lorsqu’une instance d’un groupe de consommateurs qui était auparavant inactive rejoint le groupe, un rééquilibrage est déclenché pour affecter une partition à partir de laquelle commencer à consommer. Le service Streaming n’offre aucune garantie de réaffecter l’instance à la même partition lorsqu’elle rejoint le groupe.
Pour récupérer après une défaillance, vous devez stocker le décalage du dernier message que vous avez traité pour chaque partition afin de pouvoir commencer à consommer à partir de ce message si vous devez redémarrer votre consommateur.
Remarque : ne stockez pas le curseur ; il expire après 5 minutes.
Nous ne fournissons aucune indication pour stocker le décalage du dernier message que vous avez traité, vous pouvez donc utiliser la méthode de votre choix. Par exemple, vous pouvez stocker le curseur sur un autre flux, ou un fichier sur une machine virtuelle ou un compartiment Object Storage. Lorsque votre consommateur redémarre, lisez le décalage du dernier message que vous avez traité, puis créez un curseur de type AFTER_OFFSET
et spécifiez le décalage que vous venez d’obtenir.
Le service Streaming fournit un point de terminaison Kafka qui peut être utilisé par vos applications basées sur Apache Kafka existantes. Un changement de configuration est tout ce qui est nécessaire pour avoir une expérience Kafka entièrement gérée. La compatibilité Kafka de Streaming offre une alternative à l’exécution de votre propre cluster Kafka. Streaming prend en charge Apache Kafka 1.0 et les versions plus récentes du client et fonctionne avec vos applications, outils et frameworks Kafka existants.
Les clients disposant d’applications Kafka existantes pourront migrer vers Streaming en modifiant simplement les paramètres suivants de leur fichier de configuration Kafka.
security.protocol: SASL_SSL
sasl.mechanism: PLAIN
sasl.jaas.config: org.apache.kafka.common.security.plain.PlainLoginModule required username="{username}" password="{pwd}";
bootstrap.servers: kafka.streaming.{region}.com:9092
# Application settings
topicName: [streamOcid]
Pour utiliser vos connecteurs Kafka avec Streaming, créez une configuration Kafka Connect à l’aide de la console ou de l’interface de ligne de commande (CLI). Le API Streaming appelle ces configurations harnesses. Les configurations Kafka Connect créées dans un compartiment donné ne fonctionnent que pour les flux dans le même compartiment. Vous pouvez utiliser plusieurs connecteurs Kafka avec la même configuration Kafka Connect. Dans les cas qui nécessitent la production ou la consommation de flux dans des compartiments séparés, ou lorsque plus de capacité est requise pour éviter d’atteindre les limites de régulation de la configuration Kafka Connect (par exemple, trop de connecteurs ou connecteurs avec trop de collaborateurs), vous pouvez créer plus de configurations de connecteurs Kafka.
La compatibilité Kafka Connect de Streaming signifie que vous pouvez tirer parti des nombreux connecteurs propriétaires et tiers existants pour déplacer les données de vos sources vers vos cibles. Les connecteurs Kafka pour les produits Oracle comprennent :
Pour obtenir la liste complète des connecteurs source et récepteur Kafka tiers, reportez-vous au hub officiel de Confluent Kafka.
Streaming est entièrement intégré à Oracle Cloud Infrastructure Monitoring. Dans la console, sélectionnez le flux que vous souhaitez surveiller. Sous la page Détails du flux, accédez à la section Ressources et cliquez sur Produire des graphiques de surveillance pour suivre les demandes des producteurs, ou cliquez sur Consommer des graphiques de surveillance pour surveiller les indicateurs clés côté consommateur. Les indicateurs clés sont disponibles au niveau du flux et non au niveau de la partition. Pour obtenir une description des indicateurs clés Streaming pris en charge, consultez la documentation.
Chaque indicateur clé disponible dans la Console fournit les statistiques suivantes :
Ces statistiques sont proposées pour les intervalles de temps suivants :
Pour les producteurs, envisagez de définir des alarmes sur les indicateurs clés suivants :
Pour les consommateurs, envisagez de définir les mêmes alarmes en fonction des indicateurs clés suivant :
Un flux est sain lorsqu’il est dans un état Actif. Si vous pouvez produire sur votre flux, et si vous obtenez une réponse positive, alors le flux est sain. Une fois les données produites dans le flux, elles sont accessibles aux consommateurs pendant la période de rétention configurée. Si les appels de l’API GetMessages renvoient des niveaux élevés d’erreurs internes du serveur, le service n’est pas sain.
Un flux sain a également des indicateurs clés sains :
La limitation indique que le flux est incapable de gérer les nouvelles lectures ou écritures. Le mécanisme de limitation s’active lorsque les seuils suivants sont dépassés :
Les détails sur les erreurs API se trouvent dans la documentation.