Merge pull request #1506 from splunk/repo-sync

Pulling refs/heads/main into main

Author: aurbiztondo-splunk

gdi/monitors-hosts/kafka-consumer.rst

@@ -6,19 +6,15 @@ Kafka consumer
 .. meta::
    :description: Use this Splunk Observability Cloud integration for the Collectd Java-based Kafka consumer monitor. See benefits, install, configuration, and metrics
 
-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. It has a set of built-in MBeans to pull metrics from the Kafka
-consumer's JMX endpoint.
+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`.
 
-This integration is only available on Kubernetes and Linux. It requires
-Kafka version 0.9.0.0 or higher and collects metrics from the new
-consumer API. Per-topic metrics are not available through the new
-consumer API in version 0.9.0.0 or lower, which can cause the logs to
-fill with warnings related to the MBean not being found. Use the
-``mBeansToOmit`` config option in such cases.
+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.
+
+This integration is only available on Kubernetes and Linux, and requires Kafka version 0.9.0.0 or higher. 
+
+Per-topic metrics are not available through the new consumer API in version 0.9.0.0 or lower, which can cause the logs to fill with warnings related to the MBean not being found. Use the ``mBeansToOmit`` config option in such cases.
 
 Benefits
 --------

gdi/monitors-hosts/kafka-producer.rst

@@ -6,16 +6,13 @@ Kafka producer
 .. meta::
    :description: Use this Splunk Observability Cloud integration for the Collectd Java-based Kafka producer monitor. See benefits, install, configuration, and metrics
 
-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. It has a set of built-in MBeans to pull metrics from the Kafka
-consumer's JMX endpoint.
+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`.
 
-This integration is only available on Kubernetes and Linux. It requires
-Kafka version 0.9.0.0 or higher and collects metrics from the new
-producer API.
+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.
+
+This integration is only available on Kubernetes and Linux, and requires Kafka version 0.9.0.0 or higher. 
 
 Benefits
 --------

gdi/monitors-languages/genericjmx.rst

@@ -6,12 +6,10 @@ GenericJMX
 .. meta::
    :description: Use this Splunk Observability Cloud integration for the GenericJMX monitor. See benefits, install, configuration, and metrics
 
-The Splunk Distribution of OpenTelemetry Collector uses the Smart Agent receiver with the
-``genericjmx`` monitor to expose metrics on Java Management Extensions
-(JMX), a generic framework to provide and query management information.
-The interface is used by the Java Virtual Machine (JVM) to provide
-information about the memory used and threads. For a more flexible
-alternative, use :ref:`the JMX monitor <genericjmx>`
+The Splunk Distribution of the OpenTelemetry Collector uses the Smart Agent receiver with the ``genericjmx`` monitor to expose metrics on Java Management Extensions (JMX), a generic framework to provide and query management information. The interface is used by the Java Virtual Machine (JVM) to provide
+information about the memory used and threads. For a more flexible alternative, use :ref:`the JMX monitor <genericjmx>`.
+
+.. note:: To monitor JMX with the OpenTelemetry Collector using native OpenTelemetry components refer to the :ref:`jmx-receiver`.
 
 This integration is only available on Kubernetes and Linux.
 

gdi/monitors-languages/jmx.rst

@@ -6,16 +6,15 @@ JMX
 .. meta::
    :description: Use this Splunk Observability Cloud integration for the JMX monitor. See benefits, install, configuration, and metrics. Run an arbitrary Groovy script to convert JMX MBeans fetched from a remote Java application to SignalFx data points
 
-The Splunk Distribution of OpenTelemetry Collector uses the Smart Agent receiver with the
-``jmx`` monitor type to run an arbitrary Groovy script to convert JMX
-MBeans fetched from a remote Java application to SignalFx data points.
-This is a more flexible alternative to the
-:ref:`GenericJMX <genericjmx>` monitor.
+The Splunk Distribution of the OpenTelemetry Collector uses the Smart Agent receiver with the ``jmx`` monitor type to run an arbitrary Groovy script to convert JMX MBeans fetched from a remote Java application to SignalFx data points. This is a more flexible alternative to the :ref:`GenericJMX <genericjmx>` monitor.
 
-.. note:: If you are instrumenting an application with the Splunk Distribution of OpenTelemetry Java, you can capture metrics with the Java agent instead of using a JMX monitor. To learn more, see :ref:`enable_automatic_metric_collection`
+.. note:: 
+   
+   To monitor JMX with the OpenTelemetry Collector using native OpenTelemetry components refer to the :ref:`jmx-receiver`.
 
