Hi,
For our application stack, we use Zipkin with a backing Cassandra store in a
Docker environment. This also uses a custom httpclient that is integrated into
the various levels of the app stack and service implementations. Zipkin adds a
custom header that is tracked through the calls.
Chris Snider
Senior Software Engineer
Intelligent Software Solutions, Inc.
[Description: Description: Description: cid:image001.png@01CA1F1F.CBC93990]
From: Andrea Aime [mailto:andrea.a...@geo-solutions.it]
Sent: Friday, March 18, 2016 6:51 AM
To: Robert Coup <robert.c...@koordinates.com>
Cc: geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] Request IDs
On Fri, Mar 18, 2016 at 12:53 PM, Robert Coup
<robert.c...@koordinates.com<mailto:robert.c...@koordinates.com>> wrote:
One small extra note, it could also be useful to have also have the request id
in the response header, so that
if I have a problematic request in the client, I can go and look for the id and
then grep the logs for just the log
lines pertaining to it.
Well, if it's generally useful I could simplify the approach a bit:
* Add a global config option with a header to look at for inbound requests
(ie. X-Request-ID or whatever). For Geoserver instances without a reverse proxy
generating UUIDs sitting in front, they would just create a UUID for each
request like precent.
* Always add the request ID to the logging/monitor/sql contexts (and pass
it through to WPS/etc as discussed below), and have the Dispatcher set it up
initially.
* Always return the request ID as a response header (either using the
configured header name, or defaulting to GeoServer-Request-ID).
Always returning a header would add 60 bytes (using the above name) to every
response... how do people feel about that?
I'm not particularly worried about it... just look at how many headers GWC sets
on returned tiles.
Personally I think OGC service responses are verbose enough that it'd be
unlikely to make any difference to users, and the ability to trace requests and
debug issues quickly and effectively massively trumps that overhead. But most
admins won't use it most of the time, so I'm interested in others views. We
could always make it disable-able if only a few admins might want to optimise
and are prepared to run with a custom applicationContext config.
Admins rarely touch app context, but are normally happy to play with system
variables. GeoServerExtensions.getProperty allows to pick a variable from env,
system, and servlet context, which allows a range of options.
Presumably changing the default behaviour and adding a new config setting would
need a GSIP?
Hum... it's unclear to me if a GSIP is needed for this, or not, since no
programming interface or user visible change is performed but... I guess it
would not hurt either?
Personally I'm happy with some conversation on the ml, let's hear what the
others think.
* Add it to the logging MDC context in the same custom callback
MDC... ? Ah:
https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/MDC.html
Yeah... I'm a little fuzzy on exactly which logging system GeoServer uses (I
don't spend enough time in Java), but the docs says it uses java.util.logging
but has log4j underneath (so MDC is available)? slf4j looks like it wraps MDC
for java.util.logging (http://www.slf4j.org/api/org/slf4j/MDC.html) and that
seems to be in the POMs too... so I think I should be able to get it working
somehow ¯\_(ツ)_/¯
slf4j is not really used, it's there because some libs we depend onto are using
it.
GeoServer by default uses a java logging to log4j bridge coming from GeoTools,
but there is a system var
one can set to just use java logging instead.
See:
https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/logging/LoggingInitializer.java
https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/logging/LoggingUtils.java
and:
https://github.com/geotools/geotools/tree/master/modules/library/metadata/src/main/java/org/geotools/util/logging
Sounds good, I hadn't thought about WPS. From my quick reading of the docs/code:
* &request=Execute will start processing, and creates an ExecutionID
* If the RequestID from the Execute request is attached to the background
processing via ThreadLocalTransfer & potentially via the Hazelcast clustering,
logs/etc can keep being associated with the initial Execute user request if
that's useful
* For Async requests any Dismiss/Status/Result requests require the
ExecutionID to be passed in. They'll each have their own RequestIDs as well.
* WPS ExecutionIDs should probably be put into the MDC/monitor/SQL/etc
contexts too if users want to track/log/use them for similar reasons.
Thinking further, it would also be good to pass request IDs to any upstream
cascaded WFS/WMS servers too, continuing the goal that a single end-user
request can be traced/followed as far as possible. Though I haven't looked at
how yet :)
Yes, that's something I've seen doing in service oriented architectures, so
that a single id is passed around across services.
Doing so might not be so easy, but have a look at
https://github.com/geotools/geotools/blob/master/modules/library/main/src/main/java/org/geotools/data/ows/HTTPClient.java
its implementations and how they are used by the WMS client, and... maybe by
the wfs client too (don't really know what the
wfs-ng store is doing internally, you'll have to check)
Cheers
Andrea
--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i
file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo
è consentito esclusivamente al destinatario del messaggio, per le finalità
indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne
il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di
procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro
sistema. Conservare il messaggio stesso, divulgarlo anche in parte,
distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse,
costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for the
attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act (Legislative
Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in
accord with its purpose, any disclosure, reproduction, copying, distribution,
or either dissemination, either whole or partial, is strictly forbidden except
previous formal approval of the named addressee(s). If you are not the intended
recipient, please contact immediately the sender by telephone, fax or e-mail
and delete the information in this message that has been received in error. The
sender does not give any warranty or accept liability as the content, accuracy
or completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of e-mail
transmission, viruses, etc.
-------------------------------------------------------
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
