CloudRaya Documentation

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.

  • LogsWhy is my application behaving this way?
    Detailed, time-ordered records of what the containers are doing.

A typical workflow is:

  1. Start with metrics to detect a problem
  2. 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

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

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.


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

Play / Pause (Live Streaming)

  • Play — Continuously stream new log entries
  • Pause — Stop live updates to inspect existing output

This is useful during active troubleshooting or after a redeploy.

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.

Download Logs

Exports the current log output to a file for:

  • Offline analysis
  • Sharing with support teams
  • Incident documentation

When to Use Metrics vs Logs

SituationStart WithThen Use
App is slowMetricsLogs
App is downMetricsLogs
Error message in UILogsMetrics
Capacity planningMetricsLogs

Troubleshooting Workflow

A recommended operational flow:

  1. Check status in My Apps (Running / Deploying / Error)
  2. Open Monitoring to identify resource pressure
  3. Switch to Logs for the affected container
  4. Reproduce the issue if possible
  5. Review error or warning messages

Production Best Practices

  • Monitor both application and database containers
  • Review metrics after every deploy or resize
  • Export logs 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.

📄 Serverless Containers — Scaling & Lifecycle Management

© 2026 CloudRaya Product Team. All rights reserved.

On this page