GithubHelp home page GithubHelp logo

lightstep / lightstep-tracer-javascript Goto Github PK

View Code? Open in Web Editor NEW
77.0 71.0 66.0 7.95 MB

Lightstep distributed tracing library for Node.js and the browser

Home Page: https://lightstep.com

License: MIT License

JavaScript 98.44% CSS 0.57% HTML 0.19% Makefile 0.52% Shell 0.27%
opentracing

lightstep-tracer-javascript's Introduction

lightstep-tracer [Deprecated]

This instrumentation is no longer recommended. Please review documentation on setting up and configuring the OpenTelemetry Node.js Launcher or OpenTelemetry JS (Browser) for more information on migrating to OpenTelemetry.

npm version Circle CI MIT license

In August 2023, Lightstep became ServiceNow Cloud Observability To ease the transition, all code artifacts will continue to use the Lightstep name. You don't need to do anything to keep using this repository.

LightStep distributed tracing library for Node.js and the browser.

Installation

npm install --save lightstep-tracer opentracing

All modern browsers and Node versions >= 12 are supported. Users who need support for Node 8 and 10 can use v0.32.0 and prior.

Getting started

To use LightStep as the OpenTracing binding, initialize the global Tracer with the LightStep implementation:

var opentracing = require('opentracing');
var lightstep   = require('lightstep-tracer');

opentracing.initGlobalTracer(new lightstep.Tracer({
    access_token   : '{your_access_token}',
    component_name : '{your_service_or_app_name}',
}));

The LightStep JavaScript Tracing Cookbook is a good next stop for information on how to quickly instrument your system. If you want to try something out quickly in your browser code, see the browser quick start example.

The browser version of the code can be explicitly included using the following, which can be helpful in some browserify (or similar) setups:

var lightstep = require('lightstep-tracer/browser');

LightStep-specific API

The OpenTracing standard JavaScript API is documented here. The following describes LightStep-specific options and methods.

LightStep


new Tracer(options)

Required options

  • access_token string required - the project access token
  • component_name string required - the string identifier for the application, service, or process

Standard options

  • verbosity number optional, default=1 - controls the level of logging to the console
    • 0 - the client library will never log to the console
    • 1 - error reporting will be throttled to the first error per minute
    • 2 - all errors are logged to the console
    • 3 - all errors, warnings, and info statements are logged to the console
    • 4 - all log statements, including debugging details
  • collector_host string optional - custom collector hostname
  • collector_port number optional - custom collector port
  • collector_path string optional - custom collector base path (if served behind a reverse proxy)
  • collector_encryption string optional, default='tls'
    • tls - use HTTPS encrypted connections
    • none - use HTTP plain-text connections

