The purpose and use-cases of the new component
The GeoIP processors adds information about the geographical location of IP addresses, based on data from the MaxMind GeoLite2 databases.
Example configuration for the component
Location of this database should be configurable and stored on disk.
For the ability to fetch we need a an account ID, license key and endpoint where to fetch it from.
Based on above we can have configuration like so:
database: path to a local file
account_id: account ID used to fetch
license_key: license key used to fetch
permalink: permalink generated used to fetch
field: field where ip is loaded from. default should probably be source.address (handle non ip e.g uri or .sock gracefully)
target_field: namespaced target e.g source.geo
auto_update: true
one of these needs to be used, if license key is specified and path is omitted we should try to fetch database and store it locally.
if path is specified, file does not exists and we have a license key we should fetch and place it at the specified location.
it path is specified, no license key we use this file
in case auto_update is enabled we should fetch database (in case account id, license and permalink are specified)
other way we either won't enrich or enrich with _geoip_expired_database
all other cases are erroneous.
mapping of service fields to semconv. As these fields are not part of SemConv yet i'm sticking to ECS definition that was donated. These would be subkeys to a target defined by target_field
| Service field |
SemConv/ECS |
Example |
| ip |
address |
12.34.56.78 |
| city_name |
geo.city_name |
Seattle |
| country_name |
geo.country_name |
United States |
| continent_code |
geo.continent_code |
NA |
| continent_name |
geo.continent_name |
North America |
| country_code2 |
geo.country_iso_code |
US |
| postal_code |
geo.postal_code |
98106 |
| region_name |
geo.region_name |
Washington |
| region_code |
geo.region_code |
WA |
| region_iso_code* |
geo.region_iso_code |
US-WA |
| timezone |
geo.timezone |
America/Los_Angeles |
| location* |
geo.location |
{"lat": 47.6062, "lon": -122.3321} |
| latitude |
geo.location.lat |
47.6062 |
| longitude |
geo.location.lon |
-122.3321 |
| domain |
domain |
example.com |
| asn |
as.number |
98765 |
| as_org |
as.organization.name |
OpenTelemetry - CNCF |
| isp |
mmdb.isp |
InterLink Supra LLC |
| dma_code |
mmdb.dma_code |
819 |
| organization |
mmdb.organization |
OpenTelemetry - CNCF |
Telemetry data types supported
Logs, metrics, traces.
Is this a vendor-specific component?
Code Owner(s)
@michalpristas
Sponsor (optional)
@andrzej-stencel
Additional context
This proposal is based on this Elasticsearch processor: https://www.elastic.co/guide/en/elasticsearch/reference/current/geoip-processor.html
Other alternative i considered is to skip fetching part and use only local database. this would require user to handle updating expired databases.
The purpose and use-cases of the new component
The GeoIP processors adds information about the geographical location of IP addresses, based on data from the MaxMind GeoLite2 databases.
Example configuration for the component
Location of this database should be configurable and stored on disk.
For the ability to fetch we need a an account ID, license key and endpoint where to fetch it from.
Based on above we can have configuration like so:
database: path to a local fileaccount_id: account ID used to fetchlicense_key: license key used to fetchpermalink: permalink generated used to fetchfield: field where ip is loaded from. default should probably besource.address(handle non ip e.gurior.sockgracefully)target_field: namespaced target e.gsource.geoauto_update: trueone of these needs to be used, if license key is specified and path is omitted we should try to fetch database and store it locally.
if path is specified, file does not exists and we have a license key we should fetch and place it at the specified location.
it path is specified, no license key we use this file
in case auto_update is enabled we should fetch database (in case account id, license and permalink are specified)
other way we either won't enrich or enrich with
_geoip_expired_databaseall other cases are erroneous.
mapping of service fields to semconv. As these fields are not part of SemConv yet i'm sticking to ECS definition that was donated. These would be subkeys to a target defined by
target_fieldTelemetry data types supported
Logs, metrics, traces.
Is this a vendor-specific component?
Code Owner(s)
@michalpristas
Sponsor (optional)
@andrzej-stencel
Additional context
This proposal is based on this Elasticsearch processor: https://www.elastic.co/guide/en/elasticsearch/reference/current/geoip-processor.html
Other alternative i considered is to skip fetching part and use only local database. this would require user to handle updating expired databases.