Syslog and SNMP traps

Routers, switches, firewalls, access points, UPSs and servers can tell the collector what happens on them: a port went down, someone changed the configuration, a sign-in failed, a fan stopped. Monitaria receives these syslog messages and SNMP traps, ties each one to its device and keeps them on the collector, searchable in the Logs tab. Rules pick out the messages that matter and turn them into problems that alert like any other. Nothing is received until an admin turns it on.

1. Turn on the receivers

1. Open Settings › Syslog and traps.
2. Under Receivers, tick Receive syslog over UDP, Receive syslog over TCP or Receive SNMP traps and informs (v1 and v2c). Keep the standard ports, 514 for syslog and 162 for traps, unless something else uses them.
3. On networks you don't fully trust, fill in Accept messages only from these networks and Accept traps only with these community strings. Then choose Save.
4. Look at Receiver status. Each receiver says it is listening, or what is wrong and what to do: for example, another program holds the port, or a port below 1024 needs extra rights (the Monitaria appliance has them).
5. On the Monitaria appliance, open the ports in its firewall too. The Device setup panel shows the command, for example sudo ufw allow 514/udp.

2. Point your devices at the collector

The Device setup panel at the bottom of the page has examples for Cisco IOS and IOS-XE, FortiGate, Aruba and HP switches (ArubaOS-Switch), Ubiquiti UniFi, Windows servers (through a log forwarder) and Linux (rsyslog), with this collector's address and ports filled in. Severity informational sends a lot; warnings is a good start for busy firewalls. On a Cisco switch it looks like this:

logging host 192.0.2.10
logging trap informational
service timestamps log datetime msec localtime show-timezone
snmp-server enable traps
snmp-server host 192.0.2.10 version 2c <community>

Each message is matched to its device by the sender's address: an address a sensor checks, an address in the device's name, or an interface address the device reports over SNMP. Messages from other addresses are kept and listed under Unknown senders; in Logs, only people who see every device can read them. Pick the device under Assign to… and choose Assign (its earlier messages move with it), or choose Ignore to drop that sender's messages. A syslog relay works too: its messages are matched by the host name inside them while the host-name option under Receivers stays ticked.

3. Turn the messages that matter into problems

• Under Rules, add a suggested rule: Interface down, Configuration changed, Authentication failures, Power supply or fan failure, High temperature, Routing neighbour down or Device restarted. Each covers the usual wording from Cisco, Juniper, FortiGate, Aruba/HP, Windows and Linux, and you can adjust it.
• Or choose + New rule and fill in what must match: Applies to, Device, Sites, Severity, Facilities, Program or trap name, Message contains (text or a regular expression) and But not when it contains. Every field you fill in must match. A regular expression that could run slowly is refused, with a suggestion.
• Or open any message in the Logs tab and choose Make a rule from this message.
• Under When it matches, choose Raise a down problem on the device or Raise a warning on the device, and set Keep the problem for (minutes after the last match).
• Choose Save rules. Test against the last 24 hours shows how many recent messages a rule would have matched, and Test a message against the rules checks a pasted line without saving anything.

A rule that raises a problem adds a sensor named after it, such as Log: Interface down, to each device it fires on. A match turns that sensor Down or Warning, as the rule says, within seconds, and it goes back to Up once the hold time passes without another match. The problem shows in Problems and on the Overview, goes out through your alert rules, can be acknowledged and stays quiet during maintenance windows. To leave one device out, pause its Log sensor or narrow the rule; a deleted Log sensor comes back the next time the rule fires.

Using the Logs tab

• Search for words or "quoted phrases", and filter by device, site, severity, syslog or traps, and period. The counts above the list, such as Warning or worse, filter to exactly those messages.
• Tick Live to add new messages every 3 seconds. Download CSV exports up to 50,000 messages with the current filters.
• Click a message for everything it carried, such as its facility, vendor fields and trap variables, then choose Only this device to see the rest of that device's messages.
• A device's dialog shows its Recent log messages from the last 7 days, with Open in Logs, and its timeline shows its errors and rule matches.
• Once the Configuration changed rule is saved, Config backup can back up a device about two minutes after it logs a configuration change. See the configuration backup guide.

Good to know

• Messages stay on the collector. Only a problem's short message, such as "2 matching messages in the last 15 minutes: …", goes out: in alerts and, if you link the hub, to the hub with IP addresses removed. Rule matches reach webhooks or tickets only if you turn those features on.
• Trap community strings are write-only: they are never shown again and never appear in a stored message, an event or a page.
• Anyone who can reach the ports can forge a sender address or a host name. That's why the allowed networks and the community list are worth filling in.
• By default, messages are kept for 30 days and at most 1,000,000 of them, oldest out first. Above 500 messages a second the rest are dropped and counted, so a flood can't slow monitoring down.
• Syslog over TLS and SNMPv3 traps aren't supported, and traps arrive over UDP only. SNMPv3 traps are counted, and Receiver status names the sender.
• If every receiver is off, Log sensors show No data and send no alerts.
• Messages are listed by when the collector received them, since device clocks are often wrong. Search reads every stored message, so on a busy network narrow the period first.