-You can use the following utility helpers in the Groovy script within
-the ``util`` variable, which is set in the script's context:
+   If you are instrumenting an application with the Splunk Distribution of OpenTelemetry Java, you can capture metrics with the Java agent instead of using a JMX monitor. To learn more, see :ref:`enable_automatic_metric_collection`.
+
+You can use the following utility helpers in the Groovy script within the ``util`` variable, which is set in the script's context:
 
 -  ``util.queryJMX(String objectName)``: This helper queries the
    configured JMX application for the given ``objectName``, which can

gdi/monitors-messaging/apache-kafka.rst

@@ -1,27 +1,24 @@
 .. _kafka:
 
-Apache Kafka
+Kafka
 ============
 
 .. meta::
    :description: Use this Splunk Observability Cloud integration for the Kafka monitor. See benefits, install, configuration, and metrics
 
-The Splunk Distribution of OpenTelemetry Collector uses the Smart Agent receiver with the
-Apache Kafka monitor type to monitor Kafka instances.
+The Splunk Distribution of the OpenTelemetry Collector uses the Smart Agent receiver with the Kafka monitor type to monitor Kafka instances using collectd's GenericJMX plugin. 
 
-This integration is only available on Kubernetes and Linux.
+.. note:: To monitor Kafka with the OpenTelemetry Collector using native OpenTelemetry components refer to the :ref:`kafkametrics-receiver`.
 
-This integration supports Kafka v0.8.2.x and above.
+This integration has a set of built-in MBeans to pull metrics from the Kafka's JMX endpoint. For more information, see :new-page:`Kafka producer MBeans <https://github.com/signalfx/signalfx-agent/tree/main/pkg/monitors/collectd/kafka/mbeans.go>` in GitHub.
 
-For Kafka v1.x.x and above, on top of default metrics, monitor the
-following:
+This integration is only available on Kubernetes and Linux, and supports Kafka v0.8.2.x and higher.
 
--  ``kafka.server:type=ZooKeeperClientMetrics,name=ZooKeeperRequestLatencyMs``
-   to track how long brokers wait for requests to Zookeeper to be
-   completed.
--  Disk utilization and network metrics of the underlying host. Since
-   Zookeeper is an integral part of a Kafka cluster, you can monitor it
-   using the Zookeeper monitor.
+For Kafka v1.x.x and higher monitor the following:
+
+* ``kafka.server:type=ZooKeeperClientMetrics,name=ZooKeeperRequestLatencyMs`` to track how long brokers wait for requests to Zookeeper to be completed.
+* Disk utilization and network metrics of the underlying host. 
+* Since Zookeeper is an integral part of a Kafka cluster, you can monitor it using the :ref:`Zookeeper integration <zookeeper>`.
 
 Benefits
 --------
@@ -38,10 +35,10 @@ Configuration
 
 .. include:: /_includes/configuration.rst
 
-### Example
+Example
+~~~~~~~~~~~~~~
 
-To activate this integration, add the following to your Collector
-configuration:
+To activate this integration, add the following to your Collector configuration:
 
 .. code-block:: yaml
 
@@ -61,241 +58,13 @@ section of your configuration file:
          receivers: [smartagent/kafka]
 
 See configuration examples for specific use cases that show how the
-Splunk Distribution of OpenTelemetry Collector can integrate and
+Splunk Distribution of the OpenTelemetry Collector can integrate and
 complement existing environments.
 
 Configuration settings
 ~~~~~~~~~~~~~~~~~~~~~~
 
