The log files are invaluable when trying to root out instability and crashes. With thousands of lines of events, how do you make sense of the logs? This article explains how to do so.
If you have not done so already, turn on logging. Check Save to file. Status button -> Log tab.
- status log_logs.png (83.53 KiB) Viewed 29360 times
The log file is really good for providing clues when external functionality that BI depends on is NOT functioning.
The Status Log Errors article provides details on error events in the log file.
Each error also documents fixes. If you identify errors, go to the Status Log Errors article, find your error and try to self correct.
The major categories are:
- DeepStack: 3rd party solution
- Storage: Hardware. Hard drive
- Database: Proxy for hardware issue. Hard drive
- Recording: Hardware. Hard drive
- GPU: Hardware. GPU
- Memory: Hardware. Memory
- ONVIF Trigger: Hardware. Camera
- Registry: Windows
- 3rd Party software
The event code is the first column (digit) in every line.
- 0 = Informational event
- 1 = Warning
- 2 = Errors
- 3 = Motion events
- 4 = Check marks
- 10 = user access (login / logout)
Address Warnings when time is available.
Excel
The log files are easy to import into excel. After doing so, it becomes very easy to process logs that are 1000s of lines long. One gotcha during the import is to set the date column to Text otherwise the column gets incorrectly translated to a number.
1. Once imported, the error code is 2. Filter the data by error code 2 to easily find all the errors events that occurred on your server.
- instability and troubleshooting_error code.png (132.92 KiB) Viewed 29567 times
2. For each error, go to the Status log errors file to resolve the issue. If you know excel pretty well, it's easy to determine the different types of errors seen by your server.
- instability and troubleshooting_errors.png (45.55 KiB) Viewed 29567 times
Filter for the Restart after unexpected shutdown events. If the event exists, the server crashed. The time stamp of the event BEFORE the Restart line identifies when the crash occurred.
If the server crashed, good to see if any of the prior events to the crash provides hints as to the cause. Continue searching up to determine if common events occur before crashes. The restart lines always state which version of the software was restarted which is usually the version that crashed. Always good to know.
A good best practice is to examine the log file on a weekly/monthly basis for errors and warnings.One user identified a camera was constantly rebooting at night prior to a BI crash. Disabling the camera restored stability.
The point of this guide is NOT to identify errors and email support. The point of this guide is to identify errors -> read through the details of your errors and apply the suggested fixes to self-correct.
If still an issue and your error is documented, provide details on what exactly you did to resolve the issue. Suggested fixes vary depending on the underlying issue.