06-tracing

Locate broken layers in Edgion controller sync and gateway runtime failures.

Updated Aug 27, 2026
One-click install
npx skills add https://github.com/Pandaala/Edgion --skill 06-tracing
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: 06-tracing
Source: https://github.com/Pandaala/Edgion/tree/main/skills/06-tracing
Command: npx skills add https://github.com/Pandaala/Edgion --skill 06-tracing

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Edgion developers need a fast, reliable way to identify which layer (config sync, controller processing, gateway runtime, routing/plugins, TLS, or statistics) is failing after a code change causes unexpected behavior.

Core Features & Use Cases

  • Layered troubleshooting flow: Diagnose issues by following the configuration/sync chain, then routing/plugin runtime, then load-balancing/statistical behavior.
  • Three-view localization with Admin APIs: Use controller center/server/client views to narrow down whether validation, parse/requeue, gRPC sync, watch/list flow, or gateway readiness is at fault.
  • Evidence-driven inspection: Validate behavior using Gateway Admin API endpoints, Access Log Store trace capture, store-stats, and Prometheus-style metrics.
  • Fast local iteration and environment control: Use integration test harness options (keep-alive, skip prepare, or manual start) to preserve the scene and reproduce issues quickly.

Quick Start

Run the integration scene with keep-alive for a single failing case, then inspect controller and gateway readiness using the health and ready endpoints to identify the failing layer.

Frequently Asked Questions about 06-tracing

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I trace which Edgion layer broke after a configuration change?

To trace a broken Edgion layer, troubleshoot the controller sync chain and gateway runtime by comparing center, server, and client views to isolate failures across validation, gRPC sync, or gateway readiness.

Can I use Access Log Store trace capture to debug Edgion plugin execution order?

Yes, you can use Access Log Store trace capture with Gateway Admin API endpoints to validate plugin execution order, routing conditions, and TLS handshake problems during local integration debugging.

What is the best way to reproduce an Edgion routing failure locally for diagnosis?

The best way to reproduce an Edgion routing failure is to run the integration test harness with keep-alive options to preserve the scene, then inspect readiness using health and ready endpoints.

Why does my Edgion gateway show inconsistent load-balancing statistics after a sync?

Inconsistent load-balancing statistics often originate from a broken layer in the sync chain; use edgion-cli three-view comparisons and store-stats metrics to produce an evidence-based diagnosis.

Does this troubleshooting approach require Prometheus-style metrics to diagnose gateway readiness states?

Yes, evidence-driven inspection requires Prometheus-style metrics and store-stats alongside Admin API endpoints to accurately diagnose gateway readiness states and statistical anomalies.

What should I do if the edgion-cli three-view comparison fails to isolate a controller processing issue?

If three-view comparison fails to isolate a controller processing issue, check the parse and requeue flow or watch and list behavior, then validate runtime behavior using Access Log Store traces.