Go coverage, call chain, and runtime data collection toolkit.
Languages: English | 简体中文
Ellyn instruments Go applications so you can collect request-level coverage, function call chains, async execution links, and runtime data such as arguments, return values, errors, and latency. It is designed for observability, precision testing, traffic replay, and risk analysis scenarios where coverage alone is not enough.
- Global coverage collection for full and incremental coverage analysis.
- Function call chain collection, including asynchronous links.
- Runtime data collection for parameters, return values, exceptions, and latency.
- Request-level collection for coverage, call graph, and runtime details.
- Concurrent data collection.
- Performance-oriented SDK components for high-frequency runtime paths.
- Experimental mock support is planned but not currently available.
- Coverage statistics and single-test coverage details.
- Call chain tracing and runtime observation.
- Data and field lineage analysis.
- Traffic observation and replay.
- Precision testing and automated testing.
- Risk analysis.
- Unified metrics, monitoring, and alerting.
- Go 1.18 or later.
- Linux, macOS, or Windows.
Download the demo program for your platform from GitHub Releases, run it, and open http://localhost:19898.
Download the ellyn CLI from
GitHub Releases.
NAME:
ellyn - Go coverage and callgraph collection tool
USAGE:
ellyn [global options] command [command options]
COMMANDS:
update update code
rollback rollback code
help, h Shows a list of commands or help for one command
GLOBAL OPTIONS:
--help, -h show help
Run the CLI in the directory that contains the target Go application's main
package:
ellyn updateellyn update instruments the project. After instrumentation, compile and start
the target service to collect data.
ellyn rollbackellyn rollback restores the original source files and removes instrumentation
artifacts.
api: Runtime API used to access the instrumented SDK.benchmark: Benchmark scenarios for comparing overhead at different sampling rates.cmd: Theellyncommand-line tool.example: Demo application for inspecting collected data.instr: Instrumentation logic that walks target Go files and injects SDK calls.sdk: SDK code copied into the target project and compiled as part of it.test: Shared test helpers.viewer: Lightweight visualization UI.
The SDK is copied into target projects, so runtime code should avoid unnecessary dependencies and keep hot paths predictable:
- Prefer lock-free designs where practical, and avoid resource contention.
- Keep core operations at
O(1). - Pad highly accessed fields to reduce false sharing.
- Trade limited memory overhead for lower runtime latency when it is justified.
- Prefer arrays and bitmaps over Go maps on high-frequency paths.
- Reuse frequently allocated objects with
sync.Poolto reduce GC pressure. - Be careful when collecting large parameter values because copying can be costly.
- RingBuffer: Buffers call data.
- LinkedQueue: Linked-list-based synchronized queue used by the goroutine pool.
- hmap / SegmentHashmap: High-performance routine-local storage implementation.
- bitmap: Records function and block execution.
- UnsafeCompressedStack: Simulates stack push and pop operations.
- routineLocal / GLS / GoRoutineLocalStorage: Caches goroutine context.
- routinePool: Goroutine pool for concurrent file processing.
- Uint64GUIDGenerator: Generates call IDs.
- AsyncLogger: High-performance asynchronous logger.
- CPU-intensive workloads can show measurable overhead even at low sampling rates.
- IO-intensive workloads are usually affected much less, even with higher sampling rates.
See benchmark details.
Part of the SDK is copied into target repositories. Custom implementations help avoid dependency conflicts in those repositories and allow Ellyn to optimize for its specific runtime collection paths. For code that is not copied into target projects, reusing mature open-source implementations is preferred.