Häufig gestellte Fragen

In einem Elasticsearch-Cluster mit mehreren Indizes ist es wichtig, Folgendes zu definieren:

• Die Mindestanzahl der Shards muss auf die Anzahl der Knoten im Cluster gesetzt werden.
• Pro Shard müssen mindestens zwei Replikate festgelegt werden.

MobileFirst Analytics Version 8.0 verwendet mehrere Indizes, um die Ereignisdaten zu speichern.

In MobileFirst Analytics Version 8.0 hat der Elasticsearch-Datenspeicher mehrere Indizes. Es handelt sich nicht um einen Datenspeicher, der auf nur einem Index basiert. Je nach Art der Ereignisse, die in die Analyse einfließen, werden dynamisch Indizes erstellt. Die Endbenutzer müssen also nicht wegen der zahlreichen Indizes besorgt sein. Jeder Index innerhalb von Elasticsearch wird gemäß der in der Konfigurationsdatei festgelegten Anzahl von Shards aufgeteilt.

Sie müssen mit dem Hardware Sizing Calculator überprüfen, ob die Hardware für die Daten und Anforderungen des Kunden ausreichend ist. Die Leistung des Systems wird durch verschiedene Faktoren beeinflusst, zu denen die Hardware gehört sosie der Typ oder die Größe von Datenereignissen, die zum Analyseserver gelangen, und der Umfang dieser Ereignisse.

Nein. Wenn die Daten gelöscht sind, können sie nicht wiederhergestellt werden.

Die TTL-Eigenschaften werden nicht auf Daten der Analytics-Plattform angewendet. Sie müssen die TTL-Eigenschaften festlegen, bevor Sie Daten hinzufügen.

Stellen Sie sicher, dass mit den JNDI-Eigenschaften von MobileFirst Server die richtigen Analytics-Endpunkte konfiguriert wurden. Vergewissern Sie sich, dass der Datumsfilter für die anzuzeigenden Daten ordnungsgemäß definiert ist.

Zum Aufrufen der REST-APIs von Elasticsearch muss die Eigenschaft analytics/http.enabled in der Datei server.xml von Analytics Server auf true gesetzt sein.

Nein. Wenn Sie IBM WebSphere Application Server Full Profile oder Network Deployment (ND) verwenden, müssen Sie das IBM JDK verwenden, das zusammen mit WebSphere Application Server bereitgestellt wird.

Wenn die Anwendung zum ersten Mal geöffnet wird, gibt es null App-Sitzungen. Wenn der Endbenutzer die mobile App in den Hintergrund stellt und dann wieder in den Vordergrund holt, erhöht diese Aktion die Anzahl der App-Sitzungen auf 1. Bei jeder Wiederholung dieser Aktion erhöht sich die Anzahl der App-Sitzungen weiter.

Die Anzeige von GELB für den Clusterzustand muss kein Problem sein. Meistens gibt es nicht zugeordnete Shards, wenn für den Clusterzustand GELB angezeigt wird. Wenn neue Knoten in den Cluster aufgenommen werden, ordnet Elasticsearch nicht zugeordnete Shards den neuen Knoten zu. Dadurch wechselt der Clusterzustand zu GRÜN. Wenn es zu viele Shards gibt, kann es vorkommen, dass einige der Shards keinem Knoten zugeordnet werden. In dem Fall wird GELB für den Clusterzustand angezeigt. Stellen Sie sicher, dass alle Knoten im Cluster aktiv sind und ordnungsgemäß funktionieren und dass die Shards den Zustand "gestartet/aktiv" haben.

Bei Web-Apps wird die Anzahl der App-Sitzungen ausgehend von den Browsersitzungen erhöht und basiert auf der Verbindung vom Browser (d. h. von der App) zu MFP Server.

Wenn der Browser das allgemeine Fenster bzw. die allgemeine Registerkarte verwendet und eine Verbindung zum Server herstellt, wird die Anzahl der App-Sitzungen um eins erhöht. Wenn der Benutzer die App in demselben Browser auf einer anderen Registerkarte öffnet und die Verbindung herstellt, erhöht sich die Anzahl der Sitzungen nicht. Die Sitzung bleibt für 30 Minuten inaktiv. Wenn Sie versuchen, die Verbindung erneut herzustellen, wird die Anzahl um eins erhöht.

Wenn der Benutzer den Browser-Cache löscht und dann versucht, eine Verbindung herzustellen, wird das Gerät als neues Gerät angesehen, sodass sich die Geräteanzal erhöht. Da Browser keine reale Geräte-ID haben, wird eine ID für die Browser-App generiert, bis die Offlinedateien bzw. die Cache-Inhalte gelöscht werden.

Dies gilt auch für ein privates Browserfenster. Wenn Sie ein privates Browserfenster verwenden und versuchen, eine Verbindung herzustellen, wird jede App, die von einer Registerkarte aus eine Verbindung herstellt, als eine neue Sitzung betrachtet und somit die Sitzungsanzahl erhöht. Wenn der Benutzer zwei verschiedene Browser verwendet und auf die App zugreift, um eine Verbindung zu MFP Server herzustellen, wird der Gerätezähler um zwei erhöht.

Aktive Benutzer sind die Benutzer, die die App verwenden. Jeder eindeutige Benutzer wird als ein Benutzer, der die App verwendet, gezählt. Die Geräte-ID ist standardmäßig die Benutzer-ID. Der App-Entwickler kann allerdings die API setUserContext(userid) verwenden, um die Benutzer-ID durch den von ihm festgelegten Wert zu ersetzen.

Eine Lösung bzw. ein Ansatz ist, eine eindeutige ID vom Computer zu generieren, wenn der Benutzer auf die Web-App zugreift und der Computer dies als customData sendet. Diese Daten können genutzt werden, um die Statistik für die tatsächlichen Maschinen (oder Computer/Browser) zu berechnen, von denen aus der Benutzer auf die App zugreift und setUserContext verwendet, um die Benutzer-ID festzulegen. Mithilfe dieser Daten können auch kundenspezifische Diagramme generiert werden.

In Analytics 8.0 erfolgt die Berechnung von App-Sitzungen grundsätzlich anders als in den Vorgängerversionen von MFP Analytics.

Die Anzahl der App-Sitzungen wird um eins erhöht, wenn die App vom Hintergrund in den Vordergrund gebracht wird. Um dies für Cordova-Apps zu ermöglichen, müssen Ereignisse vom Typ CLIENT APP LIFECYCLE aktiviert werden. Weitere Informationen finden Sie hier.