Across most systems, there are varying log levels for different services such as system logs, PHP logs, Apache logs and many other application specific logs. From a hosting perspective, this also includes services such as ModSecurity as well.
Many read what they see to be errors in the logs and blame that particular part of the code or that service as causing a problem, missing the critical part that these have a severity level. These levels vary so that you can either filter down to the bits you want when searching or so that you reduce the resource overheads (increased CPU and disk space) of verbose logging.
Log Levels
Below is a reference table of the log levels and their various meanings. As most of the use within the hosting realm is at a web application or webserver level, these meanings have been adapted to be more meaningful to these areas.
Blocking means the severity level was high enough that the application didn’t return as normal and either completely stopped or returned an error message instead of the expected code.
Log Level | Usage / Meaning | Blocking? |
Trace | Ultra low level logs, normally featuring full variable dumps, code lines and very explicit formation of exactly what the application or code is doing. | No |
Debug | Detailed information from the application / code and how it’s running. This can be down to logging each step within a functional call, with variable values occasionally used as well. Debug information is usually quite verbose but not as detailed as a Trace. | No |
Info / Informational | At an Information level, you would expect information that a function has been called or an event has occurred. For example, you might see “function X was called successfully”. | No |
Warning | When the application has encountered something unexpected, but was able to handle it. For example, it could be a deprecated feature or where a value wasn’t specified and a default instead inserted. Warning level issues are normally where a developer could improve code or use of a system but it’s not necessarily a showstopper. | No |
Error | When the application has encountered something unexpected, but was NOT able to handle it. This could be when a website tries to parse data which it couldn’t make sense of or where there’s a syntax error in the code (e.g. missing bracket). This generally results in a 500 error being displayed. | Yes |
Fatal | When the application or code caused a crash and immediate exit. Obviously as the most severe, this normally only occurs where there’s a very critical issue such as a buffer overflow, a call to a function which didn’t exist or where a system library was unable to be found. Depending on the handler, this may result in a 500 error or no error returned (and a possible white screen of death). | Yes |
Older UNIX based systems may use shortened and capitalised versions of the log levels as well, such as INFO, DEBUG, WARN, ERROR and FATAL.
Some other services may also have Alert / Critical levels, which are a blend of Error and Fatal so should be considered at this level.
The critical part here is that anything under Error / Fatal should not interfere with the app. A warning is simply that, it’s a caution that something wasn’t quite correct but it wasn’t bad enough to block nor stop.
How do I read errors for websites hosted with Conetix?
As we use Plesk as our hosting environment, this includes a simple log reader, which we’ve documented in our Reading Website Error Logs support guide.
These error logs include PHP errors, ModSecurity errors (if applicable) and Apache errors.
Generally, application level logs (e.g. from a Content Management System) are kept separately by the application itself and will be dependent on the application as to where they’re stored and how they can be read.
For most common errors we occur where a workaround is possible, we have documented these within the Conetix Support Portal so it’s always worth searching for the error here for a possible fix.