Pulling refs/heads/main into main

Dockerfile

@@ -8,4 +8,5 @@ RUN apt-get update && \
 RUN pip3 install --upgrade pip
 RUN pip3 install -r requirements.txt --force-reinstall --no-cache-dir --root-user-action=ignore
 RUN pip3 install sphinx-autobuild --root-user-action=ignore
+RUN pip3 install standard-imghdr
 ENTRYPOINT ["tail", "-f", "/dev/null"]

admin/authentication/authentication-tokens/org-tokens.rst

@@ -237,7 +237,7 @@ To rotate an access token with the API, use the ``POST /token/{name}/rotate`` en
 
 .. code-block:: bash
 
-   curl -X  POST "https://api.{realm}.signalfx.com/v2/token/{name}/rotate?graceful={gracePeriod}" \
+   curl -X  POST "https://api.{realm}.signalfx.com/v2/token/{name}/rotate?graceful={gracePeriod}&secondsUntilExpiry={secondsUntilExpiry}" \
       -H "Content-type: application/json" \
       -H "X-SF-TOKEN: <your-user-session-api-token-value>"
 
@@ -247,6 +247,7 @@ Follow these steps:
 #. Enter your API session token in the ``your-user-session-api-token-value`` field. To find or create an API session token, see :ref:`admin-api-access-tokens`.
 #. Provide the name of the token you want to rotate in the ``name`` field.
 #. Optionally, provide a grace period, in seconds, in the ``gracePeriod`` field.
+#. Optionally, provide the seconds until your token expires in the ``secondsUntilExpiry`` field. This can be any value between 0 second and 5,676,000,000 seconds (18 years), inclusive. If left unspecified, the token remains valid for 30 days. 
 #. Call the API endpoint to rotate the token.
 
 For example, the following API call rotates ``myToken`` and sets a grace period of 604800 seconds (7 days) before the previous token secret expires.

gdi/opentelemetry/collector-kubernetes/kubernetes-config-advanced.rst

@@ -503,3 +503,32 @@ Cluster Receiver support
 The Cluster receiver is a 1-replica deployment of the OpenTelemetry Collector. Because the Kubernetes control plane can select any available node to run the cluster receiver pod (unless ``clusterReceiver.nodeSelector`` is explicitly set to pin the pod to a specific node), ``hostPath`` or ``local`` volume mounts don't work for such environments.
 
 Data persistence is currently not applicable to the Kubernetes cluster metrics and Kubernetes events.
+
+Monitor OpenShift infrastructure nodes
+============================================
+
+By default, the Splunk Distribution of OpenTelemetry Collector for Kubernetes doesn't collect data from OpenShift infrastructure nodes. 
+
+You can customize the Collector Helm Chart file to activate data collection from OpenShift infrastructure nodes. To do so, complete the following steps:
+
+#. Open your values.yaml file for the Helm Chart.
+#. Copy and paste the following YAML snippet into the values.yaml file:
+
+    .. code-block:: yaml
+
+      tolerations:
+        - key: node-role.kubernetes.io/master
+          effect: NoSchedule
+        - key: node-role.kubernetes.io/control-plane
+          effect: NoSchedule
+        - key: node-role.kubernetes.io/infra
+          effect: NoSchedule
+          operator: Exists
+
+#. Install the Collector using the Helm Chart:
+
+    .. code-block:: bash
+
+      helm install my-splunk-otel-collector --values values.yaml splunk-otel-collector-chart/splunk-otel-collector
+
+.. note:: Monitoring OpenShift infrastructure nodes might pose a security risk depending on which method you used to create the Kubernetes environment.

gdi/opentelemetry/components/redis-receiver.rst

@@ -21,7 +21,7 @@ Get started
 
 Follow these steps to configure and activate the component:
 
-1. Deploy the Splunk Distribution of OpenTelemetry Collector to your host or container platform:
+1. Deploy the Splunk Distribution of the OpenTelemetry Collector to your host or container platform:
 
    - :ref:`otel-install-linux`
    - :ref:`otel-install-windows`
@@ -56,9 +56,9 @@ To complete the configuration, include the receiver in the ``metrics`` pipeline
         receivers: [redis]
 
 Configuration settings
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+-------------------------------------------------
 
-The following setting is required:
+The following settings are required:
 
 * ``endpoint``: The hostname and port of the Redis instance, separated by a colon. No default value.
 

gdi/opentelemetry/components/vcenter-receiver.rst

@@ -7,6 +7,108 @@ vCenter receiver
 .. meta::
       :description: The vCenter receiver supports ESXi and vCenter.
 
-The Splunk Distribution of the OpenTelemetry Collector supports the vCenter receiver. Documentation is planned for a future release.  
+The vCenter receiver fetches metrics from a vCenter or ESXi host running VMware vSphere APIs.
 
