List the active users using login and logged out events

Elastic Stack Elasticsearch
1

I want to list the number of active users in our web application using elastic search.
Right now we are creating new documents whenever on login and logout event. using this document i want to derive number of active users in system currently. How this can be achieved using Kibana and elastic search.

2

Do you need to pair these login/logout records for each user or is it adequate to simply sum the global number of login events and the global number of logout events and subtract the 2?

3

I need to pair them as I need to list down the username along with the count.

4

Do you mean the final results need a list of usernames who are currently active or is this pairing just required to help calculate "current number of active users" given some data quality issues ( > 1 logout recorded per user login, logouts missing logins etc)

5

Mark, right now i create separate documents for Login and Logout. Both document has session id field which i am using to find the elaspsed time of that particular session. Now i want to query elastic search which should give the number of users are currently logged in and their username (available as a field in both document). The count can be derived by number of login documents subtract number of logged out documents. But how do i fetch the username users currently logged in? So i have to pair login and logout event based on sessionid, and list down the login documents where it could not find corresponding logout event?

My approach may not be correct. Is there any other way or alternate solution to achieve this?

6

I can think of several:

  1. Aggs solution - terms agg to group by session ID and sub aggs to gather related login/out events
  2. Stream solution - use scroll api sorted on session ID
  3. Active users index - create doc with session ID on login, delete on logout
  4. Entity-centric index to track active sessions, durations and more.

Solution 1 is not scalable with large numbers of users and is needlessly bogged-down with historical inactive sessions.
Solution 2 is scalable but slow and requires custom querying code
Solution 3 requires custom indexing code but is easy to query
Solution 4 requires custom scripts (examples available) but offers greater potential insights into sessions.

7

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.