{"id":18016535,"url":"https://github.com/webassembly/wasi-observe","last_synced_at":"2025-03-26T18:32:12.600Z","repository":{"id":212713949,"uuid":"731275656","full_name":"WebAssembly/wasi-observe","owner":"WebAssembly","description":"Observability World for WASI","archived":false,"fork":false,"pushed_at":"2025-03-05T18:27:59.000Z","size":87,"stargazers_count":17,"open_issues_count":3,"forks_count":6,"subscribers_count":13,"default_branch":"main","last_synced_at":"2025-03-22T06:41:48.420Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"Just","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/WebAssembly.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE.md","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":"ROADMAP.md","authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2023-12-13T18:04:40.000Z","updated_at":"2025-03-05T18:28:04.000Z","dependencies_parsed_at":"2024-10-30T04:32:30.402Z","dependency_job_id":null,"html_url":"https://github.com/WebAssembly/wasi-observe","commit_stats":null,"previous_names":["dylibso/wasi-observe","webassembly/wasi-observe"],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/WebAssembly%2Fwasi-observe","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/WebAssembly%2Fwasi-observe/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/WebAssembly%2Fwasi-observe/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/WebAssembly%2Fwasi-observe/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/WebAssembly","download_url":"https://codeload.github.com/WebAssembly/wasi-observe/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":245712995,"owners_count":20660331,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-10-30T04:18:23.532Z","updated_at":"2025-03-26T18:32:12.342Z","avatar_url":"https://github.com/WebAssembly.png","language":"Just","funding_links":[],"categories":[],"sub_categories":[],"readme":"# WASI Observe World\n\nA proposed [WebAssembly System Interface](https://github.com/WebAssembly/WASI) API.\n\n### Current Phase\n\nWASI Observe is currently in [Phase 1].\n\n[Phase 1]: https://github.com/WebAssembly/WASI/blob/42fe2a3ca159011b23099c3d10b5b1d9aff2140e/docs/Proposals.md#phase-1---feature-proposal-cg\n\n### Meetings\n\nMeetings are **fortnightly** (held every other week, starting on `2024-W05`\n(`2024 Jan 31`) on **Wednesdays at UTC 16:00**.\n\nContact [**@calebschoepp**](https://github.com/calebschoepp) via `caleb.schoepp\nat fermyon dot com` to request an invite. Participants must be W3C [WebAssembly\nCG members](https://www.w3.org/community/webassembly/).\n\n### Roadmap\n\n- [Phase 1](./ROADMAP.md)\n\n### Champions\n\n- Caleb Schoepp ([Fermyon][fermyon])\n\n[fermyon]: https://www.fermyon.com/\n[dylibso]: https://dylibso.com/\n\n### Portability Criteria\n\nTODO before entering Phase 2.\n\n## Table of Contents\n\n- [Introduction](#introduction)\n    - [An aside](#an-aside-about-the-origin-of-the-proposal)\n- [Goals](#goals)\n    - [Technical Values](#technical-values)\n    - [User Stories](#user-stories)\n        - [A Programmer is Required to Implement O11Y Instrumentation](#a-programmer-is-required-to-implement-o11y-instrumentation)\n        - [An O11Y Vendor Evaluates Supporting Wasm Components](#an-o11y-vendor-evaluates-supporting-wasm-components)\n        - [A Site Reliability Engineer Considers Supporting Wasm Components](#a-site-reliability-engineer-considers-supporting-wasm-components)\n- [Non-goals](#non-goals)\n- [API walk-through](#api-walk-through)\n- [Stakeholder Interest \u0026 Feedback](#stakeholder-interest--feedback)\n- [References \u0026 acknowledgements](#references--acknowledgements)\n\n### Introduction\n\nWASI Observe exposes observability (\"o11y\") tracing, logging, and metrics\ninterfaces to Wasm components. The primary motivation of the interface is to\nallow for manual and automatic instrumentation of components that consume the\ninterface (**\"guests\"**), while allowing components instances that implement\nthe interface (**\"hosts\"**) sufficient context to ship the produced data to an\no11y **vendor** (DataDog, Honeycomb.) The protocol used by the host to\ncommunicate with the vendor is an implementation detail of the providing\ncomponent.\n\n#### An aside about the origin of the proposal\n\nDylibso extracted the interface proposal [from an effort][dylibso-pr] to port\nDylibso's Observe-SDK bindings, which target Wasm Core Modules, to the Wasm\nComponent Model; the initial proposal reflects those origins. In particular:\n\n- The host is expected to track and maintain span state for guests.\n- The interface is isomorphic across components and core modules. A runtime\n  implementing the host interface only needs to implement the interface once.\n\nThese properties are not set in stone! This proposal is a work in progress and\nwe're looking for interested parties to help us set technical values and direction\nstarting in Jan.\n\n[dylibso-pr]: https://github.com/dylibso/observe-sdk/pull/128\n\n### Goals\n\n#### Technical Values\n\n- WASI Observe is a pipe. The interesting O11Y work happens at either end of\n  this pipe: at guest instrumentation or host collection.\n- Using WASI Observe should be as transparent as possible for authors of guest\n  applications.\n- TKTK(proposed value)?: Target the OTel specification as the \"base layer\" of functionality.\n\n---\n\n#### User Stories\n\n##### A Programmer is Required to Implement O11Y Instrumentation\n\nA programmer working at a company goes to implement a new service. The Site\nReliability Engineering function of the engineering department requires that\nnew services be instrumented using standard tooling. The programmer installs an\ninstrumentation package using the appropriate package manager (`npm`, `cargo`,\n`curl -o`), configures the package according to the documentation, and pushes\nthe code.\n\nThe instrumentation Just Works (TM.) In this scenario, it is not necessary for\nthe programmer to be aware that their service is compiled to a Wasm component,\nor to make any adjustments to accommodate the compile target.\n\n##### An O11Y Vendor Evaluates Supporting Wasm Components\n\nA hypothetical O11Y Vendor, Omni Consumer Products (\"OCP\"), evaluates\nsupporting Wasm Components as a target. OCP maintains instrumentation libraries\nacross several language platforms: JavaScript, Ruby, Golang, Rust, Python, and\nothers; collocated collector services meant to be run by their customers;\nshort- and long-term data storage; and visualization dashboards.\n\nOCP takes particular care to ensure that on-site collector services and\ninstrumentation libraries introduce as little resource overhead as possible,\nboth in terms of CPU time and memory use.\n\nIn order to support Wasm Components across their language platform offerings,\nOCP are able to introduce low-cost checks for the availability of WASI Observe\nfunctions at initialization time. Where the Observe functions are available\nthey can be used to intercept incoming domain objects (spans, logs, metrics)\nwith minimal modification to the incoming data.\n\nLooking forward, OCP is considering compiling their on-site collector service\nto a Wasm component to more directly intercept and export o11y data off-site\nusing fewer resources with a better security profile.\n\nBuoyed by the success of this approach, OCP is considering automatic\ninstrumentation of components at component instantiation points.\n\n##### A Site Reliability Engineer Considers Supporting Wasm Components\n\nA Site Reliability Engineering engineer (\"SRE\") working at a large software as\na service company evaluates whether supporting Wasm components is feasible at\nthis time. The SRE is responsible for the operation and maintenance of several\nproduction services. Before adopting a new platform target, the SRE considers\nthe telemetry that platform makes available.\n\nHaving considered the telemetry available through the WASI observe tooling, the\nSRE determines that the Wasm component model is an acceptable platform target.\n\n##### A Programmer Wants Automatic Instrumentation Of Their Component\n\nA programmer is having trouble tracking down a problem in their component related\nto imports and exports during development. Without bringing in specific libraries\nto set up spans and trace contexts, they wish to export a trace of each invoked\nexport and import during the lifetime of that component.\n\n### Non-goals\n\n- TKTK\n\n### API walk-through\n\nThe full API documentation can be found [here](imports.md).\n\n### Stakeholder Interest \u0026 Feedback\n\nTODO before entering Phase 3.\n\n[This should include a list of implementers who have expressed interest in implementing the proposal]\n\n### References \u0026 acknowledgements\n\nMany thanks for valuable feedback and advice from:\n\n- [Person 1]\n- [Person 2]\n- [etc.]\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fwebassembly%2Fwasi-observe","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fwebassembly%2Fwasi-observe","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fwebassembly%2Fwasi-observe/lists"}