In APMdigest's exclusive interview, Charley Rich, VP Marketing and Product Management at Nastel, talks about logging and application performance.
CR: Application developers can write log events about their attempted acquisition of system resources, shortage of resources, current state or errors to a log file. By reading and analyzing the log, one can determine to some extent the problems the application is experiencing.
In addition there are additional logs, including those for: the physical server, the application server and the database. Manually, an expert can examine each of these logs and string together a picture of what is happening when a problem has been reported. But, this is not for the faint of heart and often adds considerable trouble to the troubleshooting process.
CR: Yes. Manually correlating the information an application logs along with system and other logs can be quite laborious. In addition, many of these logs have multiple unrelated writers posting entries to these logs. Tracing the information pertaining to specific applications is not easy. It is sort of a signal-to-noise problem with the extraneous information in the log acting as noise. All the sources write log events as they happen and thus, each entry may have no relation at all to the prior entry. Deciphering what is relevant to your task is hard.
Standard logging facilities such as Log4j and syslog do not help resolve this issue. They are not sufficiently structured to perform effective problem determination. The burden is on the developer to include enough detail in the log message for effective root cause analysis. They also do not help with the problem of relating application activity messages spread across multiple applications in multiples tiers and multiple logs.
As a result, standard logging can be a burden on development due to the long time it takes to correlate activities manually. Thus, standard logging facilities are somewhat unhelpful in reproducing production problems.
CR: Standard logging can be augmented to become “Smart Events”. Smart events are members of a flow of events and can have location, timing, source, correlation information embedded in them (such as IP, server, GPS, geo, etc.). Such augmentation is a combination of an enhanced logging methodology, combined with a simple programming model that allows recording of relevant information that can aid in fast root cause analysis and inter and intra log correlation.
CR: Once a Smart Event has been created, the necessary context is provided for an analytics process to correlate these events into a more meaningful format that will make troubleshooting considerably easier.
CR: Smart Events are most useful for applications that require fast root cause diagnostics for performance problems and application misbehavior using logging facilities.
They are also very useful for applications running in cloud or mobile where very little control exists over application behavior.
CR: Not a lot is required. The developer must use an enhanced programing model that allows for generation of Smart Events where context, time and location are combined into a single concept. Instead of using logging frameworks directly and write to an event log, the developer uses a simplified interface that supports Smart Event methodology. It is important to note that correlation comes from the application's standpoint and not from the technology point of view
CR: Smart Events can be used for existing applications that make use of log4j or other logging frameworks. A post processor could be applied to their current logs where data is mined from the existing set of logs and transformed into smart events. Of course, the value of such transformation will largely depend on the level of detail available in the log entries themselves.
CR: Yes. If a user has these installed, the processed or consolidated log files can be used as the source without a need to add API calls to the applications.
CR: As activities are traced down to the thread level, it becomes even more important to know where that thread is executing and how that relates to the activity produced by other threads. As these multi-threaded applications execute in multiple locations, the complexity in using log files for debugging becomes far greater. Awareness of location, context and behavior would be very helpful.
CR: An auto-processing logging framework would imitate the way the application works and automatically time how long it takes from start to completion. It can also measure the timing in detail between, for example event 1, event 2 and event 3. There are a lot of implicit values in a timing perspective and using this model, as well capturing exceptions and errors associated with application activities.
CR: They should evaluate their current logging process and framework and determine the delta between what they are doing and what has been described here. They should consider how the value described can be garnered across all their applications by evolving their logging.
Charley Rich, Vice President of Product Management and Marketing at Nastel, is a software product management professional who brings over 20 years of experience working with large-scale customers to meet their application and systems management requirements. Earlier in his career, he held positions in Worldwide Product Management at IBM, as Director of Product Management at EMC/SMARTS, and Vice President of Field Marketing for eCommerce firm InterWorld. Rich is a sought after speaker and a published author with a patent in the application management field.