With app.telemetry, you can create ad-hoc reports about the use of Mindbreeze in the context of search queries any time you want. For example, you can quickly get an overview of frequently searched queries (or alternatively, just queries without hits).
In the report view, you can now carry out analyses according to any dimensions for the selected time period and, if necessary, refine them with restrictions to specific dimension values.
Now, by switching to the dimension "Query" and entering the desired time range, you can pull up a list of the most common search queries.
To pull up only the searches that didn’t result in hits, select the dimension "No Results" and then restrict to the value "TRUE" using "Add Filter".
If you switch back to the dimension "Query" and define the desired time range, you’ll receive a list of all searches without hits for this period.
By default, Mindbreeze already provides a predefined “Mindbreeze – Search Experience“ dashboard for statistics about search usage.
If the number of search queries in an installation is too high and the loading time of this dashboard chart is no longer acceptable (or even results in a timeout), the following two strategies can be used to counter this and to take advantage of the other possibilities of the analysis.
The default setting of these charts can either be edited using the Edit icon in the upper right corner of each chart, or you can use the “Configuration” view to find the configuration objects.
There you can shorten the loading times and also better utilize the background cache using the following two settings:
Increase the update interval of the chart to e.g. one hour:
Decrease the analysis period of 1000 intervals (10 min each − corresponds to approximately one week) to e.g. 300 intervals (10 min each − corresponds to about 2 days).
Or you can configure aggregations on a daily basis to precalculate the values at night - see next chapter.
For longer-term search query analyses, we recommend that you precalculate (aggregate) the data based on a suitable interval. To do this, you can define log pool statistics with the desired interval and the necessary columns. Since this procedure is very installation-specific, you need to consider which data/columns for which period of time are suitable for the aggregation. The following is an example of our best practice.
The DB Table Extension defines a suffix for unique detection in the database. The Database Data Retention settings are used to define the time period for storing the data.
Optionally, a restriction can be defined via the DB filter using SQL conditions (in our case, for example, restricting to search requests for the method “search “... "call:method_name"='search').
Note: The new statistics contain only the columns defined there and, in contrast to the default statistics, do not offer all columns.
General note about dashboard charts based on log pool statistics: The statistics are calculated once a day shortly after midnight. That means that the charts will display usable data only after a few days.
The statistics defined in the previous chapter can also be used to define a dashboard chart with the searches per day.
For problems with app.telemetry the log file "/var/log/app.telemetry/apptelemetryserverd.log" is helpful.
This file is already active on G7 appliances.
On G6 appliances, it must first be activated.
Please add the following directive to the file "/etc/app.telemetry/server.conf":
ProcessOutFile /var/log/app.telemetry/apptelemetryserverd.log
The app.telemetry server service must then be restarted:
service apptelemetry server restart