Objective

Enable Pollerd-generated metrics to carry enriched metadata by referencing associated SNMP interface data when available. This will provide additional context for metrics related to IP interfaces, leveraging metadata such as ifAlias, ifName, and ifDescr from SNMP interfaces when an association exists.

Current Limitations

1. Resource Identification Only: Pollerd currently sends metrics to the time series layer with only the resourceId, lacking broader identifiers like nodeId or IP-related metadata, which limits context.

2. No Cross-Reference for Metadata: Metrics generated by Pollerd lack access to rich metadata gathered from SNMP interfaces in Collectd.

Functional Requirements

1. Enrichment of Pollerd Metrics: Metrics generated by Pollerd for IP interfaces should include metadata tags (like ifAlias, ifName, and ifDescr) if an associated SNMP interface exists.

2. Cross-Referencing Capability: Pollerd should be able to cross-reference IP interfaces with corresponding SNMP interfaces to retrieve additional metadata when possible.

Suggested Approaches for Implementation

We leave the specifics of implementation to the maintainers, but the following options could be considered:

1. Leverage Database Access:

   • Since OpenNMS already stores SNMP interface metadata in the database (likely accessed via the ORM layer such as Hibernate), Pollerd could query or retrieve these associations directly from the database rather than from Collectd.

   • Suggestion: A lightweight query mechanism or an ORM-based lookup to retrieve SNMP metadata when generating Pollerd metrics.

2. Centralized Metadata Store or Cache:

   • Implementing a shared metadata service or caching layer might help avoid repeated direct queries, especially in environments with high polling frequencies.

   • Suggestion: A caching mechanism that maps IP interfaces to associated SNMP metadata could help reduce load and improve performance, especially in environments where the same associations are queried frequently.

3. Incremental Synchronization:

   • If feasible, Pollerd could receive regular updates about interface associations from Collectd or a centralized metadata registry, allowing it to keep a local or session-based cache of these relationships. This approach would limit the load on the database or Collectd during metric generation.

   • Suggestion: Explore the possibility of an asynchronous synchronization job that updates mappings between IP interfaces and SNMP metadata periodically.

Example Workflow

1. Pollerd polls an IP interface (e.g., 192.168.1.1) and initiates metric generation.

2. Pollerd attempts to identify if an associated SNMP interface exists, either by querying the ORM/database layer, consulting a centralized metadata store, or using an in-memory cache.

3. If a match is found, Pollerd enriches the metric with metadata tags from the SNMP interface (ifAlias, ifName, ifDescr).

4. The enriched metric, now carrying more context, is sent to the time series integration layer.

Benefits

• Enhanced Observability: Detailed interface metadata improves situational awareness and provides richer context for troubleshooting.

• Seamless Integration: Aligning Pollerd and Collectd metadata creates a more cohesive view of network performance.

• Scalability Considerations: Implementing a metadata caching strategy or batched synchronization can help balance performance in high-frequency polling environments.