Proxy support

[killnine]

Is your feature request related to a problem? Please describe. My employer has a proxy that outbound traffic is routed through. Unfortunately, the .NET agent doesn't seem to support proxy credentials like, say, the Ruby agent does.

Describe the solution you'd like I'd like to help implement proxy support for the client where users can supply a client URI, a plaintext username, and password for the agent to use in its outbound requests to APM servers (in this case, cloud instances). Alternatively, supplying a ClientCredential or NetworkCredential might be better from a security standpoint.

Describe alternatives you've considered Long-term, we whitelist URLs or IPs for resources we commonly use. However, we're prototyping our solution and authenticating through the proxy would normally be faster for a short-term solution. However, based on what our secops folks are saying, it doesn't seem like traffic is consistently routing to and from the same locations (maybe because of load balancing or something?) so their attempts to whitelist haven't worked.

Additional context We're evaluating APM Cloud solutions right now but stopped in our tracks because we can't reach out to the URL provided by the startup documentation. We're a .NET shop so this would really help things out and at least make it consistent with some other agents.

[gregkalapos]

Hi @killnine,

definitely sounds like a valid use-case.

Configs similar to what the Ruby agent has would be preferred.

To be very open here - this is not one of our top priorities right now, but as always we are super happy to take community PRs and I can also try helping with it.

Some ideas and hints in this regard:

• So, I'd suggest trying to implement configs similar to what the Ruby agent has, maybe proxy_headers is a bit more complicated, but if some configs are missing, it's totally fine. If the PR achieves useful functionality it'll be fine.
• Adding other configs to cover your use case (ClientCredential or NetworkCredential) is also fine.
• IConfigurationReader is a good place to start if you want to add a new config. You'll need to add the new properties to multiple classes, the best approach is to just follow how other configs are implemented - once you add the new properties to IConfigurationReader build errors will show what other classes you need to extend. Some configs are runtime changeable from Kibana, that's why configs are not trivial. I'd suggest ignoring that for now, these don't have to be live changeable in the first iteration.
• Reading config values is implemented in AbstractConfigReader - that's where you should parse the values from the config source.
• Here is where the HttpClient instance gets instantiated, that's where values from the config should be applied.
• If you want to debug the action of sending events to APM Server and see how the HttpClient instance looks like at a given point this could be a useful place to set a breakpoint - PayloadSenderV2 is the component that sends the data to the APM Server.
• Before you open a PR please take a look at our CONTRIBUTING.md
• Ping me if you have any question