I assume you've seen https://github.com/FreeRADIUS/freeradius-server/tree/v3.1.x/doc/schemas/logs... which might be useful. Very interesting! If you'd like to, please drop me an email, I'd be happy exchange experiences / thoughts.
The State attribute should tie any challenges with the subsequent request, which might be helpful. Good point. The problem is that I don't see the State attribute in Access-Accepts anymore.
Include the Calling-Station-Id and User-Name as well? Then perhaps hash them to get a (most likely unique) hex string. (See e.g. acct_unique policy.) Sounds like this calls for some unlang wizardry but definitely feasible.
I would have thought you could generate a new Correlation attribute on first request, log it with the request, and then cache it with rlm_cache. Then pull it out each time you are about to log a request or reply and put it on the log. Then you should have a stable ID across all entries in your elasticsearch db. rlm_cache is a very good advice. Copying the attributes to tunneled requests with the session-state methods should be easy enough as well so that we get a consistent correlation.
You might be better to keep track of the request time in FreeRADIUS and then just log it with each log entry. rlm_cache probably needed as well - but examples of arithmetic are in sites-enabled/default preacct (FreeRADIUS-Acct-Session-Start-Time).
Doing both timing in FR as well as a Correlation attribute is probably the best option. Sounds sensible. I'll say what I can manage to do. Sounds like I've got some work ahead of me to get this to work.
Thanks for the hints, that's good advice. Cheers, Christian -- Dipl.-Math. Christian Strauf Clausthal University of Techn. E-Mail: strauf@rz.tu-clausthal.de Rechenzentrum Web: www.rz.tu-clausthal.de Erzstraße 51 Tel.: +49-5323-72-2086 Fax: -992086 D-38678 Clausthal-Zellerfeld