The release is out, the Change Advisory Board has signed off, and the next morning the business unit reports that claims submissions are stuck. There are logs in Elasticsearch, but the Quarkus services write them differently than the Spring Boot services, and not a single line reveals the version. Anyone running Quarkus and Spring Boot side by side therefore needs shared conventions for logs, metrics and version information. Using an insurer as an example, we show how both frameworks deliver their data to Elasticsearch and how Grafana turns it into a verifiable criterion for every release.<\/p>\n
The landscape we encounter at insurers has grown over time. Older business services for contract management and policy administration run on Spring Boot, newer services for claims submission or rate calculators run on Quarkus. Both run in containers on Kubernetes or OpenShift. Elasticsearch is set as the central log store and has been approved by information security, and Grafana serves as the interface for operations.<\/p>\n
Releases run in fixed windows. Every change goes through a Change Advisory Board, or CAB for short: a body that assesses the risk and rollback plan of a deployment before it is allowed into production. Today the CAB reviews documents, but no measurements from live operations.<\/p>\n
On top of this comes regulation. Since January 2025, the EU regulation DORA applies to insurers. Its Article 10 requires mechanisms that promptly detect anomalous activities and performance issues of ICT systems (Regulation (EU) 2022\/2554<\/a>). Monitoring that only reacts once the business unit raises the alarm does not meet this standard.<\/p>\n Both frameworks come with good tooling, but use it with different default settings. Spring Boot writes text logs in its own pattern, Quarkus writes a different one via JBoss Logging. Filebeat reads both as unstructured text, and Elasticsearch ends up with a The situation with metrics is similar. Both frameworks measure via Micrometer, the shared metrics library of the Java world, and expose the values in Prometheus text format. Quarkus does this under The third problem concerns security. By default, the endpoints for metrics and health checks are exposed on the same port as the business API. Anyone who can reach the API can therefore also reach the operational data. For a DevSecOps approach \u2014 that is, security as an integral part of development and operations \u2014 this is a finding.<\/p>\n Finally, insurance logs contain personal data. Policy numbers, names, or, in the case of health and life insurance, health-related information slip into the logs via debug output. Once this data is in Elasticsearch, the same protection requirements apply to the index as to the policy administration system.<\/p>\n The target picture is simple: both frameworks write logs in the same schema, expose metrics on a separate port and carry the version in every record. Elasticsearch stores logs and metrics, Grafana shows both side by side and checks the release. The configurations are written for Spring Boot 3.5, Quarkus 3.20, Elasticsearch, Filebeat and Metricbeat 8.18, and Grafana 12.1.<\/p>\n In Quarkus, the management interface separates the operational endpoints from business traffic. This is a second HTTP server that exposes health, metrics and info endpoints on port 9000 (Quarkus Management Interface<\/a>). The extensions In Spring Boot, ECS stands for Elastic Common Schema, a fixed field schema in which HTTP status codes show technical errors, but not business ones. A claims submission that fails the plausibility check still returns status 200. The development teams count such events themselves. The code is identical in both frameworks; only the bean annotation differs: In Prometheus format the counter is named Filebeat reads the container logs, parses the JSON lines and enriches them with Kubernetes metadata (Filestream Input<\/a>).<\/p>\nWhy Quarkus and Spring Boot diverge in operations<\/h2>\n
message<\/code> field in which timestamp, level and content are mixed together. Searching for all errors of a service in a specific version is not possible this way.<\/p>\n\/q\/metrics<\/code>, Spring Boot via Actuator under \/actuator\/prometheus<\/code>. Often no one collects the values, because a dedicated Prometheus would be another platform that has to be operated and approved.<\/p>\nBringing Quarkus and Spring Boot to the same conventions<\/h2>\n
flowchart LR\n Q[Quarkus-Service] -- ECS-JSON auf stdout --> F[Filebeat]\n S[Spring-Boot-Service] -- ECS-JSON auf stdout --> F\n Q -- Port 9000 \/q\/metrics --> M[Metricbeat]\n S -- Port 8081 \/actuator\/prometheus --> M\n F --> E[Elasticsearch]\n M --> E\n E --> G[Grafana]\n G --> R[Release-Gate im Rollout]<\/code><\/pre>\nStep 1: Configure Quarkus and Spring Boot the same way<\/h2>\n
quarkus-micrometer-registry-prometheus<\/code>, quarkus-smallrye-health<\/code> and quarkus-logging-json<\/code> are required. Quarkus provides the ECS format directly (Quarkus Logging<\/a>).<\/p>\n# application.properties (Quarkus)\nquarkus.application.name=schadenmeldung\nquarkus.management.enabled=true\nquarkus.log.console.json.enabled=true\nquarkus.log.console.json.log-format=ecs\nquarkus.log.console.json.mdc.flat-fields=true\n%dev.quarkus.log.console.json.enabled=false\n%test.quarkus.log.console.json.enabled=false<\/code><\/pre>\nmanagement.server.port<\/code> handles the separation; the prerequisites are spring-boot-starter-actuator<\/code> and micrometer-registry-prometheus<\/code>. Structured logging in ECS format has been available since Spring Boot 3.4 (Spring Boot Logging<\/a>). We set the version explicitly from the Maven build so that it does not depend on the manifest.<\/p>\n# application.yaml (Spring Boot)\nspring:\n application:\n name: vertragsverwaltung\nmanagement:\n server:\n port: 8081\n endpoints:\n web:\n exposure:\n include: health,prometheus\nlogging:\n structured:\n format:\n console: ecs\n ecs:\n service:\n version: "@project.version@"\n environment: production<\/code><\/pre>\nlog.level<\/code>, service.name<\/code> and service.version<\/code> have the same names in both frameworks. The network policy in the cluster only allows ports 9000 and 8081 for Metricbeat.<\/p>\nStep 2: Business metrics with Micrometer<\/h2>\n
@ApplicationScoped<\/code> in Quarkus, @Component<\/code> in Spring Boot.<\/p>\nimport io.micrometer.core.instrument.Counter;\nimport io.micrometer.core.instrument.MeterRegistry;\nimport jakarta.enterprise.context.ApplicationScoped;\n\n@ApplicationScoped\npublic class SchadenmeldungMetriken {\n\n private final Counter abgelehnt;\n\n public SchadenmeldungMetriken(MeterRegistry registry) {\n this.abgelehnt = Counter.builder("schadenmeldung.abgelehnt")\n .description("Schadenmeldungen, die die Plausibilit\u00e4tspr\u00fcfung nicht bestehen")\n .tag("sparte", "kfz")\n .register(registry);\n }\n\n public void abgelehnt() {\n abgelehnt.increment();\n }\n}<\/code><\/pre>\nschadenmeldung_abgelehnt_total<\/code>. Tags such as sparte<\/code> should stay limited to a few fixed values. Using a policy number as a tag would blow up the number of time series and carry personal data into the metric store.<\/p>\nStep 3: Logs to Elasticsearch with Filebeat<\/h2>\n
# filebeat.yml\nfilebeat.inputs:\n - type: filestream\n id: java-services\n paths:\n - \/var\/log\/containers\/*.log\n parsers:\n - container:\n stream: all\n format: auto\n - ndjson:\n target: ""\n overwrite_keys: true\n expand_keys: true\n add_error_key: true\n\nprocessors:\n - add_kubernetes_metadata:\n host: ${NODE_NAME}\n matchers:\n - logs_path:\n logs_path: "\/var\/log\/containers\/"\n - drop_fields:\n fields: ["<FELD_MIT_PERSONENBEZUG>"]\n ignore_missing: true\n\noutput.elasticsearch:\n hosts: ["https:\/\/<ELASTICSEARCH_HOST>:9200"]\n api_key: "${ES_API_KEY}"\n ssl.certificate_authorities: ["\/etc\/filebeat\/certs\/ca.crt"]<\/code><\/pre>\n