Logging

OpenShift provides some convenient mechanisms for viewing application logs. First and foremost is the ability to examine a Pod's logs directly from the web console or via the command line.

Background: Container Logs

OpenShift is constructed in such a way that it expects containers to log all information to STDOUT. In this way, both regular and error information is captured via standardized Docker mechanisms. When exploring the Pod's logs directly, you are essentially going through the Docker daemon to access the container’s logs, through OpenShift’s API.

In some cases, applications may not have been designed to send all of their information to STDOUT and STDERR. In many cases, multiple local log files are used. While OpenShift cannot parse any information from these files, nothing prevents them from being created, either. In other cases, log information is sent to some external system. Here, too, OpenShift does not prohibit these behaviors. If you have an application that does not log to STDOUT, either because it already sends log information to some "external" system or because it writes various log information to various files, fear not.

Exercise: Examining Logs

Since we already deployed our application, we can take some time to examine its logs. From Workloads → Topology, click the parksmap entry and then the Resources tab in the side panel. You should see a View logs link next to the Pod entry.

View logs for Pod

Click the View logs link and you should see a nice view of the Pod's logs:

Application Logs
If you notice some errors in the log, that’s okay. We’ll remedy those in a little bit.

You also have the option of viewing logs from the command line. Get the name of your Pod:

oc get pods
NAME                        READY   STATUS    RESTARTS   AGE
parksmap-5d5f84ffcc-jbvh2   1/1     Running   0          5h

And then use the logs command to view this Pod's logs:

oc logs parksmap-5d5f84ffcc-jbvh2

You will see all of the application logs scroll on your screen:

2026-09-11 09:08:14.343  INFO 1 --- [           main] o.s.m.s.b.SimpleBrokerMessageHandler     : Started.
2026-09-11 09:08:14.445  INFO 1 --- [           main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8080 (http)
2026-09-11 09:08:14.449  INFO 1 --- [           main] c.o.evg.roadshow.ParksMapApplication     : Started ParksMapApplication in 15.093 seconds (JVM running
 for 16.252)
2026-09-11 09:08:48.147  INFO 1 --- [nio-8080-exec-1] o.a.c.c.C.[Tomcat].[localhost].[/]       : Initializing Spring FrameworkServlet 'dispatcherServlet'
2026-09-11 09:08:48.148  INFO 1 --- [nio-8080-exec-1] o.s.web.servlet.DispatcherServlet        : FrameworkServlet 'dispatcherServlet': initialization sta
rted
2026-09-11 09:08:48.162  INFO 1 --- [nio-8080-exec-1] o.s.web.servlet.DispatcherServlet        : FrameworkServlet 'dispatcherServlet': initialization com
pleted in 14 ms
2026-09-11 09:08:48.265  INFO 1 --- [nio-8080-exec-1] c.o.e.roadshow.rest.BackendsController   : Backends: getAll
2026-09-11 09:09:12.251  INFO 1 --- [MessageBroker-1] o.s.w.s.c.WebSocketMessageBrokerStats    : WebSocketSession[0 current WS(0)-HttpStream(0)-HttpPoll(
0), 0 total, 0 closed abnormally (0 connect failure, 0 send limit, 0 transport error)], stompSubProtocol[processed CONNECT(0)-CONNECTED(0)-DISCONNECT(0)]
, stompBrokerRelay[null], inboundChannel[pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0], outboundChannel[pool size = 0, active
 threads = 0, queued tasks = 0, completed tasks = 0], sockJsScheduler[pool size = 1, active threads = 1, queued tasks = 0, completed tasks = 0]
If you scroll through the logs, you may notice an error that mentions a service account. What’s that? Never fear, we will cover that shortly.