# Which Problems Are Solved
Streams allow differentiating logs produced by different components of
Zitadel.
# How the Problems Are Solved
The `backend/v3/instrumentation/logging` package now exposes convenience
function for setting and getting a logger from the context. As well as
high-level functions to emit log records at various levels. When
constructing a new logger a "stream" needs to be specified:
- **runtime**: General runtime logs, such as startup and shutdown
messages. Default for logs that do not belong to the other categories.
- **request**: Logs for incoming API and HTTP requests.
- **event_handler**: Logs for event handling in projections.
- **queue**: Logs for the job queue processing.
- **event_pusher**: Logs for event pushing to the database. Disabled by
default, contains sensitive information.
Each line from the returned logger contains a `stream` field as well as
a `version` field with the current Zitadel version.
## Runtime config
Streams can be enabled by passing an array of stream names in the
runtime config. Because some log streams may contain sensitive data
(especially events), it is now also possible to mask values by their
key.
# Additional Changes
- Wrap `slogctx` in the `logging` package. (Except API error converter
packages, because of import cycle)
- Add some docs to `logging` package so other devs understand how to add
logging to Zitadel
- Add `logging.OnError` and `logging.WithError` helper functions with
`Panic()` and `Fatal()` methods, to preserve current calls in the `cmd`
packages.
- Add instance context extractor.
- Only output request details in the request info log. Request ID
remains propagated through context.
- Moved middleware functionality into protocol specific packages.
- Removed setting of URI to context in metric middleware. There were ony
setters and no getters. (Unused value)
- Reuse a single statusWriter in the middleware package for middlewares
that need to know the response status.
# Additional Context
- Closes#11333
- Closes#11331
- Partly #11330
---------
Co-authored-by: Silvan <[email protected]>
This pull request addresses an issue where ZITADEL's initialization
process could fail in environments with restricted database permissions,
such as managed database services (e.g., Google Cloud SQL, Amazon RDS,
Azure PostgreSQL).
## Which problem is solved
Previously, `zitadel init` (and its sub commands) and `zitadel
start-from-init` commands would attempt to execute `CREATE DATABASE`,
`CREATE USER`, and `GRANT` statements. These commands often fail if the
provided database user lacks superuser privileges, which is a common
security practice in hosted database environments.
## How the problem is solved
With this change, Zitadel is now smarter during initialization. It
checks if the database and user specified in your configuration already
exist and are accessible. If they are, ZITADEL will skip the creation
and grant commands, allowing for a seamless setup even with a
less-privileged database user.
## Additional information
closes#10730
closes https://github.com/zitadel/zitadel/issues/8198
### How to leverage this feature (skip admin commands)
To have ZITADEL skip the database administration commands, you need to
configure it so that the initialization process can use the
already-existing database and user. This is achieved by pointing the
admin access in your ZITADEL configuration to the user and database that
ZITADEL will use for its operations.
In your ZITADEL configuration file (e.g., zitadel.yaml), configure the
Database section as follows:
```yaml
Database:
Postgres:
Database: existing_database
# Admin credentials should be the same as the application user credentials
Admin:
User: zitadel-user
ExistingDatabase: existing_database # this is used to connect the admin to the previously created database
# Application user credentials
User:
User: zitadel-user
```
---------
Co-authored-by: Marco A. <[email protected]>
This implementation increases parallel write capabilities of the eventstore.
Please have a look at the technical advisories: [05](https://zitadel.com/docs/support/advisory/a10005) and [06](https://zitadel.com/docs/support/advisory/a10006).
The implementation of eventstore.push is rewritten and stored events are migrated to a new table `eventstore.events2`.
If you are using cockroach: make sure that the database user of ZITADEL has `VIEWACTIVITY` grant. This is used to query events.