Browser-specific initialization options

  • instrument_page_load bool - creates a long-lived single span for the entire page view and is recommended for short-page visits in a multi-page website. For a single-page web app, this behavior may be undesirable. Defaults to false. This must be set at initialization, changes after initialization will have no effect.

  • xhr_instrumentation bool - if false, disables automatic instrumentation of XMLHttpRequests (XHRs). This must be set at initialization; changes after initialization will have no effect. Defaults to false.

  • xhr_url_inclusion_patterns RegExp[] - an array of regular expressions used to whitelist URLs for XMLHttpRequest auto-instrumentation. The default value is wildcard matching all strings. For a given URL to be instrumented, it must match at least one regular expression in xhr_url_inclusion_patterns and not match any regular expressions in xhr_url_exclusion_patterns.

  • xhr_url_exclusion_patterns RegExp[] - an array of regular expressions used to exclude URLs from XMLHttpRequest auto-instrumentation. The default value is an empty array. For a given URL to be instrumented, it must match at least one regular expression in xhr_url_inclusion_patterns and not match any regular expressions in xhr_url_exclusion_patterns.

  • xhr_url_header_inclusion_patterns RegExp[] - an array of regular expressions used to include URLs which auto-instrumented XMLHttpRequests add tracing headers to. The default value is wildcard matching all strings. For a given URL to have tracing headers added, it must match at least one regular expression in xhr_url_header_inclusion_patterns and not match any regular expressions in xhr_url_header_exclusion_patterns.

  • xhr_url_header_exclusion_patterns RegExp[] - an array of regular expressions used to exclude URLs that auto-instrumented XMLHttpRequests add tracing headers to. The default value is an empty array. For a given URL to have tracing headers added, it must match at least one regular expression in xhr_url_header_inclusion_patterns and not match any regular expressions in xhr_url_header_exclusion_patterns.

  • fetch_instrumentation bool - if false, disables automatic instrumentation of window.fetch. This must be set at initialization; changes after initialization will have no effect. Defaults to false.

  • fetch_url_inclusion_patterns RegExp[] - an array of regular expressions used to whitelist URLs for window.fetch auto-instrumentation. The default value is wildcard matching all strings. For a given URL to be instrumented, it must match at least one regular expression in fetch_url_inclusion_patterns and not match any regular expressions in fetch_url_exclusion_patterns.

  • fetch_url_exclusion_patterns RegExp[] - an array of regular expressions used to exclude URLs from window.fetch auto-instrumentation. The default value is an empty array. For a given URL to be instrumented, it must match at least one regular expression in fetch_url_inclusion_patterns and not match any regular expressions in fetch_url_exclusion_patterns.

  • fetch_url_header_inclusion_patterns RegExp[] - an array of regular expressions used to include URLs for window.fetch tracer header inclusion. The default value is wildcard matching all strings. For a given URL to be have tracing headers added, it must match at least one regular expression in fetch_url_header_inclusion_patterns and not match any regular expressions in fetch_url_header_exclusion_patterns.

  • fetch_url_header_exclusion_patterns RegExp[] - an array of regular expressions used to exclude header insertion onto URLs from window.fetch auto-instrumentation. The default value is an empty array. For a given URL to have tracing headers added, it must match at least one regular expression in fetch_url_header_inclusion_patterns and not match any regular expressions in fetch_url_header_exclusion_patterns.

  • include_cookies bool - if true, includes cookies in the span logs for both window.fetch and XMLHttpRequest. Defaults to true.

node-specific initialization options

  • nodejs_instrumentation bool - if false, disables automatic instrumentation of node requests. This must be set at initialization; changes after initialization will have no effect. Defaults to false.

  • nodejs_url_inclusion_patterns RegExp[] - an array of regular expressions used to whitelist URLs for the http and https modules auto-instrumentation. The default value is wildcard matching all strings. For a given URL to be instrumented, it must match at least one regular expression in nodejs_url_inclusion_patterns and not match any regular expressions in nodejs_url_exclusion_patterns.

  • nodejs_url_exclusion_patterns RegExp[] - an array of regular expressions used to exclude URLs from the http and https modules auto-instrumentation. The default value is an empty array. For a given URL to be instrumented, it must match at least one regular expression in nodejs_url_inclusion_patterns and not match any regular expressions in nodejs_url_exclusion_patterns.

Non-standard options

