|
The following logs are available for troubleshooting. Depending on the type of investigation, output from multiple logs can be correlated.
Log Name | Description and Uses | uptime.conf parameter and values | |
---|---|---|---|
uptime.log | This is the base Uptime Infrastructure Monitor log. System events are automatically recorded to these weekly logs, which follow the You can determine the type of system information Uptime Infrastructure Monitor writes to the log (ranging from verbose, to informational, to critical errors) by setting the logging level. The default setting, |
| |
uptime_diagnostics.log | This log is similar to the Like the |
| |
uptime_exceptions.log | All DEBUG -level Java runtime exceptions evoked by Uptime Infrastructure Monitor actions. Full stack traces are channeled to this log to lighten and accompany the core uptime.log and uptime_diagnostics.log files. Use the context marker in the core log to find the exception in this log. | N/A | |
uptime_console.log | All Java-related command-line feedback based on Uptime Infrastructure Monitor activity is routed to this log, providing extra information that may not be captured in the standard Uptime Infrastructure Monitor log. | N/A | |
audit.log | Uptime Infrastructure Monitor can record changes to the application’s configuration in an audit log, and is essentially a record of which user performed which action, and when. The following is an example of an audit log entry:
There are many uses for the audit log. For example, you can use it to track changes to your Uptime Infrastructure Monitor environment for compliance with your security or local policies. You can also use the audit log to debug problems that were introduced into your Uptime Infrastructure Monitor installation by a specific configuration change; the audit log enables you to determine who made the change and when it took effect. By default, the |
| |
uptime_access.log | A summary of which Uptime Infrastructure Monitor access-related actions, mainly database queries, were evoked by which service or user, and the execution time. This database-focused log can be used in conjunction with the more user-focused | N/A | |
thirdparty.log | Aggregation of warnings and errors logged by third-party libraries that Uptime Infrastructure Monitor is using, such as the iReasoning library for SNMP monitoring. Correlating these with the other logs may help with investigation. | N/A | |
| When SQL logging is enabled with the assistance of IDERA Customer Support, these log shows all SQL queries, with and without execution time, respectively. Queries in uptime_sql.log are listed before execution, which can be compared with the second log to determine conflicts and deadlocks. | contact IDERA Customer Support |
When you encounter a problem with Uptime Infrastructure Monitor, IDERA Customer Support needs a specific set of information to diagnose and fix the problem. Uptime Infrastructure Monitor can automatically collect this information and compress it in an archive which you can send to Customer Support.
The archive contains the following:
hs_err_pid
error filesThe archive is saved to the GUI/problemreports
directory on the Monitoring Station and has a file name with the following format:
prYYYYMMDD-HHMMSS.zip |
YYYYMMDD
is the date on which the report was generated (for example, 20101224
).HHMMSS
is the time at which the report was generated (for example, 202306
).To generate a problem report, do the following:
dbchecker
script with the default values on your DataStore. This integrity test allows you to ensure there are no database issues that are part of, or are at the root of the problem. Disable this check box to improve generation performance by skipping the database check.