-To find information about this component in the meantime, see :new-page:`vCenter receiver <https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/vcenterreceiver>` on GitHub.
+Prerequisites
+======================
+
+This receiver supports ESXi and vCenter versions 7.0 and 8.
+
+To retrieve data you need to assign a read-only user to vSphere with permissions to the vCenter server, cluster and all subsequent resources being monitored.
+
+Get started
+======================
+
+Follow these steps to configure and activate the component:
+
+1. Deploy the Splunk Distribution of the OpenTelemetry Collector to your host or container platform:
+
+   - :ref:`otel-install-linux`
+   - :ref:`otel-install-windows`
+   - :ref:`otel-install-k8s`
+
+2. Configure the receiver creator receiver as described in the next section.
+3. Restart the Collector.
+
+Sample configuration
+----------------------------------------------------------------------
+
+To activate the vCenter receiver in the Collector, add ``vecenter`` to the ``receivers`` section of your configuration file, as shown in the following example:
+
+.. code:: yaml
+
+  receivers:
+    vcenter:
+
+To complete the configuration, include the receiver in the ``metrics`` pipeline of the ``service`` section of your configuration file. For example:
+
+.. code:: yaml
+
+  service:
+    pipelines:
+      metrics:
+        receivers: [vcenter]
+
+Configuration example
+----------------------------------------------------------------------
+
+See the following config example:
+
+.. code:: yaml
+
+  vcenter:
+    endpoint: http://vcsa.host.localnet
+    username: otelu
+    password: ${env:VCENTER_PASSWORD}
+    collection_interval: 5m
+    metrics:
+      vcenter.host.cpu.utilization:
+        enabled: false
+
+Configuration settings
+-------------------------------------------------
+
+The following settings are required:
+
+* ``password``
+
+* ``username``
+
+* ``endpoint``. Endpoint to the vCenter Server or ESXi host that has the SDK path enabled. 
+
+  * Use the <protocol>://<hostname> format, for example ``https://vcsa.hostname.localnet``.
+
+The following settings are optional:
+
+* ``collection_interval``. ``2m`` by default.  This receiver collects metrics on an interval. If the vCenter is large, increase this value. 
+
+  * Valid time units are ``ns``, ``us`` (or ``µs``), ``ms``, ``s``, ``m``, ``h``.
+
+* ``initial_delay``. ``1s`` by default. Defines how long the receiver waits before starting.
+
+* ``tls``. TLS control. By default insecure settings are rejected and certificate verification is on. Will use defaults for configtls.ClientConfig. Learn more at :new-page:`TLS Configuration Settings <https://github.com/open-telemetry/opentelemetry-collector/blob/main/config/configtls/README.md>` in GitHub.
+
+Settings
+======================
+
+The following table shows the configuration options for the vCenter receiver:
+
+.. raw:: html
+
+  <div class="metrics-standard" category="included" url="https://raw.githubusercontent.com/splunk/collector-config-tools/main/cfg-metadata/receiver/vcenter.yaml"></div>
+
+.. _vcenter-receiver-metrics:
+
+Metrics
+=====================
+
+The following metrics, resource attributes, and attributes are available.
+
+.. raw:: html
+
+  <div class="metrics-component" category="included" url="https://raw.githubusercontent.com/splunk/collector-config-tools/main/metric-metadata/vcenterreceiver.yaml"></div>
+
+Troubleshooting
+======================
+
+.. include:: /_includes/troubleshooting-components.rst

gdi/opentelemetry/discovery-mode.rst

@@ -92,6 +92,9 @@ Automatic discovery supports the following host services and applications:
    * - Service
      - Receiver
 
+   * - Apache Web Server
+     - Apache Web Server receiver. See :ref:`apache-receiver`.
+
    * - MySQL
      - MySQL receiver. See :ref:`mysql-receiver`
 
@@ -104,6 +107,9 @@ Automatic discovery supports the following host services and applications:
    * - NGINX
      - Smart Agent with collectd/nginx monitor type. See :ref:`nginx`
 
+   * - RabbitMQ
+     - RabbitMQ receiver. See :ref:`rabbitmq-receiver`.
+
    * - Redis
      - Redis receiver. See :ref:`redis-receiver`
 

synthetics/test-config/private-locations.rst

@@ -144,17 +144,17 @@ Configuring Proxy Settings for Private Locations
 
 In environments where direct internet access is restricted, you can route synthetic test traffic through a proxy server by configuring the following environment variables:
 
-* HTTP_PROXY: Specifies the proxy server for HTTP traffic.
+* ``HTTP_PROXY``: Specifies the proxy server for HTTP traffic.
 
-    * Example: export HTTP_PROXY="\http://proxy.example.com:8080"
+    * Example: ``export HTTP_PROXY="\http://proxy.example.com:8080"``
 
-* HTTPS_PROXY: Specifies the proxy server for HTTPS traffic.
+* ``HTTPS_PROXY``: Specifies the proxy server for HTTPS traffic.
 
-    * Example: export HTTPS_PROXY="\https://proxy.example.com:8443"
+    * Example: ``export HTTPS_PROXY="\https://proxy.example.com:8443"``
 
-* NO_PROXY: Specifies a comma-separated list of domains or IP addresses that should bypass the proxy.
+* ``NO_PROXY``: Specifies a comma-separated list of domains or IP addresses that should bypass the proxy.
 
-    * Example: export NO_PROXY="localhost,127.0.0.1,.internal-domain.com"
+    * Example: ``export NO_PROXY="localhost,127.0.0.1,.internal-domain.com"``
 
 For example, here is what a command might look like after you modify it to fit your environment:
 
@@ -165,15 +165,15 @@ For example, here is what a command might look like after you modify it to fit y
 
 In this example:
 
-HTTP_PROXY and HTTPS_PROXY are set to route traffic through a proxy at \http://172.17.0.1:1234.
+``HTTP_PROXY`` and ``HTTPS_PROXY`` are set to route traffic through a proxy at ``http://172.17.0.1:1234``.
 
-NO_PROXY is configured to bypass the proxy for local addresses and specific domains like .signalfx.com and .amazonaws.com.
+``NO_PROXY`` is configured to bypass the proxy for local addresses and specific domains like .signalfx.com and .amazonaws.com.
 
 Ensure that these variables are correctly configured to comply with your network policies. This setup allows the synthetic tests to communicate securely and efficiently in a controlled network environment.
 
 When using runner, it's important to correctly configure the proxy settings to avoid issues with browser-based tests. The following steps should be followed when setting up their environment:
 
-1. :strong:`Ensure Proper NO_PROXY Setup`:
+1. :strong:`Ensure proper NO_PROXY setup`:
 
    - When configuring ``NO_PROXY`` always include the following addresses: