We want to use RUM in our plugin, the plugin is loaded into an iframe of another company's application, but the recent samesite attribute change, which I understand is needed, prevents us from using RUM, due to that the cookie test fails when samesite=strict

I found this page that talks about the samesite attribute and third party contexts. And as a workaround I created my own RUM sdk version, were I instead of samesite=strict use samesite=none; secure and that works fine, but it would be better if this was supported out of the box.

Currently PII can be sent with some of the collected data:

• url
• error message / stack
• user action name

Add a way to mask them for both logs and rum SDK.

This probably isn't possible due to RUM only using the Performance API, but I'll throw out there as a future idea:

I'd like to add additional facets to individual Resource calls to help with analyzing the data.

The main facet I have in mind would be the CDN's cache result being hit or miss, which is an HTTP response header. Being able to include any CDN IDs would be nice.

The CDNs are a caching proxy style (eg, Cloudflare, CloudFront, StackPath, etc.) that use the same origin/domain as the website, so there shouldn't be an issue with accessing the response headers.

Cloudflare and CloudFront have a simple CF-Cache-Status or X-Cache response header and hit/miss value, but other services like StackPath have a more complicated header value, eg, "1541178655.cds005.da2.hc,1541178655.cds113.da2.c" so would need custom parsing.

Please consider adding a changelog to the project. I think a file in the repo is friendlier than relying on GitHub's Releases functionality, but I'd even settle for that. Fortunately, the project is small enough where auditing commits is an option. But reviewing commits in general to piece together the changes is a bit tedious because GitHub renders the commits in the opposite direction you'd normally want to read them.

A changelog would be a good way to communicate API changes to your customers and help them evaluate when and why they should upgrade the module in their projects.

Converting #387 to follow this topic.

This behavior is not requested by many customers so it is not in our top priorities right now.
It is definitely something that we would want to integrate but it could take some time before we make progress on that.

Some code (not sure if ours or 3rd party) seems to be throwing an Event object.

This is a commonly-misused pattern in JavaScript world.

something.onerror = e => {
  throw e
}

It would help if the event name and event target class name is serialized in Datadog RUM.

Please let me know if I'm missing something but:

• There doesn't appear to be a way to check if datadogLogs.init() has already been called, and console.error() is called if it had already been initialized. However, since we're sending our console errors to datadog, this leads to our logs getting spammed by these error messages that we don't care about. Ideally, there would be something on the datadogLogs API that we could check before calling init to see if it has already been called.

• There's no good workaround at the moment for suppressing these console errors, because they're using console.error() rather than throw - presumably this is because you don't want to halt execution, which is understandable - however, it'd be nice in this case if there was a way to configure the logger to filter out certain console errors. If such functionality already exists, that would be something that would be helpful to highlight in the documentation.

Thanks!

I haven't been able to find in the docs a way to hide or mask the URL.

For my use case, part of the URL may contain sensitive information (ok to share internally but not externally) I was wondering if there's a way to mask part of the URL or omit it entirely from reporting when using the @datadog/browser-rum package.

Hi,

One of your product advantage compared to Google Analytics, is that it is not tainted by marketing / advertising / campaign performances purposes and thus can be used as a pure analytic tool in regard of the European privacy regulations.

Sadly, there's no option to make it works without dumping first (and third party) cookies.

With a "non cookie based session / client identifier" option, it would be possible to only display an opt-out banner to the user instead of having to show them a Cookie Policy wall with "Accept" and "Reject" options.

When using your SDK on Single Page Applications, having a session ID generated in memory is fine and do the job most of the time.

