Class RequestLogger

java.lang.Object
org.frontcache.reqlog.RequestLogger
public class RequestLogger extends Object
Log requests to file (slf4j) for statistics and further analysis REQUEST LOGGING FORMAT 1 - true 0 - false cacheable_flag - true/1 if request is run through FrontCache engine (e.g. GET method, text data). false/0 - otherwise (request forwarded to origin) dynamic_flag{1|0} - true if origin has been requested. false/0 - otherwise (it's cacheable invalid input: '&' cached). log-timestamp request-id domain http-method is-fallback-error{success|error} request-type {toplevel|include|include-async} is-cacheable{cacheable|direct} is-cached{dynamic|from-cache|dynamic-soft} runtime-millis datalength-bytes url client-IP frontcache-ID client-type{bot|guest} client-type-rule user-agent EXAMPLE 2016-06-03T15:06:35,092-0600 1649b11f-8acf-4718-8e0b-abdcf7356212 example.com GET success toplevel cacheable from-cache 0 50874 "http://myfc.example.com:8080/en/coin_definition-1_Thaler-Silver-Kingdom_of_Prussia_(1701_1918)-c_sK.GJAIx4AAAEvnTTi7NnT.htm" 0:0:0:0:0:0:0:1 front-cache-local-1 guest 2016-06-03T15:06:35,100-0600 1649b11f-8acf-4718-8e0b-abdcf7356212 example.com GET success include cacheable from-cache 0 1581 "http://myfc.example.com:8080/fc/include-footer.htm?locale=en" 127.0.0.1 front-cache-local-1 guest 2016-06-03T15:06:35,105-0600 1649b11f-8acf-4718-8e0b-abdcf7356212 example.com GET success include-async cacheable from-cache 0 1411 "http://myfc.example.com:8080/fc/external-ads.htm?locale=" 127.0.0.1 front-cache-local-1 guest 2016-06-03T15:06:35,558-0600 e67a3f57-07f1-4fdb-91e1-e33313ba4185 example.com GET success toplevel direct dynamic 5 -1 "http://myfc.example.com:8080/follower?eid=c_sK.GJAIx4AAAEvnTTi7NnTinvalid input: '&activity'=COIN_GROUP_UPDATEinvalid input: '&cmd'=check" 0:0:0:0:0:0:0:1 front-cache-local-1 guest 2016-06-03T15:06:35,565-0600 66223049-3269-4de2-8d0e-a467b83a8390 example.com GET success toplevel cacheable dynamic 12 1676 "http://myfc.example.com:8080/fc/include-header.htm?view=desktopinvalid input: '&locale'=en" 0:0:0:0:0:0:0:1 front-cache-local-1 guest 2016-06-03T15:06:35,578-0600 cac3e17f-2084-4f18-b4f7-cb7ae6ee8a37 example.com GET success toplevel direct dynamic 2 -1 "http://myfc.example.com:8080/uinfo" 0:0:0:0:0:0:0:1 front-cache-local-1 guest 2016-06-03T15:06:35,741-0600 55ba8287-cedd-43b6-ae47-357292664cb3 example.com GET success toplevel cacheable dynamic 4 9662 "http://myfc.example.com:8080/favicon.ico" 0:0:0:0:0:0:0:1 front-cache-local-1 bot The examples above predate the user-agent and client-type-rule columns (and the quotes around the client IP); a current line ends with the client type, the conf/bots.conf rule that decided it, and the evidence: 2026-09-21T09:14:02,118-0600 55ba8287-cedd-43b6-ae47-357292664cb3 example.com GET success toplevel cacheable from-cache 0 50874 "https://www.example.com/index.htm" "203.0.113.7" front-cache-local-1 bot "bingbot" "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)" client-type-rule was INSERTED, not appended, and it is the only column ever to have been: it is unreadable apart from the client type it explains, so the two are kept side by side and the user-agent column moved right by one in 2.10.0. Every column before the client type is where it always was, and an ELK pipeline reading from the left keeps working - but the request log is parsed by position outside this jar (2.7.0 pins the layout), so a NEXT column goes on the END unless there is as strong a reason as this one.

  • Method Details

    • logGuardedRequest

      public static void logGuardedRequest(String url, String reason, int status, String disposition, RequestContext context)
      Logs a request a guard rule acted on before it touched cache or origin - rejected (e.g. a 400 for a malformed query), redirected (e.g. a scanner hitting the node by IP), or matched by a dry-run rule that only observed it. Written to the dedicated failed-requests log with the GUARD rule name as the reason and the sent HTTP status as the last two columns - NOT to error.log, so a high-volume bad-crawler flood stays filterable without drowning real errors. (A second rule name sits earlier in the line, beside the client type - the bots.conf one behind it; see clientTypeRule(RequestContext). A guard rule matching on client-type: is exactly where that matters.) The trailing status column is written for guard actions only; the fallback lines that logRequest(String, boolean, boolean, long, long, RequestContext) adds to the same file end at the reason (the response there is a normal - usually 200 - fallback response, whose status this logger does not read: includes are logged off the request thread, where HttpServletResponse is not safe to touch).
      Parameters:
      url - request URL (host + URI + query)
      reason - guard rule name, e.g. "bad-request" / "ip-access"
      status - HTTP status sent to the client (0 for dry-run, where nothing was sent)
      disposition - what happened: "rejected" | "redirected" | "dry-run" - written to the is_cached column, which is what the ELK pipeline buckets on

    • logRequest

      public static void logRequest(String url, boolean isCacheable, boolean isCached, long runtimeMillis, long lengthBytes, RequestContext context)
      Parameters:
      url - - request URL
      isCacheable - - true if request is run through FrontCache engine (e.g. GET method, text data). false - otherwise (request forwarded to origin)
      isCached - - true if origin has been cached. false/0 - otherwise (origin is called).
      runtimeMillis - - runtime is milliseconds
      lengthBytes - - content length in bytes.

    • logRequestToHeader

      public static void logRequestToHeader(String url, String requestType, boolean isCached, boolean softRefresh, long runtimeMillis, long lengthBytes, RequestContext context, String includeLevel)
      Parameters:
      url -
      requestType -
      isCached -
      softRefresh -
      runtimeMillis -
      lengthBytes -
      context -
      includeLevel -
      dummy -