Strategy ONE
Contrôles au démarrage
Plusieurs services ont été renommés dans la version 2019 de MicroStrategy. Ce guide nécessite de modifier les fichiers sous-jacents et utilise donc les noms de service d'origine.
Le stockage Telemetry Store (Platform Analytics Consumer) et le producteur Identity Telemetry (Usher Metadata Producer) dépendent de trois composants auxquels ils doivent avoir accès pour traiter les journaux de télémétrie :
- Référentiel Platform Analytics (c.-à-d. Serveur de base de données)
- Cache Telemetry (Redis)
- Serveur Telemetry Server (Kafka)
Ces trois composants doivent être opérationnels pour que Platform Analytics traite correctement les journaux de télémétrie. Si l'un de ces composants n'est pas disponible, le consommateur Telemetry Store et le producteur Identity Telemetry s'arrêtent. Ainsi, lors du démarrage, le consommateur et le producteur exécutent un contrôle pour les trois composants et génèrent un rapport détaillé contenant les résultats.
Il peut arriver que l'un des composants soit en cours de démarrage et qu'il ne soit donc pas encore prêt lorsque le contrôle commence. Dans ce cas, le consommateur et le producteur effectuent trois contrôles consécutifs espacés de 60 secondes pour vérifier si les dépendances sont opérationnelles ou non.
Pour plus d'informations sur l'architecture Platform Analytics, reportez-vous à la page Architecture et services de Platform Analytics.
Conventions d'attribution de nom et emplacements
Un contrôle est effectué au démarrage de Platform Analytics Consumer et d'Usher Metadata Producer. Ainsi, deux rapports de contrôle sont générés dans le dossier log de Platform Analytics, situé dans le chemin d'installation par défaut :
- Linux : /opt/MicroStrategy/PlatformAnalytics/log
- Windows : C:\Program Files (x86)\MicroStrategy\Platform Analytics\log
Le nom du fichier indique si le rapport correspond au consommateur ou au producteur.
Par exemple :
platform-analytics-consumer-health-check-yyyymmddhhmmss.out
platform-analytics-usher-lookup-producer-health-check-yyyymmddhhmmss.out
Résultats des rapports de contrôle
Chaque rapport de contrôle est structuré en quatre sections :
Chaque section fournit des informations différentes sur l'état de vos trois composants.
Bilan d'intégrité
Pendant le bilan d'intégrité, deux vérifications sont exécutées :
- Le consommateur/producteur peut-il se connecter à la base de données fournie lors de l'installation et stockée dans le PAConsumerConfig.yaml fichier de configuration ? Si ce n'est pas le cas, des tests de connectivité réseau supplémentaires ont lieu pour diagnostiquer la cause du problème.
- L'utilisateur de base de données possède-t-il les privilèges requis ? Pour connaître la liste complète des conditions préalables à l'installation, reportez-vous à la page Conditions préalables pour Platform Analytics.
Le rapport Health Check fournit une liste des privilèges et l'état qui en résulte. Si toutes les vérifications réussissent, la dernière ligne se lira Warehouse health check result is healthy.
Si une ligne lit Failed, vérifiez votre PAConsumerConfig.yaml fichier et assurez-vous que la base de données dispose des privilèges corrects.
Si vous recevez l'une des erreurs suivantes lors du bilan d'intégrité, nous vous proposons des solutions de contournement :
Erreur Missing Privileges (Privilèges manquants)
Si l'utilisateur de la base de données a enregistré dans PAConsumerConfig.yaml il manque des privilèges dans le fichier de configuration, alors INFO [privilege type] privilege: Failed. Pour résoudre cette erreur, l'administrateur doit accorder le ou les privilèges manquants à l'utilisateur de base de données, puis redémarrer le consommateur.
Comment accorder des privilèges manquants :
- Arrêtez Platform Analytics Consumer et Usher Metadata Producer.
- Connectez-vous au serveur de base de données qui contient le référentiel Platform Analytics. Exécutez la commande suivante, en remplaçant 'utilisateur' et 'hôte' par les informations spécifiées du client :Copier
GRANT DROP ON platform_analytics_wh.* TO ‘someuser’@‘somehost’;
- Redémarrez Platform Analytics Consumer et Usher Metadata Producer.
Erreur d'échec de connexion
Si le consommateur ou le producteur ne peut pas se connecter à la base de données en utilisant la configuration spécifiée dans PAConsumerConfig.yaml fichier de configuration, vous pouvez voir l'erreur suivante :
2018-11-21 21:43:28,793 INFO HealthCheck main - Failed to connect to the database. Retrying after waiting for 60 seconds.
2018-11-21 21:45:31,797 INFO HealthCheck main - Failed to connect to the database. Retrying after waiting for 60 seconds.
2018-11-21 21:47:34,800 ERROR HealthCheck main - Failed to connect to the database using url:jdbc:mysql://XX.Y.Z.1:3306/platform_analytics_wh?rewriteBatchedStatements=true&useLegacyDatetimeCode=false&serverTimezone=UTC. Please double check your connection parameters.
Communications link failure
Le PAConsumerConfig.yaml Le fichier est peuplé en fonction des informations de base de données fournies pendant l'installation. Pour résoudre cette erreur, connectez-vous à l'ordinateur hébergeant Platform Analytics et confirmez tous les champs sous warehouseDbConnection l'en-tête est correct dans PAConsumerConfig.yaml fichier.
Erreur Database User Password is Incorrect (Mot de passe de l'utilisateur de base de données incorrect)
Le consommateur ou le producteur ne pourra pas se connecter à la base de données si le mot de passe de l'entrepôt crypté est incorrect. Pour générer un nouveau mot de passe crypté et mettre à jour la confirmation, reportez-vous à la page Mettre à jour le mot de passe d'utilisateur de base de données configuré dans le référentiel Platform Analytics .
Erreur Database User Created with SSL Enabled (Utilisateur de base de données créé avec SSL activé)
Platform Analytics prend en charge les versions 5.6, 5.7 et 8.0 de MySQL. Pour MySQL 8.0, la connexion SSL est activée par défaut. Actuellement, Platform Analytics ne prend pas en charge SSL pour l'utilisateur de base de données qui se connecte à MySQL. Lorsque vous créez l'utilisateur de base de données pour le consommateur Platform Analytics ou le producteur Usher Metadata, spécifiez l'option SSL/TLS en utilisant REQUIRE clause.
Comment désactiver SSL :
- Connectez-vous au référentiel Platform Analytics et exécutez la commande suivante :Copier
show variables like '%ssl%';
-
Si le résultat pour 'have_ssl' est 'YES' SSL est activé. Créer l'utilisateur avec mysql_native_password et REQUIRE NONE options pour se connecter sans SSL.
CopierCREATE USER 'test'@'%' IDENTIFIED WITH mysql_native_password BY 'password' REQUIRE NONE;
Contrôle Redis
Le contrôle Redis détermine si le consommateur ou le producteur peut se connecter avec succès au serveur Redis. Il offre des statistiques détaillées sur Redis, collectées lors du démarrage. Si toutes les vérifications réussissent, la dernière ligne se lira Redis server health check result is healthy.
Si vous voyez une erreur lors de votre vérification, assurez-vous que Redis est en cours d'exécution et que votre configuration est correcte dans PAConsumerConfig.yaml fichier.
Si vous recevez l'une des erreurs suivantes dans la Redis Health Check, voici des solutions de contournement suggérées :
Erreur Redis is Stopped (Redis est arrêté)
Si le consommateur ou le producteur ne parvient pas à se connecter à Redis, il se peut que Redis soit arrêté. Pour résoudre cette erreur, démarrez le cache en mémoire MicroStrategy, Platform Analytics Consumer et Usher Metadata Producer.
Erreur Failed to Connect to Redis (Échec de la connexion à Redis)
Si le consommateur ou le producteur ne peut pas se connecter à Redis, cela peut être dû au fait que la configuration n'est pas correcte dans PAConsumerConfig.yaml fichier. Pour résoudre cette erreur, connectez-vous à l'ordinateur hébergeant Platform Analytics et confirmez tous les champs sous redisConnection l'en-tête est correct dans PAConsumerConfig.yaml fichier.
Authentification par mot de passe activée pour Redis Erreur
Si le consommateur ou le producteur ne parvient pas à se connecter à Redis, il se peut que l'authentification par mot de passe soit activée. Par défaut, Redis n'est pas configuré avec l'authentification par mot de passe, mais celle-ci peut être configurée après l'installation.
Si Redis a été activé avec l'authentification par mot de passe et que le mot de passe est manquant dans PAConsumerConfig.yaml fichier de configuration, le consommateur ou le producteur ne pourra pas se connecter à Redis. Pour résoudre cette erreur, suivez les étapes détaillées sur la page Activer l'authentification par mot de passe sur le cache MicroStrategy Telemetry Cache.
Contrôle Kafka
Le bilan d'intégrité Kafka s'assure que Telemetry Manager (Apache Zookeeper) et Telemetry Server (Kafka Server) sont démarrés et connectés. Si toutes les vérifications réussissent, la dernière ligne se lira Kafka cluster health check result is healthy.
Le serveur Telemetry Server dépend de Telemetry Manager. Ce dernier doit donc être démarré en premier.
Si une erreur s'affiche dans le contrôle, vérifiez que ZooKeeper et Kafka sont démarrés.
Comment vérifier si les serveurs ZooKeeper fonctionnent sur tous les nœuds :
- Sous Linux, exécutez la commande suivante pour exécuter le PID.Copier
ps ax | grep java | grep -i QuorumPeerMain | grep -v grep | awk '{print $1}'
- Sous Windows, ouvrez les services de Windows et vérifiez si le service \"Apache ZooKeeper\" est en cours d'exécution.
Comment vérifier si les serveurs Kafka sont en cours d'exécution sur tous les nœuds :
- Sous Linux, exécutez la commande suivante pour exécuter le PID.Copier
ps ax | grep -i 'kafka\\.Kafka' | grep java | grep -v grep | awk '{print $1}'
- Sous Windows, ouvrez les services de Windows et vérifiez si le service \"Apache Kafka\" est en cours d'exécution.
Comment démarrer ZooKeeper et Kafka sur tous les nœuds :
-
Sous Linux, exécutez les commandes suivantes dans le répertoire Kafka :
Copier# Start Zookeeper on all nodes,
./zookeeper-server-start.sh -daemon ../config/zookeeper.properties
# Start Kafka on all nodes,
./kafka-server-start.sh -daemon ../config/server.properties - Sous Windows, ouvrez les services de Windows et démarrez Apache ZooKeeper et Apache Kafka.
Si vous disposez d'un environnement en cluster avec plusieurs nœuds ZooKeeper et Kafka, vous devez commencer par démarrer tous les nœuds.
Résumé du contrôle
Si toutes les vérifications d'état réussissent, les résultats seront passing. Si l'une des vérifications échoue, vous recevrez une FAIL pour le composant correspondant. En cas d'échec, utilisez la liste de rapport détaillée ci-dessus pour déterminer les causes possibles d'échec.