> For the complete documentation index, see [llms.txt](https://docs.dorg.pro/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dorg.pro/install-dorg/troubleshooting/application-logs.md).

# Application logs

The primary source of information for troubleshooting is the application container logs. 

## Browsing Logs on Grafana

Starting from Dorg 3.3, logs are collected into Grafana via Loki.\
A predefined Grafana Dashboard is made available for browsing logs coming from Orchestrator and the main external MCPs  (Files and RAG), as well as custom MCPs that supports the logging.

<figure><img src="/files/ywEhFUdMtnLsNl1OK6yD" alt=""><figcaption></figcaption></figure>

### Sharing the logs

You can share logs to us or to Partners to help you troubleshooting issues.\
\
**Share a link to externals**\
Click on **Share** button, then **Share externally**.

**Download the logs as a file**

1. Click on the 3 dots icon at right of Dorg Logs header.<br>

   <figure><img src="/files/3xPXgWoR024yQtnBupK5" alt=""><figcaption></figcaption></figure>
2. Click **Explore**.
3. On the right bar, click on **Download Logs**.<br>

   <figure><img src="/files/RuDVhKUd4gCouNf4yYJ3" alt=""><figcaption></figcaption></figure>

## Accessing Logs on Azure

These can be accessed through the **Azure Portal** by navigating to the specific Container App resource and selecting Log stream from the left-hand menu.

Logs are also ingested into a **Log Analytics workspace** (with 30-day retention), which allows querying historical logs across all containers using the Azure Portal's Logs blade with KQL queries.

#### Accessing Log Stream

1. Open the [Azure Portal](https://portal.azure.com/)
2. Navigate to the **Resource Group** containing your Dorg deployment
3. Select the desired **Container App** resource
4. In the left menu, under **Monitoring**, click **Log stream**
5. Select the **Application** console to view real-time stdout/stderr output from the container

#### Container Apps and Their Purpose

The platform is composed of the following Container Apps, grouped by function. Each runs as an **Azure Container App** within a managed environment.

**Orchestration and UI**

<table><thead><tr><th width="209">Container App</th><th>Description</th></tr></thead><tbody><tr><td>orchestrator</td><td>The main Dorg API and orchestration engine. Handles AI model integration (Azure OpenAI, Claude), Keycloak authentication, Teams/Entra connectivity, MCP service routing, Document Intelligence, and MongoDB persistence. Exposes an external HTTP endpoint behind Azure Front Door. Runs with Dapr enabled for service-to-service communication.</td></tr><tr><td>dashboard-gateway</td><td>The Admin Console backend-for-frontend (BFF) API gateway. Proxies requests from the web UI to the orchestrator, Keycloak, and other internal services. Handles license validation, ACR credentials, and optional Azure AI administration. Exposed via Front Door on the <code>/api</code> path.</td></tr><tr><td>dashboard-web</td><td>The Admin Console web UI. Provides the operator-facing portal for managing and monitoring the DORG platform. Authenticates users via OIDC through Keycloak. Exposed via Azure Front Door.</td></tr></tbody></table>

**Identity**

<table><thead><tr><th width="207">Container App</th><th>Description</th></tr></thead><tbody><tr><td>keycloak</td><td>The identity and single sign-on (SSO) provider based on <a href="https://www.keycloak.org/">Keycloak</a>. Manages user authentication, realm configuration, and OIDC token issuance. Backed by a dedicated PostgreSQL Flexible Server. Listens on port 8080 and is exposed externally via Front Door.</td></tr></tbody></table>

**Internal MCP Services**

These containers run in a shared internal environment (`env-internal-mcp`) and are not exposed to the public internet. They provide Model Context Protocol (MCP) capabilities to the orchestrator.

<table><thead><tr><th width="170">Container App</th><th>Description</th></tr></thead><tbody><tr><td>mcp-db</td><td>The MCP database hub. Exposes database query and schema inspection capabilities over HTTP (port 3002), backed by a dedicated PostgreSQL instance. Allows the orchestrator to interact with structured data sources via MCP.</td></tr><tr><td>mcp-365</td><td>The Microsoft 365 MCP server. Provides organizational data and authentication tools from Microsoft 365 (Exchange, SharePoint, Teams) to the orchestrator over HTTP (port 3001).</td></tr><tr><td>mcp-playwright</td><td>The Playwright MCP server. Provides browser automation capabilities (web scraping, interaction, screenshots) to the orchestrator over HTTP (port 3000). Allocated higher resources (1 CPU, 2 GiB memory) due to headless browser requirements.</td></tr></tbody></table>

**RAG Stack**

These containers run in a dedicated internal environment (`env-rag`) with private DNS resolution to the orchestrator's virtual network.

<table><thead><tr><th width="178">Container App</th><th>Description</th></tr></thead><tbody><tr><td>qdrant</td><td>A <a href="https://qdrant.tech/">Qdrant</a> vector database instance used for semantic search and retrieval-augmented generation. Stores document embeddings on a persistent Azure Files volume. Internal-only ingress on port 6333.</td></tr><tr><td>rag</td><td>The RAG and MCP service. Handles document ingestion, embedding generation (via Azure OpenAI), vector storage in Qdrant, and semantic retrieval. Also connects to Document Intelligence for document parsing and MongoDB for metadata. Exposed to the orchestrator via internal DNS.</td></tr></tbody></table>

**Observability**

These containers run in a shared metrics environment (`env-metrics`) and provide monitoring dashboards and telemetry collection.

<table><thead><tr><th width="183">Container App</th><th>Description</th></tr></thead><tbody><tr><td>grafana</td><td>A <a href="https://grafana.com/">Grafana</a> instance for visualizing platform metrics and dashboards. Pre-provisioned with a Prometheus data source and a DORG orchestrator dashboard. Backed by PostgreSQL for session and dashboard storage, with persistent file storage on Azure Files. Exposed externally via Front Door on the metrics subdomain.</td></tr><tr><td>otel-collector</td><td>An <a href="https://opentelemetry.io/docs/collector/">OpenTelemetry Collector</a> (contrib distribution) that scrapes the orchestrator's <code>/metrics</code> endpoint and exports metrics in Prometheus format on port 9464. Internal-only; not directly accessible.</td></tr><tr><td>prometheus</td><td>A <a href="https://prometheus.io/">Prometheus</a> instance that scrapes the OpenTelemetry Collector and stores time-series data on an Azure Files volume. Internal-only; used as a data source by Grafana.</td></tr></tbody></table>

#### Environment Grouping

All containers are deployed across five Azure Container Apps managed environments:

<table><thead><tr><th width="206">Environment</th><th>Containers</th><th>Network</th></tr></thead><tbody><tr><td><code>env-orch</code></td><td>orchestrator, dashboard-gateway, dashboard-web</td><td>External (Front Door)</td></tr><tr><td><code>env-auth</code></td><td>keycloak</td><td>External (Front Door)</td></tr><tr><td><code>env-internal-mcp</code></td><td>mcp-db, mcp-365, mcp-playwright</td><td>Internal (VNet only)</td></tr><tr><td><code>env-rag</code></td><td>qdrant, rag</td><td>Internal (private DNS)</td></tr><tr><td><code>env-metrics</code></td><td>grafana, otel-collector, prometheus</td><td>Mixed (Grafana external via Front Door; others internal)</td></tr></tbody></table>

#### Tips

* Real-time logs: Use Log stream in the Azure Portal for live tail of container output.
* Historical logs: Use Logs in the Azure Portal to run KQL queries against the Log Analytics workspace for past events across all containers.
* Grafana dashboards: For ongoing metric monitoring, use the Grafana instance accessible via the metrics subdomain.
* Increase verbosity: If troubleshooting requires more detail, update the `LOG_LEVEL` environment variable to `debug` (or `Debug` for .NET containers) in the Pulumi configuration and redeploy the affected container.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.dorg.pro/install-dorg/troubleshooting/application-logs.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.