Having the application generate the client ID for the SDK (usually based on the application own user's unique identifier) and pass it during the init process or via a dedicated method would also works nicely for all application where a user has to log-in in some way.

We frequently see several logs with this pattern:

Message: XHR error GET https://url-of-ajax-endpoint
Stack trace: Failed to load

What we discovered is that these are not actually errors but are aborted XHR requests. We use a library called select2 which makes XHR requests as the user types an input. It's not uncommon for a single user interaction to generate several requests as they type their input string.

The select2 library is aborting in-flight XHR requests before it makes a new one as described here https://stackoverflow.com/a/37319150/7691972

I am curious what the best way is to either prevent these from being logged, or to distinguish these from other legitimate errors that may present similarly.

Logging objects with circular structures causes an uncaught error. For example, try DD_LOGS.logger.info('hello', window).

Normally, we don't log such objects, but when it happens by accident it can break the whole application.

What about using smth like fast-json-stringify?

Hello! When developing locally I set the log handler to "console", to not spam the live site.

datadogLogs.logger.setHandler(
  process.env.DD_ENABLED === "true"
    ? HandlerType.http
    : HandlerType.console
);

The downside to this is that I can't see the context values of the log, which makes this much less useful. This call to the logger:

datadogLogs.logger.info("Switching viewed account", {
  from: oldAccount,
  to: newAccount,
});

Results in this log to the console:

I can't see the "from" and "to" values I'm sending along, which makes these logs much less useful for debugging (if the handler were "http", I could see these values in the network tab). I end up having to go into the code and setting a console.log if I want to debug things, whereas I would hope that datadog's logger would make that unnecessary.

Either way I hope you all are well, thank you!

Hi,

Is there a way to anonymise the IP address that is stored with each log ? It is a requirement to be compliant with privacy regulations in Europe (GDPR/E-Privacy).

The full IP shouldn't be available at all in the source data and shouldn't be used for GeoIP resolution. Only the "pseudo-anonymized" IP can be stored and used for GeoIP resolution.

For a lack of official sources I redirect you to the GA documentation: https://support.google.com/analytics/answer/2763052?hl=en

This feature is designed to help site owners comply with their own privacy policies or, in some countries, recommendations from local data protection authorities, which may prevent the storage of full IP address information.

The IP anonymization feature in Analytics sets the last octet of IPv4 user IP addresses and the last 80 bits of IPv6 addresses to zeros in memory shortly after being sent to the Analytics Collection Network. The full IP address is never written to disk in this case.

Does the browser-sdk support sourcemaps? I don't see anything about this in the docs and the only mention of it seems to be from another datadog project (DataDog/dd-trace-js#48 (comment)).

Thanks in advance, this is a pretty key feature for my team to consider adoption!

Hello!

I recently saw and answered this StackOverflow question about adding context to log entries, and noticed that the docs call out Context as the execution environment, however the browser SDK uses Context differently internally, and since that's the user-facing API (add context here...) I completely understand the confusion on what a user might want to do - it took me a while to re-read both the docs and the code to find the mismatch.

I'd recommend creating consistent naming - either clear up the docs/UI, or the internal namespaces in the SDK - either way the confusion can't be good for clients trying to determine if they can add tags or attributes to specific log entries.

Hey!

I am using the browser-sdk for logs in our hybrid mobile app built with Ionic. Currently, we are using the file protocol to handle internal files and some specific features.

I noticed this check related to the file protocol and is blocking us from using the library :(

I would like to know if there's any specific reason I'm not aware of to have that check. We can do a fork and remove it, just wanted to double-check if that check is useful.

Thank you for your work :)

When Client Token is not configured, datadog-logs treat as error and write
error message Client Token is not configured, we will not send any data.
to browser console on initializing.
It is usual situation that application start without Client Token
such as developing or testing environment.

It would be nice to write the message as warn in stead of error.

Hi,

I have set up @datadog/browser-logs in react-native app according to the guide

but whenever I am calling log method I see this warning in console:

'logs.logger.info' not yet available, please call '.init()' first.

how can this library be used for react-native?

utils.js?3d73:86 Uncaught RangeError: Maximum call stack size exceeded
    at deepMerge (utils.js?3d73:86)
    at deepMerge (utils.js?3d73:118)
    at deepMerge (utils.js?3d73:118)
    at deepMerge (utils.js?3d73:118)
    at deepMerge (utils.js?3d73:118)
    at deepMerge (utils.js?3d73:118)
    at deepMerge (utils.js?3d73:118)
    at deepMerge (utils.js?3d73:118)
    at deepMerge (utils.js?3d73:118)
    at deepMerge (utils.js?3d73:118)

After some debugging found that one of the things I was logging had an object with a circular reference.

I think the error might somehow be able to be caught and give this hint in an error message, or possibly even avoid the circular reference some how would be better.

Not sure how or why it wasn't caught in previous versions, It did not happen in 1.19.0

Hi,

I have a project where I've installed both Datadog RUM and Sentry (https://sentry.io) and when Sentry is initialized before RUM, RUM will override the onunhandledrejection handler (see the code)

The fix for this project was to initialize Datadog before Sentry, so Sentry calls both its handler & the previously installed handler (RUM). I'm wondering if the RUM team will be receptive of a PR changing the installation behavior to respect previously installed handlers. Thanks!

Hi! We are a pretty big Datadog customer looking to adopt DD browser logger. Based on our experience with other FE logger tools it would be great if the sdk provided a callback before the event is sent to the server so we can decide to drop it based on some heuristics (i.e useless browser exceptions we have no way of fixing, errors we want to ignore, other tools to send errors to, etc).

This would be equivalent to the before send callback on Sentry.

Hello,

I use the library with the following code.

import { datadogLogs } from '@datadog/browser-logs';

export function init(): void {
  datadogLogs.init({
    clientToken: '<TOKEN>',
    datacenter: 'us',
    forwardErrorsToLogs: true,
    sampleRate: 100,
  });
}

export function info(message: string, context?: {}): void {
  datadogLogs.logger.info(message, context);
}

export function error(message: string, context?: {}): void {
  datadogLogs.logger.error(message, context);
}

My very first call is init(), but when I call info, I get a warning that init() must be call before.

I am also bundling my app with webpack.

Versions tried are: 1.12.1, 1.12.0, 1.11.1

The code is executed from an iframe.

Is it an issue you are aware of?

Context
To start with, some context for this feature request. I would like to:

1. Incrementally add contextual information to my logging, as my code progresses.
2. Remove contextual information when I leave the context for which that data is relevant.
3. Have console.log statements include the context

Provided solution
The library doesn't make it impossible to do this, but it lacks a bit of convenience:

1. is currently possible by adding data either to the global logger or a local logger.
2. is currently possible only by overwriting the entire context. This method is inconvenient for removing just the bits that are no longer relevant, and is further constrained because I cannot query the current context. As such, the only real way to do this currently is set up our own context tracking mechanism next to the one datadog provides.
3. although we can fork local loggers from global loggers for a single extra layer of context, the console.logs made from this context wouldn't include that additional context.

Proposed solution
Include the following API and implementation:

1. pushContext([key1: value1, ..., keyN: valueN}]) to push a bit of context into a global context array
2. popContext() to remove one layer of context from the global context stack.

