OpenShift Logging Overview

Learn how logging works in OpenShift, understand cluster logging architecture, centralized log collection, Spring Boot logging, Fluentd, Vector, Loki, Elasticsearch, Kibana, and enterprise logging best practices.

Introduction

Imagine your Spring Boot application is running perfectly in OpenShift.

Suddenly, users report:

Login failures
Payment errors
API timeouts
Database connection issues
Memory problems

How do you investigate?

You cannot log in to every Pod because:

Pods are ephemeral
Pods restart frequently
Multiple replicas generate logs simultaneously
Old Pods disappear after deployment

This is why enterprise applications use Centralized Logging.

Instead of storing logs inside individual Pods, OpenShift collects logs from every container and stores them in a centralized logging platform for searching, monitoring, and troubleshooting.

Learning Objectives

By the end of this article, you will understand:

Why centralized logging is required
OpenShift Logging Architecture
Application Logs
Infrastructure Logs
Audit Logs
Log Collectors
Log Storage
Spring Boot Logging
Enterprise Best Practices

Why Centralized Logging?

Without centralized logging:

flowchart LR
    A[Pod 1]
    B[Pod 2]
    C[Pod 3]

    A --> D[Local Logs]
    B --> E[Local Logs]
    C --> F[Local Logs]

Problems:

Logs disappear when Pods restart.
Difficult to search logs.
No cluster-wide visibility.
Hard to troubleshoot distributed applications.

Centralized Logging

flowchart LR
    A[Pod 1]
    B[Pod 2]
    C[Pod 3]

    D[Log Collector]

    E[Log Store]

    F[Dashboard]

    A --> D
    B --> D
    C --> D

    D --> E
    E --> F

Every log is collected automatically.

Logging Architecture

flowchart LR
    A[Spring Boot Pods]
    B[Node Log Collector]
    C[Log Storage]
    D[Visualization]

    A --> B
    B --> C
    C --> D

OpenShift Logging Stack

A typical logging stack consists of:

Component	Responsibility
Spring Boot	Generates logs
Vector / Fluentd	Collects logs
Loki / Elasticsearch	Stores logs
Grafana / Kibana	Searches and visualizes logs

Log Collection Flow

flowchart LR
    A[Spring Boot]
    B[Container stdout]
    C[Vector Collector]
    D[Loki]
    E[Grafana]

    A --> B
    B --> C
    C --> D
    D --> E

Types of Logs

OpenShift manages three major categories of logs.

Log Type	Description
Application Logs	Generated by applications
Infrastructure Logs	Generated by OpenShift components
Audit Logs	Security and API activities

Application Logs

Generated by:

Spring Boot
Node.js
Python
Go
.NET

Example

2026-07-01 10:15:23

Payment Created

TransactionId=TX12345

Infrastructure Logs

Generated by:

API Server
Scheduler
Controller Manager
Router
Kubelet
CRI-O

These logs help troubleshoot cluster issues.

Audit Logs

Audit logs record security-sensitive events.

Examples:

User Login
API Calls
Secret Access
Deployment Creation
RBAC Changes

Example

User admin

Created Deployment payment-api

Logging Architecture Overview

flowchart TD
    A[Application Logs]
    B[Infrastructure Logs]
    C[Audit Logs]

    D[Vector Collector]

    E[Loki]

    F[Grafana]

    A --> D
    B --> D
    C --> D

    D --> E
    E --> F

Spring Boot Logging

Spring Boot uses Logback by default.

Example

private static final Logger log =
LoggerFactory.getLogger(PaymentService.class);

log.info("Payment Created");

log.error("Database Connection Failed");

Logging Levels

Level	Purpose
TRACE	Detailed execution
DEBUG	Development
INFO	Business events
WARN	Recoverable problems
ERROR	Application failures

Logging Best Practice

Log business events.

log.info(
"Payment {} processed for customer {}",
paymentId,
customerId
);

Avoid logging sensitive data.

Do Not Log

Never log:

