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
Related
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.
Whenever I send a post request, I'm getting the following error. I couldn't track down where it is coming from.
SentryError: HTTP Error (429): Creation of this event was denied due to rate limiting
at new SentryError (/home/bwsuser/bws-verwaltung/node_modules/#sentry/core/dist/error.js:9:28)
at ClientRequest.<anonymous> (/home/bwsuser/bws-verwaltung/node_modules/#sentry/node/dist/transports/base.js:46:44)
at Object.onceWrapper (events.js:315:30)
at emitOne (events.js:116:13)
at ClientRequest.emit (events.js:211:7)
at HTTPParser.parserOnIncomingClient (_http_client.js:543:21)
at HTTPParser.parserOnHeadersComplete (_http_common.js:112:17)
at TLSSocket.socketOnData (_http_client.js:440:20)
at emitOne (events.js:116:13)
at TLSSocket.emit (events.js:211:7)
at addChunk (_stream_readable.js:263:12)
at readableAddChunk (_stream_readable.js:250:11)
at TLSSocket.Readable.push (_stream_readable.js:208:10)
at TLSWrap.onread (net.js:597:20)
anyone has any idea what might be causing that? or at least where to start looking.
I ran out of ideas here :/
anyone has any idea what might be causing that? or at least where to start looking. I ran out of ideas here :/
Yes, certainly, you need to look here at Quota Management | Sentry Documentation. It mostly happens when you run an app from a local dev server. Here's the summary right from the doc ...
Sentry completes a thorough evaluation of each event to determine if it counts toward your quota, as outlined in this overview. Detailed documentation for each evaluation is linked throughout. Before completing any of these evaluations, Sentry confirms that each event includes a valid DSN and project as well as whether the event can be parsed. In addition, for error events, Sentry validates that the event contains valid fingerprint information. If any of these items are missing or incorrect, the event is rejected.
Another hint, try to disable all your browser extensions and check if that call is gone. I just figure out it is called by a chrome extension for me.
Hope helps
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
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.
As of today, Dec 10th, 2013, it seems that passport-yahoo is unable to correctly complete the openid workflow. We are getting an invalid signature. My knowledge of openid is quite limited, and I am still looking into the issue. Can anyone provide some insight into this problem? Is anyone else running in to the same problem?
Here is the stack trace from node:
{
"message":"Failed to verify assertion",
"stack":"Failed to verify assertion (message: Invalid signature)
at app/node_modules/passport-yahoo/node_modules/passport-openid/lib/passport-openid/strategy.js:184:36
at app/node_modules/passport-yahoo/node_modules/passport-openid/node_modules/openid/openid.js:1063:12
at app/node_modules/passport-yahoo/node_modules/passport-openid/node_modules/openid/openid.js:1188:14
at app/node_modules/passport-yahoo/node_modules/passport-openid/node_modules/openid/openid.js:1269:7
at Object.openid.loadAssociation (app/node_modules/passport-yahoo/node_modules/passport-openid/node_modules/openid/openid.js:107:5)
at _checkSignatureUsingAssociation (app/node_modules/passport-yahoo/node_modules/passport-openid/node_modules/openid/openid.js:1231:10)
at _checkSignature (app/node_modules/passport-yahoo/node_modules/passport-openid/node_modules/openid/openid.js:1221:5)
at _verifyAssertionAgainstProvider (app/node_modules/passport-yahoo/node_modules/passport-openid/node_modules/openid/openid.js:1184:3)
at app/node_modules/passport-yahoo/node_modules/passport-openid/node_modules/openid/openid.js:1155:16
at app/node_modules/passport-yahoo/node_modules/passport-openid/node_modules/openid/openid.js:678:7
at app/node_modules/passport-yahoo/node_modules/passport-openid/node_modules/openid/openid.js:533:11
at done (app/node_modules/passport-yahoo/node_modules/passport-openid/node_modules/openid/openid.js:254:9)
at IncomingMessage.<anonymous> (app/node_modules/passport-yahoo/node_modules/passport-openid/node_modules/openid/openid.js:258:32)
at IncomingMessage.EventEmitter.emit (events.js:117:20)
at _stream_readable.js:920:16
at process._tickCallback (node.js:415:13)",
"name":"InternalOpenIDError",
"openidError":{"message":"Invalid signature"}
}
Yes - we started having intermittent issues starting this past Friday, then complete failure today. From Y! developer forums, it seems others are having the same problem - http://developer.yahoo.com/forum/OpenID-General-Discussion/OpenID-login-with-Yahoo-broke-today/1386713784256-49fd81b6-7752-4c9f-8b7c-728235c46bae
And in general testing a number of OpenID sites, Yahoo login doesn't work