New Relic data types

You can use most New Relic features without needing to understand the underlying data structure. But understanding New Relic data categories can help you:

New Relic supports four categories of telemetry data commonly recognized in the monitoring industry:


First, we’ll explain the definition of metrics from a monitoring industry perspective, and then we’ll explain how New Relic handles metrics.

Metrics in the monitoring industry

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.

Metrics at New Relic

Conceptually, "metrics" is a broad category that covers many different ways systems can be measured. To improve your ability to query your New Relic data and get data into New Relic, it can help you to understand the different approaches New Relic takes to handling metric data:

Dimensional metrics (sent by Metric API, Telemetry SDKs)

In September 2019, we introduced a Metric API for sending detailed metric data to New Relic, without the need for an agent. Our Telemetry SDKs (and the open-source exporters that use them) also send this type of data.

Each metric data point has a variety of attributes (key-value pairs) attached to it, which allow for in-depth analysis and querying. In the monitoring industry, metrics with multiple key-value pairs are sometimes called "dimensional metrics."

To query your metrics, you could use a NRQL query like:

Select * from Metric

As time passes, these metrics are increasingly aggregated into larger time buckets. This is done to optimize your ability to query data over a long period of time.

Metric timeslice data (sent by APM, Browser, Mobile)

New Relic APM, Browser, and Mobile report and display metrics in a format that we call metric timeslice data (not to be confused with dimensional metrics). A metric timeslice consists of three parts: a metric name, the segment of time the metric represents (the "timeslice"), and a numeric value (the measurement).

For example: a New Relic APM metric timeslice for time spent in a particular transaction is named WebTransaction/URI/foo, and might have a response time of 0.793 for a one-minute time slice from 10:20 A.M. to 10:21 A.M.

New Relic agents can collect thousands of metric timeslices per minute for a variety of performance metrics. For example: error rate, bandwidth usage, and garbage collection time.

To query metric timeslice data, use the New Relic Insights' metric data explorer or use our REST API.

Metric timeslice data is lightweight, but it lacks the detail that metric time series data has.

Metrics as attributes on events (sent by Infrastructure)

New Relic Infrastructure reports metrics as attributes on our event data. For example, New Relic Infrastructure reports a ProcessSample event, which has various sample-based metrics attached to it, like CPU percentage.

Another example: our Kubernetes integration reports metrics attached to a K8sSample event type. You would query it with a NRQL query like:

Select * from K8sNodeSample
Metrics as a computation of events

Metrics can be formed by counting New Relic events, or doing some other mathematical calculation on those events. For example, if you wanted to measure the total number of Transaction events over the last half hour, you might run this NRQL query:

Select count(*) from Transaction since 30 minutes ago

Another example: if you wanted to compute the average response time for your service, you might run a query like:

FROM Transaction SELECT average(duration) SINCE 30 minutes ago

Some New Relic charts are generated with these kinds of queries. The downside of this approach is that there are limits on how many events a monitoring system (including ours) can report. This means that sometimes, for high-throughput systems, the count may not accurately represent the total activity on that system. To learn more about this can be addressed, see Event limits and sampling.

Want to report custom metrics? See Get data into New Relic.

Event data

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.

Events in the monitoring industry

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 has a high level of detail, so it’s very useful for very detailed analysis and querying. The downside to event monitoring is that there are typically such a large amount of events reported that it can become difficult to query that data easily over longer time ranges.

Events at New Relic

At New Relic, we report events to data objects called events, which have multiple attributes (key-value pairs) attached.

For example: New Relic APM reports an event named Transaction, which represents a logical unit of work in an application. To see the attributes attached to this event, you’d use a NRQL query like:

Select * from Transaction

Some New Relic charts display event data. For these charts, you can view the NRQL query that generated them.

In some cases, events are reported at specific scheduled intervals, and can have metric data attached in the form of attributes. For example, the New Relic Infrastructure integration for Kubernetes reports an event K8sNodeSample that reports a memoryAvailableBytes metric.

To send custom events to New Relic, you can use the Event API.

Some high-throughput systems can generate a large number of events, and this may reach event-collection limits. For more on this, see Event limits and sampling.

Log data

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.

Logs in the monitoring industry

A log is a message about a system used to understand the activity of the system and to diagnose problems.

Logs at New Relic

New Relic offers a logging feature that gives you a centralized log management platform that connects your log data with the rest of your New Relic-monitored data. 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 distributed tracing data, see the Log API.

Trace data

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.

Tracing in the monitoring industry

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.

Tracing at New Relic

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 report custom distributed tracing data, see the Trace API.

Query and send data

Understanding New Relic data types can help you:

For more help

Recommendations for learning more: