The New Relic platform is built around the four fundamental telemetry data types we believe are necessary for complete and effective system monitoring: metrics, events, logs, and traces (often referred to as "MELT" in the observability industry). After you sign up for a free New Relic account and install any of our monitoring services, you can start working with your data.
This doc will give you a fairly technical explanation of our core MELT data types, their structure, and how they're used in our features. You can use most of our features without needing to understand the underlying data structure. But having a better understanding of this can help you get data into New Relic, understand the data you see in our UI, and query your data.
First, we'll explain the definition of metrics from a monitoring industry perspective, and then we'll explain how New Relic handles metrics.
In the software monitoring industry, a metric means a numeric measurement of an application or system. Metrics are typically reported on a regular schedule.
Two major types of metrics are:
- Aggregated data. For example: a count of events over one minute's time, or the rate of some event per minute.
- A numeric status at a moment in time. For example: a CPU temperature reading, or a “CPU% used” status.
Metrics are relatively easy to report and store because a single record can represent a range of time. They can also be aggregated more and more over time. For example, per-minute data may be “rolled up” to per-hour aggregations after some amount of time, and eventually may be rolled up to a per-day aggregation. This approach is efficient for long-term data storage.
Metrics are a strong solution for storing data long-term, and understanding trends over time. One potential downside is that it can be difficult to do detailed analysis of older data that has been aggregated over time; when high detail is required about specific important actions, event data can be used.
Conceptually, "metrics" is a broad, general category. There are various ways New Relic measures and reports metrics but, in practice, when using the New Relic UI, you usually won't have to understand how exactly this happens. In our documentation, we typically will just refer to "metrics," regardless of how that data is reported, unless there's a reason you need to know more (like understanding how to query your data).
Here are some of the ways metrics are reported and stored across the New Relic platform:
Want to report custom metrics? See Get data into New Relic.
First, we'll explain the definition of events from a monitoring industry perspective, and then we'll explain some specifics about how New Relic handles event data.
In the software industry, events can be thought of as simply “things that occur in a system.” For example, a server setting being changed would be an event. Another example: a website user clicking a mouse.
Some events will generate a stored record, and that record is typically also called an event.
Event data represents discrete occurrences and typically will have a high level of detail, so event data is suited for detailed analysis and querying. The downside to the use of event data is that there are typically so many events reported that it can become difficult to query that large dataset over longer time ranges.
At New Relic, we report events to data objects also called events. These events have multiple attributes (key-value pairs) attached. Event data is used in some UI charts and tables, and you can also query it. How long event data remains available is determined by data retention rules.
One example of an event: APM reports an event type named
Transaction, which represents a logical unit of work in an application. To see the attributes attached to this event, you could use a NRQL query like:
Select * from Transaction
For examples of querying event data, see Introduction to NRQL.
Other details about New Relic event data:
- Events can have any type of attributes attached. Some events have attributes that report metric data.
- You can report custom events.
- To increase the availability of your event data for querying/charting, you can turn events into metrics.
- Some systems generate a large number of events that exceeds collection limits and results in incomplete query results. For more on this, see Event sampling.
- Because event is a general term, in some New Relic contexts it will refer to any data type that can be queried via NRQL. For example, when you run a NRQL query, it returns a count of inspected events: this is a count of all data types queried.
First, we'll explain the definition of logs from a monitoring industry perspective, and then we'll explain some specifics about how New Relic handles log reporting.
A log is a message about a system used to understand the activity of the system and to diagnose problems.
In New Relic, log data is reported with multiple attributes (key-value data) attached. To query your log data, you could use a NRQL query like:
Select * from Log
To report custom log data, see the Log API.
First, we'll explain the definition of traces from a monitoring industry perspective, and then we'll explain some specifics about how New Relic handles tracing.
In the application/infrastructure-monitoring world, tracing is a general term used to refer to various ways to report information about how a program or system is operating. For example, a stack trace provides in-depth information about a program's subroutines.
For large modern systems, which are often distributed across many services and micro-services, “tracing” often refers to distributed tracing, which is a way to monitor requests as they propagate through a complex, distributed environment.
New Relic offers a distributed tracing feature that tracks requests across a distributed system, and provides a dedicated UI for understanding and analyzing your traces. In New Relic, trace data is reported as
Span objects, with multiple attributes (key-value pairs) attached.
To query your tracing data, you could use a NRQL query like:
Select * from Span
To learn more about how distributed tracing works, see Understand distributed tracing.
To report custom distributed tracing data, see the Trace API.
Understanding New Relic data types can help you: