I'm not sure what exactly you mean by the point "history of the usage of different WebSockets", but I have a feeling that you are not intending to inspect the packets exchanged via websockets, but rather the "transaction content" between chains. This is an entirely different thing, and if this is the case, I would forget about the websocket aspect altogether - that is all about networking and doesn't help answer your question.
This answer is focused on my assumption about it not being about websocket package content - which could be wrong of course.
What you are really looking for are a subset of transactions that are being executed on a parachain - perhaps not the full set of transactions.
That subset would be all transactions coming from and going to other parachains, possibly via the relaychain and having some implication for storage on the source and target parachains.
Bear in mind that a transaction has three components:
- the content of the transaction (transactions also known as extrinsics)
- if the processing produces a successful outcome for the entirety of the transaction (if not then of course there are error messages and events to collect)
- the state changes stored in the blockchain if the transaction was successful
And this should really relate to the following endpoints, which you can inspect as follows (I use Polkadot as an example):
Polkadot Chain State (storage)
Downward messaging protocol - dmp
Horizontal Messaging Protocol - hrmp
This is also available as an extrinsic which you can visit from PDJS Apps
Upward Messaging Protocol - ump
Cross Chain Messaging Protocol - xcmPallet
Also available as an extrinsic - and you can see the various endpoints by selecting the second menu in PDJS Apps
From the perspective of a parachain, I will use Statemint as the example for storage endpoints, which for a parachain are the same for extrinsic endpoints. (i.e. they are from the same pallets.)
Downward Message Protocol Queue - dmpQueue
I mentioned Events and Errors. These are issues at the time of the transaction, and are commonly available either at the moment they are issued, or by inspecting the specific block that the transaction was executed in (failed or not).
The last point is about history. Whilst you can of course run a node yourself (you will need to run both the relay chain and all parachain nodes you want to inspect) bear in mind that the history would better be stored in a dedicated database for performance reasons, and because eventually nodes that are not full archive nodes will be pruned.
Storing history also has another benefit in that you do not have to be constantly online to monitor the responses(Events and errors) from transaction, but can parse the contents of blocks whenever convenient to catch up.