Nœud de création de rapport : Résolution de la sensibilité à la casse du nom du contrôleur de données après ServerDR

Problèmes observés après le signalement du redéploiement du nœud et de ServerDR.

Les symptômes suivants ont été identifiés :

• Les nouvelles données collectées après l’exécution de ServerDR n’apparaissent dans aucun rapport.
• Seules les données historiques restent visibles dans le Report Browser.
• Les logs de service du collecteur de données contiennent un échec de connexion.
• Une requête de base de données affiche le nom du collecteur de données stocké en minuscules/majuscules (par exemple, data-collector@report ).
• Le nom d’hôte actuel du nœud de création de rapport se trouve dans une casse différente (majuscule ou minuscule) que le nom enregistré dans la base de données.

Entrées de journal pertinentes à partir de /var/log/reporting/logs/data-collector/data-collector.log :

2026-02-10T06:45:00.006Z INFO [] [DataCollectionQuartzScheduler_Worker-1] [c.e.b.d.c.s.DataCollectionJob.execute(17)] - Start to perform data collection.
2026-02-10T06:45:00.007Z INFO [] [DataCollectionQuartzScheduler_Worker-1] [c.e.b.d.c.s.d.c.DataCollectionService.doCollect(93)] - Query systems by data collector data-collector@REPORT.
2026-02-10T06:45:00.113Z ERROR [] [DataCollectionQuartzScheduler_Worker-1] [c.e.b.d.c.a.CollectedSystemApiServiceImpl.findAllByDataCollectorName(227)] - Error finding all by data collector name: data-collector@gcntnb05
java.net.ConnectException: Failed to connect to localhost/127.0.0.1:18455
    at okhttp3.internal.connection.RealConnection.connectSocket(RealConnection.kt:297)
    at okhttp3.internal.connection.RealConnection.connect(RealConnection.kt:207)
    at okhttp3.internal.connection.ExchangeFinder.findConnection(ExchangeFinder.kt:226)
    at okhttp3.internal.connection.ExchangeFinder.findHealthyConnection(ExchangeFinder.kt:106)
    at okhttp3.internal.connection.ExchangeFinder.find(ExchangeFinder.kt:74)
    at okhttp3.internal.connection.RealCall.initExchange$okhttp(RealCall.kt:255)

Commande utilisée pour inspecter les enregistrements du collecteur dans la base de données :

psql postgresql://reporting:Password123\!@127.0.0.1:9003/collected_business_data -c "select * from public.collected_system"

Incompatibilité sensible à la casse du nom du collecteur de données

Le problème se produit parce que le data_collector_name Le stockage dans la base de données du nœud de création de rapport est sensible à la casse. Après le redéploiement du nœud de reporting, son nom d’hôte est en lettres majuscules, alors que le nom d’hôte d’origine enregistré pendant ServerDR était en minuscules. Cette divergence empêche le service Data Collector de localiser l’entrée correcte, ce qui entraîne des échecs de synchronisation des données.

• L’entrée de base de données pour data_collector_name est stocké en minuscules (par exemple, data-collector@report ).
• Le nom d’hôte actuel du nœud de création de rapport est en majuscules, mais le nom d’hôte ServerDR précédent était en minuscules (par exemple, REPORT ).
• Étant donné que la comparaison de noms est sensible à la casse, le service ne peut pas faire correspondre le nom stocké avec le nom d’hôte actuel.

Erreur de connexion résultante

2026-02-10T06:45:00.113Z ERROR [] [DataCollectionQuartzScheduler_Worker-1] [c.e.b.d.c.a.CollectedSystemApiServiceImpl.findAllByDataCollectorName(227)] - Error finding all by data collector name: data-collector@REPORT
java.net.ConnectException: Failed to connect to localhost/127.0.0.1:18455
    at okhttp3.internal.connection.RealConnection.connectSocket(RealConnection.kt:297)
    at okhttp3.internal.connection.RealConnection.connect(RealConnection.kt:207)
    at okhttp3.internal.connection.ExchangeFinder.findConnection(ExchangeFinder.kt:226)
    at okhttp3.internal.connection.ExchangeFinder.findHealthyConnection(ExchangeFinder.kt:106)
    at okhttp3.internal.connection.ExchangeFinder.find(ExchangeFinder.kt:74)
    at okhttp3.internal.connection.RealCall.initExchange$okhttp(RealCall.kt:255)

Restaurez les données du nœud Reporting après ServerDR.

Option 1 : redéployer le nœud Reporting avec le nom d’hôte correct.

Utilisez cette méthode lorsque vous préférez un redéploiement propre.

• Assurez-vous que le nouveau nom d’hôte du nœud de création de rapport correspond **exactement** au nom d’hôte d’origine, y compris la casse (par exemple, REPORT ou rapport ).
• Redéployez le nœud de création de rapport à l’aide du nom d’hôte correct.
• Exécutez à nouveau ServerDR (Server Disaster Recovery) sur le nœud de reporting.

Option 2 : mettre à jour le nom du Data Collector directement dans la base de données

Utilisez cette méthode pour éviter un redéploiement complet.

1. Connectez-vous au nœud de création de rapport avec les privilèges appropriés.
2. Vérifiez les entrées actuelles du collecteur de données :

   psql postgresql://reporting:[PASSWORD]@127.0.0.1:9003/collected_business_data -c "SELECT * FROM public.collected_system;"        

3. Identifiez la ligne qui contient l’ancien nom d’hôte et notez sa valeur d’adresse (par exemple, 192.168.1.15 ).
4. Pour correspondre à la casse actuelle du nom d’hôte :

   postgresql://reporting:[PASSWORD]@127.0.0.1:9003/collected_business_data -c "UPDATE public.collected_system SET data_collector_name='data-collector@[HOSTNAME]' WHERE address='[IP_ADDRESS]';"       

   Remplacez [HOSTNAME] par le nom d’hôte exact du nœud de création de rapport (sensible à la casse) et [IP_ADDRESS] par l’adresse identifiée à l’étape 2.
5. Redémarrez le service Data-Collector pour appliquer la modification :

   systemctl restart data-collector.service        

Vérification

• Vérifiez le journal du collecteur de données pour les requêtes réussies :

  cat /var/log/reporting/logs/data-collector/data-collector.log | grep -i "Start to perform data collection"       

  Aucune ConnectException Des erreurs doivent apparaître.
• Patientez environ une heure, puis ouvrez le Report Browser et vérifiez que les données nouvellement collectées s’affichent en même temps que les données historiques.