JS code for Browser seems to be incomplete

Hello everyone. I’m not being able to get all the information on the Browser section page for my instances. When I verified the JS code located on the head tags I noticed that the loader_config object seems to be missing some of the properties (e.g. agentID, trustKey, accountID, xpid). It only hasdefined licenseKey and applicationID properties. The Browser was installed as part of the APM agent installation. Could it be the root cause of me not being able to get all the information on the Browser section page? If that is the case does anyone know how to fix it? Thanks in advance.

Regards

Hi @martin.fernandez

Thanks for reaching out, I hope you are well.

I notice this the first post of yours in the community. Congrats!

Im happy to help here, but need a little more context. Can you provide a permalink to where are checking for agentID, trustKey, accountID and xpid. This will give us some more clarity for support.

Please do note only New Relics will have access to this link. Should you have additional questions please do reach out also.

Hi @dcody, first of all thanks for answering my post. Regarding your question and just to understand your request, do you a mean a permalink to my app Browser monitoring page where the data is not being displayed? Thanks again.

Hi @martin.fernandez

Can you share where you are seeing the trust key located, only New Relics will have access to this, But with this link to where you are / arent seeing the info needed will give us more context.

Hi @dcody, first of all I would like to apologize for the delay. For instance, on this url support.invgate.com, in the JS code generated by new relic on the HEAD tags (specifically in the loader_config object) you can see that it is only sending the applicationID property and the licenseKey property. Currently if I go to the Browser section on New Relic for that instance, I’m not being able to get all the information that the page is supposed to display. I’ve applied every step listed on the Browser troubleshooting page and I’m still not able to get all the information on the browser section. I’ve deployed that same application on my development environment, and installed there the APM agent and when I go to the Browser section on New Relic and select that instance I’m fully able to get all the information displayed. So I decided to compare the JS code generated on the HEAD tags for both instances, and that was the moment when I realized that there were differences on the number of properties located in the loader_config object (the instance that is working is also sending agentID, trustKey, accountID, xpid as part of that object). That triggered my original question, assuming that those properties are required to be defined on the loader_config object. Is that correct? If that is not the case, is there a support channel where I could find some help to determine the root cause of this issue? Thanks a lot

Hi @dcody , this is the new relic permalink where I’m not being able to get the Browser information for the instance I’ve mentioned in the last message

https://onenr.io/0ERPpWvvGRW

Thanks!

Hey @martin.fernandez,

Thank you for the response and providing us with further information. We are looping in a support engineer from the browser team to look over this with us. The team will get a response out shortly when we have an answer for you. We may also reach out for further information so keep an eye on this thread as we provide support.

Please let us know if we can assist with anything else as well. I hope you have a great day.

Hey @martin.fernandez!

You may want to try manually instrumenting via API.

To give you more insight, here are some things that can cause automatic browser instrumentation to not work:

Content-length header has been modified

  • The user modifies the Content-length header. The PHP agent needs to recalculate and update this value to include the snippet. If the agent detects that it has been modified, the agent bails out on snippet insertion.

Content-type header is not text/html

  • The mime type must be set to html. Frequently, if you see odd behavior like a pdf that contains some HTML getting the snippet, it’s because this header is set to text/html instead of something like application/pdf

Output buffering has been flushed or otherwise tampered with

  • The PHP Agent creates an output handler buffer solely for the purpose of attaching a callback function which inserts the agent.

Malformed HTML - appears before

  • The agent bails out of the insertion if it can’t make sense of the page’s positional elements.

A page might stream its output and never actually flush the buffer

  • The additional output handler buffer the agent attaches its snippet insertion callback function to might never actually end

zliboutput_compression is on (check in php.ini )

  • The zlib extension has the option to compress pages on the fly as it outputs them. This creates its own buffer, which can conflict with the output buffer the PHP agent uses to detect the correct time to insert the snippet

Drupal cache is compressing and serving cached pages

  • Since pages are being compressed and then served, the agent never has a chance to see the uncompressed version and insert the snippet.