Logging in BILLmanager

BILLmanager saves information about its operation in log files. Log data can be used for platform diagnostics.

Logging configuration

The logging level determines the detail of information recorded in logs. The higher the value, the more detailed the information.

Logging levels:

• 1 — notices;
• 2 — critical errors;
• 3 — errors;
• 4 — warnings;
• 5 — request information;
• 6 — extended information;
• 7 — remote service notifications;
• 8 — code tracing;
• 9 — debug information.

Via web interface

To change the logging level, in the main menu go to Settings → Logging settings → select modules → click:

• Edit to configure the logging level for selected modules;
• Default to remove logging configuration for selected modules from the configuration file. The logging level for * All modules will be used;
• Maximum to set the maximum logging level for selected modules.

If the required service is not displayed in the list, you can configure its logging level via the configuration file /usr/local/mgr5/etc/debug.conf. See the COREmanager documentation article Logging configuration (debug.conf) for details.

Via configuration file

To change the logging level:

1. Connect to the platform server via SSH. For more information on SSH connection, see the article Workstation setup.

2. Add a line with the module name and required logging level to the file /usr/local/mgr5/etc/debug.conf. For example, an entry for the pmvmmgr6.log module log file:

   pmvmmgr6.* 9

To restore the default logging level, delete the added lines from the file /usr/local/mgr5/etc/debug.conf.

/usr/local/mgr5/sbin/mgrctl -m billmgr -R

systemctl restart ihttpd

List of log files

Log files are stored in the directory /usr/local/mgr5/var/

Archived log files are stored in the directory /usr/local/mgr5/var/logs/

Main log files

Message gateways

Related articles:

• Configuring SMS gateway;
• Configuring mail server;
• Setting up notifications via Telegram.

Phone verification

Related articles:

• Phone verification gateways.

Service processing

Related articles:

• Service processing.

Payment methods

Log files for billing platform interaction with payment modules are described in the articles in the Payment gateway section.

Ticket management modules

Related articles:

• Managing tickets in Telegram.

Log management

Modules can write their events to different log files, so the module name in logging settings may differ from the log file name.

Mar 21 08:45:12 [2962:1] <module_name> <log_level> Query: 'SELECT nc.* FROM notifytemplate nt JOIN notifycontent nc ON nc.notifytemplate = nt.id WHERE nt.notice = 'sitebuilderopen' AND nt.project IS NULL'

Where:

• Mar 21 08:45:12 — event timestamp according to server system time;
• [2962:1] — log thread. Unique identifier where:
  • first value — Linux OS process ID. This value changes after BILLmanager platform restart;
  • second value — unique BILLmanager platform request ID. Each request has its own number for tracking in logs.
• <log_level> — can have the following values:
  • NOTE — notices;
  • FATAL — critical errors;
  • ERROR — errors;
  • WARNING — warnings;
  • INFO — request information;
  • EXTINFO — extended information;
  • EXT — remote service notifications;
  • TRACE — code tracing;
  • DEBUG — debug information.

Diagnostics

This section provides an example of diagnostics using the main platform log billmgr.log. Other logs may also be required for diagnostics. For example, payment issues are logged in payment module logs, while resale problems are logged in the interaction log between selling and reselling billing systems. All log files are located in /usr/local/mgr5/var/. Service-specific log names are listed in the integration article for that service. For example, PayMaster payment issue logs are listed in the PayMaster article.

The main platform log billmgr.log records all major events and errors. To check for errors in the main log, run the command:

grep 'ERROR' /usr/local/mgr5/var/billmgr.log

To view current logs, run the command:

tail -f /usr/local/mgr5/var/billmgr.log

You can diagnose most issues using the log display command. To do this:

1. Open the BILLmanager interface section where the incorrect behavior occurs.
2. Connect to the platform server via SSH. For more information on SSH connection, see the Workstation setup article.

3. Open the real-time log with the command:

   tail -f /usr/local/mgr5/var/billmgr.log

4. Reproduce the incorrect behavior in the interface.

As a result, the log will display the error and the request preceding it, helping identify the cause of the incorrect behavior.

Log rotation

Log rotation is the automatic process of archiving and cleaning log files when they reach a specified size. In BILLmanager, each log file is limited to 100 MB by default. All logs are written to the /usr/local/mgr5/var/ directory. When a file reaches its maximum size, the system:

1. Moves the log content to the /usr/local/mgr5/var/logs/ directory and compresses it into an archive.
2. Adds a suffix to the archived filename containing:
   • creation date and time in YYYY_MM_DD_HH_MM_SS format;
   • sequence number to ensure uniqueness if multiple files are rotated within the same second.
3. Clears the original file content. Writes the full name of the created archive as the first line.

billmgr.log.2026_02_03_15_3022_01.0.gz

Rotation parameter configuration

You can control log rotation using global parameters in the /usr/local/mgr5/etc/debug.conf file:

• max_log_size — maximum log file size in bytes before rotation; default value is 104857600 (100 MB);
• color — colored log formatting. Valid values:
  • on — enabled (default);
  • off — disabled.
• storage — log output method. Valid values:
  • file — write to file (default).
  • console — output to stdout.

Python plugin log rotation

For plugins written in Python using the billmgr.logging module from the BILLmanager SDK (Software Development Kit), automatic log rotation is implemented at 100 MB. Changing the file size is not supported. The archive name is not written during rotation.