Lack of Country Code in Network Delay Alarms Schema

[mohamedawnallah]

Issue:

In the current network delay alarms schema, there is no country code included, unlike the Hegemony Dependency Alarms response schema which contains the country code in the asn_name field. This poses a problem as we currently have around 5000 Network Delay Alarms (at the time of creating this issue). To retrieve the country code, we would need to make 5000 API requests (at least) to the network API endpoint. This approach lacks efficiency, particularly when the server experiences downtime due to high (or even low) concurrent user activity.

Proposed Solution:

We should consider adding the country code to the network delay alarms response schema. This would eliminate the need for additional API requests and improve the efficiency of the system.

Additional Information

We need the country code to plot the data on the World Map

[mohamedawnallah]

Maybe we could think of this solution after ending this project to avoid any regressions

[mohamedawnallah]

Still using IHR Networks API to get the country code from ASN number a bottleneck as you see today's there are New Edges huge alarms generated right now which correlates with the network disconnections

[romain-fontugne]

Are you still facing this issue?
I thought you could get country code from the grip api?

[mohamedawnallah]

Right, it is now solved. I'm gonna close it

[mohamedawnallah]

In today's 3-day IHR report, there are no Hegemony Alarms, which means all network delay alarms will request IHR Network API to get the country code, and that's overwhelming for the server. This kind of tight coupling between alarm types is not good in the long term.

I propose two potential solutions:

1. Add the country code in the response coming from the network delay alarm the same as the one in the Hegemony Alarms response.
2. Cache the resulting Country Codes from Network Delay after the first cache miss. However, it should be noted that this approach may not be scalable and could introduce unnecessary complexity.

[romain-fontugne]

ah, sorry we had some problems recently with the AS hegemony code. Hopefully it will be back to normal this week. But you are right these cascading problems are not good. Are you querying the network API with multiple ASN?
For example:

https://ihr.iijlab.net/ihr/api/networks/?number=2497,3356,174,1299,15169,13335

[mohamedawnallah]

I've just tried, and the performance is a lot better this way. By doing it this way, we achieve multiplexing and shift the load from the client side to the server side.

[romain-fontugne]

great :)

[romain-fontugne]

@mohamedawnallah I have been thinking again about this problem. We'll have that problem every time we had a new data source. So one way to really fix that problem is to get a complete list of AS names for example here:
https://ftp.ripe.net/ripe/asnames/asn.txt
That we can load when we start the global report.

What do you think?

[mohamedawnallah]

That sounds like a durable solution! The file size is 1Byte which is pretty good. I have one question regards Return AS names in all IHR alarms API This may be a low priority or at least we don't need in Global Report then?

[romain-fontugne]

Yes, then we don't need to change the API!👍