h$,+6      !"#$%&'()*+,-./012345None >core-telemetryOutput metrics to the terminal. This is mostly useful for debugging, but it can also be used as general output mechanism if your program is mostly concerned with gathering metrics and displaying them.None None >pcore-telemetry=Indicate which "dataset" spans and events will be posted intocore-telemetryConfigure your application to send telemetry in the form of spans and traces to the Honeycomb observability service.  context <-  ... context' <-   [] context   context' ... None >6  core-telemetryGet the MAC address of the first interface that's not the loopback device. If something goes weird then we return a valid but bogus address (in the locally administered addresses block).  core-telemetryGenerate an identifier suitable for use in a trace context. Trace identifiers are 16 bytes. We incorporate the time to nanosecond precision, the host system's MAC address, and a random element. This is similar to a version 1 UUID, but we render the least significant bits of the time stamp ordered first so that visual distinctiveness is on the left. The MAC address in the lower 48 bits is not reversed, leaving the most distinctiveness [the actual host as opposed to manufacturer OIN] hanging on the right hand edge of the identifier. The two bytes of supplied randomness are put in the middle. core-telemetryGenerate an identifier for a span. We only have 8 bytes to work with. We use the nanosecond prescision timestamp with the nibbles reversed, and then overwrite the last two bytes with the supplied random value. core-telemetry Render the  and  identifiers representing a span calling onward to another component in a distributed system. The W3C Trace Context recommendation specifies the HTTP header  traceparent2 with a version sequence (currently hard coded at 00), the 16 byte trace identifier, the 8 byte span identifier, and a flag sequence (currently quite ignored), all formatted as follows:  traceparent: 00-fd533dbf96ecdc610156482ae36c24f7-1d1e9dbf96ec4649-00 core-telemetryParse a  traceparent header into a  and , assuming it was a valid pair according to the W3C Trace Context recommendation. The expectation is that, if present in an HTTP request, these values would be passed to   to allow the program to contribute spans to an existing trace started by another program or service. core-telemetryGet the identifier of the current trace, if you are within a trace started by   or  . core-telemetryGet the identifier of the current span, if you are currently within a span created by  .core-telemetryOverride the identifier of the current span, if you are currently within a span created by  . This is an unsafe action, specifically and only for the situation where you need create a parent span for an asynchronous process whose unique identifier has already been nominated. In this scenario all child spans would already have been created with this span identifier as their parent, leaving you with the final task of creating a "root" span within the trace with that parent identifier.      None  >* core-telemetryA telemetry value that can be sent over the wire. This is a wrapper around JSON values of type string, number, or boolean. You create these using the  method provided by a " instance and passing them to the  function in a span or   if noting an event.core-telemetryRecord the name of the service that this span and its children are a part of. A reasonable default is the name of the binary that's running, but frequently you'll want to put something a bit more nuanced or specific to your application. This is the overall name of the independent service, component, or program complimenting the label set when calling , which by contrast descibes the name of the current phase, step, or even function name within the overall scope of the "service".This will end up as the  service.name parameter when exported.core-telemetry4Activate the telemetry subsystem for use within the  monad.Each exporter specified here will add setup and configuration to the context, including command-line options and environment variables needed as approrpiate:  context' <-  [ ] context This will allow you to then select the appropriate backend at runtime: $ !burgerservice --telemetry=console 8which will result in it spitting out metrics as it goes,  calories = 667.0 flavour = true meal_name = "hamburger" precise = 45.0  and so on.core-telemetry Begin a span.You need to call this from within the context of a trace, which is established either by calling  or + somewhere above this point in the program.You can nest spans as you make your way through your program, which means each span has a parent (except for the first one, which is the root span) In the context of a trace, allows an observability tool to reconstruct the sequence of events and to display them as a nested tree correspoding to your program flow.1The current time will be noted when entering the 6< this span encloses, and its duration recorded when the sub Program exits. Start time, duration, the unique identifier of the span (generated for you), the identifier of the parent, and the unique identifier of the overall trace will be appended as metadata points and then sent to the telemetry channel.core-telemetrySend a span value up by hand.This handles a number of convenient things for you, and takes care of a few edge cases.9Start a new trace. A random identifier will be generated.You must have a single "root span" immediately below starting a new trace.  program ::   () program = do  $ do ( "Service Request" $ do ... core-telemetry#Continue an existing trace using a  identifier and parent  identifier sourced externally. This is the most common case. Internal services that play a part of a larger request will inherit a job identifier, sequence number, or other externally supplied unique code. Even an internet-facing web service might have a correlation ID provided by the outside load balancers.  program ::   () program = do -- do something that gets the trace ID trace <- ... -- and something to get the parent span ID parent <- ...  ( trace) ( parent) $ do , "Internal processing" $ do ... core-telemetry&Create a new trace with the specified  identifier. Unlike  this does not set the parent  identifier, thereby marking this as a new trace and causing the first span enclosed within this trace to be considered the "root" span of the trace. This is unusual and should only expected to be used in concert with the ; override to create a root spans in asynchronous processes after9 all the child spans have already been composed and sent.>Most times, you don't need this. You're much better off using  to create a root span. However, life is not kind, and sometimes bad things happen to good abstractions. Maybe you're tracing your build system, which isn't obliging enough to be all contained in one Haskell process, but is a half-dozen steps shotgunned across several different processes. In situations like this, it's useful to be able to generate a  identifier and  identifier, use that as the parent across several different process executions, hanging children spans off of this as you go, then manually send up the root span at the end of it all.  trace <- ... unique <- ... -- many child spans in other processes have used these as trace -- identifiers and parent span identifier. Now form the root span thereby -- finishing the trace.  trace $ do $ "Launch Missiles" $ do ! start  unique  [  ... ] core-telemetry%Add measurements to the current span.   [  "calories" (667 :: 7) , % "precise" measurement ,  "meal_name" ("hamburger" :: 8) ,  "flavour" 9 ] The 3 function is a method provided by instances of the  Telemtetry typeclass which is mostly a wrapper around constructing key/value pairs suitable to be sent as measurements up to an observability service. core-telemetryRecord telemetry about an event. Specify a label for the event and then whichever metrics you wish to record.The emphasis of this package is to create traces and spans. There are, however, times when you just want to send telemetry about an event. You can use   to accomplish this.If you do call  ' within an enclosing span created with  (the usual and expected use case) then this event will be "linked" to this span so that the observability tool can display it attached to the span in the in which it occured.   & "Make tea" [  "sugar" : ] !core-telemetry,Override the start time of the current span.Under normal circumstances this shouldn't be necessary. The start and end of a span are recorded automatically when calling . Observabilty tools are designed to be used live; traces and spans should be created in real time in your code."core-telemetry8Reset the accumulated metadata metrics to the emtpy set.This isn't something you'd need in normal circumstances, as inheriting contextual metrics from surrounding code is usually what you want. But if you have a significant change of setting then clearing the attached metadata may be appropriate; after all, observability tools visualizing a trace will show you the context an event was encountered in.'core-telemetry%The usual warning about assuming the  ByteString is ASCII or UTF-8 applies here. Don't use this to send binary mush.(core-telemetry%The usual warning about assuming the  ByteString is ASCII or UTF-8 applies here. Don't use this to send binary mush. !"! "None >+?5core-telemetryOutput metrics to stdout" in the form of a raw JSON object.55None+^$  !"5; !"#$%&'()*    +,-./0123456789:;<=>?@ABCDEFGHCDICDJ-core-telemetry-0.2.2.0-LhJioUnZQU09VzLhHpr468Core.Telemetry.ObservabilityCore.Telemetry.ConsoleCore.Telemetry.GeneralCore.Telemetry.HoneycombCore.Telemetry.IdentifiersCore.Telemetry.StructuredCore.Program.Execute configureinitializeTelemetry executeWith usingTrace beginTrace encloseSpanProgramconsoleExporterNoneCore.Telemetry+core-program-0.4.6.4-2re5sTHsKujGAB4dEmp6shCore.Program.ContextSpanTraceExportergeneralExporterDatasethoneycombExporterhostMachineIdentitycreateIdentifierTracetoHexReversed64 toHexNormal64toHexReversed32 toHexNormal32createIdentifierSpancreateTraceParentHeaderparseTraceParentHeadergetIdentifierTracegetIdentifierSpansetIdentifierSpanLabel Telemetrymetric MetricValuesetServiceName usingTrace' telemetry sendEvent setStartTime clearMetrics$fTelemetryJsonValue$fTelemetryBool$fTelemetryText$fTelemetryText0$fTelemetryByteString$fTelemetryByteString0 $fTelemetry[]$fTelemetryRope$fTelemetryScientific$fTelemetryDouble$fTelemetryFloat$fTelemetryInteger$fTelemetryWord64$fTelemetryWord32$fTelemetryInt64$fTelemetryInt32$fTelemetryInt$fShowMetricValuestructuredExporterghc-prim GHC.TypesInt(core-text-0.3.7.1-HMe6JnWxzAuL39oitLQVXoCore.Text.RopeRopeTrueFalse