Fixes

aurbiztondo-splunk · aurbiztondo-splunk · commit 1223c9ab5ad4 · 2024-10-04T12:33:44.000+02:00
diff --git a/admin/notif-services/splunkplatform.rst b/admin/notif-services/splunkplatform.rst
@@ -51,7 +51,7 @@ Step 1: Create a Splunk platform integration in Splunk Observability Cloud
         - Enter the HTTP Event Collector (HEC) URI for your Splunk platform instance. To learn more, see the :new-page:`Send data to HTTP Event Collector <https://docs.splunk.com/Documentation/SplunkCloud/9.1.2312/Data/UsetheHTTPEventCollector#Send_data_to_HTTP_Event_Collector>` section in the *Documentation for Splunk Cloud Platform*.
 
       * - HEC token
-        - Enter the HTTP Event Collector token that allows access to your Splunk platform instance. To learn more, see :new-page:`Set up and use HTTP Event Collector in Splunk Web <https://docs.splunk.com/Documentation/SplunkCloud/9.2.2403/Data/UsetheHTTPEventCollector>`.
+        - Enter the HTTP Event Collector token that allows access to your Splunk platform instance. To learn more, see :new-page:`Set up and use HTTP Event Collector <https://docs.splunk.com/Documentation/SplunkCloud/9.2.2403/Data/UsetheHTTPEventCollector>` in Splunk Web .
           
    .. note:: Splunk Observability Cloud doesn't support HEC indexer acknowledgement. To use the Splunk platform integration, don't activate indexer acknowledgement for HEC token in your Splunk Enterprise instance.
 
diff --git a/admin/notif-services/webhook.rst b/admin/notif-services/webhook.rst
@@ -42,7 +42,7 @@ the request to your webhook is secure and valid.
 
 To learn more about the shared secret string, the cryptographic algorithm, and the message code, see the
 :new-page:`Shared secret <https://dev.splunk.com/observability/docs/integrations/webhook_integration_overview/#Shared-secret>` section in
-the :emphasis:`Splunk Observability Cloud Developers Guide`.
+the :emphasis:`Splunk Observability Cloud Developers Guide` docs.
 
 Your webhook must return a HTTP ``200 OK`` response code immediately after you receive the request.
 If Splunk Observability Cloud does not receive a 200 response code within a certain time frame, it retries the request.
diff --git a/gdi/monitors-cloud/heroku.rst b/gdi/monitors-cloud/heroku.rst
@@ -12,7 +12,7 @@ and runs the Splunk OpenTelemetry Connector on a Dyno to receive, process and ex
 -  Splunk APM through the ``sapm`` exporter. The ``otlphttp`` exporter can be used with a custom configuration.
 -  Splunk Infrastructure Monitoring through the ``signalfx`` exporter.
 
-To learn more about the Splunk Distribution of the OpenTelemetry Collector, see :ref:`otel-intro`.
+See :ref:`otel-intro` to learn more.
 
 Prerequisites
 ----------------
diff --git a/gdi/monitors-cloud/kong.rst b/gdi/monitors-cloud/kong.rst
@@ -31,8 +31,8 @@ In addition, the integration provides system-wide connection statistics, includi
 
 To learn more: 
 
-* About the Kong metrics Prometheus endpoint, see the official :new-page:`Kong documentation on Prometheus <https://docs.konghq.com/hub/kong-inc/prometheus>`. 
-* About using the Prometheus receiver to monitor applications, see :ref:`prometheus-generic`.
+* About the Kong metrics Prometheus endpoint, see the official :new-page:`Kong documentation <https://docs.konghq.com/hub/kong-inc/prometheus>` on Prometheus. 
+* About using the Prometheus receiver to monitor applications, see the :ref:`prometheus-generic` doc.
 
 Benefits
 --------
diff --git a/gdi/monitors-cloudfoundry/cloudfoundry-firehose-nozzle.rst b/gdi/monitors-cloudfoundry/cloudfoundry-firehose-nozzle.rst
@@ -8,7 +8,7 @@ Cloud Foundry Loggregator Firehose
 
 The Splunk Distribution of the OpenTelemetry Collector uses the Smart Agent receiver with the Cloud Foundry Loggregator Firehose monitor type to create a Cloud Foundry Firehose nozzle which connects to the Cloud Foundry Reverse Log Proxy (RLP) Gateway to extract metrics from Loggregator. 
 
-.. note:: To monitor Cloud Foundry with the OpenTelemetry Collector using native OpenTelemetry components refer to the :ref:`cloudfoundry-receiver`.
+.. note:: To monitor Cloud Foundry with the OpenTelemetry Collector using native OpenTelemetry refer to the :ref:`cloudfoundry-receiver` component.
 
 The following applies:
 
diff --git a/gdi/monitors-databases/microsoft-sql-server.rst b/gdi/monitors-databases/microsoft-sql-server.rst
@@ -11,7 +11,7 @@ The Splunk Distribution of the OpenTelemetry Collector uses the Smart Agent rece
 Microsoft SQL Server monitor type to send metrics from Microsoft SQL
 Server instances.
 
-.. note:: To monitor Microsoft SQL server instances with the OpenTelemetry Collector using native OpenTelemetry components refer to the :ref:`mssql-server-receiver`.
+.. note:: To monitor Microsoft SQL server instances with the OpenTelemetry Collector using native OpenTelemetry refer to the :ref:`mssql-server-receiver` component.
 
 Benefits
 =================
diff --git a/gdi/monitors-databases/mongodb.rst b/gdi/monitors-databases/mongodb.rst
@@ -8,7 +8,7 @@ MongoDB (deprecated)
 
 .. note:: The MongoDB monitor is deprecated and will reach end of support on January 15, 2025. During this period, only critical security and bug fixes are provided. When the monitor reaches end of support, you won't be able to use it to send data to Splunk Observability Cloud.
 
-   To monitor your MongoDB databases, you can instead use the native OpenTelemetry MongoDB receiver. To learn more, see :ref:`mongodb-receiver`.
+   To monitor your MongoDB databases, you can instead use the native OpenTelemetry MongoDB receiver. See :ref:`mongodb-receiver` to learn more.
 
 The
 :ref:`Splunk Distribution of the OpenTelemetry Collector <otel-intro>`
diff --git a/gdi/monitors-databases/mysql.rst b/gdi/monitors-databases/mysql.rst
@@ -10,7 +10,7 @@ MySQL (deprecated)
    
    The MySQL monitor is now deprecated and will reach of End of Support on October 31st, 2024. During this period only critical security and bug fixes are provided. When End of Support is reached, the monitor will be removed and no longer be supported, and you won't be able to use it to send data to Splunk Observability Cloud. 
 
-   To monitor your MySQL databases you can use the native OpenTelemetry MySQL receiver instead. See more at :ref:`MySQL receiver <mysql-receiver>`. 
+   To monitor your MySQL databases you can use the native OpenTelemetry MySQL receiver instead. See :ref:`MySQL receiver <mysql-receiver>` to learn more. 
 
 The :ref:`Splunk Distribution of the OpenTelemetry Collector <otel-intro>` uses the :ref:`Smart Agent receiver <smartagent-receiver>` with the MySQL monitor type to retrieve metrics and logs from MySQL.
 
diff --git a/gdi/monitors-databases/postgresql.rst b/gdi/monitors-databases/postgresql.rst
@@ -10,7 +10,7 @@ PostgreSQL (deprecated)
    
    The PostgreSQL monitor is now deprecated and will reach of End of Support on October 31st, 2024. During this period only critical security and bug fixes are provided. When End of Support is reached, the monitor will be removed and no longer be supported, and you won't be able to use it to send data to Splunk Observability Cloud. 
 
-   To monitor your PostgreSQL databases you can use the native OpenTelemetry PostgreSQL receiver instead. See more at :ref:`postgresql-receiver`.
+   To monitor your PostgreSQL databases you can use the native OpenTelemetry PostgreSQL receiver instead. See :ref:`postgresql-receiver` to learn more.
 
 The Splunk Distribution of the OpenTelemetry Collector uses the Smart Agent receiver with the ``postgresql`` monitor type to pull metrics from all PostgreSQL databases from a specific Postgres server instance using SQL queries.
 
diff --git a/gdi/monitors-databases/redis.rst b/gdi/monitors-databases/redis.rst
@@ -8,7 +8,7 @@ Redis (deprecated)
 
 .. note:: The Redis monitor is deprecated and will reach end of support on January 15, 2025. During this period, only critical security and bug fixes are provided. When the monitor reaches end of support, you won't be able to use it to send data to Splunk Observability Cloud.
 
