[Yandex Cloud documentation](../../index.md) > [Monium](../index.md) > Concepts > Basic terms

# Basic Monium terms

This section describes the terms used in Monium and its guides.

## Common terms in Monium {#common-terms}

### Quick links {#project-menu}

_Quick links_ are links displayed in the Monium interface that you can configure for each [project](#project) via the UI or API.

### Timeseries {#timeseries}

_Timeseries_ is a time-ordered set of values of a variable with a timestamp for each measurement: `[[(time_stamp_1, value_1), (time_stamp_2, value_2), ...]`. For more information, see [Data model in Monium.Metrics](data-model.md).

### Chart {#graph}

1. Visual representation of a set of [metrics](#metric).
1. [Dashboard](#dashboard) element.

### Alert {#alert}

An _alert_ is a Monium configuration object that calculates a query or expression at regular intervals and changes its status, e.g., to `OK`, `Warning`, `Alarm`, or `No data`. You can use alerts to monitor metric state and get notifications about issues. For more information, see [Alert](alerting/alert.md).

### Multialert {#multi-alert}

A _multialert_ is an alert that automatically splits into multiple subalerts based on the values of one or several [labels](#label). Each subalert is calculated independently. For more information, see [Multialerts](alerting/alert.md#multi-alerts).

### Subalert {#subalert}

A _subalert_ is an automatically created alert within a multialert. Subalerts are generated when a multialert is split by selected labels, e.g., `host` or a combination of `host` and `disk`. Subalerts inherit their settings from the parent multialert. For more information, see [Multialerts](alerting/alert.md#multi-alerts).

### Mute {#mute}

A _mute_ is a rule that temporarily stops notifications for alerts, multialerts, or subalerts based on the selectors you set. A mute suppresses notifications but does not interrupt alert evaluation. For more information, see [Mutes](../alerts/mutes.md).

### Dashboard {#dashboard}

_Dasboard_ is a Monium configuration object that includes sets of [charts](#graph) and their display settings.

### Cluster {#cluster}

_Cluster_ is a Monium configuration object defining the set of hosts Monium will poll to collect metrics in metric Pull mode. The cluster is usually aligned with the environment (installation) of the client application delivering the metrics, e.g., production, test, or regional clusters.

### Label {#label}

_Label_ is a pair of strings in `<name>="<value>"` format, e.g., `host="monitoring-kfront-man-00"` or `code="200"`. Labels describe various slices used to visualize metrics delivered to Monium. A set of labels identify a [metric](#metric). For more information, see [Data model in Monium.Metrics](data-model.md).

### Metric {#metric}

_Metric_ is a [timeseries](#timeseries) and its identifying set of [labels](#label) enclosed in curly brackets.

### Dashboard parameter {#dashboard-param}

_Dashboard parameters_ let you create interactive dashboards whose content changes depending on the user's choice. For example, a dashboard presenting aggregated VM status information can be parameterized using the VM ID.

### Project {#project}

_Project_ is a top-level Monium configuration object containing observation data. It is used for logical grouping of related services and assignment of access permissions for telemetry data to project teams. A project can contain data on resources of an individual [folder](../../resource-manager/concepts/resources-hierarchy.md#folder), in which case the project ID format is `folder_<folder_ID>`. With a project, you can restrict access to data by assigning [roles](../../iam/concepts/access-control/roles.md).

### Decimation {#downsampling}

1. _Read data decimation_ is a mechanism that limits the number of data points on the [chart](#graph). For more information, see [Read data decimation](decimation.md#reading-decimation).

1. _Historical data decimation_ is a mechanism used to archive historical data in Monium. To reduce the amount of stored historical data, all metrics saved in Monium get aggregated on a 5-minute grid after a week. For more information, see [Historical data decimation](decimation.md#history-decimation).

### Service {#service}

_Service_ is a Monium configuration object that defines the methods used to deliver data to Monium (Pull or Push). The service is usually aligned with the client application delivering the metrics, e.g., a web server, database, or another component.

### Shard {#shard}

_Shard_ is a Monium configuration object that owns the metrics from a particular [service](#service)-[cluster](#cluster) pair, as well as their storage settings, e.g., [TTL](#ttl).

### Expression Language {#query-language}

_Expression Language_ (or simply Expression) is a method to describe how to calculate and transform metrics when configuring charts and alerts and exporting data over the API. For more information, see [Query language in Monium](querying.md).

### TTL (Time-to-Live) {#ttl}

_TTL_ is a mechanism used to automatically delete obsolete data that has not been updated over a specified period of time.

For example, a seven-day TTL for metrics means that they will be automatically deleted if the timestamp of their latest data point is older than seven days.

For more information, see [TTL (Time-to-Live)](#ttl).

### Unified Agent {#unified-agent}

_Unified Agent_ is a program used to collect, store, transform, and deliver metrics and logs to Monium.

## Logging terms {#logging-terms}

### Log line (log record) {#log-row}

The smallest data processing unit in the system. It represents a system event, its description, timestamp, and labels that identify it.

### Log line size {#log-row-size}

Log line size in bytes represents the sum of all top-level field values, as well as the lengths of all keys and values from `labels` and `meta`.

### Event lag {#event-lag}

Event lag is the latency between when the event was generated in the user system and when it was delivered to the centralized logging system (upstream of the collector).

### Observed lag {#observed-lag}

Observed lag is the latency between when the event was first processed by the collection agent and when it was delivered to the centralized logging system (upstream of the collector).

## Tracing terms {#tracing-terms}

### Request tracing {#tracing} 

Request tracing is there for analysis of distributed requests. It allows you to visualize and track the execution path of a specific request as it passes through many different services and infrastructure components. Request execution path is a sequence of operations called spans.

### Span {#span}

A span is a basic distributed tracing element representing a single operation in your system. For example, this may be a database query, an HTTP request, or a function call. Each span comes with a name, start and end time, labels, logs, and execution context. Spans may contain links to other spans to join them together into a trace.

### Trace {#trace}

A trace is a combination of spans forming the execution path of a particular request.