What Are Network Monitoring Tools?

Network monitoring tools continuously observe the health, performance, and availability of network infrastructure—routers, switches, firewalls, load balancers, servers, and the links between them. They collect metrics such as latency, packet loss, bandwidth utilization, and interface errors, then surface alerts when values breach defined thresholds. For DevOps teams, these tools are a foundational layer of observability alongside application performance monitoring (APM) and log management.

Notable Platforms in the Space

The following tools are widely referenced in enterprise and open-source contexts. This is not an exhaustive list, and capabilities change with each release—always verify current feature sets against vendor documentation.

Nagios

Nagios is one of the oldest open-source network and infrastructure monitoring platforms. Its plugin architecture allows engineers to monitor virtually any service or device. Nagios Core is free and self-hosted; Nagios XI is a commercial product that adds a web UI, reporting, and configuration wizards. Nagios is widely used in Linux-centric environments and has a large community plugin library.

Zenoss

Zenoss is an IT monitoring platform with roots in open source (Zenoss Core) and a commercial offering (Zenoss Cloud). It uses a model-driven architecture that automatically discovers and maps network topology. Zenoss is often chosen by enterprises that need unified monitoring across on-premises infrastructure and cloud workloads.

Riverbed

Riverbed is better known for WAN optimization but also offers network performance management through its Riverbed NetProfiler and AppResponse products. These focus on flow-based analysis and packet-level visibility, making them particularly relevant for diagnosing application performance over wide-area networks.

Zoho Network Monitor (ManageEngine)

Zoho’s IT management arm, ManageEngine, offers OpManager for network monitoring. It covers SNMP-based device monitoring, flow analysis, and configuration management, and targets both SMEs and larger enterprises with tiered licensing.

Other Widely Used Alternatives

• PRTG Network Monitor (Paessler) – sensor-based model with an out-of-the-box web UI, popular with SMEs.
• Zabbix – open-source, agent and agentless, strong SNMP and IPMI support.
• Datadog Network Performance Monitoring – SaaS, integrates tightly with cloud-native stacks.
• SolarWinds NPM – enterprise-grade, strong auto-discovery and topology mapping.
• Grafana + Prometheus – popular open-source stack for metrics collection and visualization, often combined with SNMP exporters for network devices.

Key Market Segments

When evaluating or comparing solutions, the market is typically segmented along two axes:

By Organization Size

• Small and Medium Enterprises (SMEs) – typically prioritize ease of deployment, low total cost of ownership, and SaaS delivery to avoid managing monitoring infrastructure.
• Large Enterprises – often require on-premises or hybrid deployment, fine-grained role-based access, compliance reporting, and the ability to monitor tens of thousands of devices at scale.

By Deployment Model

• On-premises / self-hosted – full control, required for air-gapped or highly regulated environments.
• SaaS / cloud-hosted – lower operational overhead, faster time to value, suits distributed teams.
• Hybrid – collector agents run on-premises, data is aggregated in the cloud.

Core Capabilities to Evaluate

When assessing any network monitoring tool, measure it against the following capabilities:

Open Source vs. Commercial: A Practical Comparison

Open Source (e.g., Nagios Core, Zabbix, Grafana/Prometheus)

• No license cost, but engineering time is required for setup, maintenance, and scaling.
• Large community plugin ecosystems.
• Best suited to teams with strong Linux and scripting skills.
• Total cost of ownership can exceed commercial options at scale when staff time is factored in.

Commercial (e.g., Zenoss Cloud, PRTG, Datadog, SolarWinds)

• Support contracts and SLAs reduce operational risk.
• Richer out-of-the-box dashboards, reporting, and integrations.
• License costs can be significant at high device counts—model pricing carefully.
• Vendor lock-in is a real consideration for long-term architecture decisions.

Trends Shaping Network Monitoring

• AIOps and anomaly detection – machine-learning baselines replace static thresholds for dynamic cloud environments.
• Observability convergence – vendors are merging metrics, traces, and logs into unified platforms (e.g., Datadog, Dynatrace, New Relic).
• Cloud-native networking – Kubernetes networking (CNI plugins, service meshes like Istio) requires new monitoring approaches beyond traditional SNMP polling.
• eBPF-based monitoring – tools like Cilium and Hubble use eBPF to provide deep kernel-level network visibility without agents.
• Network as Code – monitoring configurations are increasingly version-controlled and deployed via CI/CD pipelines alongside infrastructure.

Choosing the Right Tool for Your Environment

There is no single best network monitoring tool. Selection should be driven by:

