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());
>>>>>>>
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
--
---
Marco Neumann
KONA
