3.2.5. RTI Connext Observability Framework

3.2.5.1. Monitoring Library 2.0 incompatible with earlier Collector Service versions

Connext 7.7 applications using Monitoring Library 2.0 are not compatible with Collector Service from earlier releases (for example, release 7.3.1). RTI does not plan to change this behavior in future releases.

To ensure compatibility, use a Collector Service version that matches, or is newer than, the Connext application version. For example, to collect data from 7.3.1, use Collector Service 7.3.1 or 7.7.0; you cannot use Collector Service 7.3.1 to collect data from Connext 7.7.0.

If you plan to run a system with a mix of applications from different Connext releases, use a Collector Service from the highest release.

3.2.5.2. Changes to domain ID and domain tag for observability traffic

Starting in Connext 7.7, the default DomainParticipant configuration used for observability traffic has changed:

Monitoring Library 2.0 now uses domain 101 (previously 2)
Collector Service uses:
- Domain 101 for ingestion (from applications)
- Domain 102 for forwarding between Collector Services
All observability DomainParticipants are assigned the domain tag RTI_o11y

Due to these changes, Monitoring Library 2.0 applications running in Connext versions earlier than 7.7.0 are not compatible with Collector Service 7.7.0 and later.

To restore compatibility, update the configuration of existing applications to match the new defaults (domain ID and domain tag). For example:

<qos_library name="MyQosLibrary">
    <qos_profile name="MyObservabilityProfile" base_name="BuiltinQosLib::Generic.Monitoring2">
        <property>
            <value>
                <element>
                    <name>dds.domain_participant.domain_tag</name>
                    <value>RTI_o11y</value>
                </element>
            </value>
        </property>
    </qos_profile>
    <qos_profile name="MyApplicationProfile" is_default_participant_factory_profile="true">
        <participant_factory_qos>
            <monitoring>
                <enable>true</enable>
                <distribution_settings>
                    <dedicated_participant>
                        <domain_id>101</domain_id>
                    </dedicated_participant>
                    <participant_qos_profile_name>
                        MyQosLibrary::MyObservabilityProfile
                    </participant_qos_profile_name>
                </distribution_settings>
            </monitoring>
        </participant_factory_qos>
    </qos_profile>
</qos_library>

3.2.5.3. Monitoring Library 2.0 security now enforced when using RTI Security plugins

Previously, you could use an unsecured Monitoring Library 2.0 while having DomainParticipants secured with the Security Plugins library. Now, Connext enforces Monitoring Library 2.0 to be secured whenever any DomainParticipant in the application uses a Security Plugins library (either the RTI Security Plugins or the Lightweight Security Plugins). This change prevents Monitoring Library 2.0 from inadvertently publishing telemetry data and metrics from a secured application over an unsecured channel.

If any DomainParticipant in your application has security enabled and Monitoring Library 2.0 is not secured, the enablement of Monitoring Library 2.0 will fail with the following error:

[ERROR] FAILED TO ENABLE | You are attempting to enable the RTI Monitoring Library 2.0 without security, but your system already contains a DomainParticipant with security enabled. Please, enable security for the RTI Monitoring Library 2.0 (refer to the RTI Connext Observability Framework for further information).

Conversely, if Monitoring Library 2.0 is already enabled without security, enabling a DomainParticipant that uses the Security Plugins will fail with the following error:

[ERROR] FAILED TO ENABLE | You are attempting to enable a secure DomainParticipant, but the RTI Monitoring Library 2.0 is not secured. Please, disable RTI Monitoring Library 2.0 (using factoryQos.monitoring.enable) or enable security for it (refer to the RTI Connext Observability Framework for further information).

To resolve either error, enable security for Monitoring Library 2.0 by configuring the appropriate security artifacts in the monitoring DomainParticipant QoS profile, or disable Monitoring Library 2.0 using participant_factory_qos.monitoring.enable.

For details on how to secure Monitoring Library 2.0, see the Security chapter in the RTI Connext Observability Framework User’s Manual.

3.2.5.4. Setting monitoring.telemetry_data.metrics in a derived profile or using an XML snippet now behaves differently

Before 7.7.0, when configuring QoS profiles in XML, setting the sequence monitoring.telemetry_data.metrics in a derived profile—either via a snippet or by defining the value directly—did not override the inherited value from the base profile or previously applied snippets. Instead, the previous sequence values remained in effect (merged behavior).

In 7.7.0, this issue is fixed. The sequence is now always fully replaced when explicitly defined in a derived profile, whether through a snippet or directly in the profile. This behavior now aligns with Connext’s documented rule that sequences defined in a derived QoS profile replace the corresponding sequences in the base profile. See Sequences.