For each log statement issued, assemble a context by merging context layers, overwriting older context values with newer ones on key conflicts.

For now I am doing the above myself with some React components in my app, but I think this would be a great addition for anybody using this logging package.

Thanks in advance for your consideration!

Hey DataDog team 👋

Recently started using @datadog/browser-logs to init a client-side logger like so:

// logger.ts
import { datadogLogs } from '@datadog/browser-logs';

datadogLogs.init({
  clientToken: DATADOG_CLIENT_TOKEN,
  datacenter: 'us',
});

export default datadogLogs.logger;

// app.ts
import logger from './logger';

logger.setContext({ globalField: true });
// ...
logger.info('Something happened', { localField: true });

My expectation here is that, in the DataDog UI, I'd see a combined context of { globalField: true, localField: true }, however I see only the local context that is passed at the logger.info call site - global context seems to be discarded.

Am I doing something wrong, or is it expected that any local context would completely overwrite the global context (and thus, global context is only used when no local context is provided)?

In my use case I basically want them to be combined with shallow merge - is there a good way to do this without having to write a wrapper that handles this logic myself?

Hi! While looking into using Datadog RUM, I noticed the bundle size is much bigger than I'd expect: @datadog/browser-rum bundle analysis. Currently it's about half the size of our entire UI component library, including styles.

