Our network engineers wanted to eliminate unnecessary customer calls, and wanted to concentrate on providing a fast and stable network. To reach this goal, a new approach to proactive monitoring needed to be implemented.
Nagios, Zabbix, Cacti, and SmokePing are great monitoring tools. They are missing something important though. The data they collect only shows metrics based on where they are installed. One option was to configure multiple distributed instances, which is terribly complex and not scalable at all.
Customers would call to complain that the internet was slow, some sites are slow, or their emails were not sending. We had no way of checking this without having the customer run tests for us, or remotely control their PC and run the same mundane tests that we always do.
PACKY is designed to be easy, scalable, and reliable.
Initial setup is a one-time process, and includes registering an account on packy.io and configuring modules to use, and targets to test, as well as schedules (how often to run these tests).
See packy.io/solutions for guidelines, and to learn about different monitoring approaches.
Once the initial setup is done, it’s time to deploy! Every agent by default uses the global settings that you defined in step 1. So deploy as many agents as you like, and they will all do as instructed by your defined schedules and tests.
You may of course customise tests per agent. Our roadmap includes the ability to define groups of agents to apply configuration templates, but for the time being you have the flexibility to define custom targets per agent.
We recommend to use our hardware agents. They are cost effective and work from whatever network they are connected to. The only requirement is to log into the web interface of the agent and enter your packy.io username and password to tie the agent to your dashboard.
We designed this monitoring system with ease of configuration and deployment as a primary factor. This is because we are network operators too, and know that we have other things we would rather be doing. Any future configuration will only be required if you need to change some testing parameters (such as new targets) or perhaps we have a shiny new module that you want to install!