MicroStrategy ONE
起動時に行う稼働状態の確認処理
MicroStrategy 2019 リリースでは、サービス名をいくつか変更しました。このガイドでは基礎となるファイルを変更する必要があるため、オリジナルサービス名。
テレメトリストア(つまりプラットフォーム分析コンシューマー)とアイデンティティテレメトリプロデューサー(つまりUsher メタデータ プロデューサーは、テレメトリ ログを処理するために 3 つのコンポーネントに依存しており、これらのコンポーネントにアクセスする必要があります。
- プラットフォーム分析リポジトリ(つまりデータベースサーバー)
- Telemetry Cache (Redis)
- テレメトリサーバー(つまりカフカ)
3 つすべてが正常に稼働していなければ、Platform Analytics はテレメトリー ログを処理できません。ひとつでも障害があると、Telemetry Store (コンシューマー) や Identity Telemetry (プロデューサー) は停止してしまいます。そこで、コンシューマー/プロデューサーは起動時に、上記コンポーネントの稼働状況を確認し、結果を詳細なレポートとしてまとめます。
確認処理が始まった時点で、いずれかのコンポーネントが起動処理中で、完全に稼働していないこともありえます。その場合、60 秒ごとに 3 回繰り返して稼働状況を確認するようになっています。
プラットフォーム分析アーキテクチャの詳細については、以下を参照してください。Platform Analytics のアーキテクチャとサービス。
レポート名と出力先
両方の起動時にヘルスチェックが実行されます。プラットフォーム分析消費者そしてUsher メタデータ プロデューサー。したがって、プラットフォームアナリティクスでは2つのヘルスチェックレポートが生成されます。ログデフォルトのインストール パスにあるフォルダー:
- リナックス : /opt/MicroStrategy/PlatformAnalytics/ログ
- ウィンドウズ : C:\Program Files (x86)\MicroStrategy\Platform Analytics\log
どちらが生成したレポートかは、ファイル名で区別できます。
次に例を示します。
platform-analytics-consumer-health-check-yyyymmddhhmmss.out
platform-analytics-usher-lookup-producer-health-check-yyyymmddhhmmss.out
稼働状況の確認結果のレポート
各レポートは次の 4 つのセクションから成ります。
各セクションには、3 つのコンポーネントそれぞれの確認結果が載っています。
ヘルス チェック
ヘルス チェックについては次の 2 つの事項を確認します。
- 消費者/生産者は、インストール時に提供され、 PAコンシューマ構成.yaml設定ファイルですか?接続できない場合、問題の原因を診断するために追加のネットワーク接続テストが実行されます。
- データベース ユーザーが必要な権限を付与されているか。インストールの前提条件の完全なリストについては、以下を参照してください。Platform Analytics の前提条件。
ヘルス チェック レポートには、必要な権限とその付与状況の一覧が載っています。すべてのチェックが成功した場合、最終行には次のように表示されます。倉庫のヘルスチェックの結果は正常です。
いずれかの行に失敗した、確認してくださいPAコンシューマ構成.yamlファイルを確認し、データベースに適切な権限があることを確認します。
考えられる問題とその対処法を以下に示します。
権限の不足
データベースユーザーがPAコンシューマ構成.yaml設定ファイルに権限がない場合、 INFO [権限の種類] 権限: 失敗。管理者が該当する権限を当該データベース ユーザーに付与した後、コンシューマーを再起動してください。
権限を付与する手順を以下に示します。
- Platform Analytics Consumer および Usher Metadata Producer をいったん停止します。
- Platform Analytics Repository を収容するデータベース サーバーに接続します。次のコマンドを実行してください。ただし「someuser」と「somehost」は顧客が指定する情報で置き換えます。コピー
GRANT DROP ON platform_analytics_wh.* TO ‘someuser’@‘somehost’;
- Platform Analytics Consumer と Usher Metadata Producer を再起動します。
接続の失敗
コンシューマまたはプロデューサが、 PAコンシューマ構成.yaml構成ファイルでは、次のエラーが表示される場合があります。
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
のPAコンシューマ構成.yamlファイルは、インストール時に提供されたデータベース情報に基づいて作成されます。このエラーを解決するには、Platform Analyticsをホストしているマシンに接続し、ウェアハウスデータベース接続見出しは正しいPAコンシューマ構成.yamlファイル。
データベース ユーザーのパスワードが不正
暗号化したウェアハウスのパスワードが正しくない場合、コンシューマー/プロデューサーはデータベースに接続できません。新しい暗号化パスワードを生成し、確認を更新するには、Platform Analytics Repository に設定した、データベース ユーザーのパスワードの更新。
SSL が有効な状態でデータベース ユーザーを作成したことによるエラー
Platform Analytics は MySQL 5.6、5.7、8.0 の各版に対応しています。MySQL 8.0 の場合、SSL 接続がデフォルトで有効になっています。一方、Platform Analytics は現状、MySQL に対する SSL 接続に対応していません。Platform Analytics ConsumerまたはUsher Metadata Producerのデータベースユーザーを作成するときは、必要とする句。
SSL を無効にする手順:
Redis の稼働状況
Redis については、コンシューマー/プロデューサーが Redis サーバーに接続できるか否かを確認します。レポートには、起動時に収集した、Redis に関する詳しい統計情報が載っています。すべてのチェックが成功した場合、最終行には次のように表示されます。 Redis サーバーのヘルスチェックの結果は正常です。
チェックでエラーが表示された場合は、Redisが実行中であることと、 PAコンシューマ構成.yamlファイル。
考えられる問題とその対処法を以下に示します。
Redis が停止
コンシューマー/プロデューサーが Redis に接続できない原因として、Redis が停止していることが考えられます。その場合、MicroStrategy In-Memory Cache、Platform Analytics Consumer、Usher Metadata Producer を起動してください。
Redis への接続不可
コンシューマーまたはプロデューサーがRedisに接続できない場合は、 PAコンシューマ構成.yamlファイル。このエラーを解決するには、Platform Analyticsをホストしているマシンに接続し、 redis接続見出しは正しいPAコンシューマ構成.yamlファイル。
Redis のパスワード認証が有効
コンシューマー/プロデューサーが Redis に接続できない原因として、パスワード認証が有効になっていることが考えられます。初期状態の Redis はパスワード認証が無効になっていますが、いつでも有効にすることができます。
Redisがパスワード認証で有効になっており、パスワードがPAコンシューマ構成.yaml構成ファイルが正しくない場合、コンシューマーまたはプロデューサーは Redis に接続できなくなります。このエラーを解決するには、以下の手順に従ってください。MicroStrategy Telemetry Cache に対するパスワード認証の有効化。
Kafka の稼働状況
Kafka については、Telemetry Manager (Apache Zookeeper) および Telemetry Server (Kafka Server) が稼働しており接続されているか否かを確認します。すべてのチェックが成功した場合、最終行には次のように表示されます。 Kafka クラスターのヘルスチェックの結果は正常です。
Telemetry Server は Telemetry Manager に依存しているので、先に Telemetry Manager を起動する必要があります。
エラーが見つかった場合は、ZooKeeper および Kafka が稼働していることを確認してください。
ZooKeeper サーバーがすべてのノードで実行されているかどうかを確認する方法
- Linux では、次のコマンドを実行して PID を実行します。コピー
ps ax | grep java | grep -i QuorumPeerMain | grep -v grep | awk '{print $1}'
- Windows では、[サービス] ダイアログを開き、\"Apache ZooKeeper\" サービスが実行されているかどうか確認します。
Kafka サーバーがすべてのノードで実行されているかどうかを確認する方法
- Linux では、次のコマンドを実行して PID を実行します。コピー
ps ax | grep -i 'kafka\\.Kafka' | grep java | grep -v grep | awk '{print $1}'
- Windows では、[サービス] ダイアログを開き、\"Apache Kafka\" サービスが実行されているかどうか確認します。
ZooKeeper と Kafka をすべてのノードで開始する方法
-
Linux では、Kafka ディレクトリで次のコマンドを実行します。
コピー# 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 - Windows では、[サービス] ダイアログを開き、Apache ZooKeeper と Apache Kafka を開始します。
ZooKeeper および Kafka の、複数のノードから成るクラスター化環境であれば、ZooKeeper の全ノードをまず起動してください。
要約
すべてのヘルスチェックが成功した場合、結果は通過。いずれかのチェックに失敗した場合は、失敗対応するコンポーネントについて。上記の詳細レポートをもとに、考えられる原因を調べてください。