Open athompson-merlin opened 7 months ago
I wrote up mini KB pages for each alert type with extra info on how/why they are generated, for example: https://bgp.tools/kb/alert-help-hijack
These are now also provided as links on each alert details page:
I also added "mire detail" URLs to a handful of alerts where it now makes sense to do so
,That's helpful, but in the example I linked to, what I had in mind (put didn't put into writing, my bad...) was more that - great, there's a hijack for prefix X, great, and it's being done by AS X, great, and the new is is [ X ], great... but until I'm faimiliar with the system I have no clue what data you're using to trigger this alert, i.e. I don't know why I'm getting this alert in the first place.
I can't figure out from the alert that I manually added this prefix during setup, thereby telling your system that AS16796 should always be advertising it.
(I also certainly can't tell that I have to click on my ASN in the top-right corner, then the Monitoring tab, then Settings, then click "Edit" beside AS16796, then remove that prefix from the table, but that's a separate ticket about the UI/UX...)
Further in that vein... the detection logic obviously already looked up the relevant IRR and RPKI records and based on them decided NOT to suppress the alert... having those shown to me (hyperlinks would help) would let me understand that I forgot to edit the !@#$%^ RADB IRR record when I changed what router advertises this prefix.
I think exposing the "business logic" would be significantly more helpful than a "something is wrong" email.
I saw the new text in the latest alert, that's helpful, thank you!
URL:
Browser (User-Agent if you can):
Error base64 blob (If a site error):
What were you expecting:
What happened: