AEL Docs
Follow updates
Menu
Follow updates
Browse the documentation

AEL 1.0.0

Logging and monitoring

Programs written in AEL, the Agent Engineering Language, tell you what they did wherever they run. Structured logs go to the console, a file, or custom or remote sinks, with redaction, rotation and retention. This page describes what that means on each kind of target, and how you watch health, resource use and devices.

The events, sinks and redaction rules themselves are described in Console and logging, and time and token reports in Reporting, logs and replay.

Logs on each kind of target

TargetWhere logs go
Desktop and serverThe console, JSON Lines files with rotation and retention, a remote collector you run, or a sink you write in AEL.
ContainersStandard error by default, so standard output carries only the program's result. File logs only on a writable mount you declare, checked before the program reports ready.
Edge boardsCompact events through the serial port or to AEL Gateway.
Nano boardsCompact events through a fixed-size buffer, the serial port or the gateway, with no file system needed.
Coin-cell-class and other small boardsNo text: a small board sends compact events through the serial port when its board support declares one, and on the smallest boards a fault is reported where the board can report it.
  • Bounded everywhere. Every sink has a bounded queue. A slow or failing sink never holds up your agents indefinitely, and its failure is reported through a fallback route.
  • Counted on boards. On a board, what logging uses appears in the firmware's memory report, like any other part of the program.

What every event carries

Agents are multi-tenant from the start: a trusted tenant identity flows through every call, store, log and reply. Each log event also carries the run, the agent and node, the versions of the prompt and configuration in use, a severity and a time.

  • Redacted by default. Logs record what happened, not your data. Recording prompts, inputs or outputs is a separate choice, with its own access and retention rules, and credentials are never logged.
  • Audit apart. Records of security and platform events are kept apart from your application's logs. Your code cannot alter or erase them.

Health and readiness

  • Programs in containers report ready once their own configuration and files are validated and they can accept a request. Whether a model provider or another service can be reached is reported separately. Health checks never call a model. See Containers.
  • Applications on servers you operate have health checks for the storage, databases and models they declare: each storage point, database binding and model binding. A health report never shows a credential or the value of a secret, and the check of a model binding never calls a model. See Self-hosting your application.

Resource use

Per-agent CPU and memory limits state whether each limit is hard-enforced or accounted.

  • Honest reports. Resource reports include the runtime's own overhead and each agent's share of what agents use together, not only your agent's code.
  • Clear outcomes. When a limit ends a run, the run ends with an outcome that names the limit, and its child agents are cancelled.
  • Boards. Firmware images come with RAM, flash and stack reports when you build; see Microcontroller boards.

Budgets, retries and validation describes how limits are set for tenants, agents and runs.

Watching a device

You flash and monitor supported boards from the command line, using each board's standard flashing tools. ael monitor shows a device's output:

ael devices
ael monitor --device <device>
  • The output is bounded in rate and in how much is kept, and secrets are redacted. Monitoring a device describes the command in full.
  • Monitoring takes the device for itself: while you monitor a device, no one else can flash it.

Debugging

You debug at source level in standard native debuggers. See Desktop and server.