How to make container logs being print out in docker logs -f or cloud watch

Docker Engine General
, ,
1

Hi,

I want to make sure my logs is being print out in docker logs -f some container id but all I get is something like this

WARN  : System properties and/or JVM args set.  Consider using --dry-run or --exec
2025-10-05 20:27:15.549:INFO::main: Logging initialized @532ms to org.eclipse.jetty.util.log.StdErrLog
2025-10-05 20:27:15.829:INFO::main: Console stderr/stdout captured to /opt/jetty-base/logs/2025_10_05.jetty.log

instead of like this

2025-10-05 20:27:42.514:INFO:oejs.AbstractConnector:main: Started ServerConnector@5d27b4c1
2025-10-05 20:27:42.544:INFO:oejs.Server:main: Started @27526m

Here is my config:

  1. logback - I had already defined my logs should look like
    <!-- Console Appender for STDOUT (Docker-friendly) -->
    <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <!-- Timestamp + level + logger name + message -->
            <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level [%thread] %logger{36} - %msg%n</pattern>
        </encoder>
    </appender>
    <root level="INFO">
        <appender-ref ref="CONSOLE" />
    </root>

I think this is the minimal setting to make the logs being print out in docker logs -f cause currently my logs are being print out by going inside the container and from there we tail the log. Can someone please help me, can suggest what should be the configuration needed in docker file and entrypoint.sh

2

I feel some context is missing. You shared two outputs and i don’t know what and why would be expected. Are you using only the command line, or do you expect the logs appear in a window of an IDE?

You shared a config file, but nothing about what is that for. Possibly it would be obvious for a Java developer, but not to me.

My second guess is you have problem with configuring the Java application to send the logs to the standard output instead of saving to a file on the filesystem?

Official images are already optimized for containers, but if you have your own image, or any other not official made by someone, you will need to configure the app or server. If you need help with the right configuration for a Java-based webserver, you need someone more familiar with Java.

You cans till hope some help here, but please, share more about what you are doing. What image you are using and how you start the container. If for example you just use docker exec to start a new process in a running container, that will not appear in the docker logs. Only those that were written by the main process that keeps the container alive.running in the foreground.

3

  • Are you using only the command line.
    Yes, I’m using the command line to handle the build, tag, and push process to ECR. I want the logs to be appear using this command docker logs -f <my-service>

  • do you expect the logs appear in a window of an IDE
    My goal is that after pushing the image to ECR and deploying it on ECS, I want the application logs to appear in CloudWatch or be viewable via docker logs -f <my-service>.
    However, right now it only shows this line:
    2025-10-08 15:41:43.307:INFO::main: Console stderr/stdout captured to /opt/jetty-base/logs/2025_10_08.jetty.log

  • You shared a config file, but nothing about what is that for
    The reason I shared the configuration file is to show that in my application code, I’ve already done the proper or minimal setup for the logging to work. However, it still doesn’t appear as expected like this
    2025-10-08 10:19:11.014:INFO:oejs.Server:main: Started @72976ms

  • My second guess is you have problem with configuring the Java application to send the logs to the standard output instead of saving to a file on the filesystem
    This is not my goal, my goal is already stated in the first question

  • share more about what you are doing
    I want to deploy my application on ECS, so I’ve followed the usual deployment steps. I have several configuration files for this process — mainly the Dockerfile and the entrypoint script — which contain important variables such as the image tag, port number, and other settings. After pulling the image and deploying it on my server, I tried checking the logs, but it doesn’t show that the application has started. Instead, I have to go inside the container and manually tail the logs, which I’d prefer not to do. The only message that appears is: Console stderr/stdout captured to /opt/jetty-base/logs/2025_10_08.jetty.log

  • If you need help with the right configuration for a Java-based webserver, you need someone more familiar with Java
    Thanks for the suggestion! I’ll check with the right channel, but please feel free to share any advice — I’d really appreciate it!:crying_cat::crying_cat::crying_cat:

4

Based on the single log line you get, it seems that it is your goal. If docker logs returns only that the standard output (stdout) and standard error (stderr) is captured to a file under “jetty-base/logs”, that must be a Jetty settings issue.

I understand that yyou shared the config file to show that you configured the application, but without sharing what the configuration is for, you can expect help only from people who recognize the config just based on a couple of lines. Since this is a Docker community forum, people with other specific application configuration skills are less likely to be found. At least at a level that allows them to recognize details based on a couple of lines.

I see “Jetty” in the logs, so I assume the config file is for Jetty, but a filename can help a lot to search for right configuration parameters and possibly recognize if something will not work in a Docker container.

Even then, we would need to know what base image you are using or if you add extra configurations to an image you build from the base image, a Dockerfile is important as well.

I’m guessing that even if the configuration file is correct, the config file could be in the wrong folder or named incorrectly. It could also be unreadable by the server, but I assume that would result in an actual error message.

Since you haven’t really shared Docker-related files, guessing is the best I can do. If you share anything I mentioned above, then we will have something to work with. Otherwise, a Java forum can be more useful to you.

Final tips:

