Add CMSSW performance metrics

[vkuznet]

Adds CMSSW performance metrics as requested in WMCore https://github.com/dmwm/WMCore/issues/11538

[amaltaro]

Valentin, is it a hard schema for production FJR? Or will it only be enforced if the client enabled schema check? I guess it is StompAMQ that has schemas that can be enforced, right? Is it in use by WMArchive as well?

My concern here is that we will be blindly publishing whatever performance metrics are provided by CMSSW, and I am pretty sure there are different metrics in releases separated by many years.

[vkuznet]

The schema is used to produce WMArchive docs, and it can be enforced on MONIT side (if I recall correctly) but WMArchive service takes whatever docs agents sent to it and add only additional meta-data metrics to it but it does not check the doc for all attributes. This is done on MONIT side where we presented the schema with its data-type for attribute values.

Therefore, your concern may be valid about blindly publishing metrics, but in my view it is task of WMA rather the WMArchive service which only serve as proxy between WMA and MONIT.

[makortel]

What happens on MONIT if the document

• contains fields that not part of the schema
• does not not contain fields that are part of the schema

?

@amaltaro is correct in assuming that different CMSSW releases can produce different metrics, and in general for some metrics whether they are reported or not depends on the application itself.

[vkuznet]

@makortel , from MONIT point of view document should not change its data-types, but if it has more or less number of keys it will be accepted. Said that, the WMCore code prepares WMArchive document according to the schema, and if we provide extra attributes which are not part of the schema they will be ignored. If certain attribute is missing it will be missing in a WMArchive doc too. For instance we may have empty sections in WMArchive document.

And, I think your statement about CMSW release metrics is correct too.

[makortel]

@vkuznet Thanks. So as long as we don't change the data types, and provide the superset of possible fields in the schema, things should work, right?

[vkuznet]

Yes, this is the case.

Sent from Proton Mail mobile

-------- Original Message -------- On Aug 22, 2023, 2:30 PM, Matti Kortelainen wrote:

@.***(https://github.com/vkuznet) Thanks. So as long as we don't change the data types, and provide the superset of possible fields in the schema, things should work, right?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[makortel]

Hi, just for me to understand the overall status of the propagation of the CMSSW performance metrics into the MONIT system, does this issue still need some work? Or was everything necessary done already, and this issue could be closed

Thanks!

[vkuznet]

@makortel , the issue may be closed since we do propagate CMSSW metrics to MONIT. For example, here is recent document which contains CMSSW metrics. If you need specific dashboards based on them you should open a ticket with CMS Monitoring group using their [Jira]((https://its.cern.ch/jira/projects/CMSMONIT/summary).

[vkuznet]

@amaltaro could you please review and confirm that I can merge this PR?

[amaltaro]

From previous discussions in this thread:

• this schema is not enforced by default
• hence, documents don't need to have all those metrics (or they may have other metrics)
• the most important is that a given metric/field stick to a single data type.

with that, I have no other concerns and I this looks good to me.