app.telemetry Statistics Regarding Search Queries Ad-hoc reports and statistics dashboard charts
Mindbreeze GmbH, A-4020 Linz, 2022
All rights reserved. All hardware and software names are brand names and/or trademarks of their respective manufacturers.
These documents are strictly confidential. The submission and presentation of these documents does not confer any rights to our software, our services and service outcomes or other protected rights. The dissemination, publication or reproduction hereof is prohibited.
For ease of readability, gender differentiation has been waived. Corresponding terms and definitions apply within the meaning and intent of the equal treatment principle for both sexes.
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).
- Open the "Client Service" log pool in the "Applications" view
- For ad-hoc reports, open the "View Request Statistics" view of the log pool
- If, for instance, you‘d like to limit the report to include only the user search queries (without Suggest, Preview, etc.), start the analysis using the dimension "Method" ...
- ... and then use “Add Filter” to restrict to “search“ requests.
Frequent search queries from the previous month
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.
Searches without hits
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.
Statistics dashboard charts
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.
Optimizing the default settings for a large number of search queries
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.
Log pool statistics for data aggregation
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.
- First you create a new “Log Statistic“ object…
- … and then you select the desired log pool for the aggregations (e.g. Client Service).
- Then, add all the dimension columns that you want to be included in the aggregation, e.g.: Method, No Results, Query, Termination Cause.
Please note: It’s important that the dimension values for the selected interval (1440 minutes = 1 day) can be well aggregated and that no random values are included. After all, the point of the aggregation is to greatly reduce the row number of the individual requests on one day.
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').
- Ultimately, you only need to activate the new statistic for the desired dashboard, i.e. instead of selecting the "<Default Statistic>" you select the newly defined one and then change the period to the newly defined (daily) interval (instead of 1000 x 10 min, it‘s 7 x 1440 min).
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.
Example 2 –Searches per day
The statistics defined in the previous chapter can also be used to define a dashboard chart with the searches per day.
- To do this, you create a new “Top-X Logpool Statistics“ chart.
- Configure an adequate update interval and define the Table chart with the chart data mode “date“.
- For the "Data Source Properties", select the "Client Service" log pool as well as the previously defined daily statistics. Now you can define the number of intervals/days for the time range and group them according to the "Method" column, for instance, to pull up all the searches per day. As a measure for the display, add "Count" to the table using "Add" to get the desired number.
- The result looks something like this:
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":
The app.telemetry server service must then be restarted:
service apptelemetry server restart