Merge pull request splunk#1737 from splunk/repo-sync

Pulling refs/heads/main into main

Author: aurbiztondo-splunk

_images/images-charts/charts-drilldown-link.png

@@ -134,7 +134,7 @@ Follow these steps to create a Monitoring MetricSet for an instrumented service:
 .. note:: For standard MMS Splunk APM replaces dots with underscores in dimension names for MMS time series. For histogram MMS underscores are preserved.
 .. _inferred-service-mms:
 
-Create a Monitoring MetricSet with a custom dimension for an inferred service
+Create a Monitoring MetricSet for an inferred service
 =======================================================================================
 
 .. note:: Only 3rd-party or uninstrumented HTTP services are supported for MMS.

_images/images-charts/drilldown-example.png

@@ -57,7 +57,7 @@ MMS are available for the APM components listed in the following table. Each MMS
        * ``service.name`` - This dimension is only available for histogram MMS.
        * ``sf_error``
      - Yes
-   * - ``inferred.services`` - 
+   * - ``inferred.services`` - the requests to a service that has not yet been instrumented
      - * ``sf_service``
        * ``service.name`` - This dimension is only available for histogram MMS.
        * ``sf_environment``

apm/span-tags/cmms.rst

@@ -217,8 +217,26 @@ When data is sampled, you can see a message like this on the chart:
 .. image:: /_images/images-charts/sampling.png
     :width: 65%
 
-If you click :guilabel:`Click here to disable sampling`, or check the :guilabel:`Disable sampling` checkbox in the chart options tab, the sampling message is no longer displayed, and any time series data previously omitted is shown. Depending on the number of time series, disabling sampling might cause the chart to render more slowly.
+If you select :guilabel:`Click here to disable sampling`, or select the :guilabel:`Disable sampling` check box in the chart options tab, the sampling message is no longer displayed, and any time series data previously omitted is shown. Depending on the number of time series, disabling sampling might cause the chart to render more slowly.
 
+.. _chart-drilldown-link:
+
+Drilldown link
+=============================================================================
+
+This option lets you add a drilldown link to the chart header when you view the chart in a dashboard.
+
+.. image:: /_images/images-charts/charts-drilldown-link.png
+    :width: 65%
+
+Providing a drilldown link helps other users in your organization navigate to other parts of Splunk Observability Cloud or external resources containing data related to the chart.
+
+You can include dashboard variables and time range in the URL using curly brackets, such as ``startTime={{{-15m}}}``. For more information on dashboard variables, see :ref:`customize-dashboard-variables`.
+
+For example, you can configure a link to go from a chart to a RUM instance during a specific time window for the same metric.
+
+.. image:: /_images/images-charts/drilldown-example.png
+    :width: 65%
 
 .. _heatmap-group-by:
 
@@ -258,7 +276,7 @@ Max delay
 
 By default, the :strong:`Max delay` field is set to ``Auto``, which allows data to come in with as little delay as possible.
 
-If you know that some of your data is delayed and you want to wait for that data to arrive before your charts are updated, click the drop-down menu and choose a new value from the list. For more information, see :ref:`delayed-datapoints`.
+If you know that some of your data is delayed and you want to wait for that data to arrive before your charts are updated, select the dropdown menu and select a new value from the list. For more information, see :ref:`delayed-datapoints`.
 
 The value you specify is applied whenever you open the chart or view it in a dashboard, unless there is a max delay override. To learn more, see :ref:`dashboard-max-delay`.
 
@@ -321,7 +339,7 @@ To learn more about rollups, see :ref:`rollups`.
 No active metrics message
 =============================================================================
 
-This option allows you to add an optional message on graph charts, heatmap charts, list charts, and single value charts to indicate when metrics used in a chart either don't exist or are inactive. 
+This option lets you add an optional message on graph charts, heatmap charts, list charts, and single value charts to indicate when metrics used in a chart either don't exist or are inactive. 
 
 A metric is considered inactive by Splunk Observability Cloud in the following cases: 
 

apm/span-tags/metricsets.rst

