Container logs provide records of activity on the internal components of Package Security Manager—activity like incoming requests, errors, and configuration changes. Checking these logs can help you troubleshoot specific problems with your instance. Logs also give you a clearer picture of how your containers interact with each other. Below is a brief description of each container in the application, and what information you can gain from reviewing the logs for that container.
Container nameDescriptionUse case
nginx_proxyThe nginx_proxy logs capture HTTP request details, such as source IPs, requested URLs, and response status codes.Monitor routing decisions, load balancing actions, errors during proxying, and buffering behavior. Includes connection details, such as IP addresses used and handling of slow client connections.
nginx-exporterThe nginx-exporter container provides metrics for real-time data on request rates, connection states, and other performance indicators.Use these logs to diagnose active connections, HTTP requests, and errors related to metric scraping.
proxyIf your setup has a dedicated proxy container separate from the nginx_proxy, its logs likely include similar request and response details.Logs incoming and outgoing requests, records HTTP status codes, URLs, client IP addresses, and identifies network-related errors such as failed connections, timeouts, or DNS issues.
keycloakThe keycloak container logs focus on authentication and authorization events.Monitor login attempts, token issuances, and any errors related to identity management or user account configuration.
configuratorThe configurator container handles dynamic application settings.Review these logs for errors in configuration files or loading of new settings. If you see repeated reload attempts, investigate potential misconfigurations.
repo_apiLogs from the repo_api container track API requests and responses.Find status codes, endpoint usage stats, and application-level errors. Monitoring these logs helps you diagnose failing API calls or performance slowdowns.
database_migratorThe database_migrator logs capture schema updates, migration scripts, and any associated errors.If a migration fails, these logs can pinpoint the exact database operation or script that caused the issue.
repo_workerThe repo_worker container often performs background jobs or asynchronous tasks. These logs might include job execution times, error messages, and status updates on queued tasks.Monitor details on job dispatching, event handling, and Prometheus metrics, with security requirements for internal access only
repo_dispatcherThe repo_dispatcher container is responsible for routing tasks.These logs relate to job scheduling, event dispatching, and the outcome of triggered processes.
postgrespostgres container logs cover database-level events like connections, queries, and errors.These logs show database queries, connection attempts, transaction processes, and any errors or warnings related to database integrity and performance, particularly during upgrades or backups. Check these logs if you’re tracking database performance or investigating query timeouts.
postgres-exporterThe postgres-exporter container provides metrics instead of raw logs.Monitor database performance details for metrics collection, export status, connection attempts to the PostgreSQL database, and any encountered errors during metrics scraping, helping to
redisThe redis logs often show keyspace events, connection details, and error messages related to data persistence.Use these logs to track ephemeral key usage, detect potential memory leaks, and troubleshoot connection issues.
redis-exporterThe redis-exporter container shows metrics on Redis usage—such as memory consumption, key eviction rates, and command execution frequency.Provides metrics on cache performance, hit/miss ratios, and memory usage. Essential for monitoring Redis health and performance. Review these metrics to optimize your caching strategy and forecast resource needs.
prometheusThe prometheus logs can highlight scraping errors, rule evaluation problems, or storage-related issues.Logs metric collection, storage details, and alerting rules. Important for ensuring accurate and timely monitoring data. Review these logs if your metrics aren’t updating as expected or alerts fail to trigger. Check for error messages or slow scrape warnings.
node_exporterThe node_exporter logs report on the health of the exporter process.These logs provide metrics on system resources like CPU, memory, and disk usage. Check for messages about missing permissions or inaccessible system files.

​
Viewing containers

Follow these steps to view the containers in your Package Security Manager instance:
  1. Open a terminal and connect to your instance of Package Security Manager.
  2. Run the following command: 
    docker ps --all

​
Viewing container logs

Follow these steps to view the logs for a specific container:
  1. Open a terminal and connect to your instance of Package Security Manager.
  2. Run the following command: 
    # Replace <CONTAINER_NAME> with the name of the container
docker logs <CONTAINER_NAME>
    For example: 
    docker logs keycloak
    You can also view container logs in real-time by adding the --follow option to your command:
    # Replace <CONTAINER_NAME> with the name of the container
docker logs --follow <CONTAINER_NAME>
    Viewing logs in real time allows you to monitor ongoing processes and catch issues as they occur. This is particularly useful during deployments or troubleshooting sessions.

​
Analyzing container logs

Container logs hold various types of information that can help you understand the behavior and performance of your containers, enabling you troubleshoot and maintain your Package Security Manager instance effectively. Container logs typically capture the following important details:
Log InformationDescription
TimestampsEach log entry includes a timestamp, which tracks when specific events occurred, making it easier to correlate container logs with other system activities. Docker and Podman both support adding timestamps to log output using the --timestamps option.
Log levelsApplications inside containers typically categorize logs by severity, such as INFO, DEBUG, WARNING, ERROR, or FATAL. These levels help prioritize which logs need immediate attention. While container runtimes don’t enforce log levels, most applications generate logs with different severity levels.
Error messagesCritical issues or failures during container operations are captured in error messages. These messages include information like stack traces or system-generated errors, offering additional context for troubleshooting. Containers running services like web servers or databases log these issues via STDERR.
Process informationLogs often capture details about the processes running inside the container, such as when services start, stop, or encounter issues. This information is helpful for understanding the container’s operational state.
Log routingSome applications running inside containers may log directly to files instead of using standard output (STDOUT) or standard error (STDERR). In such cases, you can redirect log files to STDOUT/STDERR. For example, in Docker, this is done using symbolic links (as with the official Nginx image), or by configuring applications to log directly to the appropriate file descriptors.

​
Exporting logs

Save the logs for a specific container by running the following command: 
# Replace <CONTAINER_NAME> with the name of the container you are viewing
# Replace <FILE_NAME> with the name of the file you are saving
docker logs <CONTAINER_NAME> > <FILE_NAME>.log
Alternatively, you can collect and save logs for all the containers at once by running the following commands: 
# Replace <LOG_FILE_PREFIX> with a prefix for all of your log files (for example, logs_dump)
# Replace <CONTAINER_LOGS_DUMP> with a name for the tarball file that contains all the logs
for x in $(sudo docker ps --format '{{.Names}}'); do sudo docker logs $x >& <LOG_FILE_PREFIX>_$x; done
tar cvjf <CONTAINER_LOGS_DUMP>.tar.bz2 <LOG_FILE_PREFIX>_*

​
Integrating logs with monitoring tools

Use monitoring tools like Grafana and Prometheus to visualize container performance trends and set up alerts for issues in your Package Security Manager instance. Grafana helps you spot anomalies, while Prometheus allows you to create alerts based on error rates. For more information on accessing your dashboards and monitoring the health of your Package Security Manager instance, see Grafana monitoring. To learn more about Prometheus and metrics collection, see System metrics with Prometheus. To configure your logs to be sent directly to AWS CloudWatch, see the official AWS CloudWatch Logs documentation for detailed instructions.