Uploaded image for project: 'OpenNMS'
  1. OpenNMS
  2. NMS-13191

Improve usability and self-contained features of the Kafka Producer payload for metrics



    • Enhancement
    • Status: Resolved (View Workflow)
    • Low
    • Resolution: Fixed
    • Meridian-2020.1.6, 27.1.0
    • 29.0.0
    • Data Collection, OSGi
    • Security Level: Default (Default Security Scheme)
    • Horizon 2021 - Jun 23 - Jul 7
    • NB


      NMS-13185 was the first step in this direction, but there is a lot of room for improvements to make the Protobuf content for Collection Sets more useful and consistent with other APIs, so a given user can consume its information without the need to get content from other APIs to use it.

      We spoke about not changing APIs for current versions to avoid breaking the solution that users might be currently using. In that regard, Protobuf is perfect, as an old version of a ".proto" file can parse content from a newer ".proto" (even from different versions, and vice versa) if the definition is consistent.

      With that in mind, we can "keep" the implementation of the "instance" field as it is and mark it as deprecated on the newer versions of OpenNMS. That way, there is no "breaking" change to describe in the changelog.

      Then, we can introduce new fields to ALL the resource entities in the ".proto" files to make them more usable and independent. Those fields are:

      • id: The Resource ID, for instance node[Cisco:router1].interfaceSnmp[fa0_0]. This is required when using the Resources end-point or the Measurements API through ReST.
      • name: The unique identifier used to replace the raw index which is what we use within the Resource ID. For instance, fa0_0. That'd be the name of the directory or part where the RRD for the metrics live (or the Newts Identifier).
      • label: The resource label, or the human-readable content we see in the UI (which comes from the resource-type definition and what the resources end-point will show). For instance, Fa0/0.
      • index: The raw identifier of a row from a tabular data like an SNMP Table (this would be the ifIndex for Interface Resources or the OID that represents the index of a table, and so on). Note that for interface resources as part of the solution for NMS-13185, the field would be called ifIndex and will be numeric.
      • type: The resource type identifier (or the resource type name). This would only apply to generic index resources, and it is already part of that entity in the ".proto" file.
      • typeLabel: The label of the resource type (optional but useful, as the resources end-point provides it).

      All the above fits perfectly for Interface Resources and Generic Index Resources from the SNMP perspective. I know that some of those entries might not apply to other protocols, but I believe it worth, for consistency, having all of them.

      If we go this route, we would have a backward-compatible API (as instance won't be changed but marked as deprecated), and we will introduce new fields with all the necessary content to make the ".proto" content self-contained and independent; meaning a given user wouldn't have to look other sources to consume it and use it. That's because it was precisely the lack of why the old TCP Exporter was never useful, and I believe we should avoid that same mistake on the Kafka Producer.


        Issue Links



              cgorantla Chandra Gorantla
              agalue Alejandro Galue
              0 Vote for this issue
              3 Start watching this issue



                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.