-The following table shows the configuration options for this monitor:
-
-.. list-table::
-   :widths: 18 18 18 18
-   :header-rows: 1
-
-   - 
-
-      - Option
-      - Required
-      - Type
-      - Description
-   - 
-
-      - ``host``
-      - **yes**
-      - ``string``
-      - Host to connect to – JMX must be configured for remote access
-         and accessible from the agent
-   - 
-
-      - ``port``
-      - **yes**
-      - ``integer``
-      - JMX connection port (NOT the RMI port) on the application. This
-         corresponds to the ``com.sun.management.jmxremote.port`` Java
-         property that should be set on the JVM when running the
-         application.
-   - 
-
-      - ``name``
-      - no
-      - ``string``
-      - 
-   - 
-
-      - ``serviceName``
-      - no
-      - ``string``
-      - This is how the service type is identified in the Splunk
-         Splunk Observability Cloud UI so that you can get built-in content for
-         it. For custom JMX integrations, it can be set to whatever you
-         like.
-   - 
-
-      - ``serviceURL``
-      - no
-      - ``string``
-      - The JMX connection string. This is rendered as a Go template and
-         has access to the other values in this config. NOTE: under
-         normal circumstances it is not advised to set this string
-         directly - setting the host and port as specified above is
-         preferred. (**default:**
-         ``service:jmx:rmi:///jndi/rmi://{{.Host}}:{{.Port}}/jmxrmi``)
-   - 
-
-      - ``instancePrefix``
-      - no
-      - ``string``
-      - Prefixes the generated plugin instance with prefix. If a second
-         ``instancePrefix`` is specified in a referenced MBean block,
-         the prefix specified in the Connection block will appear at the
-         beginning of the plugin instance, and the prefix specified in
-         the MBean block will be appended to it.
-   - 
-
-      - ``username``
-      - no
-      - ``string``
-      - Username to authenticate to the server
-   - 
-
-      - ``password``
-      - no
-      - ``string``
-      - User password to authenticate to the server
-   - 
-
-      - ``customDimensions``
-      - no
-      - ``map of strings``
-      - Takes in key-value pairs of custom dimensions at the connection
-         level.
-   - 
-
-      - ``mBeansToCollect``
-      - no
-      - ``list of strings``
-      - A list of the MBeans defined in ``mBeanDefinitions`` to actually
-         collect. If not provided, then all defined MBeans will be
-         collected.
-   - 
-
-      - ``mBeansToOmit``
-      - no
-      - ``list of strings``
-      - A list of the MBeans to omit. This will come in handy in cases
-         where only a few MBeans need to be omitted from the default
-         list.
-   - 
-
-      - ``mBeanDefinitions``
-      - no
-      - ``map of objects (see below)``
-      - 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 will be merged with those. To learn more, see the :new-page:`Collectd documentation <https://www.collectd.org/documentation/manpages/collectd-java.html>`.
-   - 
-
-      - ``clusterName``
-      - **yes**
-      - ``string``
-      - Cluster name to which the broker belongs
-
-The **nested** ``mBeanDefinitions`` configuration object has the
-following fields:
-
-.. list-table::
-   :widths: 18 18 18 18
-   :header-rows: 1
-
-   - 
-
-      - Option
-      - Required
-      - Type
-      - Description
-   - 
-
-      - ``objectName``
-      - no
-      - ``string``
-      - Sets the pattern used to retrieve MBeans from the MBeanServer.
-         If more than one MBean is returned, you should use the
-         ``instanceFrom`` option to make the identifiers unique.
-   - 
-
-      - ``instancePrefix``
-      - no
-      - ``string``
-      - Prefixes the generated plugin instance with prefix
-   - 
-
-      - ``instanceFrom``
-      - no
-      - ``list of strings``
-      - The object names used by JMX to identify MBeans include
-         so-called “properties” which are basically key-value pairs. If
-         the given object name is not unique and multiple MBeans are
-         returned, the values of those properties usually differ. You
-         can use this option to build the plugin instance from the
-         appropriate property values. This option is optional and can be
-         repeated to generate the plugin instance from multiple property
-         values.
-   - 
-
-      - ``values``
-      - no
-      - ``list of objects (see below)``
-      - The ``value`` blocks map one or more attributes of an MBean to a
-         value list. There must be at least one ``value`` block within
-         each MBean block.
-   - 
-
-      - ``dimensions``
-      - no
-      - ``list of strings``
-      - 
-
-The **nested** ``values`` configuration object has the following fields:
-
-.. list-table::
-   :widths: 18 18 18 18
-   :header-rows: 1
-
-   - 
-
-      - Option
-      - Required
-      - Type
-      - Description
-   - 
-
-      - ``type``
-      - no
-      - ``string``
-      - Sets the data set used to handle the values of the MBean
-         attribute
-   - 
-
-      - ``table``
-      - no
-      - ``bool``
-      - Set this to ``true`` if the returned attribute is a composite
-         type. If set to ``true``, the keys within the composite type
-         are appended to the type instance. (**default:** ``false``)
-   - 
-
-      - ``instancePrefix``
-      - no
-      - ``string``
-      - Works like the option of the same name directly beneath the
-         MBean block, but sets the type instance instead
-   - 
-
-      - ``instanceFrom``
-      - no
-      - ``list of strings``
-      - Works like the option of the same name directly beneath the
-         MBean block, but sets the type instance instead
-   - 
-
-      - ``attribute``
-      - no
-      - ``string``
-      - Sets the name of the attribute from which to read the value. You
-         can access the keys of composite types by using a dot to
-         concatenate the key name to the attribute name. For example,
-         “attrib0.key42”. If ``table`` is set to ``true``, path must
-         point to a composite type, otherwise it must point to a numeric
-         type.
-   - 
-
-      - ``attributes``
-      - no
-      - ``list of strings``
-      - The plural form of the ``attribute`` configuration above. Used
-         to derive multiple metrics from a single MBean.
+See Settings in :ref:`genericjmx`.
 
 Metrics
 -------