Merge pull request #1551 from splunk/repo-sync

Pulling refs/heads/main into main

admin/subscription-usage/apm-billing-usage-index.rst

@@ -122,8 +122,8 @@ Usage reports for host subscription plans include the following information abou
 * The number of billed hosts. Host data is available per minute.
 * The number of billed containers. Container data is available per minute.
 * The billed trace volume. Trace volume data is available per minute.
-* The number of billed Troubleshooting MetricSets (TMS). TMS data is available per minute. 
-* The number of billed Monitoring MetricSets (MMS). MMS data is available only for histogram MMS and is available only in the usage report. MMS data is available at 10-minute intervals.
+* The number of billed Troubleshooting MetricSets (TMS). TMS data is available per minute and has a look-back period of 1 minute. 
+* The number of billed Monitoring MetricSets (MMS). MMS data is available only for histogram MMS and is available only in the usage report. MMS data is available at 10-minute intervals and has a look-back period of 1 hour. 
 * The average number of hosts. Averages are available in usage reports for complete months only.
 * The average number of containers. Averages are available in usage reports for complete months only.
 * The average number of Troubleshooting MetricSets. Averages are available in usage reports for complete months only.
@@ -141,8 +141,8 @@ Usage reports for TAPM subscription plans include the following information abou
 
 * The number of billed TAPM. TAPM data is available per minute.
 * The billed trace volume. Trace volume data is available per minute.
-* The number of billed Troubleshooting MetricSets (TMS). TMS data is available per minute. 
-* The number of billed Monitoring MetricSets (MMS). MMS data is available only for histogram MMS and is available only in the usage report. MMS data is available at 10-minute intervals.
+* The number of billed Troubleshooting MetricSets (TMS). TMS data is available per minute and has a look-back period of 1 minute. 
+* The number of billed Monitoring MetricSets (MMS). MMS data is available only for histogram MMS and is available only in the usage report. MMS data is available at 10-minute intervals and has a look-back period of 1 hour. 
 * The average number of TAPM. Averages are available in usage reports for complete months only.
 * The average number of Troubleshooting MetricSets. Averages are available in usage reports for complete months only.
 * The average number of Monitoring MetricSets. Averages are available in usage reports for complete months only.
@@ -245,11 +245,11 @@ The following metrics power the charts in your APM Subscription Usage page with
 
    * - ``sf.org.apm.numTroubleshootingMetricSets``
      - Troubleshooting MetricSets
-     - The cardinality of Troubleshooting MetricSets for each 1-minute window.
+     - The cardinality of Troubleshooting MetricSets. TMS data is available per minute and has a look-back period of 1 minute.
 
    * - ``sf.org.apm.numMonitoringMetricSets``
      - Monitoring MetricSets
-     - The cardinality of Monitoring MetricSets for each 10-minute window.
+     - The cardinality of Monitoring MetricSets. MMS data is available only for histogram MMS. MMS data is available at 10-minute intervals and has a look-back period of 1 hour. 
 
 .. _host_subscription_plans:
 
@@ -280,10 +280,10 @@ The following metrics power the charts in your APM Subscription Usage page with
 
    * - ``sf.org.apm.numTroubleshootingMetricSets``
      - Troubleshooting MetricSets
-     - The cardinality of Troubleshooting MetricSets for each 1-minute window.
+     - The cardinality of Troubleshooting MetricSets. TMS data is available per minute and has a look-back period of 1 minute.
 
    * - ``sf.org.apm.numMonitoringMetricSets``
      - Monitoring MetricSets
-     - The cardinality of Monitoring MetricSets for each 10-minute window.
+     - The cardinality of Monitoring MetricSets. MMS data is available only for histogram MMS. MMS data is available at 10-minute intervals and has a look-back period of 1 hour. 
 
 To see all of the organization metrics for APM, see :ref:`org-metrics`.

gdi/get-data-in/connect/aws/aws-prereqs.rst

@@ -98,6 +98,7 @@ Regardless of the services you want to use, you need the following permissions:
 
 * ``organizations:DescribeOrganization``. Only needed when Amazon cost and usage metrics are activated.
 * ``ec2:DescribeRegions``. Used to check if regions configured in the integration are enabled on the AWS account.
+* ``iam:ListAccountAliases``. Used to sync account aliases for AWS MTS.
 
 Tag and property sync permissions:
 

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

@@ -55,54 +55,65 @@ For more information, refer to Google's official announcement :new-page:`Introdu
       <h3>Select a role for your GCP service account<a name="gcp-one" class="headerlink" href="#gcp-one" title="Permalink to this headline">¶</a></h3>
    </embed>
 
-If you use GCP's :strong:`Project Viewer` role, you won't require any changes to your GCP setup to use Splunk Observability Cloud, and any update will be applied automatically. 
+You can use GCP's :strong:`Viewer` role as it comes with the permissions you need for most scenarios. 
 
