Skip to content
cccskills
FreePublished on GitHub

iii-observability

Record and query iii engine logs, traces that show how calls flow, and operational metrics. Set up reactions to incoming errors, inspect alerts, and review metrics aggregated over time windows.

OriginalShow the original description

OpenTelemetry-backed tracing, structured logs, metrics with rollups, alerts, sampling, and baggage for the engine — emit and query telemetry through `engine::*` functions and react to logs with a `log` trigger.

See how to install

Good for

  • Investigating errors through related logs and traces
  • Triggering notifications when error logs arrive
  • Reviewing metrics aggregated over time
  • Checking engine health and alert status

Files included (1)

  • SKILL.md6.1 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

iii-observability

The iii-observability worker provides OpenTelemetry-backed observability for the iii engine: distributed tracing, structured logs, metrics with rollups, alert rules, sampling configuration, and baggage propagation. Every surface is a callable engine::* function, plus a single log reactive trigger that fires on every ingested log entry. Functions span nine sub-namespaces — emit, query stored telemetry, inspect configuration, and propagate context.

The worker is on by default (enabled: true). When disabled, the emit and read functions still register but become no-ops and the trigger never fires. Core config: service_name/service_version/service_namespace (OTel resource attributes), exporter (memory | otlp | both), endpoint (OTLP collector URL, default http://localhost:4317), sampling_ratio (0.0–1.0), memory_max_spans, and per-pillar toggles/limits (metrics_enabled, logs_enabled, retention and count caps). Most fields accept OTEL_* env overrides. The in-memory query functions (logs, traces) require the memory or both exporter.

Traces and metrics use OTLP/gRPC by default; https:// endpoints enable TLS and http:// endpoints use cleartext. Set OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf to use OTLP/HTTP protobuf for traces and metrics, or use OTEL_EXPORTER_OTLP_TRACES_PROTOCOL / OTEL_EXPORTER_OTLP_METRICS_PROTOCOL for signal-specific overrides. The HTTP/protobuf path is appended automatically (/v1/traces, /v1/metrics) when the configured endpoint is a base collector URL. Logs export over OTLP/HTTP to /v1/logs.

Use OTEL_EXPORTER_OTLP_HEADERS for collector headers and the signal-specific OTEL_EXPORTER_OTLP_TRACES_HEADERS, OTEL_EXPORTER_OTLP_METRICS_HEADERS, or OTEL_EXPORTER_OTLP_LOGS_HEADERS when needed. The logs exporter reads OTEL_EXPORTER_OTLP_LOGS_HEADERS first and falls back to OTEL_EXPORTER_OTLP_HEADERS. Keep credentials in environment variables or a secret manager, not in config files.

When to Use

  • Emit structured logs or read back stored logs/spans/metrics from inside a function instead of shelling out to a collector.
  • React in real time to log entries (page on errors, archive everything) without polling.
  • Inspect engine health, active sampling rules, or alert state operationally.
  • Propagate OpenTelemetry baggage across calls for cross-cutting context.

Boundaries

  • engine::baggage::set does not propagate back to the caller — baggage propagation happens at the SDK/invocation level via headers.
  • The in-memory query functions return nothing useful unless the memory (or both) exporter is configured; with otlp-only the data lives in your collector.
  • When logs_enabled is off the log pipeline is dormant and the log trigger never fires; the ingest level sets the minimum severity stored.
  • This worker observes telemetry — it is not a general event bus (pubsub) or durable queue (queue); those are standalone Compose workers.

Functions

  • engine::log::info, engine::log::warn, engine::log::error, engine::log::debug, engine::log::trace — emit a log entry at the named severity; same input shape, only the level differs.
  • engine::logs::list — read stored OTel logs, filtered by time, trace correlation, or severity.
  • engine::logs::clear — wipe the in-memory log store.
  • engine::traces::list — list compact trace summaries with aggregate status/counts and optional attribute projection.
  • engine::traces::spans — list full span records for detail/timeline consumers.
  • engine::traces::tree — walk a single trace as a parent/child tree.
  • engine::traces::group_by — aggregate stored spans by an attribute value (counts, duration, errors per group).
  • engine::traces::clear — wipe stored spans.
  • engine::metrics::list — list metrics with aggregated stats and optional time bucketing.
  • engine::rollups::list — list metric rollup aggregations across 1-minute, 5-minute, and 1-hour windows.
  • engine::baggage::get, engine::baggage::get_all — read one or all OpenTelemetry baggage keys.
  • engine::baggage::set — set a baggage key locally (does not propagate to the caller).
  • engine::sampling::rules — list the active sampling rules.
  • engine::health::check — return engine health (status, per-component breakdown, version).
  • engine::alerts::list — inspect configured alert rules and current state.
  • engine::alerts::evaluate — manually run an alert evaluation pass.

Reactive triggers

Bind a log trigger when a function should run every time a log entry lands in the engine's OTel log pipeline — emitted via engine::log::*, ingested via OTLP, or recorded by any worker using structured logging. Each subscription receives the same OTel-shaped record, so handlers can route by severity, attribute, or trace correlation.

Reach for it when:

  • A specific severity (typically error) should page a human, post to Slack, or open a ticket.
  • You want real-time fan-out of log entries to a downstream sink (archive, analytics, transformer) without polling engine::logs::list.

Use engine::logs::list instead when you need to query stored entries on demand rather than react to each as it arrives.

How to bind

  1. Register a handler: iii.registerFunction('monitoring::on-error', handler).
  2. Register the trigger:
iii.registerTrigger({
  type: "log",
  function_id: "monitoring::on-error",
  config: {
    level: "error", // optional. trace|debug|info|warn|error. Omit to fire on every level.
  },
});

The log trigger only fires when the logs pipeline is enabled, and level filters to that minimum severity. The handler's return value is ignored; invocations are spawned asynchronously after each entry is stored.

For the OTel log record shape, call iii get function info on the trigger type or handler function id.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

configuration

FreeSummary

Manage shared iii configuration with JSON Schema, a definition of allowed value structures. Covers validated settings, automatic change notifications, YAML edits, temporary overrides, and default initialization that preserves existing values.

  • Sharing validated settings between workers
  • Reacting to manual YAML configuration edits
  • Initializing defaults while preserving existing values
iii-hq/iii18.8KUpdated Oct 18, 2026

iii

FreeSummary

Helps extend an iii system by checking live functions, searching the public worker registry, and writing a worker when needed. Covers TypeScript SDK calls, event triggers, error handling, and worker operation through Compose.

  • Finding and calling functions already available in iii
  • Searching for and adding a published worker
  • Building a custom worker with the TypeScript SDK
iii-hq/iii18.8KUpdated Oct 18, 2026

Design iii backends by combining functions, queues, and shared state. Choose patterns for workflows with retries, live updates, cooperating AI agents, and event-driven processing, with examples showing how the pieces connect.

  • Designing order workflows with retries and step tracking
  • Updating screens or caches when stored data changes
  • Passing tasks between specialized AI agents
iii-hq/iii18.8KUpdated Oct 18, 2026

Guides development of iii functions, event triggers, and workers, the processes that execute functions. Helps choose result-returning calls, one-way calls, or queued work, inspect live registrations, and connect existing HTTP services.

  • Running a function on an HTTP request or schedule
  • Choosing between direct calls and queued work
  • Inspecting registered workers and functions
iii-hq/iii18.8KUpdated Oct 18, 2026

Helps configure an iii engine for Compose management or direct supervision by tools such as systemd. Covers configuration file structure, ports, storage, and role-based access control through rbac-proxy, including requirements for public connections.

  • Configuring an engine managed by Compose
  • Configuring an engine supervised by systemd or Kubernetes
  • Setting authentication and access rules for public connections
iii-hq/iii18.8KUpdated Oct 18, 2026

Diagnose iii invocation failures using error codes across Node, Python, Rust, and browser workers. Distinguish permission denials, timeouts, and handler failures, then choose appropriate exception handling and decide whether retrying is suitable.

  • Diagnosing failed function calls by error code
  • Deciding whether a timed-out operation should be retried
  • Handling permission denials without blind retries
iii-hq/iii18.8KUpdated Oct 18, 2026

See all skills by iii-hq

Report a problem with this skill