I think rtrdump should retain this functionality for machine based troubleshooting and monitoring purposes. The RTR serial number can otherwise only be extracted by running rtrdump in debug mode.
I realize there is rtrmon but it's use case seem to be quite different:
checkrtr is a shell script that can be dropped into any monitoring systems compatible with nagios plugins and will provide monitoring for availability and hung/stuck rtr server. It requires the user to know how to access the RTR endpoint and a sufficiently large check interval, but doesn't require any other inputs from the user.
rtrmon collects data from RTR endpoints, compares the data and provides the data for external consumption. It does not make it's own decision about whether a situation is good or bad, that is out of scope.
I don't see a lot of drawbacks to keep the rtr serial in the metadata json output of rtrdump.
Hello @job
in https://github.com/bgp/stayrtr/commit/38d058e133d97b8b2dae526d4da98fd561fa336b some metadata outputs (
Generated,ValidandSerial) were removed from rtrdump JSON output.I think rtrdump should retain this functionality for machine based troubleshooting and monitoring purposes. The RTR serial number can otherwise only be extracted by running rtrdump in debug mode.
My use-case is that I'm monitoring
serialincrease over time with rtrdump and alert when there is a hung rtr server: https://github.com/lukastribus/rtrcheck/blob/d072488ab9e0f9bf9afe16f62dcd5c07a311ac1e/rtrcheck#L101Tracked in https://github.com/lukastribus/rtrcheck/issues/1
I realize there is
rtrmonbut it's use case seem to be quite different:checkrtr is a shell script that can be dropped into any monitoring systems compatible with nagios plugins and will provide monitoring for availability and hung/stuck rtr server. It requires the user to know how to access the RTR endpoint and a sufficiently large check interval, but doesn't require any other inputs from the user.
rtrmoncollects data from RTR endpoints, compares the data and provides the data for external consumption. It does not make it's own decision about whether a situation is good or bad, that is out of scope.I don't see a lot of drawbacks to keep the rtr serial in the metadata json output of rtrdump.
Thank you, Lukas