This information is typically used by programmers for debugging purposes, and additionally, depending on the type and detail of information contained in a trace log, by experienced system administrators or technical-support personnel and by software monitoring tools to diagnose common problems with software.
Tracing is primarily used for anomaly detection, fault analysis, debugging or diagnostic purposes in distributed software systems, such as microservices or serverless functions.
In embedded 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] The primary visualization method is the swimlane view, which is exemplified by tools like Jaeger 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.
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: Enabling or disabling tracing during runtime often necessitates the inclusion of extra data in the binary.