59 lines
2.0 KiB
Markdown
59 lines
2.0 KiB
Markdown
# T-shaped Signals
|
|
|
|
Semantic Conventions approaches observability with a T-shaped mindset. This
|
|
splits signals into two types of a "T" shape:
|
|
|
|
```mermaid
|
|
block-beta
|
|
columns 3
|
|
Broad["Broadly Applicable Signals"]:3
|
|
columns 3
|
|
space:1
|
|
Deep("Rich,\nDeep\nSignals")
|
|
space:1
|
|
```
|
|
|
|
This matches an 80-20 rule, where 80% of users (or use-cases) can leverage the
|
|
broadly applicable signals and 20% of users (or use-cases) will dive deeply into
|
|
a problem with deep signals.
|
|
|
|
## Broadly Applicable Signals
|
|
|
|
These are conventions meant to provide a baseline observability experience
|
|
across a domain. An example includes HTTP semantic conventions that allow
|
|
general-purpose dashboarding, alerting, and diagnostics for HTTP
|
|
(micro-)services. These signals should provide "horizontal" coverage for
|
|
observability.
|
|
|
|
Examples include:
|
|
|
|
- Golden Signals / RED metrics (Saturation, Rate, Error, Duration)
|
|
- High Level Spans
|
|
- Error logs, Crash reports
|
|
- Request/Response logs
|
|
|
|
## Rich, Deep Signals
|
|
|
|
These are conventions meant to provide deep understanding of a specific
|
|
system, library, module, application or service. These are used to diagnose
|
|
issues specific to that system.
|
|
|
|
Examples include:
|
|
|
|
- Linux slab memory usage
|
|
- Specific database signals, e.g MySQL index usage
|
|
- Language-specific Garbage Collection metrics (JVM, Go, .NET, etc.)
|
|
|
|
## Recommendations
|
|
|
|
Defining semantic conventions is a balance between generating
|
|
broadly applicable signals and ensuring rich observability for a specific
|
|
technology. It is recommended to start with the *broad* use cases and signals
|
|
for a particular domain first. After providing a baseline set of signals for
|
|
that domain, then explore deeper integrations that may be vendor or
|
|
implementation specific.
|
|
|
|
For example, see [Database semantic conventions](/docs/database/README.md) where
|
|
there is general guidance for spans about communicating with a database, and
|
|
additionally there is database-specific guidance as an extension of the general.
|