Reference: Trends data collection for saved question sources
Learn how saved question sources collect data so that the panels you design in Trends appropriately display the results that you want to analyze.
A saved question in a saved question source can ask for results from one sensor. The sensor can be a single column sensor, a multicolumn sensor, or a parameterized sensor. If you use a multicolumn sensor, you must choose the result column (field) to use when you create a panel that uses the corresponding saved question source.
Trends stores results as counts of the answers returned when sensors run on the Tanium Client. Most sensors return numeric results that can be meaningfully counted. For example, the question Get Running Applications from all machines returns counts of the application versions found in running processes on endpoints.
When you create a saved question source in Trends, the Question Builder is available to build the saved question. Before you save the saved question source, you can run the question to preview the results. Evaluate whether the result strings can be meaningfully counted and whether question filters are required. Avoid using questions that return unique strings, such as Computer Name or IP address, because there is little value in aggregate counts of these answers. If a source returns more than 100,000 unique results in a day, Trends only stores the 100,000 results with the highest counts.
When the Tanium Server issues a saved question for a saved question source, the results are temporarily stored in the Tanium Server cache. When a source collection is initiated, Trends retrieves the cached results, aggregates the results as single day counts, and stores the data in a dedicated Trends database on the Module Server.
For each saved question source, you can configure how often to issue the saved question, and how often to collect the data from the Tanium Server cache. When Trends collects the data, Trends aggregates the data and updates any panels that use the source. You can find these settings in the Source Intervals section when you create or edit a source.
The process of collecting data from the Tanium Server is also called a source run or collection.
For each source, Trends only stores one set of results for each endpoint for a one day period. If a source issues a saved question multiple times in a day, Trends stores the latest results of the saved question for each endpoint. For most sources, you should reissue the saved question approximately every five hours and collect the data every 24 hours. This frequency is intended to get responses from endpoints that are offline sometimes during a one day period, but are online at one of the times the saved question is issued. When Trends collects data for a saved question source, Trends issues the saved question one more time to get the most recent results.
- If endpoints are online during shorter timeframes, consider setting a higher frequency to reissue the saved question.
- The frequency to collect data largely depends on how often you want to access the information in Trends, and how often you expect the data to change. If you need to view updated data in the charts multiple times per day, either set a more frequent collection schedule or manually collect data through the Run Now button.
- If your charts display counts from Online and most recent offline endpoints, consider a lower collection frequency. For more information, see Answers from online and offline endpoints.
Trends collects data for each saved question source with minor offsets to avoid traffic spikes. If Trends collects data at an unsuitable time, you can edit the saved question source to change the collection schedule. For optimal results, saved question sources should collect results on a routine schedule to maintain similar comparisons. For example, measuring running applications every day at noon provides more accurate data to compare than if you measure running applications some days at noon and some days at midnight.
If a scheduled run fails, you can manually run the saved question source to issue the question and collect results. If results are collected more than once a day, the daily count resolves to the last data that Trends collects that day. For more information, see Working with sources.
Results are reported in Trends as aggregate single day counts based on the timestamps of the collected data. The time and date clock is based on the UTC time of the Module Server (not the local time zone adjusted time). For example, a panel configured to show Chassis Type on December 31 includes the counts of the responses that Trends collects on December 31 UTC time.
The Tanium Client is deployed to a broad spectrum of enterprise assets, including infrastructure servers, employee workstations, and employee laptops. Each of these assets is an endpoint that may be online or offline. While infrastructure servers are almost always online, employee workstations or laptops may be online or offline according to employee schedules and habits.
When the Tanium Server issues a saved question, an endpoint that is online sends its current response to the question; if the endpoint is offline, the Tanium Server may have a recent value for it. The Tanium Server tallies counts for both types of answers.
The online and offline statuses relate to the time when Trends collected results, not the present time. For example, Trends collects data at 9:00 UTC for a source that queries Get Reboot Required from all machines, and the data for Online clients and Online and most recent offline clients are tallied at that point in time. Online clients are endpoints that responded to the question within the last 24 hours. Online and most recent offline clients are endpoints that responded within the last week.
Note that the time of day that Trends collects data might impact the count recorded, depending on business practices such as maintenance operations. For example, if Trends collects data for a source at 2:00 UTC, and 2:00 UTC is during a daily maintenance window where maintenance processes might put more machines in a state requiring reboot, then the counts for Get Reboot Required from all machines would routinely be higher.
Last updated: 12/2/2020 9:32 AM | Feedback