Reading RTI Monitor data from a DDS application

Submitted by isabel on Tue, 11/07/2017 - 09:48

What is the Monitoring Library and how do I enable it?

RTI Monitoring Library is a plug-in that enables an RTI Connext DDS application to provide monitoring data. This data can be visualized using the RTI Monitor application or read by a separate, user-created application.

In RTI Connext DDS, monitoring data are a series of topics that contain two categories of information about the currently running Connext DDS application. The list of published topics can be found here, in general they can be split into two categories:

Statistical data
QoS and static system information

There are two ways to enable Monitoring Library in an application:

Once you have configured your application such that it is publishing the monitoring topics, you can create an application to read the data, or visualize it using the RTI Monitor application. It is possible to confirm that your application is generating monitoring data by using one of the following:

RTI Monitor application
RTI DDS Spy application
RTI Administration Console (you will need to disable the “Filter all RTI internal Topics” filter via the blue funnel icon).

Reading monitoring topics

A DomainParticipant that is using Monitoring Library can not read its own monitoring topics. This is due to the fact that when Monitoring Library is enabled, the DomainParticipant internally creates monitoring topics in order to publish them - since they already exist you cannot create them again. If you try to create the topic again you will get the following error:

DDS_Topic_createI:!create presentation topic
DDSTopic_impl::createI:!create topic
create_topic error

There are, however, two options that you can implement to have both the Monitoring Library enabled and a DomainParticipant which is subscribed to those monitoring topics from within the same application:

Create a new DomainParticipant within the same application and domain that subscribes to the monitoring topics.
Use property rti.monitor.config.new_participant_domain_id. This property will cause the application to internally create a new DomainParticipant which will be used to publish the monitoring topics. An example of this written in C++ is attached to this article (monitoring_property.zip).

Whether you should publish the monitoring topics in a different domain to the one your application is running in will depend on your use-case. By creating a new DomainParticipant (via the rti.monitor.config.new_participant_domain_id property) you will incur the overhead of another DomainParticipant in your machine (see this Best Practice for why this isn't desirable). However, if you choose to use the same domain, you will be adding additional DDS traffic to the same domain as your application is running, which could affect the issue you are trying to debug.

Here is an example QoS snippet showing how to enable Monitoring Library in your Connext DDS Pro application (note that this snippet includes the optional rti.monitor.config.new_participant_domain_id property):

<participant_qos>
    <property>
        <value>
            <element>
                <name>rti.monitor.library</name>
                <value>rtimonitoring</value>
            </element>
            <element>
                <name>rti.monitor.create_function</name>
                <value>RTIDefaultMonitor_create</value>	
            </element>
            <element> 
                <name>rti.monitor.config.new_participant_domain_id</name>
                <value>34</value>
            </element> 
        </value> 
    </property> 
</participant_qos>

Attached you will find examples for C, C++, and C#. These examples demonstrate using rti.monitor.config.new_participant_domain_id to internally create a new DomainParticipant.

To create an application that subscribes to monitoring topics using the attached examples, follow these steps:

Generate the code for dds_rtf2_dcps.idl:

You will find this IDL in the following path: <NDDSHOME>\resource\idl\dds_rtf2_dcps.idl

Generate the type files for this IDL with rtiddsgen:

<NDDSHOME>\bin\rtiddsgen -create typefiles -language <C/C++/C#> dds_rtf2_dcps.idl

You will need the generated files:

dds_rtf2_dcps.h
dds_rtf2_dcpsPlugin.h
dds_rtf2_dcpsSupport.h
dds_rtf2_dcps.cxx
dds_rtf2_dcpsPlugin.cxx
dds_rtf2_dcpsSupport.cxx

For this example, you will also need the dds_typedefs.h file, which can be found in: <NDDSHOME>\resource\idl\dds_typedefs.h
Then, you will need monitoring.idl (which is where all of the monitoring topics are defined). You will find this IDL in the following path: <NDDSHOME>\resource\idl\monitoring.idl

Generate the code with rtiddsgen for monitoring.idl:

<NDDSHOME>\bin\rtiddsgen -example <your_architecture> -language <C/C++/C#> monitoring.idl

[Only for C++11]
- There is a known issue (CODEGENII-1183) where generated code does not compile in Modern C++ if the IDL contains the combination of modules called "rti" and "dds". To workaround this, modify the monitoring.idl and change "module rti" to "module my_rti".
- In monitoring.idl change "dds_rtf2_dcpsPlugin.h" to "dds_rtf2_dcpsPlugin.hpp"

Modify the generated Visual Studio solution if you are you are using Windows or the makefile if using Linux:

You will need to add the files generated for dds_rtf2_dcps.idl to the monitoring example manually.

Use the same QoS configuration that Monitoring uses. We will copy it and rename it to USER_QOS_PROFILES.xml to ensure it is loaded by your subscribing application:
```
cp $NDDSHOME/resource/template/rti_workspace/examples/connext_dds/qos/MONITORING_LIBRARY_QOS_PROFILES.xml ./USER_QOS_PROFILES.xml
```
(Skip this step if you are using the given examples) Modify the subscriber if needed.

Modify the subscriber so it subscribes to the desired topic.
Note: In the given example, we already provide the modified subscriber code to read the “rti/dds/monitoring/topicEntityStatistics” monitoring topic.
[Only for C++11] Because of changing the module name in monitoring.idl, the generated type_name will contain my_rti. This difference will prevent matching with some monitoring topics where the TypeObject is not propagated and the type_name is used. To fix that, when creating the Topic, specify as the third paramiter the type_name starting with "rti". For example "rti::dds::monitoring::TopicEntityStatistics".