The monitoring manager, scheduled on its own thread, informs other parts of the data component about servers for which it has received information, and how to monitor these servers. If possible, the monitoring manager runs attached to a user-type hardware thread (in a user core). The code for the monitoring manager is in the file
The monitoring manager logs a message to syslog when a server's state changes. The maximum frequency of these updates depends on the monitor's configuration.
By default, the status of a given server is down until the monitoring service can reach the server. (The exception is that servers that are not monitored have no status updates since they are assumed to be up without verification.) Servers found to be up are inserted into a list of servers for that application, and the data component logs a message to syslog. Correspondingly, servers found to be down are deleted from the list, and again, a state transition message is logged.
To help clients reach a new server, the monitoring manager also iterates over the session entries in the flow table, searching for flows that are using the server, and removes any entries it finds. (For details about the flow table, see Maintaining Session Information.)
The aging manager sends updates about the number of sessions that are assumed to still be active. The code for the aging manager is in the function
aging_cleanup() in the file
The aging manager is scheduled to run every 15 seconds, but the content of the message (the number of active flows) again depends on the
session-timeout value. You can usually expect larger numbers when a longer
session-timeout value is configured.
The aging manager iterates over the lookup table entries and removes expired session entries. To do this, it compares the current time to the session expiration time that was last updated when a packet passed through the system matching this session. While performing this iteration, the aging manager also counts the number of active sessions for each application in each service set. When the iteration has finished, it reports these counters to the management component.
Although the status updates come from data-component managers running on separate threads, the update messages are funneled into a common channel, so that only one connection to the management component is needed.
Maintaining Session Information