@@ -95,8 +95,7 @@ Customizing mirrored dashboard filters
 Customize dashboard variables
 =========================================
 
-You can define various dashboard variable settings that take effect for any dashboard in this dashboard group.
-Select :guilabel:`Dashboard Variables` from the dashboard's Actions menu.
+You can define various dashboard variable settings that take effect for any chart in this dashboard. Select :guilabel:`Dashboard variables` from the dashboard actions menu.
 
 When you save these settings, the dashboard variable and the suggested values now reflect the customizations you
 specified.
@@ -105,12 +104,12 @@ Customizing mirrored dashboard variables
 ----------------------------------------
 
 - You can make changes directly on the :guilabel:`Overrides` bar; if you save the mirror, these settings become
-  default values in the :guilabel:`Variable Details` section of the :guilabel:`Dashboard Variables` tab.
+  default values in the :guilabel:`Variable details` section of the :guilabel:`Dashboard variables` tab.
 
-- When you save customization options that you set in the :guilabel:`Dashboard Variables` tab, these changes are
+- When you save customization options that you set in the :guilabel:`Dashboard variables` tab, these changes are
   automatically saved as default settings for this mirror.
 
-- On the :guilabel:`Dashboard Variables` tab, anyone with dashboard write permissions can add, delete, and edit
+- On the :guilabel:`Dashboard variables` tab, anyone with dashboard write permissions can add, delete, and edit
   dashboard variables and their settings. These variables affect all mirrors that don't have variable
   customizations applied.
 

data-visualization/charts/chart-options.rst

@@ -48,7 +48,7 @@ To install the Splunk Distribution of the OpenTelemetry Collector for Linux you
 See the default settings and configuration options at:
 
 * :ref:`linux-config-ootb`
-* By default, you'll obtain these :ref:`metrics <ootb-metrics-windows>` 
+* By default, you'll obtain these :ref:`metrics <ootb-metrics-linux>` 
 * :ref:`otel-linux-config`
 * :ref:`linux-config-logs`
 

data-visualization/dashboards/dashboard-create-customize.rst

@@ -7,7 +7,7 @@ Process your data with pipelines
 .. meta::
       :description: Learn how to process data collected with the Splunk Distribution of the OpenTelemetry Collector.
 
-Use pipelines in your Collector's config file to define the path you want your ingested data to follow. Specify which components you want to use, starting from data reception using :ref:`receivers <otel-components-receivers>`, then data processing or modification with :ref:`processors <otel-components-processors>`, until data finally exits the Collector through :ref:`exporters <otel-components-exporters>`. For an overview of all available components and their behavior refer to :ref:`otel-components`.
+Use pipelines in your Collector's config file to define the path you want your ingested data to follow. Specify which components you want to use, starting from data reception using :ref:`receivers <otel-components-receivers>`, then data processing or modification with :ref:`processors <otel-components-processors>`, until data finally exits the Collector through :ref:`exporters <otel-components-exporters>`. For an overview of all available components and their behavior refer to :ref:`otel-components`. For general recommendations and guidelines for using processors, see the :new-page:`OpenTelemetry processor documentation <https://github.com/open-telemetry/opentelemetry-collector/tree/main/processor#recommended-processors>`.   
 
 Pipelines operate on three data types: logs, traces, and metrics. To learn more about data in Splunk Observability Cloud, see :ref:`data-model`.
 

gdi/opentelemetry/collector-linux/collector-linux-intro.rst

