Observability: Centralized Logging

The Jmix REST Data Store provides an easy way to connect two Jmix applications using a REST API. The Portal fetches data such as Pet and Visit entities from the Petclinic backend without persisting or managing the data itself.

By splitting things up this way, we can deploy the Portal as a public-facing app with its own login system — like social login. At the same time, we don’t have to expose the full backend to the internet. Instead, we just expose a focused set of features, so users get exactly what they need without opening up the whole system.

The Petclinic Portal uses a fully customized layout that intentionally deviates from the typical look of a business application. Instead of relying on standard Jmix or Vaadin UI components, the layout mimics elements of modern websites — including scrollable views, card-based presentation, and visually grouped sections.

We use a Fragment to represent each Pet entity visually as a card component. Each card displays key information such as the pet’s name, type, birthdate, and offers a button to navigate to the detail view.

The visual appearance of the cards is defined using a custom CSS file. While it reuses selected Lumo theme variables for consistency (e.g., spacing, colors, border radius), the styles themselves are custom-defined and not based on Vaadin components. Let’s create a dedicated file under src/main/frontend/themes/jmix-petclinic-portal/view/pet-card.css:

Cards are dynamically created when the Pet data is loaded into the Pet List View by reacting to a CollectionContainer.CollectionChangeEvent on the data container.

This event listener allows us to rebuild the card layout each time the set of loaded pets changes.

With both the Petclinic backend and the Portal application up and running, we now turn our attention to observability. Specifically, we want to see how to equip both applications with centralized logging.

Structured logging refers to writing logs in a machine-readable format such as JSON or key-value pairs, rather than plain text messages. This makes it significantly easier for centralized logging systems to parse, index, and query logs efficiently.

With structured logs, fields like userId, petId, or errorType can be used directly in queries, enabling fast and precise troubleshooting. It also supports advanced use cases such as automated detection and masking of sensitive information (PII) and correlating events across distributed systems.

Here’s an example of a structured log entry in JSON format:

In contrast, a traditional log entry using a default Logback console appender might look like this:

In the unstructured format, the petId is embedded somewhere in the message string — for example after a colon, or within a phrase like 'with ID'. Because log messages vary widely in wording and structure, it’s nearly impossible for automated systems to reliably extract such values from plain text logs.

With structured logging, fields like petId are explicitly available, so we can filter and search for all logs related to a specific entity — something that’s critical for debugging and monitoring distributed systems.

To fully benefit from centralized logging, applications should produce structured logs natively. Structured data makes it possible to query specific fields and build rich, user-specific dashboards across distributed systems.

In our petclinic example, we will use Spring Boot’s OpenTelemetry support to export structured logs from the applications and send them to the centralized logging backend.

In this guide, Loki stores and queries the application logs, while Grafana provides the user interface for exploring them.

Unlike the Elastic Stack (ELK), which indexes the full content of log messages, Loki only indexes a small set of pre-defined labels (like app, env, or service) and stores the actual log content separately. This design makes Loki much more efficient in terms of storage and memory usage, while still enabling powerful filtering and search capabilities for common queries.

Loki is part of the broader Grafana observability stack alongside Tempo for distributed tracing and Prometheus for metrics. For the local observability environment, this guide introduces the Grafana OpenTelemetry LGTM stack instead of configuring and running the Collector, Loki, and Grafana as separate services.

The OpenTelemetry Collector receives telemetry, optionally processes it, and forwards it to one or more backends. The Collector included in the LGTM image is already configured to accept OTLP logs and write them to the bundled Loki instance.

As a result, this sample does not need a custom otelcol-config.yaml. We only need to point the applications to the Collector endpoint.

The endpoint in application.properties uses localhost:4318, which is correct when the applications run from Jmix Studio or through Gradle and the LGTM container runs on the same machine.

When the applications run as Docker containers, localhost refers to the application container itself. The Compose configuration therefore overrides the endpoint with the internal lgtm service address:

Both application services use the same override and send their logs to the Collector inside the LGTM container.

The screenshot above shows a unified view in Grafana’s Log UI. Each application appears as a separate service label (jmix-petclinic and jmix-petclinic-portal). As we can see both applications started logging into Loki.

This view highlights one of the key benefits of centralized logging: we can monitor all applications from a single place and quickly switch between them to inspect log streams, without jumping through multiple interfaces or terminals.

If we drill into one of the services, like jmix-petclinic-portal, Grafana shows a list of all log entries for that service. The active filter at the top indicates that logs are scoped to this specific service (service_name = jmix-petclinic-portal). We can search for keywords in the logs, apply field-based filters, and inspect individual entries.

After getting an overview of all logs per application, we can drill down into the individual log entries to explore the structured data we’ve configured.

The screenshot below shows the details of a specific log line emitted by the jmix-petclinic-portal application:

We can see the original log message body, along with various fields that were automatically extracted by the logging pipeline. These fields include standard ones like level, service_name, and timestamp, as well as application-specific MDC fields like attributes_logback_ownerId and attributes_logback_jmixUser.

The ownerId field was added in the source code before the log statement using MDC (Mapped Diagnostic Context):

By adding context such as the current user’s ID to each log entry, we enable precise filtering in Grafana — making it much easier to troubleshoot and trace events back to specific users or actions.

To dive deeper into MDC and how to enrich your logs with contextual information, see our introduction guide on logging: Application Logging in Jmix: Context Information in Logs.

While centralized logging gives us great visibility into logs across multiple services, we still lack a mechanism to link related log entries across applications. What’s missing is a correlation mechanism that ties together the full execution path of a request.

This is exactly the use case for distributed tracing — a topic we’ll dive into in the next part of this series.