22191 Network interfaces: reveal index, description and alias in details
The interface check summary shows a single bracketed value, e.g. [tun0].
That value can come from ifIndex, ifDescr, ifAlias or ifName, and there
was no way to tell which one it was, nor whether the device populates
the others at all. Deciding whether to switch "Appearance of network
interface" in the discovery ruleset therefore required an SNMP walk or
guesswork.
_interface_name() now attaches an identification block to the details:
Index: 3
Description: tun0
Alias: not set
Service item based on: description (ifDescr)
Index, Description and Alias are always listed, with "not set" where the
device leaves a field empty, so it is visible which fields the device
actually fills. Name is added when ifName is populated.
The provenance line is authoritative rather than inferred: discovery
already persists the used appearance as the "item_appearance" parameter
and the check reads it back. Deriving it from the item string would be
wrong, since _compute_item silently falls back to the padded index and
duplicate items get " <index>" appended.
Interface groups are excluded, since _accumulate_attributes overloads
alias with meta text and a block there would be misleading. Services
whose summary had no bracketed part now emit a details-only Result via
notice=, which is exactly the case where "does this device populate
anything?" matters most.
The service summary and $SERVICEOUTPUT$ are unchanged.
$LONGSERVICEOUTPUT$ now carries the block above in place of the
bracketed value that was previously repeated there. Test expectations
across the interface-based plugins are updated accordingly, including
the two cluster helpers that assumed summary and details are equal.
CMK-10025
Change-Id: I15992dae465e694ddbfb791304f82d712ee06175 F
Frans Fürst committed
2bd06954f35f06f7b857e25eb2c8f900511f1986
Parent: 4edd49b
Committed by Jenkins <jenkins@review.lan.tribe29.com>
on 8/21/2026, 9:37:01 AM