Dictionnaire de données New Relic

AjaxRequest events occur for any Ajax request, including during a BrowserInteraction event. The event attribute tracks geographic and browser info. Use browser app settings to block specific requests.

This event is reported by New Relic monitoring for AWS Lambda. This event captures overall function timing and associated metadata. A single AwsLambdaInvocation event is generated for each invocation.

This event is reported by New Relic monitoring for AWS Lambda. It's generated when an error occurs during a Lambda function invocation.

A BrowserInteraction represents a unit of work in a browser session, triggered by a user interacting with the webpage. It captures information about the session, AJAX calls and custom JavaScript timing that occurred as a result of the interaction. Initial load and route changes are captured as special types of browser interactions, and are used for SPA monitoring.

BrowserPerformance events represents performance data gathered through the web Performance API. Presently, it can contain resource timing and user timing.

BrowserTiming is a custom event that captures SPA timing data for browser interactions started using the custom createTracer SPA API method. BrowserTiming contains many of the same attributes used by other events, especially AjaxRequest.

This event is reported by the New Relic Infrastructure agent. It collects data from all the Docker containers on the host (which may or may not be running). It includes the container's ID, name, image, image name, and metrics about CPU, memory and networking. We take a snapshot of this data every 15 seconds for each container and package it into this event, which is then sent to New Relic. This data appears on the Containers UI page.

Deployment events occur for changes you decide to follow using the change tracking feature.

This event contains summary data about a distributed trace and provides an aggregated view of distributed tracing data. DistributedTraceSummary events are generated by New Relic and are triggered by distributed tracing data from agents or the Trace API. This event only appears in the parent account.

InfrastructureEvent describes changes (deltas) that occur in a system's live state. When an inventory or system state is added, removed, or changed, Infrastructure will produce an InfrastructureEvent that logs that activity.

As JavaScript errors are triggered, we capture details as events. The JavaScriptError event contains information to help you segment errors to understand how they impact performance.

This event contains Kubernetes API server data.

This event contains Kubernetes cluster data.

This event contains Kubernetes container data.

This event contains Kubernetes controller manager data.

This event contains Kubernetes CronJob data.

This event contains Kubernetes DaemonSet data.

This event contains Kubernetes deployment data.

This event contains Kubernetes endpoint data.

This event contains Kubernetes etcd data.

This event contains Kubernetes horizontal pod autoscaler data.

This event contains Kubernetes Job data.

This event contains Kubernetes namespace data.

This event contains Kubernetes node data.

This event contains Kubernetes pod data.

This event contains Kubernetes ReplicaSet data.

This event contains Kubernetes scheduler data.

This event contains Kubernetes service data.

This event contains Kubernetes StatefulSet data.

This event contains Kubernetes volume data.

An event that corresponds to each message (sent and received) from a chat completion call. These messages include those created by the user, assistant, and system.

An event that captures high level data about the creation of a chat completion for request and response messages.

An event that captures data specific to the creation of an embedding.

Represents a metric data point (a measurement over a range of time, or a sample at a specific point in time) with multiple attributes attached, which allow for in-depth analysis and querying. This metric data comes from our Metric API, our Telemetry SDKs, network performance monitoring, and some of our open-source exporters/integrations.

A Mobile event is created when a crash occurs, when an interaction ends, or when the harvest cycle is triggered. The harvest cycle typically occurs every 600 seconds (10 minutes), but this can vary depending on the app's activity. Events are created during the session and reported when event harvest cycle has ended. Recommendation: Upgrade to the most recent mobile monitoring agent version to take full advantage of the new event types.

The MobileCrash event is created when an app crashes. MobileCrash includes attributes such as crash line number, class, and crash message.

MobileHandledException is sent when an exception is caught and is used for non-fatal exceptions reported to New Relic using the recordHandledException API for Android or iOS.

A MobileRequest event is created when an HTTP request successfully completes, resulting in a response code below 400.

A MobileRequestError is used for HTTP errors or network failures. HTTP errors are HTTP requests that have a status code greater than 400. A network failure is a HTTP request that results in no response. The event is sent when the HTTP request completes.

A MobileSession event is sent when an app is closed, backgrounded, or when 10 minutes of active use has elapsed. This is the source of the general session data used by the other mobile monitoring events. MobileSession captures attributes such as device type, device OS, and geographical information.

NetworkSample event captures the descriptive and state information for each network device associated with a server. It includes the device's interface and address information, as well as current usage data. New Relic samples this data every 10 seconds for each attached network interface and packages it into a NetworkSample event, then sends the raw data to New Relic's collectors.

An NrAiIncident is created when violation of an alerts condition generates a violation event, which passes important information downstream.

An NrAiIncidentExternal event is created when a custom incident event is received via the incident event API.

An NrAiIssue is created when a threshold of an alert condition generates an incident event, which passes important information downstream.

NrAiNotification shows details from every sent notification on your account, including both successful and failed notifications.

NrAiSignal shows details from every NRQL alert condition and every signal on your account, for every aggregation window that passes. This data is posted immediately after each aggregation window is aggregated and evaluated, so it will show you exactly what our alerts are seeing.

An NrAuditEvent is created by New Relic services to record configuration changes made in New Relic products. The data gathered for this event includes the type of account change, actor (user or API key) that made the change, a human-readable description of the action taken, and a timestamp for the change.

