Well, there are plenty of options. And I do not know what is best for you. But I will give them here with some pros and cons, and you can come to your own conclusions, taking into account your requirements.
The simplest answer is to put it in storage. Both Azure SQL and the Azure base table or blog storage options are for you. One issue that needs to be addressed is performance in the face of large-scale concurrency, but I also urge you to think about the correctness. You really want something that supports atomic increment in order to convey this problem to IMO.
Another storage-oriented option would be a highly available virtual machine. You can deploy your own virtual machine to Azure, return the data disk to Azure Drives, and then use something on top of the OS for this (database server, an application that directly uses the file system). It would be more like what you would do at home, but it would have some pretty bad compromises ... your whole cloud now depends on the availability of this virtual machine, the cost is what you need to think about, the scalability of the solution, and so on . Splunk can also be considered if you look at virtual machines.
As mentioned earlier by an earlier commenter, you can compute log data. But it probably won't be super in real time.
A service tire is another consideration. You can pump messages through SB for these events and have a consumer who reads them and emits a "resume". There are several design options to consider if you look at this. The SB stack is well documented. Another interesting element of SB is that you could adjust 100% correctness for performance / scale / cost. This can be a worthy compromise for you depending on your goals.
Azure also provides queues that may be appropriate. I agree, I think SB is probably a better fit, but it's worth a look at both if you go this route.
Sorry, I don't have a silver bullet, but I hope this helps.