DOCS: ADVISORIES

Signed-off-by: jokob-sk <jokob.sk@gmail.com>

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.

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?

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