Logging in BILLmanager

BILLmanager saves information about the platform in log files. The data from the log files can be used to diagnose the operation of the platform.

Logging configuration

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

Logging levels:

• 1 — notes;
• 2 — critical errors;
• 3 — errors;
• 4 — warnings;
• 5 — information about requests;
• 6 — extended information;
• 7 — messages from remote services;
• 8 — code tracing;
• 9 — debugging information.

Note

Detailed logs take up more disk space. After completing the diagnostics, we recommend that you reset the logging level to the default value.

Enter Settings → Logging settings → select the modules → click:

• Edit, to configure the logging level for the selected modules;
• Default, to delete the logging settings from the config file for the selected modules. The * All modules value of the module's logging level will be used;
• Maximum, to set the maximum logging level for the selected modules.

Editing the logging level for * All modules will result in a level change for all modules with the "Default logging configuration" status.

List of log files

The log files are stored in the directory /usr/local/mgr5/var/.

The archive log files are stored in /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 method

Log files of interaction between the billing platform and payment modules are described in the articles of the section Payment gateways.

Ticket management modules

Related articles:

• Managing tickets in Telegram

Log management

Modules can record their events in different log files, so the name of the module in the logging settings may be different from the name of the log file.

Example of a string in the billmgr.log log file:

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

• Mar 21 08:45:12 — date of the event in the system time of the server;
• [2962:1] — log thread. A unique identifier, where
• the first value is the process number in Linux. After restarting BILLmanager, the value will change;
• the second value is the unique query number for the BILLmanager platform. Each query has its own number, so it can be tracked in the log.
• <logging_level> — has the following levels:
• NOTE — notes;
• FATAL — critical errors;
• ERROR — errors;
• WARNING — warnings;
• INFO — information about queries;
• EXTINFO — extended information;
• EXT — message from remote services;
• TRACE — code tracing;
• DEBUG — debugging information.

Diagnostics

This section gives an example of diagnostics with the main log of the billmgr.log platform. Other logs may also be required for diagnostics. For example, in case of payment problems, information about errors will be recorded in the logs of the payment module, and in case of problems with reselling services — in the log of the interaction between the selling and reselling billing systems. The list of all logs is located at /usr/local/mgr5/var/. For the names of the logs, see the corresponding section in the BILLmanager 6 documentation. For example, logs to diagnose Paymaster payment problems are listed in the PayMaster article.

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

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

To check the logs at the moment, run the command:

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

Any problem can be diagnosed using the command to display the logs at the moment. To do this:

1. Open the section in the BILLmanager interface where the incorrect behavior occurs.
2. Connect to the server with the platform via SSH.
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 of these actions, the log will display an error and the request that precedes it. This will help identify the cause of the incorrect behavior.

For detailed diagnostics, the above instructions can be used with any other log, such as the processing module log. 

Useful tips

Knowledge base articles:

• Basic diagnostics