よくある質問

improve this page | report issue

概説

このトピックでは、MobileFirst Analytics Server に関連したよくある質問について説明します。

マルチ索引 Elasticsearch クラスターでは、以下の設定が重要です。

  • 最小シャード数を、クラスター内のノード数に設定する。
  • シャード当たりのレプリカ数を最低限 2 に設定する。

MobileFirst Analytics v8.0 は、複数の索引を使用してイベント・データを保管します。

MobileFirst Analytics v8.0 では、Elasticsearch のデータ・ストアは複数の索引を持ちます。 単一索引ベースのデータ・ストアではありません。 索引は、Analytics に流入してくるイベントのタイプに基づいて動的に作成されます。 したがって、エンド・ユーザーは、複数の索引について心配する必要はありません。 ここでは、Elasticsearch 内部の各索引が、構成ファイルに設定されたシャード数に分割されます。

データ要件および顧客要件に照らして正しいハードウェアかどうかがハードウェア・サイジング計算器を使用してチェックされていることを確認してください。 ハードウェア、Analytics サーバーに入ってくるデータ・イベントのタイプやサイズ、イベントの量など、いくつかの要因がシステムのパフォーマンスに影響を及ぼします。

いいえ。いったんパージしたデータを復旧することはできません。

TTL プロパティーは、Analytics プラットフォームに存在するデータには適用されません。 TTL プロパティーを設定した後でデータを追加する必要があります。

MobileFirst Server JNDI プロパティーを使用して正しい Analytics エンドポイントが構成されていることを確認してください。 レンダリングされるデータに応じて日付フィルターが正しく設定されていることを確認してください。

Elasticsearch REST API を呼び出すには、Analytics サーバーの server.xml 内でプロパティー analytics/http.enabledtrue に設定されている必要があります。

いいえ。IBM WebSphere Application Server フル・プロファイルまたは Network Deployment (ND) を使用している間は、すぐに使用可能な状態で WebSphere Application Server と一緒に提供される IBM JDK を使用するようにしてください。

アプリケーションを開いた最初の時点ではアプリケーション・セッション数はゼロです。 エンド・ユーザーがモバイル・アプリケーションをバックグラウンドに移してからフォアグラウンドに戻すと、このアクションによってアプリケーション・セッション数が 1 に増えます。同じアクションをさらに繰り返すと、アプリケーション・セッション数は増え続けます。

クラスター・ヘルスの「黄」は、問題ではないことがあります。 ほとんどの場合、未割り当てのシャードがあるとクラスター・ヘルスは「黄」と示されます。 新しいノードがクラスターに加わると、Elasticsearch は未割り当てのシャードを新しいノードに再割り振りするため、クラスター・ヘルスは「緑」になります。 場合によっては、シャード数が多すぎても、どのノードにも割り当てられていないシャードが残るため、クラスター・ヘルスの状況が「黄」と示されます。 クラスター内のすべてのノードがアクティブで良好に作動していること、および、シャードの状態が開始済みまたはアクティブであることを確認してください。

Web アプリケーションの場合、アプリケーション・セッション数は、ブラウザー・セッションに基づいて増やされ、ブラウザー (アプリケーション) から MFP Server への接続に基づきます。

例えば、ブラウザーが一般ウィンドウ/タブを使用しているときに、サーバーへの接続を実行します。これにより、アプリケーション・セッション数が 1 だけ増加します。 同じブラウザーでユーザーが別のタブでアプリケーションを開き、接続を実行すると、セッションは増加しません。 セッションは 30 分間アクティブでないままです。 再接続を再び試行すると、1 だけ増加します。

ユーザーがブラウザー・キャッシュを初期化し、接続を試行すると、デバイスは新しいものであると見なされ、デバイス数が増やされます。 ブラウザーは実デバイス ID を保有していないため、オフラインのファイル/キャッシュが初期化されるまで、ブラウザー・アプリケーション用に生成される ID は 1 つになります。

これは、匿名ブラウザー・ウィンドウにも当てはまります。匿名ブラウザー・ウィンドウを使用していて、接続を試行すると、各タブからの接続に使用されるアプリケーションは新規セッションであると見なされ、セッション数が増やされます。 ユーザーが 2 つの異なるブラウザーを使用していて、MFP Server に接続するためにアプリケーションにアクセスすると、デバイス数は 2 増やされます。

アクティブ・ユーザー は、アプリケーションを使用しているユーザーの数です。 固有の各ユーザーが、アプリケーションを使用しているユーザーとしてカウントされます。 デフォルトでは、デバイス ID が userID です。 ただし、アプリケーション開発者は setUserContext(userid) API を使用できます。 これにより、userID はアプリケーション開発者が設定する値に置き換えられます。

1 つの解決策/手段は、ユーザーが Web アプリケーションにアクセスしたときにコンピューターで固有 ID を生成し、それをカスタム・データとして送信することです。 このデータは、ユーザーがアプリケーションにアクセスし、setUserContext を使用して userID を設定する実際のマシン (またはコンピューター/ブラウザー) の統計情報を計算するのに使用できます。 また、このデータは、カスタム・グラフを生成するためにも使用できます。

Analytics 8.0 におけるアプリケーション・セッションの計算は、それより前のバージョンの MFP Analytics とはまったく異なります。

アプリケーション・セッション数は、アプリケーションがバックグラウンドからフォアグラウンドに移されると 1 だけ増やされます。 これを Cordova アプリケーションに対して有効にするには、CLIENT APP LIFECYCLE イベントを有効にする必要があります。 詳しくは、ここを参照してください。

Last modified on October 03, 2018