apm-agent-nodejs: Countless retries and log spam for misconfigure port.
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:
logging error 6a9ff729-cec0-45d5-bc5e-a57e27f2a25d with Elastic APM
logging error 54c4eb0f-5a98-4b41-b07e-5b4f60a2ba5f with Elastic APM
logging error 8cbe19af-37fb-468b-b9bf-8070b5531ca4 with Elastic APM
logging error f9d805e8-488f-4a41-b4f6-20154d8101fe with Elastic APM
logging error 53df0b4b-2cd0-419c-8af4-27be7f36d716 with Elastic APM
logging error 80fd91b6-c09f-48cb-8787-b8ac0d1d1775 with Elastic APM
logging error c9858407-17a3-4968-8cce-297e0bd31f3d with Elastic APM
logging error b3a69e7b-8eec-4580-a219-e72eb4e5b637 with Elastic APM
logging error 6935b29d-9629-4dc2-8b62-9954e6559693 with Elastic APM
logging error 6e31e7cb-4a2d-44e1-bb1c-279bef550de5 with Elastic APM
logging error cf647462-65e1-48e3-a3c4-15a3779bce6f with Elastic APM
logging error 79e1590c-bdad-4c41-b97e-ccc43189bdbb with Elastic APM
...
When I just misconfigure to another wrong port, e.g. 8201 I get a proper Connection Refused error.
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Comments: 27 (20 by maintainers)
Commits related to this issue
- feat: ignore internal errors Fixes #31 — committed to Qard/apm-agent-nodejs by deleted user 5 years ago
- feat: ignore internal errors Fixes #31 — committed to Qard/apm-agent-nodejs by deleted user 5 years ago
@codebrain Oops yeah sorry for the spam… updated my comment 😃
@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
loggerconfig option. That will allow you to redirect the output to a specific file.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.