L is for Logging


Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/1/d95165460/htdocs/wordpress/wp-content/plugins/prettify-gc-syntax-highlighter/prettify-gc-syntax-highlighter.php on line 63

Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/1/d95165460/htdocs/wordpress/wp-content/plugins/prettify-gc-syntax-highlighter/prettify-gc-syntax-highlighter.php on line 69

11 Thoughts.

  1. I use log levels in a similar way, with one distinction: I use error levels that map to the health of the application, instead of the services it uses. So failing to connect to the primary DB raises a WARNING. If it can’t connect to the secondary DB and thus does not work with full functionality, *that* would be an ERROR condition.

    • The example log I have does the same thing. First, the application tried to connect to the primary database. That failed so a WARNING was logged. Next it tried to connect to the secondary database. That one was in read only mode. The application knows that the current request requires a database write, so it logged another WARNING about the failure to connect to a useable database. At this point, it ran out of options and threw an ERROR.

      In general, if an application can continue to work (albeit under less desirable circumstances) it should try to do so. If the application can’t recover, and therefore can’t fulfill the requested operation, it should throw an ERROR. ERRORs should be addressed ASAP. WARNINGs may be able to be shelved until the morning. They key to maintaining sanity is making sure that what you consider an ERROR is something that really requires immediate attention.

  2. The problem is that not everyone reads the logs – in fact, rare are those (even the system administrators) who read actual logs.

    Logs say everything about the application – and when it comes to proactive anti-hacking measures, logs are the best as they reveal some information that tell you if your website is about to be hacked.

    Maybe there should be a dedicated role, like “Log Reader”, but my guess that the person doing this will end up not reading logs anyway.

    • Right. If no one reads your logs, it doesn’t matter how good they are. However, there are applications out there that do the reading for you. If you provide consistency and proper messaging, those applications can alert you via text message or email when things begin to go south. Additionally, other applications can read the logs and let you know when things are going well. For instance, if you begin to see an uptick in registrations, you may want to beef up your servers. Being able to see a trend based on your log output helps you make the right decision about how many more servers you will need.

      Logging stuff doesn’t actually solve any problems. Logging simply opens the gates for other people/applications to solve them for you.

  3. Pingback: U is for Unit Tests | Crisscott.com

  4. Pingback: D is for Documentation | Crisscott.com

  5. Pingback: Centralized Logging with Monolog, Logstash, and Elasticsearch

Leave a Reply to FGM Cancel reply

Your email address will not be published. Required fields are marked *