Most of this comes from @datadog/browser-core and its dependencies.

While there's a lot of code in the packages themselves, the size is mostly inefficiency in dependencies and bundling. This is good! It's the easiest to cut down.

Likely highest gains:

• Inline merge and assign functions in the project instead of using lodash. The two lodash imports account for almost 25% of the total size.
• Consider switching from tsc to rollup, possibly using tsdx to save headaches. Rollup is specifically designed for building self-contained libraries, and will avoid the tslib dependency (the second largest after lodash).

We would like to implement RUM in our server-side rendered React application. We get an error at runtime because this library attempts to access window during script load.

The ask is:

• can we avoid invoking window until after calling init?
  OR
• can we safely access window and do an early termination if its not defined?

We reverted to execute the code via html script download, but would really like to avoid that. Thanks!

If both browser-logs and browser-rum are included on the page but only browser-logs is initialised, unhandled exception that occur on the page result in shared code in the core module firing the following warning:

'getInternalContext' not yet available, please call '.init()' first. 

It's desirable to be able to conditionally initialise one module over the other depending on the environment context (in my case, I don't want RUM metrics firing in development, but I do wan't logs going to the console). If it helps the fix, setting forwardErrorsToLogs to false fixed the issue.

Repro: https://codesandbox.io/s/polished-field-xjyxz?file=/src/index.js
(View the console to see the warning)

SDK Versions:

• @datadog/browser-logs: 1.17.0
• @datadog/browser-rum: 1.17.0

Hi!

I'm integrating the @datadog/browser-rum with at our react (16.12.0) application that uses react-router-dom (5.1.2) to manage the routers.

We are currently using HashRouter and due to already existing analysis data, we can't migrate from HashRouter to BrowserRouter without having the /# prefixed.

Basically, the issue we have is that the @datadog/browser-rum seems not to be integrating with HashRouter very well. I uploaded some code I was using to debug here https://github.com/eduardogspereira/datadog-debug, but basically I'm setting the datadogRum and router like this:

Even that the hashchange event is being triggered, the paths are not being correct updated at datadog:

Also, we trying to migrate from HashRouter to BrowserRouter keeping the /# prefixed. Like this:

But with this approach the datadogRum don't update the locationPath also.

It's possible that this is a bug?
Thanks!

The library console.errors when cookies aren't enabled, which is then sent to Datadog. Could this be a console.info so it doesn't pollute our application's logging?

The current applications that we monitor we make extensive use of tags to be able to aggregate and filter the logs in the way the teams get easier debugging.

Running the browser log it is possible to see default tags being added based on the params of passed on the init method. As can be confirmed here

I was wondering if would be ok to have an optional parameter to the interface UserConfiguration to allow custom tags during the init of the browser logs and RUM.

Currently only responses with statuses 0 or >= 500 are logged. I'd like to log all responses with 404 status too so it would be great if this would be configurable.

It appears that the documentation needs to be updated with the latest release. The sample init script no longer builds using Typescript. We are updating from 1.5.0 so not sure when this was introduced.

ERROR in app/app.component.ts:42:9 - error TS2322: Type '"us"' is not assignable to type 'Datacenter'.
42 datacenter: 'us',
~~~~~~~~~~

../node_modules/@datadog/browser-core/cjs/configuration.d.ts:38:5
38 datacenter?: Datacenter;
~~~~~~~~~~
The expected type comes from property 'datacenter' which is declared here on type 'RumUserConfiguration'

I don't see anything in the docs on this. Is there a way to pick up already-caught errors? We just switched to Datadog from New Relic, and we were using NewRelic's noticeError for that. Example with NR:

try {
  someThingThatMightError()
} catch (e) {
  someLogicToShowFriendlyErrorToUser(e)
  window.newrelic.noticeError(e, someExtraFieldsForEnrichment)
}

