====================
Reviewing log files
====================

Bonding services keep detailed log files that can be viewed with the
``bondlog`` application. They can also be view using ``journalctl`` on
Debian Jessie and above, or ``less`` on Wheezy.

Logs are a valuable troubleshooting resource. When investigating any
issue, be sure to review the logs on the bonder or aggregator, or both.

To view the logs, see
instructions `here <node-applications.html#bondlog>`__.

Logs on Debian Jessie and above
--------------------------------

The ``journalctl`` command can be used to view all logs at once, or
filters can be used to isolate services. Some common filters:

-  ``journalctl /usr/lib/bonding/node``: the node service
-  ``journalctl /usr/lib/bonding/bridge``: the TCP proxy service. Use
   ``bondlog`` to isolate by bond ID
-  ``journalctl /usr/lib/bonding/subprocess``: the subprocess service
-  ``journalctl /usr/lib/bonding/tunnel``: the tunnel service. Use
   ``bondlog`` to isolate by bond ID
-  ``journalctl /usr/lib/bonding/web``: the web service
-  ``journalctl /usr/lib/bonding/privatewan-aggregator-agent``: the
   private WAN space agent for aggregators. Use ``bondlog`` to isolate
   by space
-  ``journalctl /usr/lib/bonding/privatewan-router-agent``: the private
   WAN space agent for private WAN routers. Use ``bondlog`` to isolate
   by space

Logs on Debian Wheezy
----------------------

The log files, located at ``/var/log/bonding/``, are as follows:

-  ``bridge.log``: logs for all TCP proxy applications on the node (TCP
   proxy is known internally as bridge). To view TCP proxy logs for a
   specific bond, use ``bondlog``.
-  ``config.log``: for the config service
-  ``node.log``: for the node service
-  ``openvpn.mtun0.log``: for the management VPN client
-  ``subprocess.log``: for the subprocess service
-  ``tunnel.log``: for all tunnels on the node.  To view tunnel logs for
   a specific bond, use ``bondlog``.
-  ``web.log``: for the node HTTP service

Rotated log files are named as, for example, tunnel.log.1 (for the
previous day's logs), tunnel.log.2 (for two days ago), and so on.

Debug logging
--------------

.. warning::

    Debug logging is not recommended for production devices because it makes
    it more difficult to view warning and error log messages and because it
    increases disk usage. Only enable debug mode when recommended by a
    technical support agent.

Node services can be set to debug-level logging. This greatly increases
the number of log messages and can be used to troubleshoot unusually
difficult issues. Debug logging is enabled in one three places,
depending on which service or services have a problem.

-  Aggregator core services: to enable debug mode for the node, config,
   or subprocess service on an aggregator, set the "debug" field in the
   aggregator record on the management server.
-  Bonder core services: to enable debug mode for the node, config, or
   subprocess service on an bonder, set the "node debug" field in the
   **Details** section of the bond record on the management server.
-  Tunnel and TCP proxy service for a particular bond: to enable debug
   mode for the tunnel and TCP proxy applications of a particular bond,
   on both the bonder and aggregator, set the "debug" field in
   the **Configuration** section of the bond record of the management
   server.

There is no method to enable debug logging for all the tunnel or TCP
proxy applications on a single aggregator. To do this, enable debug
logging for each individual bond on the aggregator.
