...
WIS2 Global Services metrics
Commentary Jeremy introduced the commentary based on analysis performed by WMO Secretariat (Maaike), 1-hour period on 20-Feb-2025.
Key outcomes from discussion: agree what the correct reporting is for each metric
...
Metrics can be used to understand WIS2 performance in a “stepwise” fashion - i.e., start with “connection”, then look at the numbers of messages/data-objects.(Rémy) it is good to have a sensor centre. Do you have the broker of GM for the GB to subscribe the notification.
(Action) GM (Morocco) and GM (China) to share the GM broker endpoint with the Secretariat.
Global Monitor:
Looking at the metrics available from ma-meteomaroc-global-monitor there are gaps in the metrics from 18h-20h UTC, 19-Feb-2025.
...
… do we need a dashboard indicating “Global Services available now” (red/green traffic light) etc. - based on connection to HTTP or MQTT end-points
(Rémy) regarding the Global Monitors, since China and Morocco have confirmed having a Broker, he proposed establishing a sensor centre to monitor the Global Monitors' connectivity. He also requested China and Morocco to share their brokers endpoints with WMO Secretariat.
Action: GM (Morocco) and GM (China) to share the GM broker endpoint with the Secretariat.
Global Broker metrics:
gb_metrics_analysis.xlsx
...
[lines 6, 8, 92] US-GB does not report a metric on WIS2 Node (au-bom, bf-anam, za-weathersa) that is known to be offline - all other GB report “0” (not connected)
Action: Steve to check and follow up on this.
[lines 10, 15, etc.] CN-GB does not appear to report metrics on other Global Services
Action: Lei to follow up on this.
[lines 17, 18, 23, 48, 62] CN-GB cannot connect to WIS2 Nodes from Chile (cl-meteochile), Cameroon (cm-meteocameroon), Cuba (cu-insmet), Italy (it-meteoam), Morocco (ma-marocmeteo) - confirm?
Action: Lei to check and follow up on this issue
Action: the Secretariat to resend the IP addresses of GB(China) and GB (China) need to check the user and password of these WIS2 nodes, e.g Morocco.
Action:
[line 35] Only BR-GB appears to be subscribing to FR-GB (specifically, only BR-GB is reporting being connected) - more connections expected (albeit CN-GB probably not reporting its connection)
Remy reported that the Global Broker in Brazil is using different credentials for incoming and outgoing connections and suspects this as the source of the problem
Action: Lei to check and follow up on this connectivity issue
[line 36] US-GB is using the wrong centre-id for FR-GB (which probably also explains why it looks like there are so few connections to FR-GB - see above)
Action: Steve to check and follow up on this
[line 41, 47] Only FR-GB connected to WIS2 Nodes hk-hko-swic and ir-irimo - recommended to have at least 2 subscriptions
Action: hk-hko-swic, Secretariat to check verify the right correct IP address of GB (Brazil) and share with HKO Hong Kong colleague and also check with the Iran colleague for their access control
[lines 46, 47, 48] US-GB is not reporting connection to EUMETSAT, Iran, and Italy - is this because US-GB never attempts to establish a connection?
Action: Steve to check. Secretariat : to share GB the Global Broker (US) the credentials, and the Italy to check verify their whitelist of GB for the Global Broker (US)
[line 53] US-GB reports connection to ke-kmd which isn’t in the WIS2 Registry - what’s happening here?
Action: Steve to check
[line 59] Only US-GB reports connection to WIS2 Node from Kazakhstan (kz-kazhydromet) - confirm?
Remy confirmed that GB-FR and Brazil have connectivity with Kazakhstan and that there was only a downtime limited to a short period (one day)
[lines 75, 76] Confusion on centre-id for Sint Maarten (sx-met or sx-metservice)
Action: Secretariat to check with Sint Maarten
Sheet #2: wmo_wis2_gb_msg_received_total
...
[summary] FR-GB and BR-GB report roughly similar numbers (they’re running the same software!), CN-GB reports roughly 20x more messages, 3000-3500x more messages
Action: Steve and Marc to follow up on this
[line 8] CN-GB reports receiving 25k messages from Burkina Faso while that WIS2 Node is known to be offline (and CN-GB reports no connection)
Action: Lei to follow up on this
Decision: no need to run the function test. To select performance tests. identify 3 or 4 centres, as a reference, to monitor the all 4 GBs if they behave consistently. Each GB to test the will test the metrics.
A discussion was raised regarding how to report on the functioning of Global Services and the required retention of metrics . For GB (France), Remy informed that the retention period is two weeks of archiving of archived metrics. For GM China and GM Morocco, the retention period is it also two weeks enough.
Chems informed that the retention for GM Morocco can be extended to one month.
(Hassan) how to report on the functioning of the Global Services, we can consider using the Jira system to provide statistics of GS performance.How long does GM (Morocco) retain the metrics and how much data space it takes? For GM
(China), the retention period is one month for the metrics. (Action) Lei to report the size of the retention. (GM) Morocco, 15 days for the retention of metrics. 50GB a week. frequency of scraping is 10 seconds. (Action) Jeremy and Rémy to discuss the report mechanism. (Rémy) we need to collectively define the KPI KPIs of global services performance to be presented at INFCOM-4.
Action: Remy, Jeremy, and Hassan will discuss the retention of the metrics in Geneva this week on the sideline of the Gateways meeting
Sheet #3: wmo_wis2_gb_msg_no_metadata_tot
...
Global Cache metrics
gc_metrics_analysis.xlsx sent by email from Jeremy
Nomenclature:
CN-GC = cn-cma-global-cache
UK/USA-GC = data-metoffice-noaa-global-cache
DE-GC = de-dwd-global-cache
JP-GC = jp-jma-global-cache
KR-GC = kr-kma-global-cache
...
Decision: we need to agree on the consistent metrics considering current DWD and Uk&USA implement differently.
Action: Jeremy, Rémy, Kai and Max to have a meeting this week to discuss the GC metrics.
...
… so recommend that we prioritise getting metrics for GB and GC consistent first.
Topic 3: 3-validation of discovery metadata at Global Discovery Catalogue; implementation of Global Broker “discard”
Tom presented the issue presented on GitHub regarding finding the best time to set properties.metadata_id as required #119.
(Rémy) currently, the properties of metadata is not mandatory. During ET-WISOP kick-off meeting, we notified that we will enable metadata validation at by 1st September . Two different datasets having one set of metadata is enough. Before 2027, to use the channel in the topic hierarchy2025. He highlighted if we are going to change the regulations we need to present it for INFCOM in 2026 for approval and EC, which means it will be done in 2027, which is too long. He proposed another approach by using the channel in metadata record.
(Kai) we should enforce the metadata in WIS2 exchange. The problem is if The issue is that if there is something wrong 's an error in GDC, it will break could disrupt data exchange. Canada GDC and Germany GDC, enforce the check. GDC got the single failure. GM, data from DWD is missing but we don’t update any metadata.
(Jeremy) the first part, because GB will need to look through GDC, if a metadata record is broken (or if the metadata fails validation by a GDC), the channel will be parsed down by GB. Then the data will be missing.
(Rémy) we We cannot use the metadata id on ID starting from 1st September 2025. A risk There's a risk that issues with one GDC having problems may could impact data sharing. To improve the reliability, we need to be loose more flexible rather than to be too strict.
Remy propose to combine the truth from all GDCs and create a reference based on that on GitHub
Actions
GM (Morocco) and GM (China) to share the GM broker endpoint with the Secretariat.
Kari and Steve to follow up to make sure more consistent GB (US) metrics reports
All to go through the list shared in the email to have a consistent metrics
...