Observability notes
How the Full Setup Works Together (Assuming All Are Set Up)
1. ILogger<T> as the unified logging interface
Your app writes logs using ILogger<T>, and the EvLoggingBuilder setup routes these logs to all configured sinks based on:
- Configured log levels
- Sink-specific filters
- Environment settings (e.g., dev vs prod)
Example:
_logger.LogWarning("Something might be wrong here");
This log could go to:
- Console (if enabled)
- Elasticsearch (structured, for querying)
- Sentry (if it’s an error and meets Sentry’s criteria)
Sink Behavior Overview
| Sink | Captures | Triggered By | Key Value |
|---|---|---|---|
| Console | Logs | All levels (e.g., dev only) | Local development visibility |
| Elastic (logs) | Logs (structured) | All log levels based on config | Centralized search and dashboards |
| Sentry | Exceptions and errors | Exceptions, logged or unhandled | Error visibility with stack traces |
| Elastic APM | Traces, spans, errors | Auto and manual instrumentation | Performance insights and bottlenecks |
How They Complement Each Other
Console
- Dev-only feedback.
- Quick, real-time inspection.
- No long-term storage.
Elastic (logs)
- Persistent, searchable logs.
- Useful for monitoring trends and incident postmortems.
- Correlates with APM traces via trace IDs (if enrichers are enabled).
Sentry
- Developer-centric error capture.
- Shows stack traces, breadcrumbs, and user context.
- Less noise — focuses on actionable errors.
Elastic APM
- Visual traces of request flows.
- Pinpoints slow DB queries or external API calls.
- Enriches logs with trace IDs for correlation.
Example Scenario: What Happens When an Error Occurs
Suppose your service throws an exception during a database call.
-
ILogger.LogError(...)is called. -
The log goes to:
- Console (if dev or forced)
- Elastic logs (structured, with trace ID)
- Sentry (captured if severity meets threshold)
-
Elastic APM also auto-captures:
- The full trace (request path, DB call span)
- The exception as part of the trace
-
Observability tools are connected:
- Log entry in Kibana links to APM trace ID.
- Sentry alert shows full stack trace and links to the deployment or release.
- Prometheus (via
/metrics) may show a spike in errors or response times.
Why It’s Not Redundant
Each tool has a distinct lens:
| Tool | Main Focus | Data Type |
|---|---|---|
| Console | Local dev logs | Text |
| Elastic | Centralized logs | Structured JSON |
| Sentry | Error debugging | Exceptions + context |
| Elastic APM | Performance tracing | Spans + metrics |
Together they form a complete feedback loop:
- Detect (Metrics / APM)
- Understand (Logs / Traces)
- Fix (Sentry / Logs)