-
Notifications
You must be signed in to change notification settings - Fork 223
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Countless retries and log spam for misconfigure port. #31
Comments
For reference, this is the actual error that occurs. It's thrown by the agent and then caught again by the agent and so on:
|
If the agent ever goes into an infinite loop like this a trick is to add this config option: |
But obviously the agent shouldn't throw because of this. And it would be nice if we in some way to guard against these infinite call loops 🤔 |
After thinking about this I say that it's expected behaviour for the agent to throw in this case. So the actual issue here is the looping uncaught exception. I don't have a good way of detecting this at the moment. Suggestions much appreciated 😃 |
Should the agent really be allowed to throw exceptions rather than to just log them once per occurence? |
The looping uncaught exception should obviously not happen, but throwing if you provide invalid input is a fairly normal behaviour in Node.js land. You could argue that this module is a special case though, not sure. |
@Qard would love your input on this 😃 |
I don't really have an opinion either way. Crashing is fairly standard in Node.js, but also APM vendors generally try to have as little side effects as possible, so they generally downgrade internal errors to warnings and just disable themselves. If we want to just warn, we can catch the connection error internally and log that. If we want to throw, we could catch the connection error, put a special property on it and rethrow, then have our uncaughtException handler abort properly when it encounters an error with our special no-really-i-want-to-fail property. |
Do we have a decision for what to do about this? This issue has been open for awhile... |
No, but thanks for bumping it. We should find a good solution. After this was opened another related issue has been created as well: #232 |
The two options we have is either:
Only 1.ii handles the case where we throw by a mistake (e.g. a coding mistake or if someone passes us an unexpected argument that we try to access in a wrong way), so I'm leaning towards that solution. But I'm not sure how hard it would be to correctly detect these stack traces |
How have the changes in API v2 impacted this? Is this still relevant, or can we close this? |
This is also an issue with v2 as far as I can see. The backoff algorithm should take care of that however when we implement that |
Are these issues resolved? I am getting |
@coolboi567 No this particular issue is not resolved. There's a in-progress PR: elastic/apm-nodejs-http-client#17 But are you sure that this is the issue you're experiencing? From reading your description, I'm not entirely sure what you're experiencing |
Actually, I encountered this when I was checking the APM client behavior(and application's behavior) when APM server is down or different APM address was mentioned. Application behavior was fine. All the native functionalities seem to work fine. |
@coolboi567 Thanks for clarifying. It sounds like a slightly different but related issue. But the good news is that it will also be fixed by elastic/apm-nodejs-http-client#17. Regarding redirecting the log output: By default the agent will log to stdout/stderr. But you can supply a custom logger using the |
Well I get some thing when I miss configure something or missing some npm modules. However, I was checking my production server logs and found this for the first time -not quite sure if it's related - |
@MHDMAM That sounds unrelated to this issue. Could I get you to ask on our our Discuss forum instead please? 😃 |
@watson Hey Thomas, any suggestion on a lite logger to separate agent's output in a different file would be really helpful. |
@codebrain Pino is a light weight logger that should do the job - https://github.com/pinojs/pino/blob/master/docs/api.md#destination-sonicboom--writablestream--string |
@vigneshshanmugam Hey Vignesh, can I achieve the same without using any logging module? |
@coolboi567 The default logger used in the agent only writes logs to STDOUT/STDERR based on the log level and does not have support for writing it to files. Winston does support it - https://github.com/winstonjs/winston/blob/master/docs/transports.md#file-transport |
Hi @vigneshshanmugam - did you mean to mention @coolboi567 instead? |
@codebrain Oops yeah sorry for the spam.. updated my comment :) |
You can read how to change the logger here: https://www.elastic.co/guide/en/apm/agent/nodejs/current/configuration.html#logger |
We have done some improvements to this situation (see linked PRs and comments about changing the logger.), at this point we don't see any other clear improvement in this line. |
I misconfigured the apm server url by accident
serverUrl: 'https://localhost:82000'
.This lead to countless retries of sending data to the APM Server, see logs:
When I just misconfigure to another wrong port, e.g.
8201
I get a properConnection Refused
error.The text was updated successfully, but these errors were encountered: