When attempting to help a customer with debugging the Radius monitoring capabilities of OpenNMS, we start with troubleshooting the detector abilities to find the Radius service. However, the logging is eating an exception and making it impossible to debug the reason for failing to connect. The logging is also sparse and confusing where sometimes the nodelabel is printed and other times it's not as well as sometimes there are || used as a token separator. Mainly, though, the reason is hidden from the user since there is no "reason" code like there is in the poller. Here is the current logging with DEBUG enabled:
2012-01-06 11:39:40,547 INFO [scanExecutor-23] IpInterfaceScan$2: Attemping to detect service Radius on address 1.1.1.1 2012-01-06 11:39:40,547 INFO [scanExecutor-23] RadiusAuthDetector: Address: ca1/1.1.1.1 || port: 1812 || 2012-01-06 11:39:40,548 INFO [scanExecutor-23] NullDetectorMonitor: Checking address: ca1/1.1.1.1 for Radius capability 2012-01-06 11:39:40,583 INFO [scanExecutor-23] NullDetectorMonitor: Attempting to connect to address: 1.1.1.1 port 1812 attempt #0 2012-01-06 11:39:40,593 INFO [scanExecutor-23] NullDetectorMonitor: Radius: Failed to detect Radius on address 1.1.1.1 port 1812 2012-01-06 11:39:40,593 INFO [scanExecutor-23] NullDetectorMonitor: Radius: An undeclared throwable exception was caught contating address 1.1.1.1 port 1812 2012-01-06 11:39:40,604 INFO [scanExecutor-23] IpInterfaceScan$1: Attempted to detect service Radius on address 1.1.1.1: false
Acceptance / Success Criteria
None
Lucidchart Diagrams
Activity
Show:
Seth Leger January 16, 2012 at 11:26 PM
Edited
I've improved the logging inside the NullDetector class so that it will log a stack track if an IOException or Throwable is caught. This shouldn't be too chatty since these are unexpected conditions to be in, ie. not a timeout, routing failure, or other common cause of a detection failure.
When attempting to help a customer with debugging the Radius monitoring capabilities of OpenNMS, we start with troubleshooting the detector abilities to find the Radius service. However, the logging is eating an exception and making it impossible to debug the reason for failing to connect. The logging is also sparse and confusing where sometimes the nodelabel is printed and other times it's not as well as sometimes there are || used as a token separator. Mainly, though, the reason is hidden from the user since there is no "reason" code like there is in the poller. Here is the current logging with DEBUG enabled:
2012-01-06 11:39:40,547 INFO [scanExecutor-23] IpInterfaceScan$2: Attemping to detect service Radius on address 1.1.1.1
2012-01-06 11:39:40,547 INFO [scanExecutor-23] RadiusAuthDetector: Address: ca1/1.1.1.1 || port: 1812 ||
2012-01-06 11:39:40,548 INFO [scanExecutor-23] NullDetectorMonitor: Checking address: ca1/1.1.1.1 for Radius capability
2012-01-06 11:39:40,583 INFO [scanExecutor-23] NullDetectorMonitor: Attempting to connect to address: 1.1.1.1 port 1812 attempt #0
2012-01-06 11:39:40,593 INFO [scanExecutor-23] NullDetectorMonitor: Radius: Failed to detect Radius on address 1.1.1.1 port 1812
2012-01-06 11:39:40,593 INFO [scanExecutor-23] NullDetectorMonitor: Radius: An undeclared throwable exception was caught contating address 1.1.1.1 port 1812
2012-01-06 11:39:40,604 INFO [scanExecutor-23] IpInterfaceScan$1: Attempted to detect service Radius on address 1.1.1.1: false