---
title: Concepts
description: The core objects and terms in APM v2 - entities, signals, spans, traces, operations, transactions, span metrics, health policies, cases, and apdex.
url: https://coralogix.com/docs/user-guides/apm-v2/concepts/
product: apm
feature: APM Overview
feature_id: apm-general
feature_identifier: apm/apm-general
last_updated: '2026-10-20'
---

# Concepts

APM v2 is built on a small set of objects. This page defines them once, so the rest of the documentation can use them precisely.

| Term              | What it is                                                                                                                                                                                                                          |
| ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Entity**        | A service or database APM v2 monitors, each with its own health model. Entities are what the [catalog](https://coralogix.com/docs/user-guides/apm-v2/services.md) lists and what you open to drill into.                            |
| **Signal**        | A data source reporting for an entity - **Traces**, **Profiling**, **Infra**, **Transactions**, **Runtime metrics**, **Ops events**, or **RUM**. The catalog's Signal column shows which are active.                                |
| **Span**          | A single timed operation in a distributed trace - one unit of work, such as an HTTP handler or a database call.                                                                                                                     |
| **Trace**         | The full set of spans for one request as it moves across your services.                                                                                                                                                             |
| **Operation**     | A class of span, grouped by name - for example an endpoint (`GET /cart`) or a database statement (`SELECT`). Metrics aggregate spans by operation.                                                                                  |
| **Transaction**   | A request that enters a service, identified by its entry-point operation (the root span). Transactions are the service's incoming work. See [Transactions](https://coralogix.com/docs/user-guides/apm-v2/features/transactions.md). |
| **Span metric**   | A metric Coralogix derives from your spans - the RED metrics that power the catalog, charts, and health. See [Span metrics](https://coralogix.com/docs/user-guides/apm-v2/getting-started/span-metrics.md).                         |
| **RED metrics**   | The three golden signals: **R**ate (requests), **E**rrors, and **D**uration (latency).                                                                                                                                              |
| **Health policy** | A rule that contributes to an entity's health state - apdex, error rate, latency, log errors, cases, or SLOs. See [Service health](https://coralogix.com/docs/user-guides/apm-v2/features/service-health.md).                       |
| **Case**          | An operational issue linked to an entity, from Coralogix [Cases](https://coralogix.com/docs/user-guides/cases/overview.md).                                                                                                         |
| **Apdex**         | A score from 0 to 1 that measures user satisfaction with a service's response time against a threshold. See [Apdex score](https://coralogix.com/docs/user-guides/apm-v2/features/apdex-score.md).                                   |

## Entities, signals, and health

An **entity** is the thing you monitor - a service or a database. Every entity carries a **health** state derived from its **health policies**, and reports one or more **signals** (spans, profiling, infrastructure) that populate its telemetry. The [catalog](https://coralogix.com/docs/user-guides/apm-v2/services.md) lists your entities; opening one takes you into its drilldown.

## Spans, operations, and transactions

These three describe your traffic at increasing levels of aggregation:

* A **span** is one operation instance inside a trace.
* An **operation** groups spans of the same kind - every `GET /cart`, or every `SELECT` against a table.
* A **transaction** is a request that enters a service - its root operation - together with the segments and spans beneath it.

For databases, the equivalent of a transaction is an **operation**: a class of query, such as a `SELECT` against a given table.

## Span metrics and RED

Coralogix reads your spans and derives **span metrics** - counters and histograms for requests, errors, and duration (**RED**). These power the catalog, the overview widgets, and the health model, so you read golden signals without querying raw traces. An entity needs span metrics to appear in the catalog; an account needs [compact span metrics](https://coralogix.com/docs/user-guides/apm-v2/getting-started/using-compact-span-metric.md) on services **and** databases to access APM v2.

## Next steps

Get your services reporting in the [onboarding tutorial](https://coralogix.com/docs/user-guides/apm-v2/getting-started/apm-onboarding-tutorial.md).