Recipe: knowing before your customer calls

Goal: when something fails, you hear it from your own equipment instead of from the customer. The router can do part of that, and it matters to know which part.

What you need

A management VLAN, or at least a fixed management address, so monitoring is not allowed from every network.
Somewhere outside the router that watches. A small VM or a Raspberry Pi will do; the point is that it does not fail together with the device it is watching.
An SMTP account for outgoing mail, preferably not over the line you are watching.

Step 1: SNMP, so someone else can read the router

In Services & tools:

Set SNMP to SNMPv3. It costs you two passwords and gives you authentication (SHA1) and encryption (AES). SNMPv2c sends the community across your network in plain text; use that only on a management network that is genuinely separated.
Fill in a community or v3 user, monitoring by default.
Under Only from, enter your monitoring server's address, 10.0.0.5/32 for example. Leave it empty and the tool uses the management network. If there is no management network either, the tool warns you that SNMP is reachable from any address, which is exactly what you do not want.
Contact and Location are optional, but they end up in your monitoring system and save you a search later.

What ends up in the script: the default community is disabled, your user gets read access only, and SNMP is switched on. The tool has no write access over SNMP, and that is deliberate: reading is monitoring, writing is management.

Step 2: graphs on the router itself

In the same section, turn on Graphing. The tool then writes /tool graphing for interfaces, system resources and queues, reachable from your management address. You find them at http://<router address>/graphs.

What to know: the graphs are deliberately not stored on disk. They live in memory and are gone after a reboot. That is good for the flash and bad for your memory of last week. Use them to see what is happening now, not as an archive.

Step 3: being able to send mail

Turn on Send e-mail.
Fill in the SMTP server, port (587), TLS (STARTTLS), user, password and sender.
Fill in a recipient for backups if you want the weekly backup mailed as well.

This one setting enables two things: the weekly backup by mail, and a netwatch script that calls /tool e-mail send. Mind the trap: mail over the line that has just gone down does not arrive. Mail works for watching something inside your network, not for watching your own internet connection.

Step 4: netwatch for the things that matter

In High availability (VRRP, Netwatch), below the VRRP table. The section is off by default and has no wizard step. Per row you fill in:

Host: Pick something that actually tells you anything: the NAS, the access point at the furthest site, the far end of a tunnel. An address that drops out regularly for innocent reasons only produces noise.
Interval: 30s by default. Shorter reacts faster, and makes it more likely that a single lost packet fires an action.
Script on down and Script on up: One line of RouterOS script, /log warning "NAS unreachable" for instance. If you need more, put the content in a custom script under Services & tools and call it here with /system script run name.

What the tool writes: one /tool netwatch entry per host, with timeout=1s and type=icmp. Those two are fixed. RouterOS 7 also has checks on a TCP port or an HTTP response, but you add those on the device yourself.

Step 5: logging that survives a reboot

In System: set Logging to remote and fill in your syslog server and port (514). The log on the router lives in memory; after a reboot it is gone, and a reboot is exactly when you want to know what came before it.
Turn on Log firewall drops if you want to see what knocks on your input chain. Expect a lot of lines.
Consider Watchdog: give it an address at your provider and the router reboots itself when that stays unreachable too long. One setting instead of a script.

If you want to see what passes through the router rather than only whether it is alive, turn on Traffic flow export with your collector's address, port 2055 and NetFlow v9 or IPFIX.

Testing

Run an snmpwalk from your monitoring server. If that fails, check the address under Only from and whether your server really comes from there.
Run an snmpwalk from some other address. That should fail.
Send a test mail from the router: /tool e-mail send to="you@example.com" subject="test" body="test", then check /log print to see whether it went out.
Unplug the device you watch with netwatch. Within your interval the down script should run. Check with /tool netwatch print and in the log.
Open the graphs at /graphs and see whether lines are moving.
Check on your syslog server that the router's lines arrive.

Where a proper monitoring system starts

Everything above runs on the router, and that is where the limit sits. Four things a router cannot do by definition:

A device cannot report its own death. A router that is off is exactly as silent as a router with nothing wrong. Only something outside it sees the difference.
There is no history. You see the current state and whatever you logged yourself. No graph of last month, no availability figure for a report.
There is no alerting. No escalation, no on-call rota, no confirmation that somebody is looking. A mail that lands in a folder is not an alert.
Netwatch only checks whether something answers. A line that answers but drops 40 percent of packets is fine as far as netwatch is concerned.

As soon as you manage more than a couple of devices, the watching belongs outside the router. A monitoring system such as LibreNMS, Zabbix or Prometheus reads your router over SNMP, keeps the history, draws the graphs and sends the alert. The configurator prepares the router's side of that, and that is all it does: it installs no monitoring system, writes no SNMP trap destination and does not set up The Dude.

The division that works in practice: the monitoring system watches your network from the outside, and netwatch does the one small trick inside the router that can only be done there.

What to watch out for

Do not leave SNMP reachable from every address. It reads out your whole device: interfaces, addresses, names, neighbours.
A script that changes your configuration on a failure does so at four in the morning on a false alarm too. Log lines are safer than switching actions.
Do not use netwatch for failover between two internet lines. That belongs to route distances and a gateway check under Multiple uplinks, which is faster and has no script that can get stuck.
Device-mode can block features. If your down script uses fetch or e-mail, it silently does nothing. Check with /system/device-mode/print.

Further reading: Netwatch and monitoring, Services and tools and System and time.