I am using application insights on my node js application and I keep on getting this error. Can you please help me
ApplicationInsights:CorrelationIdManager [ { Error: unable to verify the first certificate
at TLSSocket.<anonymous> (_tls_wrap.js:1105:38)
at ZoneDelegate.invokeTask (C:\src\xyz\xyz\xyz\node_modules\zone.js\dist\zone-node.js:275:35)
at Zone.runTask (C:\src\xyz\xyz\xyz\node_modules\zone.js\dist\zone-node.js:151:47)
at TLSSocket.ZoneTask.invoke (C:\src\xyz\xyz\xyz\node_modules\zone.js\dist\zone-node.js:345:33)
at emitNone (events.js:106:13)
at TLSSocket.emit (events.js:208:7)
at TLSSocket._finishInit (_tls_wrap.js:639:8)
at TLSWrap.ssl.onhandshakedone (_tls_wrap.js:469:38) code: 'UNABLE_TO_VERIFY_LEAF_SIGNATURE' } ]
You're seeing this error because of transient problems on the Application Insights backend, but the error should not be fatal and your app should continue working as expected (albeit with this message being printed).
In the default configuration of the Application Insights SDK for Node.js, communication with the backend is retried - so you should be able to ignore this error and still see telemetry show up in the Azure Portal.
If you've changed the defaults, the setting you'll want to make sure to set is .setUseDiskRetryCaching(true) For example:
appInsights.setup("key")
.setUseDiskRetryCaching(true)
.start()
If you want to suppress messages like this from the SDK you can disable internal logging: (Be aware you'll be suppressing other errors potentially as well)
appInsights.setup("key")
.setUseDiskRetryCaching(true)
.setInternalLogging(false, false)
.start()
If you're curious about the history of this issue, and why it spontaneously occurs, there's a long-running issue on GitHub here: https://github.com/Microsoft/ApplicationInsights-node.js/issues/180
Related
I am presently working through the Azure Rock Paper Scissors sample code found on Microsoft's website.I have built the application through Azure, and I have tested and published the Custom Vision resource. My Azure resources group looks like this.
When I run the application it opens, counts to three, takes a picture, and then stops functioning. The screen just sits there and when I go to Azure's Log Stream I get the following error:
(node:23732) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.(Use node --trace-deprecation ... to show where the warning was created)
Listening on \.\pipe\51f320fe-45d4-4c1b-8d7b-2dde79f0a294
ApplicationInsights:TelemetryClient [
'The URL object is failed to create.',TypeError [ERR_INVALID_URL]: Invalid URLat new NodeError (node:internal/errors:371:5)at onParseError (node:internal/url:552:9)at new URL (node:internal/url:628:5)at NodeClient.TelemetryClient.trackDependency (C:\PROGRA~2\SITEEX~1\NODEAP~1\293739~1.3\nodejs\node_modules\applicationinsights\out\Library\TelemetryClient.js:108:36)at ClientRequest. (C:\PROGRA~2\SITEEX~1\NODEAP~1\293739~1.3\nodejs\node_modules\applicationinsights\out\AutoCollection\HttpDependencies.js:224:24)at ClientRequest.clsBind (C:\PROGRA~2\SITEEX~1\NODEAP~1\293739~1.3\nodejs\node_modules\cls-hooked\context.js:172:17)at ClientRequest.emit (node:events:390:28)at ClientRequest.emitted (C:\PROGRA~2\SITEEX~1\NODEAP~1\293739~1.3\nodejs\node_modules\emitter-listener\listener.js:134:21)at TLSSocket.socketErrorListener (node:_http_client:447:9)at TLSSocket.emit (node:events:390:28) {input: 'https://<PUT_HOST_SERVER_HERE>:443',code: 'ERR_INVALID_URL'}]
Does anyone know how I might fix this?
I fixed this issue by looking at and correcting the config.json.
I have a node webapp that makes various API calls to Stripe using the stripe npm package. Sometimes I get errors like the one below. Notice that the stacktrace is truncated so that I cannot see which stripe API call causes the error and I also cannot see where in my app this API call is made.
Is there anything I can do to get better error stacktraces?
Error: Missing required param: customer.
at Function.generate (/home/molsson/dv/foobar/node_modules/stripe/lib/Error.js:39:16)
at IncomingMessage.<anonymous> (/home/molsson/dv/foobar/node_modules/stripe/lib/StripeResource.js:175:33)
at Object.onceWrapper (events.js:299:28)
at IncomingMessage.emit (events.js:215:7)
at IncomingMessage.EventEmitter.emit (domain.js:476:20)
at endReadableNT (_stream_readable.js:1183:12)
at processTicksAndRejections (internal/process/task_queues.js:80:21)
Note: the error itself is just an example. I have already fixed it. I just want to get better stacktraces or a better method of debugging these types of errors quickly.
I'm pretty sure my node version has async stacks by default:
$ node --version
v12.12.0
$ node -p process.versions.v8
7.7.299.13-node.12
I tried running with NODE_OPTIONS='--trace-warnings --stack-trace-limit=9999' but it didn't help.
Does it exists some kind of "async stacktraces across event emitters" debugging thing?
I found a good answer to this question myself. The stripe library fires and event before making a new API request, so you can print a stacktrace from there:
stripe.on('request', request => {
const currentStack = (new Error()).stack.replace(/^Error/, '')
console.log(`Making Stripe HTTP request to ${request.path}, callsite: ${currentStack}`)
})
I added a STRIPE_API_TRACING option to my app that I can turn on if I experience errors without stacks. With the tracing on I can just scroll a bit up in the log and see what API calls was dispatched just before the error happened.
The application insights keeps on throwing the following error every few minutes.
ApplicationInsights:Sender [ 'Ingestion endpoint could not be reached 5 consecutive times. There may be resulting telemetry loss. Most recent error:',
{ Error: unable to verify the first certificate
at TLSSocket.\u003canonymous\u003e (_tls_wrap.js:1116:38)
at ZoneDelegate.invokeTask (/usr/src/app/node_modules/zone.js/dist/zone-node.js:275:35)
at Zone.runTask (/usr/src/app/node_modules/zone.js/dist/zone-node.js:151:47)
at TLSSocket.ZoneTask.invoke (/usr/src/app/node_modules/zone.js/dist/zone-node.js:345:33)
at emitNone (events.js:106:13)
at TLSSocket.emit (events.js:208:7)
at TLSSocket._finishInit (_tls_wrap.js:643:8)
at TLSWrap.ssl.onhandshakedone (_tls_wrap.js:473:38) code: 'UNABLE_TO_VERIFY_LEAF_SIGNATURE' } ]
I reviewed the discussion GITHUB DISCUSSION and tried some proposed solution but it did not work.
Here is the code that I am using to connect to application insights.
let appInsights = require('applicationinsights');
appInsights.setup(config.APPINSIGHTS_KEY.trim())
.setAutoDependencyCorrelation(true)
.setAutoCollectRequests(true)
.setAutoCollectPerformance(true)
.setAutoCollectExceptions(true)
.setAutoCollectDependencies(true)
.setAutoCollectConsole(true)
.setUseDiskRetryCaching(true)
.start();
I am not 100% sure if there is any telemetry loss or not, but getting these errors all the time is annoying. Please help.
I've updated the github discussion thread. A fix on the ingestion side is in the works.
https://github.com/Microsoft/ApplicationInsights-node.js/issues/180#issuecomment-475699485
I used swagger (swagger.io) to built my app's API and everything works fine in production environment. However, when I ran some mocha tests on these APIs, I keep getting this error regarding status code 429 Too Many Requests:
Unhandled rejection Error: Too Many Requests
at Request.callback (..../node_modules/superagent/lib/node/index.js:698:17)
at IncomingMessage.<anonymous> (..../node_modules/superagent/lib/node/index.js:922:12)
at emitNone (events.js:91:20)
at IncomingMessage.emit (events.js:185:7)
at endReadableNT (_stream_readable.js:926:12)
at _combinedTickCallback (internal/process/next_tick.js:74:11)
at process._tickDomainCallback (internal/process/next_tick.js:122:9)
Usually this error happens after I ran the mocha test twice in a row (ie start throwing this error from the third time onwards). I suspected I was overloading my localhost server, but the error persisted even after I closed and reopened the server.
Would be super grateful if someone could point me towards the right direction to solve this problem.
I'm getting an error while working through https://cloud.google.com/nodejs/getting-started/using-pub-sub. (I've successfully completed previous tutorials in the series.)
With the command "SCRIPT=worker.js PORT=8081 npm start", I get this error related to background.js:
TypeError: Cannot call method 'on' of null
at /Users/xke/Documents/node.js/6-pubsub/lib/background.js:57:20
at /Users/xke/Documents/node.js/6-pubsub/node_modules/gcloud/lib/pubsub/index.js:256:7
at /Users/xke/Documents/node.js/6-pubsub/node_modules/gcloud/lib/common/util.js:684:11
at Object.handleResp (/Users/xke/Documents/node.js/6-pubsub/node_modules/gcloud/lib/common/util.js:192:5)
at Request._callback (/Users/xke/Documents/node.js/6-pubsub/node_modules/gcloud/lib/common/util.js:679:12)
at Request.self.callback (/Users/xke/Documents/node.js/6-pubsub/node_modules/request/request.js:354:22)
at Request.EventEmitter.emit (events.js:98:17)
at Request.<anonymous> (/Users/xke/Documents/node.js/6-pubsub/node_modules/request/request.js:1207:14)
at Request.EventEmitter.emit (events.js:117:20)
at IncomingMessage.<anonymous> (/Users/xke/Documents/node.js/6-pubsub/node_modules/request/request.js:1153:12)
Thoughts / solutions?
Thanks!
It appears this is a bug in the gcloud-node library. The library is supposed to automatically create the topic for you, but it appears that there is an edge case that the topic isn't automatically created when you try to subscribe to it.
In the meantime, there is a simple way around this: run the bookshelf app and create / edit a book. It'll cause the library to create the topic. This is because the library does correctly auto-create the topic when you try to publish to it. After that, you should be able to run the worker without error.
Alternatively, you can modify background.js#subscribe to check for the topic's existence and create it if necessary.