splunk · aurbiztondo-splunk · May 5, 2025 · Apr 9, 2025 · Apr 9, 2025 · Apr 16, 2025
@@ -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`.
+To learn more about token limits, see :ref:`admin-manage-usage`.
@@ -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
 
     <div class="instrumentation" section="instrumentations" url="https://raw.githubusercontent.com/splunk/o11y-gdi-metadata/main/apm/splunk-otel-java/metadata.yaml" data-renaming='{"keys": "Identifier", "description": "Description", "stability": "Stability", "support": "Support", "instrumented_components": "Components", "signals": "Signals", "source_href": "Source", "settings": "Settings", "dependencies": "Dependencies", "supported_versions": "Supported versions", "name": "Name", "package_href": "Package URL", "version": "Version", "instrument": "Type", "metric_name": "Metric name", "metrics": "Metrics", "env": "Environment variable", "default": "Default", "type": "Type", "category": "Category"}'></div>
 
 For a complete list of supported libraries and frameworks, see :new-page:`Supported libraries <https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/supported-libraries.md>` 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

@@ -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"``

@@ -8,28 +8,50 @@ 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
-port.
+default, it runs on port 4193, but it can be configured to any other
+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.
 
+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  
+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.
+
+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 <prometheus_receiver>` 
+to scrape metrics from the proxy metric server. 
+
+
+cAdvisor with Docker
+---------------------
+
 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
 Kubernetes dashboards instead.
 
-This integration is available on Kubernetes, Linux, and Windows.
 
 Benefits
 --------
 
-
-
 .. raw:: html
 
    <div class="include-start" id="benefits.rst"></div>
@@ -41,13 +63,9 @@ Benefits
    <div class="include-stop" id="benefits.rst"></div>
 
 
-
-
 Installation
 ------------
 
-
-
 .. raw:: html
 
    <div class="include-start" id="collector-installation-linux.rst"></div>
@@ -59,13 +77,9 @@ Installation
    <div class="include-stop" id="collector-installation-linux.rst"></div>
 
 
-
-
 Configuration
 -------------
 
-
-
 .. raw:: html
 
    <div class="include-start" id="configuration.rst"></div>
@@ -77,10 +91,11 @@ Configuration
    <div class="include-stop" id="configuration.rst"></div>
 
 
+Examples
+^^^^^^^^
 
-
-Example
-~~~~~~~
+Activate integration
+####################
 
 To activate this integration, add the following to your Collector
 configuration:
@@ -102,8 +117,60 @@ section of your configuration file:
        metrics:
          receivers: [smartagent/cadvisor]
 
+.. _prometheus_receiver:
+
+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
+
+   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
-~~~~~~~~~~~~~~~~~~~~~~
+^^^^^^^^^^^^^^^^^^^^^^
 
 The following table shows the configuration options for this receiver:
 
@@ -135,9 +202,7 @@ The following metrics are available for this integration:
       <div class="metrics-yaml" url="https://raw.githubusercontent.com/signalfx/splunk-otel-collector/main/internal/signalfx-agent/pkg/monitors/cadvisor/metadata.yaml"></div>
 
 Notes
-~~~~~
-
-
+^^^^^
 
 .. raw:: html
 
@@ -155,8 +220,6 @@ Notes
 Troubleshooting
 ---------------
 
-
-
 .. raw:: html
 
    <div class="include-start" id="troubleshooting-components.rst"></div>

@@ -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`.
+
@@ -46,7 +46,7 @@ The following settings are optional and can be added to the configuration for mo
 
 * ``logs_endpoint``. The target URL to send log data to. For example, ``https://example.com:4318/v1/logs``.
 
-* ``metrics_endpoint``. The target URL to send metric data to. For example, ``"https://ingest.us0.signalfx.com/v2/trace/otlp"`` to send metrics to Splunk Observability Cloud.
+* ``metrics_endpoint``. The target URL to send metric data to. For example, ``"https://ingest.<realm>.signalfx.com/v2/datapoint/otlp"`` to send metrics to Splunk Observability Cloud.
 
 * ``tls``. See :ref:`TLS Configuration Settings <otlphttp-exporter-settings>` in this document for the full set of available options. Only applicable for sending data to a custom endpoint.
 
@@ -67,6 +67,8 @@ To send traces and metrics to Splunk Observability Cloud using OTLP over HTTP, c
     otlphttp:
       # The target URL to send trace data to. By default it's set to ``https://ingest.${SPLUNK_REALM}.signalfx.com/v2/trace/otlp``.
       traces_endpoint: https://ingest.<realm>.signalfx.com/v2/trace/otlp
+      # The target URL to send metrics data to. By default it's set to ``https://ingest.${SPLUNK_REALM}.signalfx.com/v2/datapoint/otlp``.
+      metrics_endpoint: https://ingest.<realm>.signalfx.com/v2/datapoint/otlp
       # Set of HTTP headers added to every request.
       headers:
         # X-SF-Token is the authentication token provided by Splunk Observability Cloud.
@@ -92,8 +94,8 @@ This is a detailed configuration example:
 .. code-block:: yaml
 
   endpoint: "https://1.2.3.4:1234"
-  traces_endpoint: https://ingest.us0.signalfx.com/v2/trace/otlp
-  metrics_endpoint: https://ingest.us0.signalfx.com/v2/datapoint/otlp
+  traces_endpoint: https://ingest.<realm>.signalfx.com/v2/trace/otlp
+  metrics_endpoint: https://ingest.<realm>.signalfx.com/v2/datapoint/otlp
   headers:
     X-SF-Token: <access_token>
   timeout: 10s
@@ -160,8 +162,8 @@ For example:
 
   exporters:
     otlphttp:
-      metrics_endpoint: https://ingest.lab0.signalfx.com/v2/datapoint/otlp
-      traces_endpoint: https://ingest.lab0.signalfx.com/v2/trace/otlp
+      metrics_endpoint: https://ingest.<realm>.signalfx.com/v2/datapoint/otlp
+      traces_endpoint: https://ingest.<realm>.signalfx.com/v2/trace/otlp
       headers:
           "X-SF-Token": "mytoken"
       auth:
Original file line number	Diff line number	Diff line change
Expand Up		@@ -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`.