Logs¶

Where to find the logs¶

Each service writes its log to its container's output, which Docker stores. With Docker's default logging, Docker deletes the log when it removes the container. Recreating the backend after a configuration change therefore starts a new log. From deploy/:

docker compose logs -f backend

Use frontend or postgres for the other services. Add --tail 100 or --since 10m to read only the latest lines. Read the backend log first because it contains plintz's own messages. The frontend log contains nginx access and error messages. The postgres log contains PostgreSQL messages.

What is logged¶

The backend logs:

Startup and requests. Uvicorn logs when the server starts and writes one line per request, such as INFO: <client> - "POST /api/samples HTTP/1.1" 200 OK. A request without a session returns status 401.
Startup failures. The backend logs a traceback. Its last line names the problem. See When startup fails.
plintz's own messages. plintz logs warnings and errors without a timestamp or level. An error is followed by its traceback. It does not log successful operations, so a successful Indexing run produces no line.

These messages indicate:

Message	Meaning
`Indexing of Datasource 'x' failed`, with a traceback	Indexing of that Datasource failed, and it kept its previous index. The traceback ends with the cause. See When a Datasource fails.
`startup Indexing failed` or `scheduled Indexing failed`, with a traceback	The whole run failed, not one Datasource, for example because Postgres couldn't be reached. The next scheduled run tries again.
`Datasource 'x': Stored Signal 'id' goes to the Trash: …`	One Stored Signal has an Interpolation Method or Maximum Interpolation that plintz doesn't accept. Indexing leaves it out and moves it to the Trash, but indexes the rest of the Datasource.
`Databricks metadata table <table>: Stored Signal 'id' left out: …`	A row of the metadata table has no Data ID, no name, or a Maximum Interpolation that isn't a duration. Indexing leaves out that Stored Signal, but continues with the rest.
`Databricks Datasource 'x' rejected query tags, so its queries run untagged: …`	Databricks rejected the query tags. The queries and their results are unaffected, but not attributed. Logged once per Datasource, each time the backend starts.
`unreadable cache block file <path>: …` or `cache block file <path> doesn't match its index`	A block's file in the block cache can't be used. plintz fetches that block again, so no result is wrong. If it repeats, check the `block-cache` volume.
`could not start an OIDC login: …`	Users who tried to sign in saw "login failed: the identity provider is unavailable or misconfigured". Check `oidc` in `plintz.yaml` and that the backend can reach the provider. See Sign-in.
`OIDC login failed: …`	The provider's response to one user's sign-in was refused, and they saw a 401. The message says why.