FAQ¶

No Data After Integration¶

Follow the steps below in order to quickly identify configuration, sampling, or network issues:

1. Confirm the SDK is initialized: The initialization code must be executed before any business events occur, and init() should be called only once per page.
2. Confirm the integration parameters are complete: applicationId is required; for public OpenWay use site and clientToken, for direct DataKit connection use datakitOrigin. Do not mix the two reporting methods.
3. Confirm session sampling: When troubleshooting for the first time, set sessionSampleRate to 100 to avoid false negatives due to sampling being missed.
4. Check the browser Console: Focus on the following initialization errors.

1. Check Network: Filter for /v1/write/rum. If no requests are found, verify initialization timing, sampling, and CSP. If requests fail, check the address, Token, CORS, proxy, and DataKit accessibility.
2. Check filter conditions in the console: Confirm the correct application is selected and check service, env, version, and the time range.

Basic troubleshooting steps can also be found in Web Application Integration > Verify Integration.

Cross-Origin Async Requests After Configuring allowedTracingUrls¶

To achieve full front-end to back-end tracing (commonly referred to as RUM, i.e., Real User Monitoring) when using APM (Application Performance Monitoring) tools, you need to configure both the frontend and backend accordingly. The following are the main steps and considerations.

Frontend Configuration¶

1. Install and configure the RUM SDK:

2. Install the RUM SDK provided by the APM tool in your web frontend application.

3. Configure the SDK, including setting allowedTracingUrls (a list of URL patterns for which Trace Headers are allowed to be injected) and traceType (the tracing type). For NPM + TypeScript integration, use the TraceType enum, e.g., TraceType.DDTRACE; the corresponding runtime value is ddtrace.

4. Send trace information:

5. The RUM SDK automatically adds the corresponding headers based on the traceType. For DDTrace, these include x-datadog-parent-id, x-datadog-origin, x-datadog-sampling-priority, x-datadog-trace-id, etc.

Backend Configuration¶

1. Set CORS policy:

2. Configure CORS (Cross-Origin Resource Sharing) on the backend server to allow requests from the frontend domain, and explicitly specify Access-Control-Allow-Headers to include all necessary trace information headers.

3. For example, if your backend uses Node.js and Express, add the CORS middleware and set the allowedHeaders property to include these trace headers.

const cors = require('cors')
app.use(
  cors({
    origin: 'https://your-frontend-domain.com', // Replace with your frontend domain
    allowedHeaders: [
      'x-datadog-parent-id',
      'x-datadog-origin',
      'x-datadog-sampling-priority',
      'x-datadog-trace-id',
      // Possibly other necessary headers
    ],
  })
)

1. Handle requests:
2. Ensure the backend service can receive and correctly process these trace information headers. These headers are typically used to correlate and trace requests within backend services.

Verification and Testing¶

• Test the configuration:

• Initiate a request from the frontend to the backend and check the HTTP headers of the network request to confirm the trace information was sent correctly.

• Check the backend server logs to verify the trace information was processed correctly.

• Debug and correct:

• If any issues arise (e.g., CORS errors, headers not sent), review the frontend and backend configurations and adjust as needed.

Important Notes¶

• Security: Ensure allowedTracingUrls only matches trusted request URLs to avoid injecting Trace Headers into unintended targets.
• Performance: Although trace information is crucial for performance monitoring, ensure it does not negatively impact your application's performance.

By following these steps, you can successfully configure the APM tool to support full front-end to back-end tracing, enabling more effective monitoring and optimization of your web application's performance.

Script error¶

When using the Guance Web RUM SDK to collect errors on the web side, you often see Script error in js_error. Such error messages do not contain any detailed information.

Possible causes for the above issue:

1. The user's browser does not support error capture (very low probability).
2. The offending script file is loaded cross-origin on the page.

For cases where the user's browser does not support it, we cannot do anything. Here we mainly address the cause and solution for cross-origin script errors that cannot be collected.

Typically, script files are loaded using the <script> tag. For same-origin scripts, when using the browser's GlobalEventHandlers API, the collected error information includes detailed error details. When a cross-origin script errors, the collected error information is only the Script error. text, which is controlled by the browser's same-origin policy and is normal behavior. For cross-origin scripts, we need to perform Cross-Origin Resource Sharing (also known as HTTP Access Control / CORS).

Solutions:

Script file stored directly on the server:

Add the following Header to the static file output on the server:

Access-Control-Allow-Origin: *

Add the crossorigin="anonymous" attribute to the Script tag where the cross-origin script is loaded:

<script type="text/javascript" src="path/to/your/script.js" crossorigin="anonymous"></script>

Script file stored on a CDN:

Add the following Header in the CDN settings:

Access-Control-Allow-Origin: *

Add the crossorigin="anonymous" attribute to the Script tag where the cross-origin script is loaded:

<script type="text/javascript" src="path/to/your/script.js" crossorigin="anonymous"></script>

Script file loaded from a third party:

Add the crossorigin="anonymous" attribute to the Script tag where the cross-origin script is loaded:

<script type="text/javascript" src="path/to/your/script.js" crossorigin="anonymous"></script>

Resource Data Collection Incomplete¶

The following phenomena may be considered as incomplete resource data collection:

1. Resource size-related data is 0
   Includes fields such as resource_transfer_size, resource_decode_size, resource_encode_size, resource_size.

