|
| 1 | +## ADVISORY: Best Practices for Monitoring Multiple Networks with NetAlertX |
| 2 | + |
| 3 | +### 1. Define Monitoring Scope & Architecture |
| 4 | + |
| 5 | +Effective multi-network monitoring starts with understanding how NetAlertX "sees" your traffic. |
| 6 | + |
| 7 | +* **A. Understand Network Accessibility:** Local ARP-based scanning (**ARPSCAN**) only discovers devices on directly accessible subnets due to Layer 2 limitations. It cannot traverse VPNs or routed borders without specific configuration. |
| 8 | +* **B. Plan Subnet & Scan Interfaces:** Explicitly configure each accessible segment in `SCAN_SUBNETS` with the corresponding interfaces. |
| 9 | +* **C. Remote & Inaccessible Networks:** For networks unreachable via ARP, use these strategies: |
| 10 | +* **Alternate Plugins:** Supplement discovery with [SNMPDSC](SNMPDSC) or [DHCP lease imports](https://docs.netalertx.com/PLUGINS/?h=DHCPLSS#available-plugins). |
| 11 | +* **Centralized Multi-Tenant Management using Sync Nodes:** Run secondary NetAlertX instances on isolated networks and aggregate data using the **SYNC plugin**. |
| 12 | +* **Manual Entry:** For static assets where only ICMP (ping) status is needed. |
| 13 | + |
| 14 | +> [!TIP] |
| 15 | +> Explore the [remote networks](./REMOTE_NETWORKS.md) documentation for more details on how to set up the approaches menationed above. |
| 16 | +
|
| 17 | +--- |
| 18 | + |
| 19 | +### 2. Automating IT Asset Inventory with Workflows |
| 20 | + |
| 21 | +[Workflows](./WORKFLOWS.md) are the "engine" of NetAlertX, reducing manual overhead as your device list grows. |
| 22 | + |
| 23 | +* **A. Logical Ownership & VLAN Tagging:** Create a workflow triggered on **Device Creation** to: |
| 24 | +1. Inspect the IP/Subnet. |
| 25 | +2. Set `devVlan` or `devOwner` custom fields automatically. |
| 26 | + |
| 27 | + |
| 28 | +* **B. Auto-Grouping:** Use conditional logic to categorize devices. |
| 29 | +* *Example:* If `devLastIP == 10.10.20.*`, then `Set devLocation = "BranchOffice"`. |
| 30 | + |
| 31 | +```json |
| 32 | +{ |
| 33 | + "name": "Assign Location - BranchOffice", |
| 34 | + "trigger": { |
| 35 | + "object_type": "Devices", |
| 36 | + "event_type": "update" |
| 37 | + }, |
| 38 | + "conditions": [ |
| 39 | + { |
| 40 | + "logic": "AND", |
| 41 | + "conditions": [ |
| 42 | + { |
| 43 | + "field": "devLastIP", |
| 44 | + "operator": "contains", |
| 45 | + "value": "10.10.20." |
| 46 | + } |
| 47 | + ] |
| 48 | + } |
| 49 | + ], |
| 50 | + "actions": [ |
| 51 | + { |
| 52 | + "type": "update_field", |
| 53 | + "field": "devLocation", |
| 54 | + "value": "BranchOffice" |
| 55 | + } |
| 56 | + ] |
| 57 | +} |
| 58 | +``` |
| 59 | + |
| 60 | + |
| 61 | +* **C. Sync Node Tracking:** When using multiple instances, ensure all synchub nodes have a descriptive `SYNC_node_name` name to distinguish between sites. |
| 62 | + |
| 63 | +> [!TIP] |
| 64 | +> Always test new workflows in a "Staging" instance. A misconfigured workflow can trigger thousands of unintended updates across your database. |
| 65 | +
|
| 66 | +--- |
| 67 | + |
| 68 | +### 3. Notification Strategy: Low Noise, High Signal |
| 69 | + |
| 70 | +A multi-network environment can generate significant "alert fatigue." Use a layered filtering approach. |
| 71 | + |
| 72 | +| Level | Strategy | Recommended Action | |
| 73 | +| --- | --- | --- | |
| 74 | +| **Device** | Silence Flapping | Use "Skip repeated notifications" for unstable IoT devices. | |
| 75 | +| **Plugin** | Tune Watchers | Only enable `_WATCH` on reliable plugins (e.g., ICMP/SNMP). | |
| 76 | +| **Global** | Filter Sections | Limit `NTFPRCS_INCLUDED_SECTIONS` to `new_devices` and `down_devices`. | |
| 77 | + |
| 78 | + |
| 79 | +> [!TIP] |
| 80 | +> **Ignore Rules:** Maintain strict **Ignored MAC** (`NEWDEV_ignored_MACs`) and **Ignored IP** (`NEWDEV_ignored_IPs`) lists for guest networks or broadcast scanners to keep your logs clean. |
| 81 | +
|
| 82 | +--- |
| 83 | + |
| 84 | +### 4. UI Filters for Multi-Network Clarity |
| 85 | + |
| 86 | +Don't let a massive device list overwhelm you. Use the [Multi-edit features](./DEVICES_BULK_EDITING.md) to categorize devices and create focused views: |
| 87 | + |
| 88 | +* **By Zone:** Filter by "Location", "Site" or "Sync Node" you et up in Section 2. |
| 89 | +* **By Criticality:** Use custom the device Type field to separate "Core Infrastructure" from "Ephemeral Clients." |
| 90 | +* **By Status:** Use predefined views specifically for "Devices currently Down" to act as a Network Operations Center (NOC) dashboard. |
| 91 | + |
| 92 | +> [!TIP] |
| 93 | +> If you are providing services as a Managed Service Provider (MSP) customize your default UI to be exactly how you need it, by hiding parts of the UI that you are not interested in, or by configuring a auto-refreshed screen monitoring your most important clients. See the [Eyes on glass](./ADVISORY_EYES_ON_GLASS.md) advisory for more details. |
| 94 | +
|
| 95 | +--- |
| 96 | + |
| 97 | +### 5. Operational Stability & Sync Health |
| 98 | + |
| 99 | +* **Health Checks:** Regularly monitor the [Logs](https://docs.netalertx.com/LOGGING/?h=logs) to ensure remote nodes are reporting in. |
| 100 | +* **Backups:** Use the **CSV Devices Backup** plugin. Standardize your workflow templates and [back up](./BACKUPS.md) you `/config` folders so that if a node fails, you can redeploy it with the same logic instantly. |
| 101 | + |
| 102 | + |
| 103 | +### 6. Optimize Performance |
| 104 | + |
| 105 | +As your environment grows, tuning the underlying engine is vital to maintain a snappy UI and reliable discovery cycles. |
| 106 | + |
| 107 | +* **Plugin Scheduling:** Avoid "Scan Storms" by staggering plugin execution. Running intensive tasks like `NMAP` or `MASS_DNS` simultaneously can spike CPU and cause database locks. |
| 108 | +* **Database Health:** Large-scale monitoring generates massive event logs. Use the **[DBCLNP (Database Cleanup)](https://www.google.com/search?q=https://docs.netalertx.com/PLUGINS/%23dbclnp)** plugin to prune old records and keep the SQLite database performant. |
| 109 | +* **Resource Management:** For high-device counts, consider increasing the memory limit for the container and utilizing `tmpfs` for temporary files to reduce SD card/disk I/O bottlenecks. |
| 110 | + |
| 111 | +> [!IMPORTANT] |
| 112 | +> For a deep dive into hardware requirements, database vacuuming, and specific environment variables for high-load instances, refer to the full **[Performance Optimization Guide](https://docs.netalertx.com/PERFORMANCE/)**. |
| 113 | +
|
| 114 | +--- |
| 115 | + |
| 116 | +### Summary Checklist |
| 117 | + |
| 118 | +* [ ] **Discovery:** Are all subnets explicitly defined? |
| 119 | +* [ ] **Automation:** Do new devices get auto-assigned to a VLAN/Owner? |
| 120 | +* [ ] **Noise Control:** Are transient "Down" alerts delayed via `NTFPRCS_alert_down_time`? |
| 121 | +* [ ] **Remote Sites:** Is the SYNC plugin authenticated and heartbeat-active? |
0 commit comments