NOTE: Future API compatibility on non-standard options is not guaranteed.

  • disable_reporting_loop bool optional, default=false - if true, the timer that automatically sends reports to the collector will be disabled. This option is independent of disable_report_on_exit.
  • disable_report_on_exit bool optional, default=false - if true, the final report that is automatically sent at process exit in Node or page unload in the browser will not be sent.
  • report_timeout_millis number optional, default=30000 - the default timeout value, in milliseconds, for reports to the LightStep collector
  • gzip_json_requests bool optional, default=true - if true, the reports will be gzipped before sent to the collector.
  • default_span_tags string optional - an associative array of tags to add to every span started by the tracer (e.g., the active user id in a browser client)
  • delay_initial_report_millis int optional, default=1000 - maximum additional delay of the initial report in addition to the normal reporting interval. A value between zero and this maximum will be selected as the actual delay. This can be useful when concurrently launching a large number of new processes and there is a desire to distribute the initial reports over a window of time.
  • error_throttle_millis int optional, default=60000 - when verbosity is set to 1, this the minimum time between logged errors.
  • transport string optional, default=proto - when transport is set to thrift, the Tracer will use Thrift as its transport instead of Proto over HTTP. (Not supported in React-Native)
  • logger function(level: string, message: string, payload: any): void optional - specify a custom logger function. Possible level values are debug, info, warn and error. By default messages will be logged to the console.
  • disable_meta_event_reporting bool optional, default=false - when disable_meta_event_reporting is set to true, the tracer will disable meta event reporting even if requested by the Satellite.
  • propagators dictionary optional, defaults={ [opentracing.FORMAT_HTTP_HEADERS]: new lightstep.LightStepPropagator(), [opentracing.FORMAT_TEXT_MAP]: new lightstep.LightStepPropagator(), [opentracing.FORMAT_BINARY]: new lightstep.UnsupportedPropagator() }: Allows inject/extract to use custom propagators for different formats. This package includes B3Propagator that supports B3 headers on text maps and http headers. DDPropagator supports DataDog trace headers.
  • clear_span_buffer_consecutive_errors number optional, default=null - each consecutive buffer flush error will check to see if clear_span_buffer_consecutive_errors has been reached. If reached, the span buffer will be emptied. This is useful for auto-recovering from errors based on request size constraints, particularly max payload size on intermediate load balancers.

An example configuration using custom propagators might look like:

const tracer = new lightstep.Tracer({
  propagators: {
    [opentracing.FORMAT_HTTP_HEADERS]: new lightstep.DDPropagator(),
    [opentracing.FORMAT_TEXT_MAP]: new lightstep.B3Propagator()
  }
})

SpanImp


generateTraceURL()

Returns an absolute URL to the LightStep application for the trace containing this span. It is safe to call this method after finish().

...
span.finish();

var url = span.generateTraceURL())
console.log('View the trace for this span at:', url);

Release process using circleCI

  1. Run command
make release RELEASE_TYPE=patch

License

The MIT License.

Copyright (c) 2016, LightStep

lightstep-tracer-javascript's People

Contributors

aroc avatar austinlparker avatar bcronin avatar bensigelman avatar bg451 avatar bhs avatar charud avatar dependabot[bot] avatar dm03514 avatar eiathom avatar frenchfrywpepper avatar iredelmeier avatar ishg avatar ja30278 avatar karan-taneja avatar kirbysayshi avatar luk3thomas avatar marmaladebacon avatar mattcobb avatar mwear avatar nimeshksingh avatar obecny avatar odeit avatar rowno avatar sbaum1994 avatar smithclay avatar snyk-bot avatar stephen avatar tedpennings avatar trescenzi avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

lightstep-tracer-javascript's Issues

Limited support for Symbol

I started seeing our CI builds fail after we upgraded from version 0.9.21

        ReferenceError: Can't find variable: Symbol

It looks like the more recent releases are using the Symbol primitive. At first I thought we could upgrade our headless browser to the latest version and then I wondered why bable wasn't polyfilling Symbol? The babel documentation links to a caveats section on core-js https://github.com/zloirock/core-js#caveats-when-using-symbol-polyfill concerning the limited use of the Symbol polyfill.

  • We can't add new primitive type, Symbol returns object.
  • Symbol.for and Symbol.keyFor can't be shimmed cross-realm.
  • By default, to hide the keys, Symbol polyfill defines setter in Object.prototype. For this reason, uncontrolled creation of symbols can cause memory leak and the in operator is not working correctly with Symbol polyfill: Symbol() in {} // => true.

I also looked and it seems that even the latest versions of Internet Explore don't have Symbol support.

