Chapter 10. Monitoring containers

This chapter focuses on useful Podman commands that allow you to manage a Podman environment, including determining the health of the container, displaying system and pod information, and monitoring Podman events.

10.1. Performing a healthcheck on a container

The healthcheck allows you to determine the health or readiness of the process running inside the container. A healthcheck consists of five basic components:

Command
Retries
Interval
Start-period
Timeout

The description of healthcheck components follows.

Command: Podman executes the command inside the target container and waits for the exit code.

The other four components are related to the scheduling of the healthcheck and they are optional.

Retries: Defines the number of consecutive failed healthchecks that need to occur before the container is marked as "unhealthy". A successful healthcheck resets the retry counter.
Interval: Describes the time between running the healthcheck command. Note that small intervals cause your system to spend a lot of time running healthchecks. The large intervals cause struggles with catching time outs.
Start-period: Describes the time between when the container starts and when you want to ignore healthcheck failures.
Timeout: Describes the period of time the healthcheck must complete before being considered unsuccessful.

Healthchecks run inside the container. Healthcheck only make sense if you know what is a health state of the service and can differentiate between a successful and unsuccessful health check.

Procedure

Define a healthcheck:

$ sudo podman run -dt --name hc1 --health-cmd='curl http://localhost || exit 1' --health-interval=0 quay.io/libpod/alpine_nginx:latest
D25ee6faaf6e5e12c09e734b1ac675385fe4d4e8b52504dd01a60e1b726e3edb

The --health-cmd option sets a healthcheck command for the container.
The -health-interval=0 option with 0 value indicates that you want to run healthcheck manually.

Run the healthcheck manually:

$ sudo podman healthcheck run hc1
Healthy

Optionally, you can check the exit status of last command:
```
$ echo $?
0
```
The "0" value means success.

Additional resources

For more information on the podman run command, type man podman-run.
For more information, see article Monitoring container vitality and availability with Podman by Brent Baude.

10.2. Displaying Podman system information

The podman system command allows you to manage the Podman systems. This section provides information on how to display Podman system information.

Procedure

Display Podman system information:

To show Podman disk usage, enter:

$ podman system df
TYPE            TOTAL   ACTIVE   SIZE    RECLAIMABLE
Images          3       1        255MB   255MB (100%)
Containers      1       0        0B      0B (0%)
Local Volumes   0       0        0B      0B (0%)

To show detailed information on space usage, enter:

$ podman system df -v
Images space usage:

REPOSITORY                            TAG      IMAGE ID       CREATED         SIZE     SHARED SIZE   UNQUE SIZE   CONTAINERS
docker.io/library/alpine              latest   e7d92cdc71fe   3 months ago    5.86MB   0B            5.86MB       0
registry.access.redhat.com/ubi8/ubi   latest   8121a9f5303b   6 weeks ago     240MB    0B            240MB        1
quay.io/libpod/alpine_nginx           latest   3ef70f7291f4   18 months ago   9.21MB   0B            9.21MB       0

Containers space usage:

CONTAINER ID    IMAGE   COMMAND     LOCAL VOLUMES   SIZE   CREATED          STATUS   NAMES
ff0167c6c271    8121    /bin/bash   0               0B     10 seconds ago   exited   playTest

Local Volumes space usage:

VOLUME NAME   LINKS   SIZE

To display information about the host, current storage stats, and build of Podman, enter:

$ podman system info
host:
  arch: amd64
  buildahVersion: 1.15.0
  cgroupVersion: v1
  conmon:
    package: conmon-2.0.18-1.module+el8.3.0+7084+c16098dd.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.18, commit: 7fd3f71a218f8d3a7202e464252aeb1e942d17eb'
  cpus: 1
  distribution:
    distribution: '"rhel"'
    version: "8.3"
  eventLogger: file
  hostname: localhost.localdomain
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 4.18.0-227.el8.x86_64
  linkmode: dynamic
  memFree: 69713920
  memTotal: 1376636928
  ociRuntime:
    name: runc
    package: runc-1.0.0-66.rc10.module+el8.3.0+7084+c16098dd.x86_64
    path: /usr/bin/runc
    version: 'runc version spec: 1.0.1-dev'
  os: linux
  remoteSocket:
    path: /run/user/1000/podman/podman.sock
  rootless: true
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.1.1-1.module+el8.3.0+7084+c16098dd.x86_64
    version: |-
      slirp4netns version 1.1.1
      commit: bbf27c5acd4356edb97fa639b4e15e0cd56a39d5
      libslirp: 4.3.0
      SLIRP_CONFIG_VERSION_MAX: 3
  swapFree: 1833693184
  swapTotal: 2147479552
  uptime: 145h 19m 14.55s (Approximately 6.04 days)
