Prospective users often try to figure out how indeni will fit in their environment. This document will hopefully help you visualize this better.
The world before indeni
Since you’re reading this, we’ll assume you are responsible for some kind of Network Devices – switches, routers, firewalls, load balancers, etc. If you have a sizable deployment, you probably also use a Manufacturer-Provided Management Application (such as Palo Alto Networks Panorama, F5 Enterprise Manager, Check Point Provider-1, Cisco Prime, etc.). These management applications are great for configuring your devices, but generally are somewhat challenged in providing you with insight into the operational health of those devices.
We’d also bet you have a Network Monitoring System to see how your environment is doing – maybe one of the more expensive products (HP NNMi), or the cheaper ones (SolarWinds Orion NPM) or even the free ones (Nagios). These systems are great at telling you what’s up, what’s down and show green or red lights. However, making sense of the data is difficult, and they generally “dumb-it-down” to the lowest common denominator. So the level of visibility you get is low.
You may have your Network Devices send their logs to a Log Server – such as Splunk (if you’ve got more budget) or Kiwi (if less). These are extremely useful at storing logs and helping you sift through them and run complex queries – to troubleshoot an issue once it happens. They are not good at telling you before a problem happens, because they don’t truly understand what the logs mean.
In larger enterprises we also see IT Operations Management systems, which centralize the monitoring information coming out of various systems as well as help with tracking service tickets, assets, etc.
If you are on the security side of the house in larger organizations you may also be using a Firewall Policy Manager, such as Tufin or Algosec, which is great for tracking how well the firewall policy is configured.
Where does indeni fit?
indeni was created to deal with specific shortcomings of the setup described above. Namely – that there are many systems out there that are great at collecting data (logs, configs, stats, etc.) but not very good at making sense of it. So, naturally, we’ve invested most of our R&D effort into the mechanisms required to figure out what to do with the data and how to make it actionable. Specifically, providing pin-point insights and suggesting remedial action to ensure problems are averted.
However, we also had another requirement – indeni must be easy to set up and take no more than an hour to get up and running. To achieve this, we needed to have indeni capable of collecting the data it needs on its own (hence the direct arrows from the Network Devices to indeni in the diagram). When indeni finds an issue, it will send alerting information over to the operations’ management systems as well as emails directly to the operations and engineering teams.
To summarize– indeni fits side by side with your current systems to ensure you get actionable alerts while keeping your current operations’ processes the same. It automatically makes sense of the data and runs the troubleshooting steps required to get to the bottom of many issues.
Interested in digging deeper?
- Comparing indeni and Algosec/Firemon/Tufin
- SolarWinds© NPM© & NCM© vs indeni
- Manual Creation of Log Rules Is So 1999
- How does indeni work?
Are you ready for 99.9999%? Try indeni for free and see what is lurking in your network.