screen shot 2016-03-24 at 10 39 03 am

We're required to maintain browser support for Internet Explore. Is it possible to rewrite without using the Symbol primitive? I'm reading back through the commit history. Looks like symbol support was was added in version 0.9.23.

Support for reporter tags

It would be nice to get support for setting the reporter.tags which show up as "Additional Details" in the trace view.

Currently everything is in the tags of the span, which causes quite a bit of unnecessary duplication and noise in the UI because most of the time I care about the tags that were specifically set on a particular span.

SameSite Cookie attributes

As you may be aware, in Chrome 80, they're changing the way that cookies are handled if the SameSite attribute isn't set for a cookie.

While looking into cookies that would be affected for our application, we noticed the cookies set by Lightstep, the lightstep_guid%F<cookiename> cookies didn't have SameSite or Secure set. I'm not terribly familiar with what these cookies are used for, but if they are potentially affected by this change in SameSite behavior, I figured it was worth filing an issue.

Another caveat on top of this change in default SameSite behavior, is that it isn't as simple as enabling for all browsers, as certain versions of Chrome will reject if this attribute is set. The list of incompatible clients is included here, which psuedocode as well.

Let me know if there's any additional information or clarification I can provide for this.

Allow bundling for browser without having to set PLATFORM_BROWSER: true with webpack

Currently to use in the browser you have to either load the minified bundle, which includes (and duplicates) dependencies that I may already have in my bundle, or bundle with webpack and set PLATFORM_BROWSER to true. Parcel doesn't have an option to inject these global variables or tree-shake with them, so importing lightstep-tracer and bundling with parcel will always end up bundling both platform implementations and running the Node implementation.

Span is not exported

Span exposes a LightStep-specific API generateTraceURL(), but there is no way in code to safely check if a given OpenTracing Span is a LighStep Span with instanceof because the class is not exported.

Error tag for auto instrumented XHRs

I am enabling xhr_instrumentation to help me get traces for the frontend of my application and I do get error logs for 400 and 500 level errors in the span logs but it would be helpful to also get an error: true tag in the same way as the span logs are being automatically populated.

The explorer does not support filtering by logs and also does not recognize errors in the logs.

This would be really helpful.

Thank you! :)

Tracer is required as a global

I noticed Tracer is required as a global on the window object for lightstep to run in _getXHRSpan. In our application I am setting things up within an auto generated closure:

  Tracer = require('opentracing')
  Lightstep = require('lightstep-tracer/dist/lightstep-tracer')

When the page loads I see the exception Uncaught ReferenceError: Tracer is not defined(…)

chrome.loadTimes() is being deprecated

chrome.loadTimes() is used in lightstep-tracer-javascript/src/plugins/instrument_document_load.js but is going to be deprecated in late 2018 according to https://developers.google.com/web/updates/2017/12/chrome-loadtimes-deprecated.

It seems that the reason for its deprecation is that there are other more standard APIs with wider browser support. In terms of a fix do we want to use the new APIs to get this data and apply it to more than just Chrome, switch to using the new Chrome APIs and continue to only add these metrics for Chrome, or drop the feature entirely?

Contributing Guidelines

Hi there :)

I am wondering what the procedure is to contribute to the project?
I have a PR I would like be looked over by you guys and gals...

PR: #117

Thanks!

Span startTime should handle decimal values for nanoseconds

Opentracing docs state that decimals for nanoseconds in start times on spans is supported: https://opentracing-javascript.surge.sh/interfaces/spanoptions.html

However we only account for microseconds and not nanoseconds in our handling of startTime see below:

spanImp.setBeginMicros(value * 1000);

Our satellites expect integers, resulting in an Go unmarshalling error on the satellite side when nanosecond decimals are passed in to startTime using this tracer

-- Issue brought to attention by @Rowno please add more details if I missed anything or described it incorrectly!

React Native crash when it tries to access or add cookies. Error: 'document is undefined'.'

