Serverless Containers: Monitoring & Logs
This guide explains how to observe, troubleshoot, and validate Serverless Container applications in CloudRaya using platform-level metrics and container logs.
It focuses on an SRE-style mental model: knowing when to look at metrics, when to inspect logs, and how to move from a symptom to a root cause.
Metrics vs Logs
Monitoring and logs answer two different operational questions:
-
Metrics (Monitoring) → Is my application healthy?
High-level signals such as CPU and memory usage over time. -
Logs → Why is my application behaving this way?
Detailed, time-ordered records of what the containers are doing.
A typical workflow is:
- Start with metrics to detect a problem
- Use logs to diagnose the cause
Monitoring Overview
The Monitoring tab provides near real-time visibility into resource usage for each container in your application.
You can:
- View CPU usage
- View memory usage
- Select a time range
- Switch between containers in multi-container applications
Metrics are only available while the application is Running. If the app is stopped or still deploying, the tab shows a Monitoring Usage Unavailable state until it comes back online.
Time Range Selection
You can change the observation window to match the type of issue you are investigating:
- Last 15 minutes: Real-time troubleshooting
- Last 1 hour / 3 hours: Recent changes or deploy impact
- Last 12 / 24 hours: Trend analysis
- Last 7 days: Capacity planning and baseline behavior
Choose shorter ranges for active incidents and longer ranges for performance analysis.
Container Scope
Some applications run more than one container, such as:
- An application container
- A database container
Use the container selector to choose which container’s metrics you want to view.
This is important because:
- High CPU in the database container indicates query or connection pressure
- High memory in the application container may indicate caching or memory leaks
Always verify the selected container before drawing conclusions.
Understanding Metrics
CPU Usage
CPU usage shows how much processing capacity the container is consuming relative to its allocated limit.
Common patterns:
- Consistently high CPU → The container may be under-provisioned
- Sudden spikes → Traffic bursts or expensive operations
- Sustained 100% → The chart flags maximum capacity reached; the container is CPU-bound and likely needs a larger package
Memory Usage
Memory usage shows how much RAM the container is using.
Common patterns:
- Keeps going up over time → The application may not be releasing memory properly
- Close to the limit → The app may slow down or restart if it runs out of memory
Logs Overview
The Logs tab shows the live output of the selected container.
This is where you can see what the application is doing in real time, such as:
- Messages when the app starts
- Errors and warnings
- Activity from user requests or background tasks
Logs are shown as a live stream, meaning new lines appear automatically as the container runs.
Like monitoring, logs are only available while the application is Running.
Container Selection for Logs
Just like monitoring, logs are shown per container.
Always select the container that matches the component you are troubleshooting:
- Application issues → Select the application container
- Database connection issues → Select the database container
Log Controls and What They Mean
Number of Tail Lines
This controls how many recent log lines are loaded when the log view starts.
- Smaller numbers load faster
- Larger numbers provide more historical context
Refresh
Reconnects the log stream and reloads the most recent lines. Use it after a redeploy, or if the stream has ended and you want the latest output.
Auto Scroll
- Enabled: The view follows new log lines automatically
- Disabled: The view stays at your current position
Disable auto scroll when reviewing earlier messages.
Clear View
Clears the current log display. This does not delete logs from the system.
Use this to create a clean view before reproducing an issue.
Container and Tail Lines
The Container and Tail Lines selectors above the log view control which container's output you see and how many recent lines are loaded.
When to Use Metrics vs Logs
| Situation | Start With | Then Use |
|---|---|---|
| App is slow | Metrics | Logs |
| App is down | Metrics | Logs |
| Error message in UI | Logs | Metrics |
| Capacity planning | Metrics | Logs |
Troubleshooting Workflow
A recommended operational flow:
- Check the app's status badge in My Apps or on the app detail page (it should be Running)
- Open Monitoring to identify resource pressure
- Switch to Logs for the affected container
- Reproduce the issue if possible
- Review error or warning messages
Production Best Practices
- Monitor both application and database containers
- Review metrics after every deploy or resize
- Capture logs (copy from the view) for critical incidents
- Establish baseline CPU and memory usage for normal operation
- Avoid sharing logs publicly if they contain sensitive data
Responsibility Model
In general:
- CloudRaya is responsible for:
- Metrics collection and platform availability
- Log streaming infrastructure
- You are responsible for:
- Interpreting metrics and logs
- Application-level troubleshooting
- Protecting sensitive information in logs
Next Guide
Learn how to resize applications, redeploy safely, and manage the full lifecycle of your Serverless Container apps.