honeycomb-tracing

Topics in the source

• Honeycomb Tracing
• Choose the data path
• Find the application's trace
• Read the timeline correctly
• Design a human-readable waterfall
• Add only the missing instrumentation
• Compare and hand back useful evidence

Produce an inspectable waterfall tied to the actual run or CI attempt, explain which intervals dominate elapsed time, and identify the smallest useful next experiment. Respect diagnosis-only requests; tracing does not itself authorize replaying tasks, changing credentials, or deploying instrumentation. | Question | Start here | | --- | --- | | Why is a task slow before, during, or after model execution? | Application workflow below; runtime setup if spans are absent | | Why does an issue page load slowly? | Request spans plus browser timing, described below | | Which CI jobs or test files delay the whole suite? | CI profiling | | How should a trace be organized so a person can understand it? | Human-readable waterfall guidance below and trace design | | Where should a new span go? | Instrumentation guidance below and Observability contract | Repository-relative paths and commands assume the checkout root. The maintained contracts are doc/observability.md and doc/ci-profiling.md; recheck them and the owning code when a deployed version differs. Keep the repository's three paths distinct: Observability: operator-configured OpenTelemetry export to Honeycomb or another OTLP destination

This is an excerpt. Refer to the complete source and its current requirements.