cromeroprofile/spring-boot-monitoring

1. This repo is a small Spring Boot 3 application written in Kotlin, focused on observability rather than business logic. The only visible application source file is KotlinMvcApplication.kt, which suggests a thin MVC entrypoint backed mostly by framework auto-configuration.

2. The application runtime is configured through two main files:

- src/main/resources/application.properties for Spring/Micrometer/Actuator behavior

- src/main/resources/logback-spring.xml for log shipping and log correlation

These two files are central to how the app emits telemetry.

3. The application’s request path is the standard Spring MVC layer: incoming HTTP traffic hits the Spring Boot app, which produces three observability signals from the same request context:

- metrics via Actuator/Micrometer

- distributed traces via Micrometer Tracing + Brave

- logs via Logback with trace context injected into the log pattern

4. Metrics flow from the app to Prometheus. Spring Boot exposes an /actuator/prometheus endpoint, and Prometheus scrapes it according to docker/prometheus/prometheus.yml. The README indicates histogram/percentile data is enabled so Prometheus samples can include trace_id/span_id exemplars.

5. Traces flow from the app to Grafana Tempo. The repo uses Zipkin-compatible tracing export (zipkin-reporter-brave in the README) and Tempo is configured to receive Zipkin-format spans. This makes Tempo the trace store for request-level latency and span inspection.

6. Logs flow from the app to Grafana Loki. logback-spring.xml configures a Loki appender, and the log pattern includes labels such as application name, host, log level, class, and importantly traceID. That trace label is what enables log-to-trace correlation.

7. Grafana is the read side of the system. It does not collect data itself; it queries the three backends:

- Prometheus for metrics

- Tempo for traces

- Loki for logs

The provided dashboard is centered on “Logs, Traces, Metrics” as a single observability view.

8. Correlation is the key architectural idea in this repo. The same trace context is propagated across metrics, logs, and traces, so a user can move from a metric exemplar to a trace, then jump from that trace into related logs. The README explicitly frames trace_id as the join key across all layers.

9. docker-compose.yml is the infrastructure boundary for the whole stack. It starts the observability services locally, so the application and the monitoring stack can be run as a self-contained demo environment without external dependencies.

10. The configuration files under docker/ are operationally important:

- Grafana provisioning files prewire datasources and dashboards

- Prometheus config defines scrape behavior

- Tempo config defines the tracing receiver/storage behavior

- Grafana provisioning auto-loads the dashboard and datasource setup

This means the repo is designed for repeatable local startup, not manual UI setup.

11. The project uses Maven (pom.xml) as the build and dependency manager. The README highlights the key dependencies that shape architecture: Spring Boot Actuator, Micrometer Prometheus registry, Micrometer Tracing with Brave, Zipkin reporter, and Loki4j Logback appender.

12. In diagram terms, the main boundaries are:

- client/request traffic into Spring Boot MVC

- telemetry egress from the app to Prometheus, Tempo, and Loki

- Grafana as the visualization/query layer over those stores

- Docker Compose as the environment orchestrator that ties everything together