@@ -0,0 +1,81 @@
+:orphan:
+
+.. _aopt-glossary:
+
+.. include:: /private-preview/aopt/toc.rst
+    :start-after: :orphan:
+
+**********************************************************
+Glossary
+**********************************************************
+
+.. _aopt-glossary-confidence-level:
+
+Confidence level
+==========================================================
+
+The ratio of how many days of information is available for a workload compared to how many days worth of information Application Optimization needs in order to analyze it (14 contiguous days). If your data spans 14 contiguous days, the confidence will be high. If your data spans fewer than 14 days or since the initial deployment, the confidence level will be lower. For example, if you've made a configuration change such as a change to CPU or memory limits, an addition of a container, and so on. Definition of confidence levels:
+
+* :guilabel:`High`: Greater than 90% of needed information is available.
+
+* :guilabel:`Medium`: 50-89% of needed information is available.
+
+* :guilabel:`Low`: Only 5-49% of needed information is available.
+
+* :guilabel:`Unknown`: Less than 5% of needed information is available.
+
+
+Application Optimization calculates an overall confidence level by taking the lowest confidence level across all containers, where each container's confidence level is an average of the separate confidence levels for CPU and memory.
+
+
+Why the confidence level matters
+----------------------------------------------------------
+
+It's a good idea to match the confidence level to your workload's importance or criticality. In other words, if your workload is a test or you just need to preview the recommendations, a confidence level of :guilabel:`Low` is okay. But if your workload is a production or business critical workload, it's best to wait for a confidence level of :guilabel:`High` before applying the recommendations.
+
+
+.. _aopt-glossary-efficiency:
+
+Efficiency
+==========================================================
+
+The balance between over-provisioning and under-provisioning to optimize resource utilization without compromising performance or stability. Highly efficient workloads use resources in a way that aligns closely with their actual consumption, reducing waste and maximizing your cluster's capacity to run other workloads. 
+
+Application Optimization is a powerful tool for achieving and maintaining efficiency. It calculates efficiency as the average of the pod-wide usage of a resource's ``request`` setting, capped at 100%. Its calculation only includes metrics within the analysis window, which is the lesser of 14 days and the time since the last resource change (or the initial deployment). Note that rather than finding the utilization (usage over requests) of each container within a pod, all of the containers' usage and requests are added up first. The averages for each CPU and memory ``request`` setting are then weight-averaged based on the assumed resource cost weights.
+
+Best practices call for resource utilization in the 60-80% range. Having efficiency above 70-80% presents resource starvation risks. 
+
+When values are unset for a particular resource, this tool assumes those ``request`` settings to be at usage (in other words, 100% efficient) to more accurately weigh multi-container rates.
+
+When the main container has an unset resource, this tool considers the efficiency rate to be undefined.
+
+
+.. _aopt-glossary-resource-footprint:
+
+Resource Footprint
+==========================================================
+
+A workload's resource footprint is the sum of its pods' ``request`` settings for that resource or its average usage if it exceeds its ``request`` settings. If the ``request`` value is not set, the footprint represents the sum of actual usage instead. This tile displays the sum of all resource footprints of all the pods of all your workloads. 
+
+
+.. _aopt-glossary-starvation-risk:
+
+Starvation risk
+==========================================================
+
+A workload's average risk of running out of CPU or memory:
+
+* :guilabel:`High`: The workload has tried to use more resources than were available, so its performance and reliability have likely been impacted. Application Optimization marks any container in which usage is greater than or equal to 95% of its ``limit`` settings as :guilabel:`High`.
+
+* :guilabel:`Medium`: The workload has used more than its allocated resources (``request`` settings). While this may not have an impact on its performance and reliability due to Kubernetes bursting into additional resources, future occurrences of overusage may have an impact, since extra resources are not guaranteed to exist. 
+  
+  Application Optimization sets :guilabel:`Starvation risk` to :guilabel:`Medium` for any container in which either of these is true:
+  
+    * At least one resource (CPU or memory) of is undefined.
+    
+    * All ``request`` settings are defined and actual usage of at least one resource of exceeds its ``request`` setting for any time slot.
+
+* :guilabel:`Low`: The workload hasn't exceeded its allocated resources but doesn't have enough headroom to absorb spikes or delays in scale-out when traffic increases. Application Optimization marks any container in which, for either CPU or memory, the recommendation is greater than the baseline value. For example, the usage is greater than target utilization (0.85).
+
+* :guilabel:`Minimal`: None of the above conditions are detected. In other words, all containers have ``request`` settings for both CPU and memory, and neither of these resources has had usage exceeding its target utilization. 
+