NREUM: (1) instead of Javascript? #125

sebastianhoitz · 2014-03-15T13:36:30Z

I just installed the newrelic end user monitoring.

It did report data for a few seconds, but then it stopped and just outputs this HTML code:

<!-- NREUM: (1) -->

how do I get it back? Does this have anything to do with the environment NR thinks I'm in?

Edit: For some reason the reports ended when I saved the application settings in the NR interface. Also, it shows me this error:

groundwater · 2014-03-15T17:04:23Z

Hi @sebastianhoitz, thanks for trying out browser tracing.

The getBrowserTimingHeader call is meant to always be safe, so header generation has a circuit-breaker that will output a semi-informative comment in the event there was not enough information to generate the header properly.

A code of (1) indicates that you tried to generate headers outside of a web-transaction. Are you pre-generating the headers? Calling getBrowserTimingHeader during startup for example would likely produce this result.

It's a bit tough to say exactly what's happening, can you give an example of where and how you're calling getBrowserTimingHeader. If you'd like to send information privately, you can email support@newrelic.com or jacob@newrelic.com. The former will also engage our awesome support team.

sebastianhoitz · 2014-03-15T17:10:17Z

Ok, I have this scenario:

I use handlebars to output my templates.

I have an object of handlebars helpers that looks like this:

unless window?
  newrelic = require "newrelic"

App.HandlebarsHelpers =
  newrelic_header: ->
    unless newrelic
      return ""

    new handlebars.SafeString(newrelic.getBrowserTimingHeader())

for name, method of App.HandlebarsHelpers
  handlebars.registerHelper name, method

in my handlebars template I then do this:

layouts/application.hbs

<!DOCTYPE html>
<html lang="de">
  <head>
    <meta charset="utf-8">
    <title>PrismaBox Webseite</title>
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <link rel="shortcut icon" href="/images/favicon.png">

    {{> layouts/_application_newrelic}}

    ...
</html>

layouts/_application_newrelic.hbs

