From 74da7a059c8fb0b5152ff3ab464c5c6e9813da5c Mon Sep 17 00:00:00 2001 From: ada Date: Wed, 9 Apr 2025 16:10:41 -0700 Subject: [PATCH 01/24] [O11YDOCS-7152] Update downtime config docs to clarify recurring edit restrictions --- synthetics/test-config/syn-downtimes.rst | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/synthetics/test-config/syn-downtimes.rst b/synthetics/test-config/syn-downtimes.rst index 28f20d272..58c49b689 100644 --- a/synthetics/test-config/syn-downtimes.rst +++ b/synthetics/test-config/syn-downtimes.rst @@ -43,6 +43,15 @@ How to schedule a downtime configuration: When a recurring downtime configuration is active, you can't edit, delete, or extend it, but you can end it immediately. When a non-recurring downtime configuration is active, you can't edit or delete it, but you can extend its duration or end it immediately. +.. comment: Update the documentation to state: + + After the first run of a recurring downtime config, it cannot be edited or extended, regardless of its current status. + + Only deletion and manual ending are allowed after the first execution. + + UI may still show it as “Scheduled” but it is functionally locked. + + Preview the downtime schedule ---------------------------------------- From ad41e98fcdf35f507365f97580398a314581d3d3 Mon Sep 17 00:00:00 2001 From: ada Date: Wed, 9 Apr 2025 16:18:38 -0700 Subject: [PATCH 02/24] Updated wording --- synthetics/test-config/syn-downtimes.rst | 11 ++--------- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/synthetics/test-config/syn-downtimes.rst b/synthetics/test-config/syn-downtimes.rst index 58c49b689..059fb53fa 100644 --- a/synthetics/test-config/syn-downtimes.rst +++ b/synthetics/test-config/syn-downtimes.rst @@ -41,16 +41,9 @@ How to schedule a downtime configuration: #. Select :guilabel:`Create`. -When a recurring downtime configuration is active, you can't edit, delete, or extend it, but you can end it immediately. When a non-recurring downtime configuration is active, you can't edit or delete it, but you can extend its duration or end it immediately. - -.. comment: Update the documentation to state: - - After the first run of a recurring downtime config, it cannot be edited or extended, regardless of its current status. - - Only deletion and manual ending are allowed after the first execution. - - UI may still show it as “Scheduled” but it is functionally locked. +When a recurring downtime configuration is active, you can't edit, delete, or extend it, but you can end it immediately. After the first run of a recurring downtime configuration, you can't edit or extend it, regardless of its current status; you can only delete it or stop it manually. Its status may still be displayed as :guilabel:`Scheduled`, but it's functionally locked. +When a non-recurring downtime configuration is active, you can't edit or delete it, but you can extend its duration or end it immediately. Preview the downtime schedule From 97d255d1a1926d4025062b0c4c1f2c942c848663 Mon Sep 17 00:00:00 2001 From: Joe Catera Date: Wed, 16 Apr 2025 10:30:14 -0700 Subject: [PATCH 03/24] Added a note that cgroup metrics exposed by cAdvisor cannot be collected by the Splunk OTel collector. --- gdi/monitors-monitoring/cadvisor.rst | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/gdi/monitors-monitoring/cadvisor.rst b/gdi/monitors-monitoring/cadvisor.rst index a5b0b587d..a81a23a7e 100644 --- a/gdi/monitors-monitoring/cadvisor.rst +++ b/gdi/monitors-monitoring/cadvisor.rst @@ -16,8 +16,11 @@ If you are using Kubernetes, consider the expose cAdvisor on a network port, even though they are running it within Kubelet. +.. :note:: The Splunk Distribution of OpenTelemetry Collector cannot collect specific cgroup metrics exposed by cAdvisor, such as ``container_cpu_cfs_*`` + in managed environments such as Amazon EKS, and the supported `kubeletstats` receiver does not expose these metrics by default. + If you are running containers with Docker, retrieved metrics might -overlap with ``docker-container-stats``\ '. Consider not enabling the +overlap with ``docker-container-stats``. Consider not enabling the Docker monitor in a Kubernetes environment, or else use filtering to allow only certain metrics. This will cause the built-in Docker dashboards to be blank, but container metrics will be available on the From 5e427d5768b4d7d70c1c8bbe59c35ece3ff79c23 Mon Sep 17 00:00:00 2001 From: Joe Catera Date: Wed, 16 Apr 2025 10:44:25 -0700 Subject: [PATCH 04/24] Rewrote the note to make it easier to understand. --- gdi/monitors-monitoring/cadvisor.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/gdi/monitors-monitoring/cadvisor.rst b/gdi/monitors-monitoring/cadvisor.rst index a81a23a7e..2b1dbd3f4 100644 --- a/gdi/monitors-monitoring/cadvisor.rst +++ b/gdi/monitors-monitoring/cadvisor.rst @@ -16,8 +16,9 @@ If you are using Kubernetes, consider the expose cAdvisor on a network port, even though they are running it within Kubelet. -.. :note:: The Splunk Distribution of OpenTelemetry Collector cannot collect specific cgroup metrics exposed by cAdvisor, such as ``container_cpu_cfs_*`` - in managed environments such as Amazon EKS, and the supported `kubeletstats` receiver does not expose these metrics by default. +.. :note:: The Splunk Distribution of OpenTelemetry Collector has limitations in managed environments like Amazon EKS. + For example, the collector cannot collect specific cgroup metrics exposed by cAdvisor, such as ``container_cpu_cfs_*``. + The ``kubeletstats`` receiver also does not expose these metrics by default. If you are running containers with Docker, retrieved metrics might overlap with ``docker-container-stats``. Consider not enabling the From a12f07f147e54f766da367cb41774caddc33d495 Mon Sep 17 00:00:00 2001 From: Joe Catera Date: Wed, 16 Apr 2025 10:53:03 -0700 Subject: [PATCH 05/24] Made a copy edit. --- gdi/monitors-monitoring/cadvisor.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gdi/monitors-monitoring/cadvisor.rst b/gdi/monitors-monitoring/cadvisor.rst index 2b1dbd3f4..27289c915 100644 --- a/gdi/monitors-monitoring/cadvisor.rst +++ b/gdi/monitors-monitoring/cadvisor.rst @@ -16,7 +16,7 @@ If you are using Kubernetes, consider the expose cAdvisor on a network port, even though they are running it within Kubelet. -.. :note:: The Splunk Distribution of OpenTelemetry Collector has limitations in managed environments like Amazon EKS. +.. :note:: The Splunk Distribution of OpenTelemetry Collector has limitations in managed environments such as Amazon EKS. For example, the collector cannot collect specific cgroup metrics exposed by cAdvisor, such as ``container_cpu_cfs_*``. The ``kubeletstats`` receiver also does not expose these metrics by default. From e53526b4922542f4bccaa779c6e0a0c4a3c71f69 Mon Sep 17 00:00:00 2001 From: Joe Catera Date: Wed, 16 Apr 2025 11:43:55 -0700 Subject: [PATCH 06/24] Fixing note syntax. --- gdi/monitors-monitoring/cadvisor.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gdi/monitors-monitoring/cadvisor.rst b/gdi/monitors-monitoring/cadvisor.rst index 27289c915..b5a06cc5c 100644 --- a/gdi/monitors-monitoring/cadvisor.rst +++ b/gdi/monitors-monitoring/cadvisor.rst @@ -8,7 +8,7 @@ cAdvisor The Splunk Distribution of OpenTelemetry Collector uses the Smart Agent receiver with the cAdvisor monitor type to pull metrics directly from cAdvisor. By -default, it runs on port 4194, but it can be configured to any other +default, it runs on port 4193, but it can be configured to any other port. If you are using Kubernetes, consider the @@ -16,7 +16,7 @@ If you are using Kubernetes, consider the expose cAdvisor on a network port, even though they are running it within Kubelet. -.. :note:: The Splunk Distribution of OpenTelemetry Collector has limitations in managed environments such as Amazon EKS. +.. note:: The Splunk Distribution of OpenTelemetry Collector has limitations in managed environments such as Amazon EKS. For example, the collector cannot collect specific cgroup metrics exposed by cAdvisor, such as ``container_cpu_cfs_*``. The ``kubeletstats`` receiver also does not expose these metrics by default. From 0027285ea73f116af448d8e9e9486d82492a6632 Mon Sep 17 00:00:00 2001 From: Joe Catera Date: Fri, 18 Apr 2025 16:28:34 -0700 Subject: [PATCH 07/24] Updated the cAdvisor doc based on feedback from engineering. --- gdi/monitors-monitoring/cadvisor.rst | 93 +++++++++++++++++++++------- 1 file changed, 69 insertions(+), 24 deletions(-) diff --git a/gdi/monitors-monitoring/cadvisor.rst b/gdi/monitors-monitoring/cadvisor.rst index b5a06cc5c..201f418b6 100644 --- a/gdi/monitors-monitoring/cadvisor.rst +++ b/gdi/monitors-monitoring/cadvisor.rst @@ -9,16 +9,28 @@ cAdvisor The Splunk Distribution of OpenTelemetry Collector uses the Smart Agent receiver with the cAdvisor monitor type to pull metrics directly from cAdvisor. By default, it runs on port 4193, but it can be configured to any other -port. +port. + +This integration is available on Kubernetes, Linux, and Windows. + +cAdvisor with Kubernetes +------------------------ If you are using Kubernetes, consider the :ref:`kubelet-stats-receiver` because many Kubernetes nodes do not expose cAdvisor on a network port, even though they are running it within Kubelet. -.. note:: The Splunk Distribution of OpenTelemetry Collector has limitations in managed environments such as Amazon EKS. - For example, the collector cannot collect specific cgroup metrics exposed by cAdvisor, such as ``container_cpu_cfs_*``. - The ``kubeletstats`` receiver also does not expose these metrics by default. +If you are using Kubernetes, consider the Kubelet stats receiver +because many Kubernetes nodes do not expose cAdvisor on a network port, +even though they are running it within Kubelet. Because the Splunk Distribution +of OpenTelemetry Collector has limitations in managed environments such as Amazon EKS, +you can use a :ref:`Prometheus receiver ` to collect specific +cgroup metrics exposed by cAdvisor, such as ``container_cpu_cfs_*``. +The kubeletstats receiver also does not expose these metrics by default. + +cAdvisor with Docker +--------------------- If you are running containers with Docker, retrieved metrics might overlap with ``docker-container-stats``. Consider not enabling the @@ -27,13 +39,10 @@ allow only certain metrics. This will cause the built-in Docker dashboards to be blank, but container metrics will be available on the Kubernetes dashboards instead. -This integration is available on Kubernetes, Linux, and Windows. Benefits -------- - - .. raw:: html
@@ -45,13 +54,9 @@ Benefits
- - Installation ------------ - - .. raw:: html
@@ -63,13 +68,9 @@ Installation
- - Configuration ------------- - - .. raw:: html
@@ -81,10 +82,11 @@ Configuration
+Examples +^^^^^^^^ - -Example -~~~~~~~ +Activate integration +#################### To activate this integration, add the following to your Collector configuration: @@ -106,8 +108,55 @@ section of your configuration file: metrics: receivers: [smartagent/cadvisor] +.. _prometheus_receiver: + +Prometheus receiver +################### + +.. code:: yaml + + receivers: + prometheus/cadvisor: + config: + scrape_configs: + - job_name: 'kubernetes-nodes-cadvisor' + scheme: https + bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token + kubernetes_sd_configs: + - role: node + relabel_configs: + - target_label: __address__ + replacement: kubernetes.default.svc:443 + - source_labels: [__meta_kubernetes_node_name] + regex: (.+) + target_label: __metrics_path__ + replacement: /api/v1/nodes/$$1/proxy/metrics/cadvisor + metric_relabel_configs: + - source_labels: [__name__] + regex: 'container_cpu_cfs.*' + action: keep + - source_labels: [pod] + target_label: k8s.pod.name + - source_labels: [namespace] + target_label: k8s.namespace.name + - source_labels: [container] + target_label: k8s.container.name + - action: labeldrop + regex: 'pod|namespace|name|id|container' + service: + pipelines: + metrics/scrapers: + exporters: + - signalfx + processors: + - memory_limiter + - batch + - resource/add_environment + receivers: + - prometheus/cadvisor + Configuration settings -~~~~~~~~~~~~~~~~~~~~~~ +^^^^^^^^^^^^^^^^^^^^^^ The following table shows the configuration options for this receiver: @@ -139,9 +188,7 @@ The following metrics are available for this integration:
Notes -~~~~~ - - +^^^^^ .. raw:: html @@ -159,8 +206,6 @@ Notes Troubleshooting --------------- - - .. raw:: html
From 2f002013295b70e91638de74d8d846ccde37d2cd Mon Sep 17 00:00:00 2001 From: Joe Catera Date: Fri, 18 Apr 2025 18:19:07 -0700 Subject: [PATCH 08/24] Removed the step to set a time for when Splunk Observability Cloud sends an expiration alert as it's not present in the UI. --- admin/authentication/authentication-tokens/org-tokens.rst | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/admin/authentication/authentication-tokens/org-tokens.rst b/admin/authentication/authentication-tokens/org-tokens.rst index dbc952968..44d589bf0 100644 --- a/admin/authentication/authentication-tokens/org-tokens.rst +++ b/admin/authentication/authentication-tokens/org-tokens.rst @@ -201,8 +201,6 @@ To finish creating the token, select an expiration date for the token. * :menuselection:`Only admins can receive alert`: Only admins receive an alert when the token is close to its expiration date. * :menuselection:`Admins and users or teams with token permissions can receive alert`: Admins and any users with token permissions receive an alert when the token is close to its expiration date. - -#. (Optional) Set a time for when Splunk Observability Cloud sends an expiration alert. For example, a value of 7 days means Splunk Observability Cloud will send an alert 7 days before the token expires. #. Select :guilabel:`Create` to finish creating the new token. .. _access-token-rotate: @@ -299,4 +297,4 @@ To change limits for your access tokens, including host and container limits, fo #. Select the token actions menu (|verticaldots|), and select :guilabel:`Manage limits`. #. In the :guilabel:`Manage limits` menu, add the new token limits. -To learn more about token limits, see :ref:`admin-manage-usage`. \ No newline at end of file +To learn more about token limits, see :ref:`admin-manage-usage`. From 480a931ce4ff43a4cf298d0fe6f147e6c7d840f7 Mon Sep 17 00:00:00 2001 From: ada Date: Wed, 23 Apr 2025 18:17:25 -0700 Subject: [PATCH 09/24] Updated based on SME input. --- synthetics/test-config/syn-downtimes.rst | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/synthetics/test-config/syn-downtimes.rst b/synthetics/test-config/syn-downtimes.rst index 059fb53fa..8552e3cdd 100644 --- a/synthetics/test-config/syn-downtimes.rst +++ b/synthetics/test-config/syn-downtimes.rst @@ -41,13 +41,25 @@ How to schedule a downtime configuration: #. Select :guilabel:`Create`. -When a recurring downtime configuration is active, you can't edit, delete, or extend it, but you can end it immediately. After the first run of a recurring downtime configuration, you can't edit or extend it, regardless of its current status; you can only delete it or stop it manually. Its status may still be displayed as :guilabel:`Scheduled`, but it's functionally locked. +Modify a downtime configuration +------------------------------------------------------------ -When a non-recurring downtime configuration is active, you can't edit or delete it, but you can extend its duration or end it immediately. +* Before a downtime configuration has run: + + * If it's non-recurring you can edit it, and if it's still in "scheduled" state you can delete it. + * If it's recurring you can edit it, but you can only delete it before its first run. + + +* While a downtime configuration is active: + + * If it's non-recurring you can't edit or delete it, but you can extend it or end it immediately. + * If it's recurring you can't edit, delete, or extend it, but you can end it immediately. + +* After the first run of a recurring downtime configuration, you can't edit or extend it, regardless of its current status; you can only delete it or stop it manually. To delete it, select the :guilabel:`Delete` action from the vertical dot menu (|verticaldots|). Its status may still be displayed as :guilabel:`Scheduled`, but it's functionally locked. Preview the downtime schedule ----------------------------------------- +------------------------------------------------------------ If you selected a value other than :guilabel:`Does not repeat` in the :guilabel:`Recurrence` menu, the :guilabel:`Create a downtime configuration` form displays a preview of the first ten downtime configurations. From e14d8b638dace50b00fb1c01695454e4a60eb993 Mon Sep 17 00:00:00 2001 From: Joe Catera Date: Thu, 24 Apr 2025 14:25:41 -0700 Subject: [PATCH 10/24] Applied some of the suggestions by Josh and updated the code example. --- gdi/monitors-monitoring/cadvisor.rst | 103 +++++++++++++++------------ 1 file changed, 59 insertions(+), 44 deletions(-) diff --git a/gdi/monitors-monitoring/cadvisor.rst b/gdi/monitors-monitoring/cadvisor.rst index 201f418b6..88a183d89 100644 --- a/gdi/monitors-monitoring/cadvisor.rst +++ b/gdi/monitors-monitoring/cadvisor.rst @@ -23,11 +23,21 @@ within Kubelet. If you are using Kubernetes, consider the Kubelet stats receiver because many Kubernetes nodes do not expose cAdvisor on a network port, -even though they are running it within Kubelet. Because the Splunk Distribution -of OpenTelemetry Collector has limitations in managed environments such as Amazon EKS, -you can use a :ref:`Prometheus receiver ` to collect specific -cgroup metrics exposed by cAdvisor, such as ``container_cpu_cfs_*``. -The kubeletstats receiver also does not expose these metrics by default. +even though they are running it within Kubelet. + + +In some managed Kubernetes environments, such as Amazon EKS, you cannot +directly access cAdvisor metrics due to the cluster provider's design +choices to enhance security and control. Instead, when exposed through +the Kubernetes proxy metric server, you can access these metrics, but a +specific configuration is required to collect them. For example, in +Amazon EKS, the kubeletstats receiver cannot directly collect cAdvisor metrics. + +To address this limitation, you are recommended to use the +:ref:`Prometheus receiver ` to scrape +metrics from the proxy metric server. This constraint applies to +managed environments and is not a restriction of the Splunk Distribution of +OpenTelemetry Collector. cAdvisor with Docker --------------------- @@ -113,47 +123,52 @@ section of your configuration file: Prometheus receiver ################### +The following example shows how to configure a Prometheus receiver +to scrape cAdvisor metrics securely from Kubernetes nodes using TLS and authorization +credentials. + .. code:: yaml - receivers: - prometheus/cadvisor: - config: - scrape_configs: - - job_name: 'kubernetes-nodes-cadvisor' - scheme: https - bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token - kubernetes_sd_configs: - - role: node - relabel_configs: - - target_label: __address__ - replacement: kubernetes.default.svc:443 - - source_labels: [__meta_kubernetes_node_name] - regex: (.+) - target_label: __metrics_path__ - replacement: /api/v1/nodes/$$1/proxy/metrics/cadvisor - metric_relabel_configs: - - source_labels: [__name__] - regex: 'container_cpu_cfs.*' - action: keep - - source_labels: [pod] - target_label: k8s.pod.name - - source_labels: [namespace] - target_label: k8s.namespace.name - - source_labels: [container] - target_label: k8s.container.name - - action: labeldrop - regex: 'pod|namespace|name|id|container' - service: - pipelines: - metrics/scrapers: - exporters: - - signalfx - processors: - - memory_limiter - - batch - - resource/add_environment - receivers: - - prometheus/cadvisor + agent: + config: + receivers: + prometheus/cadvisor: + config: + scrape_configs: + - job_name: cadvisor + tls_config: + ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt + authorization: + credentials_file: /var/run/secrets/kubernetes.io/serviceaccount/token + scheme: https + kubernetes_sd_configs: + - role: node + relabel_configs: + - replacement: 'kubernetes.default.svc.cluster.local:443' + target_label: __address__ + - regex: (.+) + replacement: '/api/v1/nodes/$${1}/proxy/metrics/cadvisor' + source_labels: + - __meta_kubernetes_node_name + target_label: __metrics_path__ + service: + pipelines: + metrics: + exporters: + - signalfx + processors: + - memory_limiter + - batch + - resourcedetection + - resource + receivers: + - hostmetrics + - kubeletstats + - otlp + - prometheus/cadvisor + - receiver_creator + - signalfx + Configuration settings ^^^^^^^^^^^^^^^^^^^^^^ From 878df57332abc5a8bafe2ea258dcf645296d250b Mon Sep 17 00:00:00 2001 From: Joe Catera Date: Thu, 24 Apr 2025 15:44:50 -0700 Subject: [PATCH 11/24] Made another edit. --- gdi/monitors-monitoring/cadvisor.rst | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/gdi/monitors-monitoring/cadvisor.rst b/gdi/monitors-monitoring/cadvisor.rst index 88a183d89..3422a576c 100644 --- a/gdi/monitors-monitoring/cadvisor.rst +++ b/gdi/monitors-monitoring/cadvisor.rst @@ -25,13 +25,12 @@ If you are using Kubernetes, consider the Kubelet stats receiver because many Kubernetes nodes do not expose cAdvisor on a network port, even though they are running it within Kubelet. - In some managed Kubernetes environments, such as Amazon EKS, you cannot directly access cAdvisor metrics due to the cluster provider's design -choices to enhance security and control. Instead, when exposed through -the Kubernetes proxy metric server, you can access these metrics, but a -specific configuration is required to collect them. For example, in -Amazon EKS, the kubeletstats receiver cannot directly collect cAdvisor metrics. +choices to enhance security and control. Instead, these metrics are +exposed through the Kubernetes proxy metric server and require a specific +configuration to collect them. For example, in Amazon EKS, the kubeletstats +receiver cannot directly collect cAdvisor metrics. To address this limitation, you are recommended to use the :ref:`Prometheus receiver ` to scrape From 84c5b6585f6d69e4bef1b80cc1a286a9530aa3a2 Mon Sep 17 00:00:00 2001 From: Joe Catera Date: Thu, 24 Apr 2025 16:16:18 -0700 Subject: [PATCH 12/24] Made another edit. --- gdi/monitors-monitoring/cadvisor.rst | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/gdi/monitors-monitoring/cadvisor.rst b/gdi/monitors-monitoring/cadvisor.rst index 3422a576c..91df47047 100644 --- a/gdi/monitors-monitoring/cadvisor.rst +++ b/gdi/monitors-monitoring/cadvisor.rst @@ -27,16 +27,15 @@ even though they are running it within Kubelet. In some managed Kubernetes environments, such as Amazon EKS, you cannot directly access cAdvisor metrics due to the cluster provider's design -choices to enhance security and control. Instead, these metrics are -exposed through the Kubernetes proxy metric server and require a specific -configuration to collect them. For example, in Amazon EKS, the kubeletstats -receiver cannot directly collect cAdvisor metrics. - -To address this limitation, you are recommended to use the -:ref:`Prometheus receiver ` to scrape -metrics from the proxy metric server. This constraint applies to -managed environments and is not a restriction of the Splunk Distribution of -OpenTelemetry Collector. +choices to enhance security and control. For example, in Amazon EKS, +the ``kubeletstats`` receiver cannot directly collect cAdvisor metrics. +Instead, these metrics are exposed through the Kubernetes proxy metric +server and require a specific configuration to collect them. +Thus, you are recommended to use the :ref:`Prometheus receiver ` +to scrape metrics from the proxy metric server. This constraint is +specific to managed environments and is not a restriction of the Splunk +Distribution of OpenTelemetry Collector. + cAdvisor with Docker --------------------- From a399da9b174ad406107c7a2623abfdec791fa8e7 Mon Sep 17 00:00:00 2001 From: Joe Catera Date: Thu, 24 Apr 2025 17:33:27 -0700 Subject: [PATCH 13/24] Made another edit. --- gdi/monitors-monitoring/cadvisor.rst | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/gdi/monitors-monitoring/cadvisor.rst b/gdi/monitors-monitoring/cadvisor.rst index 91df47047..d32351a57 100644 --- a/gdi/monitors-monitoring/cadvisor.rst +++ b/gdi/monitors-monitoring/cadvisor.rst @@ -29,12 +29,13 @@ In some managed Kubernetes environments, such as Amazon EKS, you cannot directly access cAdvisor metrics due to the cluster provider's design choices to enhance security and control. For example, in Amazon EKS, the ``kubeletstats`` receiver cannot directly collect cAdvisor metrics. -Instead, these metrics are exposed through the Kubernetes proxy metric -server and require a specific configuration to collect them. -Thus, you are recommended to use the :ref:`Prometheus receiver ` -to scrape metrics from the proxy metric server. This constraint is -specific to managed environments and is not a restriction of the Splunk -Distribution of OpenTelemetry Collector. +This constraint is specific to managed environments and is not a restriction +of the Splunk Distribution of OpenTelemetry Collector. + +You can, however, indirectly collect cAdvisor metrics exposed through +the Kubernetes proxy metric server using a receiver with the required configuration. +We recommend using the :ref:`Prometheus receiver ` +to scrape metrics from the proxy metric server. cAdvisor with Docker From e1dbb520e9b205e5f9498d549cf4c84a760e6ebc Mon Sep 17 00:00:00 2001 From: Joe Catera Date: Thu, 24 Apr 2025 17:34:28 -0700 Subject: [PATCH 14/24] Made another edit. --- gdi/monitors-monitoring/cadvisor.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gdi/monitors-monitoring/cadvisor.rst b/gdi/monitors-monitoring/cadvisor.rst index d32351a57..a863f29e5 100644 --- a/gdi/monitors-monitoring/cadvisor.rst +++ b/gdi/monitors-monitoring/cadvisor.rst @@ -26,8 +26,8 @@ because many Kubernetes nodes do not expose cAdvisor on a network port, even though they are running it within Kubelet. In some managed Kubernetes environments, such as Amazon EKS, you cannot -directly access cAdvisor metrics due to the cluster provider's design -choices to enhance security and control. For example, in Amazon EKS, +directly access cAdvisor metrics due to the cluster provider's +security and control design. For example, in Amazon EKS, the ``kubeletstats`` receiver cannot directly collect cAdvisor metrics. This constraint is specific to managed environments and is not a restriction of the Splunk Distribution of OpenTelemetry Collector. From 866c576cbae592dfabaf71eb1a8d39070a6260ef Mon Sep 17 00:00:00 2001 From: pkopta-splunk Date: Mon, 28 Apr 2025 11:18:08 +0200 Subject: [PATCH 15/24] possition of deactivation information changed --- gdi/get-data-in/application/java/java-otel-requirements.rst | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/gdi/get-data-in/application/java/java-otel-requirements.rst b/gdi/get-data-in/application/java/java-otel-requirements.rst index 395f76862..447629376 100644 --- a/gdi/get-data-in/application/java/java-otel-requirements.rst +++ b/gdi/get-data-in/application/java/java-otel-requirements.rst @@ -45,15 +45,14 @@ Supported libraries and frameworks The Splunk Distribution of OpenTelemetry Java instruments numerous libraries, frameworks, and application servers. +.. note:: To deactivate specific instrumentations, see :ref:`java-instrumentation-issues`. + .. raw:: html
For a complete list of supported libraries and frameworks, see :new-page:`Supported libraries ` in the OpenTelemetry documentation. -.. note:: To deactivate specific instrumentations, see :ref:`java-instrumentation-issues`. - - .. _java-otel-connector-requirement: Install and configure the Splunk Distribution of OpenTelemetry Collector From 8f83e6fdd41471d05058d75a7d62e16de17bc722 Mon Sep 17 00:00:00 2001 From: ada Date: Mon, 28 Apr 2025 08:53:50 -0700 Subject: [PATCH 16/24] Updated based on SME input. --- release-notes/2025-4-rn.rst | 2 +- synthetics/set-up-synthetics/set-up-synthetics.rst | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/release-notes/2025-4-rn.rst b/release-notes/2025-4-rn.rst index 03eedb9fc..d22ca3fa6 100644 --- a/release-notes/2025-4-rn.rst +++ b/release-notes/2025-4-rn.rst @@ -20,7 +20,7 @@ April 22, 2025 release * - New feature or enhancement - Description * - Splunk Synthetic Monitoring audit logs - - Use the Synthetics API to retrieve audit logs. These logs provide a detailed history of any changes made to Synthetics resources, such as tests, downtime configurations, TOTP tokens, private locations, and more. Audit logs enable you to track every change within your environment for regulatory and compliance needs, and to identify the root cause of performance issues or failures. + - Use the Synthetics API to retrieve audit logs. These logs provide a detailed history of any changes made to Synthetics resources, such as tests, downtime configurations, TOTP tokens, private locations, and more. Audit logs enable you to track every change within your environment for regulatory and compliance needs, and to identify the root cause of performance issues or failures. See :new-page:`Synthetics audit API ` to learn more. * - Curated APM teams landing page updates - View your Splunk APM services, dashboards, top alerts, and the team members of every team you are part of from the teams landing page. Preview potential teams by selecting :guilabel:`View all teams` to join teams you're not yet a member of. See :ref:`admin-configure-page` to learn more. * - Guided setup updates for getting GCP data in diff --git a/synthetics/set-up-synthetics/set-up-synthetics.rst b/synthetics/set-up-synthetics/set-up-synthetics.rst index 867923b0e..0e36506df 100644 --- a/synthetics/set-up-synthetics/set-up-synthetics.rst +++ b/synthetics/set-up-synthetics/set-up-synthetics.rst @@ -111,7 +111,7 @@ After you choose which type of test you want to use, follow these steps to set u Get audit logs ============================================================ -Use the Synthetics API to retrieve audit logs. These logs provide a detailed history of any changes made to Synthetics resources, such as tests, downtime configurations, TOTP tokens, private locations, and more. Audit logs enable you to track every change within your environment for regulatory and compliance needs and to identify the root cause of performance issues or failures. +Use the :new-page:`Synthetics audit API ` to retrieve audit logs. These logs provide a detailed history of any changes made to Synthetics resources, such as tests, downtime configurations, TOTP tokens, private locations, and more. Audit logs enable you to track every change within your environment for regulatory and compliance needs and to identify the root cause of performance issues or failures. From 1f151e4fa71601c0afcda19f3f9060cfdc651949 Mon Sep 17 00:00:00 2001 From: ada Date: Tue, 29 Apr 2025 09:56:00 -0700 Subject: [PATCH 17/24] Updated based on SME input. --- synthetics/test-config/syn-downtimes.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/synthetics/test-config/syn-downtimes.rst b/synthetics/test-config/syn-downtimes.rst index 8552e3cdd..5c1fc0194 100644 --- a/synthetics/test-config/syn-downtimes.rst +++ b/synthetics/test-config/syn-downtimes.rst @@ -46,16 +46,16 @@ Modify a downtime configuration * Before a downtime configuration has run: - * If it's non-recurring you can edit it, and if it's still in "scheduled" state you can delete it. - * If it's recurring you can edit it, but you can only delete it before its first run. - + * If it's non-recurring you can edit or delete it. + * If it's recurring you can edit it, but you can only delete it before its first run. Its status may still be displayed as :guilabel:`Scheduled`, but it's functionally locked after the first occurrence. + * To delete a downtime configuration, select the :guilabel:`Delete` action from the vertical dot menu (|verticaldots|). * While a downtime configuration is active: * If it's non-recurring you can't edit or delete it, but you can extend it or end it immediately. * If it's recurring you can't edit, delete, or extend it, but you can end it immediately. -* After the first run of a recurring downtime configuration, you can't edit or extend it, regardless of its current status; you can only delete it or stop it manually. To delete it, select the :guilabel:`Delete` action from the vertical dot menu (|verticaldots|). Its status may still be displayed as :guilabel:`Scheduled`, but it's functionally locked. +* After the first run of a downtime configuration, whether it's recurring or not, you can't delete or edit it. Preview the downtime schedule From 4d239375f232b3de9176bfff0b4f51f284379f70 Mon Sep 17 00:00:00 2001 From: Tracey Carter Date: Tue, 29 Apr 2025 14:48:37 -0700 Subject: [PATCH 18/24] applied docguild feedback - added 2 permissions --- gdi/get-data-in/connect/aws/aws-prereqs.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/gdi/get-data-in/connect/aws/aws-prereqs.rst b/gdi/get-data-in/connect/aws/aws-prereqs.rst index fe8d58ec2..47cf10717 100644 --- a/gdi/get-data-in/connect/aws/aws-prereqs.rst +++ b/gdi/get-data-in/connect/aws/aws-prereqs.rst @@ -218,6 +218,8 @@ On top of the required permissions, you also need to include the specific permis These are these permissions to allow Splunk Observability Cloud to collect AWS tags and properties: +- ``"acm:DescribeCertificate"`` +- ``"acm:ListCertificates"`` - ``"airflow:ListEnvironments"`` - ``"airflow:GetEnvironment"`` - ``"apigateway:GET"`` From abfbb488d01d04d9503daf52bb64cd985080a644 Mon Sep 17 00:00:00 2001 From: ada Date: Tue, 29 Apr 2025 22:12:31 -0700 Subject: [PATCH 19/24] Reordered paragraphs and fixed typos. --- synthetics/test-config/syn-downtimes.rst | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/synthetics/test-config/syn-downtimes.rst b/synthetics/test-config/syn-downtimes.rst index 5c1fc0194..c443e4406 100644 --- a/synthetics/test-config/syn-downtimes.rst +++ b/synthetics/test-config/syn-downtimes.rst @@ -28,8 +28,8 @@ The best practice is to schedule a downtime configuration with a 15 to 30 minute Schedule requirements: -* Downtimes configurations must be at least fifteen minutes long. -* Downtimes configurations can be a maximum of one year in advance and one year in duration. +* Downtime configurations must be at least fifteen minutes long. +* Downtime configurations can be a maximum of one year in advance and one year in duration. How to schedule a downtime configuration: @@ -41,6 +41,12 @@ How to schedule a downtime configuration: #. Select :guilabel:`Create`. +Preview the downtime schedule +------------------------------------------------------------ + +If you selected a value other than :guilabel:`Does not repeat` in the :guilabel:`Recurrence` menu, the :guilabel:`Create a downtime configuration` form displays a preview of the first ten downtime configurations. + + Modify a downtime configuration ------------------------------------------------------------ @@ -58,12 +64,6 @@ Modify a downtime configuration * After the first run of a downtime configuration, whether it's recurring or not, you can't delete or edit it. -Preview the downtime schedule ------------------------------------------------------------- - -If you selected a value other than :guilabel:`Does not repeat` in the :guilabel:`Recurrence` menu, the :guilabel:`Create a downtime configuration` form displays a preview of the first ten downtime configurations. - - Mute alerts during downtime ============================================================ From d9324ad995c4e53ccd0d5f9ccddaf9968da13eb1 Mon Sep 17 00:00:00 2001 From: ada Date: Tue, 29 Apr 2025 22:14:39 -0700 Subject: [PATCH 20/24] Changed an h3 to an h2. --- synthetics/test-config/syn-downtimes.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/synthetics/test-config/syn-downtimes.rst b/synthetics/test-config/syn-downtimes.rst index c443e4406..9e4d0ad0c 100644 --- a/synthetics/test-config/syn-downtimes.rst +++ b/synthetics/test-config/syn-downtimes.rst @@ -48,7 +48,7 @@ If you selected a value other than :guilabel:`Does not repeat` in the :guilabel: Modify a downtime configuration ------------------------------------------------------------- +============================================================ * Before a downtime configuration has run: From 383bfcdbd721e9a3b51fed0a1de569ad4aad8c99 Mon Sep 17 00:00:00 2001 From: Tracey Carter Date: Wed, 30 Apr 2025 14:43:57 -0700 Subject: [PATCH 21/24] added link to Related Content doc --- gdi/opentelemetry/components/http-forwarder-extension.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/gdi/opentelemetry/components/http-forwarder-extension.rst b/gdi/opentelemetry/components/http-forwarder-extension.rst index b7fbe77b6..a3f75c143 100644 --- a/gdi/opentelemetry/components/http-forwarder-extension.rst +++ b/gdi/opentelemetry/components/http-forwarder-extension.rst @@ -9,3 +9,5 @@ HTTP forwarder extension The Splunk Distribution of the OpenTelemetry Collector supports the HTTP forwarder extension. Documentation is planned for a future release. +Splunk Observability Cloud uses OpenTelemetry to correlate telemetry types. To do this, your telemetry field names or metadata key names must exactly match the metadata key names used by both OpenTelemetry and Splunk Observability Cloud. To ensure your metadata key names are correctly named, see :ref:`relatedcontent-collector`. + From 82ba5442c6ac893db5e82bb4977d4840cb43e568 Mon Sep 17 00:00:00 2001 From: Tracey Carter Date: Wed, 30 Apr 2025 15:40:18 -0700 Subject: [PATCH 22/24] implemented docs feedback - linked to centralized RBAC doc --- splunkplatform/centralized-rbac.rst | 2 +- splunkplatform/unified-id/unified-identity.rst | 10 ++++++++++ 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/splunkplatform/centralized-rbac.rst b/splunkplatform/centralized-rbac.rst index 90d401078..cb4d3f36d 100644 --- a/splunkplatform/centralized-rbac.rst +++ b/splunkplatform/centralized-rbac.rst @@ -9,7 +9,7 @@ Centralized user and role management .. meta:: :description: This page describes how Splunk Cloud Platform admins can manage Splunk Observability Cloud roles from Splunk Cloud Platform. -Administrators can now centrally manage users and roles for both Splunk Cloud Platform and Splunk Observability Cloud in Splunk Cloud Platform. Splunk Cloud Platform becomes the role based access control (RBAC) store for Splunk Observability Cloud. +Administrators can centrally manage users and roles for both Splunk Cloud Platform and Splunk Observability Cloud in Splunk Cloud Platform. Splunk Cloud Platform becomes the role based access control (RBAC) store for Splunk Observability Cloud. Who can access centralized user and role management? ================================================================================================= diff --git a/splunkplatform/unified-id/unified-identity.rst b/splunkplatform/unified-id/unified-identity.rst index e300a61c3..2c6975b08 100644 --- a/splunkplatform/unified-id/unified-identity.rst +++ b/splunkplatform/unified-id/unified-identity.rst @@ -222,6 +222,14 @@ To add a new user to Splunk Observability Cloud after the integration is complet The user can now log in to Splunk Observability Cloud with their Splunk Cloud Platform permissions. +.. _centralized-rbac: + +Centralized user and role management +------------------------------------------------------------------------------------------ +Administrators of organizations that have Splunk Cloud Platform and Splunk Observability Cloud can centrally manage users and roles for both in Splunk Cloud Platform. Splunk Cloud Platform becomes the role based access control (RBAC) store for Splunk Observability Cloud. + +All customers who have Unified Identity can access centralized user and role management in Splunk Cloud Platform. For more information, see :ref:`centralized-rbac`. + After initial user provisioning ------------------------------------------------------------------------------------------- @@ -260,6 +268,8 @@ Contact your Splunk Cloud Platform administrator if you receive the following :s Users receive this error message if their Splunk Cloud Platform administrator did not give them the custom role ``o11y_access``. The ``o11y_access`` role is required to access Splunk Observability Cloud. +If you set up centralized user and role access, make sure to assign the ``o11y_access`` role to all roles that should access Splunk Observability Cloud, not just the user role. + Working in Splunk Observability Cloud after the integration ========================================================================================== From d85adf1fc6b9d4cf51a6bc3596dd0db7c748f524 Mon Sep 17 00:00:00 2001 From: Tracey Carter Date: Wed, 30 Apr 2025 16:30:49 -0700 Subject: [PATCH 23/24] fixed label --- splunkplatform/unified-id/unified-identity.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/splunkplatform/unified-id/unified-identity.rst b/splunkplatform/unified-id/unified-identity.rst index 2c6975b08..7425cb4d0 100644 --- a/splunkplatform/unified-id/unified-identity.rst +++ b/splunkplatform/unified-id/unified-identity.rst @@ -222,7 +222,7 @@ To add a new user to Splunk Observability Cloud after the integration is complet The user can now log in to Splunk Observability Cloud with their Splunk Cloud Platform permissions. -.. _centralized-rbac: +.. uid-central-rbac: Centralized user and role management ------------------------------------------------------------------------------------------ From 1110040d94bf40d08a53b2f5e911542073eb410c Mon Sep 17 00:00:00 2001 From: Tracey Carter Date: Thu, 1 May 2025 15:33:12 -0700 Subject: [PATCH 24/24] crossorigin to crossOrigin --- rum/rum-session-replay.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/rum/rum-session-replay.rst b/rum/rum-session-replay.rst index 1524f04c9..5254f5fa2 100644 --- a/rum/rum-session-replay.rst +++ b/rum/rum-session-replay.rst @@ -40,8 +40,8 @@ This example shows the order in which to initialize the scripts: .. code-block:: html - - + + + + To avoid gaps in your data, load and initialize the Splunk JavaScript Agent asynchronously and as early as possible.