Learn Spring Boot - Logging, Metrics & Health

#Introduction

An application that can't be monitored is a black box — when something goes wrong in production, you can only guess. Episode 9 pulls back the curtain with logging, metrics, and health: the three things that make your application observable.

You'll learn to write proper logs with Logback, expose Actuator endpoints for health checks and metrics, and export metrics to Prometheus through Micrometer. This is the foundation that will be deepened in episode 22 on observability.

#Logging with Logback

#Log Levels and Format

Spring Boot uses Logback as its default logging framework. Log levels — from most important: ERROR, WARN, INFO, DEBUG, TRACE — are controlled via configuration. In the application, use a Logger from SLF4J:

@Service
public class ItemService {
 
    private static final Logger log =
            LoggerFactory.getLogger(ItemService.class);
 
    public Item create(Item item) {
        log.info("Membuat item baru: {}", item.getName());
        return repository.save(item);
    }
}

The log.info("teks {}", nilai) form uses the {} placeholder — avoid wasteful string concatenation that messes up the format. Logs carry useful context for tracking down problems.

#Logback Configuration in application.yml

Set log levels and output through configuration:

logging:
  level:
    root: INFO
    com.example: DEBUG
  file:
    name: logs/aplikasi.log
  pattern:
    console: "%d{yyyy-MM-dd HH:mm:ss} %-5level %logger{36} - %msg%n"

With this configuration, the application writes logs to the console and to the file logs/aplikasi.log. The com.example level is set to DEBUG for detail during development. For production, get into the habit of structured logging — JSON format — so log aggregators can process it easily, as covered in episode 22.

#Spring Boot Actuator

#Adding and Securing Actuator

Actuator brings production endpoints that show the application's condition. Add the dependency:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

Actuator also needs access configuration — by default only health is exposed:

management:
  endpoints:
    web:
      exposure:
        include: health,info,metrics,env
  endpoint:
    health:
      show-details: always

#Health Checks and Other Endpoints

The health check is the most important endpoint for orchestrators like Kubernetes:

curl http://localhost:8080/actuator/health

The curl http://localhost:8080/actuator/health command returns the overall status along with component details such as disk and database. Other endpoints available: info for application metadata, metrics for the metric list, and env for environment properties.

#Custom Actuator Endpoints and Metrics

#Custom Health Indicator

When the application depends on an external service, create your own health indicator:

@Component
public class ExternalApiHealthIndicator
        implements HealthIndicator {
 
    @Override
    public Health health() {
        boolean up = checkExternalApi();
        return up
                ? Health.up().build()
                : Health.down().withDetail("reason",
                        "API eksternal tidak responsif").build();
    }
}

This health indicator will appear as a component at /actuator/health under the name externalApi. Orchestrators like Kubernetes use it to decide when the application is considered healthy.

#Micrometer and Prometheus

Micrometer is a metrics facade that collects metrics from the JVM and the application, then exports them to a monitoring system. For Prometheus, add the dependency:

<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-prometheus</artifactId>
</dependency>

The actuator/prometheus endpoint now exposes metrics in the format Prometheus understands:

curl http://localhost:8080/actuator/prometheus | grep http_server_requests

The curl http://localhost:8080/actuator/prometheus | grep http_server_requests command shows the HTTP request count metric along with status code and duration. Prometheus can scrape this endpoint periodically, and the metrics are visualized in Grafana.

#Observability Best Practices

Some habits that make observability work in production:

• Log at the right level: ERROR for failures, INFO for important activity, DEBUG for detail.
• Don't log secrets — passwords and tokens must never appear in logs.
• Expose health, info, and metrics via Actuator; limit env and beans to trusted environments.
• Use Micrometer for all custom metrics so they're consistent with JVM metrics.
• Integrate tracing (episode 22) so requests can be followed across services.

Logging -> know what happened
Metrics -> know how many and how fast
Health -> know if the application is healthy

#Closing

Episode 9 equipped you with basic observability: logging with Logback, Actuator endpoints for health and metrics, custom health indicators, and Micrometer integration with Prometheus for an application that can be monitored in production.

Key takeaways:

• Use SLF4J with {} placeholders, not string concatenation.
• Actuator provides the health, info, metrics, and env endpoints.
• /actuator/health is the primary health status source for Kubernetes.
• Custom health indicators report the health of external dependencies.
• Micrometer exports metrics to Prometheus via the actuator/prometheus endpoint.
• Never write secrets to logs.

In the next episode, episode 10, we'll discuss transactions and advanced persistence — transaction management with @Transactional, propagation and isolation levels, lazy loading and JPA performance tuning, and schema migration with Flyway or Liquibase.