registries:
  search:
  - registry.access.redhat.com
  - registry.redhat.io
  - docker.io
store:
  configFile: /home/user/.config/containers/storage.conf
  containerStore:
    number: 1
    paused: 0
    running: 0
    stopped: 1
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-1.1.1-1.module+el8.3.0+7121+472bc0cf.x86_64
      Version: |-
        fuse-overlayfs: version 1.1.0
        FUSE library version 3.2.1
        using FUSE kernel interface version 7.26
  graphRoot: /home/user/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 15
  runRoot: /run/user/1000/containers
  volumePath: /home/user/.local/share/containers/storage/volumes
version:
  APIVersion: 1
  Built: 0
  BuiltTime: Thu Jan  1 01:00:00 1970
  GitCommit: ""
  GoVersion: go1.14.2
  OsArch: linux/amd64
  Version: 2.0.0

To remove all unused containers, images and volume data, enter:
```
$ podman system prune
WARNING! This will remove:
        - all stopped containers
        - all stopped pods
        - all dangling images
        - all build cache
Are you sure you want to continue? [y/N] y
```
- The podman system prune command removes all unused containers (both dangling and unreferenced), pods and optionally, volumes from local storage.
- Use the --all option to delete all unused images. Unused images are dangling images and any image that does not have any containers based on it.
- Use the --volume option to prune volumes. By default, volumes are not removed to prevent important data from being deleted if there is currently no container using the volume.

Additional resources

For more information on the podman system df command, type man podman-system-df.
For more information on the podman system info command, type man podman-system-info.
For more information on the podman system prune command, type man podman-system-prune.

10.3. Podman event types

You can monitor events that occur in Podman. Several event types exist and each event type reports different statuses.

The container event type reports the following statuses:

attach
checkpoint
cleanup
commit
create
exec
export
import
init
kill
mount
pause
prune
remove
restart
restore
start
stop
sync
unmount
unpause

The pod event type reports the following statuses:

create
kill
pause
remove
start
stop
unpause

The image event type reports the following statuses:

prune
push
pull
save
remove
tag
untag

The system type reports the following statuses:

refresh
renumber

The volume type reports the following statuses:

create
prune
remove

Additional resources

For more information on the podman events command, type man podman-events.

10.4. Monitoring Podman events

You can monitor and print events that occur in Podman. Each event will include a timestamp, a type, a status, name (if applicable), and image (if applicable).

Procedure

Show Podman events:

To show all Podman events, enter:

$ podman events
2020-05-14 10:33:42.312377447 -0600 CST container create 34503c192940 (image=registry.access.redhat.com/ubi8/ubi:latest, name=keen_colden)
2020-05-14 10:33:46.958768077 -0600 CST container init 34503c192940 (image=registry.access.redhat.com/ubi8/ubi:latest, name=keen_colden)
2020-05-14 10:33:46.973661968 -0600 CST container start 34503c192940 (image=registry.access.redhat.com/ubi8/ubi:latest, name=keen_colden)
2020-05-14 10:33:50.833761479 -0600 CST container stop 34503c192940 (image=registry.access.redhat.com/ubi8/ubi:latest, name=keen_colden)
2020-05-14 10:33:51.047104966 -0600 CST container cleanup 34503c192940 (image=registry.access.redhat.com/ubi8/ubi:latest, name=keen_colden)

To exit logging, press CTRL+c.

To show only Podman create events, enter:

$ podman events --filter event=create
2020-05-14 10:36:01.375685062 -0600 CST container create 20dc581f6fbf (image=registry.access.redhat.com/ubi8/ubi:latest)
2019-03-02 10:36:08.561188337 -0600 CST container create 58e7e002344c (image=registry.access.redhat.com/ubi8/ubi-minimal:latest)
2019-03-02 10:36:29.978806894 -0600 CST container create d81e30f1310f (image=registry.access.redhat.com/ubi8/ubi-init:latest)

Additional resources

For more information on the podman events command, type man podman-events.

Log in to Your Red Hat Account

Red Hat Account

Customer Portal

Select Your Language

Infrastructure and Management

Cloud Computing

Storage

Runtimes

Integration and Automation

Services

Tools

Red Hat Insights

Red Hat Product Security Center

Security Updates

Resources

Customer Portal Community

Customer Events

Stories

Chapter 10. Monitoring containers

10.1. Performing a healthcheck on a container

10.2. Displaying Podman system information

10.3. Podman event types

10.4. Monitoring Podman events