mirror of
https://github.com/jokob-sk/NetAlertX.git
synced 2026-05-24 16:49:52 -04:00
Enhance documentation and improve formatting across multiple files
This commit is contained in:
@@ -4,6 +4,9 @@ For Managed Service Providers (MSPs) and Network Operations Centers (NOC), "Eyes
|
||||
|
||||

|
||||
|
||||
> [!TIP]
|
||||
> If you are using Grafana check the `/metrics` endpoint that exposes **Prometheus-compatible metrics** for NetAlertX, including aggregate device counts and per-device status. See the [Metrics API endpoint](./API_METRICS.md) documentation for details.
|
||||
|
||||
---
|
||||
|
||||
### 1. Configure Auto-Refresh for Live Monitoring
|
||||
|
||||
@@ -12,20 +12,25 @@ Effective multi-network monitoring starts with understanding how NetAlertX "sees
|
||||
* **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.
|
||||
> Explore the [remote networks](./REMOTE_NETWORKS.md) documentation for more details on how to set up the approaches mentioned above.
|
||||
|
||||
---
|
||||
|
||||
### 2. Automating IT Asset Inventory with Workflows
|
||||
|
||||
[Workflows](./WORKFLOWS.md) are the "engine" of NetAlertX, reducing manual overhead as your device list grows.
|
||||
[Workflows](./WORKFLOWS.md) are the "engine" of NetAlertX, reducing manual overhead as your device list grows. See some examples below.:
|
||||
|
||||
#### A. Logical Ownership & VLAN Tagging
|
||||
|
||||
Create a workflow triggered on **Device Creation** to:
|
||||
|
||||
* **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.
|
||||
|
||||
* **B. Auto-Grouping:** Use conditional logic to categorize devices.
|
||||
* *Example:* If `devLastIP == 10.10.20.*`, then `Set devLocation = "BranchOffice"`.
|
||||
|
||||
```json
|
||||
@@ -56,9 +61,9 @@ Effective multi-network monitoring starts with understanding how NetAlertX "sees
|
||||
]
|
||||
}
|
||||
```
|
||||
#### C. Sync Node Tracking
|
||||
|
||||
|
||||
* **C. Sync Node Tracking:** When using multiple instances, ensure all synchub nodes have a descriptive `SYNC_node_name` name to distinguish between sites.
|
||||
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.
|
||||
@@ -107,6 +112,7 @@ As your environment grows, tuning the underlying engine is vital to maintain a s
|
||||
* **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.
|
||||
* Enable the `DEEP_SLEEP` setting.
|
||||
|
||||
> [!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/)**.
|
||||
|
||||
@@ -7,6 +7,7 @@ Configure how your plugin's data is displayed in the NetAlertX web interface.
|
||||
Plugin results are displayed in the UI via the **Plugins page** and **Device details tabs**. You control the appearance and functionality of these displays by defining `database_column_definitions` in your plugin's `config.json`.
|
||||
|
||||
Each column definition specifies:
|
||||
|
||||
- Which data field to display
|
||||
- How to render it (label, link, color-coded badge, etc.)
|
||||
- What CSS classes to apply
|
||||
@@ -275,6 +276,7 @@ Replaces specific values with display strings or HTML.
|
||||
```
|
||||
|
||||
**Output Examples:**
|
||||
|
||||
- `"online"` → 🟢 Online
|
||||
- `"offline"` → 🔴 Offline
|
||||
- `"idle"` → 🟡 Idle
|
||||
|
||||
@@ -45,23 +45,23 @@ Sometimes devices are manually archived (e.g., no longer expected on the network
|
||||
],
|
||||
"enabled": "Yes"
|
||||
}
|
||||
```
|
||||
````
|
||||
|
||||
### 🔍 Explanation
|
||||
|
||||
- Trigger: Listens for updates to device records.
|
||||
- Conditions:
|
||||
- `devIsArchived` is `1` (archived).
|
||||
- `devPresentLastScan` is `1` (device was detected in the latest scan).
|
||||
- Action: Updates the device to set `devIsArchived` to `0` (unarchived).
|
||||
* **Trigger**: Listens for updates to device records.
|
||||
* **Conditions**:
|
||||
|
||||
* `devIsArchived` is `1` (archived).
|
||||
* `devPresentLastScan` is `1` (device was detected in the latest scan).
|
||||
* **Action**:
|
||||
|
||||
* Updates the device to set `devIsArchived` to `0` (unarchived).
|
||||
|
||||
### ✅ Result
|
||||
|
||||
Whenever a previously archived device shows up during a network scan, it will be automatically unarchived — allowing it to reappear in your device lists and dashboards.
|
||||
|
||||
|
||||
Here is your updated version of **Example 2** and **Example 3**, fully aligned with the format and structure of **Example 1** for consistency and professionalism:
|
||||
|
||||
---
|
||||
|
||||
## Example 2: Assign Device to Network Node Based on IP
|
||||
@@ -107,7 +107,7 @@ When new devices join your network, assigning them to the correct network node i
|
||||
### 🔍 Explanation
|
||||
|
||||
* **Trigger**: Activates when a new device is added.
|
||||
* **Condition**:
|
||||
* **Conditions**:
|
||||
|
||||
* `devLastIP` contains `192.168.1.` (matches subnet).
|
||||
* **Action**:
|
||||
@@ -173,12 +173,12 @@ You may want to automatically clear out newly detected Google devices (such as C
|
||||
* **Trigger**: Runs on device updates.
|
||||
* **Conditions**:
|
||||
|
||||
* Vendor contains `Google`.
|
||||
* Device is marked as new (`devIsNew` is `1`).
|
||||
* `devVendor` contains `Google`.
|
||||
* `devIsNew` is `1` (device marked as new).
|
||||
* **Actions**:
|
||||
|
||||
1. Set `devIsNew` to `0` (mark as not new).
|
||||
2. Delete the device.
|
||||
1. Sets `devIsNew` to `0` (mark as not new).
|
||||
2. Deletes the device.
|
||||
|
||||
### ✅ Result
|
||||
|
||||
|
||||
@@ -1417,6 +1417,7 @@ textarea[readonly],
|
||||
grid-template-columns: repeat(auto-fit, minmax(125px, 1fr));
|
||||
gap: 0.75em;
|
||||
padding: 0.5em 0;
|
||||
padding-top: 0;
|
||||
}
|
||||
|
||||
#columnFilters::before,
|
||||
|
||||
Reference in New Issue
Block a user