Skip to content
Thirdlane

Call Logs Database

The Call Logs Database settings (General Settings & Tools > Call Logs Database) define the MySQL database used for communications logs (pbxlogs): credentials services use to write call detail records, queue activity, and related events, and the connection the Manager UI uses to read that data for reports, grids, CRM timelines, and analytics.

Write path

The write fields (host, database name, user, password) are what recording services use to store data in MySQL. Queue log data uses the same connection. Use Test Connection to verify reachability and credentials from the Manager host.

Reporting (read) path

By default, reporting uses the same MySQL server and credentials as the write path. This is appropriate for most deployments.

Choose Separate MySQL host or replica when you want the Manager to run reporting against another host (for example a read replica) so heavy reporting does not compete with write load on the primary database server. Enter the reporting host, database name, user, and password, then use Test Connection for that path before saving.

When reporting is set to the same database as writes, the product keeps the stored reporting parameters aligned with the write credentials on save.

Ports and remote hosts

If the database listens on a non-default port, include it in the host field (for example db.example.com:3307) where your deployment expects host:port format.

Report scale settings

A few reporting behaviours are not in the Manager UI. They live in /etc/webmin/asterisk/reports_analytics.conf as key=value lines, and every default keeps the installation on MariaDB:

SettingDefaultEffect
max_days_interactive90Largest date range an interactive report will run. Protects the reporting database from a casual multi-year query.
prefer_rollups1Read pre-aggregated daily summaries where a report can use them, instead of scanning raw CDR.
rollup_lookback_days3How far back the nightly job recomputes summaries, so late-arriving records are picked up.

The same file holds the reporting privacy defaults for organization-level administrators - whether they may drill into individual call detail, open Users and Access, and see messaging gateway names. Platform, global and system administrators always see everything, and a global administrator can override the call-detail setting per organization on the tenant record.

ClickHouse analytics store

Very high call volumes can outgrow MariaDB for reporting, at the point where even rollups and indexes leave interactive reports slow. For those installations an optional ClickHouse store can serve the heaviest sections - currently Overview and Call List, which fall back to MariaDB when it is not enabled.

This is off by default and most deployments never need it. Enabling it takes two keys in the same configuration file, both required:

analytics_enabled=1
backend=clickhouse

The connection defaults to http://127.0.0.1:8123/, database thirdlane_reports, user default, each overridable with clickhouse_url, clickhouse_database, clickhouse_user and clickhouse_password.

ClickHouse is fed by a batch export from MariaDB, not by services writing to it directly. MariaDB remains the system of record: an hourly job copies new call detail records, queue activity, IVR events and hunt group events across, resuming from the highest record already loaded. Nothing is exported at all while the feature is disabled.

Two consequences are worth knowing before enabling it. Because the export is hourly, ClickHouse-backed sections lag behind live data by up to an hour, which is fine for trend analysis and wrong for checking what just happened - use the MariaDB-backed sections or Users Status for that. And because MariaDB keeps every record regardless, turning the feature off changes which store reports read from rather than losing anything.

Best practices

  • Use Test Connection before saving on both the write and reporting paths so a typo in host, credentials, or port is caught immediately rather than surfacing later as missing reports.
  • Offload heavy reporting to a replica when report queries begin to compete with live write load - point the reporting (read) path at a read replica while writes continue against the primary.
  • Include the port in the host field (for example db.example.com:3307) when the database does not listen on the default port.