You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Sep 2, 2025. It is now read-only.
Infrastructure Monitoring collects metric time series (MTS) which are classified into different categories depending on the type of subscription you have.
22
22
23
-
* In MTS-based subscriptions, all MTS count towards custom metrics usage.
24
-
* In host-based plans, the following categories apply:
23
+
.. note:: Each histogram data point is billed as 8 MTS. Learn more about metric categories in :ref:`metrics-category`.
* MTS from host and container metrics and bundled metrics are covered as part of the subscription and not charged separately
36
+
* MTS from custom metrics are subject to the entitlements (200 MTS per host for Enterprise plan and 100 MTS per host for Standard plan)
37
+
* Additional MTS from custom metrics are charged separately per MTS
38
+
39
+
See the table for more details:
25
40
26
41
.. list-table::
27
42
:header-rows: 1
@@ -32,23 +47,18 @@ Infrastructure Monitoring collects metric time series (MTS) which are classified
32
47
- :strong:`Description`
33
48
34
49
* - Host and container metrics
35
-
- * Default metrics sent by the Splunk Distribution of OpenTelemetry Collector or through Infrastructure Monitoring public cloud integrations for hosts, containers, and the services running on them.
50
+
- * Default metrics sent by the Splunk Distribution of OpenTelemetry Collector or through Infrastructure Monitoring public cloud integrations for hosts, containers, and the services running on them.
51
+
* Metrics retrieved out-of-the-box by Collector receivers also fall in this category. These metrics are listed in the :ref:`otel-components-receivers` documentation.
36
52
37
53
* - Bundled metrics
38
-
- * Additional metrics sent through Infrastructure Monitoring public cloud integrations that are not attributed to specific hosts or containers.
39
-
* They are included as part of a host-based subscription, so you're not charged for them.
54
+
- * Additional metrics sent through Infrastructure Monitoring public cloud integrations that are not attributed to specific hosts or containers.
40
55
41
56
* - Custom metrics
42
57
- * Metrics reported to Infrastructure Monitoring outside of the host, container, or bundled metrics.
43
58
* Custom metrics are often used for application monitoring, such as counting the number of Splunk Infrastructure Monitoring API calls or measuring the duration of the API requests.
44
59
* You can also configure the Splunk Distribution of OpenTelemetry Collector to send custom metrics (such as system or service metrics) outside of its default set of metrics.
45
60
* Your Infrastructure Monitoring subscription lets you send a certain number of custom metrics. If you exceed this number your organization might be overcharged.
46
61
47
-
In host-based subscriptions, MTS from host and container metrics and bundled metrics are covered as part of the subscription and not charged separately. MTS from custom metrics are subject to the entitlements (200 MTS per host for Enterprise plan and 100 MTS per host for Standard plan). Additional MTS from custom metrics will be charged separately per MTS.
48
-
49
-
.. note:: Each histogram data point is billed as 8 MTS. Learn more about metric categories in :ref:`metrics-category`.
Copy file name to clipboardExpand all lines: apm/apm-spans-traces/apm-errors.rst
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -29,7 +29,7 @@ See the Span Status section of the OpenTelemetry Transformation to non-OTLP Form
29
29
How OpenTelemetry handles HTTP status codes
30
30
----------------------------------------------
31
31
32
-
The following table provides an overview of how HTTP status codes are used to set the ``span.status`` field, and subsequently ``otel.status_code``, in OpenTelemetry instrumentation in accordance with OpenTelemetry semantic conventions. To learn more, see the OpenTelemetry semantic conventions for HTTP spans on GitHub :new-page:`https://github.com/open-telemetry/semantic-conventions/blob/main/model/trace/http.yaml`.
32
+
The following table provides an overview of how HTTP status codes are used to set the ``span.status`` field, and subsequently ``otel.status_code``, in OpenTelemetry instrumentation in accordance with OpenTelemetry semantic conventions. To learn more, see the OpenTelemetry semantic conventions for HTTP spans on GitHub :new-page:`https://github.com/open-telemetry/semantic-conventions/blob/main/model/http/spans.yaml`.
33
33
34
34
.. list-table::
35
35
:header-rows: 1
@@ -132,7 +132,7 @@ To determine if a gRPC span counts towards the error rate for a service, Splunk
132
132
- unset
133
133
- ERROR
134
134
135
-
See the OpenTelemetry specification for information on the handling of gRPC status codes on GitHub :new-page:`https://github.com/open-telemetry/semantic-conventions/blob/main/model/trace/rpc.yaml`.
135
+
See the OpenTelemetry specification for information on the handling of gRPC status codes on GitHub :new-page:`https://github.com/open-telemetry/semantic-conventions/blob/main/model/rpc/spans.yaml`.
0 commit comments