apm
apm copied to clipboard
Proxy support - alignment
Some agents have a configuration to set a proxy to the http client which reports to APM Server.
Current status:
-
Ruby
- 5 different configs:
ELASTIC_APM_
+proxy_address
,proxy_headers
,proxy_password
,proxy_port
,proxy_username
- Likely heavily influenced by the ruby Http.rb API
- 5 different configs:
-
Python
- 2 (or 3) different configs:
HTTP_PROXY
/HTTPS_PROXY
,NO_PROXY
- these are generic configs, not only for the agent. If a user wanted to use different proxy settings for the agent and the underlying app, that could be problematic.
- 2 (or 3) different configs:
- Go
- Uses the Go standard library's support, net/http.ProxyFromEnvironment
- "HTTP_PROXY, HTTPS_PROXY and NO_PROXY (or the lowercase versions thereof). HTTPS_PROXY takes precedence over HTTP_PROXY for https requests."
- Node.js, .NET, Java, PHP : No such setting atm. (feel free to correct this if not the case)
It seems these settings are very different across agents. Some agents don't have this config (e.g. .NET) and it came up that we should support it in those agents as well.
Questions:
- Should we align across agents? (Given that these configs are very different at the moment)
- If so, what would be a good config?
- As a first suggestion I'd throw in a single config which takes a URL with a name something like
ELASTIC_APM_HTTP_PROXY
(happy to take another name, the point of the suggestion is to have a single config with a string value that takes a URL with all the URL address rules)
- As a first suggestion I'd throw in a single config which takes a URL with a name something like
- If not, do we agree on having these very different configs? (can be good reasons to have it tech specific)
Python is in a good place at the moment, judging by the (lack of) feedback. That said, it would be fairly trivial to align if we decide to do so. I don't have strong feelings on alignment, might be easier to keep it technology-specific.
Go does have proxy support, I've updated the description. I haven't seen enough requests to know if we should align, but if we do I'd prefer to use the de-facto standard names HTTP_PROXY
, HTTPS_PROXY
, NO_PROXY
.
Summary from agent weekly:
- No need to align at this point
- Since we had multiple requests for .NET, we'll implement this config for .NET as well - this implementation will be likely a single config (a string) because that fits how proxy configuration works in .NET.
- I'll draft a spec PR, which other agents could implement in the future (but that won't be a spec with
MUST
, so no need for agents with existing implementations to change anything).