13.5. What’s New in 7.7.0
This section describes what’s new in Observability Framework 7.7.0 compared to release 7.6.0.
Connext 7.7.0 is the first production release in the 7.7 long-term support (LTS) series. It is built upon and combines all of the features in releases 7.4.0, 7.5.0, and 7.6.0 (see Previous Releases). See the Connext Versions and Lifecycle page for more information on RTI’s software release model.
For what’s new and fixed in other products in the Connext suite, see those products’ release notes on the RTI Community Portal or in your installation.
13.5.1. Improved discovery and reduced overhead with Collector Service
Default discovery and liveliness settings for Collector Service and Monitoring Library 2.0 participants have been updated to improve responsiveness.
Because observability discovery is asymmetric (applications discover Collector Service), late-joining Collector Services could previously take up to 30 seconds to be discovered. This is now improved.
The new defaults provide faster discovery and quicker detection of Collector Service loss:
participant_liveliness_lease_duration= 35sparticipant_liveliness_assert_period= 10smax_liveliness_loss_detection_period= 10s
In addition, bandwidth has been reduced by disabling unnecessary system properties.
Several system properties that increase DATA(P) size are now disabled by default, reducing bandwidth and memory usage. This disabled properties are as follows:
dds.sys_info.creation_timestampdds.sys_info.executable_filepathdds.sys_info.execution_timestampdds.sys_info.targetdds.sys_info.username
Finally, the initial discovery announcements on LAN
(<initial_participant_announcements>) have decreased from 5 to 3.
Lowering the number of initial participant announcements reduces
discovery traffic to the Monitoring Library 2.0 initial peers.
All these changes are part of the Generic.Monitoring2 builtin
profile. See Configuring QoS for Entities
for more information.
13.5.2. Support for Multicast Discovery
Collector Service now enables multicast discovery by default for communication with Connext applications.
When multicast is available on the network, Collector Service
instances can be automatically discovered by applications running on
different hosts. This removes the need to manually configure Collector
Service initial peers (<collector_initial_peers>) in applications
using Monitoring Library 2.0.
Connecting a single application to multiple Collector Services is not yet officially supported. With multicast discovery enabled, the likelihood of this scenario increases.
When multiple Collector Services are detected, Monitoring Library 2.0 will emit a warning such as:
Multiple active Collector Services detected. Some features may not work correctly with multiple collectors.
Note: This condition is safe if a Collector Service was stopped ungracefully and discovery has not yet removed it.
13.5.3. Reduced default metrics set in Monitoring Library 2.0, minimizing bandwidth utilization
When a Collector Service is active, Monitoring Library 2.0 now reduces the default set of published metrics to minimize bandwidth utilization.
The default metrics focus on those required to drive alerts in the standard Grafana Observability dashboards. Additional metrics can be enabled on demand from the Grafana UI by sending a command to the Collector Service.
To see which metrics are enabled by default, see Setting Initial Metrics and Log Configuration.
To restore the previous behavior and publish all available metrics, update the Monitoring Library 2.0 configuration as follows:
<qos_library name="MyQosLibrary">
<qos_profile name="MyApplicationProfile" is_default_participant_factory_profile="true">
<participant_factory_qos>
<monitoring>
<!-- Enable monitoring -->
<enable>true</enable>
<!-- Enable all metrics -->
<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>
See Monitoring Library 2.0 for more information.
13.5.4. Improved flexibility in security configuration for Collector Service
Additional configuration profiles are included in Collector Service to
allow the use of Lightweight Security Plugins for securing monitoring
data between applications using Monitor Library 2.0 and Collector
Service. New LWSecure profiles are now available for all existing
secure configurations that use the Lightweight Security Plugins. The
new profiles are as follows:
Configuration Name |
Supported Exporter(s) |
Network |
Security |
|---|---|---|---|
LWSecureF orwarderLANtoLAN |
dds_exporter |
LAN to LAN |
Yes |
LWSecureF orwarderLANtoWAN |
dds_exporter |
LAN to WAN |
Yes |
LWSecureF orwarderWANtoWAN |
dds_exporter |
WAN to WAN |
Yes |
LWSecureLAN |
prom etheus_exporter, loki_exporter, we bsocket_exporter |
LAN |
Yes |
LWSecureWAN |
prom etheus_exporter, loki_exporter, we bsocket_exporter |
WAN |
Yes |
LWSecureOTelLAN |
otlp_exporter, we bsocket_exporter |
LAN |
Yes |
LWSecureOTelWAN |
otlp_exporter, we bsocket_exporter |
WAN |
Yes |
LWSecureRe moteDebuggingLAN |
we bsocket_exporter |
LAN |
Yes |
LWSecureRe moteDebuggingWAN |
we bsocket_exporter |
WAN |
Yes |
13.5.5. Improved isolation for observability traffic
The configuration of the DomainParticipants created by Collector Service has been updated to improve isolation of observability traffic.
Collector Service uses DomainParticipants to:
Receive telemetry data from applications using Monitoring Library 2.0
Send and receive telemetry data between Collector Services
By default, the DomainParticipant used to receive data from
applications now runs in domain 101 (previously 2), reducing the
likelihood of interference with application traffic.
Additionally, the default domain ID of the forwarding
DomainParticipant has been changed from 101 to 102, further
separating internal observability communication.
All DomainParticipants are also assigned the domain tag RTI_o11y,
providing an extra layer of isolation for observability-related
communication.
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 due to these changes in domain IDs and domain tags.
To restore compatibility, update existing applications to use the new
observability domain (101) and domain tag (RTI_o11y), or upgrade
them to Connext 7.7.0 or later. See the Migration Guide on the RTI
Community Portal for
additional info.
13.5.6. New standalone Collector Service executable simplifies Observability Framework deployments
Collector Service is now provided as an executable on supported platforms with Connext Professional. This new deployment option enables:
running Collector Service to support the Remote Debugging feature and Observability Framework deployments without using Docker, and
deploying Collector Service in air-gapped and other environments where using Docker is prohibited.
The new executable is available in addition to the existing Docker-based deployment, which continues to be supported and updated in parallel. For installation information, see the Observability Framework User’s Manual.
13.5.7. Monitoring Library 2.0 now enabled by default under specific conditions, making it easier to use remote debugging
Monitoring Library 2.0 is now enabled by default for Connext applications if either of the following conditions is met:
Your application links to dynamic Connext libraries and Monitoring Library 2.0 is available in your library path.
Your application links to static Connext libraries (including Monitoring Library 2.0) and you invoke
RTI_Monitoring_initialize.
This improvement enables you to use the Observability Framework and Admin Console Remote Debugging feature at any time without modifying your deployed applications. All Connext Infrastructure Services (except Collector Service) also enable the library by default when available in the library path. The library remains disabled by default in RTI Admin Console, RTI Monitor, RTI DDS Spy, and RTI DDS Ping.
See Enabling Monitoring Library 2.0 for more information.
13.5.8. Disallow unrealistic values of polling_period, to avoid errors collecting data for Observability Framework
Monitoring Library 2.0 uses the DDS_MonitoringPeriodicDistributionSettings::polling_period
to periodically poll for new telemetry data to send to
RTI Observability Framework. To avoid internal integer overflows,
the 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.
13.5.9. Improved security configuration provides more robust protection for Collector Service
Collector Service server security has been reinforced by ensuring that when either TLS/SSL security or Basic Authentication is enabled, the other is as well.
13.5.10. Collector Service 7.7.0 works with Monitoring Library 2.0 in release 7.3.x to improve interoperability
Collector Service 7.7.0 is compatible with applications using the 7.3.x release of Monitoring Library 2.0. These components were previously incompatible due to support for remote debugging. In release 7.7.0, Collector Service checks the Monitoring Library 2.0 release running in an application, then filters commands accordingly.
Although Monitoring Library 2.0 in releases 7.3.x and 7.7.0 both work with Collector Service 7.7.0, the 7.3.x library only provides observable metric data. The non-metric observables required to use remote debugging are only available in Monitoring Library 2.0 release 7.7.0.
13.5.11. Flexible control over Monitoring Library 2.0 enablement using new environment variable
A new environment variable, RTI_MONITORING2_ENABLE, can now be set
to 1, true, or on (case insensitive) to enable Monitoring Library
2.0. The variable can be set to 0, false, or off to disable it.
The RTI_MONITORING2_ENABLE setting takes precedence over the XML
configuration.
See Enabling Monitoring Library 2.0 for more information.
13.5.12. Monitoring Library 2.0 security enforced when using an RTI security plugin, elevating security standards
To prevent Monitoring Library 2.0 from inadvertently publishing telemetry data and metrics from a secured application over an unsecured channel, Connext now enforces that Monitoring Library 2.0 is also secured whenever any DomainParticipant in the application uses a security plugin (either the RTI Security Plugins or the Lightweight Security Plugins).
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 a security plugin 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.
13.5.13. Third-Party Software Changes
13.5.13.1. Observability Collector Service
The following third-party software used by Collector Service has been upgraded:
Third-Party Software |
Old Version |
New Version |
|---|---|---|
OpenSSL |
3.5.1 |
3.5.5 |
OpenTelemetry C++ |
1.13.0 |
1.24.0 |
Prometheus C++ |
1.0.1 |
1.3.0 |
nlohmann-json |
3.11.2 |
3.12.0 |
libxml2 |
2.11.4 |
2.15.1 |
For information on third-party software used by Connext products, see the “3rdPartySoftware” documents in your installation: <NDDSHOME>/doc/manuals/connext_dds_professional/release_notes_3rdparty.
13.5.13.2. Docker containers for Observability Collector Service
The following third-party software used by the Docker containers created by Observability Framework has been upgraded:
Third-Party Software |
Old Version |
New Version |
|---|---|---|
NGINX |
1.24.0 |
1.28.1 |
OpenTelemetry Collector Contrib |
0.91.0 |
0.144.0 |
Prometheus |
2.45.1 |
3.5.1 |
Grafana |
10.1.4 |
12.3.1 |
Grafana Loki |
2.8.5 |
3.6.4 |