There is an issue where lightstep-tracer always assumes we are running on a browser and tries to access the document object. React Native apps crash because the document is undefined. We have a workaround solution where we define a global document object fallback property as shown in the snippet below but we would prefer a permanent solution to the library.

Object.defineProperties(global, {
  document: {
    value: {
      getElementsByTagName: () => [],
      cookie: {},
    },
  },
  window: {
    value: {
      location: {
        href: '',
      },
      addEventListener: () => {}
    },
  },
  requestAnimationFrame: {
    value: setTimeout
  }
});

version 0.20.10 breaks the lightstep reports

  • The transport mode is switched from thrift to proto from version 0.20.10 which breaks the trace reporting.
  • This is a breaking change and should not have been released as a patch from 0.20.9 -> 0.20.10.

Error from logs

[LightStep:WARN] Error in report: status code=404, message='Not Found', body='404 page not found' { last_report_seconds_ago: NaN }

Figured out we can override using the options,{ transport: "thrift" }

Accept arbitrary configuration keys

When using a more generic OpenTracing configuration strategy, for ex., using JSON, it's possible that some keys exist for other purposes, different from the actual Lightstep configuration. For ex.:

"lightstep": {
    "_comment": "https://github.com/lightstep/lightstep-tracer-javascript/#new-traceroptions",
    "access_token": "<...>",
    "component_name": "app",
    "verbosity": 3,
    "collector_host": "tracing.example.com",
}

Leaving comments in JSON is not possible and it's common to use strategies like the example above. That is one use case.

Currently, this generates an error:

Error: Invalid option _comment
    at Tracer.options (/workspace/node_modules/lightstep-tracer/lib/imp/tracer_imp.js:534:27)
    at Tracer.setPlatformOptions (/workspace/node_modules/lightstep-tracer/lib/imp/tracer_imp.js:487:18)
    at new Tracer (/workspace/node_modules/lightstep-tracer/lib/imp/tracer_imp.js:172:15)

Maybe logging a warning would suffice or accepting a constructor argument to be less strict.

No way to create a custom propagator

There is an API which allows you to pass a custom propagator as an option, but the propagator is meant to convert back and forth between a SpanContext and a carrier. Unfortunately SpanContext is private, so there's no way to actually use the API without completely reimplementing SpanContext (or importing it from the library internals). While both are technically easy, neither seems like a good idea.

Does not work with the ambassador/envoy/lightstep integration

The lightstep tracing module in envoy/ambassador passes down the headers x-ot-span-context and x-request-id, none of which work with the custom tracer.extract() function.

Renaming x-request-id to ot-tracer-traceid is not an issue, but I'm not sure how to decode x-ot-span-context into something useful (assuming it's not ot-tracer-spanid).

GRPC transport

The javascript version only provides thrift as a transport option. Is there anything that would prevent using the GRPC version available in other languages?

Browser friendly lightweight distribution

Hello and thank you for a great product!

We use LightStep heavily on the server side of things in our node apps and would like to also enable tracing on the browser side to have the full stack covered. Is there an effort planned for making the browser builds lightweight, lazy loadable and friendly to the modern packaging tools to enable tree shaking?

Minimum supported IE version?

What's the minimum version of Internet Explorer this project supports? I'm noticing that requiring it breaks the page in IE9 with the error:

Unable to get value of the property 'access_token': object is null or undefined

TS type definitions

It'd be nice to have typescript definitions for lightstep tracer, since it extends what's in opentracing spec.

Would this repo be a good place to host such typedefs?

Included version of ws (transitive dependency) has a high severity security issue

Our internal CI security scans have detected that the version of ws==0.4.32 which is pulled in as a transitive dependency of thrift==0.10.0 (lightstep dependency) exposes 2 high severity security threats.

DoS vulnerability:
ws < 1.1.15 || >=2.0.0 <3.3.1

DoS vulnerability:

