- Legacy APM Overview:
- Overview
- Components and documentation
- Install and run
- Data Model
- Distributed tracing
- Real User Monitoring (RUM)
- OpenTracing bridge
- OpenTelemetry integration
- Observability integrations
- Cross-cluster search
- Agent and Server compatibility
- Troubleshooting
- Breaking changes
- 7.7.0 APM Breaking changes
- 7.6.0 APM Breaking changes
- 7.5.0 APM Breaking changes
- 7.4.0 APM Breaking changes
- 7.3.0 APM Breaking changes
- 7.2.0 APM Breaking changes
- 7.1.0 APM Breaking changes
- 7.0.0 APM Breaking changes
- 6.8.0 APM Breaking changes
- 6.7.0 APM Breaking changes
- 6.6.0 APM Breaking changes
- 6.5.0 APM Breaking changes
- 6.4.0 APM Breaking changes
- Release highlights
A newer version is available. For the latest information, see the
current release documentation.
Errorsedit
An error event contains at least
information about the original exception
that occurred
or about a log
created when the exception occurred.
For simplicity, errors are represented by a unique ID.
An Error contains:
-
Both the captured
exception
and the capturedlog
of an error can contain astack trace
, which is helpful for debugging. -
The
culprit
of an error indicates where it originated. -
An error might relate to the transaction during which it happened,
via the
transaction.id
. -
Data about the environment in which the event is recorded:
- Service - environment, framework, language, etc.
- Host - architecture, hostname, IP, etc.
- Process - args, PID, PPID, etc.
- URL - full, domain, port, query, etc.
- User - (if supplied) email, ID, username, etc.
In addition, agents provide options for users to capture custom metadata.
Metadata can be indexed - labels
, or not-indexed - custom
.
Most agents limit keyword fields (e.g. error.id
) to 1024 characters,
non-keyword fields (e.g. error.exception.message
) to 10,000 characters.
Errors are stored in error indices.
Was this helpful?
Thank you for your feedback.