Function Compute:Monitoring and Logs

This capability is provided by Function Compute and Alibaba Cloud observability services. It is not a native interface of the E2B SDK.

Configuration entry and effective scope

Before integration, confirm the monitoring and logging configuration entry and effective scope:

• Configuration entry: Use the currently available FC Agent Sandbox console, Function Compute console, or Simple Log Service configuration as the source of truth. If the console does not show a log collection entry for FC Agent Sandbox, contact product support to confirm the enablement method.

• Effective scope: Confirm whether the configuration applies to the account, region, template, sandbox, or session, and whether it affects only newly created sandboxes.

• Log destination: Confirm the Simple Log Service project, Logstore, indexed fields, retention period, and cost policy.

Log collection boundary

After log collection is configured, logs printed to stdout or stderr by programs inside the sandbox are collected into Simple Log Service. If you want task logs to be searchable in cloud logging systems, output structured logs directly from the program and include correlation fields such as sandboxId and task ID.

sandbox.commands.run() still returns stdout and stderr to business code. If the business side needs to store command summaries, exit codes, or error categories, capture the command result, truncate and redact it, and then emit it as application logs.

Do not use the E2B SDK-compatible Sandbox Logs interface as the production log collection entry point. Production troubleshooting should rely on business-side structured logs, Function Compute log collection, CloudMonitor, and Simple Log Service data.

Record sandbox runtime information

import { Sandbox } from "e2b";

const taskId = crypto.randomUUID();

const sandbox = await Sandbox.create("code-interpreter-v1", {
  apiKey: process.env.E2B_API_KEY,
  apiUrl: process.env.E2B_API_URL,
  domain: process.env.E2B_DOMAIN,
  metadata: {
    taskId,
  },
});

try {
  console.log(JSON.stringify({
    event: "sandbox_created",
    taskId,
    sandboxId: sandbox.sandboxId,
  }));

  const result = await sandbox.commands.run("python3 -V", {
    timeoutMs: 30_000,
  });

  console.log(JSON.stringify({
    event: "command_finished",
    taskId,
    sandboxId: sandbox.sandboxId,
    exitCode: result.exitCode,
    stdout: result.stdout.trim(),
    stderr: result.stderr.trim(),
  }));
} finally {
  await sandbox.kill();
}

Output structured logs

After log collection is configured, output structured logs so you can search by field in Simple Log Service.

const result = await sandbox.commands.run(
  `python3 - <<'PY'
import json
import os
import time

task_id = os.environ["TASK_ID"]
print(json.dumps({
    "event": "task_started",
    "taskId": task_id,
    "ts": int(time.time()),
}), flush=True)
print(json.dumps({
    "event": "task_finished",
    "taskId": task_id,
    "ts": int(time.time()),
}), flush=True)
PY`,
  {
    envs: {
      TASK_ID: taskId,
    },
    timeoutMs: 30_000,
  }
);

console.log(result.stdout);

Common observability targets

• Sandbox Lifecycle: create, connect, pause, resume, kill.

• Command execution results: exit code, stdout, stderr, and execution time.

• Resource usage: CPU, memory, disk, and network.

• Correlation fields: sandboxId, task ID, user or tenant identifier, and template name.

• Structured log fields: event, taskId, sandboxId, exitCode, and summaries of stdout and stderr.

Notes

• Your business system should persist the mapping between task IDs and sandboxId values.

• Do not write full API keys, AccessKeys, database passwords, or OAuth tokens to logs.

• For long-running tasks, set both command timeouts and sandbox timeouts.

• For tasks that produce large volumes of logs, control output size to avoid excessive logging costs.