We have a client who is a global logistics company, and we use NPM to manage their devices globally. These devices are network and network security devices.
We take configuration backups and have predefined templates that we push. We also use NPM for reporting purposes, network configuration comparisons, firmware upgrades, and more. There are many use cases.
The availability and reachability of the CIs are valuable. Since it works on SNMP, it collects a lot of data from the CIs, meaning the devices.
It also confirms device availability uptime and provides information on errors, basic configurations, snapshots, CPU and memory utilization, and the overall health of your CI.
It gives you a picture without needing to directly access the CI. It also maintains historical data, so you can go back and see the performance and health of the device over time.
The alerting system in SolarWinds NPM aids in proactive network management. Once you have the basic data available, you can tweak it based on your standard threshold.
You can use the standard threshold defined by SolarWinds, which is globally accepted, or you can customize them. Based on these thresholds, you can configure alerts that are triggered when the threshold is hit.
For example, CPU or memory utilization, or the bandwidth of a particular link. The alerting mechanism continuously monitors and samples data, and based on that, generates alerts for users who can proactively act on them and mitigate the problem.
AI-driven initiatives:
We are planning to switch to SolarWinds' new licensing model called the observability layer, where you only need to buy a single license. We are working on that and looking for stakeholder justification for the cost before implementing it. I am aware of the AI functionality that SolarWinds offers. Recently, we migrated our on-premises SolarWinds solution to the Azure cloud.
Challenges with migration:
It was challenging because it was a ten-year-old system. We had to figure out a different approach when I was onboarded. There was also no firmware upgrade done, so we couldn't just do a simple migration. We had to build a completely new setup and then migrate the database.
However, it wasn't a big challenge because we planned it well and kept a close eye on the implementation. We completed it in three months with minimal downtime, which the client appreciated.
The resources required for the migration process depend on the approved timelines and workload. For my migration, the timelines were aggressive, and there were multiple modules, so we had to put two resources on each bundle of modules. If the workload is not as heavy and the timelines are flexible, it can also be done with two resources working continuously.