We use following fields for proxy logs:
- client.ip
- server.ip
- destination.ip
Or to describe it in details for one proxy system we use client/destination pair (client.ip - CLIENT; destination.ip, destination.network, ... - to ORIGIN server). In another proxy system it is client/server - here client is communicating primarily with proxy and sometimes the requests are being forwarded to some specified backends.
This makes sense for us and is readable. But this also creates a question if source/destination should be always be populated if one of the source/destination fields is already part of the event?
Maybe client/source/server/destination usage should be more discussed here as I found (squid logs parsing, haproxy parsing) source-client-server-destination convention is often used in different ways for different purposes.
Btw. I found there are systems (like SIEM solutions) which usually recognizes only src/dst (so in this case src is client.ip and dst should be server.ip). But this is not always win as I noticed it sometimes creates a mess. So I like this ECS separation.
We use following fields for proxy logs:
Or to describe it in details for one proxy system we use client/destination pair (client.ip - CLIENT; destination.ip, destination.network, ... - to ORIGIN server). In another proxy system it is client/server - here client is communicating primarily with proxy and sometimes the requests are being forwarded to some specified backends.
This makes sense for us and is readable. But this also creates a question if source/destination should be always be populated if one of the source/destination fields is already part of the event?
Maybe client/source/server/destination usage should be more discussed here as I found (squid logs parsing, haproxy parsing) source-client-server-destination convention is often used in different ways for different purposes.
Btw. I found there are systems (like SIEM solutions) which usually recognizes only src/dst (so in this case src is client.ip and dst should be server.ip). But this is not always win as I noticed it sometimes creates a mess. So I like this ECS separation.