I need to trace every user activity, ideally I would like to keep records of events like
I saw from several old forum posts (like this one or this one)
that suggest writing his own prosody module (by hooking the events of the muc) or go trough the JICOFO logs (I would avoid the latter).
The posts are a bit old and I was wondering if meanwhile something has been made(I would prefer a REST integration, but I’m open to other options).
Did someone already approached this problem?
Writing a new module is the only solution? If this is really the only solution, could someone elaborate on how to do this with some starting tips (I’m a beginner with lua - ex. rest calls, serializing a table into a json, etc…)?
I would really avoid parsing the jicofo logs with a bash script: It seems like it’s not a solution easy to maintain (ex. we might need to parse a potentially very long file, not talk about file locks, permissions and stuff like that) and the results would not arrive in real time.
I already explained why I think it’s unmainteinable and a road that cannot be used. We need to have data in real time.
IMO using jicofo logs is better than Prosody as I think there is no way to get at the nicknames picked by users with a Prosody handler. If it’s not needed however, Prosody could be used.
doesn’t jicofo receive data from Prosody? Therefore whatever is available on on jicofo should be available on Prosody.
If there was some way to instruct jicofo to send the logs through REST or some other integration method that would be great
Then replacing nc by some custom app should need less than 250 LOC in a high level language and maybe 3 days of dev ?
I am talking of a SERIOUS real time integration with a communication protocol (rest, websockests, grpc, etc…) with an EXTERNAL system that is already in place and error handling. I don’t want to read a volatile file or the system logs. I don’t want to deal with quick solutions that will create more troubles than the one they are resolving (which seems the case)
The net.http lib (https://prosody.im/doc/developers/net/http) used for the POST calls is already doing non-blocking calls so doesn’t block the process. But prosody is still inherently single-threaded, so having lots of async calls in flight will still have an impact on performance. I have not benchmarked this though, so cannot comment on what constitutes “a lot” and how noticeable the impact would be.