Repository navigation
NMS-9014: Provisioning detector reference docs - #8998
joseanesONMS wants to merge 5 commits into
Conversation
The JmxMonitor had a reference page, but the Jsr160Detector, the only JMX detector registered for provisioning, had none. Parameters and defaults come from JMXDetector, GenericJMXDetectorFactory, and JmxConnectionConfigBuilder; examples follow default-foreign-source.xml.
Twenty-four detectors registered as ServiceDetectorFactory services on develop had no reference page, including the line-oriented, SNMP-based, DHCP, NTP, ICMP, SMB, SSH, RADIUS, and general purpose detectors. Parameters and defaults come from each detector class and its base classes in opennms-provision and protocols/radius; examples validate against foreign-sources.xsd.
GenericServiceDetectorFactory sets detector parameters as bean properties, so the documented keys must match the setters: brokerURL and useNodeLabel (ActiveMQDetector), storedProcedure (JdbcStoredProcedureDetector), supported (LoopDetector), and authEnabled (WebDetector). Defaults now follow the code: DBTools.DEFAULT_URL for the JDBC detectors, the unset TcpDetector banner, HttpsDetector's port 443 and maxRetCode 500, and the WSManWQL service name.
dino2gnt
left a comment
dino2gnt
left a comment
There was a problem hiding this comment.
Comments inline. A fair number of these don't require documentation because they should be deprecated, some of them need to be evaluated for function before we bother adding docs for them.
There was a problem hiding this comment.
We need to confirm this detector is valid for modern versions of Citrix services. I don't know if ICA is still "a thing."
|
|
||
| The DhcpDetector finds DHCP servers in your network. | ||
| It uses the same DHCP client as the xref:service-assurance/monitors/DhcpMonitor.adoc[DhcpMonitor]: it sends a DISCOVER message to the interface and detects the service when the server answers with a valid response. | ||
| The CAUTION about UDP ports 67 and 68 on the DhcpMonitor page also applies to this detector. |
There was a problem hiding this comment.
We should validate that this service still exists and is in common use. if not, we shouldn't bother documenting it and should instead consider the detector for removal.
There was a problem hiding this comment.
It's fine to remove it.
There was a problem hiding this comment.
I don't believe this should be documented, but instead should be added to the deprecation list. There are better alternatives (WsmanWqlDetector, for example)
There was a problem hiding this comment.
I don't believe this should be documented, but instead should be deprecated and removed.
There was a problem hiding this comment.
Preferably with fire.
There was a problem hiding this comment.
I don't believe this should be documented, but instead should be deprecated and removed. Even Nagios discourages use of NRPE today.
There was a problem hiding this comment.
We should validate that this service is still in common use and still functions in the way this detector expects, or remove it.
There was a problem hiding this comment.
We should validate that this service is still in common use and still functions in the way this detector expects, or remove it.
There was a problem hiding this comment.
We should validate that this service is still in common use and still functions in the way this detector expects, or remove it.
There was a problem hiding this comment.
This should be deprecated, no documentation necessary. It may not even be functional: https://opennms.atlassian.net/browse/NMS-5894
There was a problem hiding this comment.
First pass:
-
The Jsr160Detector.adoc page gives the retries parameter as "Number of connection attempts". This is correct. But a value of 0 makes zero connection attempts, and the detector never detects the service. The other detector pages use 0 to mean "no retry after the first attempt". Add one sentence that says that a value of 0 disables detection.
-
The GpDetector.adoc page does not list the match parameter. The detector accepts this parameter, but it does not use it. Only banner controls the result. Add a row for match that says the detector accepts it and ignores it. The JMX page and the NTP page do the same for their unused parameters.
Overall... I think these are pretty decent. Nothing is over-stated from the spot checks I did and the new detectors all seem to be in alignment with how I'd expect the doc pages for them to look. Some of these we may want to deprecate though.
JMXDetector.isServiceDetected loops while attempts < retries, so a value of 0 makes no connection attempt and the service is never detected.
… caution GpClient stores match but never reads it, so the row says only banner decides the result. The DhcpDetector page now links the DhcpMonitor page whose caution it refers to.
|
@marshallmassengill @dino2gnt Addressed the concrete items:
The detectors questioned for deprecation or relevance (MSExchange, NotesHttp, Nrpe, Smb, Citrix, DominoIIOP, OmsaStorage, OpenManageChassis, Perc) are still open; I'll follow up on those separately. |
marshallmassengill
left a comment
marshallmassengill
left a comment
There was a problem hiding this comment.
I would remove the ones picked for deprecation and then this can probably be merged. The ones for deprecation can have their code removed but need NMS issues for it.
Documents the provisioning detector reference pages, split out of #8984; content checked against the code on develop, one commit per ticket.
reference/…/detectors/Jsr160Detector.adoc(new),JmxMonitor.adocopennms-provision/opennms-detector-jmx/…,core/jmx/api/…/JmxConnectionConfig*.javareference/…/detectors/*.adocopennms-provision/opennms-detector-*,protocols/radius/…/detector,opennms-provision-api/…/support/*Detector*.javaCorrections to existing docs (separate
NMS-9014: Fix …commits, each can be dropped on its own)brokerURL,useNodeLabel,storedProcedure,supported,authEnablednames; JDBCurl, WQLserviceName, TCPbanner, HTTPS defaultsNot addressed
The docs build adds no warnings (develop's two existing ones remain).
External References