{{#is env "production"}}
{{newrelic_header}}
{{/is}}

Do I have any options to pass the request context to newrelic as an argument?

sebastianhoitz · 2014-03-15T17:19:04Z

From what I see right now is, that I could pass the generated header string as parameter to the handlebars template, so that I just output a string in handlebars, right?

Edit: Ok, looks like this does not work, either.

Here are some more details:

I use an express-based framework.
nodeJS version: 0.10.25

The weird thing is: the backend side gets reported to newrelic just fine. It detects transactions and sends the metrics to newrelic. But for some reason this part has problems trying to detect the transaction.

groundwater · 2014-03-17T16:58:05Z

@sebastianhoitz this is a bit difficult to debug without seeing the entire application, but I suspect it has something to do with where the getBrowserTimingHeader method is being called.

A rather crude, but effective means of determining this might be:

include require('stackup') temporarily in your app, it's a long-stack module that uses the same underlying async-listeners as the newrelic module.
instead of calling newrelic.getBrowserTimingHeader(), just throw new Error()

The stack trace generated might have some useful information about whether it's generated in the context of a transaction or not. This is definitely not to be used in production code, or checked in.

Sorry I don't have a better idea at the moment, if you want to discuss more details in a private ticket, feel free to email support@newrelic.com with a link to this thread.

Don't worry, we'll figure this out!

sebastianhoitz · 2014-03-22T15:51:48Z

Ok, I sent you an email with the stacktrace.

I also noticed that NR inserts the JS script during the first request to the page. But after that it is not able to identify the request anymore.

groundwater · 2014-03-24T18:20:33Z

I followed up to your email. I'll leave this issue open for now, perhaps we can find a general solution, and it might make a good reference for others.

santihbc · 2014-03-29T06:18:03Z

Could you inform on what news there are about this? Did you manage to solve your personal case?

groundwater · 2014-03-31T16:53:12Z

Hey @santihbc, we're still working on solving everyones specific case.

I want to take this opportunity to apologize for lack of good documentation around these errors. We're preparing a troubleshooting document to explain the error codes that will go on our help site soon.

The error with NREUM: 1 is that getBrowserTimingHeader is called outside of a web transaction, and newrelic does not have enough context to generate a working header. This is an artifact of how the templates are being rendered, and is likely a caching problem.

The solution is to ensure that getBrowserTimingHeader is called downstream from the start of every http request. You may call it asynchronously because our tracer can actually correlate asynchronous events, but it must be an async event that was scheduled after the web request began.

There are some template rendering techniques which violate this; they're not doing anything wrong, and neither are we. In these circumstances, you'll just need to find a better way to generate the header. One option would be to call getBrowserTimingHeader in your route/controller and pass the result in as a variable to be rendered.

I do not have a general solution yet, but if you can share details about how your templates are rendering/caching I would love to help come up with a solution that could be useful to others.

santihbc · 2014-03-31T20:31:34Z

Thanks for your response @groundwater , how about NREUM: 3? I managed to get that one instead of NREUM: 1 also.

groundwater · 2014-03-31T21:20:23Z

For reference, the errors are explained in the api source, but we will be moving that to an actual help doc very soon.

An NREUM: 3 means you are in an unnamed transaction. These are normally the web transactions that get rolled up into /* in the web ui. If you are using express, restify, or hapi, then your transactions should be named automatically. Non-supported routers, and the base http server mechanism must use our naming API to generate transaction names.

If you are using a supported router, can you describe how the route is being called?

If you are not using a supported router, you will have to use our naming API along any route that you wish to have browser tracing enabled.

santihbc · 2014-04-01T02:17:13Z

The route is the base route. I have a single page application so I download HTML just once from the server:

app.get('/', function(req, res){
  res.render('index', {
    nreum: newrelic.getBrowserTimingHeader()
  });
});

Then inside the layout.html template that contains the index.html sub-template I render the headers in the following way:

<!DOCTYPE html>
    <head>
        <meta charset="utf-8">
        <meta http-equiv="X-UA-Compatible" content="IE=edge">
        <meta name="description" content="">

        <title>My website</title>
        <meta name="viewport" content="width=device-width, initial-scale=1">
        <link rel='shortcut icon' type='image/x-icon' href='/images/favicon.ico' />

        <!-- new relic -->
        {{nreum}}
        <!-- new relic -->


    </head>
    <body>
            ...

Then I get the NREUM: 3 comment instead of the headers

lyric · 2014-04-02T18:14:37Z

@groundwater We are using Hapi and getting the same issue (NREUM: 3), we also are on / in a one page app, any advice?

mdarnall · 2014-04-02T19:13:47Z

Here is what @lyric and I did to resolve our issue:

because we were trying to use the / route, we explicitly named it, via newrelic.setTransactionName('home');
We then got the RUM_ERROR of 4, which after looking at the code indicates 'NREUM: browser_monitoring requires valid application_id',. Putting application_id : 'foo', into our config solved that issue 😢
We then got the RUM_ERROR of 5, which after looking at the code indicates 'NREUM: browser_monitoring requires valid browser_key'. Putting browser_key : 'foo' into our browser_monitoring config solved that issue 😢

Then the headers were rendered to our page, and page metrics showed up in our dashboard. 👍

lyric · 2014-04-03T15:39:23Z

This works locally, but when I deployed to heroku, we start getting RUM_ERROR 3 again. Starting to look now.

groundwater · 2014-04-03T22:36:43Z

Hey everyone. It looks like there are several people experiencing errors generating browser headers. I'd like to help everyone get this working, but this ticket is probably already too crowded to address people individually.

I would highly recommend opening a ticket with our support staff by emailing support@newrelic.com. Feel free to reference this issue here when you're sending your request in. We have awesome support engineers who would love to hear from you.

It's clear to me that the variety of applications wanting to use browser tracing is much wider than we originally anticipated, and it's also likely that there are new use-cases we should sit down and thing about accommodating.

It's worth mentioning that if you do receive an error, it's because something is not configured correctly, or the agent could not establish a session with our servers. Node's async nature makes some areas of tracing difficult, and it may be possible that your app is escaping our tracer at some points. In these situations, the more detail you have the better, and the faster we can reproduce your error the faster it can be fixed.

@santihbc I followed your template, and could not replicate the error.

@lyric if you have more info, especially logs I would be glad to take a look. You may want to email those to support when you get the chance.

@mdarnall I'm happy you got the agent working, but you may be introducing some subtle errors. I'm cool with that if it works, but I would ask that if you file a future ticket make sure to mention your modifications.

Thanks for your support on this, our browser agent team is awesome, so I definitely want to get their product out to all our node customers.

lyric · 2014-04-07T16:28:27Z

Thanks @groundwater. It is working for us now. We are now trying to get better reporting for a single page app.

santihbc · 2014-04-07T23:21:38Z

@lyric can you share the solution please? :)

groundwater · 2014-04-22T22:16:07Z

I'm going to close this issue in a few days, not because I think everyone's issue has been solved, but because I think this issue has grown and diverged too much to be useful to people.

If you are still having an issue, I encourage you to use our support channel so we can better track the success of each ticket.

hparra · 2014-05-11T04:07:57Z

It would be great if != newrelic.getBrowserTimingHeader() worked directly from a jade template as is suggested. Unfortunately, I believe this is not possible due to jade template caching, which is enabled in Express for NODE_ENV=production by default. I suspect this is the same for other engine and framework combinations.

As @groundwater suggested above, I had to call newrelic.getBrowserTimingHeader() in each route and pass the result into my jade templates. :/

I recommend at least mentioning this somewhere in the README. Similarly I found documentation about the Browser feature very difficult to find. Leaving links for whomever lands here as well:

sebastianhoitz · 2014-07-07T15:49:34Z

I updated to version 1.7.5 and am still experiencing the NREUM(1) messages. :(

txase · 2014-07-18T14:03:17Z

Hi @sebastianhoitz,

We are transitioning away from using the GitHub issue tracker for support of the Node.js Agent. Instead, please go to http://support.newrelic.com. You will have a better experience through our support portal than we have been able to provide here on GitHub.

We appreciate your understanding as we undergo this transition.

feat: Add Nest.js application example demonstrating file based agent config

…wrelic#125)

NEWRELIC-4422: remove __NR prefix properties and usage

Resolves several dev npm audit warnings.

groundwater closed this as completed Apr 29, 2014

snyk-bot mentioned this issue Feb 3, 2023

[Snyk] Upgrade @newrelic/koa from 7.0.0 to 7.1.1 #1496

Merged

cmcadams-newrelic pushed a commit to cmcadams-newrelic/node-newrelic that referenced this issue Jan 29, 2024

Merge pull request newrelic#125 from jmartin4563/nestjs-config-file

2a19416

feat: Add Nest.js application example demonstrating file based agent config

jsumners-nr pushed a commit to jsumners-nr/node-newrelic that referenced this issue Apr 11, 2024

ci: Removed use_new_release input from prepare release workflow (ne…

78fbc51

…wrelic#125)

jsumners-nr pushed a commit to jsumners-nr/node-newrelic that referenced this issue Apr 15, 2024

ci: Removed use_new_release input from prepare release workflow (ne…

b8586b6

…wrelic#125)

bizob2828 pushed a commit that referenced this issue Apr 15, 2024

ci: Removed use_new_release input from prepare release workflow (#125)

9518f44

jsumners-nr pushed a commit to jsumners-nr/node-newrelic that referenced this issue Apr 16, 2024

Merge pull request newrelic#125 from jordigh/remove-dunder

dcd4a3d

NEWRELIC-4422: remove __NR prefix properties and usage

bizob2828 added a commit to bizob2828/node-newrelic that referenced this issue Apr 19, 2024

Merge pull request newrelic#125 from michaelgoin/audit-fix

8e81528

Resolves several dev npm audit warnings.

bizob2828 added a commit to bizob2828/node-newrelic that referenced this issue Apr 23, 2024

Merge pull request newrelic#125 from michaelgoin/audit-fix

f65ba56

Resolves several dev npm audit warnings.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

NREUM: (1) instead of Javascript? #125

NREUM: (1) instead of Javascript? #125

sebastianhoitz commented Mar 15, 2014

groundwater commented Mar 15, 2014

sebastianhoitz commented Mar 15, 2014

sebastianhoitz commented Mar 15, 2014

groundwater commented Mar 17, 2014

sebastianhoitz commented Mar 22, 2014

groundwater commented Mar 24, 2014

santihbc commented Mar 29, 2014

groundwater commented Mar 31, 2014

santihbc commented Mar 31, 2014

groundwater commented Mar 31, 2014

santihbc commented Apr 1, 2014

lyric commented Apr 2, 2014

mdarnall commented Apr 2, 2014

lyric commented Apr 3, 2014

groundwater commented Apr 3, 2014

lyric commented Apr 7, 2014

santihbc commented Apr 7, 2014

groundwater commented Apr 22, 2014

hparra commented May 11, 2014

sebastianhoitz commented Jul 7, 2014

txase commented Jul 18, 2014

NREUM: (1) instead of Javascript? #125

NREUM: (1) instead of Javascript? #125

Comments

sebastianhoitz commented Mar 15, 2014

groundwater commented Mar 15, 2014

sebastianhoitz commented Mar 15, 2014

sebastianhoitz commented Mar 15, 2014

groundwater commented Mar 17, 2014

sebastianhoitz commented Mar 22, 2014

groundwater commented Mar 24, 2014

santihbc commented Mar 29, 2014

groundwater commented Mar 31, 2014

santihbc commented Mar 31, 2014

groundwater commented Mar 31, 2014

santihbc commented Apr 1, 2014

lyric commented Apr 2, 2014

mdarnall commented Apr 2, 2014

lyric commented Apr 3, 2014

groundwater commented Apr 3, 2014

lyric commented Apr 7, 2014

santihbc commented Apr 7, 2014

groundwater commented Apr 22, 2014

hparra commented May 11, 2014

sebastianhoitz commented Jul 7, 2014

txase commented Jul 18, 2014