Set Per-route Sidecar Filters

The Grey Matter Route object offers the ability to configure filters on specific routes of a domain. Read the reference documentation on per route filter configuration here.

This guide will walk through the steps of setting two different configurations of the Grey Matter observables filter on different routes. To demonstrate this, step 1 provides the files to deploy a fibonacci service and configure it into the mesh for testing. For a step by step guide on service deployment, see the Quickstart Launch Service to Kubernetes or the Service Deployment guide. To test the per filter route configuration for observables on a service already existing in the mesh, skip to step 2.

Pre-requisites

  1. An existing Grey Matter deployment following the Grey Matter Quickstart Install with Helm/Kubernetes guide.

    1. This guide assumes you've followed the step to configure a load balancer for ingress access to the mesh. If so, you should have a URL to access the Grey Matter Intelligence 360 application (e.g. a2832d300724811eaac960a7ca83e992-749721369.us-east-1.elb.amazonaws.com:10808).

    2. Make note of your load balancer ingress URL and use it wherever this guide references {your-gm-ingress-url}.

  2. greymatter setup with a running Fabric mesh.

Overview

  1. Deploy and configure a Fibonacci service

  2. Enable the Grey Matter observables filter

  3. Enable per filter route configurations on a specific route

Steps

1. Deploy and configure a fibonacci service

Deploy and configure a fibonacci service following the Quickstart Launch Service to Kubernetes Guide.

If you are using a non-SPIFFE/SPIRE deployment, follow this guide instead.

Before you move on to the next step of this guide, you should be able to see Fibonacci on the dashboard and successfully connect to the service. The fibonacci service route will be at https:///{your-gm-ingress-url}:30000/services/fibonacci/. You should see Alive when you navigate to this route in a browser. Try https:///{your-gm-ingress-url}:30000/services/fibonacci/fibonacci/37 to get the 37th fibonacci in response, 24157817.

2. Enable the Grey Matter observables filter

Now we will turn on the observables filter for the Fibonacci service. The configuration that we add to the fibonacci-listener object will enabled observables on all of the routes from it's domain. Make sure that the greymatter CLI is set up.

greymatter edit listener fibonacci-listener

Add the following configuration

"active_http_filters": [
"gm.observables"
],
"http_filters": {
"gm_observables": {
"topic": "fibonacci-topic",
"eventTopic": "fibonacci-event-topic",
"logLevel": "debug"
}
}

Check the logs kubectl logs deployment/fibonacci sidecar -f and hit the fibonacci endpoint https://{your-gm-ingress-url}/services/fibonacci/ in a browser, you should see something that looks like the following:

6:05PM DBG Message publishing to STDOUT; emitFullResponse = false
Encryption= EncryptionKeyID=0 Filter=Observables Topic=fibonacci-topic

followed by the observable string of JSON.

3. Configure and test two different route filter configurations

Now we will configure and test per route filter configurations. To do this, we'll add a route from the fibonacci sidecar to the fibonacci service.

The route looks for the /fibonacci/37 path, so any request into the mesh at https://{your-gm-ingress-url}/services/fibonacci/fibonacci/37, looking for exactly the 37th fibonacci number, will use this route.

Per route filter configurations are configured by the filter_metadata field of the route object. The filter configuration we will make for this route specifically is to turn emitFullResponse in the observables filter to true. This means that for any request to https://{your-gm-ingress-url}/services/fibonacci/fibonacci/37, the full response body will be printed in the observable.

Save this route in the /mesh directory as fibonacci-route-37.json

{
"zone_key": "zone-default-zone",
"domain_key": "fibonacci-domain",
"route_key": "fibonacci-route-37",
"route_match": {
"path": "/fibonacci/37",
"match_type": "exact"
},
"filter_metadata": {
"gm.observables": [
{
"key": "emitFullResponse",
"value": "true"
}
]
},
"prefix_rewrite": "",
"shared_rules_key": "fibonacci-rules"
}
greymatter create route < mesh/fibonacci-route-37.json

Follow the logs again kubectl logs deployment/fibonacci sidecar -f.

First, hit any endpoint that isn't the 37th fibonacci number, try https://{your-gm-ingress-url}/services/fibonacci/, or https://{your-gm-ingress-url}/services/fibonacci/fibonacci/18. Since neither of those requests have path exactly equal to /fibonacci/37, neither will correspond to the fibonacci-route-37 route. The observable printed for both of those requests in the fibonacci logs should be preceeded with:

6:46PM DBG Message publishing to STDOUT; emitFullResponse = false
Encryption= EncryptionKeyID=0 Filter=Observables Topic=fibonacci-topic

Now, watch the logs and make a request to the fibonacci-route-37 route - https://{your-gm-ingress-url}/services/fibonacci/fibonacci/37. The observable JSON string should this time be preceeded with:

6:47PM DBG DecodeHeaders: route based config: changing emitFullResponse from false to true Encryption= EncryptionKeyID=0 Filter=Observables Topic=fibonacci-topic
6:47PM DBG Message publishing to STDOUT; emitFullResponse = true
Encryption= EncryptionKeyID=0 Filter=Observables Topic=fibonacci-topic

Notice the route based config log, as well as the emitFullResponse = true for this route only. If you inspect the JSON of the observable you will also see thar it contains a field "body", with value "24157817\n", the full body of the response.