Q&A: Nastel Talks About Smart Logging

Pete Goldin
APMdigest
Learn more about MeshIQ

In APMdigest's exclusive interview, Charley Rich, VP Marketing and Product Management at Nastel, talks about logging and application performance.

APM: How can logging be used for troubleshooting application misbehavior?

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.

APM: Are standard logging facilities such as log4j and syslog insufficient for problem determination?

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.

APM: What are “Smart Events”?

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.

APM: What happens when a Smart Event is created?

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.

APM: When are Smart Events most useful?

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.

APM: How much effort is required to change an application to create Smart Events?

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

APM: What happens when a developer is unable or not permitted to change existing applications?

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.

APM: Are Smart Events still helpful if a developer is already using Log4j or one of the log file management tools such as Splunk or Loggly?

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.

APM: Does the smart logging approach track thread interdependencies?

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.

APM: Can smart logging capture elapsed time for activities?

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.

APM: How does someone know if smart logging is right for their organization?

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.

ABOUT Charley Rich

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.

Hot Topic
The Latest
The Latest 10

The Latest

Three Strikes and They're Gone: Why Proactive Operations is Now a Customer Retention Strategy

IT organizations have historically measured success by how quickly they can respond when something goes wrong. The entire discipline of Incident Management has been optimized around mean time to resolution, first-response SLAs and ticket closure rates. But new research suggests that even though this is a well-executed playbook, it's no longer enough to retain customers ...

When the Database Is the Problem, Is APM Enough?

Production incidents rarely announce themselves as database problems. They appear as slow transactions, timeouts, rising response times, or an application struggling under a workload it previously handled. APM provides an essential starting point. It can identify a slow transaction path, highlight an affected service, and show that a database dependency is consuming more time than expected. But identifying the database as part of the problem is not the same as explaining what is happening inside it ...

From Cleanup to Prevention: The Future of Cloud-Native Cost Optimization

Cloud teams are under constant pressure to reduce spend without slowing development or increasing operational risk. They are deploying autoscalers, rightsizing workloads, enforcing resource requests, reviewing utilization dashboards, and building FinOps processes around cloud-native environments. Yet the results often disappoint ...

The Real Enterprise AI Risk Isn't Hallucinations

Ask most IT leaders about their biggest concern with AI and you'll hear the same answer: hallucinations ... Today, however, the conversation has shifted ... As organizations move beyond chatbots and experiments, they are increasingly deploying AI agents that perform multi-step tasks. These systems retrieve documents, query databases, call APIs, generate reports, write code, and make recommendations. The issue is not whether the model can reason. The issue is whether the organization can see, verify, and govern the decisions being made along the way ...

Beyond Buy vs. Build: The New Playbook for Data Pipelines

While organizations want to take control of their telemetry, building telemetry pipelines from scratch can be a very daunting, complicated task, even when leveraging open-source standards like OpenTelemetry. It requires specialized knowledge across distributed systems, data engineering, and security. This fragmented approach across systems causes higher operational costs; it puts a strain on resources and reduces efficiency as teams have to work with different interfaces and processes ...

The Corporate Network Is Fading - Here's What Replaces It

For decades, enterprise networks were designed around a simple assumption: work happened inside the office. Applications lived in centralized data centers, employees connected through internal infrastructure, and security focused on protecting the perimeter that surrounded everything ... But the way organizations operate today bears little resemblance to that environment. Cloud platforms host critical applications, employees connect from homes and airports as often as they do from offices, and partners collaborate through shared systems that exist far beyond corporate walls. In short, the corporate network no longer resembles the environment it was designed to protect ...

IT Leaders Must Establish a Network Data Architecture Practice

As an analyst who researches how IT organizations design, build, and operate their networks, I find that network data is a constant source of pain. Network teams struggle with data quality, fragmentation, authority, access, and trust. And these issues undermine everything they try to do. Here are the numbers: Only 45% of network teams are completely confident in the accuracy of their network source of truth, which documents the intent of their network ...

Data Center Outages Are Decreasing but More Costly

The 2026 Global Data Center Survey from Uptime Institute reveals an industry navigating workforce constraints, escalating outage expenses, even as rising costs remain the top concern for management teams ...

Observability Has a Physical Layer Now: What AI Infrastructure Teaches IT Operations

The next observability gap may not be in the code. It may be under the rack. That sounds strange until you think about how AI incidents actually feel in the middle of an investigation ... The application dashboard may be accurate. It may also be stopping at the wrong boundary. AI systems depend on software, but they also depend on a dense physical stack: racks, power paths, thermal margin, maintenance activity and, in many environments, liquid cooling. Those physical dependencies can change slowly before they look like a software incident ...

TLS Certificate Expiration Is Becoming an Observability Problem

Certificate expiration is the rare outage you can see coming. Every TLS certificate carries the date it stops working, so the moment it will begin breaking connections is knowable in advance. That's what makes an expired certificate such a frustrating way to lose a service. What's changing now is how often that date comes around ...

