wasmtime / PR #1796 wiggle: support logging via `tracing`... · git-wasmtime · Zulip Chat Archive

Stream: git-wasmtime

Topic: wasmtime / PR #1796 wiggle: support logging via `tracing`...

Wasmtime GitHub notifications bot (May 31 2020 at 02:07):

pchickey opened PR #1796 from pch/wiggle_tracing to master:

Wasmtime GitHub notifications bot (May 31 2020 at 02:13):

pchickey edited PR #1796 from pch/wiggle_tracing to master:

based on #1790

Wasmtime GitHub notifications bot (May 31 2020 at 02:17):

pchickey edited PR #1796 from pch/wiggle_tracing to master:

based on #1790.
Adds tracing logs to wiggle as an optional feature. Retails existing logging support by default, but we could consider removing it if everyone is satisfied with tracing.

We use tracing by default at Fastly, so I'd like to use it in wiggle and wasi-common without adapters if possible. Tracing has a couple of advantages over log that make it well suited here:

The concept of spans, which are natural to use in wiggle-generated functions where we want to log the arguments of a function, then later when an inner func returns we want to log the return values. the argument values and return value s are part of the same span, which means the backend can automatically correlate them, rather than have to associate them by searching on some common part of the text

(stable) support for structured fields (in log this is noted as unstable and called kv support), which also naturally matches to the names of arguments / return values we already have in witx, and keeps that structure around longer so that it can be e.g. encoded in json by the backend that sends it to some logging endpoint that understands json

tracing statements that are disabled (marked as uninteresting, essentially) by the backend are very low overhead - its one atomic load to determine whether a hook is disabled.

Wasmtime GitHub notifications bot (Jun 02 2020 at 19:32):

pchickey updated PR #1796 from pch/wiggle_tracing to master:

based on #1790.
Adds tracing logs to wiggle as an optional feature. Retails existing logging support by default, but we could consider removing it if everyone is satisfied with tracing.

We use tracing by default at Fastly, so I'd like to use it in wiggle and wasi-common without adapters if possible. Tracing has a couple of advantages over log that make it well suited here:

The concept of spans, which are natural to use in wiggle-generated functions where we want to log the arguments of a function, then later when an inner func returns we want to log the return values. the argument values and return value s are part of the same span, which means the backend can automatically correlate them, rather than have to associate them by searching on some common part of the text

(stable) support for structured fields (in log this is noted as unstable and called kv support), which also naturally matches to the names of arguments / return values we already have in witx, and keeps that structure around longer so that it can be e.g. encoded in json by the backend that sends it to some logging endpoint that understands json

tracing statements that are disabled (marked as uninteresting, essentially) by the backend are very low overhead - its one atomic load to determine whether a hook is disabled.

Wasmtime GitHub notifications bot (Jun 02 2020 at 23:00):

pchickey updated PR #1796 from pch/wiggle_tracing to master:

based on #1790.
Adds tracing logs to wiggle as an optional feature. Retails existing logging support by default, but we could consider removing it if everyone is satisfied with tracing.

We use tracing by default at Fastly, so I'd like to use it in wiggle and wasi-common without adapters if possible. Tracing has a couple of advantages over log that make it well suited here:

The concept of spans, which are natural to use in wiggle-generated functions where we want to log the arguments of a function, then later when an inner func returns we want to log the return values. the argument values and return value s are part of the same span, which means the backend can automatically correlate them, rather than have to associate them by searching on some common part of the text

(stable) support for structured fields (in log this is noted as unstable and called kv support), which also naturally matches to the names of arguments / return values we already have in witx, and keeps that structure around longer so that it can be e.g. encoded in json by the backend that sends it to some logging endpoint that understands json

tracing statements that are disabled (marked as uninteresting, essentially) by the backend are very low overhead - its one atomic load to determine whether a hook is disabled.

Wasmtime GitHub notifications bot (Jun 03 2020 at 00:47):

pchickey updated PR #1796 from pch/wiggle_tracing to master:

based on #1790.
Adds tracing logs to wiggle as an optional feature. Retails existing logging support by default, but we could consider removing it if everyone is satisfied with tracing.

We use tracing by default at Fastly, so I'd like to use it in wiggle and wasi-common without adapters if possible. Tracing has a couple of advantages over log that make it well suited here:

The concept of spans, which are natural to use in wiggle-generated functions where we want to log the arguments of a function, then later when an inner func returns we want to log the return values. the argument values and return value s are part of the same span, which means the backend can automatically correlate them, rather than have to associate them by searching on some common part of the text

(stable) support for structured fields (in log this is noted as unstable and called kv support), which also naturally matches to the names of arguments / return values we already have in witx, and keeps that structure around longer so that it can be e.g. encoded in json by the backend that sends it to some logging endpoint that understands json

tracing statements that are disabled (marked as uninteresting, essentially) by the backend are very low overhead - its one atomic load to determine whether a hook is disabled.

Wasmtime GitHub notifications bot (Jun 03 2020 at 01:25):

pchickey updated PR #1796 from pch/wiggle_tracing to master:

based on #1790.
Adds tracing logs to wiggle as an optional feature. Retails existing logging support by default, but we could consider removing it if everyone is satisfied with tracing.

We use tracing by default at Fastly, so I'd like to use it in wiggle and wasi-common without adapters if possible. Tracing has a couple of advantages over log that make it well suited here:

