WASI Observe World

A proposed WebAssembly System Interface API.

Current Phase

WASI Observe is currently in Phase 1.

Meetings

Meetings are fortnightly (held every other week, starting on 2024-W05 (2024 Jan 31) on Wednesdays at UTC 16:00.

Contact @calebschoepp via caleb.schoepp at fermyon dot com to request an invite. Participants must be W3C WebAssembly CG members.

Roadmap

• Phase 1

Champions

• Caleb Schoepp (Fermyon)

Portability Criteria

TODO before entering Phase 2.

Table of Contents

• Introduction
  • An aside
• Goals
  • Technical Values
  • User Stories
    • A Programmer is Required to Implement O11Y Instrumentation
    • An O11Y Vendor Evaluates Supporting Wasm Components
    • A Site Reliability Engineer Considers Supporting Wasm Components
• Non-goals
• API walk-through
• Stakeholder Interest & Feedback
• References & acknowledgements

Introduction

WASI Observe exposes observability ("o11y") tracing, logging, and metrics interfaces to Wasm components. The primary motivation of the interface is to allow for manual and automatic instrumentation of components that consume the interface ("guests"), while allowing components instances that implement the interface ("hosts") sufficient context to ship the produced data to an o11y vendor (DataDog, Honeycomb.) The protocol used by the host to communicate with the vendor is an implementation detail of the providing component.

An aside about the origin of the proposal

Dylibso extracted the interface proposal from an effort to port Dylibso's Observe-SDK bindings, which target Wasm Core Modules, to the Wasm Component Model; the initial proposal reflects those origins. In particular:

• The host is expected to track and maintain span state for guests.
• The interface is isomorphic across components and core modules. A runtime implementing the host interface only needs to implement the interface once.

These properties are not set in stone! This proposal is a work in progress and we're looking for interested parties to help us set technical values and direction starting in Jan.

Goals

Technical Values

• WASI Observe is a pipe. The interesting O11Y work happens at either end of this pipe: at guest instrumentation or host collection.
• Using WASI Observe should be as transparent as possible for authors of guest applications.
• TKTK(proposed value)?: Target the OTel specification as the "base layer" of functionality.

---

User Stories

A Programmer is Required to Implement O11Y Instrumentation

A programmer working at a company goes to implement a new service. The Site Reliability Engineering function of the engineering department requires that new services be instrumented using standard tooling. The programmer installs an instrumentation package using the appropriate package manager (npm, cargo, curl -o), configures the package according to the documentation, and pushes the code.

The instrumentation Just Works (TM.) In this scenario, it is not necessary for the programmer to be aware that their service is compiled to a Wasm component, or to make any adjustments to accommodate the compile target.

An O11Y Vendor Evaluates Supporting Wasm Components

A hypothetical O11Y Vendor, Omni Consumer Products ("OCP"), evaluates supporting Wasm Components as a target. OCP maintains instrumentation libraries across several language platforms: JavaScript, Ruby, Golang, Rust, Python, and others; collocated collector services meant to be run by their customers; short- and long-term data storage; and visualization dashboards.

OCP takes particular care to ensure that on-site collector services and instrumentation libraries introduce as little resource overhead as possible, both in terms of CPU time and memory use.

In order to support Wasm Components across their language platform offerings, OCP are able to introduce low-cost checks for the availability of WASI Observe functions at initialization time. Where the Observe functions are available they can be used to intercept incoming domain objects (spans, logs, metrics) with minimal modification to the incoming data.

Looking forward, OCP is considering compiling their on-site collector service to a Wasm component to more directly intercept and export o11y data off-site using fewer resources with a better security profile.

Buoyed by the success of this approach, OCP is considering automatic instrumentation of components at component instantiation points.

A Site Reliability Engineer Considers Supporting Wasm Components

A Site Reliability Engineering engineer ("SRE") working at a large software as a service company evaluates whether supporting Wasm components is feasible at this time. The SRE is responsible for the operation and maintenance of several production services. Before adopting a new platform target, the SRE considers the telemetry that platform makes available.

Having considered the telemetry available through the WASI observe tooling, the SRE determines that the Wasm component model is an acceptable platform target.

A Programmer Wants Automatic Instrumentation Of Their Component

A programmer is having trouble tracking down a problem in their component related to imports and exports during development. Without bringing in specific libraries to set up spans and trace contexts, they wish to export a trace of each invoked export and import during the lifetime of that component.

Non-goals

• TKTK

API walk-through

The full API documentation can be found here.

Stakeholder Interest & Feedback

TODO before entering Phase 3.

[This should include a list of implementers who have expressed interest in implementing the proposal]

References & acknowledgements

Many thanks for valuable feedback and advice from:

• [Person 1]
• [Person 2]
• [etc.]