Still, you can get the results of any show command you can do on the CLI and get the response in easy to parse JSON.The monitor will support both the Latency Busters Messaging (LBM) solution for streaming messaging and the Ultra messaging for the Enterprise (UME) messaging solution. Arista has eAPI, which is not a REST API, but JSON-RPC. Most of the switch vendors have some sort of API. An API call will generally provide more information, more quickly, with less overhead on the queried system. SNMP is far more limited to counters, gauges, and I think the strings max out at 255 characters. An API call can get me a lot of information formatted in easy to deal with JSON or even XML. Doable, but it's a pain in the ass.Īnother issue with SNMP is the very rudimentary data structure. You've got to run the MIB file through a MIB compiler to get the frickin' OID. The MIB file doesn't provide the OID, not in an easy to use format at least. If you want to get a bit of information, you can search the MIB to see if it's provided, and then you need the OID. Getting other information, that was a different matter. You could do that with switches and servers a like, and it was awesome. Specifically it was super easy, barely an inconvenience to setup MRTG (and later Cacti/RRDTool, etc.) to get graphs of network traffic. On one hand, back in the day it was a great way to get information from a device (it was the only way for a while). I have a love/hate relationship with SNMP. Lot of examples out there with python and node.js Lookup how to ingest real time API data into “insertyourtoolhere”. This collector can then export metrics to your data collector (i.e influxdb, prometheus) This is commonly resolved by a “collector” programmed by your devs from scratch to customize: inventory, credential management, collection interval, exception mgmt, and most importantly data structure. Now, like you explained, there will be certain metrics that a platform does not provide via SNMP/MDT, only REST. SNMP polling = MDT with periodic policy SNMP traps = MDT with on-change policy I see it as the next generation of SNMP polling+traps: You can set up devices to push data directly to your data collector. It’s a much more efficient transport than SNMP polling, CLI or REST collection. If you really want to get modern, you can explore Model-Driven Telemetry. I see REST more useful for transactional tasks like configuration changes.įor monitoring, good ol’ SNMP is already well integrated in most network monitoring applications. TL DR I don’t, unless it is the only option to gather statistics for the element of interest. Have any of you ever built a custom web application specifically to display their desired information in specific ways? I'm not an application or web developer by any means, so I can't speak to the complexity for a task like this, but I'm more looking into the need for something like this if there are existing commercial tools that do this already. This is no different than the request/response format which would occur for API calls.Īre there tools built to utilize API calls to network devices? These systems poll devices every second (or several seconds) for new data. We use a combination of SolarWinds, DNA centre, Intermapper, and a few other methods. Most environments, mine included, have a number of monitoring tools. What about for network monitoring? API calls to devices can obtain much of the same information, if not more detailed information than SNMP MIBs can get - but how could they be worked into an operations environment? With the increase of focus on DevOps has led to performing many actions and automated tasks with APIs! You can write a script that performs actions on a device or group of devices, and make intelligent decisions based on the CRUD responses. TL DR: How do you use REST APIs to improve your monitoring abilities?
0 Comments
Leave a Reply. |