The concept of spans, which are natural to use in wiggle-generated functions where we want to log the arguments of a function, then later when an inner func returns we want to log the return values. the argument values and return value s are part of the same span, which means the backend can automatically correlate them, rather than have to associate them by searching on some common part of the text

(stable) support for structured fields (in log this is noted as unstable and called kv support), which also naturally matches to the names of arguments / return values we already have in witx, and keeps that structure around longer so that it can be e.g. encoded in json by the backend that sends it to some logging endpoint that understands json

tracing statements that are disabled (marked as uninteresting, essentially) by the backend are very low overhead - its one atomic load to determine whether a hook is disabled.

Wasmtime GitHub notifications bot (Jun 03 2020 at 01:42):

pchickey updated PR #1796 from pch/wiggle_tracing to master:

based on #1790.
Adds tracing logs to wiggle as an optional feature. Retails existing logging support by default, but we could consider removing it if everyone is satisfied with tracing.

We use tracing by default at Fastly, so I'd like to use it in wiggle and wasi-common without adapters if possible. Tracing has a couple of advantages over log that make it well suited here:

The concept of spans, which are natural to use in wiggle-generated functions where we want to log the arguments of a function, then later when an inner func returns we want to log the return values. the argument values and return value s are part of the same span, which means the backend can automatically correlate them, rather than have to associate them by searching on some common part of the text

(stable) support for structured fields (in log this is noted as unstable and called kv support), which also naturally matches to the names of arguments / return values we already have in witx, and keeps that structure around longer so that it can be e.g. encoded in json by the backend that sends it to some logging endpoint that understands json

tracing statements that are disabled (marked as uninteresting, essentially) by the backend are very low overhead - its one atomic load to determine whether a hook is disabled.

Wasmtime GitHub notifications bot (Jun 03 2020 at 17:52):

pchickey updated PR #1796 from pch/wiggle_tracing to master:

based on #1790.
Adds tracing logs to wiggle as an optional feature. Retails existing logging support by default, but we could consider removing it if everyone is satisfied with tracing.

We use tracing by default at Fastly, so I'd like to use it in wiggle and wasi-common without adapters if possible. Tracing has a couple of advantages over log that make it well suited here:

The concept of spans, which are natural to use in wiggle-generated functions where we want to log the arguments of a function, then later when an inner func returns we want to log the return values. the argument values and return value s are part of the same span, which means the backend can automatically correlate them, rather than have to associate them by searching on some common part of the text

(stable) support for structured fields (in log this is noted as unstable and called kv support), which also naturally matches to the names of arguments / return values we already have in witx, and keeps that structure around longer so that it can be e.g. encoded in json by the backend that sends it to some logging endpoint that understands json

tracing statements that are disabled (marked as uninteresting, essentially) by the backend are very low overhead - its one atomic load to determine whether a hook is disabled.

Wasmtime GitHub notifications bot (Jun 03 2020 at 17:53):

pchickey has marked PR #1796 as ready for review.

Wasmtime GitHub notifications bot (Jun 03 2020 at 17:53):

pchickey requested kubkon for a review on PR #1796.

Wasmtime GitHub notifications bot (Jun 03 2020 at 17:53):

pchickey requested alexcrichton and kubkon for a review on PR #1796.

Wasmtime GitHub notifications bot (Jun 03 2020 at 17:55):

pchickey updated PR #1796 from pch/wiggle_tracing to master:

based on #1790.
Adds tracing logs to wiggle as an optional feature. Retails existing logging support by default, but we could consider removing it if everyone is satisfied with tracing.

We use tracing by default at Fastly, so I'd like to use it in wiggle and wasi-common without adapters if possible. Tracing has a couple of advantages over log that make it well suited here:

The concept of spans, which are natural to use in wiggle-generated functions where we want to log the arguments of a function, then later when an inner func returns we want to log the return values. the argument values and return value s are part of the same span, which means the backend can automatically correlate them, rather than have to associate them by searching on some common part of the text

(stable) support for structured fields (in log this is noted as unstable and called kv support), which also naturally matches to the names of arguments / return values we already have in witx, and keeps that structure around longer so that it can be e.g. encoded in json by the backend that sends it to some logging endpoint that understands json

tracing statements that are disabled (marked as uninteresting, essentially) by the backend are very low overhead - its one atomic load to determine whether a hook is disabled.

Wasmtime GitHub notifications bot (Jun 03 2020 at 17:57):

pchickey edited PR #1796 from pch/wiggle_tracing to master:

Wiggle generated code now emits code that uses tracing for logging.

We use tracing by default at Fastly, so I'd like to use it in wiggle and wasi-common without adapters if possible. Tracing has a couple of advantages over log that make it well suited here:

The concept of spans, which are natural to use in wiggle-generated functions where we want to log the arguments of a function, then later when an inner func returns we want to log the return values. the argument values and return value s are part of the same span, which means the backend can automatically correlate them, rather than have to associate them by searching on some common part of the text

(stable) support for structured fields (in log this is noted as unstable and called kv support), which also naturally matches to the names of arguments / return values we already have in witx, and keeps that structure around longer so that it can be e.g. encoded in json by the backend that sends it to some logging endpoint that understands json

tracing statements that are disabled (marked as uninteresting, essentially) by the backend are very low overhead - its one atomic load to determine whether a hook is disabled.

Last updated: Oct 23 2024 at 20:03 UTC