1. Scale – how many devices and interfaces need to be monitored?
2. Team skill set – can you maintain an open-source stack, or do you need vendor support?
3. Environment type – on-premises data center, cloud-native, or hybrid?
4. Compliance requirements – does data sovereignty or audit logging constrain deployment options?
5. Existing toolchain – which alerting, ticketing, and incident management tools do you already use?
6. Budget – model both license costs and the engineering hours required to operate the platform.

Running a proof-of-concept in a staging environment against your actual device inventory is the most reliable way to surface gaps before committing to a platform.

What Is Cacti?

Cacti is an open-source network monitoring and graphing tool written in PHP, released under the GNU General Public License. It uses MySQL as its backend database and relies on RRDtool (Round-Robin Database tool) to store and render time-series performance data. Cacti has built-in SNMP support, making it well-suited for polling network devices such as routers, switches, and servers.

Deploying Cacti manually involves installing and configuring several interdependent components. This article walks through automating the entire process with Ansible, reducing a multi-step manual procedure to a single playbook invocation.

Environment Overview

The walkthrough uses the following environment:

• Target host: CentOS 6.8 virtual machine running on KVM
• Control node: Parabola GNU/Linux-libre x86_64 running Ansible 2.2.1.0
• Guest VM IP: 192.168.122.98

Security note: SELinux is disabled in this demonstration to simplify the walkthrough. Set SELINUX=disabled in /etc/selinux/config and reboot the VM only for testing purposes. Always enable and properly configure SELinux in production environments.

Inventory and Directory Structure

The Ansible project uses the following layout:

ansible/inventory/kvm/inventory
ansible/inventory/kvm/group_vars/all/all.yml

The inventory file defines the target CentOS VM:

centos ansible_host=192.168.122.98 ansible_connection=ssh ansible_user=root ansible_password=password

Add a corresponding entry to the control node’s /etc/hosts:

192.168.122.98 centos

The all.yml group variables file references sensitive values from an Ansible Vault file rather than storing them in plain text:

---
mysql_cacti_password_hash: "{{ vault_mysql_cacti_password_hash }}"

mysql_username: "{{ vault_mysql_user }}"
mysql_password: "{{ vault_mysql_password }}"

The main playbook file cacti.yml lives under ansible/playbooks/configuration/.

Managing Secrets with Ansible Vault

Ansible Vault encrypts sensitive files so that credentials are never stored in plain text. Set your preferred editor before creating a vault file:

$ export EDITOR=nano

Create the vault file to hold MySQL credentials:

$ ansible-vault create inventory/kvm/group_vars/all/vault.yml

Ansible will prompt for an encryption password, then open your editor. Enter the credentials and save the file:

---
vault_mysql_cacti_password_hash: "*528573A4E6FE4F3E8B455F2F060EB6F63ECBECAA"

vault_mysql_user: "cacti"
vault_mysql_password: "cacti123"

To edit the vault file later, use:

$ ansible-vault edit inventory/kvm/group_vars/all/vault.yml

Ansible will prompt for the vault password before decrypting the file for editing.

Important: The password shown above (cacti123) is a placeholder for demonstration only. Use strong, unique credentials in any real deployment.

Play 1: Install Apache HTTP Server

The first play installs the Apache web server. It updates the package cache, installs httpd and supporting utilities, starts the service, and waits until port 80 is accepting connections before continuing.

---
- name: Install web server
  hosts: centos
  gather_facts: true
  tags: [httpd]

  tasks:
    - name: Update the software package repository
      yum:
        name: '*'
        update_cache: yes

    - name: Install HTTP packages
      package:
        name: "{{ item }}"
        state: latest
      with_items:
        - wget
        - nano
        - httpd
        - httpd-devel

    - name: Start the httpd server
      service:
        name: httpd
        state: started

    - wait_for:
        port: 80

Play 2: Install MySQL, PHP, RRDtool, and SNMP

The second play installs Cacti’s core dependencies: MySQL, a full set of PHP extensions, RRDtool, and the SNMP utilities. After installation, both the SNMP daemon and the MySQL server are started, and the play waits for MySQL to become available on port 3306.

