Pulling refs/heads/main into main

gdi/opentelemetry/collector-how-to.rst

@@ -12,46 +12,114 @@ Use the Collector: How to perform common tasks
     :titlesonly:
     :hidden:
 
-Browse the table below to learn how to carry out common tasks with the Splunk Distribution of OpenTelemetry Collector.
+Browse the table below to learn how to carry out common tasks with the Splunk Distribution of the OpenTelemetry Collector.
 
 .. list-table::
   :width: 100%
-  :widths: 40 60
+  :widths: 25 25 25 25
   :header-rows: 1
 
   * - I want to...
+    - Why?
+    - When?
     - See...
   * - Control data pre-ingest
+    - To optimize data ingestion performance, reduce storage costs, allow for customization, and address privacy concerns by controlling the data sent to Splunk Observability Cloud.
+    - Use this when you encounter redundant or unnecessary telemetry data, need to modify data to meet specific requirements, or must sanitize sensitive information before ingestion using the Collector.
     - :ref:`configure-remove`
-  * - Obfuscate sensitive data
-    - :ref:`sensitive-data-controls`  
-  * - Uniquely identify an instance	
-    - :ref:`attributes-processor` 
-  * - Use tags or attributes
-    - :ref:`otel-tags`   
-  * - Remove attributes
-    - :ref:`attributes-processor` 
+  * - Work with tags or attributes
+    - To add, modify, or remove tags or attributes on data for better organization and control.
+    - Use this when learning how to modify tags and attributes on data before ingestion using the Collector.
+    - :ref:`otel-tags`
+  * - Obfuscate sensitive data in logs
+    - To protect privacy by ensuring sensitive log data is not ingested.
+    - Use this when sensitive information needs to be sanitized before ingestion using the Collector.
+    - :ref:`attributes-processor-obfuscate-logs` 
+  * - Obfuscate sensitive data in traces
+    - To protect privacy by ensuring sensitive trace data is not ingested.
+    - Use this when sensitive information needs to be sanitized before ingestion using the Collector.
+    - :ref:`sensitive-data-controls`
+  * - Filter unwanted logs
+    - To prevent ingestion of unwanted log data by using filtering logic to include or exclude specific logs. This helps to optimize data flow and reduce costs.
+    - Use this when you need to collect log data only from certain sources or of specific types, or when log ingestion load is too high.
+    - :ref:`filter-processor-logs` 
+  * - Filter unwanted metrics
+    - To prevent ingestion of unwanted metric data by using filtering logic to include or exclude specific metrics. This helps to optimize data flow and reduce costs.
+    - Use this when you need to collect metric data only from certain sources or of specific types, or when metric ingestion load is too high.
+    - :ref:`filter-processor-metrics` 
+  * - Filter unwanted traces
+    - To prevent ingestion of unwanted trace data by using filtering logic to include or exclude specific traces. This helps to optimize data flow and reduce costs.
+    - Use this when you need to collect trace data only from certain sources or of specific types, or when trace ingestion load is too high.
+    - :ref:`filter-processor-spans` 
+  * - Collect a fraction of logs using sampling
+    - To reduce log ingestion volume and costs by using probabilistic sampling to collect a percentage of log data.
+    - Use this when you need to collect only a sample set of log data which can help address ingesting too many logs.
+    - :ref:`probabilistic-sampler-processor` 
+  * - Collect a fraction of traces using sampling
+    - To reduce trace ingestion volume and costs by using tail sampling to collect a percentage of trace data.
+    - Use this when you need to collect only a sample set of trace data which can help address ingesting too many traces.
+    - :ref:`tail-sampling-processor` 
   * - Collect custom metrics	
-    - :new-page:`Receive any custom metric with the Collector <https://opentelemetry.io/blog/2023/any-metric-receiver/>`
+    - To send custom infrastructure and application metrics to Splunk Observability Cloud for deeper custom visibility.
+    - Use this when instrumenting a service that isn't natively supported or when specific custom metrics are required.
+    - :new-page:`send-custom-metrics` 
   * - Collect Prometheus metrics	
+    - To collect widely used Prometheus metrics and send them to Splunk Observability Cloud.
+    - Use this when instrumenting a Prometheus source for monitoring.
     - :ref:`prometheus-receiver`        
-  * - Collect logs	
+  * - Collect host logs
+    - To collect on-disk logs for analysis and monitoring.
+    - Use this when you need to collect logs from the local system or host.
     - :ref:`filelog-receiver`
-  * - Collect Kubernetes events 
-    - :ref:`otel-k8s-events` 
-  * - Filter Kubernetes elements 
-    - :ref:`filter-processor-kubernetes` 
-  * - Deactivate Kubernetes metrics
-    - :ref:`kubernetes-cluster-receiver`
-  * - Observe specific events	
+  * - Dynamically collect data from new data sources at runtime
+    - To monitor data sources that may be created, removed, or recreated during runtime.
+    - Use this when the receiver creator feature is needed to dynamically create receivers at runtime, based on configured rules and observer extensions.
     - :ref:`receiver-creator-receiver`
-  * - Look for support for an environment	
+  * - Look for collector support for a specific environment
+    - To ensure that your environment is compatible with the Collector.
+    - Validate support for your target environment before deploying your Collector instance.
     - :ref:`requirements`
