I have configured the host to push network traffic using packet beat. On kibana, I was able to see packet beat dashboard too. But in my dashboard, i was not able to see the geolocation. When I check what packet beat sending to elastic search, I see it missing geolocation field. Can someone help me how can I configure my packet beat to include geolocation? Thanks for your help!
@andrewkroh Thanks you, for the quick response!
I have tried geoip configuration. Still I did not see Geolocation in kibana dashboard.
This is my configuration
# The name of the shipper that publishes the network data. It can be used to group
# all the transactions sent by a single shipper in the web interface.
# If this options is not defined, the hostname is used.
# The tags of the shipper are included in their own field with each
# transaction published. Tags make it easy to group servers by different
# logical properties.
#tags: ["service-X", "web-tier"]
# Uncomment the following if you want to ignore transactions created
# by the server on which the shipper is installed. This option is useful
# to remove duplicates if shippers are installed on multiple servers.
# How often (in seconds) shippers are publishing their IPs to the topology map.
# The default is 10 seconds.
# Expiration time (in seconds) of the IPs published by a shipper to the topology map.
# All the IPs will be deleted afterwards. Note, that the value must be higher than
# refresh_topology_freq. The default is 15 seconds.
# Internal queue size for single events in processing pipeline
# Configure local GeoIP database support.
# If no paths are not configured geoip is disabled.
# - "/usr/local/var/GeoIP/GeoLiteCity.dat"
A typical use case for geo-ip is monitoring requests to a your web servers. In this case the client IPs will be public. Often in this scenario the web-servers are located behind a load balancer so the client IP becomes the private IP of the load balancer. When this happens you can tell Packetbeat to not use the client IP from the request, but instead use the IP from the X-Forwarded-For header added to the request by the load balancer.
This is my use case.
I have two VM hosted on Azur at the different location. We are running our application on each host as docker container. docker container can receive packets from the internet and send packets to another container on the different host. I am running packet beat on both the VM host to capture the network traffic. Which gives us the pretty good view of latency, errors and Response times. But the only issue I was facing, I can not see geolocation on kibana due to private IP vs public IP. Kindly help me on this.
Where is the "client" in the diagram? What are the protocols? It seems odd that traffic flows into one VM but the return path is from a different VM.
When packets from the Internet hit the "worker docker container" they will pass through DNAT and this will modify their destination address to be the private IP of the docker container, but it will not modify the source address so it should remain as a public IP.
Clients can be in different locations. For example, Source is in US and Destination is in Belgium. Source and destination are sitting in a private network. VM's are providing tunneling service between source and destination. One VM close to the Source and other VM close to the destination. we are using Http (80) or Https (443). In packet beat, I am capturing traffic on 80 and 443 ports.