feat(seo): add MikroTik problem-focused doc pages and update README
Create 5 SEO documentation pages targeting engineer search queries: - /docs/mikrotik-configuration-drift - /docs/mikrotik-router-backup-automation - /docs/manage-multiple-mikrotik-routers - /docs/mikrotik-router-monitoring - /docs/mikrotik-centralized-management Each page: 800-1200 words, problem-first structure, practical engineer language, internal cross-links, proper meta/OG tags. Update README intro to highlight fleet monitoring, config drift detection, safe pushes, backup management, and topology. Add GitHub topics: mikrotik, routeros, network-management, network-automation, router-monitoring, router-fleet-management, msp-tools, network-infrastructure. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
Jason Staack
@@ -1,6 +1,8 @@
|
||||
# The Other Dude
|
||||
|
||||
**Fleet management for MikroTik RouterOS devices.** Built for MSPs who manage hundreds of routers across multiple tenants. Think "UniFi Controller, but for MikroTik."
|
||||
**Fleet management platform for MikroTik RouterOS.**
|
||||
|
||||
Monitor routers, detect configuration drift, manage backups, and safely push configuration changes across hundreds of devices. Built for MSPs and network engineers managing MikroTik fleets.
|
||||
|
||||
The Other Dude is a self-hosted, multi-tenant platform that gives you centralized visibility, configuration management, real-time monitoring, and zero-knowledge security across your entire MikroTik fleet -- from a single pane of glass.
|
||||
|
||||
@@ -8,6 +10,16 @@ The Other Dude is a self-hosted, multi-tenant platform that gives you centralize
|
||||
|
||||
## Features
|
||||
|
||||
### Highlights
|
||||
|
||||
- **Router Fleet Monitoring** -- Real-time CPU, memory, disk, traffic, and wireless metrics across every device. Configurable alerts with email, Slack, and webhook notifications.
|
||||
- **Configuration Drift Detection** -- Automated config snapshots with full version history and side-by-side diffs. Know when configs change and what changed.
|
||||
- **Safe Configuration Pushes** -- Two-phase config push with automatic panic-revert. Push confidently to remote devices without risking lockouts.
|
||||
- **Backup Management** -- Automated configuration backups on a schedule. One-click restore to any previous version.
|
||||
- **Network Topology Visibility** -- Interactive topology map showing device interconnections and shared subnets.
|
||||
|
||||
---
|
||||
|
||||
### Fleet
|
||||
|
||||
- **Dashboard** -- At-a-glance fleet health with device counts, uptime sparklines, status breakdowns per organization, and an "APs Needing Attention" card highlighting wireless issues.
|
||||
|
||||
304
docs/website/docs/manage-multiple-mikrotik-routers.html
Normal file
304
docs/website/docs/manage-multiple-mikrotik-routers.html
Normal file
@@ -0,0 +1,304 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
|
||||
<title>Manage Multiple MikroTik Routers</title>
|
||||
<meta name="description" content="How to manage hundreds of MikroTik routers from a single dashboard. Fleet-level visibility, batch configuration, and centralized monitoring.">
|
||||
<meta name="keywords" content="manage multiple mikrotik routers, mikrotik router fleet management, mikrotik centralized management, routeros fleet, msp mikrotik">
|
||||
<meta name="robots" content="index, follow">
|
||||
<meta name="theme-color" content="#FAFBFC">
|
||||
<link rel="canonical" href="https://theotherdude.net/docs/manage-multiple-mikrotik-routers.html">
|
||||
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 64 64'><rect x='2' y='2' width='60' height='60' rx='8' fill='none' stroke='%238B1A1A' stroke-width='2'/><rect x='6' y='6' width='52' height='52' rx='5' fill='none' stroke='%23F5E6C8' stroke-width='1.5'/><rect x='8' y='8' width='48' height='48' rx='4' fill='%238B1A1A' opacity='0.15'/><path d='M32 8 L56 32 L32 56 L8 32 Z' fill='none' stroke='%238B1A1A' stroke-width='2'/><path d='M32 13 L51 32 L32 51 L13 32 Z' fill='none' stroke='%23F5E6C8' stroke-width='1.5'/><path d='M32 18 L46 32 L32 46 L18 32 Z' fill='%238B1A1A'/><path d='M32 19 L38 32 L32 45 L26 32 Z' fill='%232A9D8F'/><path d='M19 32 L32 26 L45 32 L32 38 Z' fill='%23F5E6C8'/><circle cx='32' cy='32' r='5' fill='%238B1A1A'/><circle cx='32' cy='32' r='2.5' fill='%232A9D8F'/><path d='M10 10 L16 10 L10 16 Z' fill='%232A9D8F' opacity='0.7'/><path d='M54 10 L54 16 L48 10 Z' fill='%232A9D8F' opacity='0.7'/><path d='M10 54 L16 54 L10 48 Z' fill='%232A9D8F' opacity='0.7'/><path d='M54 54 L48 54 L54 48 Z' fill='%232A9D8F' opacity='0.7'/></svg>">
|
||||
|
||||
<!-- Open Graph -->
|
||||
<meta property="og:type" content="article">
|
||||
<meta property="og:title" content="Manage Multiple MikroTik Routers from One Dashboard">
|
||||
<meta property="og:description" content="How to manage hundreds of MikroTik routers from a single dashboard. Fleet-level visibility, batch configuration, and centralized monitoring.">
|
||||
<meta property="og:url" content="https://theotherdude.net/docs/manage-multiple-mikrotik-routers.html">
|
||||
<meta property="og:site_name" content="The Other Dude">
|
||||
<meta property="og:image" content="https://theotherdude.net/assets/og-image.png">
|
||||
<meta property="og:locale" content="en_US">
|
||||
|
||||
<!-- Twitter Card -->
|
||||
<meta name="twitter:card" content="summary_large_image">
|
||||
<meta name="twitter:title" content="Manage Multiple MikroTik Routers from One Dashboard">
|
||||
<meta name="twitter:description" content="How to manage hundreds of MikroTik routers from a single dashboard. Fleet-level visibility, batch configuration, and centralized monitoring.">
|
||||
<meta name="twitter:image" content="https://theotherdude.net/assets/og-image.png">
|
||||
|
||||
<!-- Structured Data -->
|
||||
<script type="application/ld+json">
|
||||
{
|
||||
"@context": "https://schema.org",
|
||||
"@type": "TechArticle",
|
||||
"headline": "How to Manage Multiple MikroTik Routers from One Dashboard",
|
||||
"description": "How to manage hundreds of MikroTik routers from a single dashboard. Fleet-level visibility, batch configuration, and centralized monitoring.",
|
||||
"author": {
|
||||
"@type": "Organization",
|
||||
"name": "The Other Dude"
|
||||
},
|
||||
"publisher": {
|
||||
"@type": "Organization",
|
||||
"name": "The Other Dude",
|
||||
"url": "https://theotherdude.net"
|
||||
},
|
||||
"mainEntityOfPage": "https://theotherdude.net/docs/manage-multiple-mikrotik-routers.html"
|
||||
}
|
||||
</script>
|
||||
|
||||
<!-- Fonts -->
|
||||
<link rel="preconnect" href="https://fonts.googleapis.com" />
|
||||
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
|
||||
<link href="https://fonts.googleapis.com/css2?family=DM+Sans:wght@400;500;700&family=Fira+Code:wght@400;500&family=Outfit:wght@400;500;600;700;800&display=swap" rel="stylesheet" />
|
||||
|
||||
<link rel="stylesheet" href="../style.css" />
|
||||
<style>
|
||||
.doc-article {
|
||||
max-width: 760px;
|
||||
margin: 0 auto;
|
||||
padding: 80px 24px 120px;
|
||||
}
|
||||
.doc-article .back-link {
|
||||
display: inline-block;
|
||||
margin-bottom: 40px;
|
||||
font-size: 14px;
|
||||
text-decoration: none;
|
||||
color: var(--text-muted);
|
||||
}
|
||||
.doc-article .back-link:hover {
|
||||
color: var(--accent);
|
||||
}
|
||||
.doc-article h1 {
|
||||
font-family: "Outfit", sans-serif;
|
||||
font-weight: 700;
|
||||
font-size: 2.4rem;
|
||||
line-height: 1.2;
|
||||
color: var(--text-primary);
|
||||
margin-bottom: 36px;
|
||||
}
|
||||
.doc-article h2 {
|
||||
font-family: "Outfit", sans-serif;
|
||||
font-weight: 600;
|
||||
font-size: 1.35rem;
|
||||
color: var(--text-primary);
|
||||
margin-top: 52px;
|
||||
margin-bottom: 16px;
|
||||
}
|
||||
.doc-article p {
|
||||
color: var(--text-secondary);
|
||||
font-size: 1.05rem;
|
||||
line-height: 1.75;
|
||||
margin-bottom: 20px;
|
||||
}
|
||||
.doc-article p strong {
|
||||
color: var(--text-primary);
|
||||
}
|
||||
.doc-article ul {
|
||||
margin: 0 0 20px 0;
|
||||
padding-left: 24px;
|
||||
}
|
||||
.doc-article li {
|
||||
color: var(--text-secondary);
|
||||
font-size: 1.05rem;
|
||||
line-height: 1.75;
|
||||
margin-bottom: 8px;
|
||||
}
|
||||
.doc-article li strong {
|
||||
color: var(--text-primary);
|
||||
}
|
||||
.doc-article a {
|
||||
color: var(--accent);
|
||||
text-decoration: underline;
|
||||
text-underline-offset: 3px;
|
||||
}
|
||||
.doc-article a:hover {
|
||||
color: var(--text-primary);
|
||||
}
|
||||
.doc-article .related-links {
|
||||
margin-top: 56px;
|
||||
padding-top: 32px;
|
||||
border-top: 1px solid var(--border);
|
||||
}
|
||||
.doc-article .related-links h2 {
|
||||
margin-top: 0;
|
||||
font-size: 1.1rem;
|
||||
}
|
||||
.doc-article .related-links ul {
|
||||
list-style: none;
|
||||
padding-left: 0;
|
||||
}
|
||||
.doc-article .related-links li {
|
||||
margin-bottom: 10px;
|
||||
}
|
||||
@media (max-width: 480px) {
|
||||
.doc-article h1 { font-size: 1.8rem; }
|
||||
.doc-article { padding: 60px 20px 80px; }
|
||||
}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
|
||||
<a href="#doc-content" class="skip-link">Skip to main content</a>
|
||||
|
||||
<!-- ===== TESTING BANNER ===== -->
|
||||
<div class="testing-banner testing-banner--light">
|
||||
<div class="container">
|
||||
<strong>Early Access</strong> — This software is in active development and testing. It is not yet ready for production use.
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<!-- ===== NAV ===== -->
|
||||
<nav class="site-nav site-nav--light" aria-label="Main navigation">
|
||||
<div class="nav-inner container">
|
||||
<a href="../index.html" class="nav-logo">
|
||||
<svg class="nav-logo-mark" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 64 64" width="32" height="32" aria-hidden="true">
|
||||
<rect x="2" y="2" width="60" height="60" rx="8" fill="none" stroke="#8B1A1A" stroke-width="2"/>
|
||||
<rect x="6" y="6" width="52" height="52" rx="5" fill="none" stroke="#F5E6C8" stroke-width="1.5"/>
|
||||
<rect x="8" y="8" width="48" height="48" rx="4" fill="#8B1A1A" opacity="0.15"/>
|
||||
<path d="M32 8 L56 32 L32 56 L8 32 Z" fill="none" stroke="#8B1A1A" stroke-width="2"/>
|
||||
<path d="M32 13 L51 32 L32 51 L13 32 Z" fill="none" stroke="#F5E6C8" stroke-width="1.5"/>
|
||||
<path d="M32 18 L46 32 L32 46 L18 32 Z" fill="#8B1A1A"/>
|
||||
<path d="M32 19 L38 32 L32 45 L26 32 Z" fill="#2A9D8F"/>
|
||||
<path d="M19 32 L32 26 L45 32 L32 38 Z" fill="#F5E6C8"/>
|
||||
<circle cx="32" cy="32" r="5" fill="#8B1A1A"/>
|
||||
<circle cx="32" cy="32" r="2.5" fill="#2A9D8F"/>
|
||||
<path d="M10 10 L16 10 L10 16 Z" fill="#2A9D8F" opacity="0.7"/>
|
||||
<path d="M54 10 L54 16 L48 10 Z" fill="#2A9D8F" opacity="0.7"/>
|
||||
<path d="M10 54 L16 54 L10 48 Z" fill="#2A9D8F" opacity="0.7"/>
|
||||
<path d="M54 54 L48 54 L54 48 Z" fill="#2A9D8F" opacity="0.7"/>
|
||||
</svg>
|
||||
<span>The Other Dude</span>
|
||||
</a>
|
||||
<div class="nav-links">
|
||||
<a href="../index.html" class="nav-link">Home</a>
|
||||
<a href="../index.html#what-it-does" class="nav-link">Features</a>
|
||||
<a href="../docs.html" class="nav-link nav-link--active">Docs</a>
|
||||
<a href="../blog/" class="nav-link">Blog</a>
|
||||
<a href="https://github.com/staack/the-other-dude" class="nav-link" rel="noopener">GitHub</a>
|
||||
</div>
|
||||
</div>
|
||||
</nav>
|
||||
|
||||
<!-- ===== CONTENT ===== -->
|
||||
<main id="doc-content">
|
||||
<article class="doc-article">
|
||||
<a href="../docs.html" class="back-link">← Back to Docs</a>
|
||||
|
||||
<h1>How to Manage Multiple MikroTik Routers from One Dashboard</h1>
|
||||
|
||||
<h2>The Problem</h2>
|
||||
|
||||
<p>At five routers, WinBox tabs are manageable. You open a session per device, keep credentials in your head or a password manager, and move on. At fifty routers spread across multiple client sites, the tab approach breaks down: you're writing bash scripts to loop SSH connections, hoping your expect scripts handle timeouts gracefully, and maintaining a firmware spreadsheet that's perpetually out of date.</p>
|
||||
|
||||
<p>At two hundred routers or more, you're dealing with a different class of problem entirely. Pushing a firewall rule change means coordinating across dozens of simultaneous connections. A firmware upgrade cycle requires tracking which devices are on which RouterOS version, which hardware models support the target version, and which sites have maintenance windows. Onboarding a new client means manually provisioning credentials and confirming connectivity for every device they hand you. A single misconfiguration that bypasses your SSH loop silently fails and leaves one router out of compliance.</p>
|
||||
|
||||
<p>The operational cost compounds: credential sprawl, inconsistent configs across hardware generations, no audit trail for who changed what, and no alerting when a device goes offline at 3 AM except your phone at 3:05 AM.</p>
|
||||
|
||||
<h2>Why MikroTik Lacks Fleet Management</h2>
|
||||
|
||||
<p>MikroTik's tooling was designed for single-device administration. That's not a criticism — WinBox is genuinely good at what it does. But the design assumptions don't scale to fleet operations:</p>
|
||||
|
||||
<ul>
|
||||
<li><strong>WinBox is one device at a time.</strong> There's no concept of a device group, no bulk operation interface, no shared state between sessions.</li>
|
||||
<li><strong>The Dude monitors but doesn't manage.</strong> It gives you network maps and SNMP polling, but it won't push a config change or track firmware versions across the fleet.</li>
|
||||
<li><strong>No native cross-device API.</strong> The RouterOS API (port 8728/8729) is per-device. There's no management plane that aggregates across devices — you have to build that yourself.</li>
|
||||
<li><strong>Each device is an island.</strong> There's no shared config state, no template system, no way to say "these 40 routers should all have this firewall ruleset."</li>
|
||||
<li><strong>SSH scripting hits a ceiling.</strong> Scripts work until you need error handling, state tracking across partial failures, retry logic, and audit logging. At that point you're building infrastructure, not writing scripts.</li>
|
||||
</ul>
|
||||
|
||||
<p>The result is that most MikroTik fleet operators end up with a collection of tribal knowledge, SSH scripts of varying quality, and a Nagios instance that tells them about outages after the fact.</p>
|
||||
|
||||
<h2>What MSPs and Network Teams Need</h2>
|
||||
|
||||
<p>A workable mikrotik router fleet management solution needs to address several distinct operational concerns:</p>
|
||||
|
||||
<ul>
|
||||
<li><strong>Single-pane-of-glass visibility.</strong> Device count, online/offline status, uptime, CPU load, and memory usage across all routers without opening individual sessions.</li>
|
||||
<li><strong>Batch configuration operations.</strong> Push a firewall rule or interface change to 50 devices simultaneously, with per-device success/failure reporting and rollback capability.</li>
|
||||
<li><strong>Consistent firmware management.</strong> Know which devices are running which RouterOS version, which are behind, and which hardware supports the target version before you start an upgrade cycle.</li>
|
||||
<li><strong>Credential management without spreadsheets.</strong> Store device credentials encrypted at rest, rotate them centrally, and audit access without maintaining parallel systems.</li>
|
||||
<li><strong>Multi-tenant isolation.</strong> MSPs managing multiple client networks need hard boundaries between client data — not just UI filtering, but enforced at the data layer.</li>
|
||||
<li><strong>Role-based access control.</strong> Junior staff doing monitoring shouldn't have the same permissions as senior engineers pushing config changes. Read-only, operator, and admin roles need to be enforced, not just honored.</li>
|
||||
</ul>
|
||||
|
||||
<h2>How The Other Dude Manages MikroTik Fleets</h2>
|
||||
|
||||
<p>The Other Dude was built specifically for this operational context. Here's what the platform provides:</p>
|
||||
|
||||
<p><strong>Fleet dashboard.</strong> A single view shows device count, online/offline ratio, uptime sparklines, and per-device CPU and memory across your entire fleet. The device table is virtual-scrolled and handles hundreds of routers without performance degradation.</p>
|
||||
|
||||
<p><strong>Batch configuration.</strong> Apply a config template to multiple devices simultaneously. Each device gets its own result — success, failure, or partial — and the operation is logged with a timestamp and the identity of who ran it. Config templates support variable substitution, so you can define a standard firewall ruleset once and apply it across sites with different IP ranges without editing the template for each device.</p>
|
||||
|
||||
<p><strong>Bulk command execution.</strong> Run arbitrary RouterOS CLI commands across a device group. Useful for one-off queries (what's the uptime on all devices at site X?) or scripted changes that don't fit a template pattern.</p>
|
||||
|
||||
<p><strong>Firmware tracking.</strong> The fleet view shows RouterOS version per device. You can filter to find devices below a target version and plan upgrade operations accordingly, accounting for hardware model compatibility.</p>
|
||||
|
||||
<p><strong>Subnet scanner.</strong> Discover MikroTik devices on a given network segment. New devices show up in the scan results and can be added to the fleet directly.</p>
|
||||
|
||||
<p><strong>Geographic map view.</strong> Devices can be assigned coordinates and viewed on a map, useful for ISPs and MSPs with geographically distributed deployments.</p>
|
||||
|
||||
<p><strong>Multi-tenant support.</strong> Tenant data isolation is enforced at the PostgreSQL layer using Row-Level Security policies, not just filtered in the application. One tenant's devices, configs, and credentials are not accessible to another tenant regardless of application bugs.</p>
|
||||
|
||||
<p><strong>RBAC.</strong> Four roles: super_admin, admin, operator, and viewer. Permissions are checked server-side on every request. Viewer accounts can monitor but cannot execute commands or push configs.</p>
|
||||
|
||||
<p><strong>Credential encryption.</strong> All device credentials are encrypted at rest using AES-256-GCM. Keys are managed separately from the database.</p>
|
||||
|
||||
<h2>Architecture Overview</h2>
|
||||
|
||||
<p>For teams evaluating self-hosted options, the stack is straightforward:</p>
|
||||
|
||||
<ul>
|
||||
<li><strong>React frontend</strong> — web interface, virtual-scrolled device tables, real-time status updates via WebSocket.</li>
|
||||
<li><strong>FastAPI backend</strong> — REST API, authentication, RBAC enforcement, task orchestration.</li>
|
||||
<li><strong>PostgreSQL + TimescaleDB</strong> — device inventory, time-series metrics, config history, multi-tenant RLS.</li>
|
||||
<li><strong>Go poller</strong> — connects to devices using the RouterOS binary API over TLS (port 8729), collects metrics, executes commands, handles reconnection and error recovery per device.</li>
|
||||
<li><strong>NATS JetStream</strong> — real-time event bus between poller and backend; device status changes and metric updates flow through here.</li>
|
||||
<li><strong>Docker Compose</strong> — all components run as containers; a single compose file brings up the full stack.</li>
|
||||
</ul>
|
||||
|
||||
<p>There's no SaaS dependency, no phone-home requirement, and no cloud account needed. Everything runs on hardware you control.</p>
|
||||
|
||||
<div class="related-links">
|
||||
<h2>Related Guides</h2>
|
||||
<ul>
|
||||
<li><a href="mikrotik-configuration-drift.html">Detect configuration drift across your MikroTik fleet</a></li>
|
||||
<li><a href="mikrotik-router-backup-automation.html">Automate RouterOS configuration backups</a></li>
|
||||
<li><a href="mikrotik-router-monitoring.html">Monitor MikroTik routers at scale</a></li>
|
||||
<li><a href="mikrotik-centralized-management.html">Centralized MikroTik management overview</a></li>
|
||||
<li><a href="https://github.com/staack/the-other-dude" rel="noopener">The Other Dude on GitHub</a></li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
</article>
|
||||
</main>
|
||||
|
||||
<footer class="site-footer">
|
||||
<div class="footer-inner container">
|
||||
<div class="footer-brand">
|
||||
<span class="footer-logo">
|
||||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 64 64" width="24" height="24" aria-hidden="true" style="vertical-align: middle; margin-right: 8px;">
|
||||
<rect x="2" y="2" width="60" height="60" rx="8" fill="none" stroke="#8B1A1A" stroke-width="2"/>
|
||||
<rect x="6" y="6" width="52" height="52" rx="5" fill="none" stroke="#F5E6C8" stroke-width="1.5"/>
|
||||
<rect x="8" y="8" width="48" height="48" rx="4" fill="#8B1A1A" opacity="0.15"/>
|
||||
<path d="M32 18 L46 32 L32 46 L18 32 Z" fill="#8B1A1A"/>
|
||||
<path d="M32 19 L38 32 L32 45 L26 32 Z" fill="#2A9D8F"/>
|
||||
<path d="M19 32 L32 26 L45 32 L32 38 Z" fill="#F5E6C8"/>
|
||||
<circle cx="32" cy="32" r="5" fill="#8B1A1A"/>
|
||||
<circle cx="32" cy="32" r="2.5" fill="#2A9D8F"/>
|
||||
</svg>
|
||||
The Other Dude
|
||||
</span>
|
||||
<span class="footer-copy">© 2026 The Other Dude. All rights reserved.</span>
|
||||
</div>
|
||||
<nav class="footer-links">
|
||||
<a href="../docs.html">Docs</a>
|
||||
<a href="../blog/">Blog</a>
|
||||
<a href="https://github.com/staack/the-other-dude" rel="noopener">GitHub</a>
|
||||
<a href="mailto:license@theotherdude.net">Licensing</a>
|
||||
</nav>
|
||||
</div>
|
||||
</footer>
|
||||
|
||||
<!-- Cloudflare Web Analytics --><script defer src='https://static.cloudflareinsights.com/beacon.min.js' data-cf-beacon='{"token": "d5f1e31cb9744c998a8f7d1303c6efef"}'></script><!-- End Cloudflare Web Analytics -->
|
||||
</body>
|
||||
</html>
|
||||
282
docs/website/docs/mikrotik-centralized-management.html
Normal file
282
docs/website/docs/mikrotik-centralized-management.html
Normal file
@@ -0,0 +1,282 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
|
||||
<title>MikroTik Centralized Management Platform</title>
|
||||
<meta name="description" content="Centralized management for MikroTik RouterOS fleets. Configuration, monitoring, backups, and security from a single self-hosted platform.">
|
||||
<meta name="keywords" content="mikrotik centralized management, routeros configuration management, mikrotik router fleet management, MSP network management, MikroTik monitoring">
|
||||
<meta name="robots" content="index, follow">
|
||||
<meta name="theme-color" content="#FAFBFC">
|
||||
<link rel="canonical" href="https://theotherdude.net/docs/mikrotik-centralized-management.html">
|
||||
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 64 64'><rect x='2' y='2' width='60' height='60' rx='8' fill='none' stroke='%238B1A1A' stroke-width='2'/><rect x='6' y='6' width='52' height='52' rx='5' fill='none' stroke='%23F5E6C8' stroke-width='1.5'/><rect x='8' y='8' width='48' height='48' rx='4' fill='%238B1A1A' opacity='0.15'/><path d='M32 8 L56 32 L32 56 L8 32 Z' fill='none' stroke='%238B1A1A' stroke-width='2'/><path d='M32 13 L51 32 L32 51 L13 32 Z' fill='none' stroke='%23F5E6C8' stroke-width='1.5'/><path d='M32 18 L46 32 L32 46 L18 32 Z' fill='%238B1A1A'/><path d='M32 19 L38 32 L32 45 L26 32 Z' fill='%232A9D8F'/><path d='M19 32 L32 26 L45 32 L32 38 Z' fill='%23F5E6C8'/><circle cx='32' cy='32' r='5' fill='%238B1A1A'/><circle cx='32' cy='32' r='2.5' fill='%232A9D8F'/><path d='M10 10 L16 10 L10 16 Z' fill='%232A9D8F' opacity='0.7'/><path d='M54 10 L54 16 L48 10 Z' fill='%232A9D8F' opacity='0.7'/><path d='M10 54 L16 54 L10 48 Z' fill='%232A9D8F' opacity='0.7'/><path d='M54 54 L48 54 L54 48 Z' fill='%232A9D8F' opacity='0.7'/></svg>">
|
||||
|
||||
<!-- Open Graph -->
|
||||
<meta property="og:type" content="article">
|
||||
<meta property="og:title" content="MikroTik Centralized Management Platform — The Other Dude">
|
||||
<meta property="og:description" content="Centralized management for MikroTik RouterOS fleets. Configuration, monitoring, backups, and security from a single self-hosted platform.">
|
||||
<meta property="og:url" content="https://theotherdude.net/docs/mikrotik-centralized-management.html">
|
||||
<meta property="og:site_name" content="The Other Dude">
|
||||
<meta property="og:image" content="https://theotherdude.net/assets/og-image.png">
|
||||
<meta property="og:locale" content="en_US">
|
||||
|
||||
<!-- Twitter Card -->
|
||||
<meta name="twitter:card" content="summary_large_image">
|
||||
<meta name="twitter:title" content="MikroTik Centralized Management Platform — The Other Dude">
|
||||
<meta name="twitter:description" content="Centralized management for MikroTik RouterOS fleets. Configuration, monitoring, backups, and security from a single self-hosted platform.">
|
||||
<meta name="twitter:image" content="https://theotherdude.net/assets/og-image.png">
|
||||
|
||||
<!-- Structured Data -->
|
||||
<script type="application/ld+json">
|
||||
{
|
||||
"@context": "https://schema.org",
|
||||
"@type": "TechArticle",
|
||||
"headline": "MikroTik Centralized Management Platform",
|
||||
"description": "Centralized management for MikroTik RouterOS fleets. Configuration, monitoring, backups, and security from a single self-hosted platform.",
|
||||
"datePublished": "2026-03-15",
|
||||
"author": {
|
||||
"@type": "Organization",
|
||||
"name": "The Other Dude"
|
||||
},
|
||||
"publisher": {
|
||||
"@type": "Organization",
|
||||
"name": "The Other Dude",
|
||||
"url": "https://theotherdude.net"
|
||||
},
|
||||
"mainEntityOfPage": "https://theotherdude.net/docs/mikrotik-centralized-management.html"
|
||||
}
|
||||
</script>
|
||||
|
||||
<!-- Fonts -->
|
||||
<link rel="preconnect" href="https://fonts.googleapis.com">
|
||||
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
|
||||
<link href="https://fonts.googleapis.com/css2?family=DM+Sans:wght@400;500;700&family=Fira+Code:wght@400;500&family=Outfit:wght@400;500;600;700;800&display=swap" rel="stylesheet">
|
||||
|
||||
<link rel="stylesheet" href="../style.css">
|
||||
<style>
|
||||
.seo-doc {
|
||||
max-width: 760px;
|
||||
margin: 0 auto;
|
||||
padding: 80px 24px 120px;
|
||||
}
|
||||
.seo-doc-meta {
|
||||
color: var(--text-muted);
|
||||
font-size: 14px;
|
||||
margin-bottom: 8px;
|
||||
}
|
||||
.seo-doc h1 {
|
||||
font-family: "Outfit", sans-serif;
|
||||
font-weight: 700;
|
||||
font-size: 2.4rem;
|
||||
line-height: 1.2;
|
||||
color: var(--text-primary);
|
||||
margin-bottom: 32px;
|
||||
}
|
||||
.seo-doc h2 {
|
||||
font-family: "Outfit", sans-serif;
|
||||
font-weight: 600;
|
||||
font-size: 1.35rem;
|
||||
color: var(--text-primary);
|
||||
margin-top: 52px;
|
||||
margin-bottom: 16px;
|
||||
}
|
||||
.seo-doc p {
|
||||
color: var(--text-secondary);
|
||||
font-size: 1.05rem;
|
||||
line-height: 1.75;
|
||||
margin-bottom: 20px;
|
||||
}
|
||||
.seo-doc p strong {
|
||||
color: var(--text-primary);
|
||||
}
|
||||
.seo-doc ul, .seo-doc ol {
|
||||
color: var(--text-secondary);
|
||||
font-size: 1.05rem;
|
||||
line-height: 1.75;
|
||||
margin-bottom: 20px;
|
||||
padding-left: 24px;
|
||||
}
|
||||
.seo-doc li {
|
||||
margin-bottom: 8px;
|
||||
}
|
||||
.seo-doc li strong {
|
||||
color: var(--text-primary);
|
||||
}
|
||||
.seo-doc a {
|
||||
color: var(--accent);
|
||||
text-decoration: underline;
|
||||
text-underline-offset: 3px;
|
||||
}
|
||||
.seo-doc a:hover {
|
||||
color: var(--text-primary);
|
||||
}
|
||||
.seo-doc .back-link {
|
||||
display: inline-block;
|
||||
margin-bottom: 32px;
|
||||
font-size: 14px;
|
||||
text-decoration: none;
|
||||
color: var(--text-muted);
|
||||
}
|
||||
.seo-doc .back-link:hover {
|
||||
color: var(--accent);
|
||||
}
|
||||
.related-links {
|
||||
margin-top: 52px;
|
||||
padding-top: 32px;
|
||||
border-top: 1px solid var(--border);
|
||||
}
|
||||
.related-links h2 {
|
||||
margin-top: 0;
|
||||
}
|
||||
.related-links ul {
|
||||
list-style: none;
|
||||
padding-left: 0;
|
||||
}
|
||||
.related-links li::before {
|
||||
content: "→ ";
|
||||
color: var(--accent);
|
||||
}
|
||||
@media (max-width: 480px) {
|
||||
.seo-doc h1 { font-size: 1.8rem; }
|
||||
.seo-doc { padding: 60px 20px 80px; }
|
||||
}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
|
||||
<nav class="site-nav site-nav--light" aria-label="Main navigation">
|
||||
<div class="nav-inner container">
|
||||
<a href="../index.html" class="nav-logo">
|
||||
<svg class="nav-logo-mark" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 64 64" width="32" height="32" aria-hidden="true">
|
||||
<rect x="2" y="2" width="60" height="60" rx="8" fill="none" stroke="#8B1A1A" stroke-width="2"/>
|
||||
<rect x="6" y="6" width="52" height="52" rx="5" fill="none" stroke="#F5E6C8" stroke-width="1.5"/>
|
||||
<rect x="8" y="8" width="48" height="48" rx="4" fill="#8B1A1A" opacity="0.15"/>
|
||||
<path d="M32 8 L56 32 L32 56 L8 32 Z" fill="none" stroke="#8B1A1A" stroke-width="2"/>
|
||||
<path d="M32 13 L51 32 L32 51 L13 32 Z" fill="none" stroke="#F5E6C8" stroke-width="1.5"/>
|
||||
<path d="M32 18 L46 32 L32 46 L18 32 Z" fill="#8B1A1A"/>
|
||||
<path d="M32 19 L38 32 L32 45 L26 32 Z" fill="#2A9D8F"/>
|
||||
<path d="M19 32 L32 26 L45 32 L32 38 Z" fill="#F5E6C8"/>
|
||||
<circle cx="32" cy="32" r="5" fill="#8B1A1A"/>
|
||||
<circle cx="32" cy="32" r="2.5" fill="#2A9D8F"/>
|
||||
<path d="M10 10 L16 10 L10 16 Z" fill="#2A9D8F" opacity="0.7"/>
|
||||
<path d="M54 10 L54 16 L48 10 Z" fill="#2A9D8F" opacity="0.7"/>
|
||||
<path d="M10 54 L16 54 L10 48 Z" fill="#2A9D8F" opacity="0.7"/>
|
||||
<path d="M54 54 L48 54 L54 48 Z" fill="#2A9D8F" opacity="0.7"/>
|
||||
</svg>
|
||||
<span>The Other Dude</span>
|
||||
</a>
|
||||
<div class="nav-links">
|
||||
<a href="../index.html#what-it-does" class="nav-link">Features</a>
|
||||
<a href="../docs.html" class="nav-link">Docs</a>
|
||||
<a href="../blog/" class="nav-link">Blog</a>
|
||||
<a href="https://github.com/staack/the-other-dude" class="nav-link" rel="noopener">GitHub</a>
|
||||
<a href="../docs.html#quickstart" class="nav-cta">Get Started</a>
|
||||
</div>
|
||||
</div>
|
||||
</nav>
|
||||
|
||||
<main>
|
||||
<article class="seo-doc">
|
||||
<a href="../docs.html" class="back-link">← Back to Docs</a>
|
||||
|
||||
<h1>Centralized Management for MikroTik Router Fleets</h1>
|
||||
|
||||
<h2>The Problem</h2>
|
||||
|
||||
<p>Managing a handful of MikroTik routers is straightforward. You open WinBox, make your changes, and move on. But at some point — ten devices, fifty, a few hundred — that approach falls apart. Individual device management doesn't scale.</p>
|
||||
|
||||
<p>Without mikrotik centralized management, the same problems surface at every shop that runs RouterOS at any meaningful scale. Configuration inconsistencies accumulate across sites: one router is still running a deprecated DHCP pool, another has a firewall rule that was supposed to be temporary six months ago, a third has credentials that haven't rotated since a contractor left. Firmware versions drift across the fleet. Visibility disappears — you're not sure which devices are healthy until something breaks and a client calls.</p>
|
||||
|
||||
<p>The operational overhead compounds. Every change requires logging into each device individually. Rollbacks mean remembering what the previous state was, if you wrote it down at all. Audits are manual. Backups are either nonexistent or ad hoc shell scripts that may or may not have run recently.</p>
|
||||
|
||||
<p>The underlying issue is that device-by-device management doesn't give you a fleet. It gives you a collection of individual routers that happen to share a vendor. Centralized management is what turns that collection into something you can actually operate.</p>
|
||||
|
||||
<h2>The Current MikroTik Management Landscape</h2>
|
||||
|
||||
<p>The existing tools for routeros configuration management each cover part of the problem:</p>
|
||||
|
||||
<ul>
|
||||
<li><strong>WinBox</strong> — The standard MikroTik management tool, and genuinely excellent for what it does. Single-device configuration, real-time traffic monitoring, firewall rule editing — it's fast and purpose-built. But it's purely single-device. There's no fleet view, no bulk operations, no config history. It's the right tool for hands-on work on one router at a time.</li>
|
||||
<li><strong>The Dude</strong> — MikroTik's own network management platform. Useful for L2/L3 topology discovery and basic device health at a glance. The monitoring features are decent for smaller deployments. However, configuration management is minimal, and the platform doesn't scale gracefully beyond a few hundred devices. It's a monitoring and topology tool, not a configuration management platform.</li>
|
||||
<li><strong>SSH and API scripting</strong> — RouterOS scripting and the REST/JSON API are powerful, but they shift the burden onto you. You're writing your own error handling, your own state management, your own rollback logic. That's real engineering work. Scripts solve specific problems well but don't constitute a management platform.</li>
|
||||
<li><strong>Third-party NMS platforms (PRTG, Zabbix, LibreNMS)</strong> — Strong on monitoring, weaker or nonexistent on configuration management. They'll tell you when a device is down or a threshold is breached, but they won't let you browse the RouterOS config tree, push changes safely, or manage credentials across the fleet.</li>
|
||||
<li><strong>Commercial platforms (Unimus, NetBox, Auvik)</strong> — These solve real parts of the problem. Unimus in particular has solid RouterOS backup and config management. But commercial platforms are closed-source, cloud-dependent, or not purpose-built for MikroTik environments. For MSPs and ISPs who want full control over their data and deployment, they're a poor fit.</li>
|
||||
</ul>
|
||||
|
||||
<p>None of these options alone provides comprehensive mikrotik router fleet management across the full lifecycle: inventory, configuration, monitoring, backups, security, and operations in one place.</p>
|
||||
|
||||
<h2>What Centralized Management Should Cover</h2>
|
||||
|
||||
<p>A complete centralized management platform for MikroTik fleets needs to address six problem areas:</p>
|
||||
|
||||
<ol>
|
||||
<li><strong>Visibility</strong> — A fleet-wide dashboard showing device inventory, health status, active alerts, bandwidth utilization, and wireless issues. You need to know the state of every device without logging into any of them.</li>
|
||||
<li><strong>Configuration</strong> — The ability to browse, edit, push, and track configuration changes across any device in the fleet. That includes safe push mechanisms with automatic rollback if a change breaks connectivity, template-based operations for applying consistent configs across groups of devices, and a change history that tells you what changed, when, and who made the change.</li>
|
||||
<li><strong>Monitoring</strong> — Real-time metrics with historical trending. Threshold-based alerts with configurable notification channels. The ability to suppress alerts during scheduled maintenance windows so on-call staff aren't paged for expected downtime.</li>
|
||||
<li><strong>Backups</strong> — Automated configuration snapshots that run without human intervention, a version timeline you can navigate, side-by-side diff views between any two snapshots, and a tested restore path. Backups that exist but can't be restored aren't backups.</li>
|
||||
<li><strong>Security</strong> — Encrypted credential storage, a complete audit trail of all management actions, role-based access control so operators can do their jobs without needing admin privileges, and tenant isolation for MSPs managing multiple clients.</li>
|
||||
<li><strong>Operations</strong> — Firmware version tracking and upgrade management, bulk command execution, VPN management, and maintenance workflow support.</li>
|
||||
</ol>
|
||||
|
||||
<h2>How The Other Dude Provides Centralized MikroTik Management</h2>
|
||||
|
||||
<p>The Other Dude is a self-hosted platform built specifically for MikroTik router fleet management. Here's what it covers across each area:</p>
|
||||
|
||||
<p><strong>Fleet Visibility:</strong> The main dashboard surfaces device health, active alerts, bandwidth utilization, and wireless issues at a glance. The device table uses virtual scrolling to handle hundreds of devices without performance degradation. A geographic map and a network topology view (built on ReactFlow with Dagre layout) give you spatial and logical context for the fleet. A built-in subnet scanner handles device discovery when you're onboarding a new site.</p>
|
||||
|
||||
<p><strong>Configuration Management:</strong> The config editor exposes the full RouterOS path hierarchy, letting you navigate and edit any config section the same way WinBox does — but with fleet-wide reach. Config pushes use a two-phase process: the change is applied, a connectivity check runs, and if the check fails the router automatically reverts to its previous state. This eliminates the risk of locking yourself out with a bad firewall rule or routing change. Simple Config mode provides a streamlined UI for common tasks — IP addressing, DHCP, firewall basics — modeled after consumer router interfaces for operators who don't need full RouterOS syntax exposure. Templates support variable substitution for batch operations across groups of devices.</p>
|
||||
|
||||
<p><strong>Monitoring and Alerts:</strong> Health, traffic, and wireless metrics are stored in TimescaleDB hypertables, which handle high-frequency time-series data efficiently without requiring separate infrastructure. Alerts are threshold-based and configurable per device or device group. Real-time updates push via SSE backed by NATS JetStream. Maintenance windows suppress alerts for scheduled work so you're not managing noise during planned outages.</p>
|
||||
|
||||
<p><strong>Security:</strong> Authentication uses SRP-6a — a zero-knowledge protocol where the server never sees your password. Device credentials are encrypted at rest using AES-256-GCM with per-tenant envelope encryption via OpenBao Transit. Role-based access control supports four roles (super_admin, admin, operator, viewer) with appropriate permission boundaries at each level. PostgreSQL Row-Level Security enforces tenant isolation at the database layer — one tenant's data is never accessible to another's, regardless of application-layer logic. Every management action is recorded in an immutable audit trail.</p>
|
||||
|
||||
<p><strong>Self-Hosted:</strong> The entire platform deploys via Docker Compose. Your device credentials, configuration history, and monitoring data stay on your infrastructure. The platform is open source and available on GitHub.</p>
|
||||
|
||||
<h2>Getting Started</h2>
|
||||
|
||||
<p>Getting The Other Dude running against your first MikroTik device takes about ten minutes. Clone the repository, run <code>setup.py</code> to walk through the initial configuration, point the platform at your first router's IP, and you'll have a connected device with monitoring active and the first config backup in the timeline. Full setup instructions, including Docker Compose prerequisites and initial credential configuration, are in the <a href="../docs.html#quickstart">Quick Start guide</a>.</p>
|
||||
|
||||
<div class="related-links">
|
||||
<h2>Related Guides</h2>
|
||||
<ul>
|
||||
<li><a href="mikrotik-configuration-drift.html">How to detect configuration drift across a MikroTik fleet</a></li>
|
||||
<li><a href="mikrotik-router-backup-automation.html">Automate RouterOS config backups with version history</a></li>
|
||||
<li><a href="manage-multiple-mikrotik-routers.html">Managing multiple MikroTik routers from one interface</a></li>
|
||||
<li><a href="mikrotik-router-monitoring.html">Monitoring MikroTik routers at scale</a></li>
|
||||
<li><a href="https://github.com/staack/the-other-dude" rel="noopener">The Other Dude on GitHub</a></li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
</article>
|
||||
</main>
|
||||
|
||||
<footer class="site-footer">
|
||||
<div class="footer-inner container">
|
||||
<div class="footer-brand">
|
||||
<span class="footer-logo">
|
||||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 64 64" width="24" height="24" aria-hidden="true" style="vertical-align: middle; margin-right: 8px;">
|
||||
<rect x="2" y="2" width="60" height="60" rx="8" fill="none" stroke="#8B1A1A" stroke-width="2"/>
|
||||
<rect x="6" y="6" width="52" height="52" rx="5" fill="none" stroke="#F5E6C8" stroke-width="1.5"/>
|
||||
<rect x="8" y="8" width="48" height="48" rx="4" fill="#8B1A1A" opacity="0.15"/>
|
||||
<path d="M32 18 L46 32 L32 46 L18 32 Z" fill="#8B1A1A"/>
|
||||
<path d="M32 19 L38 32 L32 45 L26 32 Z" fill="#2A9D8F"/>
|
||||
<path d="M19 32 L32 26 L45 32 L32 38 Z" fill="#F5E6C8"/>
|
||||
<circle cx="32" cy="32" r="5" fill="#8B1A1A"/>
|
||||
<circle cx="32" cy="32" r="2.5" fill="#2A9D8F"/>
|
||||
</svg>
|
||||
The Other Dude
|
||||
</span>
|
||||
<span class="footer-copy">© 2026 The Other Dude. All rights reserved.</span>
|
||||
</div>
|
||||
<nav class="footer-links">
|
||||
<a href="../docs.html">Docs</a>
|
||||
<a href="../blog/">Blog</a>
|
||||
<a href="https://github.com/staack/the-other-dude" rel="noopener">GitHub</a>
|
||||
<a href="mailto:license@theotherdude.net">Licensing</a>
|
||||
</nav>
|
||||
</div>
|
||||
</footer>
|
||||
|
||||
<!-- Cloudflare Web Analytics --><script defer src='https://static.cloudflareinsights.com/beacon.min.js' data-cf-beacon='{"token": "d5f1e31cb9744c998a8f7d1303c6efef"}'></script><!-- End Cloudflare Web Analytics -->
|
||||
</body>
|
||||
</html>
|
||||
173
docs/website/docs/mikrotik-configuration-drift.html
Normal file
173
docs/website/docs/mikrotik-configuration-drift.html
Normal file
@@ -0,0 +1,173 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<title>MikroTik Configuration Drift Detection</title>
|
||||
<meta name="description" content="How to detect and prevent configuration drift in MikroTik RouterOS fleets. Automated auditing, backup comparison, and centralized management.">
|
||||
<meta name="keywords" content="mikrotik configuration drift, routeros configuration audit, mikrotik config management, router configuration comparison">
|
||||
<meta name="robots" content="index, follow">
|
||||
<meta name="theme-color" content="#FAFBFC">
|
||||
<link rel="canonical" href="https://theotherdude.net/docs/mikrotik-configuration-drift.html">
|
||||
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 64 64'><rect x='2' y='2' width='60' height='60' rx='8' fill='none' stroke='%238B1A1A' stroke-width='2'/><rect x='6' y='6' width='52' height='52' rx='5' fill='none' stroke='%23F5E6C8' stroke-width='1.5'/><rect x='8' y='8' width='48' height='48' rx='4' fill='%238B1A1A' opacity='0.15'/><path d='M32 8 L56 32 L32 56 L8 32 Z' fill='none' stroke='%238B1A1A' stroke-width='2'/><path d='M32 13 L51 32 L32 51 L13 32 Z' fill='none' stroke='%23F5E6C8' stroke-width='1.5'/><path d='M32 18 L46 32 L32 46 L18 32 Z' fill='%238B1A1A'/><path d='M32 19 L38 32 L32 45 L26 32 Z' fill='%232A9D8F'/><path d='M19 32 L32 26 L45 32 L32 38 Z' fill='%23F5E6C8'/><circle cx='32' cy='32' r='5' fill='%238B1A1A'/><circle cx='32' cy='32' r='2.5' fill='%232A9D8F'/><path d='M10 10 L16 10 L10 16 Z' fill='%232A9D8F' opacity='0.7'/><path d='M54 10 L54 16 L48 10 Z' fill='%232A9D8F' opacity='0.7'/><path d='M10 54 L16 54 L10 48 Z' fill='%232A9D8F' opacity='0.7'/><path d='M54 54 L48 54 L54 48 Z' fill='%232A9D8F' opacity='0.7'/></svg>">
|
||||
|
||||
<meta property="og:type" content="article">
|
||||
<meta property="og:title" content="MikroTik Configuration Drift Detection">
|
||||
<meta property="og:description" content="How to detect and prevent configuration drift in MikroTik RouterOS fleets.">
|
||||
<meta property="og:url" content="https://theotherdude.net/docs/mikrotik-configuration-drift.html">
|
||||
<meta property="og:site_name" content="The Other Dude">
|
||||
|
||||
<link rel="stylesheet" href="../style.css">
|
||||
<link rel="preconnect" href="https://fonts.googleapis.com">
|
||||
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
|
||||
<link href="https://fonts.googleapis.com/css2?family=DM+Sans:wght@400;500;700&family=Fira+Code:wght@400;500&family=Outfit:wght@400;500;600;700;800&display=swap" rel="stylesheet">
|
||||
</head>
|
||||
<body class="docs-page">
|
||||
<a href="#article-content" class="skip-link">Skip to main content</a>
|
||||
|
||||
<nav class="site-nav site-nav--light" aria-label="Main navigation">
|
||||
<div class="nav-inner container">
|
||||
<a href="../index.html" class="nav-logo">
|
||||
<svg class="nav-logo-mark" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 64 64" width="32" height="32" aria-hidden="true">
|
||||
<rect x="2" y="2" width="60" height="60" rx="8" fill="none" stroke="#8B1A1A" stroke-width="2"/>
|
||||
<rect x="6" y="6" width="52" height="52" rx="5" fill="none" stroke="#F5E6C8" stroke-width="1.5"/>
|
||||
<rect x="8" y="8" width="48" height="48" rx="4" fill="#8B1A1A" opacity="0.15"/>
|
||||
<path d="M32 8 L56 32 L32 56 L8 32 Z" fill="none" stroke="#8B1A1A" stroke-width="2"/>
|
||||
<path d="M32 13 L51 32 L32 51 L13 32 Z" fill="none" stroke="#F5E6C8" stroke-width="1.5"/>
|
||||
<path d="M32 18 L46 32 L32 46 L18 32 Z" fill="#8B1A1A"/>
|
||||
<path d="M32 19 L38 32 L32 45 L26 32 Z" fill="#2A9D8F"/>
|
||||
<path d="M19 32 L32 26 L45 32 L32 38 Z" fill="#F5E6C8"/>
|
||||
<circle cx="32" cy="32" r="5" fill="#8B1A1A"/>
|
||||
<circle cx="32" cy="32" r="2.5" fill="#2A9D8F"/>
|
||||
<path d="M10 10 L16 10 L10 16 Z" fill="#2A9D8F" opacity="0.7"/>
|
||||
<path d="M54 10 L54 16 L48 10 Z" fill="#2A9D8F" opacity="0.7"/>
|
||||
<path d="M10 54 L16 54 L10 48 Z" fill="#2A9D8F" opacity="0.7"/>
|
||||
<path d="M54 54 L48 54 L54 48 Z" fill="#2A9D8F" opacity="0.7"/>
|
||||
</svg>
|
||||
<span>The Other Dude</span>
|
||||
</a>
|
||||
<div class="nav-links">
|
||||
<a href="../index.html#what-it-does" class="nav-link">Features</a>
|
||||
<a href="../docs.html" class="nav-link">Docs</a>
|
||||
<a href="../blog/" class="nav-link">Blog</a>
|
||||
<a href="https://github.com/staack/the-other-dude" class="nav-link" rel="noopener">GitHub</a>
|
||||
<a href="../docs.html#quickstart" class="nav-cta">Get Started</a>
|
||||
</div>
|
||||
</div>
|
||||
</nav>
|
||||
|
||||
<main id="article-content">
|
||||
<article class="docs-content" style="max-width: 800px; margin: 0 auto; padding: 60px 24px 120px;">
|
||||
|
||||
<h1>How to Detect Configuration Drift in MikroTik Routers</h1>
|
||||
|
||||
<p>Configuration drift is one of the quieter failure modes in network management. Routers that were identical at deployment gradually diverge — through manual fixes, firmware upgrades, emergency changes, and accumulated tweaks. This article explains why drift happens specifically with RouterOS, why it is difficult to detect, and what an effective solution looks like in practice.</p>
|
||||
|
||||
<h2>The Problem</h2>
|
||||
|
||||
<p>Configuration drift describes the gap between the intended state of a device and its actual running configuration. For a single router this is manageable. Across a fleet of dozens or hundreds of MikroTik devices, it becomes a real operational hazard.</p>
|
||||
|
||||
<p>The pattern is familiar: an engineer connects via WinBox to resolve an outage, adds a static route or adjusts a firewall rule, and moves on. The fix never makes it into documentation or a change ticket. Later, a firmware upgrade silently adds new default values. Someone else modifies the same firewall rule "temporarily" during a maintenance window and forgets to revert it.</p>
|
||||
|
||||
<p>After six months, the device is running something no one fully understands. If the hardware fails, reproducing that config from scratch is guesswork.</p>
|
||||
|
||||
<h2>Why RouterOS Makes This Hard</h2>
|
||||
|
||||
<p>RouterOS does not include a native mechanism for tracking configuration changes or comparing configs across devices. This is not a complaint — it is just a fact of how the platform is designed, and it matters when you are trying to build operational processes around it.</p>
|
||||
|
||||
<p>A few specific pain points:</p>
|
||||
|
||||
<ul>
|
||||
<li><strong>No built-in config versioning.</strong> RouterOS does not maintain a history of what changed, when, or who changed it. The running config is the only version.</li>
|
||||
<li><strong>Export output is not deterministic across firmware versions.</strong> The <code>/export</code> command can produce different ordering, include new default keys, or drop previously explicit values when you upgrade RouterOS. Naively diffing exports from devices on different firmware versions produces noise.</li>
|
||||
<li><strong>WinBox changes leave no audit trail.</strong> Actions taken through the GUI are not logged in a way that survives reboots or is easily queryable.</li>
|
||||
<li><strong>No desired-state model.</strong> RouterOS does not have a concept of "this is what the config should be." The running config is authoritative by definition. There is nothing to check against.</li>
|
||||
<li><strong>Fleet comparison requires external tooling.</strong> There is no native way to look across twenty devices and ask which ones have diverged from each other.</li>
|
||||
</ul>
|
||||
|
||||
<h2>Common Workarounds</h2>
|
||||
|
||||
<p>Engineers who have hit this problem have developed several approaches, each with real limitations.</p>
|
||||
|
||||
<p><strong>Scheduled <code>/export</code> to FTP or SFTP.</strong> This is the most common approach and it does produce periodic snapshots. The problem is what happens next: text dumps pile up in a directory, and comparing them requires either manual inspection or custom scripting. When a device exports 800 lines of config, spotting a single changed firewall rule by eye is unreliable.</p>
|
||||
|
||||
<p><strong>The Dude.</strong> MikroTik's own monitoring tool tracks device health and topology well. It does not track configuration changes. It will tell you a router is up; it will not tell you its firewall rules changed overnight.</p>
|
||||
|
||||
<p><strong>Custom diff scripts.</strong> Some teams build shell scripts that pull exports, normalize whitespace, strip firmware-version noise, and run <code>diff</code>. This can work, but these scripts are fragile. They break on RouterOS upgrades, fail silently when a device is unreachable, and tend to accumulate exceptions and special cases until the person who wrote them is the only one who understands them.</p>
|
||||
|
||||
<p><strong>Spreadsheets.</strong> For small deployments, a spreadsheet tracking what each site should have configured is better than nothing. It does not scale, and it is only as accurate as the last time someone updated it.</p>
|
||||
|
||||
<h2>What a Proper Solution Requires</h2>
|
||||
|
||||
<p>Solving configuration drift effectively requires a few things working together.</p>
|
||||
|
||||
<p>First, <strong>automated, periodic snapshots</strong> from every device. Manual processes do not hold up — the snapshot needs to happen whether or not an engineer remembers to trigger it. The interval should be configurable; some environments need hourly snapshots, others daily.</p>
|
||||
|
||||
<p>Second, <strong>version history with diff visibility.</strong> Storing snapshots is only useful if you can compare them. You need to be able to see exactly what changed between two points in time — not just that something changed, but which lines were added, removed, or modified. A side-by-side diff view makes this fast to review.</p>
|
||||
|
||||
<p>Third, <strong>alerts when configs change unexpectedly.</strong> Drift you don't know about is the dangerous kind. An alert when a device's config changes between polling cycles lets you investigate before that change causes a problem, rather than after.</p>
|
||||
|
||||
<p>Fourth, <strong>an audit trail tied to user actions.</strong> When a config change comes from a push made through your management platform, you want to know which user initiated it, when, and what it contained. This is separate from detecting drift caused by out-of-band changes — you need both.</p>
|
||||
|
||||
<h2>How The Other Dude Handles Configuration Drift</h2>
|
||||
|
||||
<p>The Other Dude polls RouterOS devices on a configurable interval using the RouterOS binary API (port 8729, TLS). On each poll cycle it retrieves the full running configuration and stores it in PostgreSQL alongside a complete version history. Every stored snapshot is compared to the previous one; if anything changed, the difference is recorded.</p>
|
||||
|
||||
<p>The web UI includes a side-by-side diff viewer. You can select any two snapshots for a device — or compare two different devices — and see exactly which lines differ. This makes it straightforward to answer questions like "what changed on this router between Tuesday and Thursday" or "why does this branch site have different firewall rules than the others."</p>
|
||||
|
||||
<p>Config changes pushed through the platform are recorded in an audit trail with full user attribution. If someone pushes a new firewall ruleset or modifies an interface address, that action is logged with the user, timestamp, and the exact config diff applied. Out-of-band changes made directly via WinBox or SSH will show up in the next polling cycle as an unexpected diff.</p>
|
||||
|
||||
<p>For safe config pushes, The Other Dude uses a two-phase approach: changes are applied to the device, and the platform waits for a confirmation that the device is still reachable. If the device goes silent after the change — which can happen if a firewall or routing change cuts off the management path — the platform automatically reverts to the previous config. This significantly reduces the risk of locking yourself out of a remote device.</p>
|
||||
|
||||
<p>For fleet-scale work, the platform supports config templates with variable substitution. You can define a template for a class of site (branch office, retail location, distribution hub) and push it across a batch of devices with per-device values filled in. This makes it easier to maintain consistency across similar sites and to identify which devices have diverged from that common baseline. To be clear: the current implementation detects config changes between snapshots. Full desired-state compliance checking — where the system continuously validates each device against a canonical template and flags deviations — is not yet implemented, but the snapshot and diff infrastructure is designed to support it.</p>
|
||||
|
||||
<h2>Related Guides</h2>
|
||||
|
||||
<ul>
|
||||
<li><a href="mikrotik-router-backup-automation.html">Automate MikroTik router backups</a></li>
|
||||
<li><a href="manage-multiple-mikrotik-routers.html">Manage multiple MikroTik routers</a></li>
|
||||
<li><a href="mikrotik-router-monitoring.html">Monitor MikroTik routers at scale</a></li>
|
||||
<li><a href="mikrotik-centralized-management.html">MikroTik centralized management</a></li>
|
||||
</ul>
|
||||
|
||||
<p><a href="https://github.com/staack/the-other-dude">View on GitHub</a></p>
|
||||
|
||||
</article>
|
||||
</main>
|
||||
|
||||
<footer class="site-footer">
|
||||
<div class="footer-inner container">
|
||||
<div class="footer-brand">
|
||||
<span class="footer-logo">
|
||||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 64 64" width="24" height="24" aria-hidden="true" style="vertical-align: middle; margin-right: 8px;">
|
||||
<rect x="2" y="2" width="60" height="60" rx="8" fill="none" stroke="#8B1A1A" stroke-width="2"/>
|
||||
<rect x="6" y="6" width="52" height="52" rx="5" fill="none" stroke="#F5E6C8" stroke-width="1.5"/>
|
||||
<rect x="8" y="8" width="48" height="48" rx="4" fill="#8B1A1A" opacity="0.15"/>
|
||||
<path d="M32 8 L56 32 L32 56 L8 32 Z" fill="none" stroke="#8B1A1A" stroke-width="2"/>
|
||||
<path d="M32 13 L51 32 L32 51 L13 32 Z" fill="none" stroke="#F5E6C8" stroke-width="1.5"/>
|
||||
<path d="M32 18 L46 32 L32 46 L18 32 Z" fill="#8B1A1A"/>
|
||||
<path d="M32 19 L38 32 L32 45 L26 32 Z" fill="#2A9D8F"/>
|
||||
<path d="M19 32 L32 26 L45 32 L32 38 Z" fill="#F5E6C8"/>
|
||||
<circle cx="32" cy="32" r="5" fill="#8B1A1A"/>
|
||||
<circle cx="32" cy="32" r="2.5" fill="#2A9D8F"/>
|
||||
</svg>
|
||||
The Other Dude
|
||||
</span>
|
||||
<span class="footer-copy">© 2026 The Other Dude. All rights reserved.</span>
|
||||
</div>
|
||||
<nav class="footer-links" aria-label="Footer navigation">
|
||||
<a href="../index.html">Home</a>
|
||||
<a href="../blog/">Blog</a>
|
||||
<a href="../docs.html#quickstart">Quick Start</a>
|
||||
<a href="../docs.html#security-model">Security</a>
|
||||
<a href="../docs.html#api-endpoints">API Reference</a>
|
||||
<a href="https://github.com/staack/the-other-dude" rel="noopener">GitHub</a>
|
||||
<a href="mailto:license@theotherdude.net">Licensing</a>
|
||||
<a href="mailto:support@theotherdude.net">Support</a>
|
||||
</nav>
|
||||
</div>
|
||||
</footer>
|
||||
|
||||
<script defer src='https://static.cloudflareinsights.com/beacon.min.js' data-cf-beacon='{"token": "d5f1e31cb9744c998a8f7d1303c6efef"}'></script>
|
||||
</body>
|
||||
</html>
|
||||
290
docs/website/docs/mikrotik-router-backup-automation.html
Normal file
290
docs/website/docs/mikrotik-router-backup-automation.html
Normal file
@@ -0,0 +1,290 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
|
||||
<title>MikroTik Router Backup Automation</title>
|
||||
<meta name="description" content="Automate MikroTik router configuration backups. Compare backup versions, restore configs, and track changes across your RouterOS fleet.">
|
||||
<meta name="keywords" content="mikrotik backup automation, mikrotik configuration management, RouterOS backup, MikroTik config export, RouterOS fleet backup">
|
||||
<meta name="robots" content="index, follow">
|
||||
<meta name="theme-color" content="#FAFBFC">
|
||||
<link rel="canonical" href="https://theotherdude.net/docs/mikrotik-router-backup-automation.html">
|
||||
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 64 64'><rect x='2' y='2' width='60' height='60' rx='8' fill='none' stroke='%238B1A1A' stroke-width='2'/><rect x='6' y='6' width='52' height='52' rx='5' fill='none' stroke='%23F5E6C8' stroke-width='1.5'/><rect x='8' y='8' width='48' height='48' rx='4' fill='%238B1A1A' opacity='0.15'/><path d='M32 8 L56 32 L32 56 L8 32 Z' fill='none' stroke='%238B1A1A' stroke-width='2'/><path d='M32 13 L51 32 L32 51 L13 32 Z' fill='none' stroke='%23F5E6C8' stroke-width='1.5'/><path d='M32 18 L46 32 L32 46 L18 32 Z' fill='%238B1A1A'/><path d='M32 19 L38 32 L32 45 L26 32 Z' fill='%232A9D8F'/><path d='M19 32 L32 26 L45 32 L32 38 Z' fill='%23F5E6C8'/><circle cx='32' cy='32' r='5' fill='%238B1A1A'/><circle cx='32' cy='32' r='2.5' fill='%232A9D8F'/><path d='M10 10 L16 10 L10 16 Z' fill='%232A9D8F' opacity='0.7'/><path d='M54 10 L54 16 L48 10 Z' fill='%232A9D8F' opacity='0.7'/><path d='M10 54 L16 54 L10 48 Z' fill='%232A9D8F' opacity='0.7'/><path d='M54 54 L48 54 L54 48 Z' fill='%232A9D8F' opacity='0.7'/></svg>">
|
||||
|
||||
<!-- Open Graph -->
|
||||
<meta property="og:type" content="article">
|
||||
<meta property="og:title" content="MikroTik Router Backup Automation — The Other Dude">
|
||||
<meta property="og:description" content="Automate MikroTik router configuration backups. Compare backup versions, restore configs, and track changes across your RouterOS fleet.">
|
||||
<meta property="og:url" content="https://theotherdude.net/docs/mikrotik-router-backup-automation.html">
|
||||
<meta property="og:site_name" content="The Other Dude">
|
||||
|
||||
<!-- Structured Data -->
|
||||
<script type="application/ld+json">
|
||||
{
|
||||
"@context": "https://schema.org",
|
||||
"@type": "TechArticle",
|
||||
"headline": "How to Automate MikroTik Router Backups",
|
||||
"description": "Automate MikroTik router configuration backups. Compare backup versions, restore configs, and track changes across your RouterOS fleet.",
|
||||
"author": {
|
||||
"@type": "Organization",
|
||||
"name": "The Other Dude"
|
||||
},
|
||||
"publisher": {
|
||||
"@type": "Organization",
|
||||
"name": "The Other Dude",
|
||||
"url": "https://theotherdude.net"
|
||||
},
|
||||
"mainEntityOfPage": "https://theotherdude.net/docs/mikrotik-router-backup-automation.html"
|
||||
}
|
||||
</script>
|
||||
|
||||
<!-- Fonts -->
|
||||
<link rel="preconnect" href="https://fonts.googleapis.com">
|
||||
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
|
||||
<link href="https://fonts.googleapis.com/css2?family=DM+Sans:wght@400;500;700&family=Fira+Code:wght@400;500&family=Outfit:wght@400;500;600;700;800&display=swap" rel="stylesheet">
|
||||
|
||||
<link rel="stylesheet" href="../style.css">
|
||||
<style>
|
||||
.doc-article {
|
||||
max-width: 760px;
|
||||
margin: 0 auto;
|
||||
padding: 80px 24px 120px;
|
||||
}
|
||||
.doc-article-meta {
|
||||
color: var(--text-muted);
|
||||
font-size: 14px;
|
||||
margin-bottom: 8px;
|
||||
}
|
||||
.doc-article h1 {
|
||||
font-family: "Outfit", sans-serif;
|
||||
font-weight: 700;
|
||||
font-size: 2.5rem;
|
||||
line-height: 1.2;
|
||||
color: var(--text-primary);
|
||||
margin-bottom: 32px;
|
||||
}
|
||||
.doc-article h2 {
|
||||
font-family: "Outfit", sans-serif;
|
||||
font-weight: 600;
|
||||
font-size: 1.4rem;
|
||||
color: var(--text-primary);
|
||||
margin-top: 48px;
|
||||
margin-bottom: 16px;
|
||||
}
|
||||
.doc-article p {
|
||||
color: var(--text-secondary);
|
||||
font-size: 1.05rem;
|
||||
line-height: 1.75;
|
||||
margin-bottom: 20px;
|
||||
}
|
||||
.doc-article p strong {
|
||||
color: var(--text-primary);
|
||||
}
|
||||
.doc-article ul {
|
||||
color: var(--text-secondary);
|
||||
font-size: 1.05rem;
|
||||
line-height: 1.75;
|
||||
margin-bottom: 20px;
|
||||
padding-left: 24px;
|
||||
}
|
||||
.doc-article ul li {
|
||||
margin-bottom: 8px;
|
||||
}
|
||||
.doc-article ul li strong {
|
||||
color: var(--text-primary);
|
||||
}
|
||||
.doc-article a {
|
||||
color: var(--accent);
|
||||
text-decoration: underline;
|
||||
text-underline-offset: 3px;
|
||||
}
|
||||
.doc-article a:hover {
|
||||
color: var(--text-primary);
|
||||
}
|
||||
.doc-article .back-link {
|
||||
display: inline-block;
|
||||
margin-bottom: 32px;
|
||||
font-size: 14px;
|
||||
text-decoration: none;
|
||||
color: var(--text-muted);
|
||||
}
|
||||
.doc-article .back-link:hover {
|
||||
color: var(--accent);
|
||||
}
|
||||
.doc-article code {
|
||||
font-family: "Fira Code", monospace;
|
||||
font-size: 0.9em;
|
||||
background: rgba(42, 157, 143, 0.08);
|
||||
border: 1px solid rgba(42, 157, 143, 0.15);
|
||||
border-radius: 4px;
|
||||
padding: 2px 6px;
|
||||
color: var(--text-primary);
|
||||
}
|
||||
.related-guides {
|
||||
margin-top: 48px;
|
||||
padding: 24px;
|
||||
background: rgba(42, 157, 143, 0.05);
|
||||
border: 1px solid rgba(42, 157, 143, 0.15);
|
||||
border-radius: 8px;
|
||||
}
|
||||
.related-guides h2 {
|
||||
margin-top: 0;
|
||||
}
|
||||
.related-guides ul {
|
||||
margin-bottom: 0;
|
||||
}
|
||||
@media (max-width: 480px) {
|
||||
.doc-article h1 { font-size: 1.8rem; }
|
||||
.doc-article { padding: 60px 20px 80px; }
|
||||
}
|
||||
</style>
|
||||
</head>
|
||||
<body class="docs-page">
|
||||
|
||||
<nav class="site-nav site-nav--light" aria-label="Main navigation">
|
||||
<div class="nav-inner container">
|
||||
<a href="../index.html" class="nav-logo">
|
||||
<svg class="nav-logo-mark" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 64 64" width="32" height="32" aria-label="The Other Dude logo">
|
||||
<rect x="2" y="2" width="60" height="60" rx="8" fill="none" stroke="#8B1A1A" stroke-width="2"/>
|
||||
<rect x="6" y="6" width="52" height="52" rx="5" fill="none" stroke="#F5E6C8" stroke-width="1.5"/>
|
||||
<rect x="8" y="8" width="48" height="48" rx="4" fill="#8B1A1A" opacity="0.15"/>
|
||||
<path d="M32 8 L56 32 L32 56 L8 32 Z" fill="none" stroke="#8B1A1A" stroke-width="2"/>
|
||||
<path d="M32 13 L51 32 L32 51 L13 32 Z" fill="none" stroke="#F5E6C8" stroke-width="1.5"/>
|
||||
<path d="M32 18 L46 32 L32 46 L18 32 Z" fill="#8B1A1A"/>
|
||||
<path d="M32 19 L38 32 L32 45 L26 32 Z" fill="#2A9D8F"/>
|
||||
<path d="M19 32 L32 26 L45 32 L32 38 Z" fill="#F5E6C8"/>
|
||||
<circle cx="32" cy="32" r="5" fill="#8B1A1A"/>
|
||||
<circle cx="32" cy="32" r="2.5" fill="#2A9D8F"/>
|
||||
<path d="M10 10 L16 10 L10 16 Z" fill="#2A9D8F" opacity="0.7"/>
|
||||
<path d="M54 10 L54 16 L48 10 Z" fill="#2A9D8F" opacity="0.7"/>
|
||||
<path d="M10 54 L16 54 L10 48 Z" fill="#2A9D8F" opacity="0.7"/>
|
||||
<path d="M54 54 L48 54 L54 48 Z" fill="#2A9D8F" opacity="0.7"/>
|
||||
</svg>
|
||||
<span>The Other Dude</span>
|
||||
</a>
|
||||
<div class="nav-links">
|
||||
<a href="../index.html" class="nav-link">Home</a>
|
||||
<a href="../index.html#what-it-does" class="nav-link">Features</a>
|
||||
<a href="../docs.html" class="nav-link">Docs</a>
|
||||
<a href="../blog/" class="nav-link">Blog</a>
|
||||
<a href="https://github.com/staack/the-other-dude" class="nav-link" rel="noopener">GitHub</a>
|
||||
<a href="../docs.html#quickstart" class="nav-cta">Get Started</a>
|
||||
</div>
|
||||
</div>
|
||||
</nav>
|
||||
|
||||
<main>
|
||||
<article class="doc-article">
|
||||
<a href="../docs.html" class="back-link">← Back to Docs</a>
|
||||
<div class="doc-article-meta">MikroTik Configuration Management</div>
|
||||
<h1>How to Automate MikroTik Router Backups</h1>
|
||||
|
||||
<h2>The Problem</h2>
|
||||
|
||||
<p>Most MikroTik routers get configured once and then left alone. Over months and years, someone adds firewall rules, tweaks NAT entries, adjusts OSPF timers. Nobody writes any of it down. The config that's running in production is the only record of what was done.</p>
|
||||
|
||||
<p>Then something breaks. A firmware upgrade goes sideways and the router reboots into a partially migrated config. A new hire cleans up "unused" firewall rules and takes down a VPN tunnel. The compact flash in a RB2011 starts throwing read errors. In every one of these cases, the question is the same: what was the config before this happened?</p>
|
||||
|
||||
<p>The answer is usually bad. An export someone ran eight months ago sitting in a random directory. An FTP server that stopped receiving backups when the disk filled up six months ago and no one noticed until now. A Scheduler script that was working fine until someone changed the FTP password. MikroTik backup automation is one of those things that either works reliably or doesn't work at all — there's rarely a middle state where it's "mostly working."</p>
|
||||
|
||||
<p>At scale this gets worse fast. If you manage fifty routers, you might be on top of it. If you manage five hundred, manual backup processes will fail silently across a meaningful percentage of your fleet at any given time.</p>
|
||||
|
||||
<h2>RouterOS Backup Methods</h2>
|
||||
|
||||
<p>RouterOS has two built-in mechanisms for saving configuration, and both have real tradeoffs.</p>
|
||||
|
||||
<p><strong><code>/system backup save</code></strong> produces a binary <code>.backup</code> file. It captures the full configuration including passwords and certificates. You can restore it with one command and come back to exactly the state the device was in. The catch: it's device-specific and version-dependent. Restoring a backup from RouterOS 6 to a device running RouterOS 7 will fail or produce unexpected results. You can't open the file in a text editor to see what's in it. You can't diff two backups to find what changed.</p>
|
||||
|
||||
<p><strong><code>/export</code></strong> produces a human-readable text file containing the RouterOS commands needed to recreate the configuration. It's possible to partially import an export on a different device, and you can read it with any text editor. The tradeoffs: it doesn't include passwords or private keys, it omits settings that are at their default values, and the ordering of entries can vary between RouterOS versions. Two exports of the same config taken on different firmware versions may look different even if nothing changed.</p>
|
||||
|
||||
<p>Neither method runs automatically. To get scheduled backups, the traditional approach is a Scheduler + FTP or SFTP script on each device. This works, but it requires per-device configuration, a working FTP server, error handling for failed transfers, and some way to detect when backups stop arriving. In a fleet of hundreds of devices, that's a lot of moving parts.</p>
|
||||
|
||||
<h2>What Goes Wrong Without Automated Backups</h2>
|
||||
|
||||
<p>The consequences of not having reliable backup automation tend to be invisible until they aren't:</p>
|
||||
|
||||
<ul>
|
||||
<li><strong>Device failure with no recent backup.</strong> Hardware fails, config is lost, and reconstruction from memory takes hours — assuming anyone still knows how it was set up.</li>
|
||||
<li><strong>Firmware upgrade with no rollback path.</strong> RouterOS major version upgrades occasionally break things. Without a pre-upgrade config export, rolling back means starting over.</li>
|
||||
<li><strong>Config change breaks connectivity.</strong> Without a recent baseline to diff against, finding what changed requires checking every section of the config manually.</li>
|
||||
<li><strong>Compliance and audit requirements.</strong> Regulated environments often require demonstrable config history. "We think the config has been like this for a while" doesn't hold up.</li>
|
||||
<li><strong>Staff turnover and tribal knowledge.</strong> The engineer who built the BGP setup left six months ago. The config is running, but no one understands it, and there's no version history to trace how it got to its current state.</li>
|
||||
</ul>
|
||||
|
||||
<h2>What a Backup System Should Do</h2>
|
||||
|
||||
<p>A reliable mikrotik backup automation solution needs to address the failure modes of the manual approach:</p>
|
||||
|
||||
<ul>
|
||||
<li><strong>Automatic scheduling.</strong> Backups should run without any per-device scripting. The schedule should be configurable centrally, not distributed across hundreds of individual device schedulers.</li>
|
||||
<li><strong>Text-based storage.</strong> Configs need to be stored in a format that supports comparison. Binary backups are useful for full restores but useless for understanding what changed.</li>
|
||||
<li><strong>Version history with diffs.</strong> Every backup should be a point in time you can return to, and you should be able to compare any two versions side by side.</li>
|
||||
<li><strong>Failure visibility.</strong> If a backup fails, or if a config changes unexpectedly outside of a maintenance window, someone should be alerted. Silent failure is the main problem with DIY backup scripts.</li>
|
||||
<li><strong>Restore capability.</strong> Viewing old configs is useful. Pushing a previous config back to a device is the actual recovery action — and that should be automatable too.</li>
|
||||
<li><strong>Fleet scale.</strong> The system should work the same way whether you have ten devices or a thousand. No per-device setup required.</li>
|
||||
</ul>
|
||||
|
||||
<h2>How The Other Dude Automates Backups</h2>
|
||||
|
||||
<p>The Other Dude handles mikrotik configuration management through a Go-based poller that connects to each device using the RouterOS binary API over TLS (port 8729). There are no per-device backup scripts, no FTP server to maintain, and no Scheduler entries to configure on each router.</p>
|
||||
|
||||
<p>The backup process works as follows:</p>
|
||||
|
||||
<ul>
|
||||
<li><strong>Scheduled collection.</strong> The backup scheduler service runs within the backend and captures a full <code>/export</code> from each device on a configurable interval. The same device credentials used for monitoring and management are used for backup collection — no additional credential setup required.</li>
|
||||
<li><strong>Version-controlled storage.</strong> Config exports are stored in PostgreSQL with complete version history. Every backup is a timestamped snapshot. Nothing is overwritten.</li>
|
||||
<li><strong>Change detection.</strong> The poller can detect configuration changes via NATS events in addition to scheduled polling, so a change pushed through WinBox or the CLI shows up in the history within minutes rather than waiting for the next scheduled run.</li>
|
||||
<li><strong>Diff viewer.</strong> The web UI shows a timeline of config changes per device. Select any two versions and get a side-by-side diff — additions in green, removals in red, unchanged lines in grey. This works the same way whether you're comparing yesterday to today or last year to last month.</li>
|
||||
<li><strong>One-click restore.</strong> Select a previous backup from the history and push it back to the device using the config editor's two-phase apply mechanism. The two-phase process applies the config and waits for confirmation before committing, which means a restore that breaks connectivity will roll back automatically.</li>
|
||||
<li><strong>Batch operations.</strong> You can pull the current config from multiple devices and compare them to identify inconsistencies — useful when you want to verify that a template change was applied uniformly across a group of devices.</li>
|
||||
</ul>
|
||||
|
||||
<p>Because the backup system is built on top of the same API connection the poller uses for everything else, there's no separate backup infrastructure to maintain. A device that's reachable for monitoring is reachable for backups.</p>
|
||||
|
||||
<h2>Related Guides</h2>
|
||||
|
||||
<div class="related-guides">
|
||||
<h2>More on MikroTik Configuration Management</h2>
|
||||
<ul>
|
||||
<li><a href="mikrotik-configuration-drift.html">How to detect configuration drift in MikroTik routers</a> — identify when devices have diverged from a known-good baseline</li>
|
||||
<li><a href="manage-multiple-mikrotik-routers.html">How to manage multiple MikroTik routers</a> — fleet management strategies for MSPs and network teams</li>
|
||||
<li><a href="mikrotik-router-monitoring.html">How to monitor MikroTik routers at scale</a> — metrics collection, alerting, and health dashboards</li>
|
||||
<li><a href="mikrotik-centralized-management.html">MikroTik centralized management</a> — multi-site visibility, bulk operations, and unified access</li>
|
||||
<li><a href="https://github.com/staack/the-other-dude" rel="noopener">The Other Dude on GitHub</a> — source code, issue tracker, and release notes</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
</article>
|
||||
</main>
|
||||
|
||||
<footer class="site-footer">
|
||||
<div class="footer-inner container">
|
||||
<div class="footer-brand">
|
||||
<span class="footer-logo">
|
||||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 64 64" width="24" height="24" aria-hidden="true" style="vertical-align: middle; margin-right: 8px;">
|
||||
<rect x="2" y="2" width="60" height="60" rx="8" fill="none" stroke="#8B1A1A" stroke-width="2"/>
|
||||
<rect x="6" y="6" width="52" height="52" rx="5" fill="none" stroke="#F5E6C8" stroke-width="1.5"/>
|
||||
<rect x="8" y="8" width="48" height="48" rx="4" fill="#8B1A1A" opacity="0.15"/>
|
||||
<path d="M32 18 L46 32 L32 46 L18 32 Z" fill="#8B1A1A"/>
|
||||
<path d="M32 19 L38 32 L32 45 L26 32 Z" fill="#2A9D8F"/>
|
||||
<path d="M19 32 L32 26 L45 32 L32 38 Z" fill="#F5E6C8"/>
|
||||
<circle cx="32" cy="32" r="5" fill="#8B1A1A"/>
|
||||
<circle cx="32" cy="32" r="2.5" fill="#2A9D8F"/>
|
||||
</svg>
|
||||
The Other Dude
|
||||
</span>
|
||||
<span class="footer-copy">© 2026 The Other Dude. All rights reserved.</span>
|
||||
</div>
|
||||
<nav class="footer-links">
|
||||
<a href="../index.html">Home</a>
|
||||
<a href="../docs.html">Docs</a>
|
||||
<a href="../blog/">Blog</a>
|
||||
<a href="https://github.com/staack/the-other-dude" rel="noopener">GitHub</a>
|
||||
<a href="mailto:license@theotherdude.net">Licensing</a>
|
||||
</nav>
|
||||
</div>
|
||||
</footer>
|
||||
|
||||
<!-- Cloudflare Web Analytics --><script defer src='https://static.cloudflareinsights.com/beacon.min.js' data-cf-beacon='{"token": "d5f1e31cb9744c998a8f7d1303c6efef"}'></script><!-- End Cloudflare Web Analytics -->
|
||||
</body>
|
||||
</html>
|
||||
304
docs/website/docs/mikrotik-router-monitoring.html
Normal file
304
docs/website/docs/mikrotik-router-monitoring.html
Normal file
@@ -0,0 +1,304 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
|
||||
<title>MikroTik Router Monitoring at Scale</title>
|
||||
<meta name="description" content="Monitor MikroTik routers with real-time metrics, alerts, and fleet-wide visibility. CPU, memory, traffic, wireless, and device health monitoring.">
|
||||
<meta name="keywords" content="mikrotik router monitoring, mikrotik monitoring software, RouterOS metrics, MikroTik fleet health, MikroTik SNMP alternative">
|
||||
<meta name="robots" content="index, follow">
|
||||
<meta name="theme-color" content="#FAFBFC">
|
||||
<link rel="canonical" href="https://theotherdude.net/docs/mikrotik-router-monitoring.html">
|
||||
<link rel="icon" href="data:image/svg+xml,<svg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 64 64'><rect x='2' y='2' width='60' height='60' rx='8' fill='none' stroke='%238B1A1A' stroke-width='2'/><rect x='6' y='6' width='52' height='52' rx='5' fill='none' stroke='%23F5E6C8' stroke-width='1.5'/><rect x='8' y='8' width='48' height='48' rx='4' fill='%238B1A1A' opacity='0.15'/><path d='M32 8 L56 32 L32 56 L8 32 Z' fill='none' stroke='%238B1A1A' stroke-width='2'/><path d='M32 13 L51 32 L32 51 L13 32 Z' fill='none' stroke='%23F5E6C8' stroke-width='1.5'/><path d='M32 18 L46 32 L32 46 L18 32 Z' fill='%238B1A1A'/><path d='M32 19 L38 32 L32 45 L26 32 Z' fill='%232A9D8F'/><path d='M19 32 L32 26 L45 32 L32 38 Z' fill='%23F5E6C8'/><circle cx='32' cy='32' r='5' fill='%238B1A1A'/><circle cx='32' cy='32' r='2.5' fill='%232A9D8F'/><path d='M10 10 L16 10 L10 16 Z' fill='%232A9D8F' opacity='0.7'/><path d='M54 10 L54 16 L48 10 Z' fill='%232A9D8F' opacity='0.7'/><path d='M10 54 L16 54 L10 48 Z' fill='%232A9D8F' opacity='0.7'/><path d='M54 54 L48 54 L54 48 Z' fill='%232A9D8F' opacity='0.7'/></svg>">
|
||||
|
||||
<!-- Open Graph -->
|
||||
<meta property="og:type" content="article">
|
||||
<meta property="og:title" content="MikroTik Router Monitoring at Scale — The Other Dude">
|
||||
<meta property="og:description" content="Monitor MikroTik routers with real-time metrics, alerts, and fleet-wide visibility. CPU, memory, traffic, wireless, and device health monitoring.">
|
||||
<meta property="og:url" content="https://theotherdude.net/docs/mikrotik-router-monitoring.html">
|
||||
<meta property="og:site_name" content="The Other Dude">
|
||||
<meta property="og:image" content="https://theotherdude.net/assets/og-image.png">
|
||||
<meta property="og:locale" content="en_US">
|
||||
|
||||
<!-- Twitter Card -->
|
||||
<meta name="twitter:card" content="summary_large_image">
|
||||
<meta name="twitter:title" content="MikroTik Router Monitoring at Scale — The Other Dude">
|
||||
<meta name="twitter:description" content="Monitor MikroTik routers with real-time metrics, alerts, and fleet-wide visibility. CPU, memory, traffic, wireless, and device health monitoring.">
|
||||
<meta name="twitter:image" content="https://theotherdude.net/assets/og-image.png">
|
||||
|
||||
<!-- Structured Data -->
|
||||
<script type="application/ld+json">
|
||||
{
|
||||
"@context": "https://schema.org",
|
||||
"@type": "TechArticle",
|
||||
"headline": "How to Monitor MikroTik Routers at Scale",
|
||||
"description": "Monitor MikroTik routers with real-time metrics, alerts, and fleet-wide visibility. CPU, memory, traffic, wireless, and device health monitoring.",
|
||||
"datePublished": "2026-03-15",
|
||||
"author": {
|
||||
"@type": "Organization",
|
||||
"name": "The Other Dude"
|
||||
},
|
||||
"publisher": {
|
||||
"@type": "Organization",
|
||||
"name": "The Other Dude",
|
||||
"url": "https://theotherdude.net"
|
||||
},
|
||||
"mainEntityOfPage": "https://theotherdude.net/docs/mikrotik-router-monitoring.html"
|
||||
}
|
||||
</script>
|
||||
|
||||
<!-- Fonts -->
|
||||
<link rel="preconnect" href="https://fonts.googleapis.com">
|
||||
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
|
||||
<link href="https://fonts.googleapis.com/css2?family=DM+Sans:wght@400;500;700&family=Fira+Code:wght@400;500&family=Outfit:wght@400;500;600;700;800&display=swap" rel="stylesheet">
|
||||
|
||||
<link rel="stylesheet" href="../style.css">
|
||||
<style>
|
||||
.doc-page {
|
||||
max-width: 760px;
|
||||
margin: 0 auto;
|
||||
padding: 80px 24px 120px;
|
||||
}
|
||||
.doc-page-meta {
|
||||
color: var(--text-muted);
|
||||
font-size: 14px;
|
||||
margin-bottom: 8px;
|
||||
}
|
||||
.doc-page h1 {
|
||||
font-family: "Outfit", sans-serif;
|
||||
font-weight: 700;
|
||||
font-size: 2.5rem;
|
||||
line-height: 1.2;
|
||||
color: var(--text-primary);
|
||||
margin-bottom: 32px;
|
||||
}
|
||||
.doc-page h2 {
|
||||
font-family: "Outfit", sans-serif;
|
||||
font-weight: 600;
|
||||
font-size: 1.4rem;
|
||||
color: var(--text-primary);
|
||||
margin-top: 56px;
|
||||
margin-bottom: 16px;
|
||||
}
|
||||
.doc-page p {
|
||||
color: var(--text-secondary);
|
||||
font-size: 1.05rem;
|
||||
line-height: 1.75;
|
||||
margin-bottom: 20px;
|
||||
}
|
||||
.doc-page p strong {
|
||||
color: var(--text-primary);
|
||||
}
|
||||
.doc-page a {
|
||||
color: var(--accent);
|
||||
text-decoration: underline;
|
||||
text-underline-offset: 3px;
|
||||
}
|
||||
.doc-page a:hover {
|
||||
color: var(--text-primary);
|
||||
}
|
||||
.doc-page .back-link {
|
||||
display: inline-block;
|
||||
margin-bottom: 32px;
|
||||
font-size: 14px;
|
||||
text-decoration: none;
|
||||
color: var(--text-muted);
|
||||
}
|
||||
.doc-page .back-link:hover {
|
||||
color: var(--accent);
|
||||
}
|
||||
.doc-page ul {
|
||||
margin: 0 0 20px 0;
|
||||
padding-left: 24px;
|
||||
}
|
||||
.doc-page ul li {
|
||||
color: var(--text-secondary);
|
||||
font-size: 1.05rem;
|
||||
line-height: 1.75;
|
||||
margin-bottom: 8px;
|
||||
}
|
||||
.doc-page ul li strong {
|
||||
color: var(--text-primary);
|
||||
}
|
||||
.doc-page code {
|
||||
font-family: "Fira Code", monospace;
|
||||
font-size: 0.9em;
|
||||
background: rgba(42, 157, 143, 0.08);
|
||||
color: var(--text-primary);
|
||||
padding: 2px 6px;
|
||||
border-radius: 3px;
|
||||
}
|
||||
.doc-related {
|
||||
margin-top: 64px;
|
||||
padding-top: 32px;
|
||||
border-top: 1px solid var(--border);
|
||||
}
|
||||
.doc-related h2 {
|
||||
margin-top: 0;
|
||||
font-size: 1.1rem;
|
||||
}
|
||||
.doc-related ul {
|
||||
list-style: none;
|
||||
padding-left: 0;
|
||||
}
|
||||
.doc-related ul li {
|
||||
margin-bottom: 10px;
|
||||
}
|
||||
.doc-related ul li a {
|
||||
font-size: 1rem;
|
||||
}
|
||||
@media (max-width: 480px) {
|
||||
.doc-page h1 { font-size: 1.8rem; }
|
||||
.doc-page { padding: 60px 20px 80px; }
|
||||
}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
|
||||
<nav class="site-nav site-nav--light" aria-label="Main navigation">
|
||||
<div class="nav-inner container">
|
||||
<a href="../index.html" class="nav-logo">
|
||||
<svg class="nav-logo-mark" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 64 64" width="32" height="32" aria-hidden="true">
|
||||
<rect x="2" y="2" width="60" height="60" rx="8" fill="none" stroke="#8B1A1A" stroke-width="2"/>
|
||||
<rect x="6" y="6" width="52" height="52" rx="5" fill="none" stroke="#F5E6C8" stroke-width="1.5"/>
|
||||
<rect x="8" y="8" width="48" height="48" rx="4" fill="#8B1A1A" opacity="0.15"/>
|
||||
<path d="M32 8 L56 32 L32 56 L8 32 Z" fill="none" stroke="#8B1A1A" stroke-width="2"/>
|
||||
<path d="M32 13 L51 32 L32 51 L13 32 Z" fill="none" stroke="#F5E6C8" stroke-width="1.5"/>
|
||||
<path d="M32 18 L46 32 L32 46 L18 32 Z" fill="#8B1A1A"/>
|
||||
<path d="M32 19 L38 32 L32 45 L26 32 Z" fill="#2A9D8F"/>
|
||||
<path d="M19 32 L32 26 L45 32 L32 38 Z" fill="#F5E6C8"/>
|
||||
<circle cx="32" cy="32" r="5" fill="#8B1A1A"/>
|
||||
<circle cx="32" cy="32" r="2.5" fill="#2A9D8F"/>
|
||||
<path d="M10 10 L16 10 L10 16 Z" fill="#2A9D8F" opacity="0.7"/>
|
||||
<path d="M54 10 L54 16 L48 10 Z" fill="#2A9D8F" opacity="0.7"/>
|
||||
<path d="M10 54 L16 54 L10 48 Z" fill="#2A9D8F" opacity="0.7"/>
|
||||
<path d="M54 54 L48 54 L54 48 Z" fill="#2A9D8F" opacity="0.7"/>
|
||||
</svg>
|
||||
<span>The Other Dude</span>
|
||||
</a>
|
||||
<div class="nav-links">
|
||||
<a href="../index.html" class="nav-link">Home</a>
|
||||
<a href="../index.html#what-it-does" class="nav-link">Features</a>
|
||||
<a href="../docs.html" class="nav-link">Docs</a>
|
||||
<a href="../blog/" class="nav-link">Blog</a>
|
||||
<a href="https://github.com/staack/the-other-dude" class="nav-link" rel="noopener">GitHub</a>
|
||||
</div>
|
||||
</div>
|
||||
</nav>
|
||||
|
||||
<main>
|
||||
<article class="doc-page">
|
||||
<a href="../docs.html" class="back-link">← Back to Docs</a>
|
||||
<div class="doc-page-meta">MikroTik Monitoring — The Other Dude</div>
|
||||
|
||||
<h1>How to Monitor MikroTik Routers at Scale</h1>
|
||||
|
||||
<p>If you manage more than a handful of MikroTik routers, "monitoring" stops meaning "is this device pingable" and starts meaning something harder. You need to know which of your 200 routers is spiking CPU before a user files a ticket. You need to find the access point with degraded wireless signal before the site calls in. You need bandwidth utilization trends to make capacity decisions, not just point-in-time readings. And you need to know the moment a device goes offline at 2am — not when someone shows up for work.</p>
|
||||
|
||||
<p>That's what real <strong>mikrotik router monitoring</strong> looks like in production.</p>
|
||||
|
||||
<h2>The Problem with MikroTik Monitoring at Scale</h2>
|
||||
|
||||
<p>Individual devices are easy. RouterOS has good per-device tooling. The problem is the fleet. When you're managing dozens or hundreds of routers across multiple sites, you have no single place to answer questions like:</p>
|
||||
|
||||
<ul>
|
||||
<li>Which devices are above 80% CPU right now?</li>
|
||||
<li>What's the 30-day bandwidth trend on this site's uplink?</li>
|
||||
<li>How many clients does each AP have, and which ones have poor signal?</li>
|
||||
<li>Which devices went offline in the last 24 hours, and for how long?</li>
|
||||
</ul>
|
||||
|
||||
<p>These are fleet-level questions. They require a centralized data store, consistent polling, and a UI that surfaces the signal instead of burying you in noise.</p>
|
||||
|
||||
<h2>Native RouterOS Monitoring Options</h2>
|
||||
|
||||
<p>RouterOS gives you several monitoring tools. Each has real limitations when applied at fleet scale.</p>
|
||||
|
||||
<ul>
|
||||
<li><strong>SNMP</strong> — Broadly supported and integrates with most NMS platforms. But it's polling-based with no built-in aggregation, requires navigating complex OID trees, and adds MIB management overhead to every device you onboard. At 200 devices, SNMP configuration becomes its own maintenance burden.</li>
|
||||
<li><strong>The Dude</strong> — MikroTik's own free monitoring tool. Useful for basic device discovery and health checks on smaller networks. Struggles past a few hundred devices and isn't designed to aggregate fleet-wide metrics or support multi-tenant environments.</li>
|
||||
<li><strong>Torch / Traffic Monitor</strong> — Excellent for real-time per-device traffic analysis. Not designed for fleet-wide aggregation or historical trending. You can't ask "show me all devices above 70% interface utilization."</li>
|
||||
<li><strong>Log forwarding (syslog)</strong> — Valuable for event-based alerting and troubleshooting. Logs are events, not metrics. You can't graph CPU trends from syslog entries.</li>
|
||||
<li><strong>External NMS (PRTG, Zabbix, LibreNMS)</strong> — These are powerful, general-purpose platforms. But they're generic. MikroTik-specific metrics like wireless CCQ, client counts, or RouterOS resource tables require custom sensor templates, SNMP MIB imports, or community scripts. Setup time is measured in days, not hours.</li>
|
||||
</ul>
|
||||
|
||||
<h2>What MikroTik Monitoring Software Should Include</h2>
|
||||
|
||||
<p>A purpose-built <strong>mikrotik monitoring software</strong> solution should handle the full picture — not just availability pings.</p>
|
||||
|
||||
<ul>
|
||||
<li><strong>Device health metrics</strong> — CPU load, memory usage, disk usage, and board temperature per device, polled consistently and stored for trending.</li>
|
||||
<li><strong>Interface traffic rates</strong> — Calculated in bits per second from cumulative counter deltas, not raw counters. You want throughput, not a number that means nothing without the previous reading.</li>
|
||||
<li><strong>Wireless metrics</strong> — Client count, signal strength in dBm, and CCQ per wireless interface. These are the first indicators of AP degradation.</li>
|
||||
<li><strong>Online/offline status with alerting</strong> — Detection of device unreachability with configurable thresholds and notification delivery.</li>
|
||||
<li><strong>Fleet-wide dashboards</strong> — Aggregate health views showing the entire fleet at once, with the ability to drill into individual devices.</li>
|
||||
<li><strong>Historical data for trend analysis</strong> — Metrics stored in a time-series database so you can answer "what was this router doing at 3am last Tuesday?"</li>
|
||||
<li><strong>Configurable alert rules</strong> — Threshold-plus-duration logic (e.g., CPU > 90% for 5 consecutive polls triggers a warning) to avoid noise from transient spikes.</li>
|
||||
<li><strong>Notification channels</strong> — Email, Slack, webhook. Alerts that only show up in a dashboard are alerts that get missed.</li>
|
||||
</ul>
|
||||
|
||||
<h2>How The Other Dude Monitors MikroTik Routers</h2>
|
||||
|
||||
<p>The Other Dude was built specifically for MikroTik fleet management. The monitoring stack is not bolted on — it's the core of what the platform does.</p>
|
||||
|
||||
<p><strong>Collection via the RouterOS binary API.</strong> The Go-based poller connects to each device over the RouterOS binary API on TLS port 8729. This is not SNMP. There are no OIDs, no MIB files, no polling configuration per metric type. The API returns structured data directly from RouterOS resources, which is faster, more reliable, and requires no per-device SNMP configuration.</p>
|
||||
|
||||
<p><strong>Three metric families.</strong> Each poll cycle collects health metrics (CPU, memory, disk, temperature), interface metrics (per-interface traffic rates calculated from cumulative counter deltas), and wireless metrics (client count, signal strength in dBm, CCQ per wireless interface). All three are stored in TimescaleDB hypertables with automatic time-based bucketing for efficient range queries.</p>
|
||||
|
||||
<p><strong>Real-time browser updates.</strong> Metrics flow from the poller into NATS JetStream, then out to connected browsers via Server-Sent Events. The dashboard reflects current device state without polling the database on every page load.</p>
|
||||
|
||||
<p><strong>Fleet health dashboard.</strong> The main view shows aggregate fleet health — how many devices are online, which have active alerts, uptime sparklines per device, and bandwidth charts for the busiest links. The "APs Needing Attention" card surfaces wireless access points with degraded signal or low CCQ so you can find problems before users do.</p>
|
||||
|
||||
<p><strong>Per-device detail.</strong> Each device has its own page with health graphs over configurable time windows, per-interface traffic charts, and wireless metrics broken down by interface. You can see exactly what a device was doing at any point in its history.</p>
|
||||
|
||||
<p><strong>Alert rules with duration thresholds.</strong> Alert rules combine a metric, a threshold, and a <code>duration_polls</code> count. A rule for "CPU > 90%" with <code>duration_polls = 5</code> only fires after five consecutive polling intervals above the threshold. This eliminates noise from transient spikes. New tenants receive a default set of alert rules covering CPU, memory, disk, offline detection, wireless signal, and CCQ — sensible baselines that you can tune without starting from zero.</p>
|
||||
|
||||
<p><strong>Notification channels.</strong> Alerts are delivered via email, webhook, or Slack. Maintenance windows let you suppress alerts during planned work without disabling the rules themselves.</p>
|
||||
|
||||
<p><strong>Network topology map.</strong> An interactive topology view shows device interconnections across your fleet, giving you a structural context for interpreting monitoring data.</p>
|
||||
|
||||
<h2>Related Guides</h2>
|
||||
|
||||
<div class="doc-related">
|
||||
<ul>
|
||||
<li><a href="mikrotik-configuration-drift.html">Detect configuration drift across your MikroTik fleet</a></li>
|
||||
<li><a href="mikrotik-router-backup-automation.html">Automate router backups for every device</a></li>
|
||||
<li><a href="manage-multiple-mikrotik-routers.html">Manage multiple MikroTik routers from one interface</a></li>
|
||||
<li><a href="mikrotik-centralized-management.html">MikroTik centralized management: architecture and setup</a></li>
|
||||
<li><a href="https://github.com/staack/the-other-dude" rel="noopener">The Other Dude on GitHub</a></li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
</article>
|
||||
</main>
|
||||
|
||||
<footer class="site-footer">
|
||||
<div class="footer-inner container">
|
||||
<div class="footer-brand">
|
||||
<span class="footer-logo">
|
||||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 64 64" width="24" height="24" aria-hidden="true" style="vertical-align: middle; margin-right: 8px;">
|
||||
<rect x="2" y="2" width="60" height="60" rx="8" fill="none" stroke="#8B1A1A" stroke-width="2"/>
|
||||
<rect x="6" y="6" width="52" height="52" rx="5" fill="none" stroke="#F5E6C8" stroke-width="1.5"/>
|
||||
<rect x="8" y="8" width="48" height="48" rx="4" fill="#8B1A1A" opacity="0.15"/>
|
||||
<path d="M32 18 L46 32 L32 46 L18 32 Z" fill="#8B1A1A"/>
|
||||
<path d="M32 19 L38 32 L32 45 L26 32 Z" fill="#2A9D8F"/>
|
||||
<path d="M19 32 L32 26 L45 32 L32 38 Z" fill="#F5E6C8"/>
|
||||
<circle cx="32" cy="32" r="5" fill="#8B1A1A"/>
|
||||
<circle cx="32" cy="32" r="2.5" fill="#2A9D8F"/>
|
||||
</svg>
|
||||
The Other Dude
|
||||
</span>
|
||||
<span class="footer-copy">© 2026 The Other Dude. All rights reserved.</span>
|
||||
</div>
|
||||
<nav class="footer-links">
|
||||
<a href="../docs.html">Docs</a>
|
||||
<a href="../blog/">Blog</a>
|
||||
<a href="https://github.com/staack/the-other-dude" rel="noopener">GitHub</a>
|
||||
<a href="mailto:license@theotherdude.net">Licensing</a>
|
||||
</nav>
|
||||
</div>
|
||||
</footer>
|
||||
|
||||
<!-- Cloudflare Web Analytics --><script defer src='https://static.cloudflareinsights.com/beacon.min.js' data-cf-beacon='{"token": "d5f1e31cb9744c998a8f7d1303c6efef"}'></script><!-- End Cloudflare Web Analytics -->
|
||||
</body>
|
||||
</html>
|
||||
Reference in New Issue
Block a user