On 03/05/13 18:45, Marco Neumann wrote:
Ok I see you are pushing hard for not exposing the fuseki endpoint
directly to the web in production.
On the topic of logging simply adding the following line to
org.apache.jena.fuseki.servlets.ServletBase would do for now I think.
log.info(request.getRemoteAddr());
"""
Returns the Internet Protocol (IP) address of the client or last proxy
that sent the request. For HTTP servlets, same as the value of the CGI
variable REMOTE_ADDR.
"""
which suggests to me it's "last hop", not "end-to-end".
It used to log something, which might have been getRemoteAddr and only
the TCP connection IP address was returned which is not the client
source IP in many cases.
Andy
On Fri, May 3, 2013 at 12:18 PM, Andy Seaborne <[email protected]> wrote:
On 03/05/13 16:37, Marco Neumann wrote:
another logging / monitoring question is it possible to access the
source IP in the log4j conversion pattern on INFO in fuseki 0.2.6
(Build date: 2013-02-20T12:04:26+0000)?
---
Marco Neumann
KONA
It's a good one to collect.
More generally, having a standard format request log.
The IP address it can access is the immediate previous machine. But if
you're running behind httpd, it'll be 127.0.0.0 or some such, not the
originating source IP address.
IMO: If your exposing access to the public WWW, it is better to front with
locked-down reverse proxy, including connection limiting. Java web
application servers (tomcat, jetty) do need a bit of protection.
A side-effect is that you can use whatever the proxy provides for logging,
which is usually highly configurable, and it'll work with many log analysis
tools. Good place for https termination as well.
This is one reason why the Fuseki logs are highly specialised to SPARQL - if
you want request logs, there are ways to get them. Fuseki logs add detail
you can't get elsewhere or not as clearly.
What could be done is a second (optional) log, output being the usual
combined log format, and presumably incorporating X-Forwarded-For (e.g. AWS
load balancers).
http://wiki.eclipse.org/Jetty/Tutorial/RequestLog
and tomcat for a WAR version.
As a reverse proxy setup already collects this, it's not a priority for me
personally but, as ever, if anyone wants to provide a patch, it'll get done.
Thoughts?
What I think we should avoid is bundling too much machinery into Fuseki.
Its replicating functionality available elsewhere and so it's likely Fuseki
is only going to have a not-as-good provision of such functionality.
Andy
