Navigation

Documentation

Contents[Hide]

1. Overview

By default, log entries are written to the application database, which is useful for viewing logs within the application. If you monitor your infrastructure through a centralized logging platform such as Datadog, Splunk, or the ELK stack, you may want logs to appear there as well.

Centralized logging agents typically read files rather than database tables, so this article shows you how to write logs to files on disk and forward them to your logging backend.

2. Writing logs to files

You can set up the logs to be written to files on disk in the configuration settings:

  1. Enable Tracing to File. (Log entries will also continue to be written to the application database if you leave Tracing to Database enabled.)
  2. By default, files are written to a Logs subfolder of the website's App_Data folder. If preferred, you can change this with the Logging File Location setting.
  3. If preferred, you can change the Log Entry Maximum Age setting, which determines determines how many days of logs are preserved in files and/or the database (30 by default).

3. Log file format

A separate file is written for each day using a time-stamped name such as Dundas BI-2026-05-07.log.

Log entries are written in JSON Lines format, which means one complete JSON object per line. A typical entry looks like the following:

{
  "dt": "2026-05-07T14:17:14.1704594Z",
  "lev": 4,
  "mid": 2600,
  "ch": "Framework.Transfer",
  "msg": "[Export]: Status: Success, Time taken: 0:00:00. Accounts: 1/1 ...",
  "src": "Dundas BI Web App (33b40329368c.localdomain)",
  "uid": "92ace8aa-757c-44d1-a701-6234ed210fbb",
  "sid": "d47944a1-12a7-4891-9e0b-71aadb00732f",
  "tnid": "a1b2c3d4-5678-90ab-cdef-1234567890ab",
  "pid": 1,
  "tid": 44
}

The key fields are:

  • dt – ISO 8601 timestamp
  • lev – Numeric log level (severity), corresponding to Dundas.BI.LogLevel
  • ch – Channel or category (e.g., "Framework.Transfer")
  • msg – The log message body
  • src – The Dundas instance identifier
  • uid – User ID
  • sid – Session ID
  • tnid – Tenant ID (in multi-tenant deployments)
  • pid – Process ID
  • tid – Thread ID
  • mid – Message ID (present on some entries)

Because each line is a complete JSON object, a logging agent can index every field directly, with no need for multiline aggregation rules or regular expressions to extract fields.

4. Set up log forwarding

Install a logging agent on the server where Dundas BI is running. Most platforms provide their own: for example, the Datadog Agent, the Splunk Universal Forwarder, or Filebeat for ELK. There are also backend-agnostic options such as Fluent Bit.

Note
In a Kubernetes deployment, the Dundas BI pod writes its log files to a hostPath volume, which is a directory on the host node. Run the logging agent as a DaemonSet so that it reads from that directory on each node, exactly as it would in a standalone installation.

  1. Configure the agent to read from the log file location you configured using a glob pattern that matches the daily file names (for example, Dundas BI-*.log).
  2. Set the agent to parse each line as JSON.
  3. Add a mapping that translates the numeric lev value into a severity label (see Dundas.BI.LogLevel in the API) so your backend can filter and alert on it.

5. See also

Dundas Data Visualization, Inc.
400-15 Gervais Drive
Toronto, ON, Canada
M3C 1Y8

North America: 1.800.463.1492
International: 1.416.467.5100

Dundas Support Hours:
Phone: 9am-6pm, ET, Mon-Fri
Email: 7am-6pm, ET, Mon-Fri