Setting Timing for Monitoring

Overview

By default, the settings on this page affect all devices that are monitored in the relevant monitoring mode (real time, periodic polling, or OS monitoring). The administrator can override these settings, for each specific monitored device, in the properties for that device (Monitoring > Devices > select device > Edit configuration). In some cases, the monitoring mode itself can be set there as well.

Polling and fetching, as described on this page, are the same action. This action initially sends a request, from TOS to the device, to receive policy data. TOS then compares this data with the last revision received and if there is a difference, the newly updated policy from the device appears in TOS as a new revision. The difference between polling and fetching is in the context in which they are used.

Starting from R25-1 PHF1.0.0, TOS Aurora uses a dynamic polling interval for devices based on revision processing time which improves stability by preventing a backlog of accumulated revisions. This will override previously defined polling intervals.

Monitoring settings

Setting Group	Description	Vendors
Monitoring	Real Time Monitoring 'Save policy' interval (Applies only to Check Point management servers): When a Save Policy event is followed within this time interval by an Install Policy event for the same policy, SecureTrack tries to combine the two events into a single revision (default: 60 seconds). 'Install policy' interval: When two or more Install Policy events for the same policy occur within this time interval, SecureTrack combines the events into a single Install Policy revision (default: 60 seconds). Automatic fetch frequency: Applies to devices that have been configured to use syslog to notify TOS when there are policy changes. Its purpose is to initiate a check for policy changes in case syslog messages are not received for more than the time specified. This ensures that the device will be checked for policy changes even if there is no syslog communication, due to network failure or any other reason (frequency (in minutes).	Check Point management devices, and to Cisco, Fortinet, and Juniper, and Palo Alto devices that have been configured to send syslogs to SecureTrack (unless in the device's properties real-time monitoring has been disabled)
	Periodic Monitoring Polling Frequency: Determines the frequency at which SecureTrack fetches the configuration from each device. To select an exact time for daily polling, set the polling frequency specifically for each device, in the device's properties.	TOP, Palo Alto, Juniper, Fortiner, F5 BIG-IP LTM, Cisco devices and cloud providers that do not send syslogs or have had real-time monitoring disabled in the device properties
	Management Periodic Monitoring Polling Frequency: Determines the frequency at which SecureTrack fetches the configuration from each device. To select an exact time for daily polling, set the polling frequency specifically for each device, in the device's properties.	Stonesoft SMC, Panorama, Fortianager, Cisco FMC, Cisco ACI and Arista EOS that do not send syslogs or have had real-time monitoring disabled in the device properties
	OS Monitoring: Polling frequency: How often SecureTrack fetches the configuration from each device. Timeout: Controls how long SecureTrack waits for a response from device before giving up. This setting is used in case a device is down or too busy. Retries: Number of attempts that SecureTrack will make.	N/A
Database Update	Rule and Object Usage Write to database every: Dictates the frequency with which SecureTrack updates its database. The default is every 3600 seconds (1 hour), but this can be changed. When you increase this time, you increase the amount of memory used, but have fewer write actions to the database, which in turn means a smaller amount of disk is required to store the same amount of data. Changing the default database update frequency may adversely affect the responsiveness of your system. Contact Tufin Support before making any changes to the default value.	Does not apply to Cisco devices
SSH/Telnet session timeout	Length of time that SecureTrack waits for a response from device before giving up. This setting is used in case a device is down or too busy. Applies to Automatic fetch (for real-time monitored devices) and to Periodic polling	N/A
SSH host key mismatch handling	Replace SSH host key automatically: Select to replace SSH host key automatically when a new SSH host key is detected for a device. Warning: Automatic replacement of the SSH host key can expose your server to security risks and is not recommended.	N/A

Automatic fetch frequency is typically longer than Polling frequency because with real-time monitoring, frequent notifications are expected to be received from the device's syslog and the action is an additional mechanism that occurs only when syslog notifications are not received at the expected frequency. Polling Frequency is the only method of checking for policy changes for devices that do not have syslog configured. Frequent polling is preferred to maintain a more up-to-date picture of the device policy in TOS.

What Can I do Here?

From the Timing screen, administrators can configure:

Timing values for policy retrieval, device polling, and database updating
SSH host key mismatch handling where you can choose to replace SSH host key automatically when a new SSH host key is detected for a device

For changes to take effect, you must click Save.

How Do I Get Here?

In SecureTrack, go to Monitoring > Timing.