-   To monitor your Redis databases, you can instead use the native OpenTelemetry Redis receiver. To learn more, see :ref:`redis-receiver`.
+   To monitor your Redis databases, you can instead use the native OpenTelemetry Redis receiver. See :ref:`redis-receiver` to learn more.
 
 The Splunk Distribution of the OpenTelemetry Collector uses the Smart Agent receiver with the ``redis`` monitor type to capture the following metrics:
 
diff --git a/gdi/monitors-databases/sql.rst b/gdi/monitors-databases/sql.rst
@@ -6,7 +6,7 @@ SQL
 .. meta::
    :description: Use this Splunk Observability Cloud integration for the SQL monitor. See benefits, install, configuration, and metrics
 
-.. note:: If you're using the Splunk Distribution of the OpenTelemetry Collector and want to collect SQL metrics, use the native OTel component :ref:`sqlquery-receiver`.
+.. note:: If you're using the Splunk Distribution of the OpenTelemetry Collector and want to collect SQL metrics, use the native OTel :ref:`sqlquery-receiver` component.
 
 The SQL monitor gathers database usage metrics from SQL queries on your databases. It's available for Kubernetes, Windows, and Linux.
 
diff --git a/gdi/monitors-hosts/apache-httpserver.rst b/gdi/monitors-hosts/apache-httpserver.rst
@@ -8,7 +8,7 @@ Apache HTTP Server
 
 The Splunk Distribution of the OpenTelemetry Collector uses the Smart Agent receiver with the Apache HTTP Server monitor type to monitor Apache web servers using information ``mod_status`` provides. 
 
-.. note:: To monitor Apache web server instances with the OpenTelemetry Collector using native OpenTelemetry components refer to the :ref:`apache-receiver`.
+.. note:: Refer to the :ref:`apache-receiver` to monitor Apache web server instances with the OpenTelemetry Collector using native OpenTelemetry components.
 
 Apache worker threads can be in one of the following states:
 
diff --git a/gdi/monitors-hosts/apache-tomcat.rst b/gdi/monitors-hosts/apache-tomcat.rst
@@ -160,7 +160,7 @@ integration:
       - Specifies how to map JMX MBean values to metrics. If using a
          specific service monitor such as Cassandra, Kafka, or ActiveMQ,
          they come pre-loaded with a set of mappings, and any that you
-         add in this option are merged with those. To learn more, see the :new-page:`Collectd documentation <https://www.collectd.org/documentation/manpages/collectd-java.html>`.
+         add in this option are merged with those. See the :new-page:`Collectd documentation <https://www.collectd.org/documentation/manpages/collectd-java.html>` to learn more.
 
 The **nested** ``mBeanDefinitions`` configuration object has the
 following fields:
diff --git a/gdi/monitors-hosts/jenkins.rst b/gdi/monitors-hosts/jenkins.rst
@@ -15,7 +15,7 @@ hitting the following endpoints:
 
 This integration is only available on Kubernetes and Linux.
 
-.. note:: The Jenkins integration requires Jenkins version 1.580.3 or higher and the :new-page:`Jenkins Metrics plugin <https://plugins.jenkins.io/metrics/>`.
+.. note:: The Jenkins integration requires Jenkins version 1.580.3 or higher and the :new-page:`Jenkins Metrics <https://plugins.jenkins.io/metrics/>` plugin.
 
 Benefits
 --------
diff --git a/gdi/monitors-hosts/kafka-consumer.rst b/gdi/monitors-hosts/kafka-consumer.rst
@@ -8,7 +8,7 @@ Kafka consumer
 
 The Splunk Distribution of the OpenTelemetry Collector uses the Smart Agent receiver with the ``collectd/kafka_consumer`` monitor type to monitor a Java-based Kafka consumer. 
 
-.. note:: To monitor Kafka with the OpenTelemetry Collector using native OpenTelemetry components refer to the :ref:`kafkametrics-receiver`.
+.. note:: To monitor Kafka with the OpenTelemetry Collector using native OpenTelemetry components refer to the :ref:`kafkametrics-receiver` component.
 
 This integration has a set of built-in MBeans to pull metrics from the Kafka consumer's JMX endpoint. For more information, see :new-page:`Kafka consumer MBeans <https://github.com/signalfx/signalfx-agent/tree/main/pkg/monitors/collectd/kafkaconsumer/mbeans.go>` in GitHub.
 
