My notes on using the TriggerSupervisor monitoring infrastructure

Documentation

• Example class MonitorSource (which inherits from DataSource): MonitorSource.h, MonitorSource.cc. (see also DataSource.h).
• Marc's presentation with monitoring architecture diagrams
• TS 1.5 user's guide

Applications using monitoring

• GT cell
  • This seems to have an xmas::sensor application running. In the file gt-cell.profile, a path to

    ${XDAQ_SETUP_ROOT}/${XDAQ_ZONE}/sensor

    is configured in the autoConfSearchPath tag of the xmas::sensor::Application application.
  • There are several .sensor files In this directory, e.g. gt-cell.sensor which seems to contain the absolute paths to flahslists (mostly in ${XDAQ_SETUP_ROOT}/${XDAQ_ZONE}/flash/).
  • There seem to be three ws-eventing applications:

    URL	notifies to
    http://vmepcs2g17-02.cms:5001/urn:xdaq-application:lid=400	http://vmepcs2g17-02.cms:5004/urn:xdaq-application:lid=15 (xmas::sensor::Application, profile), http://vmepcs2g17-02.cms:5002/urn:xdaq-application:lid=10 (xmas::pulser::Application, profile is probably this file)
    http://vmepcs2g17-02.cms:5003/urn:xdaq-application:lid=400	http://vmepcs2g17-02.cms:5005/urn:xdaq-application:lid=10 (xmas::las::Application), http://vmepcs2g17-02.cms:5006/urn:xdaq-application:lid=10 (xmas::dashboard::Application), http://cmsrc-trigger:19000/rcms/servlet/monitorreceiver
    http://vmepcs2g17-02.cms:5008/urn:xdaq-application:lid=400	http://vmepcs2g17-02.cms:5009/urn:xdaq-application:lid=21 (sentinel::dashboard::Application)

• http://vmepcs2g17-02.cms:5005/urn:xdaq-application:lid=10 xmas::las=, profile, general-las.las

• DTSC
  • Example xmasstore application: http://vmepcs2g16-08.cms:5007/urn:xdaq-application:lid=10 , the profile seems to be this file.

Steps performed

• Implemented a class inheriting from DataSource (see also sections 6.2.6 ff in the TS 1.5 user guide).
  • The items to be monitored are declared in the constructor. There one also declares the callbacks to be called when an item should be (periodically) updated.
• Instantiate this class in the CellContext (see e.g. CellContext.cc and the TS users guide section 6.2.8), in our case this is the class TTCMonitoringCellContext.

(Note: it looks - from the code template of the CellContext class - like it is also possible to do perform the same calls in the class inheriting from CellContext, a separate class seems not to be needed).

• Create a flashlist (TS users guide section 6.2.1)
  • See the example flash list trigger/setup/unicell/flash/subsystem-cell.flash.
  • Stored as /opt/xdaq/share/base/flash/TTCMonitoringCell.flash.
• Add xmas::sensor::Application to the configuration file /opt/xdaq/share/base/conf/ttc-mi-monitoring.xml (copied and adapted from this file and this documentation page).
• One apparently needs also to add xplore::Application because otherwise xmas::sensor::Application complains.
  • Make sure that in the properties a valid path to a shortcuts.xml file is specified (e.g. to /opt/xdaq/share/base/xplore/shortcuts.xml). IT IS IMPORTANT TO PUT THE CORRECT ZONE (e.g. base, not default) IN THIS FILE !

• When starting the ttc monitoring process (on ttc-mi), click on the xmas::sensor::Application, then on the Infospaces tab. There one should see urn:FrequencyMeterSource... in the drop down menu. This should have an item frequency.

Configuring xmas::sensor

• Created a sensor file (see also TS users guide section 6.2.2) - is the xmas::sensor actually required (looking at the architecture slides of the presentation linked above) ?
  • used the following url ${XDAQ_ROOT}/share/${XDAQ_ZONE}/flash/TTCMonitoringCell.flash#urn:xdaq-flashlist:TTCMonitoringCell in the xlink:href attribute of the xmas:flash tag.
  • stored it as /opt/xdaq/share/base/sensor/TTCMonitoringCell.sensor
  • It seems IMPORTANT to have a sensor.sensor file, (in ${XDAQ_ROOT}/share/${XDAQ_ZONE}/sensor/). See e.g. this file.
  • do NOT use the autoConfigure and autoConfSearchPath tags !

