How BigFix manages BigFix Query requests
A BigFix Query request is processed in a sequence of customizable steps.
The following picture shows the internal flow of a BigFix Query. Each step lists which variables you can configure to tune how BigFix Query requests and responses are managed.
- The operator that logged on to the WebUI submits a request from the BigFix Query Application.
- What can you customize for this step?
- You can decide to run this step as an operator that is not a master operator. In this case ensure that either the operator permissions or the permissions specified in the role assigned to the operator contain the Can Submit Queries value set to Yes.
Note: If you are using the REST API to manage the query, be aware that only the operator issuing the query can see its responses. - The submitted request is propagated through the relay hierarchy to the target clients using
dedicated memory queues on each relay. This ensures that the request quickly reaches the targets
without impacting normal BigFix
processing. If a target or a child relay does not answer within a given amount of time, then it is
no longer requested to answer.
- What can you customize for this step?
- From the BigFix Console you can
customize, for the server and for each relay, how the memory queues are cleaned up:
- How often the cleanup task is run.
- The default value is 10 minutes and the name of the setting is _BESRelay_Query_RemovalTask.
- How long a request can stay in the queue before being deleted by the cleanup task.
- The default value is 60 minutes and the name of the setting is _BESRelay_Query_MinTime.
- The maximum size of the memory queue dedicated to BigFix Query requests.
- Before running the cleanup task, BigFix checks if the size of this memory queue exceeds the maximum size specified. If it exceeds, when the cleanup task runs, it removes the entries in the queue until the size of the queue returns within the threshold. The default value is 100 MB and the name of the setting is _BESRelay_Query_MemoryLimit.
- When the request reaches the target client parent relay, the relay informs the client, using the UDP protocol, that there is a new request to process, and, in turn, the agent retrieves the request.
- For each responsive target, the client passes the query to the local QnA to run the query and
return the results.
- What can you customize for this step?
- From the BigFix Console you can
customize for the client:
- How long can the QnA process a query issued by a Master Operator before the request timeout elapses
- The default value is 60 seconds and the name of the setting is _BESClient_Query_MOMaxQueryTime.
- How long can the QnA process a query issued by a Non Master Operator before the request timeout elapses
- The default value is 10 seconds and the name of the setting is _BESClient_Query_NMOMaxQueryTime.
- How long the QnA waits for new queries to process before stopping.
- The default value is 600 seconds and the name of the setting is _BESClient_Query_IdleTimeout.
- How much CPU is used by the QnA process running the query.
- You can limit the CPU used by the QnA process by defining time slots during which the QnA runs. By default the QnA processing the query runs for 10 milliseconds and then sleeps for 480 milliseconds, which corresponds to a CPU usage lower than 1-2 %, and the name of the settings that define this behavior are _BESClient_Query_WorkTime and _BESClient_Query_SleepTime.
Note: These settings are not considered when running the QnA tool connected as local user to the client system. - When the agent receives the response from the QnA, it creates a report containing the response and delivers it to the parent relay in parallel the other reports.
- The report is delivered back to the server through the relay hierarchy. On each relay the report
is stored in a memory queue while waiting to be delivered to the parent relay. If the parent relay
is not available, the report waits in the queue and is delivered as soon as the parent relay becomes
available again. The same criteria for encryption and signing used for normal reports are applied
also to these reports.
- What can you customize for this step?
- From the BigFix Console you can
customize for each relay:
- The maximum size of the memory queue dedicated to BigFix Query results.
- Before running the cleanup task, BigFix checks if the size of this memory queue exceeds the maximum size specified. If it exceeds, when the cleanup task runs, it removes the entries in the queue until the size of the queue returns within the threshold. The default value is 100 MB and the name of the setting is _BESRelay_Query_ResultsMemoryLimit.
- When the server receives the result, it stores it in a dedicated queue from where a dedicated
FillDB thread gets the data to store it in the database. In this way, the normal processing on the
BigFix server is not impacted.
The database stores, for a specified time period, both the BigFix Query request and its responses, that can be used, for example, to be filtered, displayed, or to create reports. On a timely basis the BigFix Query Application checks the database for updates and updates the displayed results accordingly.
- What can you customize for this step?
- From the BigFix Administrative Tool
you can customize on the server:
- For how long the BigFix Query requests are stored in the database before being deleted.
- The default value is 1440 hours (60 days) and the name of the advanced option is queryHoursToLive.
- For how long the BigFix Query responses are stored in the database before being deleted.
- The default value is 4 hours and the name of the advanced option is queryResultsHoursToLive.
- How many requests and responses, for which queryHoursToLive or queryResultsHoursToLive elapsed, are deleted at a time from the database.
- The default value is 100000 entries and the name of the advanced option is queryPurgeBatchSize.
For information about how to edit computer settings, see Edit Settings for Computer.