- name: Install MySQL, PHP packages
  hosts: centos
  become: yes
  become_method: sudo
  gather_facts: true
  tags: [database-web]

  tasks:
    - name: Install database/web packages
      package:
        name: "{{ item }}"
        state: latest
      with_items:
        - mysql
        - mysql-server
        - MySQL-python
        - php-mysql
        - php-pear
        - php-common
        - php-gd
        - php-devel
        - php
        - php-mbstring
        - php-cli
        - php-process
        - php-snmp
        - net-snmp-utils
        - net-snmp-libs
        - rrdtool

    - name: Start snmpd server
      service:
        name: snmpd
        state: started

    - name: Start mysqld server
      service:
        name: mysqld
        state: started

    - wait_for:
        port: 3306

Play 3: Install Cacti from EPEL

Cacti is available in the EPEL (Extra Packages for Enterprise Linux) repository, which is not enabled on CentOS by default. This play imports the EPEL GPG key, adds the EPEL repository, updates the package cache, installs Cacti, and creates a dedicated MySQL database user for the application.

- name: Install Cacti
  hosts: centos
  become: yes
  become_method: sudo
  gather_facts: true
  tags: [cacti]

  tasks:
    - name: Import EPEL GPG key
      rpm_key:
        key: http://dl.fedoraproject.org/pub/epel/RPM-GPG-KEY-EPEL-6
        state: present

    - name: Add YUM repo
      yum_repository:
        name: epel
        description: EPEL YUM repo
        baseurl: https://dl.fedoraproject.org/pub/epel/$releasever/$basearch/
        gpgcheck: yes

    - name: Update the software package repository
      yum:
        name: '*'
        update_cache: yes

    - name: Install cacti
      package:
        name: "{{ item }}"
        state: latest
      with_items:
        - cacti

    - name: Create cacti database user
      mysql_user:
        name: cacti
        password: "{{ mysql_cacti_password_hash }}"
        encrypted: yes
        priv: '*.*:ALL,GRANT'
        state: present

Play 4: Apply MySQL Timezone Bug Fix

MySQL 5.1.73-8 (the version shipped with CentOS 6) lacks timezone data in its system tables, which causes Cacti to report an error. To resolve this, the mysql_test_data_timezone.sql file must be imported into the mysql database, and the cacti user must be granted SELECT access to the time_zone_name table.

This fix is tracked in the Cacti project as issue #242. Isolating it in its own play (or separate playbook) makes it easy to skip once you upgrade to a MySQL version where the bug no longer applies.

- name: For bug https://github.com/Cacti/cacti/issues/242
  hosts: centos
  become: yes
  become_method: sudo
  gather_facts: true
  tags: [bug]

  tasks:
    - name: Import mysql_test_data_timezone.sql
      mysql_db:
        state: import
        name: mysql
        target: /usr/share/mysql/mysql_test_data_timezone.sql

    - name: Grant privileges
      mysql_user:
        name: cacti
        append_privs: true
        priv: 'mysql.time_zone_name:SELECT'
        state: present

Play 5: Configure Cacti

The final play ties everything together:

• Creates the cacti database and imports the Cacti schema (cacti.sql)
• Updates database credentials in /etc/cacti/db.php using the lineinfile module
• Opens port 80 in iptables
• Updates /etc/httpd/conf.d/cacti.conf to allow access from all hosts (adjust this for production)
• Enables the Cacti cron poller by uncommenting its entry in /etc/cron.d/cacti
• Restarts both MySQL and Apache, then waits for each to become available

- name: Configuration
  hosts: centos
  become: yes
  become_method: sudo
  gather_facts: true
  tags: [config]

  tasks:
    - name: Create a database for cacti
      mysql_db:
        name: cacti
        state: present

    - name: Import cacti.sql
      mysql_db:
        state: import
        name: cacti
        target: /usr/share/doc/cacti-1.0.4/cacti.sql

    - name: Update database credentials in config file
      lineinfile:
        dest: /etc/cacti/db.php
        regexp: "{{ item.regexp }}"
        line: "{{ item.line }}"
      with_items:
        - { regexp: '^\$database_username', line: "$database_username = '{{ mysql_username }}';" }
        - { regexp: '^\$database_password', line: "$database_password = '{{ mysql_password }}';" }

    - name: Allow port 80
      shell: iptables -I INPUT 5 -p tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT

    - name: Update access in cacti.conf for httpd
      replace:
        dest: /etc/httpd/conf.d/cacti.conf
        regexp: "{{ item.regexp }}"
        replace: "{{ item.replace }}"
      with_items:
        - { regexp: 'Require host localhost', replace: 'Require all granted' }
        - { regexp: 'Allow from localhost', replace: 'Allow from all' }

    - lineinfile:
        dest: /etc/cron.d/cacti
        regexp: '^#(.*)$'
        line: '\1'
        backrefs: yes

    - name: Restart mysqld server
      service:
        name: mysqld
        state: restarted

    - wait_for:
        port: 3306

    - name: Restart the httpd server
      service:
        name: httpd
        state: restarted

    - wait_for:
        port: 80