Q&A: Nastel Talks About Smart Logging

Pete Goldin
APMdigest
Learn more about MeshIQ

In APMdigest's exclusive interview, Charley Rich, VP Marketing and Product Management at Nastel, talks about logging and application performance.

APM: How can logging be used for troubleshooting application misbehavior?

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.

APM: Are standard logging facilities such as log4j and syslog insufficient for problem determination?

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.

APM: What are “Smart Events”?

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.

APM: What happens when a Smart Event is created?

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.

APM: When are Smart Events most useful?

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.

APM: How much effort is required to change an application to create Smart Events?

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

APM: What happens when a developer is unable or not permitted to change existing applications?

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.

APM: Are Smart Events still helpful if a developer is already using Log4j or one of the log file management tools such as Splunk or Loggly?

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.

APM: Does the smart logging approach track thread interdependencies?

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.

APM: Can smart logging capture elapsed time for activities?

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.

APM: How does someone know if smart logging is right for their organization?

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.

ABOUT Charley Rich

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.

Hot Topic
The Latest
The Latest 10

The Latest

Three Strikes and They're Gone: Why Proactive Operations is Now a Customer Retention Strategy

IT organizations have historically measured success by how quickly they can respond when something goes wrong. The entire discipline of Incident Management has been optimized around mean time to resolution, first-response SLAs and ticket closure rates. But new research suggests that even though this is a well-executed playbook, it's no longer enough to retain customers ...

When the Database Is the Problem, Is APM Enough?

Production incidents rarely announce themselves as database problems. They appear as slow transactions, timeouts, rising response times, or an application struggling under a workload it previously handled. APM provides an essential starting point. It can identify a slow transaction path, highlight an affected service, and show that a database dependency is consuming more time than expected. But identifying the database as part of the problem is not the same as explaining what is happening inside it ...

From Cleanup to Prevention: The Future of Cloud-Native Cost Optimization

Cloud teams are under constant pressure to reduce spend without slowing development or increasing operational risk. They are deploying autoscalers, rightsizing workloads, enforcing resource requests, reviewing utilization dashboards, and building FinOps processes around cloud-native environments. Yet the results often disappoint ...

The Real Enterprise AI Risk Isn't Hallucinations

Ask most IT leaders about their biggest concern with AI and you'll hear the same answer: hallucinations ... Today, however, the conversation has shifted ... As organizations move beyond chatbots and experiments, they are increasingly deploying AI agents that perform multi-step tasks. These systems retrieve documents, query databases, call APIs, generate reports, write code, and make recommendations. The issue is not whether the model can reason. The issue is whether the organization can see, verify, and govern the decisions being made along the way ...

Beyond Buy vs. Build: The New Playbook for Data Pipelines

While organizations want to take control of their telemetry, building telemetry pipelines from scratch can be a very daunting, complicated task, even when leveraging open-source standards like OpenTelemetry. It requires specialized knowledge across distributed systems, data engineering, and security. This fragmented approach across systems causes higher operational costs; it puts a strain on resources and reduces efficiency as teams have to work with different interfaces and processes ...

The Corporate Network Is Fading - Here's What Replaces It

For decades, enterprise networks were designed around a simple assumption: work happened inside the office. Applications lived in centralized data centers, employees connected through internal infrastructure, and security focused on protecting the perimeter that surrounded everything ... But the way organizations operate today bears little resemblance to that environment. Cloud platforms host critical applications, employees connect from homes and airports as often as they do from offices, and partners collaborate through shared systems that exist far beyond corporate walls. In short, the corporate network no longer resembles the environment it was designed to protect ...

IT Leaders Must Establish a Network Data Architecture Practice

As an analyst who researches how IT organizations design, build, and operate their networks, I find that network data is a constant source of pain. Network teams struggle with data quality, fragmentation, authority, access, and trust. And these issues undermine everything they try to do. Here are the numbers: Only 45% of network teams are completely confident in the accuracy of their network source of truth, which documents the intent of their network ...

Data Center Outages Are Decreasing but More Costly

The 2026 Global Data Center Survey from Uptime Institute reveals an industry navigating workforce constraints, escalating outage expenses, even as rising costs remain the top concern for management teams ...

Observability Has a Physical Layer Now: What AI Infrastructure Teaches IT Operations

The next observability gap may not be in the code. It may be under the rack. That sounds strange until you think about how AI incidents actually feel in the middle of an investigation ... The application dashboard may be accurate. It may also be stopping at the wrong boundary. AI systems depend on software, but they also depend on a dense physical stack: racks, power paths, thermal margin, maintenance activity and, in many environments, liquid cooling. Those physical dependencies can change slowly before they look like a software incident ...

TLS Certificate Expiration Is Becoming an Observability Problem

Certificate expiration is the rare outage you can see coming. Every TLS certificate carries the date it stops working, so the moment it will begin breaking connections is knowable in advance. That's what makes an expired certificate such a frustrating way to lose a service. What's changing now is how often that date comes around ...