| Part of a series on |
| Software development |
|---|
Paradigms and models |
Standards and bodies of knowledge |
Tracing in software engineering refers to the process of capturing and recording information about the execution of a software program. This information is typically used byprogrammers fordebugging purposes, and additionally, depending on the type and detail of information contained in a trace log, by experiencedsystem administrators ortechnical-support personnel and by software monitoring tools todiagnose common problems with software.[1] Tracing is across-cutting concern.
There is not always a clear distinction betweentracing and other forms oflogging, except that the termtracing is almost never applied to logging that is afunctional requirement of a program (therefore excluding logging of data from an external source, such asdata acquisition in ahigh-energy physics experiment, andwrite-ahead logging). Logs that record program usage (such as aserver log) oroperating-system events primarily of interest to a system administrator (see for exampleEvent Viewer) fall into a terminological gray area.
Tracing is primarily used for anomaly detection, fault analysis, debugging or diagnostic purposes in distributed software systems, such as microservices or serverless functions.[2]
Software tracing is a tool for developers to gather information for debugging. This information is used both during development cycles and post-release. Unlike event logging, software tracing usually does not have the concept of a "class" of event or an "event code". Other reasons why event-logging solutions based on event codes are inappropriate for software tracing include:
OpenTelemetry is aCNCF open source project that provides comprehensive support for distributed tracing.[3] Some vendors includingDatadog,Dynatrace,New Relic,Splunk also offer tracing SaaS services.[4]
Google andMeta have developed their own tracing frameworks, named Dapper and Canopy respectively.[2]
In operating systems, tracing can be used in situations (such asbooting) where some of the technologies used to provide event logging may not be available.
Linux offers system-level and user-level tracing capabilities withkernel markers andLTTng.ftrace also supports Linux kernel tracing.syslog is another tool in various operating systems for logging and tracing system messages.
FreeBSD andSmartOS employ DTrace for tracing in bothuser space and kernel space.
Inembedded software, tracing also requires special techniques for efficient instrumentation and logging and low CPU overhead.[6]
Trace generation of method calls can be done with source code instrumentation, runtime information collection, or under debugger control.[7] Tracing macros,aspect-oriented programming and relatedinstrumentation techniques can be employed.
Libraries used in source code send data to an agent or directly to the collection component.[4]
To model execution trees, ISVis converts a rooted tree into a directed acyclic graph while Jinsight utilizes the call frame principle to gather and represent cumulative information about traces.[7]
The primary visualization method is the swimlane view, which is exemplified by tools likeJaeger and often includes annotations and key-value attributes. Despite its widespread use, this design lacks rigorous justification and users frequently face challenges like missing features and confusing navigation. Alternatives to swimlane views exist, like Jaeger’s service dependency view or SkyWalking’s List, Tree, and Table views. Aggregate visualizations are also used for analyzing large volumes of traces, with systems like Canopy offering queryable metrics and Jaeger providing trace comparison features.[8]
 | This sectiondoes notcite anysources. Please helpimprove this section byadding citations to reliable sources. Unsourced material may be challenged andremoved.(August 2024) (Learn how and when to remove this message) |
Event logging provides system administrators with information useful for diagnostics andauditing. The different classes of events that will be logged, as well as what details will appear in the event messages, are often considered early in the development cycle. Many event logging technologies allow or even require each class of event to be assigned a unique "code", which is used by the event logging software or a separate viewer (e.g., Event Viewer) to format and output a human-readable message. This facilitates localization and allows system administrators to more easily obtain information on problems that occur.
Because event logging is used to log high-level information (often failure information), performance of the logging implementation is often less important.
A special concern, preventing duplicate events from being recorded "too often" is taken care of through event throttling.
Difficulties in making a clear distinction between event logging and software tracing arise from the fact that some of the same technologies are used for both, and further because many of the criteria that distinguish between the two are continuous rather than discrete. The following table lists some important, but by no means precise or universal, distinctions that are used by developers to select technologies for each purpose, and that guide the separate development of new technologies in each area:
| Event logging | Software tracing |
|---|---|
| Consumed primarily by system administrators | Consumed primarily by developers |
| Logs "high level" information (e.g. failed installation of a program) | Logs "low level" information (e.g. a thrownexception) |
| Must not be too "noisy" (containing many duplicate events or information that is not helpful for its intended audience) | Can be noisy |
| Astandards-based output format is often desirable, sometimes even required | Few limitations on output format |
| Event log messages are oftenlocalized | Localization is rarely a concern |
| Addition of new types of events, as well as new event messages, need not be agile | Addition of new tracing messagesmust be agile |
Enabling or disabling tracing during runtime often necessitates the inclusion of extra data in the binary. This can lead to performance degradation, even when tracing is not active. The overhead of tracing depends on the used framework and the activated features;[9] in production servers, there is a trade-off between how fine-grained the tracing is and the incurred overhead.
If tracing is enabled or disabled atcompile-time, collecting trace data from a client's system hinges on their willingness and capability to install a version of the software specifically enabled for tracing, and subsequently replicate the issue.
Tracing in software typically demands high standards ofrobustness, not only in the accuracy and reliability of the trace output but also in ensuring that the process being traced remains uninterrupted.
Given its low-level nature, tracing can generate a large volume of messages. To mitigate performance issues, it's often necessary to have the option to deactivate software tracing, either at the time of compilation or during run-time.
Inproprietary software, tracing data may include sensitive information about the product'ssource code.
{{citation}}: CS1 maint: work parameter with ISBN (link)