Mit app.telemetry lassen sich auf Wunsch jederzeit ad-hoc Reports zur Nutzung von Mindbreeze im Rahmen von Suchanfragen erstellen. Damit kann man zum Beispiel schnell einen Überblick über häufige gestellte Suchanfragen (auf Wunsch auch nur jene ohne Treffer) bekommen.
Auf der Report-Ansicht kann man nun Auswertungen nach beliebigen Dimensionen für den gewählten Zeitraum durchführen und bei Bedarf um Einschränkungen auf konkrete Dimensionswerte verfeinern.
Nun kann man bei Wechsel auf Dimension „Query“ und Einstellung des gewünschten Zeitbereichs die häufigsten Suchanfragen auflisten.
Um dediziert nur jene Suchen ohne Treffer zu bekommen, wählt man als Dimension „No Results“ aus und schränkt anschließend auf den Wert „TRUE“ per „Add Filter“ Aktion ein.
Wenn man nun erneut auf Dimension „Query“ wechselt und den gewünschten Zeitbereich definiert bekommt man alle Suchen ohne Treffer für diesen Zeitraum.
Mindbreeze bietet standardmäßig bereits ein vordefiniertes Dashboard zum Thema „Nutzungsstatistik der Suche“ („Mindbreeze – Search Experience“).
Ist die Anzahl der Suchanfragen in einer Installation zu hoch und die Ladezeit dieser Dashboard-Charts nicht mehr annehmbar (oder es kommt sogar zu Timeouts bei der Darstellung), kann man über folgende 2 Varianten dem entgegensteuern sowie von den weiteren Möglichkeiten der Auswertung profitieren.
Die Standard-Einstellung dieser Charts kann man entweder über das Edit-Icon in der rechten oberen Ecke jedes Charts bearbeiten oder man findet die Konfigurations-Objekte auch auf der „Konfigurations“-Ansicht.
Dort kann man nun über folgende 2 Einstellungen die Ladezeiten verkürzen bzw. die Hintergrund-Cache besser ausnutzen:
Aktualisierungsintervall des Chart auf z.B. 1 Stunde erhöhen.
Auswertungszeitraum von 1000 Intervallen (je 10 min … entspricht in etwa einer Woche) auf z.B. 300 Intervalle (je 10 min … entspricht in etwa 2 Tagen) verkürzen.
Oder aber man konfiguriert Aggregationen auf Tages-basis zur nächtlichen Vorberechnung der Werte – siehe nächstes Kapitel.
Für längerfristige Auswertungen der Suchanfragen empfehlt es sich die Daten auf Basis eines passenden Intervalls vorauszuberechnen (zu aggregieren). Hierzu gibt es die Möglichkeit Logpool Statistics mit gewünschtem Intervall und den notwendigen Spalten zu definieren. Da dies sehr installationsspezifisch ist, muss man überlegen, welche Daten/Spalten sich gut für die Aggregation in welchem Zeitraum eignen. Im Folgenden ist ein Beispiel unserer Best-Practice beschrieben.
Wichtig: Beachten Sie, dass die Dimensionswerte für das gewählte Intervall (1440 Minuten = 1 Tag) gut aggregiert werden können und keine Random-Werte enthalten sind. Sinn der Aggregation ist die Zeilenanzahl der Einzelrequests auf den ganzen Tag summiert stark zu reduzieren.
Über die DB Table Extension wird ein Suffix für eine eindeutige Erkennung auf der Datenbank definiert. Wobei mittels Database Data Retention Einstellungen der Zeitraum der Aufbewahrung der Daten festgelegt wird.
Optional kann über den DB Filter mittels SQL-Bedingungen eine Einschränkung definiert werden können (in unserem Fall z.B. die Einschränkung auf Such-Requests der Methode ‚search‘ … "call:method_name"='search')
Hinweis: die neue Statistik enthält nur die dort definierten Spalten und bietet im Gegensatz zur Default-Statistik nicht alle Spalten an.
Allgemeiner Hinweis zu Dashboard Charts basierend auf Logpool Statistiken. Die Statistiken werden einmal täglich kurz nach Mitternacht berechnet. D.h. die Charts werden erst nach ein paar Tagen brauchbare Daten anzeigen.
Diese im vorigen Kapitel definierten Statistiken können auch genutzt werden um ein Dashboard Chart mit den Suchen pro Tag zu definieren.
Bei Problemen mit der app.telemetry is die Log-Datei „/var/log/app.telemetry/apptelemetryserverd.log“ hilfreich.
Auf G7 Appliances ist diese Datei bereits aktiv.
Dazu fügen sie bitte folgende Direktive in die Datei „/etc/app.telemetry/server.conf“ ein:
ProcessOutFile /var/log/app.telemetry/apptelemetryserverd.log
Danach muss der app.telemetry Server Dienst neu gestartet werden:
service apptelemetryserver restart
Problem: Das Feature „Suchvorschläge“ arbeitet sehr langsam oder gar nicht. Dies kann viele Ursachen haben. Eine der Ursachen kann sein, dass die Anzahl der Zeilen im Logpool zu hoch ist. Um die Performance der Suchvorschläge zu verbessern, stehen zwei Lösungen zur Verfügung.
Hinweis: Es ist auch möglich zu überprüfen, ob die Größe der Tabellen die Performance-Probleme bei den Suchvorschlägen verursacht. Öffnen Sie im Management Center den Menüpunkt „Reporting“ und klicken Sie auf „Telemetrie Details“. Klicken Sie dann auf „Konfiguration“ und erweitern Sie in der Strukturansicht den Punkt „Database Connectors“. Klicken Sie mit der rechten Maustaste auf „telemetrydb“ und wählen Sie die Option „View Database Tables“.
Im neuen Fenster haben Sie nun einen Überblick über alle Datenbanktabellen und können beispielsweise die Größe jeder Tabelle oder den aktuellen Status überprüfen. Überprüfen Sie, ob das Performance Problem bei den Suchvorschlägen durch die Größe einer oder mehrerer Datenbanktabellen verursacht wird.
Die Performance der Suchvorschläge kann verbessert werden, indem die Einstellung „Database Data Retention“ auf einen kürzeren Zeitraum angepasst wird.
Gehen Sie im Management Center zu „Reporting“ und „Telemetrie Details“ und öffnen Sie das Menü „Configuration“. Klicken Sie in der Strukturansicht mit der rechten Maustaste auf „Client Service“ und wählen Sie die Option „Edit“.
Im neuen Fenster finden Sie die Einstellung „Database Data Retention“ und können nun die Einstellung auf einen kürzeren Zeitraum ändern.
Klicken Sie auf „OK“, um die Änderungen zu speichern. Nun sollte die Performance der Suchvorschläge verbessert sein.
Wenn die Anpassung der Einstellung „Database Data Retention“ nicht möglich ist oder die Performance nicht ausreichend verbessert wurde, kann die Datenbanktabelle durch die Konfiguration von Log Pool Statistic in app.telemetry und Popular Searches im Client Service auf die notwendigen Anfragen reduziert werden. Die erforderlichen Schritte werden in den folgenden Kapiteln beschrieben.
Gehen Sie im Management Center zu „Reporting“ und öffnen Sie das Untermenü „Telemetrie Details“. Klicken Sie auf „Configuration“, um die Strukturansicht anzuzeigen.
Um das erforderliche Log Pool Statistic zu erstellen, gehen Sie zu „Log Pool Statistics“ und erstellen Sie eine neue Log Pool Statistic mit „New Log Statistic“ oder verwenden Sie eine bereits vorhandene.
Konfigurieren Sie die Log Pool Statistic wie folgt:
Einstellung | Eingabe |
Name | Beispiel: Client Popular Searches (day) |
Log Statistics Active | Aktiviert |
Time Resolution (Interval) | Empfohlenes Interval: 1440 Minuten (= 24 Stunden) |
Calculation Schedule | 10 |
DB Table Extension | clientqueriespopularday |
DB Filter (SQL syntax) (Optional) | Für weitere Verbesserungen ist es auch möglich, einen Filter zu definieren, um beispielsweise leere Suchanfragen oder Suchanfragen, bei denen Suchvorschläge nicht benötigt werden, auszuschließen, z. B. eine Suche mit einem Stern (*): "call:method_name"='search' AND "search:result_count" > 0 AND "search:user_query_expr"<>'' AND "search:user_query_expr"<>'ALL' AND "search:user_query_expr"<>'*' AND "search:user_query_expr"<>' initialemptyquery' |
Database Data Retention | Standardmäßig aktiviert und auf 25 Tage eingestellt. Um die Suchvorschläge-Funktion nicht einzuschränken, kann sie auch auf einen längeren Zeitraum eingestellt werden, beispielsweise 90 Tage. |
Dimension Name | Die folgenden Dimensionen sind erforderlich, damit die Konfiguration der Popular Searches im nächsten Schritt funktionieren kann.
Hinweis: Um einen „Dimension Name“ auszuwählen, muss zunächst in der nachfolgenden Einstellung „Statistics used in following Log Pools“ ein Log Pool hinzugefügt werden. |
Statistics used in following Log Pools | Fügen Sie den ursprünglichen Client Service Log Pool hinzu, um in der Einstellung „Dimension Name“ Dimensionsnamen auswählen zu können:
Hinweis: Wenn ein „Filtered Log Pool“ konfiguriert ist, kann er ebenfalls hier hinzugefügt werden. Zum Beispiel:
Für mehr Informationen, siehe das Kapitel Optionaler Schritt: Konfiguration eines Filtered Log Pool. |
Klicken Sie auf „OK“, um die Erstellung des Log Pool Statistic abzuschließen.
Achtung: Beachten Sie, dass das Log Pool Statistic über Nacht erstellt und am nächsten Tag wirksam wird. Warten Sie daher bitte bis zum nächsten Tag, um zu sehen, ob das Log Pool Statistic wie vorgesehen funktioniert.
Nachdem das Log Pool Statistic konfiguriert wurde, muss der Client Service angepasst werden, um die von der konfigurierten Log Pool Statistic vorbereiteten Daten zu übernehmen.
Gehen Sie im Management Center im Menüpunkt „Konfiguration“ zum Tab „Client Service“ und aktivieren Sie „Advanced Settings“. Öffnen Sie den von Ihnen verwendeten Client Service und gehen Sie zum Abschnitt „Suggest Settings (Similar Terms)“. Nehmen Sie die folgenden Einstellungen vor:
Einstellung | Eingabe |
ID | popularsearches |
Source Name | Popular Searches |
Database JDBC URL | Die URL hat die folgende Struktur: jdbc:postgresql://HOSTNAME:PORT/DATABASE?user=USERNAME&password=PASSWOR Beispiel: jdbc:postgresql://myhost:5555/mytelemetrydb?user=mytelemetryuser&password=MyPassword Hinweis: Das Passwort ist das von Mindbreeze bereitgestellte Standardpasswort. Sie können die Verbindung zur Datenbank in app.telemetry im Menüpunkt „Configuration“ testen. Erweitern Sie in der Strukturansicht „Database Connections“, klicken Sie mit der rechten Maustaste auf „telemetrydb“ und wählen Sie die Option „Edit“. Klicken Sie im neuen Fenster auf den Knopf „Test“, um die Verbindung zur Datenbank zu testen. |
Max Number Of Database Connections | 10 |
Table Name | Definiert die notwendige Datenbanktabelle, in der die Ergebnisse der konfigurierten Log Pool Statistic gespeichert werden. Der Tabellenname ist im Menüpunkt „Configuration“ in app.telemetry zu finden. Erweitern Sie in der Strukturansicht „Database Connections“, klicken Sie mit der rechten Maustaste auf „telemetrydb“ und wählen Sie die Option „View Database Tables“. Beispiel: clientqueriespopulardaystatvalue Achtung: Bitte beachten Sie, dass sich der Tabellenname ändern kann, wenn beispielsweise zu einem späteren Zeitpunkt ein Filtered Log Pool konfiguriert wird. Stellen Sie sicher, dass der Tabellenname immer korrekt ist. Beispiel:
|
Table Column for Query | search:user_query_expr |
Table Column for Score | count |
Table Column for View ID | terminationCause:view |
Additional WHERE Clause (Optional) | Alternativ kann die folgende Where-Klausel definiert werden, um Vorschläge auszuschließen, die älter als einen Monat sind: timestamp > CURRENT_DATE - INTERVAL '1 month' AND "search:user_query_expr" !~ '["():]|OR|NEAR|AND|ALL|initialemptyquery' Beachten Sie, dass diese Klausel nur Vorschläge ausschließt, die älter als einen Monat sind und nicht die Performance der Suchvorschläge verbessert. Die Klausel kann auch zu einem späteren Zeitpunkt hinzugefügt werden. |
Suggest If User Query Is Empty | Aktiviert |
Speichern Sie abschließend die Änderungen, um die Konfiguration abzuschließen.
Nachdem die Konfiguration des Log Pool Statistic und der Popular Searches abgeschlossen ist, sollten die Suchvorschläge wieder funktionieren und/oder die Performance verbessert sein.
Die Performance der Suchvorschläge kann durch die Konfiguration eines Filtered Log Pool weiter verbessert werden. Die notwendigen Schritte werden nachfolgend beschrieben.
Gehen Sie im Management Center zu „Reporting“ und öffnen Sie das Untermenü „Telemetrie Details“. Klicken Sie auf „Configuration“, um die Strukturansicht anzuzeigen.
Um das Filtered Log Pool zu erstellen, erweitern Sie den Abschnitt „Log Pools“, klicken Sie auf „Client Service“ und erstellen Sie einen neuen Filtered Log Pool mit „New Filtered Log Pool“ oder verwenden Sie einen bereits vorhandenen.
Konfigurieren Sie im Fenster „Filtered Log Pool Properties“ die folgenden Einstellungen:
Einstellung | Eingabe |
Name | Beispiel: Client Service User Queries (only search) |
Log Pool Active | Aktiviert |
Restrict Access to User/Group | apptelemetryusers |
Labels | Mindbreeze |
Filter Rules |
Achtung: Beachten Sie, dass die letzte Filterregel den Regeltyp „Accept“ haben muss, um sicherzustellen, dass alle Filterregeln ausgeführt werden. |
Database (for Persisting Logs) | telemetrydb |
Database Table Prefix | clientonlysearch |
Database Data Retention | Aktiviert und auf 400 Tage gesetzt. |
Um die erforderliche Filterregel „only search requests“ zu konfigurieren, sind die folgenden Einstellungen erforderlich:
Einstellung | Eingabe |
Name | Beispiel: only search requests |
Active | Aktiviert |
Rule Type | Accept |
Filter Rule | Konfiguriere die Filterregel folgendermaßen: Method = search |
Je nach Anwendungsfall können auch zusätzliche Filterregeln konfiguriert werden. Um beispielsweise Performance Tests auszuschließen, kann die optionale Filterregel wie folgt konfiguriert werden:
Einstellung | Eingabe |
Name | Beispiel: exclude performance tests |
Active | Aktiviert |
Rule Type | Deny |
Filter Rule | Konfiguriere die Filterregel folgendermaßen: Referer begins with performancetest |
Um Benachrichtigungen auszuschließen, kann die optionale Filterregel wie folgt konfiguriert werden:
Einstellung | Eingabe |
Name | Beispiel: exclude notifications |
Active | Aktiviert |
Rule Type | Deny |
Filter Rule | Konfiguriere die Filterregel folgendermaßen: Notification is set |
Klicken Sie auf „OK“, um die Definition der Filterregeln und die Konfiguration des Filtered Log Pool abzuschließen.
Aufgrund der Konfiguration des Filtered Log Pool muss schließlich die Einstellung „Table Name“ im Client Service angepasst werden, wie in der Beschreibung der Einstellung erwähnt. Weitere Informationen finden Sie im Kapitel Schritt 2: Konfiguration des Client Service.