globalTunnel
overrides all http requests, so assuming that the Loggly library uses the standard http
library, further proxy configuration in the Loggly library is not necessary.
I think there may be two issues here:
Linkerd Routing Rules
linkerd needs routing rules to proxy to the outside internet. You'll need a dtab that recognizes host:port
requests and routes them accordingly:
dtab: |
/ip-hostport => /$/inet;
/svc => /$/io.buoyant.hostportPfx/ip-hostport;
Confirm routing works with this command:
$ http_proxy=localhost:4140 curl -s -o /dev/null -w "%{http_code}" www.google.com:80
200
Loggly header processing
It appears that Loggly fails all requests that contain headers with forward slashes in them:
# working request:
$ curl -H "foo: bar" -s -o /dev/null -w "%{http_code}" logs-01.loggly.com
403
# failed request:
$ curl -H "foo: /bar" -s -o /dev/null -w "%{http_code}" logs-01.loggly.com
400
Linkerd sets several headers on outbound requests for tracing, service discovery, and context information. Some of those headers include strings with forward slashes.
To get around this, we have two options:
- Modify linkerd to clear headers on outbound requests. I've filed github.com/linkerd/linkerd/issues/1218 to track this work.
- Set up a proxy server to handle outbound requests for Loggly, as documented in https://github.com/loggly/loggly-jslogger#setup-proxy-for-ad-blockers. Then, assuming that service is set up at
internal-nginx-proxy
, you can use this routing rule:
dtab: |
/svc/logs-01.loggly.com => /$/inet/internal-nginx-proxy/80;