Syslog for home labs without an observability stack

What you get

MobiObs receives syslog (RFC 3164, RFC 5424, CEF and LEEF), NetFlow, IPFIX, sFlow and SNMP traps, stores them on the device, and shows them in the app and in any browser on your network. For a lab, that means:

• Logs from every device in one live, searchable list, filtered by host, app or severity.
• Flows showing which machine is using your internet connection, and where it is sending traffic.
• SNMP traps when a switch port goes down or a device restarts.
• A web view on port 8080, so a tablet or mobile device can sit on the shelf while you read the logs on your desktop.

The Free tier includes every collector, with one hour of retention and 50,000 rows per table, which suits watching what a change does. Pro adds configurable retention, export and SNMPv3 users; see pricing.

Plan the lab

1. Give the collector a stable address. Add a DHCP reservation for the device that runs MobiObs, so you configure each sender once. A USB-C Ethernet adapter avoids Wi-Fi power saving on a device that stays plugged in.
2. Keep it on the same network as the lab, or route to it. A guest SSID with client isolation blocks it. If the lab lives on its own VLAN, allow UDP from that VLAN to the collector ports.
3. Use the MobiObs ports. Android does not let apps listen on ports below 1024, and MobiObs uses the same ports on every platform, so senders use 5514 (syslog, UDP or TCP), 2055 (NetFlow and IPFIX), 6343 (sFlow) and 1162 (traps). The port 514 guide explains why and what to do with senders that cannot change the port.
4. On Android, exempt MobiObs from battery optimization if it will collect for hours. The collectors run as a foreground service, so collection continues with the screen off.

Point each device at it

The collector is 10.20.4.9 below; use the address on the MobiObs Network screen, which also shows ready-to-paste sender lines.

For a Linux host, one file is enough. This is the same configuration as in the Linux guide:

/etc/rsyslog.d/90-mobiobs.conf (rsyslog 8.x)

*.* action(type="omfwd" target="10.20.4.9" port="5514" protocol="tcp"
           template="RSYSLOG_SyslogProtocol23Format")

Check it with rsyslogd -N1 and restart rsyslog. Many lab distributions already run rsyslog; a host with only the systemd journal needs rsyslog installed to forward in syslog format.

Things worth watching

• Sign-in attempts. Failed SSH logins on a Linux host, failed DSM sign-ins on the NAS, and firewall blocks on the WAN show who is knocking, and whether a port forward is more exposed than you thought.
• DHCP and DNS. Firewall DHCP logs show each new device that joins, which is a quick way to find the address of a new board or appliance.
• Configuration changes. Most network operating systems log a message when the configuration changes, which is useful when you are learning: make a change, then watch what the device reports.
• Who is using the internet connection. Export flows from the router’s LAN interface and open Flows during a slow evening; the top talkers guide explains how to read it.
• Port and power events. Traps from a managed switch show cables unplugged, ports flapping and devices restarting.
• Practice for certifications. Configuring logging host, SNMP traps and NetFlow exporters on lab gear, and seeing the result immediately, is a practical way to learn them.

Verify it works

1. From any Linux or macOS machine, send a test message: logger -n 10.20.4.9 -P 5514 -d "home lab test". It should appear in Logs straight away.
2. Configure the real senders one at a time, and after each one check Sources, which lists every address that has reached the collector, with the kinds of data and the last-seen time.
3. Open Overview for the rate, severity split and top hosts across the lab, and the same dashboards in a browser at http://10.20.4.9:8080/, paired with the token shown in the app.

Troubleshooting

• The logger test does not arrive. Client isolation on Wi-Fi, a firewall rule between VLANs, or the wrong port. Check those before touching the senders.
• One device is missing from Sources. It is probably still sending to 514, or from an interface without a route to the collector.
• Flows arrive but the screen stays empty. NetFlow v9 and IPFIX wait for a template; lower the template refresh on the exporter.
• Collection stops overnight. On Android, check battery optimization; on an iPhone or iPad, MobiObs must stay in the foreground.
• The logs from yesterday are gone. The Free tier keeps one hour. That is by design for a live view; longer retention is part of Pro.

When a full stack is worth it

MobiObs is a live view and a short-term store, not a log archive. A permanent stack such as Grafana with Loki, an Elastic stack or Graylog is worth the effort when you need months of history, alerting when something happens while you are not looking, or dashboards that combine logs with metrics from many sources. Many home labs do both: a stack for the long view, and a collector you can pick up and point a device at when you are working on it. Because most senders accept several log hosts, adding MobiObs does not mean removing anything.