Below is a list of the most common log files produced by the application and it's services. These files contain general logging of Integrify events as well as critical and informational messages helpful in troubleshooting if problems occur. If these files become large on your system, you can delete them at any time. Some of these logs will only show up if you have debug turned on in the integrify\app\settings\settings.config file.
We are asked often what to look for in these files when implementing a monitoring tool. The answer is that you probably shouldn't. The Integrify application has numerous self checks embedded in the code. So, even though a message may appear in a log, there is a very good chance that the application already either worked around the issue or retried the same activity successfully before you are even alerted of an error. A good rule of thumb is that the Integrify logs files should only be used to assist in troubleshooting user facing issues. Almost every critical error will have a corresponding negative user interface impact.
integrify\app\scheduler\logs (v6 only):
- <YYYY-MM-DD>_scheduler.log - contains information regarding scheduled reports and processes depending on your logger-config.json configuration.
integrify\app\service:
- <instancename>_exceptions.xml - contains mostly critical and some non critical errors relating to the function of Integrify. Typically errors that cannot get logged to the database because of a database connectivity issue or any other system issues are logged here. If for some reason Integrify does not function after an upgrade or a server reboot / IIS restart, you will want to take a look at this file.
- _<descriptor>_exceptions.xml - contains error messages relating to the descriptor. As an example _connections_exceptions.xml will show errors relating to database connections.
- SystemSettings.log - contains a log of the number of Integrify instances and the number of settings per instance. For most installed customers this should be 1 and 47 respectively. It writes to this file anytime the first user hits the site after an application pool recycle or service restart. This is a verbose log and contains information as well as errors.
integrify\app\webserver\iisnode:
- <servername>-<#>-stderr-<##>.txt - contains both critical and non-critical messages relating to the function of Integrify. If for some reason Integrify does not function after an upgrade or a server reboot / IIS restart, you will want to take a look at this file. Most real errors will appear in this file along with verbose messages.
- <servername>-<#>-stout-<##>.txt - contains both critical and non-critical messages relating to the function of Integrify. If for some reason Integrify does not function after an upgrade or a server reboot / IIS restart, you will want to take a look at this file. Most real errors will appear in this file along with verbose messages
integrify\app\webserver\logs:
- <YYYY-MM-DD>_session_stats_<license>.log - contains license usage stats.
- <YYYY-MM-DD>_error_<application area>.log - contains errors of all kinds depending on what area of the application was affected (process, route, etc). This should be one of the first logs to look at when a user reports an error or an issue.
- <YYYY-MM-DD>_info_<application area>.log - contains informational messages of all kinds depending on what area of the application was affected (process, route, etc).
- <YYYY-MM-DD>_warning_<application area>.log - contains warnings of all kinds on what area of the application was affected (process, route, etc).
integrify\app\windowsservices:
- <instancename>_exceptions.xml - contains mostly critical and some non critical errors relating to the function of Integrify. Typically errors that cannot get logged to the database because of a database connectivity issue or any other system issues are logged here. If for some reason Integrify does not function after an upgrade or a server reboot / IIS restart, you will want to take a look at this file.
- SystemSettings.log - contains a log of the number of Integrify instances and the number of settings per instance. For most installed customers this should be 1 and 47 respectively. It writes to this file anytime the first user hits the site after an application pool recycle or service restart. This is a verbose log and contains information as well as errors.
- <instancename>_sync_log.xml is updated every time the ADSync application is run. It contains success, and error logging.
integrify\app\windowsservices\tp_logs:
This directory contains logs and errors from the Integrify Task Processor. Error files are named yyyymmdd_tp.error. These files will list each instance the processor was able to hit, and the count of the notifications sent for reminders as well as the number of task timeouts for that instance. This is logged every time the Task Processor runs, which is every 5 minutes by default.
integrify\app\windowsservices\em_logs:
This directory contains logs and errors from the Integrify Email Monitor. Error files are named yyyymmdd_em.error.
ERROR_LOGGER
This is a table that resides in your Integrify database. You can run a select statement directly against the table with the tool of your choice to view it's contents
Aside from the files, folders, and tables listed above, the windows event logs will also hold valuable information in case of a problem. Normally the event logs be most useful for analysis if the files above are not being updated or recreated after deletion.
The main locations for logged events for the application are in the \intergrify\app\webserver\logs diretory as well as the \integrify\app\webserver\iisnode diretory
Comments
0 comments
Please sign in to leave a comment.