It’s important to be able observe your web application at runtime, so you can detect issues as they occur and diagnose bugs. To do this effectively, you need to pay attention to how you implement logging and monitoring.
Logging refers to having an application write a record of each event that occurs to a file on disk. These “log files” can be read by administrators to analyse what the application was doing at a given point in time.
Web servers typically log a record of each HTTP request they handle, along with a timestamp, the URL and HTTP method, and the HTTP response code.
You should add logging statements to your code to record important events that occur. Each logging statement added to the log file should have a timestamp, and be traceable to a given code file and line number.
Logging packages allow you tag each log statement with a log level, indicating how significant the event is. This will allow administrators to filter out irrelevant rows form the log file by setting the appropriate configuration.
Log files from different services should be viewable at runtime, which means shipping them to a central log server. Log servers allow administrators to view consolidated log files in realtime, either via the command line or a dedicated web-console.
Log files should also be retained for as long as reasonably possible, since old log files can be analyzed to detect attacks or troubleshoot issues. In many industries, keeping old logs files is required by law, so be sure to back them up!
Be careful not to write confidential information like user passwords or personally identifiable information in log files in case an attacker gets hold of them. Store your log files in a secure location (preferably encrypted) for the same reason.
Log files are very verbose by their nature, so you should use monitoring to detect trends in your logged output. You can’t possibly read all of that data in it’s raw form!
Monitoring frequently measures key metrics for your web-server, like response times, throughput, server loads and memory usage. This can be rolled up into a monitoring dashboard to make it easy to diagnose the health of the website.
Monitoring can also be used to pick up unexpected or suspicious errors, which can often be an indicator of a cyber-attack. At the very least, you should be collecting records of errors that occur so you can fix any underlying bugs.
It’s not reasonable to expect administrators to observe your website 24/7, so unusual conditions picked up by your monitoring should trigger alerts via email, instant message or text. Make sure the alert “thresholds” are set correctly though, or else you will be getting team-members out of bed constantly!
Observe how the logs for this web-server can be used to detect an attempt to brute-force the login screen. Configure an alert that will cause an the administrator to be notified.
Finally, make sure you have a response plan to follow when alerts are raised! This should by a living document that included trouble-shooting steps such as restarting servers or adjusting firewalls in response to the problem.
occur more than time(s) per minute.