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 <> wrote:
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 <> wrote:


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

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 /statements?ascending=true&since=2015-06-30T14%3A10%3A03.078Z&skipStatementId=30a88204-0779-4385-9859-e4aabd30baf0 HTTP/1.1" 200 0 17 "-" "NING/1.0" x_forwarded_for:"-" vcap_request_id:1e58195a-cde6-4afd-7f03-43061c9ea91c 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