New Relic Performance Engineer key terms

The four core service health metrics: latency, traffic, errors, and saturation. Performance engineers use them to prioritize what to instrument and alert on before drilling into detailed telemetry.

A standardized user-satisfaction index from 0 to 1 computed from response time thresholds: satisfied, tolerating, and frustrated requests. It compresses latency distributions into one comparable number across services.

A detailed record of one slow request's full call path, showing each segment and its timing. Traces reveal which downstream call, database query, or external service consumed most of the response time.

Correlating a single request across multiple services and hosts using propagated trace identifiers. It reconstructs end-to-end timing so teams can find which service in a call chain adds latency.

A single timed operation within a trace, such as a database call or HTTP request, with start time, duration, and attributes. Spans nest to form the tree structure of a distributed trace.

A unique identifier assigned to a request at its entry point and propagated to every downstream service. It lets engineers stitch logs, spans, and errors from one user action together.

A visual graph of services and their dependencies, annotated with health, throughput, and error indicators. It helps identify upstream or downstream services responsible for degraded performance.

Response time reported at a rank such as p50, p95, or p99, showing the tail experience rather than the average. Tail percentiles expose slow outliers that averages hide.

The proportion of requests failing over a period, typically split by error class and transaction name. Rising error rate alongside latency often signals saturation or a failing dependency.

The number of requests or transactions a service processes per unit time, often called requests per minute. It contextualizes latency and error metrics because load changes their meaning.

How fully a resource such as CPU, memory, connection pool, or queue is utilized relative to its capacity. High saturation predicts imminent latency growth and is a leading indicator of incidents.

Code-level additions using an agent API to time business methods, record attributes, or create segments the automatic agent cannot infer. It extends visibility into domain logic and internal workflows.

The language-specific library installed in an application that instruments requests, reports metrics and traces, and forwards telemetry to the observability platform. Configuration and version affect data quality.

The rule set that determines how requests are grouped into named transactions, such as by route pattern rather than raw URL. Poor naming fragments metrics and breaks trend comparisons.

Real user monitoring via a JavaScript agent that captures page load timing, AJAX calls, JavaScript errors, and session data from actual visitors. It measures the client-side experience beyond server response time.

Google's user-experience metrics covering loading (LCP), interactivity (INP), and visual stability (CLS). Performance engineers track them to align front-end optimization with search and UX goals.

Scripted, agent-driven checks that simulate user journeys from multiple locations on a schedule. They provide baseline availability and performance data independent of real traffic volume.

A reconstruction of a real user's browser session, including clicks, navigation, and rendered DOM changes. It helps reproduce front-end defects and understand friction behind performance complaints.

A client-side exception captured by the browser agent with stack trace, page, browser, and affected user counts. Tracking these separates front-end failures from server-side performance problems.

Breakdown of browser navigation phases such as DNS, connect, request, response, and render. It shows whether slowness originates in the network, backend, or front-end rendering.

An asynchronous browser call to a backend endpoint, instrumented separately from the initial page load. Slow or failing AJAX calls often explain perceived sluggishness on otherwise fast pages.

Instrumentation of iOS and Android apps that captures crashes, network calls, and screen-level performance from real devices. It exposes issues unique to mobile networks, OS versions, and device hardware.

A container of alert conditions plus notification and incident preferences that decides when and to whom a signal escalation is sent. Well-designed policies reduce noise and route issues to the right responders.

A threshold, baseline, or anomaly rule evaluated against a metric or event stream inside a policy. It defines the exact signal, aggregation window, and comparison that triggers an incident.

Machine-learning baselining that learns normal behavior per signal and seasonality, then flags deviations rather than fixed limits. It adapts to traffic patterns that static thresholds handle poorly.

A fixed numeric limit, such as error rate above two percent, that triggers an alert when crossed. It is predictable but can misfire when workload or seasonality changes.

A learned or configured reference range describing expected values for a signal over time. Deviations from baseline drive anomaly alerts and comparative analysis.

The platform's AI-assisted capabilities for correlating incidents, detecting anomalies, and suggesting probable root causes across telemetry. It reduces manual triage by grouping related signals into a single issue.

Grouping related alerts and anomalies that share timing, entities, or topology into one incident. Correlation prevents responders from chasing dozens of symptoms of a single underlying failure.

The structured process of tracing an observed symptom back to the originating change, dependency, or resource constraint. It combines traces, logs, deployment markers, and topology evidence.

A target reliability level for a service, expressed as a percentage of good events over a window, backed by indicators. It converts user expectations into an error budget teams can manage.

The measured ratio of good events to total events for a service, such as successful requests under a latency bound. SLOs are defined against these indicators.

The allowed amount of unreliability derived from an SLO, equal to one minus the target over the window. It quantifies how much risk remains before the objective is breached.

A host-level daemon that collects CPU, memory, disk, network, and process metrics and forwards them to the platform. It also runs integrations for services such as databases and web servers.

A plugin configuration that collects metrics from third-party software such as MySQL, NGINX, or Kafka running on a monitored host. It extends infrastructure visibility beyond base system metrics.

A monitored object such as a host, application, container, or service with a unique identity and associated telemetry. Entities enable consistent search, alerting, and relationship mapping across the platform.

A key-value attribute attached to telemetry that supports filtering, grouping, and aggregation. Consistent tagging, including environment and team, is essential for reliable dashboards and alerts.

A numeric time series describing a measured quantity, such as CPU percent or request count, at intervals. Metrics are efficient for trends and alerting but sample away individual event detail.

A timestamped record of a discrete occurrence, such as a deployment, error, or custom business action. Events answer what happened at a moment, complementing aggregated metrics.

A timestamped text record emitted by an application or system describing an occurrence. Logs provide high-detail context that metrics and traces cannot, especially for error diagnosis.

Rules that extract structured attributes from raw log lines using patterns or grok-style expressions. Parsed fields become queryable and usable for filtering, grouping, and alerting.

Linking log entries to traces, transactions, or entities through shared identifiers so engineers can pivot between them. It shortens diagnosis by connecting a symptom to its detailed evidence.

The platform's SQL-like query language for querying metrics, events, logs, and traces. It powers dashboards, alerts, and ad hoc analysis with clauses like SELECT, FROM, WHERE, and FACET.

A curated collection of charts and query widgets arranged to communicate system health at a glance. Good dashboards separate overview signals from drill-down detail for different audiences.

A recorded timestamp of a code or configuration release overlaid on charts and timelines. It lets engineers test whether a change correlates with a shift in performance or errors.

The configured period for which each telemetry type remains queryable before aging out or being summarized. Retention limits what historical comparisons and post-incident reviews are possible.