---
title: "Metrics"
description: "Learn how to configure and access standard and extended metrics in the Aerospike Node.js client."
---

# Metrics

> For the complete documentation index see: [llms.txt](https://aerospike.com/docs/llms.txt)
> 
> All documentation pages available in markdown.

The Aerospike Node.js client implements the standard client-side metrics system. For a comprehensive overview of the available metrics please see the [Client Metrics documentation](https://aerospike.com/docs/develop/learn/metrics).

This page focuses on the Node.js-specific details for configuring and accessing these metrics.

## Configuring Metrics Collection

The Node.js client collects a standard set of essential metrics by default. You can enable more detailed “extended” metrics, which include latency histograms and transaction-level details.

The Node.js client offers two ways to enable extended metrics: via [Dynamic Client Configuration](https://aerospike.com/docs/develop/learn/dynamic-client-config) or programmatically. The preferred method is using Dynamic Client Configuration, as it allows operators to enable detailed metrics for diagnostics without requiring an application restart or code change.

#### Using Dynamic Client Configuration (preferred)

Metrics can be enabled and configured dynamically if your application is set up for [Dynamic Client Configuration](https://aerospike.com/docs/develop/learn/dynamic-client-config). This allows operators to manage metrics collection without code changes or application restarts. See the [Dynamic Client Configuration Quickstart](https://aerospike.com/docs/develop/learn/dynamic-client-config/quickstart) for details on how to get started.

::: note
You can update the metrics policy dynamically using [Dynamic Client Configuration](https://aerospike.com/docs/develop/learn/dynamic-client-config). However, be aware that changes to the metrics configuration (such as enabling/disabling extended metrics, changing labels, or adjusting reporting intervals) may affect your ability to compare new metrics data with previously collected metrics. For consistent analysis, ensure that configuration changes are tracked and considered when interpreting historical trends.
:::

#### Programmatic configuration

You can also enable extended metrics directly in your application code using a `MetricsPolicy`.

To enable extended metrics programmatically, create a `MetricsPolicy` and pass it to the client:

```js
const policy = new Aerospike.MetricsPolicy({

  reportDir: "./metrics_sub_dir/example_dir",

  interval: 600, // Write metrics snapshot approximately every 600 seconds.

});

// Enable extended metrics collection

await client.enableMetrics(policy);
```

You can disable the collection of extended metrics at any time:

```js
// Disable extended metrics collection

await client.disableMetrics()
```

### Accessing metrics

There are two primary ways to access metrics from the Node.js client:

1.  **On-demand snapshot:** you can get a snapshot of the currently collected metrics at any time using `stats()`:

```js
let clusterStats = client.stats()

console.log(clusterStats);
```

2.  **Metrics log file:** when a `MetricsPolicy` with a `reportDir` is active, the client will periodically write a snapshot of the collected metrics to a log file. The format of this log is described in the main [Client Metrics documentation](https://aerospike.com/docs/develop/learn/metrics).

### Setting client identification labels

You can add labels to your client instance to distinguish its metrics from those of other applications. These labels are configured on the `ClientPolicy` and apply to all metrics generated by that client.

```js
// Example: Set an App ID and custom labels for all metrics from this client

const config: any = {

  hosts: '192.168.33.10:3000',

  appId: "recommendation-engine",

}

let policy: MetricsPolicy = new Aerospike.MetricsPolicy({

    labels: {"owner": "data-science-team"}

  }

)

client = await Aerospike.connect(config)

await client.enableMetrics(policy)
```

### `MetricsPolicy` configuration

The `MetricsPolicy` object has the following fields to control how metrics are collected and reported:

-   `metricsListeners`: Handles metrics notification events. The default implementation writes to a file, but this can be overridden to send metrics to other systems like OpenTelemetry.
-   `reportDir`: Directory for the metrics log files.
-   `reportSizeLimit`: A soft limit for the log file size in bytes. When this limit is exceeded, a new file is created. A value of `0` means the file size is unbounded.
-   `interval`: The number of cluster tend iterations (which occur every second by default) between writing metrics snapshots to the log.
-   `latencyColumns`: The number of buckets to use in latency histograms.
-   `latencyShift`: A power-of-2 multiplier that defines the range of each latency bucket.
-   `labels`: Object containing name/value labels applied when exporting metrics.

You can update metrics policy dynamically. However, be aware that changes to the ‘configuration’ could compromise your ability to compare new data with previously collected metrics.