# This is configuration file for the Dwarf library
# The file consists of a few lines in the format of KEY=VALUE plus optional comment lines beginning with '#' character as the first line character
# DWARFG_LONG will initialize the library on startup.
# You can force debug configuration re-read via DWARFG_LONG ctl script (INSTALL_PATH/dwarfg_ctl.sh --reload-cfg)
# All the keys and their defatults are copied here in the comments for reference.
# The available debug levels (in the increasing verbosity) are:
# MDL_CRIT ... log critical events. Minimal settable log level (always logged).
# MDL_ERR ... log errors.
# MDL_WARN ... log warnings. Recommended minimal debug level.
# MDL_NOTE ... log notable events happening in DWARFG_LONG system.
# MDL_INFO ... log all messages of some potential information value. Recommended maximal debug level.
# MDL_DEBUG ... large amount of messages. Use when asked for debug logs only.
# MDL_SUPERDEBUG ... excessive amount of debug message, do not use. Usually Disable during compilation unless you have debug build
#
# Every DWARFG_LONG debug message is sent towards a particular DBG AREA (or a combination of several areas). You can set different logging level for an area. E.g. increasing debug level for an DBG_AREA_DEVREG will result in having more information regarding new device registration stored in the log file.
# DWARFG_LONG debugging subsystem will try to match debuglevel of the message against all areas this message is valid for, putting it in the log and indicating the first area that matched. If no area matches, message is compared to the generic area log level as last resort before being ignored.
# As could be seen from above, the generic area is a "catchup-all" area and as such, you should keep that area on lower debuglevel. E.g. set DBG_AREA_DEVREG to MDL_INFO, all other areas to MDL_WARN and generic area to MDL_ERR. This way, you will get informational messages on new device registration, warnings for all the specific areas and no error (even if it is generic without a specific area set) will be ignored in log.
# You should be fine with the production defaults. In emergency, remember:
#   - the defaults can be found here:
#     INSTALL_PATH/dwarflib_cfg_prod.txt - suggested production defaults
#     INSTALL_PATH/dwarflib_cfg_dbg.txt - suggested debugging defaults (as a start)
#   - if you need to limit messages to a minimum, simple delete this file. You will receive only critical messages then.
#   - remember to signal DWARFG_SHORTd to reload the debug settings after any change (INSTALL_PATH/dwarfg_ctl.sh - -reload-cfg) or simply restart the service (service dwarfg restart)
#   - NOTE it could take a few seconds until the debug cfg changes are reflected in the debug.
#
# Before getting to the particular debug areas, there are a few true/false settings you can use:
#
# Debug messages are by default statically limited to 80/240 characters. If you desire to see whole messages, you need allow dynamic allocation with no size limit - useful for debugging problems but impacts log file size and may impact performance.
#
#DBG_NOLIMIT=0
#
# If you want to see all the debug messages up to MDL_DEBUG concerning a particular device, put the device ID here and reload Dwarflib or restart Dwarfguard service. Messages concerning that device are not throttled even if debug message throttling is enabled. Only single device-id is supported.
#
#DBG_DEVICE=0
#
# The messages of any other level than MDL_CRIT can throttled. Debug system message throttling can be enabled or disabled using the following:
#
#DBG_THROTTLE=0
#
# Note that the throttling applies to all similar messages. Meaning that the throttling is not done on the exact message text but on message format text resulting in e.g. all the same error messages from multiple devices can be throttled into a single message. If you are trying to pin down a problem or create debug logs, you definitely want to disable the throttling system. Please note you need either reload the configuration or simply restart the service after the change here.
# You can also specify a time interval for throttling. If a message would be throttled, but the time since the last appearance of the (throttled) message in the log exceeds the interval, the (throttled) message is printed in the log anyway. It is generally preferable to set the interval to some reasonable amount of seconds, like between 100 and 1000. Consider having 10000 devices logging the same error every data push interval. Setting the throttle interval to e.g. 300, means that the message will appear only once per 5 minutes.
#
#DBG_THR_INT=300
#
# When you want to dump data pushes content and data pushes responses from/to devices, you can set the following variables to 1. Note that this will create additional load on storage (disk) and the amount of data stored grows by time, potentially filling up all free space on storage. Do not use unless trying to debug a problem.
#DBG_DUMPDATAPUSH=0
#DBG_DUMPDATARESP=0
#
# If you want to see the data stored into the DB for a device, you may set the following variable to a positive number. Please note that due to performance reasons, the number is hard-limited in the daemon to roughly 100 (means dumping the data for the first 100 devices in an SQL statement into the log). Also note that to effectively see something, you need to set the DBG_NOLIMIT=1 and DBG_THROTTLE=0.
#DBG_DBDATA_DUMP=0
#
# For debugging and profiling reasons (e.g. profiling memory allocation per new device) DWARFG_LONG incorporates own memory instrumentation. Do *NOT* enable on production (dwarf-only/experimental phase). Changing this on-the-fly will not work. If you want to enable/disable memory instrumentation, you need to restart DWARFG_LONG after changing this setting.
#
#DBG_MEMIN=0
#
# Description of the debug areas:
#
# The catchup-all level for debug. All messages of this (and more important) debug level will be stored in debug log (/srv/DWARFG_SHORT*/log/log_dwarfg.txt) except pure debug/profiling areas as noted below.
# The generic level should be generally set lower than individual areas.
#
#DBG_GENERIC=MDL_WARN
#
# DBG area: debug subsystem
#
#DBG_AREA_DBGSYS=MDL_INFO
#
# DBG area: application start/stop
#
#DBG_AREA_APPSYS=MDL_NOTE
#
# DBG area: device registration
#
#DBG_AREA_DEVREG=MDL_INFO
#
# DBG area: data incoming from device
#
#DBG_AREA_DEVDATA=MDL_NOTE
#
# DBG area: database queries
#
#DBG_AREA_DBQ=MDL_WARN
#
# DBG area: user-actions
#
#DBG_AREA_USERACT=MDL_NOTE
#
# DBG area: device status change
#
#DBG_AREA_DEVSYNC=MDL_WARN
#
# DBG area: alerts and notifications
#
#DBG_AREA_ALERTS=MDL_INFO
#
# DBG area: server configuration changes
#
#DBG_AREA_SRVCONFIG=MDL_INFO
#
# DBG area: Device FW/OS related events
#
#DBG_AREA_FWUPD=MDL_INFO
#
# DBG area: monitoring group related
#
#DBG_AREA_GROUP=MDL_NOTE
#
# DBG area: statistics
#
#DBG_AREA_STATIS=MDL_WARN
#
# DBG area: Device profiles.
#
#DBG_AREA_PROF=MDL_INFO
#
# DBG area: Tunnels (both web and ssh).
#
#DBG_AREA_TUNN=MDL_INFO
#
# DBG area: DWARFG_LONG function flow. Do not use unless debugging. NOTE: not covered by generic area.
#
#DBG_AREA_FFLOW=MDL_WARN
#
# DBG area: DWARFG_LONG memory instrumentation. Do not use unless debugging. NOTE: not covered by generic area.
#
#DBG_AREA_MEMINST=MDL_WARN
#
# DBG area: DWARFG_LONG lowlevel stuff (like message buffering). Do not use unless debugging. NOTE: not covered by generic area.
#
#DBG_AREA_LOWLEV=MDL_NOTE
#
#
# And now the actual values
#
DBG_NOLIMIT=1
DBG_DEVICE=0
DBG_THROTTLE=0
DBG_DUMPDATAPUSH=1
DBG_DUMPDATARESP=1
DBG_DBDATA_DUMP=120
DBG_MEMIN=0
DBG_GENERIC=MDL_NOTE
DBG_AREA_DBGSYS=MDL_INFO
DBG_AREA_APPSYS=MDL_INFO
DBG_AREA_DEVREG=MDL_DEBUG
DBG_AREA_DEVDATA=MDL_DEBUG
DBG_AREA_DBQ=MDL_DEBUG
DBG_AREA_USERACT=MDL_DEBUG
DBG_AREA_DEVSYNC=MDL_DEBUG
DBG_AREA_ALERTS=MDL_DEBUG
DBG_AREA_SRVCONFIG=MDL_DEBUG
DBG_AREA_FWUPD=MDL_DEBUG
DBG_AREA_GROUP=MDL_INFO
DBG_AREA_STATIS=MDL_INFO
DBG_AREA_PROF=MDL_DEBUG
DBG_AREA_TUNN=MDL_INFO
DBG_AREA_FFLOW=MDL_WARN
DBG_AREA_MEMINST=MDL_WARN
DBG_AREA_LOWLEV=MDL_NOTE