Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Develop non-regulatory material for WIS2 operations #109

Open
6a6d74 opened this issue Jan 27, 2024 · 1 comment
Open

Develop non-regulatory material for WIS2 operations #109

6a6d74 opened this issue Jan 27, 2024 · 1 comment

Comments

@6a6d74
Copy link
Collaborator

6a6d74 commented Jan 27, 2024

Task allocated to ET - WIS Operations

... this will include reporting
... GISC Watch
... etc.

@6a6d74 6a6d74 moved this to For performance testing hackathon (2024Q2-Q3) in WIS2 - the everything list Jan 27, 2024
@6a6d74
Copy link
Collaborator Author

6a6d74 commented Jan 27, 2024

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:

  1. 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
  2. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: For performance testing hackathon (2024Q2-Q3)
Development

No branches or pull requests

1 participant