Share

Tracing is a critical feature in N|Solid that allows developers to analyze application performance by visualizing the relationships between different processes through spans and traces. Without proper tracing, debugging performance issues becomes significantly more challenging, as developers lack visibility into how requests flow through an application. Tracing helps pinpoint bottlenecks, optimize request execution, and improve overall application efficiency.

In this post, we’ll explore how tracing works in N|Solid, including recent updates that improve visibility and filtering capabilities.

The Basics of Tracing in N|Solid

When an application generates a trace, it creates multiple spans, each representing an individual operation within that trace. These spans form a hierarchy, starting from a root span, which serves as the first executed span in the trace.

Root Spans and Hierarchy

Previously, the application name appeared as the root of a trace, but this has changed. Now, the root is the span name that was generated. A trace can contain multiple spans, but there will always be a root span, identifiable by having a Parent ID of 000000000. This root span serves as the starting point for all child spans.

Each child span references its parent span via a Parent ID, creating a hierarchical structure that maps the entire request path. This allows for detailed insights into how each operation contributes to the overall request execution.

Handling Orphaned Spans

One key challenge in tracing is dealing with orphaned spans—spans that do not have a recorded parent. This happens when the parent process is not running with N|Solid, leading to missing relationships in the trace visualization.

Example of an Orphaned Span

Imagine three applications:

• Test API (not running with N|Solid)
• Accounts API (running with N|Solid)
• Server API (running with N|Solid)

If Test API makes requests to both Accounts API and Server API, but it is not monitored by N|Solid, then its spans will not appear in the trace. Instead, spans from Accounts API and Server API will appear as orphaned nodes—lacking a parent ID, as you can see in the following image:

In such cases, N|Solid will display a warning like:

"Invalid parent span ID=8d486ba62855cdda” as is shown in the following image:

This indicates that the parent span is missing from the database, preventing the system from properly linking it to its children.

New Features and Improvements

Enhanced Filtering

A new set of filters has been introduced in the tracing section, allowing users to refine traces, these filters include:

These filters help in isolating specific traces, making debugging and performance analysis more efficient.

Visualizing Span Durations

In the updated visualization, spans are represented as bars, with their length corresponding to their duration within the total trace time range. This provides a clearer understanding of execution time distribution.

Expanded Span Details

Previously, clicking on a node only highlighted its corresponding line. Now, clicking on a span not only highlights it but also opens a detailed view, providing:

• The exact time the span was generated
• The request URL
• The duration of the operation
• The parent-child relationship

See the full list in the image below:

This improvement gives developers more in-depth trace insights at a glance.

Conclusion

Tracing in N|Solid has undergone significant improvements, particularly in how root spans are identified and how orphaned spans are handled. The addition of enhanced filtering and expanded visualization makes it easier than ever to diagnose performance issues and optimize application efficiency.

If you’re using N|Solid for tracing, these updates will help streamline your debugging process and provide deeper visibility into your application’s behavior. Stay tuned for more updates as we continue to improve the tracing experience!