Enhancment: sheduled SNMP importer

Feature Requests
1

HI Michael,
I highly appreciate a SNMPcollector for Dataimport in DataGerry.
Sheduling the import of information what could be received from network devices by SNMP on a daily/weekly/monthly base.
Automatically when changing information in a Device credentials for that specific device or by request of administrator by Button on Device details page would help quickly update the Information directly after a change.
A possibility to store such data collectors by templates for different types of Devices would help administrating general collection or type specific device information.
That would help us to automate the information gathering.
Kind Regards
Joachim

2

Hi Joachim,

welcome to our community and thanks for your enhancement request. This is a request I heard from a lot of people. So, we definitively will implement such a function in DATAGERRY. We have to do some work before that to make our base system more comfortable, but I think a realistic timeframe for working on that feature will be the second half of 2020.

I already opened an issue for that in our issue tracker some time before (NET-3). At the moment, this issue is more a reminder and needs some more specification, which I will do in a few months. If you are interested, I will get back to you to discuss a possible implementation.

Best regards
Michael

3

Hi Michael
that would be a honour for me if we could share some ideas of the functions surrounding this SNMP Collector. As I already wrote in my initial Statement, not only the RAW possibility of Collection is needed also the Triggers when this will be done (time sheduled, action triggered or simply by press a button) or the flexibility to use different templates for filling the same field for different device-types by filtering on Device information like SNMP VendorID is needed.
Looking forward for your invitation!
Kind Regards
Joachim

4

Thanks a lot, Joachim! I’ll get back to you soon, when we design such a feature. It would be nice, to get and share some ideas, before we start with our implementation.

5

I would appreciate if such a reconciliation interface would be open and not only bound to SNMP as protocol (which should be already dead, according to my supplyers :wink: )
Most vendors nowadays have APIs implemented (NETCONF, YANG, RESTCONF a.s.o.) that are able to provide Inventory Data in a structured model which is even a lot nicer to integrate as raw SNMP data.

For Exampe

<chassis-inventory xmlns="http://xml.juniper.net/junos/15.1F7/junos-chassis">
    <chassis junos:style="inventory">
        <name>Chassis</name>
        <serial-number>[...]</serial-number>
        <description>MX480</description>
        <chassis-module>
            <name>Midplane</name>
            <version>REV 44</version>
            <part-number>750-047862</part-number>
            <serial-number>[...]</serial-number>
            <description>Enhanced MX480 Midplane</description>
            <model-number>CHAS-BP3-MX480-S</model-number>
        </chassis-module>
        <chassis-module>
            <name>FPM Board</name>
            <version>REV 04</version>
            <part-number>760-059208</part-number>
            <serial-number>[...]</serial-number>
            <description>Front Panel Display</description>
            <model-number>CRAFT-MX480-S</model-number>
        </chassis-module>
        [...]
6

Thanks for this idea, @andsch!

Of course, a discovery/import interface should be generic and support multiple protocols (e.g. SNMP, NETCONF, …). I think a good way, is to also support plugins for adding new protocols in an import/discovery API.