hs-opentelemetry-instrumentation-auto: Plugin for instrumenting an application

This is a package candidate release! Here you can preview how this package release will appear once published to the main package index (which can be accomplished via the 'maintain' link below). Please note that once a package has been published to the main package index it cannot be undone! Please consult the package uploading documentation for more information.

[maintain] [Publish]

A GHC plugin that auto-instruments an application for emitting open telementry tracing.


[Skip to Readme]

Properties

Versions 0.1.0.0, 0.1.0.0, 0.1.0.1
Change log CHANGELOG.md
Dependencies base (>=4.17.0.0 && <4.20.0.0), bytestring (>=0.11 && <0.13), containers (>=0.6 && <0.7), directory (>=1.3 && <1.4), ghc (>=9.4.0 && <9.9.0), hs-opentelemetry-api (>=0.0.3 && <0.2), parsec (>=3.1 && <3.2), text (>=2.0 && <2.1), time (>=1.12 && <1.13), toml-parser (>=2.0.0.0 && <3.0.0.0), unliftio (>=0.2 && <0.3) [details]
License BSD-3-Clause
Author Aaron Allen
Maintainer aaronallen8455@gmail.com
Category Development
Uploaded by aaronallen8455 at 2024-03-04T17:44:44Z

Modules

[Index] [Quick Jump]

Downloads

Maintainer's Corner

Package maintainers

For package maintainers and hackage trustees


Readme for hs-opentelemetry-instrumentation-auto-0.1.0.0

[back to package description]

Open Telemetry Auto Instrumentation

This is a GHC plugin for automatically instrumenting a Haskell application with open telemetry spans based on user configuration. The instrumentation functionality is provided by hs-opentelemetry.

Quick start

Configuration

Configuration is supplied by a user defined TOML file that declares a set of rules used to determine which functions should be instrumented. The plugin will only consider top level functions that have type signatures when matching against these rules. By default the plugin looks for a config file called auto-instrument-config.toml in the project root. You can change this by passing a config file path as a plugin option, for example: -fplugin AutoInstrument -fplugin-opt AutoInstrument:my-config.toml.

Config structure

Example config

# Targets are things that should be auto instrumented for tracing.
# "constructor" means that it should match the return type of the function
# while "constraints" means that all the constraints in the "value" array must
# be present in the constraint context of the function.

[[targets]]
type = "constructor"
value = "AppMonad"

[[targets]]
type = "constraints"
value = ["MonadUnliftIO"]

# Exclusions denote types that should not be instrumented. This is primarily
# needed for when a target constraint appears in a definition's context but
# doesn't apply directly to the return type, for example:
# server :: MonadUnliftIO m => ServerT Api m

[[exclusions]]
type = "constructor"
value = "ServerT"

[[exclusions]]
type = "constructor"
value = "ConduitT"

Known pitfalls

Functions that loop can be problematic when instrumented if a new span is entered for each iteration. For example, if an application has a process that continually performs some polling action in a loop, then instrumenting that process would result in a space leak due to the mass of nested spans being allocated and retained on the heap. One way for dealing with this is to define a type synonym type NotInstrumented a = a, add an exclusion rule for it to the config, and apply it to the result type of any such looping functions:

type NotInstrumented a = a

loop :: NotInstrumented (MyApp ())
loop = do
  ...
  loop

[[exclusions]]
type = "constructor"
value = "NotInstrumented"