Due to the stateless nature of the HTTP protocol, it makes no sense to find what users are actually executing a request in a given point in time. That would only get all users which are in the middle of a connect and disconnect stage. Depending on the HTTP version, other objects, in addition to the main request, could also be fetched using the same connection, such as images. This doesn't make any difference, though, so we can consider this as a page load.
Once a disconnection is executed, which would happen immediately after a page load, the link between the user and the server is gone. In order to workaround this, wrappers around this stateless approach have been created, for example, cookies and server-side sessions. They will give the impression that users are logged in between requests and avoid authentications between requests.
However, each request will have access to their own session. Getting information from other active sessions is a security risk. Usually PHP and web servers work together to manage sessions, usually configured as files stored in a given directory. Those files are usually cleaned by a Cron job (in *nix-based systems). Once the file is removed, the session is lost.
Rather than getting deeper into this it might be better to make some clarifications. The logout works pretty well to understand when a session is killed. The problem is that unless a user logs out, and as long as the cookie is set and the session is active (the operating system has not removed it yet), the user will be able to access the site without the need to actually log in. So monitoring logouts and logins make sense as session observers.
However, if you consider an "active user" as user that has logged in your site in the last 3 minutes, you will be expecting people to input user and password every 3 minutes in order to observe their logins, and that's not going to happen.
In short, if you want to keep track of active users just follow a keep-alive approach. Each time a user refreshes a page, just insert/update the record in the database with the current time. Then remove the ones with a Cron job, if you want that approach.
Extra tip 1: you can improve performance significantly avoiding updating the database in every request by playing with cookies or session information.
Extra tip 2: most likely you'll want to create a composite key on the update time column and then on the user id, in that order (although this might depend on the exact SQL queries you're running).
