diff --git a/_includes/activate-deactivate-native-metrics.rst b/_includes/activate-deactivate-native-metrics.rst index efc227efa..77e7be44e 100644 --- a/_includes/activate-deactivate-native-metrics.rst +++ b/_includes/activate-deactivate-native-metrics.rst @@ -26,3 +26,11 @@ The following is an example of host metrics receiver configuration with activate enabled: true .. note:: Deactivated metrics aren't sent to Splunk Observability Cloud. + +Billing +--------------------------------------------- + +* If you're in a MTS-based subscription, all metrics count towards metrics usage. +* If you're in a host-based plan, metrics listed as active (Active: Yes) on this document are considered default and are included free of charge. + +Learn more at :ref:`monitor-imm-billing-usage`. \ No newline at end of file diff --git a/_static/signalfx-alabaster.css b/_static/signalfx-alabaster.css index fa61b636c..2f01ca4d2 100644 --- a/_static/signalfx-alabaster.css +++ b/_static/signalfx-alabaster.css @@ -948,7 +948,7 @@ a.image-reference:hover margin-top: -35px; } -#welcome .newparawithicon [class^="icon-"], #welcome .newparawithicon [class*=" icon-"], #get-started-with-splunk-observability-cloud .newparawithicon [class^="icon-"], #get-started-with-splunk-observability-cloud .newparawithicon [class*=" icon-"]{ +#welcome .newparawithicon [class^="icon-"], #welcome .newparawithicon [class*="icon-"], #get-started-with-splunk-observability-cloud .newparawithicon [class^="icon-"], #get-started-with-splunk-observability-cloud .newparawithicon [class*="icon-"]{ font-size: 28px; position: absolute; overflow: hidden; diff --git a/admin/subscription-usage/monitor-imm-billing-usage.rst b/admin/subscription-usage/monitor-imm-billing-usage.rst index 2e8377914..e60078008 100644 --- a/admin/subscription-usage/monitor-imm-billing-usage.rst +++ b/admin/subscription-usage/monitor-imm-billing-usage.rst @@ -15,13 +15,28 @@ This topic describes general aspects of your usage and consumption. For more det .. _about-custom: -Metrics in Infrastructure +Metric billing in Infrastructure ================================================== Infrastructure Monitoring collects metric time series (MTS) which are classified into different categories depending on the type of subscription you have. -* In MTS-based subscriptions, all MTS count towards custom metrics usage. -* In host-based plans, the following categories apply: +.. note:: Each histogram data point is billed as 8 MTS. Learn more about metric categories in :ref:`metrics-category`. + +MTS-based subscriptions +------------------------------------------------------------------------------------- + +In MTS-based subscriptions, all MTS are considered custom and charged. + +Host-based subscriptions +------------------------------------------------------------------------------------- + +In host-based plans, the following applies: + +* 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 are charged separately per MTS + +See the table for more details: .. list-table:: :header-rows: 1 @@ -32,11 +47,11 @@ Infrastructure Monitoring collects metric time series (MTS) which are classified - :strong:`Description` * - Host and container metrics - - * 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. + - * 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. + * 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. * - Bundled metrics - - * Additional metrics sent through Infrastructure Monitoring public cloud integrations that are not attributed to specific hosts or containers. - * They are included as part of a host-based subscription, so you're not charged for them. + - * Additional metrics sent through Infrastructure Monitoring public cloud integrations that are not attributed to specific hosts or containers. * - Custom metrics - * Metrics reported to Infrastructure Monitoring outside of the host, container, or bundled metrics. @@ -44,11 +59,6 @@ Infrastructure Monitoring collects metric time series (MTS) which are classified * 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. * Your Infrastructure Monitoring subscription lets you send a certain number of custom metrics. If you exceed this number your organization might be overcharged. -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. - -.. note:: Each histogram data point is billed as 8 MTS. Learn more about metric categories in :ref:`metrics-category`. - - .. _about-metric-res: Metric resolution diff --git a/apm/apm-spans-traces/apm-errors.rst b/apm/apm-spans-traces/apm-errors.rst index e13cfaeb9..3a8e764cb 100644 --- a/apm/apm-spans-traces/apm-errors.rst +++ b/apm/apm-spans-traces/apm-errors.rst @@ -29,7 +29,7 @@ See the Span Status section of the OpenTelemetry Transformation to non-OTLP Form How OpenTelemetry handles HTTP status codes ---------------------------------------------- -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`. +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`. .. list-table:: :header-rows: 1 @@ -132,7 +132,7 @@ To determine if a gRPC span counts towards the error rate for a service, Splunk - unset - ERROR -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`. +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`. .. _metricset-errors: