|
The following logs are available for troubleshooting. Depending on the type of investigation, output from multiple logs can be correlated.
Log Name | Descroption and Uses | uptime.conf parameter and values | |
---|---|---|---|
uptime.log | This is the base up.time log. System events are automatically recorded to these weekly logs, which follow the You can determine the type of system information up.time 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 up.time 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 up.time activity is routed to this log, providing extra information that may not be captured in the standard up.time log. | N/A | |
audit.log | up.time 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 up.time environment for compliance with your security or local policies. You can also use the audit log to debug problems that may have been introduced into your up.time 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 up.time 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 thirdparty libraries that up.time 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 has been enabled with the assistance of uptime software 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 Customer Support |
When you encounter a problem with up.time, Customer Support needs a specific set of information to diagnose and fix the problem. up.time 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.