{"_id":"56a3e7da5fb2530d00421b5a","parentDoc":null,"user":"56a1f82b06150b0d002ad173","__v":21,"category":{"_id":"56a3e78a94ec0a0d00b39fed","pages":["56a3e79b5e57f20d000eae83","56a3e7c2545bc50d000e3abf","56a3e7da5fb2530d00421b5a","56a9fee32bb3910d000ee9ba","56aa2f502bb3910d000eea00","56aa38f6befafb1900044ccf","56aa38fa2bb3910d000eea0e"],"project":"56a1f77442dfda0d00046285","version":"56a1f77542dfda0d00046288","__v":7,"sync":{"url":"","isSync":false},"reference":false,"createdAt":"2016-01-23T20:50:18.363Z","from_sync":false,"order":0,"slug":"nodejs","title":"Node.js Monitoring"},"project":"56a1f77442dfda0d00046285","version":{"_id":"56a1f77542dfda0d00046288","__v":9,"project":"56a1f77442dfda0d00046285","createdAt":"2016-01-22T09:33:41.397Z","releaseDate":"2016-01-22T09:33:41.397Z","categories":["56a1f77542dfda0d00046289","56a1fdf442dfda0d00046294","56a2079f0067c00d00a2f955","56a20bdf8b2e6f0d0018ea84","56a3e78a94ec0a0d00b39fed","56af19929d32e30d0006d2ce","5721f4e9dcfa860e005bef98","574e870be892bf0e004fde0d","5832fdcdb32d820f0072e12f"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"1.0.0","version":"1.0"},"updates":[],"next":{"pages":[],"description":""},"createdAt":"2016-01-23T20:51:38.720Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":5,"body":"# Using debug logs to find issues\n\nIf you have problems using Trace, e.g it doesn't seem to report anything, the best first step is to check the logs. We use the lightweight [debug](https://github.com/visionmedia/debug) module for logging. If you are not familiar with it yet, please read its documentation. \n\nDebug logging is **not** enabled by default. In order to turn it on for Trace, start your app with the `DEBUG` environment variable set to `risingstack/trace*`.\n\nE.g.\n```\nDEBUG=risingstack/trace* node my_app.js\n```\n\nYou should start seeing information printed out to stderr.\n\nThis works when you occasionally turn on logging for troubleshooting, but it may generate too many messages if you use it on a production server. That's why we support a way to filter log messages based on severities and subcomponents within the library.\nTo make this possible Trace uses debug namespaces. All our debug messages are printed to a namespace starting with `trace/risingstack` then a `:` then a mandatory severity specifier,\n- `error`,\n- `warn` or\n- `info`.\n\nThen come zero or more namespaces designating subcomponents within Trace, separated by colons. The namespaces are hierarchically organized.\n\nCurrently these namespaces are used:\n\n- `config`\n- `instrumentation`\n- `agent`\n- `agent:tracer`\n- `agent:metrics`\n- `agent:profiler`\n- `agent:security`\n- `api`\n\nWhen filtering for a specific namespace, always append an `*` to it to get the messages targeting its subnamespaces.\n\nExamples:\n\n- get all error messages: `DEBUG='risingstack/trace:error*'`\n\n- get all messages from agents: `DEBUG='risingstack/trace:*:agent*'`\n\n- get all error messages and all messages from agents: `DEBUG='risingstack/trace:error*,risingstack/trace:*:agent*'`\n\n# Frequently asked questions\n\n## I integrated Trace with my service but it doesn't appear on the UI\n\nBy default the client sends information to our servers every two minutes, which means it's that long before the first data packet arrives from your service and it becomes visible. If you can't see your service on the [integration status page](https://trace-app.risingstack.com/#/integration/status) after that time, it possibly means the client is badly configured or its communication is blocked by a firewall.\n[block:callout]\n{\n  \"type\": \"warning\",\n  \"title\": \"Check our NODE_ENV\",\n  \"body\": \"If `NODE_ENV=test`, the Trace collector won't start.\"\n}\n[/block]\n### 1. Did you provide an API key for the client?\n\nSee the [Getting started](doc:getting-started) page on how to correctly set the API key. Normally a debug message gets printed indicating that the API key is left unset.\n\n### 2. Is your API key valid?\n\nEven if you set the API key, it can get rejected by our servers, e.g. you mistyped it, or your subscription has expired. Once again you can assert this by inspecting the debug logs, indicating.\nIn this case you have to check the status of your project to see if it is still active and its API key matches the one you use for the client.\n\n### 3. Is Trace allowed through your firewall?\n\nThe Trace client sends data over HTTPS to our API. You can enable debug information logging to see if communication is actually taking place. We are using the [debug](https://www.npmjs.com/package/debug) package to log debugging information. To make it visible in the application's console output, set the DEBUG environment variable to `risingstack/trace` when starting it.\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"DEBUG=risingstack/trace node index.js\\nrisingstack/trace Instrumented Module._load. +0ms\\nrisingstack/trace HttpTransaction is initializing... +103ms\\nrisingstack/trace Instrumented http.Server.prototype.on. +2ms\\nrisingstack/trace Instrumented http.Server.prototype.addListener. +0ms\\nrisingstack/trace Instrumented http.request. +4ms\\nrisingstack/trace Instrumented process._fatalException. +1ms\\nrisingstack/trace getting service id from the trace servers +2ms\\nrisingstack/trace raw response from trace servers:  +443ms {\\\"key\\\":0,\\\"name\\\":\\\"trace-node-js-example\\\"}\\nrisingstack/trace HttpTransaction service is set to:  +0ms 0\\nrisingstack/trace HttpTransaction initialized +0ms\\nrisingstack/trace HttpTransaction started collecting +1ms\\n\",\n      \"language\": \"shell\"\n    }\n  ]\n}\n[/block]\nIf Trace is able to fetch the service ID, there is probably nothing wrong. Otherwise if it fails to get it, and you are sure the problem is not related to your network configuration, rather our service, please contact us at [trace-support:::at:::risingstack.com](mailto:[email protected]).\n\n# Live help\n[block:callout]\n{\n  \"type\": \"info\",\n  \"title\": \"Live chat\",\n  \"body\": \"You can also start a live chat with our experienced developers via our in-app messenger.\\nWe are always happy to hear from you, don't hesitate to contact us.\"\n}\n[/block]\n\n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://files.readme.io/564ffcb-help-1.png\",\n        \"help-1.png\",\n        2560,\n        1218,\n        \"#2e546f\"\n      ],\n      \"caption\": \"Press the help button in the right corder to read more about the  current feature or contact us\"\n    }\n  ]\n}\n[/block]\n\n[block:image]\n{\n  \"images\": [\n    {\n      \"image\": [\n        \"https://files.readme.io/9423c04-help-2.png\",\n        \"help-2.png\",\n        2560,\n        1226,\n        \"#edf0f2\"\n      ],\n      \"caption\": \"Live chat with our team.\"\n    }\n  ]\n}\n[/block]","excerpt":"","slug":"troubleshooting","type":"basic","title":"Troubleshooting"}
# Using debug logs to find issues If you have problems using Trace, e.g it doesn't seem to report anything, the best first step is to check the logs. We use the lightweight [debug](https://github.com/visionmedia/debug) module for logging. If you are not familiar with it yet, please read its documentation. Debug logging is **not** enabled by default. In order to turn it on for Trace, start your app with the `DEBUG` environment variable set to `risingstack/trace*`. E.g. ``` DEBUG=risingstack/trace* node my_app.js ``` You should start seeing information printed out to stderr. This works when you occasionally turn on logging for troubleshooting, but it may generate too many messages if you use it on a production server. That's why we support a way to filter log messages based on severities and subcomponents within the library. To make this possible Trace uses debug namespaces. All our debug messages are printed to a namespace starting with `trace/risingstack` then a `:` then a mandatory severity specifier, - `error`, - `warn` or - `info`. Then come zero or more namespaces designating subcomponents within Trace, separated by colons. The namespaces are hierarchically organized. Currently these namespaces are used: - `config` - `instrumentation` - `agent` - `agent:tracer` - `agent:metrics` - `agent:profiler` - `agent:security` - `api` When filtering for a specific namespace, always append an `*` to it to get the messages targeting its subnamespaces. Examples: - get all error messages: `DEBUG='risingstack/trace:error*'` - get all messages from agents: `DEBUG='risingstack/trace:*:agent*'` - get all error messages and all messages from agents: `DEBUG='risingstack/trace:error*,risingstack/trace:*:agent*'` # Frequently asked questions ## I integrated Trace with my service but it doesn't appear on the UI By default the client sends information to our servers every two minutes, which means it's that long before the first data packet arrives from your service and it becomes visible. If you can't see your service on the [integration status page](https://trace-app.risingstack.com/#/integration/status) after that time, it possibly means the client is badly configured or its communication is blocked by a firewall. [block:callout] { "type": "warning", "title": "Check our NODE_ENV", "body": "If `NODE_ENV=test`, the Trace collector won't start." } [/block] ### 1. Did you provide an API key for the client? See the [Getting started](doc:getting-started) page on how to correctly set the API key. Normally a debug message gets printed indicating that the API key is left unset. ### 2. Is your API key valid? Even if you set the API key, it can get rejected by our servers, e.g. you mistyped it, or your subscription has expired. Once again you can assert this by inspecting the debug logs, indicating. In this case you have to check the status of your project to see if it is still active and its API key matches the one you use for the client. ### 3. Is Trace allowed through your firewall? The Trace client sends data over HTTPS to our API. You can enable debug information logging to see if communication is actually taking place. We are using the [debug](https://www.npmjs.com/package/debug) package to log debugging information. To make it visible in the application's console output, set the DEBUG environment variable to `risingstack/trace` when starting it. [block:code] { "codes": [ { "code": "DEBUG=risingstack/trace node index.js\nrisingstack/trace Instrumented Module._load. +0ms\nrisingstack/trace HttpTransaction is initializing... +103ms\nrisingstack/trace Instrumented http.Server.prototype.on. +2ms\nrisingstack/trace Instrumented http.Server.prototype.addListener. +0ms\nrisingstack/trace Instrumented http.request. +4ms\nrisingstack/trace Instrumented process._fatalException. +1ms\nrisingstack/trace getting service id from the trace servers +2ms\nrisingstack/trace raw response from trace servers: +443ms {\"key\":0,\"name\":\"trace-node-js-example\"}\nrisingstack/trace HttpTransaction service is set to: +0ms 0\nrisingstack/trace HttpTransaction initialized +0ms\nrisingstack/trace HttpTransaction started collecting +1ms\n", "language": "shell" } ] } [/block] If Trace is able to fetch the service ID, there is probably nothing wrong. Otherwise if it fails to get it, and you are sure the problem is not related to your network configuration, rather our service, please contact us at [[email protected]](mailto:[email protected]). # Live help [block:callout] { "type": "info", "title": "Live chat", "body": "You can also start a live chat with our experienced developers via our in-app messenger.\nWe are always happy to hear from you, don't hesitate to contact us." } [/block] [block:image] { "images": [ { "image": [ "https://files.readme.io/564ffcb-help-1.png", "help-1.png", 2560, 1218, "#2e546f" ], "caption": "Press the help button in the right corder to read more about the current feature or contact us" } ] } [/block] [block:image] { "images": [ { "image": [ "https://files.readme.io/9423c04-help-2.png", "help-2.png", 2560, 1226, "#edf0f2" ], "caption": "Live chat with our team." } ] } [/block]