-If you want to use a more restrictive role than Project Viewer, make sure your selected role has sufficient permissions to connect to Splunk Observability Cloud, otherwise you'll get an error message when trying to connect. Review and activate any missing permissions, or change the role to Project Viewer.
-
-The following table specifies the permissions required for GCP integrations:
+Alternatively you can create a more restrictive role using the permissions in the table:
 
 .. list-table::
    :header-rows: 1
-   :widths: 40 60
+   :widths: 35 45 20
 
    *  - :strong:`Permission`
       - :strong:`Required?`
+      - :strong:`Included in GCP's Viewer role?`
 
    *  - ``compute.instances.list``
       - Yes, if the Compute Engine service is activated
+      - Yes
 
    *  - ``compute.machineTypes.list``
       - Yes, if the Compute Engine service is activated
+      - Yes
 
    *  - ``container.clusters.list``
       - Yes, if the Kubernetes (GKE) service is activated
+      - Yes
 
    *  - ``container.nodes.list``
       - Yes, if the Kubernetes (GKE) service is activated
+      - Yes
 
    *  - ``container.pods.list``
       - Yes, if the Kubernetes (GKE) service is activated
+      - Yes
 
    *  - ``monitoring.metricDescriptors.get``
       - Yes
+      - Yes
 
    *  - ``monitoring.metricDescriptors.list``
       - Yes
+      - Yes
 
    *  - ``monitoring.timeSeries.list``
       - Yes
+      - Yes
 
    *  - ``resourcemanager.projects.get``
       - Yes, if you want to sync project metadata (such as labels)
+      - Yes
 
    *  - ``serviceusage.services.use``
       - Yes, if you want to activate the use of a quota from the project where metrics are stored
+      - No, but included in ``roles/serviceusage.serviceUsageConsumer``
 
    *  - ``spanner.instances.list``
       - Yes, if the Spanner service is activated
+      - Yes
 
    *  - ``storage.buckets.list``
       - Yes, if the Spanner service is activated
+      - Yes
 
 .. _gcp-two:
 

gdi/opentelemetry/components/jmx-receiver.rst

@@ -9,9 +9,14 @@ JMX receiver
 
 The JMX receiver works in conjunction with the :new-page:`OpenTelemetry JMX Metric Gatherer <https://github.com/open-telemetry/opentelemetry-java-contrib/blob/main/jmx-metrics/README.md>` to report metrics from an MBean server. The supported pipeline type is ``metrics``. See :ref:`otel-data-processing` for more information.
 
+You can use the JMX receiver to monitor services such as Cassandra using the ``target_system`` setting. See more at :ref:`jmx-receiver-advanced` and :ref:`jmx-receiver-settings`. 
+
 .. note:: Out-of-the-box dashboards and navigators aren't supported for the JMX receiver yet, but are planned for a future release.
 
-This receiver launches a child JRE process which runs the JMX Metric Gatherer configured with your specified JMX connection information and target built-in OTel-helper Groovy script. It then reports metrics to an implicitly created OTLP receiver. 
+Prerequisites
+======================
+
+The receiver launches a child JRE process which runs the JMX Metric Gatherer configured with your specified JMX connection information and target built-in OTel-helper Groovy script. It then reports metrics to an implicitly created OTLP receiver. 
 
 In order to use the JMX receiver:
 
@@ -77,7 +82,9 @@ This examples provides configuration details for the receiver:
       log_level: info
       additional_jars:
         - /path/to/other.jar
-  
+
+.. _jmx-receiver-advanced:
+
 Advanced settings
 -----------------------------------------------
 
@@ -98,7 +105,9 @@ You can use the following advanced settings with the receiver:
 
 * ``target_system``. The built-in target system (or systems) metric gatherer script to run. 
 
-  * Must be a subset of: ``"activemq"``, ``"cassandra"``, ``"hbase"``, ``"hadoop"``, ``"jetty"``, ``"jvm"``, ``"kafka"``, ``"kafka-consumer"``, ``"kafka-producer"``, ``"solr"``, ``"tomcat"``, or ``"wildfly"``. 
+  * Possible values: ``"activemq"``, ``"cassandra"``, ``"hbase"``, ``"hadoop"``, ``"jetty"``, ``"jvm"``, ``"kafka"``, ``"kafka-consumer"``, ``"kafka-producer"``, ``"solr"``, ``"tomcat"``, or ``"wildfly"``. 
+
+  * You can specify multiple target systems at the same time: ``"target_system": "activemq, kafka,kafka-consumer"``. 
 
   * If you need to support additional target systems because of a custom JMX metrics gatherer jar configured using the ``MetricsGathererHash`` build time config, add them with another build time flag. It corresponds to the ``otel.jmx.target.system`` property.