-  * - Collector deployment options, such as Amazon Fargate, Ansible, Chef, PCF, or Puppet
+  * - Evaluate Collector deployment options like Ansible, Chef, PCF, or Puppet
+    - Different deployment methods have unique requirements and features, allowing you to tailor the deployment to your specific needs.
+    - Before deploying the Collector choose the most suitable deployment mechanism for your environment and requirements.
     - :ref:`otel_deployments`   
-  * - Look for changes between versions	
+  * - Review release changes before	collector version upgrades
+    - New Collector versions include important features, optimizations, and fixes, which are documented in the release notes.
+    - Always review the release notes before upgrading the collector to understand the changes.
     - * :new-page:`Main changelog for the Splunk distribution of the Collector <https://github.com/signalfx/splunk-otel-collector/blob/main/CHANGELOG.md>` 
-      * :new-page:`Changelog for the Helm chart <https://github.com/signalfx/splunk-otel-collector-chart/blob/main/CHANGELOG.md>` 
+      * :new-page:`Collector Contrib repository <https://github.com/open-telemetry/opentelemetry-collector-contrib>` 
+      * :new-page:`Upstream changelog (Contrib) <https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/CHANGELOG.md>`
+      * :new-page:`Upstream changelog (Core) <https://github.com/open-telemetry/opentelemetry-collector/blob/main/CHANGELOG.md>`
+
+.. _collector-how-to-kubernetes:
+
+Tasks specific to Kubernetes environments
+==========================================
+
+These tasks are specific to Kubernetes environments:
+
+.. list-table::
+  :width: 100%
+  :widths: 25 25 25 25
+  :header-rows: 1
+
+  * - I want to...
+    - Why?
+    - When?
+    - See...
+  * - Collect Kubernetes events 
+    - To enable the collection of Kubernetes events (events.k8s.io/v1) for enhanced observability.
+    - Use this when you want Kubernetes events to be available in your observability setup for better insight into cluster activities.
+    - :ref:`otel-k8s-events` 
+  * - Filter collecting telemetry data at different levels in Kubernetes
+    - To filter Kubernetes metrics, logs, and traces from specific clusters, namespaces, pods, or containers, reducing unnecessary data collection.
+    - Use this when you need to minimize telemetry ingestion by excluding data from certain parts of the cluster or when focusing on specific Kubernetes data souces.
+    - :ref:`filter-processor-kubernetes` 
+  * - Review release changes before	collector version upgrades
+    - New collector versions often include important features, optimizations, and fixes, which are documented in the release notes.
+    - Always review the release notes before upgrading the collector to understand the changes.
+    - * :new-page:`Changelog for the Helm chart <https://github.com/signalfx/splunk-otel-collector-chart/blob/main/CHANGELOG.md>` 
+      * :new-page:`Main changelog for the Splunk distribution of the Collector <https://github.com/signalfx/splunk-otel-collector/blob/main/CHANGELOG.md>` 
       * :new-page:`Collector Contrib repository <https://github.com/open-telemetry/opentelemetry-collector-contrib>` 
       * :new-page:`Upstream changelog (Contrib) <https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/CHANGELOG.md>`
       * :new-page:`Upstream changelog (Core) <https://github.com/open-telemetry/opentelemetry-collector/blob/main/CHANGELOG.md>`

gdi/opentelemetry/components/attributes-processor.rst

@@ -134,6 +134,8 @@ The following sample configurations show how to perform different actions on att
 
 .. note:: For a complete list of examples, see the configuration snippets in :new-page:`https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/attributesprocessor/testdata/config.yaml`.
 
+.. _attributes-processor-obfuscate-logs:
+
 Remove or obfuscate sensitive information from logs
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 

gdi/opentelemetry/components/filter-processor.rst

@@ -114,6 +114,8 @@ The following sample configurations show how to filter spans, metrics, and logs
 
 .. note:: For a complete list of examples, see the configuration snippets in :new-page:`https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/filterprocessor/testdata`.
 
+.. _filter-processor-spans:
+
 Filter spans
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -146,6 +148,8 @@ You can exclude or include spans from traces using resource attributes or OTTL c
 
 .. note:: Include filters are always applied before exclude filters for any given filter processor instance.
 
+.. _filter-processor-metrics:
+
 Filter metrics
 ^^^^^^^^^^^^^^^^^^^^^
 
@@ -190,6 +194,8 @@ You can exclude or include metrics using metric names, expressions, or OTTL cond
       datapoint:
          - 'attributes["attributename"] == "value"'
 
+.. _filter-processor-logs:
+
 Filter logs
 ^^^^^^^^^^^^^^^^^^^^^
 

infrastructure/metrics-pipeline/metrics-usage-report.rst

@@ -38,7 +38,7 @@ Metric identifiers
 
    * - Category type 
      - The category of the metric, in the format of a number. It only applies to host-based subscription plans. In data points per
-       minute (DPM) subscription plans, the system counts all metrics ase considered custom metrics.
+       minute (DPM) subscription plans, all metrics are considered custom metrics.
 
 The following table has an overview of metric category types. To learn more about metric categories, see :ref:`metrics-category`.