diff --git a/gdi/monitors-hosts/kafka-producer.rst b/gdi/monitors-hosts/kafka-producer.rst
@@ -8,7 +8,7 @@ Kafka producer
 
 The Splunk Distribution of the OpenTelemetry Collector uses the Smart Agent receiver with the ``collectd/kafka_producer`` monitor type to monitor a Java-based Kafka producer.  
 
-.. note:: To monitor Kafka with the OpenTelemetry Collector using native OpenTelemetry components refer to the :ref:`kafkametrics-receiver`.
+.. note:: To monitor Kafka with the OpenTelemetry Collector using native OpenTelemetry components refer to the :ref:`kafkametrics-receiver` component.
 
 This integration has a set of built-in MBeans to pull metrics from the Kafka producer's JMX endpoint. For more information, see :new-page:`Kafka producer MBeans <https://github.com/signalfx/signalfx-agent/tree/main/pkg/monitors/collectd/kafkaproducer/mbeans.go>` in GitHub.
 
diff --git a/gdi/monitors-hosts/nginx.rst b/gdi/monitors-hosts/nginx.rst
@@ -10,7 +10,7 @@ The Splunk Distribution of the OpenTelemetry Collector uses the Smart Agent rece
 
 This integration is available on Linux and Windows.
 
-.. note:: To monitor NGINX instances with the OpenTelemetry Collector using native OpenTelemetry components refer to the :ref:`nginx-receiver`.
+.. note:: To monitor NGINX instances with the OpenTelemetry Collector using native OpenTelemetry refer to the :ref:`nginx-receiver` component.
 
 Benefits
 --------
diff --git a/gdi/monitors-languages/expvar.rst b/gdi/monitors-languages/expvar.rst
@@ -6,7 +6,7 @@ Expvar (Go)
 .. meta::
    :description: Use this Splunk Observability Cloud integration for the Golang Expvar monitor. See benefits, install, configuration, and metrics".
 
-The :ref:`Splunk Distribution of OpenTelemetry Collector <otel-intro>` uses the :ref:`Smart Agent receiver <smartagent-receiver>` with the ``expvar`` monitor type to scrape metrics exposed by :new-page:`expvar <https://golang.org/pkg/expvar/>`.
+The :ref:`Splunk Distribution of OpenTelemetry Collector <otel-intro>` uses the :ref:`Smart Agent receiver <smartagent-receiver>` with the ``expvar`` monitor type to scrape metrics exposed Expvar. See :new-page:`expvar <https://golang.org/pkg/expvar/>` to learn more.
 
 The integration uses configured paths to get metric and dimension values from fetched JSON objects at an HTTP endpoint. The Metrics section in this document shows metrics derived from expvar variable :new-page:`memstats <https://golang.org/pkg/runtime/>`, which is exposed by default. These ``memstat`` metrics are referred to as standard or default metrics.
 
diff --git a/gdi/monitors-messaging/rabbitmq.rst b/gdi/monitors-messaging/rabbitmq.rst
@@ -8,7 +8,7 @@ RabbitMQ
 
 The Splunk Distribution of the OpenTelemetry Collector uses the Smart Agent receiver with the ``rabbitmq`` monitor type to keep track of an instance of RabbitMQ.
 
-.. note:: To monitor RabbitMQ instances with the OpenTelemetry Collector using native OpenTelemetry components refer to the :ref:`rabbitmq-receiver`.
+.. note:: To monitor RabbitMQ instances with the OpenTelemetry Collector using native OpenTelemetry refer to the :ref:`rabbitmq-receiver` component.
 
 The integration uses the RabbitMQ Python plugin and the RabbitMQ
 Management HTTP API to poll for statistics on a RabbitMQ server, then
diff --git a/gdi/monitors-prometheus/prometheus-generic.rst b/gdi/monitors-prometheus/prometheus-generic.rst
@@ -7,7 +7,7 @@ Configure applications with Prometheus metrics
 .. meta::
       :description: Use the Prometheus receiver to retrieve metrics in Prometheus format from any compatible service. 
 
-The Prometheus receiver allows the Splunk Distribution of the OpenTelemetry Collector to collect metrics from any source exposing telemetry in Prometheus format. See more at :ref:`prometheus-receiver`.
+The Prometheus receiver allows the Splunk Distribution of the OpenTelemetry Collector to collect metrics from any source exposing telemetry in Prometheus format. See :ref:`prometheus-receiver` to learn more.
 
 Benefits
 ========================