You can start a container interactively and try to start the server from the command line manually. USe the command line also to browse the filesystem and confirm if everything is in the right folder with the right permissions. You can also try running the same container in Docker Desktop locally and use Docker Desktop’s built-in filesystem browser from the GUI.

5

  • What is the configuration file for?
    The configuration I shared earlier is a Logback file that ensures my application prints logs in the specific format I’ve defined. For example, in this case:
    %d{yyyy-MM-dd HH:mm:ss.SSS} %-5level [%thread] %logger{36} - %msg%n
    This pattern represents elements such as the timestamp, log level, thread name, logger name, and the actual message.
    However, I’m not focusing on the pattern itself — let’s look at the appender. In the configuration, I declared a console appender:
    name="CONSOLE" and class="ch.qos.logback.core.ConsoleAppender",
    which means the logs will be sent to the standard output (stdout) & it does not follow the pattern I set:crying_cat::crying_cat::crying_cat:
    Then, in the following section:
    <root level="INFO"><appender-ref ref="CONSOLE" /></root>
    the root logger is configured with level INFO, so only logs with levels INFO, WARN, and ERROR will be displayed.

  • What is the filename of the configuration file?
    logback.xml

  • What base image are you using in your Docker file?
    I am using maven:3.8.6-openjdk-8 AS & custom image hosted in my AWS ECR which built on Jetty and JDK 8

  • Do you add any extra configurations to your image?
    I’ve implemented logic in the entry point script to:

  1. Instruct Docker to execute the script using the system shell.
  2. Launch the Jetty web server.
  3. Pass configuration values from environment variables into the Java process.
  • Can you share your Docker file
    Here’s the portion I’m able to share (I hope this helps!):
# Stage 1: Build project dependencies

# Stage 2: Configure JAVA_HOME and PATH

# Stage 3: Copy safe Maven settings

# Stage 4: Build the project

# Stage 5: Use the custom (runtime) base image

# Stage 6: Copy the WAR file into the image

# Stage 7: Add the entrypoint script

# Stage 8: Launch the Jetty server
6

Is this the complete configuration? Compared to mine, it looks incomplete. Where and in which file is it stored in the application folder? How does your command to start the java application look like?

It looks like the logger is not configured to use your configuration. It seems to use a default configuration instead.

7
  • Is this the complete configuration?
<?xml version="1.0" encoding="UTF-8"?> 
<!-- ================================================================================== -->
<!-- ✅ Docker-optimized configuration: Only console logging, no rolling file appenders -->
<!-- ================================================================================== -->

<!-- Console Appender for STDOUT (Docker-friendly) -->
<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
    <encoder>
        <!-- Timestamp + level + logger name + message -->
        <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level [%thread] %logger{36} - %msg%n</pattern>
    </encoder>
</appender>

<!-- ================================================================================== -->
<!-- ✅ Application log levels -->
<!-- ================================================================================== -->
<logger name="com.softspace" level="DEBUG" />
<logger name="com.softspace.payment.console.bank.annotation" level="WARN" />
<logger name="com.softspace.payment.console.bank.security" level="DEBUG" />

<!-- Third-party libraries -->
<logger name="org.springframework.core" level="WARN" />
<logger name="org.springframework.beans" level="WARN" />
<logger name="org.springframework.context" level="WARN" />
<logger name="org.springframework.web" level="WARN" />
<logger name="org.springframework.security" level="WARN" />
<logger name="org.hibernate" level="ERROR" />

<!-- ================================================================================== -->
<!-- ✅ Jetty Integration -->
<!-- Force Jetty to route through SLF4J (so it also ends up in the same console stream) -->
<!-- ================================================================================== -->
<logger name="org.eclipse.jetty" level="INFO" />
<logger name="org.eclipse.jetty.util.log" level="INFO" />

<!-- ================================================================================== -->
<!-- ✅ Root logger — only console, no files -->
<!-- ================================================================================== -->
<root level="INFO">
    <appender-ref ref="CONSOLE" />
</root>

  • Where and in which file is it stored in the application folder
    my-project
    └── src
    └── main
    └── resources
    └── logback.xml

  • How does your command to start the java application look like

mvn clean install
mvn jetty:run
mvn clean install jetty:run
mvn clean install jetty:run -Dspring.profiles.active= -Dserver.port=

8

Almost.
Looks like the top level element is missing.

See example from the docs:

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE configuration>

<configuration>
  <import class="ch.qos.logback.classic.encoder.PatternLayoutEncoder"/>
  <import class="ch.qos.logback.core.ConsoleAppender"/>

  <appender name="STDOUT" class="ConsoleAppender">
    <encoder class="PatternLayoutEncoder">
      <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} -%kvp- %msg%n</pattern>
    </encoder>
  </appender>

  <root level="debug">
    <appender-ref ref="STDOUT"/>
  </root>
</configuration>

Do you copy the lockback.xml into the image you create manually? The docs say the file is searched within the classpath. Are you sure the file is copied into the build jar file?

Can you share your thoughts on why you thought this must be a docker related problem?