About MAAS logging

Errors or typos? Topics missing? Hard to read? Let us know.

This page describes basic MAAS logging operations. For more details, refer to these reference pages:

Logging updates in MAAS 3.5

In 3.5, the MAAS snap uses the pebble service manager instead of supervisord. This means that the systemd component was renamed to snap.maas.pebble.service. It contains Pebble logs, as well as intercepted stdout of the services running under Pebble. The region and rack logs are cached there, as well (i.e., regiond.log and rackd.log are no more (supervisord was redirecting the stdout of the respective services).

Here is a per-service breakdown how logging works in MAAS 3.5:

Pebble

Pebble logs to stdout, redirecting the services to stdout if run with --verbose (currently in use). It logs additional debug information when run with envvar PEBBLE_DEBUG=1 (currently in use).

Log entry format

2023-07-24T11:12:25.495Z [pebble] GET /v1/services?names=bind9 57.716µs
2023-07-24T11:12:26.392Z [SERVICE_NAME] SERVICE STDOUT

Commands to access the log

To access only the pebble logs:

journalctl -u snap.maas.pebble.service --case-sensitive -g "^[0-9TZ:.-]{24} \[pebble\]"

To access pebble and its services logs:

journalctl -u snap.maas.pebble.service

Regiond

Regiond logs to stdout, redirected to journalctl by Pebble.

Own log format

2023-07-25 07:23:28 maasserver.rpc.regionservice: [info] Message

Pebble-proxied log format

2023-07-25T07:23:28.730Z [regiond] 2023-07-25 07:23:28 maasserver.rpc.regionservice: [info] Message

Commands to access the log

journalctl -u snap.maas.pebble.service --case-sensitive -g "^[0-9TZ:.-]{24} \[regiond\]"

Rackd

Rackd logs to stdout, redirected to journalctl by Pebble.

Own log format

2023-06-23 13:54:46 provisioningserver.rpc.clusterservice: [info] Message

Pebble-proxied log format

2023-06-23T13:54:46.391Z [rackd] 2023-06-23 13:54:46 provisioningserver.rpc.clusterservice: [info] Message

Commands to access the log

journalctl -u snap.maas.pebble.service --case-sensitive -g "^[0-9TZ:.-]{24} \[rackd\]"

API Server

The API server logs to stdout, redirected to journalctl by Pebble.

Own log format

INFO:     Started server process [24428]

Pebble-proxied log format

2023-07-24T10:25:37.602Z [apiserver] INFO:     Started server process [24428]

Commands to access the log

journalctl -u snap.maas.pebble.service --case-sensitive -g "^[0-9TZ:.-]{24} \[apiserver\]"

HTTP (nginx)

HTTP logs to its own files (/var/snap/maas/common/log/http/(access|error).log), while stdout (redirected by Pebble) contains only critical errors that cannot be redirected to the error log.

Pebble-proxied log format

2023-06-23T13:54:46.391Z [http] nginx: [alert] could not open error log file
Own logs
less /var/snap/maas/common/log/http/access.log (or error.log)
stdout redirected by Pebble:
journalctl -u snap.maas.pebble.service --case-sensitive -g "^[0-9TZ:.-]{24} \[http\]"

Proxy (squid)

The squid proxy logs to its own files (/var/snap/maas/common/log/proxy/(access|cache|store).log), while stdout (redirected by Pebble) contains init messages and errors.

Pebble proxied log format:

2023-06-23T13:54:41.114Z [proxy] 2023/06/23 13:54:41| Starting Squid Cache version 5.2
Own logs
less /var/snap/maas/common/log/proxy/access.log (or other log)
stdout redirected by Pebble:
journalctl -u snap.maas.pebble.service --case-sensitive -g "^[0-9TZ:.-]{24} \[proxy\]"

NTP (chrony)

At first glance, chrony seems to have a separate directory for log files (/var/snap/maas/common/log/chrony), but no log files are typically present there. Instead, used stdout (redirected by Pebble), which contains init message and errors.

Pebble proxied log format:

2023-06-26T12:48:01.272Z [ntp] 2023-06-26T12:48:01Z chronyd version 4.2 starting

Own log format

2023-06-26T12:48:01Z chronyd version 4.2 starting
stdout redirected by Pebble:
journalctl -u snap.maas.pebble.service --case-sensitive -g "^[0-9TZ:.-]{24} \[ntp\]"

DNS (bind9)

DNS logs everything to stdout, ignoring any configuration parameters defined in the snap. As usual, stdout is redirected by Pebble.

Pebble proxied log format:

2023-06-23T13:54:43.268Z [bind9] 23-Jun-2023 13:54:43.264 BIND 9 is maintained by Internet Systems Consortium

Own log format

23-Jun-2023 13:54:43.264 BIND 9 is maintained by Internet Systems Consortium

Commands to access the log

journalctl -u snap.maas.pebble.service --case-sensitive -g "^[0-9TZ:.-]{24} \[bind9\]"

Syslog (rsyslog)

Syslog logs machines enlistment and boot syslogs to /var/snap/maas/common/log/rsyslog/%HOSTNAME%/, and logs various MAAS-tagged records to /var/snap/maas/common/log/maas.log. Otherwise, stdout (redirected by Pebble) contains internal messages/errors.

Pebble proxied log format:

2023-07-24T05:38:56.522Z [syslog] Message

Own log format

<some message>
Own logs
less /var/snap/maas/common/log/rsyslog/PATH/TO/LOG
stdout redirected by Pebble:
journalctl -u snap.maas.pebble.service --case-sensitive -g "^[0-9TZ:.-]{24} \[syslog\]"

DHCP (dhcpd, dhcpd6)

DHCP logs everything through syslogd, while stdout (redirected by Pebble) contains init messages. There is no particularly easy way to differentiate between dhcpd and dhcpd6, although you can grep for a “PID file: /var/snap/maas/common/maas/dhcp/dhcpd6?.pid ” message, and then use the PID to filter logs in journal, like this:

journalctl -et dhcpd -u snap.maas.pebble.service SYSLOG_PID=25799

Pebble proxied log format:

2023-06-27T11:24:47.674Z [dhcpd] Internet Systems Consortium DHCP Server 4.4.1

Own log format

<plain old DHCP message>
Own logs
journalctl -t dhcpd -u snap.maas.pebble.service
stdout redirected by Pebble:
journalctl -u snap.maas.pebble.service --case-sensitive -g "^[0-9TZ:.-]{24} \[dhcpd\]"

Remote syslog (3.4 UI)

To enable remote logging, choose Settings > Network > Syslog, and enter your syslog server’s IP/URL under Remote syslog server to forward machine logs.

Remote syslog (3.3-- UI)

To enable remote logging, choose Settings > Network services > Syslog; add your syslog server’s IP/UL; and click Save.

Remote syslog (CLI)

maas $PROFILE maas set-config name="remote_syslog" value="$SYSLOG_FQDN"
# Example for setting syslog server to 192.168.100.11:
maas $PROFILE maas set-config name="remote_syslog" value=192.168.100.11
# To reset to default (sending syslog to MAAS region controllers):
maas $PROFILE maas set-config name="remote_syslog" value="

Note: Only machine syslog information is forwarded, not MAAS controllers syslog files.

Direct log access

Logs can be found at the following paths depending on your installation type (snap or package):

  • Snap installation:

    • /var/snap/maas/common/log/maas.log
    • /var/snap/maas/common/log/regiond.log
    • /var/snap/maas/common/log/rackd.log
    • /var/snap/maas/common/log/rsyslog/$MACHINE_NAME/$RELEVANT_DATE/messages
  • Package installation:

    • /var/log/maas/maas.log
    • /var/log/maas/regiond.log
    • /var/log/maas/rackd.log
    • /var/log/maas/rsyslog/$MACHINE_NAME/$RELEVANT_DATE/messages

Logs can be extensive and challenging to search. The MAAS web UI does not categorise events by type.

Events query (CLI)

The most efficient way to review events is using the events query CLI sub-command. This command allows filtering and summarising events. Use jq and various filters to simplify output interpretation.

Basic queries

maas $PROFILE events query

This command returns a lengthy JSON output, which can be simplified using jq and various filters, making it more readable.

Using jq with events

A jq command example for readable output:

maas $PROFILE events query limit=20 | jq -r '(["USERNAME","NODE","HOSTNAME","LEVEL","DATE","TYPE","EVENT"] | (., map(length*"-"))), (.events[] | [.username,.node,.hostname,.level,.created,.type,.description]) | @tsv' | column -t -s$'\t'

Filter parameters

The events query command supports multiple filters:

  • hostname: Events for a specific node hostname.
  • mac_address: Events for nodes with specified MAC addresses.
  • id: Events for nodes with specific system IDs.
  • zone: Events for nodes in a particular zone.
  • level: Filter by event level (AUDIT, CRITICAL, DEBUG, ERROR, INFO, WARNING).
  • limit: Maximum number of events to return.
  • before/after: Start returning events before or after a specific event ID.

Example usage of these filters can narrow down event listings significantly.

Auditing finesse

Audit events, tagged with AUDIT, record MAAS configuration changes and machine state transitions. They’re essential for tracking user actions and system updates, especially in multi-user environments.

Use audit events alongside jq and command-line text tools to analyse actions like machine deletions, configuration changes, and user activities. This can provide insights into system changes and help identify areas for attention or improvement.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.