Hi @herrBez,
Yes, typically you will use a combination of field sets together, when mapping your events to ECS. So using the source and destination pair is expected.
ECS doesn't really define anything for web or caching proxies per se, at this time, however. So you will likely have to add some custom (aka non-ECS) to your events to track additional information.
Adding sensible support for proxies is something that's been gnawing at me for a little bit, but we haven't had time to really look into it yet. Let's take the bull by the horns and get the discussion started, though.
Feel free to check out these past discussions for some ideas
You'll see that my suggestion in 158 and Mike's suggestion in 300 are conflicting 
So there's no definitive answer yet, until we actually sit down and add this to ECS proper. So track it in a way that makes sense to you in a custom field (maybe: haproxy.upstream.ip etc), and feel free to open aGitHub issue or a PR if you think you've figured out a schema that works well for proxies in general.
Here's a pointer for something you'll encounter, when mapping your upstream destinations.
ECS has a pattern of cramming whatever address format we get into .address and then pulling out the pieces (e.g. .ip, .port, .domain) depending on what we have in the address. This allows us to track all kinds of addresses: nginx/HAProxy can contain unix sockets in the "ip" field; httpd can contain hostnames in the "ip" field. So .address is guaranteed to always be filled, no matter the format. And if you know you specifically need the IP (e.g. doing geoip, ASN lookups), then you use the .ip field, which is filled most of the time.
I see an equivalent use case where if the upstream address you see in your logs looks like https://10.10.10.10:9200/some/path, you can put all of this into .address as is, then extract out the various interesting bits in a separate step.
Hope this helps. Let me know if you have other questions.
Mat