New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add opt-in support for outputing configureable HTTP access logs to loggregator #57
Comments
@gberche-orange Looks like a good set of requirements to me. Issue opened. |
Thanks @nebhale |
@gberche-orange
This is created with a default pattern specified in valves config in the Buildpack with this pattern. The valve will be disabled by default and can be enabled with a configuration property in tomcat.yml. |
Thanks @cgfrost for working on this enhancement. The default format seems to match the Common Log Format (CLF). While tempting to rely on a default log format, I fear this duplicates too much the data already present in the Reproducing below the access log valve format for ease of reading:
The router log format approx matches the pattern I rather believe the tomcat default access format should complete the From the available fields, I would favor the following ones: %t - Date and time, in Common Log Format The I believe the As a summary, I would suggest:
|
Hi @gberche-orange this has now gone out in release 2.4. I have raised a new issue to cover changing the log format. I agree with your reasoning and it's a small change but will have to wait for the next release now. Prefixing the X-Vcap-Request-Id header is also good as hopefully it will be more obvious when/if that headers name changes. |
Thanks @cgfrost. To ease others willing to follow details, here are: |
From GitHub issue #57. The current access logging pattern isn't as useful as it could be. The logs will often be viewed alongside with the Router logs and should provide complementing information and not overlap with it. [#74837854]
This change has now been commited. |
great, thanks a lot @cgfrost for this work ! |
I have read the whole thread on the ML, but I don't understand why this has been implemented in a way that obnly operators can use/configure it. This makes this feature pretty much useless for all hosted environments like 'run.pivotal.io' or 'swissom'. Or do you expect the hosters to do such a configuration for each app on request? |
Following up #30 (comment)
The gorouter currently generates non configureable http access traces of the following format (see access_log_record.go for desc of each field)
This has the following limitations for app-dev or app-ops:
Fortunately, the gorouter now generates a
X-Vcap-Request-Id
(may be ultimatelyX-Request-Id
see cloudfoundry/gorouter#29 ) in the HTTP header of requests send to apps and logs this request in the router access logs. This enables correlation with more detailed access logging that can be done in apps themselves or with support from the java-buildpack.This is consistent with the heroku approach documented at https://devcenter.heroku.com/articles/http-request-id
Currently, the java-buildpack allows to tune the tomcat configuration files (e.g. server.xml and to turn on the access valve ) by forking the buildpack and placing customized file into the
resources/tomcat
directory.To make it easier for java-buildpack users, I'm suggesting to offer the configuration by default in the javabuildpack and limit the amount of configuration work in required by app-ops.
I'm therefore suggesting the java-buildpack to allow ops to opt-in access logs:
[ACCESS]
prefix to differentiate access logs from app logs ([STDOUT]
) or container logs ([CONTAINER]
)X-Vcap-Request-Id=<value>
config/tomcat.yml
with new property such asaccess_login.enabled=true
(and ideally in the future ENV var controlled opt-in as to avoid most forks for turning on access logs)App-ops can then still fork the buildpack to tune the access logs format (or ideally control it with an env var in the future)
App-ops that require to dynamically turn the access logs can embed JMX remoting app such as jolokia ( related discussion into the tracker 46897105 ) to control the RemoveValve bean
Ideally in the future, the following details would be added to the gorouter, to fully enable debugging the router/app http chain (feature parity with heroku router log format ):
The text was updated successfully, but these errors were encountered: