network-tracing

nexus-labs-automation's avatarfrom nexus-labs-automation

Instrument API requests with spans and distributed tracing. Use when tracking request latency, correlating client-backend traces, or debugging API issues.

⭐70stars🔀7forks📁View on GitHub🕐Updated Dec 23, 2025⬇️1downloads

When & Why to Use This Skill

This Claude skill provides comprehensive network observability by instrumenting API requests with spans and distributed tracing. It enables developers to track request latency, correlate client-side actions with backend traces, and debug complex network issues using OpenTelemetry (OTel) compatible standards for improved system reliability.

Use Cases

  • Latency Optimization: Identify and resolve slow API calls by monitoring p50 and p95 latency thresholds across different endpoints.
  • End-to-End Troubleshooting: Correlate mobile or web client requests with backend logs using W3C trace headers and unique request IDs to pinpoint failure origins.
  • Cross-Platform Performance Tracking: Implement consistent network monitoring across iOS, Android, and React Native using standardized interceptors and delegates.
  • API Reliability Analysis: Monitor real-time error rates and payload sizes to ensure service stability and optimize data transfer efficiency.
namenetwork-tracing
descriptionInstrument API requests with spans and distributed tracing. Use when tracking request latency, correlating client-backend traces, or debugging API issues.
priority2

Network Tracing

Measure API requests and correlate with backend traces.

What to Capture (OTel-Compatible Names)

Attribute OTel Name Purpose
Method http.request.method GET, POST, etc.
Status http.response.status_code Success/failure
URL url.path Endpoint (sanitized)
Duration http.request.duration Request time (ms)
Size http.response.body.size Payload bytes

Using OTel naming = easier migration when OTel mobile matures. See references/otel-mobile.md for rationale.

Distributed Tracing

Propagate trace context to backend:

Client Request
    │
    ├── traceparent: 00-{trace_id}-{span_id}-01
    ├── X-Request-Id: {uuid}
    └── X-Session-Id: {session}
         │
         ▼
    Backend (correlates logs with trace_id)

Key Thresholds

Metric Good Acceptable Poor
API p50 <500ms <1s >1s
API p95 <2s <5s >5s
Error rate <1% <3% >3%

Integration Options

Choose based on existing vendor:

Vendor iOS Android Approach
Sentry Auto URLSession swizzling OkHttp integration Automatic
Datadog URLSession delegate OkHttp interceptor Semi-auto
Embrace Auto-instrumentation Auto-instrumentation Automatic
Custom Manual interceptor Manual interceptor Manual

Automatic (swizzling): Less code, may miss custom clients Manual (interceptors): More control, works with any HTTP client

Platform Integration Points

Platform Manual Option Works With
iOS URLSession delegate All URLSession-based clients
iOS Alamofire EventMonitor Alamofire
Android OkHttp Interceptor OkHttp, Retrofit
Android Ktor HttpClientPlugin Ktor
RN fetch wrapper Native fetch
RN axios interceptor axios

Implementation

See references/mobile-challenges.md (Client-Backend Correlation) for:

  • W3C trace header format
  • Platform-specific interceptor code
  • Backend log correlation patterns

See references/performance.md (Network section) for latency budgets.