Passwords
Credit Card Numbers
OTPs
JWT Tokens
API Keys

❌ Bad

log.info(password);

✅ Good

log.info("User Login Successful");

Spring Boot Logging Flow

flowchart LR
    A[Spring Boot]
    B[Logback]
    C[stdout]
    D[Vector]
    E[Loki]

    A --> B
    B --> C
    C --> D
    D --> E

Structured Logging

Instead of

Payment Completed

Prefer

{
  "transactionId":"TX1001",
  "customerId":"C101",
  "status":"SUCCESS",
  "amount":250
}

Structured logs are easier to search.

JSON Logging Architecture

flowchart LR
    A[Application]
    B[JSON Logs]
    C[Vector]
    D[Loki]
    E[Grafana]

    A --> B
    B --> C
    C --> D
    D --> E

Banking Example

flowchart TD
    A[Payment Service]
    B[Customer Service]
    C[Notification Service]

    D[Vector]

    E[Loki]

    F[Grafana Dashboard]

    A --> D
    B --> D
    C --> D

    D --> E
    E --> F

Operations teams can search logs across all microservices.

Log Retention

Typical enterprise policy:

Environment	Retention
Development	7 Days
QA	30 Days
Production	90-365 Days
Audit Logs	1-7 Years

Useful Commands

View Pod Logs

oc logs payment-api

Follow Logs

oc logs -f payment-api

Previous Container Logs

oc logs payment-api --previous

List Pods

oc get pods

Describe Pod

oc describe pod payment-api

Troubleshooting Workflow

flowchart LR
    A[User Reports Issue]
    B[Search Logs]
    C[Identify Error]
    D[Fix Application]
    E[Redeploy]

    A --> B
    B --> C
    C --> D
    D --> E

Enterprise Logging Architecture

flowchart TD
    A[Spring Boot Services]
    B[OpenShift Nodes]
    C[Vector Collectors]
    D[Loki Cluster]
    E[Grafana]
    F[Operations Team]

    A --> B
    B --> C
    C --> D
    D --> E
    E --> F

Common Problems

Missing Logs

Possible causes:

Pod restarted
Collector unavailable
Logging disabled

Duplicate Logs

Possible causes:

Multiple collectors
Incorrect configuration

Large Log Files

Solution:

Rotate logs
Reduce DEBUG logging
Use INFO in production

Sensitive Data Logged

Immediately:

Remove sensitive logging
Rotate affected credentials
Review security policies

Production Best Practices

Log to stdout instead of files.
Use structured JSON logging.
Include correlation IDs.
Use appropriate log levels.
Never log sensitive information.
Centralize all application logs.
Configure log retention policies.
Monitor log storage usage.
Aggregate logs across microservices.
Secure access to log platforms.

Common Mistakes

❌ Logging passwords.

❌ Writing logs to local files inside containers.

❌ Using DEBUG logging in production.

❌ Ignoring log retention.

❌ Logging stack traces for every request.

❌ Creating inconsistent log formats.

Advantages

Centralized troubleshooting
Faster incident response
Better compliance
Improved observability
Easier debugging
Cluster-wide visibility
Secure log storage
Enterprise-ready operations

Summary

Centralized logging is an essential part of operating Spring Boot applications on OpenShift.

Key takeaways:

OpenShift collects application, infrastructure, and audit logs.
Vector or Fluentd forwards logs to centralized storage such as Loki or Elasticsearch.
Grafana or Kibana provides powerful search and visualization capabilities.
Spring Boot applications should log to stdout using structured logging.
Secure, centralized logging improves troubleshooting, compliance, and operational visibility.

Interview Questions

Why is centralized logging important in OpenShift?
What are the three major types of logs in OpenShift?
Why should Spring Boot applications log to stdout?
What is the role of Vector or Fluentd?
What is the difference between Loki and Elasticsearch?
Why is structured JSON logging preferred?
What information should never be logged?
How do you view logs from a running Pod?
What are correlation IDs and why are they useful?
What are the production best practices for logging in OpenShift?