New Relic Verified Foundation cheat sheet

APM agents instrument applications and report transactions, segments, and errors to New Relic; agent language and version determine which features (e.g., distributed tracing, code-level metrics) are available.

A transaction is a single logical unit of work (e.g., a web request or background job); segments are the timed spans inside it, and the transaction breakdown attributes response time to database, external service, and application code.

Apdex = (satisfied + tolerating/2) / total responses, where satisfied <= T and tolerating <= 4T for the configured threshold T; scores range 0 to 1 and 0.94+ is generally considered healthy.

Throughput is measured in rpm (requests per minute) and error rate as a percentage; response time percentiles (median, 95th, 99th) reveal tail latency that averages hide.

Distributed tracing links spans across services and hosts via trace headers; a trace shows the full call path, per-span duration, and which downstream service introduced the delay.

Errors Inbox groups error events by fingerprint and supports assignment, marking, and triage status; error profiles aggregate stack traces across occurrences.

Browser and mobile data can be correlated with backend APM via distributed tracing and entity relationships, so a slow page can be traced to a specific backend span.

Key transactions and synthetic monitors can alert independently of overall application health; alert policies attach to entities and evaluate NRQL conditions.

Browser monitoring has two modes: the full agent (paste a JavaScript snippet / agent injection) captures page load timing, AJAX calls, JS errors, and session data; the Lite agent is a lightweight snippet limited to core page-load timing.

Core Web Vitals tracked include Largest Contentful Paint (LCP), Interaction to Next Paint (INP, which replaced First Input Delay), and Cumulative Layout Shift (CLS), plus supporting metrics such as First Contentful Paint and Time to First Byte.

Page load timing breaks into network, backend, DOM processing, and page rendering phases; the browser agent reports these as PageView events and PageAction events for interactions.

Session replay records sampled user sessions with DOM changes and user interactions, and can be linked to JS errors and network requests to reproduce a reported problem.

Synthetic monitoring runs scripted checks from public or private (location-based) minions; simple (ping), browser, and scripted API monitors differ in what they can validate and their frequency limits.

Synthetic results include success/failure, duration, and per-step screenshots for browser monitors; alert conditions can fire on failures from one or more locations.

Mobile monitoring supports iOS and Android apps via SDKs, capturing crashes, handled exceptions, HTTP requests, and mobile-specific vitals like app launch time.

Real User Monitoring (RUM) data is subject to sampling and data retention limits; adjusting sampling or agent configuration changes the volume and cost of ingested data.

New Relic AI (the AI assistant) answers natural-language questions about your telemetry and can generate NRQL queries and explanations grounded in the account's data.

Applied Intelligence detects anomalies using baselines learned from historical behavior rather than static thresholds, reducing alert noise for seasonal or spiky metrics.

Anomaly detection can be configured per alert condition; decisions include whether to use static thresholds or anomaly-based (baseline) evaluation.

AI-driven alerting groups related incidents and surfaces probable root cause signals across entities, complementing user-defined alert policies.

The AI assistant is scoped to the user's permissions and data access; it does not grant visibility into accounts or data the user cannot already query.

NRQL generation and natural-language-to-query features require valid entity/account context; ambiguous questions produce better results when scoped by entity GUID, app name, or time range.

AI features are governed by account tier and feature flags; availability can vary by region and by data-privacy settings configured for the account.

Change tracking and deployment markers feed correlation features, letting AI-assisted analysis relate performance shifts to recent deployments or configuration changes.

The infrastructure agent runs on hosts (Linux, Windows) and collects metrics such as CPU, memory, disk, and network; integrations (on-host and cloud) add service-specific metrics.

Cloud integrations (e.g., AWS, Azure, GCP) use provider APIs or metric streams to poll services such as EC2, RDS, and Lambda without installing an agent on each resource.

The entity model links hosts, applications, and services into a dependency map; entity GUIDs uniquely identify monitored resources across the platform.

Kubernetes monitoring uses the Kubernetes integration (and Pixie for eBPF-based data) to collect cluster, node, pod, and workload metrics plus events.

Infrastructure events are queryable via NRQL against metric and event types such as SystemSample, StorageSample, NetworkSample, and ProcessSample.

Network monitoring provides flow-based visibility into traffic between workloads, hosts, and cloud services, useful for identifying chatty or blocked connections.

Alert conditions on infrastructure metrics commonly use thresholds on averages or percentiles over sliding windows; multi-location and gap-filling settings affect evaluation.

Host not reporting conditions detect silent agents; entity health status (green/yellow/red) rolls up alert state from attached conditions.

Logs are ingested via the infrastructure agent's log forwarding, the New Relic log API, or third-party forwarders; parsed attributes become queryable fields in Log events.

NRQL log queries use the Log event type with clauses such as SELECT * FROM Log WHERE level = 'ERROR' SINCE 1 hour ago, and FACET to group by attributes like host or service.

Log parsing rules transform raw messages into structured attributes (e.g., extracting status codes or timestamps) and can be applied at ingest or via pipelines.

Logs in context links application logs to APM entities using attributes such as entity.guid, trace.id, and span.id, enabling navigation from a trace to related log lines.

Log patterns (clustering) group similar messages into patterns to surface new or anomalous log volume without writing per-message queries.

Drop filters and data partitions control which log data is stored and for how long; partitions with longer retention cost more per GB.

Log retention and ingest limits follow account tier and data options; exceeding the included volume results in overage charges or dropped data depending on configuration.

Live tail streams logs in real time for troubleshooting without waiting for ingest and indexing; it is a diagnostic view, not a substitute for stored queries.

NRQL is the query language across all telemetry: SELECT ... FROM [WHERE] [FACET] [TIMESERIES] [LIMIT], with functions like average(), percentile(), count(), and rate().

Dashboards are built from widgets (charts, tables, billboards) backed by NRQL or entity queries; they can be shared, templated with variables, and set to auto-refresh.

Alerts consist of policies, conditions, and notification channels/destinations; workflows route issues to destinations such as email, Slack, PagerDuty, or webhooks.

The entity explorer and service maps visualize relationships and health across applications, hosts, and services, using tags for filtering and grouping.

The NerdGraph GraphQL API and REST APIs support automation, while Terraform and CLI tooling manage dashboards, alerts, and configurations as code.

Workloads group related entities so health and alerts can be viewed and targeted at a business-service level rather than per-resource.

Tags (key/value) drive filtering, access, and grouping across the platform; consistent tagging is the basis for entity search and workload definitions.

Data retention and sampling differ by data type: metrics, events, logs, and traces each have their own retention windows and query limits.

New Relic's usage-based model charges primarily by ingested data volume (per GB) plus per-user pricing, rather than per host; the Free tier includes a monthly data allowance and one full user.

Data ingest is priced by data type (e.g., APM events, infrastructure metrics, logs, browser data), so shifting data between types can change cost even at equal volume.

Users are billed by type: full platform users vs. basic/full-portal-access users have different capabilities and prices; read-only or basic users cost less or are free depending on tier.

The Free tier caps data ingest and full users; exceeding limits requires upgrading to a paid tier, and features such as longer retention or advanced capabilities vary by tier.

Original and Pro/Enterprise-style tiers differ in included data, support, and advanced features; check the current pricing page because tiers and allowances change.

Data retention options (e.g., extending log retention via data partitions) carry additional cost; retention is a pricing lever distinct from ingest volume.

Cost management tools include usage dashboards, data ingest budgets, and alerts on ingest spikes; drop filters and sampling reduce billable volume.

Annual commitments and volume discounts can lower per-GB pricing versus on-demand; billing is calculated on data ingested after filtering, not on raw bytes sent.