• • Start the xdaq process and go to the xmas::sensor::Application. On the first tab (flashlists), you should see the flashlist in question (urn:xdaq-flashlist:TTCMonitoringCell in our case).

Configuring ws-eventing

• see also TS userguide section 6.2.3
• see e.g. this general-ws-eventing.profile.
• see e.g. http://vmepcs2g17-02.cms:5001/urn:xdaq-application:lid=400 for a GT ws-eventing application

• After about one minute, click on the subscription tab you should see at least one row filled.

Configuring xmas::las

• GT example application: http://vmepcs2g17-02.cms:5005/urn:xdaq-application:lid=10 , profile, general-las.las

Configuring xmas::store

• • see e.g. the dtsc-store.profile.
  • When trying to load this from the same configuration file as ws-eventing, I get the following error message:

    Found oldest implementation for package wseventing (01.13.00) newer than the most recent expected (01.12.00)

Configuring the xmas::pulser

• See e.g. the GT example: http://vmepcs2g17-02.cms:5002/urn:xdaq-application:lid=10 , XDAQ profile for pulser application, pulser configuration. It looks like when one goes to the 'Sensors' tab that there are several subscriptions.

• Create a file /opt/xdaq/share/base/pulser/ttc.pulser which seems to define the periods with which flashlist (?) should be pulsed
• Add the pulser application to the XDAQ configuration file.

• It looks like in the 'Sensors' tab, one should see subscriptions.

Making flashlists show up in the Triggersupervisor tree on the left

• For this one needs to add a MON channel, see section 6.4.1 of the TS1.5 user guide.

Misc.

• finding the 'locations' of the GT TS zone applications:

  slptool -i $(hostname -f) findsrvs service:peer:http '(zone=gtts)'  

• Getting a list of the services of these applications:

for i in $(slptool -i $(hostname -f) findsrvs service:peer:http '(zone=gtts)') ; do j=$(echo $i | cut -d, -f1) ; echo -n "$j: " ; slptool -i $(hostname -f) findattrs $j  service ; done                                        

If this does not work e.g. not on ttc-mi, try restarting the slp daemon using sudo /etc/init.d/slp restart

Notes from experience mid Februrary 2009

• Q: I don't see the sensor in the pulses application (in the last tab ?)
• A: make sure to have a WS-eventing process running. The pulser seem to look for the WS-Eventing (using SLP) to find the sensor.

• Q: I can't see the quantities of the flashlist
• A: make sure you have the sentinel configured. This is needed to display exceptions raised by the monitoring processes. Also check whether you have the correct types in the .flash file (check e.g. in the triggersupervisor manual the mapping from xdata:: types to the corresponding type specification in the .flash file)

Setup on ttc-mi (as of 2009-05-20)

Host/port	Sentinel	Other Applications	xdaqd service name
http://ttc-mi.cms:1972	no	XDAQ application (RF2TTC)	ttc-mi-xdaqs
http://ttc-mi.cms:1973	link	XDAQ applications (RFRXD)	ttc-mi-rfrxd
http://ttc-mi.cms:5001	link	ws::service::Eventing (group=ttc)	ttc-ws-eventing
http://ttc-mi.cms:5002	link	xmas::pulser::Application (group=ttc)	ttc-pulser
http://ttc-mi.cms:5003	link	ws::service::Eventing (group=general)	general-ws-eventing
http://ttc-mi.cms:5004	link	xmas::sensor::Application (groups=ttczone.general,ttczone.ttc) DO WE NEED THIS ONE ???	general-sensor
http://ttc-mi.cms:5005	link	xmas::las::Application (group=general)	general-las
http://ttc-mi.cms:5007	link	xmas::store::Application (groups=ttczone.database,ttczone.general)	general-store
http://ttc-mi.cms:5008	no	ws::service::Eventing (group=exception)	ttc-exception-ws-eventing
http://ttc-mi.cms:5009	no	sentinel::dashboard::Application (group=exception)	ttc-exception-dashboard
http://ttc-mi.cms:9600	link	TTCmiCell	ttc-mi-cell
http://ttc-mi.cms:9800	link	TTCMonitoringCell	ttc-mi-monitoring
http://ttc-mi.cms:9801	link	tstore::TStore	ttc-tstore

The above sentinels usually live in

group=exception

-- AndreHolzner - 23 Oct 2008