Creating Custom Application Logs & Logging Events For Forensics

by Sunny Hoi


It’s not unusual for developers to incorporate their own logging modules into applications. Their rationale for doing so is to make up for the restraints in standard logging functionality accessible with an operating system.

For example, Windows registers application errors in Event Viewer logs. Such logs supply information for developers and administrators to determine what went wrong, though they don’t always supply the level of monitoring required for an enterprise application.

If you have determined that you require custom logs for your application, below are some events that are significantly relevant.

Inadequate Performance & Load Times

An operating system will log each event when the application crashes by reason of a timeout, yet such logs solely inform you when the application crashes not when it’s exhibiting signs of performance deterioration.

When your user base increases and the application bolsters up additional traffic, your server hardware and resources ought to scale.

It’s not unusual for administrators to neglect server resources while the business expands, and such mistake may result in application timeouts.

Alongside custom application logs, you may write events that provide admins with a forewarning when the application is taking a tremendous amount of time to load. You decide on a satisfactory time for pages to load, and then generate events in a log that signify that the application is taking a significant amount of time to process.

For example, provided that a page ought to solely take five seconds to load, then you ought to write events to a log as load times amount to three seconds. Admins may keep an eye on these events and augment resources when the server requires more central processing unit power, random-access memory, and bandwidth.

An additional advantage to logging and keeping track of these events is that retaining them as a warning narrows the likelihood of your application crashing, which places pressure on your IT personnel and enterprise revenue.

Failed Events Throughout Checkout Process & Sales Inquiry

The majority of application logs seize pages that crash, though the most significant of such pages are those that lead the customer through the purchasing process.

For instance, it may be a page where a customer gets in touch with your sales team, or it may be a page that a customer visits when making an online purchase. If one of these pages crashes, you lose earnings.

An approach to salvage unintentionally neglected sales is to log events and seize the data that would alternatively be lost. By doing so, you would be able to communicate with the buyer and finish the purchase.

Visit any well-known online store, and you’ll notice that the shopping cart process is generally split up into segments where the customer submits some information and proceeds by typically clicking on a button such as “Next” to continue on to the next step. Information is accumulated and kept in the database after each step is completed. Despite holding such information, you still don’t apprehend why the application failed or at which step the customer could no more finish a purchase.

Logging unsuccessful sales events permit you to study information from a customer and determine where the sales page failed. This may arise from a customer-produced error such as a lapsed credit card, though it may also be from a bug in your application.

For example, there may be a bug in the payment component of your application that denies an authentic credit card. Operating system logs won’t register this kind of error. Nevertheless, your custom application logs may aid you to detect such logic errors.

Cybersecurity & Dubious Events

Each application exposed to the Internet publicly ought to hold onerous monitoring for security events. Logging dubious events are one of the approaches you may distinguish when a cybersecurity attack is transpiring.

You ought to retain other kinds of security on the server, the network, and implemented into the application. Nevertheless, logging events may provide you hints into a continuous attack. Logging events may assist you with forensics following a severe data breach.

The biggest challenge of this kind of logging is that discerning attacks from the application may result in numerous false positives. Furthermore, developers ought to recognize what amounts to a doubtful action and what is authentic traffic.

Developers are not generally cybersecurity specialists. Hence, it takes some cooperation between developers and admins to get such logs correct. For instance, one skeptical event is a person that persists in entering an erroneous password.

Some people plainly forget their password or require a couple of attempts before they recall the correct one. You may log the quantity of times a person wrongly enters a password before they are right. If the quantity of attempts amounts to a particular threshold, then it may warn admins.

Logging unique events is a fine approach to discern potential attacks, though the majority of attackers go after many consumers at once.

A more suitable approach to discern attacks is logging events that may demonstrate a bot or tool is being deployed to log into consumer accounts. Such account takeover tools obtain a list of consumers, their credit card numbers and passwords and log into accounts constantly to test their practicability. You may code this kind of detection by apprehending the manner bots operate.

One approach to discovering such tools is to initiate the logging of failed login events that have solely a handful of milliseconds in between attempts. A different way is to log numerous failed credit card purchases in a short duration.

Another approach to discovering such attacks is to log the user agent together with the failed login attempt. Generally, a bot fails to transmit a user agent variable to the web application. These kinds of events don’t exhibit ordinary consumer behaviour patterns, hence they are beneficial for forensics or discovering a potential continuous data breach.

Anatomy Of A Logged Event

Subsequent to determining the events you wish to log, you require accurate information in your log files for them to become productive forensic implements.

You may log events to each location such as a database or a utility software such as the Event Viewer in the Windows operating system.

The subsequent information ought to serve as a starting guideline for your logs:

  • Hostname
  • IP Address
  • Timestamp that includes the date of a particular event.
  • Name of the application
  • Raw exception information deriving out of the operating system
  • Client number if applicable
  • The technical error or warning sent back by the application

When you have finished creating your logs, you ought to accumulate them to a joint location. Recall that logged events are an origin of data breaches. Therefore, they ought to be extremely safeguarded and limited to merely admins.

You may also deploy a third-party service to stream your logs to a Software as a Service system that aids you in probing them for particular events.


Once you have established custom logs, you’ll discover that you can far more efficiently recognize security events, salvage missing sales, and debug your system prior to application errors giving rise to crucial downtime.

Related Posts