One of the issue I have (and that was not explicit because, I did not thought about it until now, sorry), is that my sessionId is clearly indexed on the front logs (ie : got sessionId=xxxxxxxxx) whereas it is not on the back logs (the sessionId is appearing aggregated to an other id and is not clearly indexed - the format of the log is, let's say, "perfectible") Currently, I just a made a dashboard to "help" me thinking : 1/ Extraction of the sessionIds related the 400 errors (and their hour, minute, second, ...) index="front_index" sourcetype=access_combined "/url/of/my/service" http_code=400 | table timestamp, hour, minute, second, sessionId So the results is as follow : timestamp hour minute second sessionId 2020-06-19 18:21:53 18 21 53 sessionIdOfMySecondError 2020-06-19 18:10:45 18 10 45 sessionIdOfMyFirstError 2/ As I click on one of the line of my previous search, I get to extract and re-use some values to identify the back logs that I want. index="back_index" *$sessionId$* *$hour$:$minute$:$second$* | where errorCode!="" | table timestamp, errorCode As the errorCode I want is not always there and is not properly indexed (again - I had to extract it with a regex), I use the "where" clause to exclude the events where it is missing. So, if I am cliking on the first row of my first table : timestamp errorCode 2020-06-19 18:10:45 explicit_error_code Here is an example of the back log event I am interested in (there are some others with a different template, but, this the first one) : 2020-06-19|18:21:53|ACH|someId_sessionId|ERROR|my.domain.error.mapper.GenericExceptionMapper|ServiceException contextualErrorCode=xxxx, reponse will be ErrorCode=explicit_error_code1 This works fine, but it forces me to "blindly" investigate each front log hoping for some helpful back logs. So what I would like in the end would be as follows : timestamp sessionId errorCode 2020-06-19 18:21:53 sessionIdOfMySecondError explicit_error_code2 2020-06-19 18:10:45 sessionIdOfMyFirstError explicit_error_code1 The map command looked ideal to get to this kind of results (not speaking of performance at all which must be taken into account of course) whereas, using the "OR" clause with the stats command seemed to "just mix the events" (no matter the timestamp nor the sessionId) => it does not seem to permit to build the table I want. Don't get me wrong : I am not sure about that, maybe I am totally wrong 🙂 I thought about using : subsearch join But they don't seem to be meant for this "loopy" logic I am thinking of (which may not be the best way to look at it, but I am struggling thinking in a different manner right now) Thanks again. Hope I am not completely wrong about this (missing the point of your solutions :))
... View more