This event records usage every hour, and is the equivalent of "real-time" usage. Use this event to observe usage trends over time. The values in this event are estimates and may not correspond exactly with your invoice. For aggregate views of usage across an entire billing period, use NrMTDConsumption.

Once per day, New Relic products generate a NrDailyUsage event. Use the productLine attribute to identify and filter for the specific product's usage.

The NrIntegrationError event captures error messages related to data ingest, such as exceeding limits or malformed data.

This event tracks your New Relic usage (data and billable users) and estimated cost across an entire calendar month. It generates aggregate values from the NrConsumption event.

This event records usage every hour and is used to see usage reported per product.

Each time a query is executed on behalf of a user in your account an NrdbQuery event is published. Events contain the full query string, information about when and where it originated, and how it performed.

The Browser PageAction event is the result of the addPageAction API call that sends a user-defined name and optional attributes, along with several default attributes, such as app and geographic data. It is used to capture any event that is not already tracked automatically by the Browser agent, such as clicking a Subscribe button or accessing a tutorial.

PageView events occur when a user navigates to (loads) a new page. It tracks geographic and timing data for each browser page load.

This event represents individual timing events during a page view lifecycle (for example, time when the largest element is displayed, or the first user interaction with the page). See the PageViewTiming docs for a list of reported events.

ProcessSample event gathers detailed resource usage information from programs running on a single system. New Relic samples the data every 20 seconds for every active process and packages it into a ProcessSample event, which then sends the raw data to New Relic's collectors.

This event is created when we periodically calculate the compliance and remaining error budget for a given service level entity.

Span events are created when New Relic agents, or other tracing instrumentation tools, instrument operations that are part of a distributed trace. The operations that a span can represent include datastore queries, calls to other services, and method-level timing. For example, in an HTTP service, a span is created at the beginning of an HTTP request and completed when the HTTP server returns a response. Span attributes contain important information about the operation that the span represents (such as duration, host data, etc.), including trace state details (such as traceId, guid) that allow New Relic to connect spans together in a trace.

StorageSample event represents a single storage device associated with a server. Each sample gathers descriptive information about the device, the type of file system it uses, and its current usage and capacity. New Relic samples this data every 20 seconds for each mounted file system and packages it into a StorageSample event, then sends the raw data to New Relic's collectors.

SyntheticCheck returns metrics from one run of a specific monitor. These metrics include duration information for the monitor, location of the monitor check, size of the request and response headers, the type of monitor, and a timestamp. Each time a synthetic monitor runs a check, details about the check are captured in the SyntheticCheck event type. SyntheticCheck events contain details specific to the check to provide visibility such as the status, type of monitor, and size of request and response headers.

SyntheticRequest returns results from individual HTTP requests made during a check. The data gathered includes job information, location, type of content for request, duration information, request size, and page load information. With each simple or scripted monitor check, we capture each individual HTTP request made during the check. The HTTP details are captured at a more granular level than the SyntheticsCheck event type.

Every monitor check running on a private location triggers capacity details for that private location. These details are captured in a SyntheticPrivateLocationStatus event. This provides visibility into the capacity of a private location and whether additional minions are required to support the workload.

If you have private locations, such as those inside your firewall, you can view information regarding those locations with the SyntheticsPrivateMinion event. Each private minion running sends health details to SyntheticPrivateMinion every 30 seconds. This allows you to understand the health of the private minion running at the location.

The SystemSample event aggregates data describing the current overall state of the entire server. This data appears in the New Relic Infrastructure Hosts page to show usage trends for the associated host's main resources. These resources include CPU, memory, disk, and network. New Relic samples this data every 5 seconds and packages it into a SystemSample event, then sends the raw data to New Relic's collectors.

A transaction is a logical unit of work in a software application, such as HTTP requests, SQL queries, background processes, message queue activity, etc. The Transaction event includes information about the app, database calls, the duration of the transaction, and any errors that may occur.

Transaction errors occur when a transaction throws an exception in the code path that was taken to complete that transaction. The number of transaction errors does not equal the number of transactions, because you can specify whether you want to collect, ignore, or mark errors as expected.

The Browser UserAction event is captured as the result of a user interaction with the web application and includes action information and DOM target identifiers along with several default attributes, such as app and geographic data.

The types of interactions captured include:

• auxclick
• blur (window only)
• click
• copy
• focus (window only)
• keydown
• paste
• scrollend

Please see element events for more information about the type of events the agent subscribes to when capturing UserAction events.

VideoAction events occur when a user performs any action in the video player. It tracks geographic and timing data for each video being played.

VideoAdAction events occur when a user performs any action in the video player while ad occurs. It tracks geographic and timing data for each video ad being played.

VideoCustomAction event is the result of the addCustomAction API call that sends a user-defined name and optional attributes, along with several default attributes, such as app and geographic data. It is used to capture any event that is not already tracked automatically by the agent, such as breadcrumbs.

VideoErrorAction events occur when there is an error/app crash while user playing video/add. It tracks geographic and timing data for each video ad being played.

New Relic Vulnerability Management is an opinionated solution that helps Devs, SREs, and Infosec teams build and run secure software with more confidence and less effort by centralizing, organizing, and prioritizing security risks in observability context.

The workload status is derived from the alerting status of entities in your workload. This allows you to set up an alert condition to notify you whenever the workload goes into a DISRUPTED or DEGRADED status.