As it stands, these issues block our CI/CD pipeline.

The next minor version release of thrift (0.11.0) - makes use of ws 5.x which resolves the threats mentioned above.

Would it be possible to update the version of thrift required by the lightstep module to mitigate this threat?

We did note a bump to 0.11.0 had been attempted in the past and was rolled back #126 due to incompatibilities with older versions of node.

error.object should use non-enumerable properties error.message and error.stack

From the specification:

error.object

object

For languages that support such a thing (e.g., Java, Python), the actual Throwable/Exception/Error object instance itself. E.g., A java.lang.UnsupportedOperationException instance, a python exceptions.NameError instance

For Javascript, this would be the Error instance, and the tag should include the message and stack properties. But message and stack are not enumerable:

> Object.getOwnPropertyDescriptors(new Error('test'))
{ stack: 
   { value: 'Error: test\n    at repl:1:34\n    at ContextifyScript.Script.runInThisContext (vm.js:23:33)\n    at REPLServer.defaultEval (repl.js:336:29)\n    at bound (domain.js:280:14)\n    at REPLServer.runBound [as eval] (domain.js:293:12)\n    at REPLServer.onLine (repl.js:533:10)\n    at emitOne (events.js:101:20)\n    at REPLServer.emit (events.js:191:7)\n    at REPLServer.Interface._onLine (readline.js:238:10)\n    at REPLServer.Interface._line (readline.js:582:8)',
     writable: true,
     enumerable: false,
     configurable: true },
  message: 
   { value: 'test',
     writable: true,
     enumerable: false,
     configurable: true } }

so LightStep only shows an empty object:

image

I think it would make sense to special-case error.object here to include these non-enumerable properties, as the tag would always be an Error instance.

collector_port=0 should mean "default"

Requested for configuration convenience in a polyglot environment. Specifically, in Go it is a convention to use0 to mean default / "unset".

Since port 0 is never a valid port, it's reasonable to adopt this convention for the JS port setting as well.

Node distribution should not be minified

It's extremely hard to debug production problems in the node lightstep distribution, because the distributed code is minified. This seems highly unusual -- I don't think I've ever seen people minify their nodejs code for distribution. Is there some reasoning behind it?

Optionally _clearBuffer on _reportErrorStreak Threshold

We have NGINX proxying to our satellites and nginx has a default max payload size of 1MB. We've seen:

  • Satellites were not accepting traffic for a brief amount of time
  • Client buffer filled up
    (Somewhere in here Satellites restarted)
  • Satellites start accepting traffic again
  • By this point client buffer was too big with the default span count limit of 4096
  • Client tried to flush to satellites
  • Rejected by NGINX config of max payload size of 1MB
  • Buffer stays full as more spans are reported but can’t flush due to NGINX limit, hence increased memory usage

There looks to be a clean path to implementing this.


If possible it would also be nice to have an option to set max buffer size bytes:

  • Configure max buffer size bytes
  • if a span would go over the size would flush
    I'm not sure of the performance implications of serializing across the different protocols. Ie are records concatenated so each span can be serialized and added to each other? or is there a different data structure that requires an array of spans making it not possible to do this??

Cannot be used in Chrome/Firefox extensions because bundle contains eval()

When trying to use this library in a browser extension (Chrome or Firefox) the extension will throw with

Error: Uncaught EvalError: Refused to evaluate a string as JavaScript because 'unsafe-eval' is not an allowed source of script in the following Content Security Policy directive: "script-src 'self' blob:".

