Upgrade an app to Node 18 breaks APM with the default configuration

[ddolcimascolo]

Describe the bug

Under Node 18, on a system with ipv6 enabled, localhost resolves to ::1 (the ipv6 address) while under Node <= 16 it resolved to 127.0.0.1 (the ipv4 address). Considering that APM server listens on the ipv4 address only in these conditions if using the default configuration (as per elastic/apm-server#1405), upgrading an application using this agent from Node 16 to Node 18 (now that Node 18 is LTS) will prevent APM from working because the agent defaults serverUrl to http://localhost:8200.

To Reproduce

Upgrade an existing app using this agent to Node 18.

Expected behavior

APM keeps on working fine after the Node upgrade.

Environment (please complete the following information)

• OS: Ubuntu 22.04
• Node.js version: 18
• APM Server version: 8.5.1
• Agent version: Latest

How are you starting the agent? (please tick one of the boxes)

• Calling agent.start() directly (e.g. require('elastic-apm-node').start(...))
• Requiring elastic-apm-node/start from within the source code
• Starting node with -r elastic-apm-node/start

Additional context

Suggested fix: Default serverUrl to http://127.0.0.1:8200

[ddolcimascolo]

For the record, simply configuring the agent to connect to http://127.0.0.1:8200 fixes the problem. I'm personnaly using the environment variable ELASTIC_APM_SERVER_URL=http://127.0.0.1:8200

[ddolcimascolo]

Reference to the change in NodeJS: nodejs/node#39987

[trentm]

Agreed on changing the default as you suggest. Thanks for this issue, @ddolcimascolo!

I actually ran into the same basic issue earlier when adding support for Node v17 here: #2380 (comment)
and I learned of the Node.js dns.lookup behaviour change on this issue: nodejs/node#40537

However, I hadn't made the logical leap that this would break usage of the APM agents usage of 'localhost' for the serverUrl config var.

I still have some changes to add to my PR. I likely won't get a release out for about a week.

[trentm]

Side note: Recently supported Lambda Node v18 containers not currently affected. With this handler code:

  dns.lookup('localhost', {all: true}, (err, results) => {
      console.log('XXX dns.lookup(localhost) results:', results)
  })

the result is:

2022-11-28T23:25:30.105000+00:00 2022/11/28/[$LATEST]9e3e3d9871304fa9b4c399485d4a4618 2022-11-28T23:25:30.105Z	5a0afd7a-e206-4b18-9a0f-93dcc90b36e9	INFO	XXX dns.lookup(localhost) results: [ { address: '127.0.0.1', family: 4 }, { address: '::1', family: 6 } ]

I.e. the IPv4 "localhost" result is first. I.e. the system resolver is returning the IPv4 address first.

[ddolcimascolo]

Thx for fixing @trentm!