43.4 MONITORING QosPolicy (DDS Extension)
This QoS policy configures RTI Monitoring Library 2.0, which is used by the RTI Connext Observability Framework. See Chapter 60 RTI Monitoring Library 2.0 for more information.
Note: This QoS policy configures the RTI Monitoring Library 2.0, not the Chapter 59 RTI Monitoring Library.
This QoS policy can be configured programmatically or via XML. You can also find information about it, including its minimum setup, in the API Reference HTML documentation and in Monitoring Library 2.0, in the RTI Observability Framework documentation.
This QoS policy has the members described in the following tables.
Type |
Field Name |
Description |
DDS_Boolean |
enable |
Enables the collection and distribution of telemetry data for a Connext application using Monitoring Library 2.0. Note: Enabling and disabling Monitoring Library 2.0 while DDS Entities are being created or deleted is not a safe operation. The entities created while Monitoring Library 2.0 is being enabled may not be monitored. In that case, children entities from that entity (invisible to the library) will not be monitored, either. Default: FALSE |
char * |
application_name |
Name of the resource that represents your Connext application. When this member is set to a value other than NULL, the resource identifier representing this application will be: /applications/<application_name> This is the resource identifier that will be used to send commands to this application from the RTI Observability Dashboards. The application_name should be unique across the Connext system; however, Monitoring Library 2.0 does not currently enforce uniqueness. When application_name is set to NULL, Monitoring Library 2.0 will automatically assign a resource identifier with this format: /applications/<host_name:process_id:uuid> Default: NULL |
DDS_MonitoringDistributionSettings |
distribution_settings |
This structure configures the distribution of telemetry data. It includes the fields in Table 43.5 DDS_MonitoringDistributionSettings. |
DDS_MonitoringTelemetryData |
telemetry_data |
This structure configures the telemetry data that will be distributed (logs and metrics). It includes the fields in Table 43.10 DDS_MonitoringTelemetryData. |
Table 43.5 DDS_MonitoringDistributionSettings
Type |
Field Name |
Description |
---|---|---|
DDS_MonitoringDedicatedParticipantSettings |
dedicated_participant |
Configures the use of a dedicated DomainParticipant to distribute the Connext application telemetry data. It includes the fields in Table 43.6 DDS_MonitoringDedicatedParticipantSettings. |
char * |
publisher_qos_profile_name |
Fully qualified name of the profile used to configure the Publishers that distribute telemetry data. There is one Publisher for each telemetry data Topic:
If NULL (the default value) then Monitoring Library 2.0 uses DDS_PROFILE_GENERIC_MONITORING2. Default: NULL |
DDS_MonitoringEventDistributionSettings |
event_settings |
Configures the distribution of event metrics. Event metrics are provided to Monitoring Library 2.0 when they change. For example, if the liveliness of a DataWriter is lost, a matching DataReader will push the new value of 40.7.4 LIVELINESS_CHANGED Status to Monitoring Library 2.0 so that the liveliness status change can be distributed. There are three kinds of event metrics:
|
DDS_MonitoringPeriodicDistributionSettings |
periodic_settings |
Configures the distribution of periodic metrics. Periodic metrics change often, and they are polled and published periodically by a thread created by Monitoring Library 2.0. Monitoring Library 2.0 obtains periodic metrics by polling the current value of periodic statuses such as the 31.6.3 DATA_WRITER_PROTOCOL_STATUS. |
DDS_MonitoringLoggingDistributionSettings |
logging_settings |
Configures the distribution of logging messages. Log messages are pushed into Monitoring Library 2.0 and published by the logging thread. The logging thread only publishes a log message with a Syslog level smaller than or equal to the forwarding level of the NDDS_Config_LogFacility associated with the log message. The default value of the forwarding level for all facilities is NDDS_CONFIG_SYSLOG_VERBOSITY_WARNING. This value can be changed with the Table 43.11 DDS_MonitoringLoggingForwardingSettings or by sending a command to Monitoring Library 2.0. Currently, commands can only be sent from the Observability Dashboards. Monitoring Library 2.0 can be configured to keep a history of log messages for later distribution when a log snapshot is requested by an Observability Collector Service. The log messages maintained in the history are the last ‘n’ messages published by the logging thread (where ‘n’ is the value of max_historical_logs). |
Table 43.6 DDS_MonitoringDedicatedParticipantSettings
Type |
Field Name |
Description |
---|---|---|
DDS_Boolean |
enable |
Enables the use of a dedicated DomainParticipant to distribute the Connext application telemetry data. Setting this value to FALSE is not currently supported. Default: TRUE |
int |
domain_id |
Domain ID used in the creation of Monitoring Library 2.0 DomainParticipant. Default: 2 |
char * |
participant_qos_profile_name |
Fully qualified name of the profile used to configure the DomainParticipant that will be used to distribute telemetry data. If NULL (the default value), then Monitoring Library 2.0 uses DDS_PROFILE_GENERIC_MONITORING2. Default: NULL |
DDS_StringSeq |
collector_initial_peers |
Determines the initial list of peers that the discovery process will contact to send announcements about the presence of the dedicated DomainParticipant. These initial peers should correspond with the RTI Observability Collector Service with which Monitoring Library 2.0 has to communicate. The collector_initial_peers works the same as initial_peers for other DomainParticipants, except that it allows you to easily specify the initial peer(s) for the Monitoring Library 2.0 DomainParticipant, which usually has different initial peer(s) than those used by your application. See Monitoring Library 2.0, in the RTI Observability Framework documentation for more context. If no collector_initial_peers are specified, or if it is explicitly set to an empty list, the initial_peers list of the QoS profile specified in participant_qos_profile_name will be used as the initial peers of the dedicated DomainParticipant. Default: An empty sequence |
Table 43.7 DDS_MonitoringEventDistributionSettings
Type |
Field Name |
Description |
---|---|---|
DDS_UnsignedLong |
concurrency_level |
Defines how concurrent the push is of event metrics to Monitoring Library 2.0. With a concurrency_level of one, all the event metrics pushed to Monitoring Library 2.0 will be stored in a single queue protected by a single mutex. With a concurrency_level of 'n', Monitoring Library 2.0 will create 'n' queues for event metrics, each queue protected by its own mutex. Each resource (e.g,, a DataReader) will be associated with one of the queues when the resource is registered with Monitoring Library 2.0. Therefore, all the event metrics for a single resource always go to the same queue. The event metrics for two resources associated with different event queues can be pushed in parallel. This is why a higher concurrency_level provides more concurrency. The event metrics added to the event queues are processed by a single thread configured using the thread field. Range: [1, 100] Default: 5 |
char * |
datawriter_qos_profile_name |
Fully qualified name of the profile used to configure the DataWriter that distributes event metrics. The DataWriter Topic is RTI_MONITORING_EVENT_TOPIC_NAME. If NULL (the default value), then Monitoring Library 2.0 uses DDS_PROFILE_GENERIC_MONITORING2. Default: NULL |
DDS_ThreadSettings_t |
thread |
Settings of the event metric thread. The event metric thread periodically publishes the event metrics pushed into Monitoring Library 2.0 event metric queues after they change their values. The thread runs at the period configured using the publication_period. See also 50.4.7 Thread Settings. Default: DDS_THREAD_SETTINGS_DEFAULT |
DDS_Duration_t |
publication_period |
Period at which the event metric thread publishes the event metrics that have changed since the last time they were published. With a period of 0 seconds, changes to event metrics will be published immediately after they are pushed into Monitoring Library 2.0. Default: 1 second |
Table 43.8 DDS_MonitoringPeriodicDistributionSettings
Type |
Field Name |
Description |
---|---|---|
char * |
datawriter_qos_profile_name |
Fully qualified name of the profile used to configure the DataWriter that distributes periodic metrics. The DataWriter Topic is RTI_MONITORING_PERIODIC_TOPIC_NAME. If NULL (the default value), then Monitoring Library 2.0 uses DDS_PROFILE_GENERIC_MONITORING2. Default: NULL |
DDS_ThreadSettings_t |
thread |
Settings of the periodic metric thread. The periodic metric thread periodically polls and publishes periodic event metrics. The thread runs at the period configured using the polling_period. See also 50.4.7 Thread Settings. Default: DDS_THREAD_SETTINGS_DEFAULT |
DDS_Duration_t |
polling_period |
Period at which the periodic metric thread polls and publishes the periodic metrics. Range: > 0 seconds Default: 5 seconds |
Table 43.9 DDS_MonitoringLoggingDistributionSettings
Type |
Field Name |
Description |
---|---|---|
DDS_UnsignedLong |
concurrency_level |
Defines how concurrent the push of log messages to Monitoring Library 2.0 is. With a concurrency_level of one, all the log messages pushed to Monitoring Library 2.0 will be stored in a single queue protected by a single mutex. With a concurrency_level of 'n', Monitoring Library 2.0 will create 'n' queues for log messages, each queue protected by its own mutex. The log messages generated by a single thread will always be pushed to the same queue. The log messages for two threads associated with different log queues can be pushed in parallel. This is why a higher concurrency_level provides more concurrency. The log messages added to the log queues are processed and published by a single thread configured using the thread field. Range: [1, 100] Default: 5 |
DDS_UnsignedLong |
max_historical_logs |
Number of log messages that Monitoring Library 2.0 will keep as history. Monitoring Library 2.0 will keep as history the last max_historical_logs published messages. A value of 0 means that Monitoring Library 2.0 should not keep any history. Default: 128 |
char * |
datawriter_qos_profile_name |
Fully qualified name of the profile used to configure the DataWriter that distributes log messages. The DataWriter Topic is RTI_MONITORING_LOGGING_TOPIC_NAME. If NULL (the default value), then Monitoring Library 2.0 uses DDS_PROFILE_GENERIC_MONITORING2. Default: NULL |
DDS_ThreadSettings_t |
thread |
Settings of the logging thread. The logging thread periodically publishes the log messages pushed into Monitoring Library 2.0 log message queues after they are generated. The thread runs at the period configured using publication_period. See also 50.4.7 Thread Settings. Default: DDS_THREAD_SETTINGS_DEFAULT |
DDS_Duration_t |
publication_period |
Period at which the logging thread publishes log messages. With a period of 0 seconds, log messages will be published immediately after they are pushed into Monitoring Library 2.0. Default: 1 second |
Table 43.10 DDS_MonitoringTelemetryData
Type |
Field Name |
Description |
---|---|---|
DDS_MonitoringMetricSelectionSeq |
metrics |
There are many metrics that Observability Framework can collect and forward for a given set of observable resources (for a DomainParticipant, Publisher, DataReader, etc.). The metrics field enables you to specify the initial set of metrics you want to collect. For example, when a DataWriter is created in your application, the metrics you define here are forwarded to Observability Collector Service, which distributes them to observability backends. If you decide later that you want more/fewer metrics to be forwarded, you can easily add/remove them via a remote command. See the RTI Observability Framework documentation for more details. The metrics field is a sequence of DDS_MonitoringMetricSelection elements, each containing three fields:
For information about how to build the patterns in these fields, see the Metrics section in the RTI Observability Framework documentation. See the API Reference HTML documentation ( Every DDS_MonitoringMetricSelection in the sequence is evaluated in order: enabled_metric_selection is evaluated first and disabled_metric_selection after. Therefore, if the same metric is enabled and disabled at the same time, the disablement will be the final result. Attention: By default, no metrics will be enabled for any resource unless you specify them here. |
DDS_MonitoringLoggingForwardingSettings |
logs |
This structure configures the NDDS_Config_SyslogVerbosity levels that will be forwarded for the different NDDS_Config_LogFacility levels. See Table 43.11 DDS_MonitoringLoggingForwardingSettings. |
Table 43.11 DDS_MonitoringLoggingForwardingSettings
Type |
Field Name |
Description |
---|---|---|
NDDS_Config_SyslogVerbosity |
middleware_forwarding_level |
Log messages with NDDS_CONFIG_LOG_FACILITY_MIDDLEWARE and a log level more verbose than this value will not be distributed by Monitoring Library 2.0. See 54.2 Configuring Connext Logging for more information on the NDDS_CONFIG_LOG_FACILITY_* and NDDS_CONFIG_SYSLOG_* settings. Note: Setting this field to a value more verbose than WARNING if your application's verbosity is greater than NDDS_CONFIG_LOG_VERBOSITY_WARNING, may affect performance due to the large amount of messages produced. Default: NDDS_CONFIG_SYSLOG_VERBOSITY_WARNING |
NDDS_Config_SyslogVerbosity |
security_event_forwarding_level |
Log messages with NDDS_CONFIG_LOG_FACILITY_SECURITY_EVENT and a log level more verbose than this value will not be distributed by Monitoring Library 2.0. See 54.2 Configuring Connext Logging for more information on the NDDS_CONFIG_LOG_FACILITY_* and NDDS_CONFIG_SYSLOG_* settings. Note: Setting this field to a value more verbose than WARNING if your application's verbosity is greater than NDDS_CONFIG_LOG_VERBOSITY_WARNING, may affect performance due to the large amount of messages produced. Default: NDDS_CONFIG_SYSLOG_VERBOSITY_WARNING |
NDDS_Config_SyslogVerbosity |
service_forwarding_level |
Log messages with NDDS_CONFIG_LOG_FACILITY_SERVICE and a log level more verbose than this value will not be distributed by Monitoring Library 2.0. See 54.2 Configuring Connext Logging for more information on the NDDS_CONFIG_LOG_FACILITY_* and NDDS_CONFIG_SYSLOG_* settings. Note: Setting this field to a value more verbose than WARNING if your application's verbosity is greater than NDDS_CONFIG_LOG_VERBOSITY_WARNING, may affect performance due to the large amount of messages produced. Default: NDDS_CONFIG_SYSLOG_VERBOSITY_WARNING |
NDDS_Config_SyslogVerbosity |
user_forwarding_level |
Log messages with NDDS_CONFIG_LOG_FACILITY_USER and a log level more verbose than this value will not be distributed by Monitoring Library 2.0. See 54.2 Configuring Connext Logging for more information on the NDDS_CONFIG_LOG_FACILITY_* and NDDS_CONFIG_SYSLOG_* settings. Note: Setting this field to a value more verbose than WARNING if your application's verbosity is greater than NDDS_CONFIG_LOG_VERBOSITY_WARNING, may affect performance due to the large amount of messages produced. Default: NDDS_CONFIG_SYSLOG_VERBOSITY_WARNING |
43.4.1 Properties
This QosPolicy can be changed at any time.
There are no compatibility restrictions for how it is set on the publishing and subscribing sides.
43.4.2 Related QoS Policies
None
43.4.3 Applicable DDS Entities
43.4.4 System Resource Considerations
Enabling Monitoring Library 2.0 by setting monitoring.enable (that is, enable in the DDS_MonitoringQosPolicy) to TRUE will allocate additional resources to collect and distribute the telemetry data. These resources include:
- An additional DomainParticipant if monitoring.distribution_settings.dedicated_participant.enable is set to TRUE (default behavior)
- A Publisher and a DataWriter to publish periodic metrics
- A Publisher and a DataWriter to publish event metrics
- A Publisher and a DataWriter to publish logging messages
By default, these entities are created using the builtin profile BuiltinQosLib::Generic.Monitoring2, which configures those entities' QoS, including minimizing their memory usage if desired. You can change the QoSs of the entities by setting the following fields; in these fields, you can provide a different profile (name), which contains your own modifications to Monitoring Qos Policy.
- monitoring.distribution_settings.publisher_qos_profile_name (apply to all Publishers)
- monitoring.distribution_settings.dedicated_participant.participant_qos_profile_name
- monitoring.distribution_settings.periodic_settings.datawriter_qos_profile_name
- monitoring.distribution_settings.event_settings.datawriter_qos_profile_name
- monitoring.distribution_settings.logging_settings.datawriter_qos_profile_name
See Monitoring Library 2.0, in the RTI Observability Framework documentation for notes about the BuiltinQosLib::Generic.Monitoring2 profile, including examples in XML for changing the settings.