For example:

<qos_library name="MyLibrary">
    <qos_profile name="MyBaseProfile">
        <participant_factory_qos>
            <monitoring>
                <telemetry_data>
                    <metrics>
                        <element>
                            <resource_selection>//data_writers/*</resource_selection>
                            <enabled_metrics_selection>
                                <element>dds_data_writer_reliable_cache_*</element>
                            </enabled_metrics_selection>
                        </element>
                    </metrics>
                </telemetry_data>
            </monitoring>
        </participant_factory_qos>
    </qos_profile>
    <qos_profile name="MySnippet">
        <?rti-qos_snippet?>
        <participant_factory_qos>
            <monitoring>
                <telemetry_data>
                    <metrics>
                        <element>
                            <resource_selection>//data_writers/MyWriter</resource_selection>
                            <enabled_metrics_selection>
                                <element>dds_data_writer_deadline_missed_total</element>
                            </enabled_metrics_selection>
                        </element>
                    </metrics>
                </telemetry_data>
            </monitoring>
        </participant_factory_qos>
    </qos_profile>
    <qos_profile name="DerivedProfileWithSnippet" base_name="MyBaseProfile">
        <base_name>
            <element>MyLibrary::MySnippet</element>
        </base_name>
    </qos_profile>
    <qos_profile name="DerivedProfileDirect" base_name="MyBaseProfile">
        <participant_factory_qos>
            <monitoring>
                <telemetry_data>
                    <metrics>
                        <element>
                            <resource_selection>//data_writers/MyWriter</resource_selection>
                            <enabled_metrics_selection>
                                <element>dds_data_writer_deadline_missed_total</element>
                            </enabled_metrics_selection>
                        </element>
                    </metrics>
                </telemetry_data>
            </monitoring>
        </participant_factory_qos>
    </qos_profile>
</qos_library>

Before the fix, both DerivedProfileWithSnippet and DerivedProfileDirect contained two entries in the <metrics> sequence:

//data_writers/*
//data_writers/MyWriter

The explicitly defined sequence was merged with the inherited sequence instead of replacing it.

After the fix, both derived profiles now contain only one entry in the <metrics> sequence:

//data_writers/MyWriter

Any explicitly defined monitoring.telemetry_data.metrics sequence—whether introduced via a snippet or directly in the derived profile—now fully replaces the inherited values. If this change affects you, please adjust your configuration accordingly.

3.2.5.5. Default metrics reduction in Monitoring Library 2.0

Starting in Connext 7.7.0, Monitoring Library 2.0 publishes a reduced set of metrics by default when a Collector Service is active. This change minimizes bandwidth usage and focuses on the metrics required for standard Grafana dashboards.

If your existing workflows rely on additional metrics being published by default, you must update the Monitoring Library 2.0 configuration to explicitly enable them.

To restore the previous behavior (publish all metrics), configure the following:

<qos_library name="MyQosLibrary">
    <qos_profile name="MyApplicationProfile" is_default_participant_factory_profile="true">
        <participant_factory_qos>
            <monitoring>
                <enable>true</enable>
                <telemetry_data>
                    <metrics>
                        <element>
                            <resource_selection>//*</resource_selection>
                            <enabled_metrics_selection>
                                <element>*</element>
                            </enabled_metrics_selection>
                        </element>
                    </metrics>
                </telemetry_data>
            </monitoring>
        </participant_factory_qos>
    </qos_profile>
</qos_library>

Enabling all metrics may increase bandwidth and memory usage compared to the new defaults.

To see which metrics are enabled by default, see Setting Initial Metrics and Log Configuration in the RTI Connext Observability Framework User’s Manual.

3.2.5.6. Disallow unrealistic values of polling_period

The DDS_MonitoringPeriodicDistributionSettings::polling_period must now be no more than 4294967 seconds (50 days). Enabling Monitoring Library 2.0 will no longer succeed if the polling_period exceeds this value.

3.2.5.7. Monitoring Library 2.0 may require increasing participant_property_string_max_length with LM bundles

In 7.7.0, when using license-managed (lm) Connext bundles, the Monitoring Library 2.0’s DomainParticipant may internally set additional participant properties. If you already configure participant properties for this DomainParticipant—for example, to enable Security Plugins—the current participant_property_string_max_length may not be large enough, causing the library activation to fail.

To resolve this, increase the value of resource_limits.participant_property_string_max_length in the QoS profile referenced by participant_factory_qos.monitoring.distribution_settings.dedicated_participant.participant_qos_profile_name.