Proposed metrics for Sensor Centre monitoring publication of GTS data in WIS2

[6a6d74]

Sensor Centre for monitoring publication of GTS data in WIS2: sgts

Metrics provided by this kind of Sensor Centre can be used to assess the publication of GTS-related WIS2 Notification Messages:

• GTS-to-WIS2 gateway
• WIS2 Node

This kind of Sensor Centre only subscribes to messages on "origin" topics so it does not collect information about the availability of GTS data from Global Caches. The Sensor Centre for Global Caches (SGC) should be used to determine variations between the availability of original and cached core data.

wmo_wis2_sgts_messages_gtsproperties_total

• labels: report_by | centre_id | cccc | data_policy
• description: Metric recording the number of messages containing valid properties.gts (TTAAii, CCCC) published by a WIS Centre on "origin" topics. Grouped by "report_by" (the centre_id for the sensor centre instance publishing the metric), "centre_id" (the centre_id of the source of the message), "cccc" (the international four-letter location identifier associated with the origin of the GTS bulletin, expressed in UPPERCASE), and "data_policy" (the data policy applied to the data object associated withe message, either "core" or "recommended").

wmo_wis2_sgts_messages_gtsproperties_invalid_format_total

• labels: report_by | centre_id
• description: Metric recording the number of messages containing invalid properties.gts (TTAAii, CCCC) published by a WIS Centre on "origin" topics. Grouped by "report_by" (the centre_id for the sensor centre instance publishing the metric), and "centre_id" (the centre_id of the source of the message).

A valid properties.gts shall contain:

• 1 (and only 1) subproperty: "ttaaii"
• 1 (and only 1) subproperty: "cccc"
• Any other subproperties are ignored
• properties.gts.ttaaii shall comprise a sequence of exactly 4 alphabetic characters following by 2 numeric characters (6 characters in total)
• properties.gts.cccc shall comprise a sequence of exactly 4 alphabetic characters

Notes:

• Alphabetic character case is ignored.
• TTAAii and CCCC values only checked for syntactic correctness - they are not cross-referenced against WMO Volume C1 to determine if they are valid GTS bulletin headers.

Example properties.gts:

"properties": { 
    … 
    "gts": { 
        "ttaaii": "ISMN01", 
        "cccc": "EGRR" 
    } 
} 

Why do we need these metrics?

wmo_wis2_sgts_messages_gtsproperties_total:

1. To count the number of WIS2 Notification Messages being published by the two GTS-to-WIS2 gateways allowing me to compare between them; and, if there are inconsistencies, allow me to dig into which CCCC are affected.
2. To count the number of WIS2 Notification messages with GTS properties being sent by Centres that have asked to decommission their Message Switch; we can dig by CCCC and compare numbers of GTS bulletins they're sending. Maybe we can directly compare by using the statistics from WNMs being published by the two GTS-to-WIS2 gateways for a given CCCC (assuming a CCCC will be associated with a single WIS Centre).
3. Vaguely interested to see if other WIS Centres are including GTS properties.

wmo_wis2_sgts_messages_gtsproperties_invalid_format_total:

1. To determine where GTS properties are being incorrectly added - particularly for centres that have decommissioned (or requested to decommission) their Message Switches. It's probably safe to assume the GTS-to-WIS2 gateways are behaving properly.

[6a6d74]

@golfvert - what do you think?

[golfvert]

For wmo_wis2_sgts_messages_gtsproperties_total, shouldn't we add the ttaaii as a label ?
Is there a computer usable list (excluding volume C1 in pdf !) of the known TTAAii/CCCC ?
If that is the case, we can have a third metrics on syntactically valid but otherwise "unknown" TTAAii/CCCC.

[6a6d74]

Adding label ttaaii to wmo_wis2_sgts_messages_gtsproperties_total:

This would be useful. I didn't suggest it initially as I thought that might generate too many individual labels to keep track of (there are many thousands!). But, thinking again, just because we create the label doesn't mean we need to look at all of them?

Computer usable list of TTAAii/CCCC:

Well - it would be useful to compare the TTAAii/CCCC pair with an authoritative list. Vol C1 is (sadly) incomplete/out of date. I don't know of another list that's complete. But perhaps the GTS-to-WIS2 Gateways could provide such based on all the traffic they're seeing? The list would not need to be updated after 31-Dec-2024 because no new AHLs (TTAAii, CCCC) will be allocated.

@kaiwirt - would it be possible to generate such a list?

If so, then we should also add @golfvert 's proposed additional metric wmo_wis2_sgts_messages_gtsproperties_unknown_total.

[golfvert]

I have completed the first version of the sensor centre, implementing three metrics:

• wmo_wis2_sgts_messages_gtsproperties_total
• wmo_wis2_sgts_messages_gtsproperties_notinC1_total
• wmo_wis2_sgts_messages_gtsproperties_invalid_format_total

Not sure what is the best way to view the results.
In Volume C1 used, there are a bit more than 120k combinations of TTAAii/CCCC.

All have the following labels:

• centre_id - who published the message
• report_by - the centre_id of the sensor center
• ttaaii
• cccc

For the notinC1 metrics, I have used https://github.com/wmo-im/VolumeC1

There are a lot of absent in Volume C1 TTAAii, CCCC published by the gateways...

[6a6d74]

@golfvert - I've created a PR to add these metrics. See PR #32
Note that I have not included the "data policy" label as suggested in my original post because, in hindsight, the use cases for these metrics don't look to distinguish between Core and Recommended data. That said, it would be useful to determine if all the GTS data published with Core data policy was being picked up by the Global Caches - but there may be other ways to determine that. Thoughts?