OpenTelemetry proof of concept

[TheAngryByrd]

Since F# 7 now contains ActivitySource traces, this adds some barebones functionality with OpenTelemetry.

• Currently just exporting to zipkin but we should probably just do just basic OTel exporter and maybe provide a nice docker-compose file with an otel config with good defaults on exporting (@cartermp maybe could help here?)
• Looks like the old EventListener stuff was removed in favorite of Activity related traces, so anything relying on that is now broke. Maybe we should figure out a way to replace that. Maybe ActivityListener or Customer Exporter ?
• This will also help verifying all the parallel optimization work such as Parallel project analysis behind a feature flag dotnet/fsharp#13521 and eventually Parallel type-checking in compilation (behind a feature flag) dotnet/fsharp#14494

[baronfel]

Have you seen the ambient Activity data for the StreamJsonRpc library coming through in your testing? https://github.com/microsoft/vs-streamjsonrpc/blob/main/doc/tracecontext.md for details, but I expect that library to be giving us a parent span for each LSP call for free. Oh, we may need to set JsonRpc.ActivityTracingStrategy to ActivityTracingStrategy to get this to light up.

[TheAngryByrd]

Have you seen the ambient Activity data for the StreamJsonRpc library coming through in your testing? https://github.com/microsoft/vs-streamjsonrpc/blob/main/doc/tracecontext.md for details, but I expect that library to be giving us a parent span for each LSP call for free.

No, I looked into that and it doesn't seem like they setup and ActivitySource. Seems like it relies on the caller (LSP lib in this case) to set it up? I didn't see much in the way of examples here unfortunately.

[TheAngryByrd]

With JsonRPC

[cartermp]

Two other considerations:

• Should this be augmented to include an OTLP Exporter (which should be the default), then we can have it respect some of the OTLP cli args and maybe Ionide could have a settings update that lets you plug them in. That would make it capable, and relatively clean, to support any tracing backend
• We should probably not try to involve a docker-compose setup with a collector here. At least that's my gut feeling. While the collector is great for production apps, it's really designed to run as a stateless proxy in your production infrastructure. The collector as a general purpose client-side trace gatherer might not work for some people (e.g., Windows without running windows subsystem for losers).

[baronfel]

There is a surprising lack of embedded-otel viewer extensions for VSCode :)

[cartermp]

Yeah, makes me sad! This is probably the closest nice desktop viewer tool we have: https://github.com/CtrlSpice/otel-desktop-viewer

[baronfel]

otel-desktop-viewer didn't run on Windows, but I just submitted a PR to fix that.

[TheAngryByrd]

Paket Lock Diff Report

This report was generated via Paket Lock Diff

Additions - (16)

• Main - (16)
  • Google.Protobuf - 3.22.0
  • Grpc - 2.46.6
  • Grpc.Core - 2.46.6
  • Grpc.Core.Api - 2.51.0
  • Grpc.Net.Client - 2.51.0
  • Grpc.Net.Common - 2.51.0
  • Microsoft.Extensions.Configuration - 6.0.1
  • Microsoft.Extensions.Configuration.Abstractions - 6.0.0
  • Microsoft.Extensions.Configuration.Binder - 6.0.0
  • Microsoft.Extensions.DependencyInjection - 6.0.1
  • Microsoft.Extensions.Logging - 6.0.0
  • Microsoft.Extensions.Logging.Configuration - 6.0.0
  • Microsoft.Extensions.Options.ConfigurationExtensions - 6.0.0
  • OpenTelemetry - 1.3.2
  • OpenTelemetry.Api - 1.3.2
  • OpenTelemetry.Exporter.OpenTelemetryProtocol - 1.3.2

Removals - (0)

Version Upgrades - (5)

• Main - (5)
  • Patch - (5)
    • FSharp.Core - 7.0.0 -> 7.0.200
    • Ionide.ProjInfo - 0.61.0 -> 0.61.2
    • Ionide.ProjInfo.FCS - 0.61.0 -> 0.61.2
    • Ionide.ProjInfo.ProjectSystem - 0.61.0 -> 0.61.2
    • Ionide.ProjInfo.Sln - 0.61.0 -> 0.61.2

Version Downgrades - (0)

[baronfel]

nit: there are some OTel semantic tags for source files and function calls:

https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/semantic_conventions/span-general.md#source-code-attributes

Maybe use these specifically:

• code.function for the FSAC type+member name?
• code.namespace for the module
• code.filepath for the passed-in file
• code.lineno for calls that specify a position
• code.column for calls that specify a position

totally optional, but IIRC some tools pick these up.

[TheAngryByrd]

Often a span is closely tied to a certain unit of code that is logically responsible for handling the operation that the span describes (usually the method that starts the span). For an HTTP server span, this would be the function that handles the incoming request

FsOpenTelemetry handles this for us (although column isn't really available).

[TheAngryByrd]

Example with exception being recorded (dont worry this is was intentionally throwing to get this):

[TheAngryByrd]

Left some more comments. Outside of that there's some additional things that could be done.

• Still could add tracing to places like Commands or other files you think are useful.

[TheAngryByrd]

As noted, FCS doesn't start their spans with tags, so we can't get them immediately to report on. This will update our notifications with tag info if it's still around.

[baronfel]

This is so cool 😎