> ## 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.
# Set Up Monitoring
> Set up monitoring so that all metrics and logs are centralized on XCC and visible in the dashboards.
**Prerequisites**
* You used the VM setup script to set up the xorlab VMs. If for any reason that was not the case, follow the **Hostname** changes there manually for the XCC: [Setup Script](/latest/vm-setup-script-breakdown#hostname).
1. Open the [Expert Editor](/latest/expert-editor).
2. Navigate to `/monitoring/prometheus/prometheus.yml`.
3. In the `scrape_configs` section, find the `mta` scrape job, and replace `example-mta1/2` with the hostnames of your MTA VMs. If you have more MTAs, add more targets with correct hostnames.
```yaml prometheus.yml {11,13} theme={null}
- job_name: mta
scheme: https
tls_config:
insecure_skip_verify: true
metrics_path: /federate
params:
match[]:
- '{job!=""}'
static_configs:
- targets:
- example-mta1:9090
- targets:
- example-mta2:9090
```
4. Click **Publish**. The monitoring configuration becomes active within about one minute; after a few minutes you should start to see data in the monitoring dashboards.
## Set up more than two MTAs
This part is only required when you plan to use more than the default of two MTA VMs.
1. Navigate to `/monitored_mta/prometheus/`.
2. Duplicate an existing `prometheus.yml.vmx.N` file once for each additional MTA.
3. For every additional `prometheus.yml.vmx.N`: Change `external_labels.host` to the name of the respective MTA, e.g. `mta3`.
```yaml prometheus.yml.vmx.N {4} theme={null}
global:
# (...)
external_labels:
host: mta3
```
Note: Setting the `host` label in `monitored_mta/prometheus/prometheus.yml.vmx.N` as opposed to setting them centrally in the XCC Prometheus config, i.e. `monitoring/prometheus/prometheus.yml`, allows alerts generated on the MTAs to display their own hostname by using `{{ $labels.host }}` in the alert template.
4. Navigate to `/monitored_mta/promtail/`.
5. Duplicate an existing `config.yml.vmx.N` file once for each additional MTA.
6. For every additional `config.yml.vmx.N`: Update the `hosts` label to match the MTA:
```yaml config.yml.vmx.N {4} theme={null}
# (...)
labels:
job: docker-logs
host: