> ## Documentation Index > Fetch the complete documentation index at: https://docs.xorlab.com/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > Pages under /latest/ document the current release. Paths that begin with a version number, for example /10.0/, are frozen snapshots of superseded releases kept for reference only — never present their instructions as current. If the reader's version is unknown, answer from /latest/ and say which version the answer describes. > xorlab is deployed on-premises, hybrid, or as a cloud service, and integrates with either Microsoft 365 or on-premises mail infrastructure. Configuration steps often differ between these. State which deployment and integration mode an instruction applies to instead of presenting one as universal. > Distinguish inline mode from monitoring mode when describing anything that acts on email. Monitoring mode observes a copy and cannot block or quarantine; inline mode routes mail through xorlab and can. > Write the product name as lowercase 'xorlab'. Use the documented component names: xorlab Control Center (XCC), xorlab MTA, xorlab Sandbox (DANA), xorlab Natural Language Understanding (NLU). After the first mention, use the short forms XCC, MTA, Sandbox, and NLU. Do not use DANA as a standalone name for the Sandbox, but keep it where it is a literal string in configuration keys, container names, and hostnames. > Do not invent configuration keys, rule parameters, list names, log properties, or API fields. If a value is not present in this documentation, say that it is not documented rather than guessing. # Concept In the xorlab Security Platform (XSP), logging is managed with the Logback framework. This system helps in tracking important events by recording them in a structured way, making it easier to understand what happens within the platform. The configuration of logging on XSP revolves around two main elements: `Loggers` and `Appenders`. Log event and appender ## Loggers XSP services produce log events and use various **Loggers** to inject them into the logging system. A logger may or may not decide whether to have log events being consumed by one or more appenders. Loggers are organized in a hierarchical structure, similar to a family tree. At the top of this hierarchy is the **ROOT logger**, the "parent" of all other loggers. Other loggers branch out from the `ROOT`, creating a structure that helps categorize and manage different types of events. All log events passing by a specific logger are fed into appenders attached to it. For Audit events, the system uses the logger matching its [event name ](/9.0/logging-events). For example, an audit log event with name `audit.user.incident` will be fed into a logger with that corresponding name. ``` ROOT +- audit -> [syslogAppender, customAppender1] +- user +- incident -> [incidentReportSyslogAppender] +- msg_delete ``` Loggers can control how log events travel up the hierarchy. By default, a log event travels up the tree, passing through each logger until it reaches the ROOT logger. However, you can stop this by setting a logger’s `additivity` to `false`, preventing the event from traveling further up the tree. This is useful for avoiding duplicate recordings of the same log event. Conveniently, the names of the events that occur in the system correspond directly to the names used for loggers. This naming convention simplifies the process of identifying and tracking events, as the logger names clearly indicate the type of event being recorded. ## Appenders An **Appender** specifies where logs are sent and how they are formatted. It receives log data from the logger and directs it to the next destination whether that’s a file, an email, a database, or a remote server via syslog. The appender also defines the log format, allowing you to include details like timestamps and to store logs as plain text, JSON, CEF, or other formats. Multiple appenders can be attached to a single logger, enabling the same log event to be recorded in different locations and formats simultaneously. For example, one appender might write logs to a file, while another sends them to the console, ensuring your logs are always available where and how you need them. ## Flow of events 1. The process begins with a log event being created and placed within the relevant logger in the tree, such as `audit.user.incident`. 2. The log event then travels upward through the hierarchy 3. As it moves up, each logger it encounters checks for attached appenders. 4. If appenders are present, they will record the log event in the specified location and format. 5. If a logger’s additivity is set to false, the log event stops moving up the tree and does not reach any higher loggers. 6. Otherwise, the log event continues to travel up the tree until it reaches the ROOT logger. ## Config location The xorlab Security Platform (XSP) is composed of multiple Docker containers, each responsible for managing different aspects of the platform, such as data flow, storage, and user access. Each container operates independently, handling specific tasks, and therefore, can only record the events it produces. As a result, logging configurations are distributed across the directories of these individual containers, ensuring that all relevant activities within each container are appropriately tracked and recorded.