<commit_before>{% import "macros.jinja" as macros %}

{% if target == "docs" -%}
# Splunk Infrastructure Monitoring Organization Metrics


- [Description](#description)
- [Usage](#usage)
- [Metrics](#metrics)
{%- endif %}

## DESCRIPTION

Splunk Infrastructure Monitoring provides the following types of metrics that measure your usage:

* Ingest metrics: Measure the data you're sending to Infrastructure Monitoring, such as the number of datapoints you've sent
* App usage metrics: Measure your use of application features, such as the number of dashboards in your organization
* Integration metrics: Measure the use cloud services integrated with your organization, such as the number of calls to the AWS CloudWatch API
* Metrics that measure your use of resources for which you can specify limits, such as the number of custom MTS you've created

You're not charged for these metrics, and they do not count against any limits.


## USAGE

If you're an admin, you can view some of these metrics in built-in charts on the Organization Overview page.
Anyone can display these metrics in custom charts.

### Metrics for values by token

In some cases, Infrastructure Monitoring has two similar metrics:

* One metric, such as `sf.org.numAddDatapointCalls`, represents the total across your entire organization.
* The similar metric, `sf.org.numAddDatapointCallsByToken` represents the total for each unique access token you use.

The sum of all the by token metric values for a measurement might be less than the total value metric value. For
example, the sum, of all `sf.org.numAddDatapointCallsByToken` values might be less than the value of
`sf.org.numAddDatapointCalls`. The sums differ because Infrastructure Monitoring doesn't use a token to retrieve
data from cloud services you've integrated. Infrastructure Monitoring counts the datapoint calls for the integrated
services, but it doesn't have a way to count the calls for any specific token.

This difference in values applies to AWS CloudWatch, GCP StackDriver, AppDynamics, and New Relic integrations.

### Metrics with values for each metric type

Some metrics have a value for each metric type (counter, cumulative counter, or gauge), so you have three MTS per metric.
Each MTS has a dimension named `category` with a value of `COUNTER`, `CUMULATIVE_COUNTER`, or `GAUGE`. Because you can have
multiple MTS for these metrics, you need to use the `sum()` SignalFlow function to see the total value.

For example, you might receive three MTS for `sf.org.numMetricTimeSeriesCreated`, one for the number of MTS that are counters, another for the number of MTS that are cumulative counters, and a third for the number of MTS that are gauges.

Also, you can filter by a single value of `category`, such as `GAUGE`, to see only the metrics of that type.

### A metric that counts stopped detectors

The metric `sf.org.numDetectorsAborted` monitors the number of detectors that Infrastructure Monitoring
stopped because the detector reached a resource limit. In most cases, the detector exceeds the limit of 250K MTS.
MTS exceeds 250K. This condition also generates the event
`sf.org.abortedDetectors`, which records details including the detector ID, the reason it stopped, and
the value or limit of MTS or datapoints, whichever caused the detector to stop.

To learn more, see [View Additional Data With Events](https://docs.signalfx.com/en/latest/detect-alert/events-intro.html).

### Metrics that track contractual limits

Two metrics track limits set for your organization as part of your contract:

* `sf.org.limit.activeTimeSeries`: As part of your contract, Infrastructure Monitoring lets you have this number of active MTS in your organization. If you
  exceed your limit, Infrastructure Monitoring stops creating new MTS while continuing to add datapoints to existing MTS.
* `sf.org.limit.metricTimeSeriesCreatedPerMinute`: As part of your contract, Infrastructure Monitoring lets you create this number of MTS
  per minute. If you exceed this rate, Infrastructure Monitoring stops creating MTS.

Infrastructure Monitoring only sends datapoints if the value is not zero.

### Metrics that track system limits

Three metrics track limits that Infrastructure Monitoring enforces for all organizations:

* `sf.org.limit.hosts`: Maximum number of hosts that can send data to your organization. If you exceed this limit, Infrastructure Monitoring
  drops datapoints from newly-added hosts but keeps datapoints for existing hosts.
* `sf.org.limit.containers`: Maximum number of Docker containers that can send data to your organization. If you exceed this limit, Infrastructure Monitoring
  drops datapoints from newly-added containers but keeps datapoints for existing containers.
* `sf.org.limit.customMetricTimeSeries`: Maximum number of custom MTS you can create in your organization. Custom MTS use a metric defined by
  you, rather than a metric defined by an integration. If you exceed this limit, Infrastructure Monitoring stops creating new custom MTS.

## Metrics

{{ macros.metric_list(metrics) }}<commit_msg>DOCS-1615: limit metrics terminology fix (#912)<commit_after>{% import "macros.jinja" as macros %}

{% if target == "docs" -%}
# Splunk Infrastructure Monitoring Organization Metrics


- [Description](#description)
- [Usage](#usage)
- [Metrics](#metrics)
{%- endif %}

## DESCRIPTION

Splunk Infrastructure Monitoring provides the following types of metrics that measure your usage:

* Ingest metrics: Measure the data you're sending to Infrastructure Monitoring, such as the number of datapoints you've sent
* App usage metrics: Measure your use of application features, such as the number of dashboards in your organization
* Integration metrics: Measure the use cloud services integrated with your organization, such as the number of calls to the AWS CloudWatch API
* Metrics that measure your use of resources for which you can specify limits, such as the number of custom MTS you've created

You're not charged for these metrics, and they do not count against any limits.


## USAGE

If you're an admin, you can view some of these metrics in built-in charts on the Organization Overview page.
Anyone can display these metrics in custom charts.

### Metrics for values by token

In some cases, Infrastructure Monitoring has two similar metrics:

* One metric, such as `sf.org.numAddDatapointCalls`, represents the total across your entire organization.
* The similar metric, `sf.org.numAddDatapointCallsByToken` represents the total for each unique access token you use.

The sum of all the by token metric values for a measurement might be less than the total value metric value. For
example, the sum, of all `sf.org.numAddDatapointCallsByToken` values might be less than the value of
`sf.org.numAddDatapointCalls`. The sums differ because Infrastructure Monitoring doesn't use a token to retrieve
data from cloud services you've integrated. Infrastructure Monitoring counts the datapoint calls for the integrated
services, but it doesn't have a way to count the calls for any specific token.

This difference in values applies to AWS CloudWatch, GCP StackDriver, AppDynamics, and New Relic integrations.

### Metrics with values for each metric type

Some metrics have a value for each metric type (counter, cumulative counter, or gauge), so you have three MTS per metric.
Each MTS has a dimension named `category` with a value of `COUNTER`, `CUMULATIVE_COUNTER`, or `GAUGE`. Because you can have
multiple MTS for these metrics, you need to use the `sum()` SignalFlow function to see the total value.

For example, you might receive three MTS for `sf.org.numMetricTimeSeriesCreated`, one for the number of MTS that are counters, another for the number of MTS that are cumulative counters, and a third for the number of MTS that are gauges.

Also, you can filter by a single value of `category`, such as `GAUGE`, to see only the metrics of that type.

### A metric that counts stopped detectors

The metric `sf.org.numDetectorsAborted` monitors the number of detectors that Infrastructure Monitoring
stopped because the detector reached a resource limit. In most cases, the detector exceeds the limit of 250K MTS.
MTS exceeds 250K. This condition also generates the event
`sf.org.abortedDetectors`, which records details including the detector ID, the reason it stopped, and
the value or limit of MTS or datapoints, whichever caused the detector to stop.

To learn more, see [View Additional Data With Events](https://docs.signalfx.com/en/latest/detect-alert/events-intro.html).

### Metrics that track system limits

Three metrics track limits that Infrastructure Monitoring enforces for all organizations:

* `sf.org.limit.hosts`: Maximum number of hosts that can send data to your organization. If you exceed this limit, Infrastructure Monitoring
  drops datapoints from newly-added hosts but keeps datapoints for existing hosts.
* `sf.org.limit.containers`: Maximum number of containers that can send data to your organization. If you exceed this limit, Infrastructure Monitoring
  drops datapoints from newly-added containers but keeps datapoints for existing containers.
* `sf.org.limit.customMetricTimeSeries`: Maximum number of custom MTS you can create in your organization. Custom MTS use a metric defined by
  you, rather than a metric defined by an integration. If you exceed this limit, Infrastructure Monitoring stops creating new custom MTS.

## Metrics

{{ macros.metric_list(metrics) }}
{'fraction_non_alphanumeric': 0.05396858859491936, 'fraction_numerical': 0.0020027405923895856, 'mean_word_length': 4.900497512437811, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '393158', 'n_tokens_mistral': 2468, 'n_tokens_neox': 2282, 'n_words': 1322}