2. Time-related data not collected
   Includes fields such as resource_dns, resource_tcp, resource_ssl, resource_ttfb, resource_trans, resource_first_byte, resource_dns_time, resource_download_time, resource_first_byte_time, resource_connect_time.

Possible Causes¶

• Connection reuse (Keep-Alive)
  When resource requests use keep-alive to maintain the connection, DNS lookup and TCP connection occur only on the first request; subsequent requests reuse the same connection, so related data may not be recorded or may be 0.

• Cross-origin resource loading
  If resources are loaded cross-origin without the relevant headers, the browser cannot collect complete performance data. This is the main cause of missing data.

• Browser compatibility
  In rare cases, some browsers may not support the Performance API, resulting in the inability to obtain resource-related performance data.

How to Resolve Data Missing Due to Cross-Origin Resources¶

1. Resource files stored on the server
Add the following HTTP Header to the resource files on the server:

Timing-Allow-Origin: *

2. Resource files stored on a CDN
Add the following HTTP Header to the resource files in the CDN configuration:

Timing-Allow-Origin: *

Reference Document

Resource resource_status Data Not Collected¶

In some cases, resource_status data may be missing, for the following reasons:

• Cross-origin resource loading
  If resources are loaded cross-origin without cross-origin access permissions, the browser cannot obtain the resource status information.

• Browser compatibility
  Some browsers may not support the Performance API, causing the related data to be unavailable (very rare).

How to Resolve Missing resource_status Data Due to Cross-Origin Resources¶

1. Resource files stored on the server
Add the following HTTP Header to the resource files in the server configuration:

Access-Control-Allow-Origin: *

2. Resource files stored on a CDN
Add the following HTTP Header to the resource files in the CDN configuration:

Access-Control-Allow-Origin: *

These configurations effectively resolve the data collection issues caused by cross-origin resources and ensure the browser can correctly obtain performance data. Reference Document.

Identifying Search Engine Bots¶

When conducting web activities, it is necessary to distinguish between real user activity and search engine activity. Use the following example script to filter sessions that have bots:

// regex patterns to identify known bot instances:
let botPattern = "(googlebot\/|bot|Googlebot-Mobile|Googlebot-Image|Google favicon|Mediapartners-Google|bingbot|slurp|java|wget|curl|Commons-HttpClient|Python-urllib|libwww|httpunit|nutch|phpcrawl|msnbot|jyxobot|FAST-WebCrawler|FAST Enterprise Crawler|biglotron|teoma|convera|seekbot|gigablast|exabot|ngbot|ia_archiver|GingerCrawler|webmon |httrack|webcrawler|grub.org|UsineNouvelleCrawler|antibot|netresearchserver|speedy|fluffy|bibnum.bnf|findlink|msrbot|panscient|yacybot|AISearchBot|IOI|ips-agent|tagoobot|MJ12bot|dotbot|woriobot|yanga|buzzbot|mlbot|yandexbot|purebot|Linguee Bot|Voyager|CyberPatrol|voilabot|baiduspider|citeseerxbot|spbot|twengabot|postrank|turnitinbot|scribdbot|page2rss|sitebot|linkdex|Adidxbot|blekkobot|ezooms|dotbot|Mail.RU_Bot|discobot|heritrix|findthatfile|europarchive.org|NerdByNature.Bot|sistrix crawler|ahrefsbot|Aboundex|domaincrawler|wbsearchbot|summify|ccbot|edisterbot|seznambot|ec2linkfinder|gslfbot|aihitbot|intelium_bot|facebookexternalhit|yeti|RetrevoPageAnalyzer|lb-spider|sogou|lssbot|careerbot|wotbox|wocbot|ichiro|DuckDuckBot|lssrocketcrawler|drupact|webcompanycrawler|acoonbot|openindexspider|gnam gnam spider|web-archive-net.com.bot|backlinkcrawler|coccoc|integromedb|content crawler spider|toplistbot|seokicks-robot|it2media-domain-crawler|ip-web-crawler.com|siteexplorer.info|elisabot|proximic|changedetection|blexbot|arabot|WeSEE:Search|niki-bot|CrystalSemanticsBot|rogerbot|360Spider|psbot|InterfaxScanBot|Lipperhey SEO Service|CC Metadata Scaper|g00g1e.net|GrapeshotCrawler|urlappendbot|brainobot|fr-crawler|binlar|SimpleCrawler|Livelapbot|Twitterbot|cXensebot|smtbot|bnf.fr_bot|A6-Indexer|ADmantX|Facebot|Twitterbot|OrangeBot|memorybot|AdvBot|MegaIndex|SemanticScholarBot|ltx71|nerdybot|xovibot|BUbiNG|Qwantify|archive.org_bot|Applebot|TweetmemeBot|crawler4j|findxbot|SemrushBot|yoozBot|lipperhey|y!j-asr|Domain Re-Animator Bot|AddThis)";

let regex = new RegExp(botPattern, 'i');

// Disable tracing header injection when the user agent matches the bot pattern
const allowedTracingUrls = regex.test(navigator.userAgent)
  ? []
  : ['https://api.example.com']

window.DATAFLUX_RUM.init({
  // ... config options
  allowedTracingUrls
})

Further Reading¶