diff --git a/docs/ADVISORY_EYES_ON_GLASS.md b/docs/ADVISORY_EYES_ON_GLASS.md new file mode 100644 index 00000000..ace8f0dc --- /dev/null +++ b/docs/ADVISORY_EYES_ON_GLASS.md @@ -0,0 +1,56 @@ +### Build an MSP Wallboard for Network Monitoring + +For Managed Service Providers (MSPs) and Network Operations Centers (NOC), "Eyes on Glass" monitoring requires a UI that is both self-healing (auto-refreshing) and focused only on critical data. By leveraging the **UI Settings Plugin**, you can transform NetAlertX from a management tool into a dedicated live monitor. + +![filters](./img/ADVISORIES/filters.png) + +--- + +### 1. Configure Auto-Refresh for Live Monitoring + +Static dashboards are the enemy of real-time response. NetAlertX allows you to force the UI to pull fresh data without manual page reloads. + +* **Setting:** Locate the `UI_REFRESH` (or similar "Auto-refresh UI") setting within the **UI Settings plugin**. +* **Optimal Interval:** Set this between **60 to 120 seconds**. +* *Note:* Refreshing too frequently (e.g., <30s) on large networks can lead to high browser and server CPU usage. + +![ui_customization_settings](./img/ADVISORIES/ui_customization_settings.png) + +### 2. Streamlining the Dashboard (MSP Mode) + +An MSP's focus is on what is *broken*, not what is working. Hide the noise to increase reaction speed. + +* **Hide Unnecessary Blocks:** Under UI Settings, disable dashboard blocks that don't provide immediate utility, such as **Online presence** or **Tiles**. +* **Hide virtual connections:** You can specify which relationships shoudl be hidden from the main view to remove any virtual devices that are not essential from your views. +* **Browser Full-Screen:** Use the built-in "Full Screen" toggle in the top bar to remove browser chrome (URL bars/tabs) for a cleaner "Wallboard" look. + +### 3. Creating Custom NOC Views + +Use the UI Filters in tandem with UI Settings to create custom views. + +![NetAlertX NOC dashboard showing offline network devices for MSP monitoring](./img/ADVISORIES/down_devices.png) + +| Feature | NOC/MSP Application | +| --- | --- | +| **Site-Specific Nodes** | Filter the view by a specific "Sync Node" or "Location" filter to monitor a single client site. | +| **Filter by Criticality** | Filter devices where `Group == "Infrastructure"` or `"Server"`. (depending on your predefined values) | +| **Predefined "Down" View** | Bookmark the URL with the `/devices.php#down` path to ensure the dashboard always loads into an "Alert Only" mode. | + +### 4. Browser & Cache Stability + +Because the UI is a web application, long-running sessions can occasionally experience cache drift. + +* **Cache Refresh:** If you notice the "Show # Entries" resetting or icons failing to load after days of uptime, use the **Reload** icon in the application header (not the browser refresh) to clear the internal app cache. +* **Dedicated Hardware:** For 24/7 monitoring, use a dedicated thin client or Raspberry Pi running in "Kiosk Mode" to prevent OS-level popups from obscuring the dashboard. + +> [!TIP] +> [NetAlertX - Detailed Dashboard Guide](https://www.youtube.com/watch?v=umh1c_40HW8) +> This video provides a visual walkthrough of the NetAlertX dashboard features, including how to map and visualize devices which is crucial for setting up a clear "Eyes on Glass" monitoring environment. + +### Summary Checklist + +* [ ] **Automate Refresh:** Set `UI_REFRESH` to **60-120s** in UI Settings to ensure the dashboard stays current without manual intervention. +* [ ] **Filter for Criticality:** Bookmark the **`/devices.php#down`** view to instantly focus on offline assets rather than the entire inventory. +* [ ] **Remove UI Noise:** Use UI Settings to hide non-essential dashboard blocks (e.g., **Tiles** or remove **Virtual Connections** devices) to maximize screen real estate for alerts. +* [ ] **Segment by Site:** Use **Location** or **Sync Node** filters to create dedicated views for specific client networks or physical branches. +* [ ] **Ensure Stability:** Run on a dedicated "Kiosk" browser and use the internal **Reload icon** occasionally to maintain a clean application cache. diff --git a/docs/ADVISORY_MULTI_NETWORK.md b/docs/ADVISORY_MULTI_NETWORK.md new file mode 100644 index 00000000..7a0dd094 --- /dev/null +++ b/docs/ADVISORY_MULTI_NETWORK.md @@ -0,0 +1,121 @@ +## ADVISORY: Best Practices for Monitoring Multiple Networks with NetAlertX + +### 1. Define Monitoring Scope & Architecture + +Effective multi-network monitoring starts with understanding how NetAlertX "sees" your traffic. + +* **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. +* **B. Plan Subnet & Scan Interfaces:** Explicitly configure each accessible segment in `SCAN_SUBNETS` with the corresponding interfaces. +* **C. Remote & Inaccessible Networks:** For networks unreachable via ARP, use these strategies: +* **Alternate Plugins:** Supplement discovery with [SNMPDSC](SNMPDSC) or [DHCP lease imports](https://docs.netalertx.com/PLUGINS/?h=DHCPLSS#available-plugins). +* **Centralized Multi-Tenant Management using Sync Nodes:** Run secondary NetAlertX instances on isolated networks and aggregate data using the **SYNC plugin**. +* **Manual Entry:** For static assets where only ICMP (ping) status is needed. + +> [!TIP] +> Explore the [remote networks](./REMOTE_NETWORKS.md) documentation for more details on how to set up the approaches menationed above. + +--- + +### 2. Automating IT Asset Inventory with Workflows + +[Workflows](./WORKFLOWS.md) are the "engine" of NetAlertX, reducing manual overhead as your device list grows. + +* **A. Logical Ownership & VLAN Tagging:** Create a workflow triggered on **Device Creation** to: +1. Inspect the IP/Subnet. +2. Set `devVlan` or `devOwner` custom fields automatically. + + +* **B. Auto-Grouping:** Use conditional logic to categorize devices. +* *Example:* If `devLastIP == 10.10.20.*`, then `Set devLocation = "BranchOffice"`. + +```json +{ + "name": "Assign Location - BranchOffice", + "trigger": { + "object_type": "Devices", + "event_type": "update" + }, + "conditions": [ + { + "logic": "AND", + "conditions": [ + { + "field": "devLastIP", + "operator": "contains", + "value": "10.10.20." + } + ] + } + ], + "actions": [ + { + "type": "update_field", + "field": "devLocation", + "value": "BranchOffice" + } + ] +} +``` + + +* **C. Sync Node Tracking:** When using multiple instances, ensure all synchub nodes have a descriptive `SYNC_node_name` name to distinguish between sites. + +> [!TIP] +> Always test new workflows in a "Staging" instance. A misconfigured workflow can trigger thousands of unintended updates across your database. + +--- + +### 3. Notification Strategy: Low Noise, High Signal + +A multi-network environment can generate significant "alert fatigue." Use a layered filtering approach. + +| Level | Strategy | Recommended Action | +| --- | --- | --- | +| **Device** | Silence Flapping | Use "Skip repeated notifications" for unstable IoT devices. | +| **Plugin** | Tune Watchers | Only enable `_WATCH` on reliable plugins (e.g., ICMP/SNMP). | +| **Global** | Filter Sections | Limit `NTFPRCS_INCLUDED_SECTIONS` to `new_devices` and `down_devices`. | + + +> [!TIP] +> **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. + +--- + +### 4. UI Filters for Multi-Network Clarity + +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: + +* **By Zone:** Filter by "Location", "Site" or "Sync Node" you et up in Section 2. +* **By Criticality:** Use custom the device Type field to separate "Core Infrastructure" from "Ephemeral Clients." +* **By Status:** Use predefined views specifically for "Devices currently Down" to act as a Network Operations Center (NOC) dashboard. + +> [!TIP] +> 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. + +--- + +### 5. Operational Stability & Sync Health + +* **Health Checks:** Regularly monitor the [Logs](https://docs.netalertx.com/LOGGING/?h=logs) to ensure remote nodes are reporting in. +* **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. + + +### 6. Optimize Performance + +As your environment grows, tuning the underlying engine is vital to maintain a snappy UI and reliable discovery cycles. + +* **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. +* **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. +* **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. + +> [!IMPORTANT] +> 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/)**. + +--- + +### Summary Checklist + +* [ ] **Discovery:** Are all subnets explicitly defined? +* [ ] **Automation:** Do new devices get auto-assigned to a VLAN/Owner? +* [ ] **Noise Control:** Are transient "Down" alerts delayed via `NTFPRCS_alert_down_time`? +* [ ] **Remote Sites:** Is the SYNC plugin authenticated and heartbeat-active? diff --git a/docs/img/ADVISORIES/down_devices.png b/docs/img/ADVISORIES/down_devices.png new file mode 100644 index 00000000..9c474c7d Binary files /dev/null and b/docs/img/ADVISORIES/down_devices.png differ diff --git a/docs/img/ADVISORIES/filters.png b/docs/img/ADVISORIES/filters.png new file mode 100644 index 00000000..92a4de81 Binary files /dev/null and b/docs/img/ADVISORIES/filters.png differ diff --git a/docs/img/ADVISORIES/ui_customization_settings.png b/docs/img/ADVISORIES/ui_customization_settings.png new file mode 100644 index 00000000..83b4cddc Binary files /dev/null and b/docs/img/ADVISORIES/ui_customization_settings.png differ diff --git a/mkdocs.yml b/mkdocs.yml index dd4769de..819ca7e1 100755 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -65,6 +65,9 @@ nav: - Workflows: WORKFLOWS.md - Workflow Examples: WORKFLOW_EXAMPLES.md - Docker Swarm: DOCKER_SWARM.md + - Best practice advisories: + - Eyes on glass: ADVISORY_EYES_ON_GLASS.md + - Multi-network monitoring: ADVISORY_MULTI_NETWORK.md - Help: - Common issues: COMMON_ISSUES.md - Random MAC: RANDOM_MAC.md