Logging and monitoring
Programs written in AEL, the Agent Engineering Language, will tell you what they did wherever they run. Structured logs will 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 will watch health, resource use and devices.
Status
Planned for AEL Beta 0.0.1. AEL is not available yet.
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
| Target | Where logs will go |
|---|---|
| Desktop and server | The console, JSON Lines files with rotation and retention, a remote collector you run, or a sink you write in AEL. |
| Containers | Standard error by default, so standard output will carry only the program's result. File logs only on a writable mount you declare, checked before the program reports ready. |
| Edge boards | Compact events through the serial port or to the gateway. |
| Nano boards | Compact events through a fixed-size buffer, the serial port or the gateway, with no file system needed. |
- Bounded everywhere. Every sink will have a bounded queue. A slow or failing sink will never hold up your agents indefinitely, and its failure will be reported through a fallback route.
- Counted on boards. On a board, what logging uses will appear in the firmware's memory report, like any other part of the program.
What every event carries
Agents will be multi-tenant from the start: a trusted tenant identity will flow through every call, store, log and reply. Each log event will also carry the run, the agent and node, the versions of the prompt and configuration in use, a severity and a time.
- Redacted by default. Logs will record what happened, not your data. Recording prompts, inputs or outputs will be a separate choice, with its own access and retention rules, and credentials will never be logged.
- Audit apart. Records of security and platform events will be kept apart from your application's logs. Your code will not be able to alter or erase them.
Health and readiness
- Programs in containers will 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 will be reported separately. Health checks will never call a model. See Containers.
- The self-hosted server will report its readiness and the health of its storage, job queue, workers and device connectors. See Self-hosted server.
Resource use
Per-agent CPU and memory limits will state whether each limit is hard-enforced or accounted.
- Honest reports. Resource reports will 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 will end with an outcome that names the limit, and its child agents will be cancelled.
- Boards. Firmware images will 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 will flash and monitor supported boards from the command line, using each board's standard flashing tools. ael monitor (command names may change before launch) will show a device's output:
ael devices
ael monitor --device <device>
- The output will be bounded in rate and in how much is kept, and secrets will be redacted. Monitoring a device describes the command in full.
- Monitoring will take the device for itself: while you monitor a device, no one else will be able to flash it.
Debugging
You will debug at source level in standard native debuggers. See Desktop and server.
Related
- Console and logging: events, sinks and redaction in detail.
- Reporting, logs and replay: time and token reports, and recording and replaying runs.
- Deployment and rollback: watching a change as it is applied.