Utiliser et surveiller des flux de données

Surveillance côté GoldenGate

• Vérifiez que la ressource Data Stream est présente et disponible dans le service de distribution.

• Surveiller les enregistrements et les octets envoyés, le nombre d'opérations, le nombre de DDL, l'activité de la table et les statistiques réseau lorsqu'ils sont exposés par les mesures d'interface utilisateur ou de service.

• Consultez les journaux du service de distribution pour connaître les erreurs d'authentification, de recherche de trace, de recherche de position, de génération de schéma, de troncation de taille et de déconnexion WebSocket.

• Surveillez l'extraction source et la génération de trace indépendamment. Une valeur WebSocket en bon état ne peut pas fournir de données qui n'atteignent pas la trace.

Métriques de consommateur

Métrique	Pourquoi est-ce important
Etat de connexion et nombre de reconnexions	Détecte l'instabilité du réseau, de l'authentification, du proxy et du service.
Dernière réception et dernière validation pos	Sépare l'arrivée des données du traitement durable réussi. Consignez une valeur de hachage ou de protection si les positions sont considérées comme sensibles.
Enregistrements et octets par type/table	Identifie le volume inattendu, les erreurs de filtrage et l'écart.
Latence de traitement	Délai entre op_ts et la validation en aval durable. Prendre en compte les différences entre les horloges source et consommateur.
Profondeur de file d'attente interne et ancienneté de la file d'attente la plus ancienne	Détecte la contrepression avant l'épuisement de la mémoire.
Modifications de la version du schéma/des métadonnées	Détecte les modifications LDD et de contrat.
Nombre de conflits de doublons et d'idémpotence	Valide le comportement de livraison et de point de reprise.
Echecs de lettre morte et de validation	Affiche les enregistrements nécessitant une correction manuelle ou automatique.

Planification de la capacité et de la réserve

bufferSize contrôle le seuil d'octets auquel le service vide sa file d'attente de messages en mémoire vers le client. Une valeur plus élevée peut améliorer l'efficacité du traitement par lots, mais peut augmenter l'utilisation et la latence de la mémoire par message. Une valeur inférieure peut réduire la latence mais augmenter la surcharge des messages. Il ne s'agit pas d'une file d'attente durable, ne remplace pas la conservation de la trace et ne supprime pas le besoin de contrôles de contrepression du consommateur.

• Testez avec des tailles de transaction représentatives, des objets LOB, des instructions LDD, le nombre de tables et le débit maximal.

• Définissez WebSocket et la taille maximale des messages proxy au-dessus du lot attendu le plus grand.

• Utilisez des files d'attente limitées et échouez rapidement plutôt que d'autoriser une croissance de la mémoire illimitée.

• Des validations distinctes de réception, de validation, d'E/S en aval et de point de reprise du réseau permettent de mesurer chaque étape.

Stratégie de reconnexion

• Reconnectez-vous du dernier point de reprise durable, et non du dernier enregistrement simplement reçu.

• Utilisez un backoff exponentiel avec un délai et une gigue maximaux.

• Réinitialisez le délai après une connexion stable.

• Classez les échecs non tentables, tels que les informations d'identification non valides ou une position enregistrée non disponible, et générez une alerte d'opérateur au lieu de réessayer indéfiniment.

• Conserver le même contrat de sortie lors de la récupération. Si la configuration du flux a changé, terminez la validation de compatibilité avant de reprendre.

Plusieurs destinataires

Data Streams ne fournit pas de groupe de consommateurs de ressources de type Kafka ni de décalage par consommateur géré par le serveur. Chaque client indépendant doit conserver son propre point de reprise et recevoir des enregistrements en fonction de sa connexion et de la valeur begin. Ne partagez pas un point de reprise entre les consommateurs actifs simultanément, sauf si un coordinateur externe garantit une propriété unique et des mises à jour de point de reprise commandées.

Gestion du changement

• Version de la configuration du flux de données et génération de AsyncAPI YAML avec la version du consommateur.

• Tester la création, la connexion, le traitement à l'état stable, la déconnexion, le redémarrage, l'échec de la position retenue, le DDL, les enregistrements volumineux et la rotation des informations d'identification.

• Déployez le code consommateur compatible avant d'activer les nouveaux champs de charge utile ou les modifications de schéma.

• Conservez un plan d'annulation qui conserve le dernier point de reprise et la dernière configuration dont le fonctionnement a été vérifié.