Overview
Stack trace capture provides complete call stack information for debugging critical errors. Unlike caller info which shows a single file:line, stack traces show the entire call chain leading to the log statement. Implementation:~/workspace/source/caller.go:68-86
Quick Start
Enable Stack Traces for Errors
From~/workspace/source/options.go:157:
Enable for All Levels
Stack Trace Functions
From~/workspace/source/caller.go:68-86:
GetStackTrace - Current Goroutine
GetStackTraceAll - All Goroutines
Configuration Options
WithStackTrace
From~/workspace/source/options.go:149-159:
stackTraceLevel threshold.
WithStackTraceLevel
From~/workspace/source/options.go:167-176:
ErrorLevel (stack traces for Error and Fatal only).
Common values:
go_logs.WarnLevel- Capture for Warn, Error, Fatalgo_logs.ErrorLevel- Capture for Error, Fatal (default, recommended)go_logs.FatalLevel- Capture only for Fatal
Entry Structure
From~/workspace/source/entry.go:28-30:
runtime.Stack().
When Stack Traces are Captured
From~/workspace/source/logger_impl.go:182-184:
WithStackTrace(true)is set, AND- Log level ≥
stackTraceLevel
Accessing Stack Traces
In Hooks
In Formatters
In Error Handling
Stack Trace Format
Output fromruntime.Stack() (from Go standard library):
- Goroutine ID and state
- Function names in call order
- File paths and line numbers
- Program counter offsets
Examples
Capture Stack for Errors Only (Default)
Capture Stack for Warnings and Above
Disable Stack Traces
Send Stack Traces to Monitoring
Development vs Production
Performance Impact
Stack Trace Overhead
- ~500ns - 2µs per capture (depends on stack depth)
- Uses
runtime.Stack()which is relatively expensive - Only affects logs at or above
stackTraceLevel
Memory Allocation
From~/workspace/source/caller.go:70:
- 4KB buffer per stack trace (current goroutine)
- 64KB buffer for all goroutines
- Buffers are allocated on each capture
Recommendations
- Use
ErrorLevelthreshold (default) in production - Avoid capturing for Info/Debug in high-throughput systems
- Consider async logging if capturing many stack traces
Best Practices
Production Configuration
- Low overhead for normal operations
- Complete debugging info for actual errors
- Balanced performance/observability
Development Configuration
- Maximum debugging information
- Easier issue reproduction
- Performance is less critical in dev
Combine with Caller Info
Filter in Formatters
Avoid outputting stack traces to console in production:Troubleshooting
Stack Trace is nil
Problem:entry.StackTrace is nil even for errors.
Solution: Ensure stack traces are enabled:
Stack Trace Truncated
Problem: Stack trace is cut off at 4KB. Solution: This is a limitation of the current implementation. For very deep stacks, consider:- Simplifying call chains
- Using
GetStackTraceAll()for debugging - Increasing buffer size (requires source modification)
Performance Degradation
Problem: Logging is slow with stack traces enabled. Solution: IncreasestackTraceLevel threshold:
Comparison: Caller Info vs Stack Traces
| Feature | Caller Info | Stack Traces |
|---|---|---|
| What | Single source location | Full call chain |
| Output | main.go:42 | Multi-line stack dump |
| Overhead | ~100-200ns | ~500ns-2µs |
| Use Case | General debugging | Critical error analysis |
| Memory | Negligible | 4KB-64KB per capture |
| Default | Disabled | Disabled |
| Enable | WithCaller(true) | WithStackTrace(true) |
When to Use
Use Caller Info when:- You need to know where logs originate
- Performance is critical
- Simple file:line is sufficient
- Debugging complex call chains
- Analyzing error propagation
- Sending to error tracking systems (Sentry, Rollbar)
See Also
- Caller Info - Capture single source location
- Hooks - Process stack traces in hooks
- Error Handling - Best practices for logging errors