Merge pull request #2484 from splunk/repo-sync

Pulling refs/heads/main into main

Author: pauljwil

gdi/get-data-in/connect/gcp/gcp-connect.rst

@@ -98,8 +98,17 @@ Your GCP integration is now complete.
 
 .. note:: Splunk is not responsible for data availability, and it can take up to several minutes (or longer, depending on your configuration) from the time you connect until you start seeing valid data from your account. 
 
-Options
-++++++++
+Using a single principal for your resources
+++++++++++++++++++++++++++++++++++++++++++++++++
+
+In IAM you can grant access to your resources to one or more entities called principals, regardless of the authentication method (single Service Account or Workload Identity Federation). 
+
+If you're using a single principal for multiple projects, GCP tracks all API usage quota in the project where the principal originates from, which can result in throttling in your integration. To mitigate this, select :strong:`Use quota from the project where metrics are stored`. To use this option the principal provided for the project needs either the ``serviceusage.services.use`` permission or the Service Usage Consumer role.
+
+For a more detailed description see :new-page:`Principals <https://cloud.google.com/iam/docs/overview#concepts_related_identity>` in GCP's docs.
+
+Other options
+++++++++++++++++
 
 Optionally you can: 
 
@@ -111,8 +120,6 @@ Optionally you can:
 
 * If you select Compute Engine as one of the services to monitor, you can enter a comma-separated list of Compute Engine Instance metadata keys to send as properties. These metadata keys are sent as properties named ``gcp_metadata_<metadata-key>``.
 
-* Select :strong:`Use quota from the project where metrics are stored` to use a quota from the project where metrics are stored. The service account provided for the project needs either the ``serviceusage.services.use`` permission, or the `Service Usage Consumer` role.
-
 Alternatives to connect to GCP
 ============================================
 

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

@@ -503,32 +503,3 @@ 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/collector-linux/collector-configuration-tutorial/collector-config-tutorial-edit.rst

@@ -42,7 +42,7 @@ Adding an empty entry like in the previous example is sometimes enough to get st
          listen_address: "0.0.0.0:54526"
        protocol: rfc5424
 
-After you've added the Syslog receiver, make sure to add it to the receivers's list under ``service.pipelines``. In this case, the pipeline type is ``logs``, since the Syslog receiver collect logs:
+After you've added the Syslog receiver, make sure to add it to the receivers's list under ``service.pipelines``. In this case, the pipeline type is ``logs``, since the Syslog receiver collects logs:
 
 .. code-block:: yaml
    :emphasize-lines: 8

gdi/opentelemetry/components/host-metrics-receiver.rst

@@ -11,6 +11,7 @@ The host metrics receiver generates metrics scraped from host systems when the C
 
 By default, the host metrics receiver is activated in the Splunk Distribution of OpenTelemetry Collector and collects the following metrics:
 
+- System metrics
 - CPU usage metrics
 - Disk I/O metrics
 - CPU load metrics
@@ -91,6 +92,10 @@ Scrapers extract data from endpoints and then send that data to a specified targ
       - Description
    - 
 
+      - ``system``
+      - System metrics
+   - 
+
       - ``cpu``
       - CPU utilization metrics
    -