The Cacti cron poller runs every five minutes to collect device metrics:

*/5 * * * * cacti /usr/bin/php /usr/share/cacti/poller.php > /dev/null 2>&1

Running the Full Playbook

Once all plays are defined in cacti.yml, run the complete deployment with a single command. The --ask-vault-pass flag prompts for the Ansible Vault password so that encrypted credentials can be decrypted at runtime:

$ ansible-playbook -i inventory/kvm/inventory playbooks/configuration/cacti.yml --ask-vault-pass

After the playbook completes successfully, navigate to http://<VM_IP>/cacti in a browser to run the Cacti web installer. The default login credentials are admin / admin; you will be prompted to change the password immediately after first login.

Key Takeaways

• Ansible Vault keeps database credentials out of source control while still making them available to playbooks at runtime.
• Tagging plays (httpd, database-web, cacti, bug, config) allows you to re-run or skip individual stages during troubleshooting or upgrades.
• Isolating bug-fix plays makes it easy to remove them when you upgrade to a version of MySQL or Cacti where the fix is no longer needed.
• The wait_for module prevents subsequent tasks from executing before a service is actually ready to accept connections, making the playbook more reliable than simple service start tasks alone.
• For production use, replace the broad Require all granted / Allow from all Apache directives with IP-restricted access controls, re-enable SELinux, and use firewalld or a dedicated firewall role instead of raw iptables shell commands.

1. Fast, Easy Setup and Configuration

The biggest barrier to distributed monitoring is the sheer volume of initial configuration work. Autodiscovery tooling addresses this directly: you specify an IP address or CIDR range, and the monitoring system scans the network, identifies devices, and imports them with sensible defaults. This eliminates the need to hand-enter host definitions one by one.

Beyond discovery, a well-designed configuration UI should let you make all changes in a single interface—no context-switching between screens or separate tools. For teams that prefer automation, a public REST API enables programmatic control: scripting bulk host imports, updating server profiles, or triggering configuration reloads as part of a CI/CD pipeline.

2. Maintain Consistency with Host Templates

In large distributed environments, configuration drift is a persistent problem. Host templates solve this by defining a standard set of service checks, thresholds, and notification rules for a given device class—say, all Cisco routers, all MySQL servers, or all Linux hosts running Apache.

When you need to change a monitoring parameter across an entire device class, you update the template once and the change propagates to every host inheriting it. This controlled, centralized approach reduces the risk of inconsistent monitoring coverage and makes auditing your configuration straightforward.

3. Reduce Errors with Cloning

Even with templates, there are situations where you need many near-identical host objects—for example, a rack of identical network switches that differ only in IP address and hostname. Manually entering each one is tedious and introduces transcription errors.

A clone function lets you duplicate an existing, correctly configured host object as many times as needed, then adjust only the fields that differ (typically the IP and display name). This saves time and keeps configuration consistent across identical infrastructure.

4. Speed Up Configuration with SNMP

SNMP (Simple Network Management Protocol) is the lingua franca of network device monitoring. A monitoring platform with embedded SNMP polling and trap handling can automatically detect SNMP interfaces on imported devices, eliminating the need to manually map OIDs or configure trap receivers.

This matters for distributed monitoring because SNMP configuration mistakes—wrong community strings, incorrect OID mappings, missed trap destinations—are a leading cause of monitoring gaps. Automating SNMP interface detection removes a significant source of human error during setup.

5. Manage Complexity with Attributes

As environments scale, the number of individual service checks grows rapidly. Attributes (sometimes called custom variables or macros in other monitoring systems) allow you to define a single parameterized service check and apply it across many targets.

A practical example: a VMware host running 20–30 guest VMs. Instead of creating a separate service check for each guest, you define one check that accepts a VM name as an attribute, then list all guests as attribute values on the host object. The monitoring system generates individual checks automatically. This pattern dramatically reduces configuration volume and makes adding or removing VMs a matter of updating a list rather than creating or deleting check objects.

6. Go Agentless Where Appropriate

Agent-based monitoring offers deep visibility but requires installing and maintaining agent software on every monitored system. In distributed environments—especially where you monitor third-party network equipment, embedded devices, or systems where you cannot install software—agentless monitoring is essential.

Agentless protocols to consider:

• SNMP — Industry-standard protocol for network devices, servers, and appliances. Suitable for availability checks, interface counters, and hardware health.
• WMI (Windows Management Instrumentation) — Native Windows management interface. Allows monitoring of CPU, memory, disk, services, and process state without installing an agent on Windows hosts.
• SSH-based checks — For Linux/Unix hosts where firewall policy or security requirements prohibit agent installation, remote checks over SSH are a common alternative.
• ICMP / synthetic transactions — Useful for basic availability and end-to-end transaction monitoring.

Agentless monitoring reduces deployment time significantly when onboarding new infrastructure, and removes the operational burden of keeping agents updated. The trade-off is that agentless checks may be less granular and more network-intensive than agent-based collection.

7. Get the Right Notifications to the Right People

Alert fatigue is one of the most common reasons monitoring deployments fail in practice. Effective notification design means routing the right alert to the right person through the right channel at the right time—and nothing more.

Best practices for distributed monitoring notifications:

• Severity-based routing — Warning states might trigger email during business hours; critical states (service outages, host down) trigger SMS or phone escalation at any hour.
• Role-based targeting — Network engineers receive network alerts; application teams receive application alerts. Avoid broadcasting all alerts to all staff.
• Time-of-day scheduling — Align notifications with on-call rotations. Suppressing non-critical alerts outside business hours reduces noise without losing visibility into genuine outages.
• Escalation paths — If the primary contact does not acknowledge within a defined window, automatically escalate to a secondary or manager.

8. Visualize the Performance of Your Infrastructure

Raw status tables are hard to act on quickly during an incident. Topology maps, network diagrams, and business process maps give operators an at-a-glance view of which systems are healthy and which are degraded—and critically, how failures in one system propagate to dependent systems.

Effective visualization capabilities for distributed monitoring include:

• Network maps — Show device-to-device relationships and link status. Immediately reveals where a connectivity failure is occurring.
• Process/application maps — Model multi-tier applications so operators can see whether a degraded front-end is caused by an application server, database, or network issue.
• Custom infrastructure maps — Upload a data center floor plan or logical architecture diagram and overlay live status indicators. Useful for communicating infrastructure health to non-technical stakeholders.
• Host group tree views — Hierarchical summary views that roll up status from individual hosts to groups (e.g., by data center, by business unit, by environment).

9. Integrate with Your Service Desk

One of the biggest time sinks in operations is the manual process of spotting an alert, deciding it warrants a ticket, opening the service desk tool, filling in the details, and assigning it to the right team. At scale, this overhead is significant and error-prone.

Monitoring platforms that integrate directly with service desk tools—such as Jira Service Management, ServiceNow, or Request Tracker—can automatically create, categorize, and assign tickets when defined thresholds are breached. When the underlying issue resolves, the ticket can be automatically updated or closed.

This bi-directional integration delivers several benefits:

• Engineers spend time resolving problems, not filing tickets.
• Every incident has an associated ticket with a full timeline, reducing post-incident investigation time.
• SLA clocks in the service desk start automatically when the monitoring system detects a problem, not when someone manually notices and files a ticket.

10. Report Against SLAs

Distributed monitoring data is only valuable if it can be turned into actionable reports for internal teams and external stakeholders. SLA, availability, and performance reports allow you to answer the questions that matter to the business: Was the agreed uptime delivered? Which services degraded last quarter? Where should capacity be added?

Useful reporting capabilities for distributed monitoring environments include:

• Availability reports — Historical uptime percentages for specific hosts, services, or application tiers over configurable time windows.
• SLA reports — Compare actual availability against contractual commitments. Particularly important for managed service providers billing against service levels.
• Performance trend reports — Long-term trending of metrics such as CPU utilization, response times, and interface throughput. Essential for capacity planning.
• Scheduled delivery — Reports generated and emailed automatically on a defined schedule (daily, weekly, monthly), reducing manual effort and ensuring stakeholders receive consistent, timely data.

Well-designed reporting closes the loop between operational monitoring and business accountability, and provides the evidence base for infrastructure investment decisions.

Summary

Successful distributed network monitoring depends on reducing manual configuration work, maintaining consistency at scale, routing the right information to the right people, and turning raw monitoring data into business-relevant reports. The ten steps above—autodiscovery, templating, cloning, SNMP automation, attribute-based checks, agentless monitoring, smart notifications, visualization, service desk integration, and SLA reporting—collectively address the most common failure modes in distributed monitoring deployments. Applied together, they give operations teams the coverage and context they need to keep complex infrastructure reliable.

Original source: opsview.com