Re: Allow gorouter to log random headers.

Shannon Coen

This is not something that would be merged, as originally proposed, without
additional investigation and discussion.

If I understand correctly, you're proposing that an operator of
CloudFoundry configure GoRouter, which is a multi-tenant, shared service,
with knowledge specific to one or a few applications. This should not be an
operator responsibility, nor should the solution be specific to one or a
few applications.

The goal is "the flexibility of being able to annotate our logs with what
we consider to be important for our debugging purposes." More specifically
you're requesting logging of headers. Do you have a preference?

If GoRouter logged whatever headers were included in the request, wouldn't
this satisfy your requirements? Doesn't GoRouter do this already?

I'm interested in solving your requirement generically for all
applications, and focussing the user experience on the correct persona.
Based on what you've described, the persona is the app developer, so
control of what is logged should be in their hands. I'm also not convinced
GoRouter should have any knowledge of headers specific to one application
or another.

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Wed, Jul 22, 2015 at 3:05 AM, Alex Lomov <alexander.lomov(a)>

Some time ago routing services were discussed on a CAB [1]. Here is a
description of this proposal.

Do you think that using such service will allow your developers to cover
this requirements?


On Jul 21, 2015, at 4:06 PM, Simon Johansson <simon(a)>


We have some devs who want to be able to trace a request troughout their

user -> a -> b -> c
|-> d -> e

When a user makes a request to "a" uuid is generated inside the app, and
the request to "b" from "a" will set a header(call it WAKAWAKA to uuid),
"b"'s call will passthrough WAKAWAKA to "c" and "d", "d" will passthrough
WAKAWAKA to "e". Etc.

We aggregate all RTR logs into ELK so it would be super helpful to them to
be able to filter on WAKAWAKA and get all the access logs(and app logs
aswell, they mostly use GELF so its easy for them to add whatewher field
they want) from the services involved.

I had a quick peek at the gorouter(
and it seems like this should be a simple PR.

1. To gorouter.yml add
- X-Random-Header

2. In makeRecord at the bottom add something like(in psuedo)

data = {}
for header in passthrough_headers:
header_val = r.FormatRequestHeader("X-Forwarded-For")
if header_val:
passthrough_headers[header] = header_val

if data:
fmt.Fprintf(b, data.to_stringified_json())

That would yield a log line like - [21/07/2015:10:17:05 +0000] "GET
HTTP/1.1" 200 0 17 "-" "NING/1.0" x_forwarded_for:"-"
response_time:0.004927106 app_id:9784cd03-050d-4b74-9e90-5f17134a3f08
{"WAKAWAKA": "Space is the place", "X-Random-Header": "Once upon a midnight
dreary, while I pondered weak and weary"}

The reason for a stringified JSON is to make it easy to parse with
logstash or other loganalysis tools.

Before I spend time implementing, is this something you would merge?
cf-dev mailing list

cf-dev mailing list

Join { to automatically receive all group messages.