Due to the use of Function in https://github.com/DataDog/browser-sdk/blob/master/packages/core/src/utils.ts#L224, the browser agent causes errors when unsafe-eval is disallowed by CSP for older browsers without globalThis (e.g. Chrome <71, Firefox <65).

Suggest also checking for the existence of window (and possibly self for webworkers) in addition to globalThis to avoid invoking the Function constructor in the vast majority of cases.

our app is a large single page application, and we've had bugs in the past that caused a lot of memory bloat in the browser, or where the browser UI becomes somewhat unresponsive

it would be great if there were some way for the RUM package to report back memory usage and/or some kind of latency on the event loop to see if an SPA has become less responsive. I'm thinking if you could set a polling interval (like every 1 second or every 30 seconds, or whenever, where you call the performance.memory API, and also do something like:

const now = performance.now();
setTimeout(function reportPerformance() {
  reportEventLoopLatency(performance.now() - now);
}, 0);

(Yes, I know setTimeout has a built in throttle... could also try using Promise.resolve().then(...) though that's measuring something slightly different)

const now = performance.now();
Promise.resolve().then(function reportPerformance() {
  reportEventLoopLatency(performance.now() - now);
});

All of our logs going into Datadog are tagged by environment (path name env). This tag is set up by the Datadog agents, so we don't really have control over the path. I followed the documentation on setting up global context for logging, which sets the "env" key:

datadogLogs.setLoggerGlobalContext({ env: 'custom-env-name', service: 'service-name' })

Unfortunately, this is coming into Datadog with path @env, rather than env. As such, the facet we're using to segregate logs by environment doesn't work. As far as I can tell, there's nothing exposed in the API that would allow setting up this tag.

We are using datadog in our app
We started to see this error in our error logs today

File webpack:///./node_modules/@datadog/browser-core/esm/xhrProxy.js line 43 col 27 in proxyXhr
this._datadog_xhr.startTime = performance.now();

I cannot repro this myself.

But looks like related to this PR #468

Impact is not clear.

Could some one please clarify if we can rollback to some older version of browser-sdk?

Hi there 👋🏻

In advance, thanks for your work 👏🏻
I'm actually trying to add your sdk inside a browser extension (in a content_script) but i stuck on 'logs.logger.info' not yet available, please call '.init()' first.

• Is it supposed to work with browser extension ? if yes, is there is something special to do ?

Thanks

We currently have a hybrid frontend as we are deprecating the legacy frontend. The legacy frontend uses the root directory so different products are accessed at /productA/, /productB/, etc. However, our new frontend is accessed at /spa/productA/, /spa/ProductB/, etc. so Datadog RUM always reports the path group at /spa/.

Is it possible to specify an expected subdirectory or specify a depth level in the RUM configuration?

In my app, there is a "debug" page allowing users to send us a report. I would like to be able to display the session id in this report to help the support team accessing the logs corresponding to the session.

Right now I've to do something like this:

(datadogLogs.logger as any).session.getId()

It would be convenient to be able to do something like:

datadogLogs.getSessionId()

or

datadogLogs.session.getId()

meaning that the session would not be anymore a private attribute here: https://github.com/DataDog/browser-sdk/blob/master/packages/logs/src/logger.ts#L132

With SPAs it would be quite handy to be able to add custom view measures, at various points of the view lifecycle, that are relative to the view's startOrigin.

In addition it would be helpful to have a standard provided measure (taking advantage of the above) to add a viewReady measure that applications could call to indicate that the view has reached an application defined 'ready' state. Such a measure could be used regardless of whether the view was created by initial page load, or via History API.

I'd be willing and able to implement such support and open a PR. I wanted to check first that such a feature would be useful and desired, and that the approach is good?

Browser: Safari 13.0.4

'prerender' seems to be deprecated.

The error goes away after a page refresh. Not sure what that is about.

When I set the proxy host parameter in datadogLogs:

datadogLogs.init({
  clientToken: '<DATADOG_CLIENT_TOKEN>',
  site: 'datadoghq.com',
  proxyHost: "dd.*****.com"
});

This error appears:

Uncaught (in promise) TypeError: Failed to construct 'URL': Invalid URL
    at s (urlPolyfill.ts:38)
    at l (urlPolyfill.ts:20)
    at c (urlPolyfill.ts:16)
    at s (configuration.ts:214)
    at n (errorCollection.ts:163)
    at errorCollection.ts:160
    at fetchProxy.ts:92
    at Array.forEach (<anonymous>)
    at fetchProxy.ts:92
    at tslib.es6.js:100
    at Object.next (tslib.es6.js:81)
    at o (tslib.es6.js:71)

As far as I investigated it comes from buildUrl function in:
https://github.com/DataDog/browser-sdk/blob/b3bf73efe65cdc2ebece5bd31dfc80124d66a991/packages/core/src/urlPolyfill.ts#L36

My proxy works well and I can get the logs successfully but this error should be solved

Right now only console.error is being enhanced to report errors to Datadog.
I would like too:

• Be able to redirect console.debug, console.info and console.warn to Datadog (depending on the log level of course).
• Be able to hide console messages in my production environment.

Reasons:
Right now I log to datadog when I am in my production environment. In my localhost environment, I want to log into the console.
If I use "datadogLogs.logger.debug", in my localhost environnement I have on those ugly warnings: logs.logger.debug' not yet available, please call '.init()' first.
I could wrap all my log conditionally like this of course:

      if (process.env.REACT_APP_DATADOG_CLIENT_TOKEN) {
        datadogLogs.logger.debug('...')
      } else {
        console.debug('...')
      }

But that's way too much code for one log.

Suggestion
Improve startConsoleTracking to handle all logging methods from the console.
Also, do not apply originalConsoleError all the time: use a configurable parameter to skip this part conditionnaly.

There is this google web vitals initiative.

I've been wondering if you guys have plans to include core web vitals (Largest Contentful Paint, First Input Delay, Cumulative Layout Shift) RUM out of the box in DD sometime in the future?

Hi,

just wanted you to be aware that your documentation on the website vs. npm package slightly differs. The documentation according to the npm package is seemingly correct. I just wanted to give a heads up to anyone else that may run into this issue. Also I have shown an example below. Thanks!

on website:
datadogLogs.setLevel(...);
datadogLogs.setHandler(...);

what works:
datadogLogs.logger.setLevel(...);
datadogLogs.logger.setHandler(...);

Hi there! I noticed that the NPM releases for the packages here don't link back to the code repository. For example: @datadog/browser-rum does not have any repository information on the right sidebar. This would be beneficial as it adds nice statistics to the NPM page, and allows dependency-update bots like dependabot or greenkeeper to automatically pull information into the pull requests they create.

I believe this would be fixed by adding the repository key to the package.json. By example, Babel does something similar in their monrepo and it works perfectly on the NPM page.

Hi,

From my tests, it seems like the only piece holding back full browser-rum support of Ionic / Cordova applications is the use of cookies on iOS. What I am seeing in iOS 13.4 is that cookies cannot be set and/or read by JavaScript, which browser-rum requires to operate.

I cannot find clear information if this is a bug in iOS or if it's intentional. I have not found a work around either.

Meanwhile, browser-rum worked great on Android.

If you can shed any light on the iOS cookie issue or a work around, that would be great.

In any case, offering an alternative mechanism than cookies for these scenarios would be a welcome feature!

Below is an output from my FF 78 with datadog-logs-eu.js active that is complaining about the missing SameSite attribute in the _dd_s and dd_rum_test cookies.

Firefox Developer: v78
datadog-logs-eu.js SDK-Version: 1.12.4

Hi

We have been using datadog for a while for our backend services, and recently went to introduce it to one of our new front end projects. We noticed that the service was being sent, but as a tag rather than as an attribute, which means it doesn't show as a service in the dashboard.

I had noticed that there was a recent pull request to fix this issue RUMF-620, but that this has been reverted in the latest release v.1.16.0.

Is this being planned for a separate release, or is actually "working as intended". Hopefully the former!

Thanks!