Update the analytics CR to customize data in your analytics deployment.
About this task
You can define filters that add, modify, or remove fields from the incoming API event records,
before they are stored in API Connect or offloaded to a
third-party system.
Procedure
-
Open the analytics_cr.yaml file for editing.
-
Filters for API events that are offloaded to an
external system are defined in the
external.offload
section. Filters for API events
that are stored in the API Connect
OpenSearch database are defined
in the ingestion
section.
- Ingestion filters - for API event data stored by API Connect
- Add the filter definition to the
ingestion
section:spec:
ingestion:
...
filter: |
mutate {
remove_field => ["query_string"]
}
- Offload filters - for API event data that is sent to a third-party system.
- Add the filter definition to the
external.offload
section:spec:
external:
offload:
filter: |
mutate {
remove_field => ["query_string"]
}
For more examples, see Sample filters for modifying analytics data.
- Optional: Include geoIP fields in your analytics data, for
both stored and offloaded data, by inserting
geoIPEnabled: true
in the ingestion
section:
ingestion:
...
geoIPEnabled: true
By default the client_geoip
and gateway_geoip
fields are not
included in the analytics data. You do not need to add geoIPEnabled
to the
external.offload
section. Enabling geoIP in the ingestion
section
enables it for both data routes.
Note: To ensure the value in the client_geoip
field is
accurate, the gateway must receive the X-Forwarded-For
header in all API calls.
Check with the administrator of your deployment environment to ensure that the
X-Forwarded-For
header is passed to your gateways. For example, in a Kubernetes
environment where NINGX ingresses are used, configure the NGINX ingress that is used by your gateway
to use the X-Forwarded-For
header: NGINX Configuration "use-forwarded-headers".
-
Save the file. Changes to filters take effect after approximately 30 seconds.