6a6d74
commented
3 months ago Adding my notes from ET-W2AT meeting in Washington (Nov 2023) about publishing reports/alerts/events for monitoring:
How to publish reports/alerts about Centre performance?
- Jeremy > publish on “report” topic of the centre to which it applies [agreed]
- … centre needs to subscribe to it’s own “report” topic to receive those notifications
- … a GISC needs to subscribe to the “report” topics for all centres in its AoR - so that it can work with the centre to resolve the issue / implement the recommendation
- …
- Remy > suggests that the “reports” topics are grouped separately to the main TH - to keep these private; not mixing “control” information with data/metadata
- … root-level topic = “monitor” … not “origin” or “cache”
- … monitor/a/wis2/{centre-id}/[event|notification]
- … {centre-id} is the centre that is the subject of the event / notification
- … maybe add GISC to the structure [no]
- Remy > also proposes an event/notification message format
- … concept is good - might want to embed more detailed reports (e.g., from metadata KPI assessment) … more work needed to develop
- Simon > should a Centre take action itself or wait to be pushed by the GISC
- Remy > Centres should be proactive; GISCs should follow up
- Kai > could also use this mechanism to self-publish notifications about their centre - informing others of upcoming changes/issues [agree]
Essentially, there are two categories of things that need to be captured:
- When the WIS2 system (e.g., a Global Service) wants to say something about a WIS Centre (e.g., identify a problem to be resolved); and
- When a WIS Centre (e.g., a WIS2 Node or a Global Service) wants to share information about itself with other WIS2 participants (e.g., an upcoming event such as downtime due to maintenance).
@tomkralidis suggested that CloudEvents might be a good start for the monitoring message format standard. To be further investigated.
Task allocated to ET - WIS Operations
... this will include reporting ... GISC Watch ... etc.