Chrome and Firefox do not allow eval( in extensions because it is a security risk.

This seems to be related to some Google library bundled (I assume for Proto support?), search https://github.com/lightstep/lightstep-tracer-javascript/blob/master/dist/lightstep-tracer.js for eval(.

Context propagation in XHR requests with auto Instrumentation

We would like to be able to add http context headers to the XHR requests when xhr_instrumentation is enabled.

Either doing it automatically or by accepting a callback which would make the span instance and the request available.

Having access to the span instance would also be useful to set more meaningful names (e.g. url pathnames), mangle url parameters (e.g. user information) or maybe remove sensitive headers from the spans, for example.

errors due to calling truncatedString with non-string

We're seeing the following error in production:

{"name"=>"TypeError", "message"=>"t.substr is not a function", "stack"=>"TypeError: t.substr is not a function\n at o (/usr/local/23307-3df9909/node_modules/lightstep-tracer/dist/lightstep-tracer-node.js:3:2991)\n at /usr/local/23307-3df9909/node_modules/lightstep-tracer/dist/lightstep-tracer-node.js:3:5051\n at …a.value (/usr/local/23307-3df9909/node_modules/lightstep-tracer/dist/lightstep-tracer-node.js:3:5501)\n at ClientRequest. (/usr/local/23307-3df9909/node_modules/lightstep-tracer/dist/lightstep-tracer-node.js:3:4971)\n at emitOne (events.js:77:13)\n at ClientRequest.emit (events.js:169:7)\n at Socket.socketCloseListener (_http_client.js:232:9)\n at emitOne (events.js:82:20)\n at Socket.emit (events.js:169:7)\n at TCP._onclose (net.js:477:12)"}

When I unwind the minified code, it appears to be due to this line:

which sometimes calls truncatedString(undefined) when payload hasn't been initialized yet

Make and use getters on SpanContext

This would allow properties of spanContext to be read without accessing private variables. Alternatively, the private variables could simply be made public, though this seems less safe. Also because the "private" variables have thus far been used in a public way, changing them would be a breaking change, where adding new public getters would not be.

Invalid imports

This error happens with opentracing v0.14

/.../node_modules/lightstep-tracer/lib/imp/span_imp.js:300
}(_opentracing2.default.Span);
                       ^

TypeError: Cannot read property 'Span' of undefined

The reason is that the lightstep tracer incorrectly imports a non-existing default export:

import opentracing from 'opentracing'

instead of

import * as opentracing from 'opentracing'

as there is no default export:
https://sourcegraph.com/github.com/opentracing/opentracing-javascript/-/blob/src/index.ts

Hook to add extra tags to auto instrumented XHR and fetch

E.g. right before around here (instrument_fetch.js#L190) we could run a hook/callback like:

tags = extraTagsHook(tags);

and the extraTagsHook would be passed in where the tracer is instantiated, e.g:

opentracing.initGlobalTracer(new lightstep.Tracer({
    access_token   : '{your_access_token}',
    component_name : '{your_service_or_app_name}',
    extraTagsHook: tags => {
      tags['web.origin.pathname'] = window.location.pathname;
      return tags;
    }
}));

WDYT?

Cheers!

related #90

[Chrome] lighstep-tracer triggers browser errors: `Security Error: Failed to read the 'sessionStorage' property from 'Window': Access is denied for this document.`

lightstep-tracer version: 0.24.0-no_protobuf
Browser: Google Chrome 78.0.3904.97 (Official Build) (64-bit)

Issue:
We have a page that loads lightstep-tracer, and that page is sometimes loaded inside an iframe. When this happens, lighstep-tracer triggers an error in the browser that reads "Security Error: Failed to read the 'sessionStorage' property from 'Window': Access is denied for this document.", which causes the tracer to fail to load. I am only able to reproduce this when third-party cookies are disabled in Chrome.

It looks to me like this is coming from this code path:

localStoreGet(key) {
if (!window.sessionStorage) {
return null;
}
try {
return JSON.parse(sessionStorage.getItem(`lightstep/${key}`));
} catch (_ignored) {
return null;
}
}
localStoreSet(key, value) {
if (!window.sessionStorage) {
return;
}
try {
sessionStorage.setItem(`lightstep/${key}`, JSON.stringify(value));
} catch (_ignored) { /* Ignored */ }
}

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.