feat: add message and event count metric

[itsoyou]

Expose message & event counts in synapse #3264

• synapse_messages_by_source: select COUNT(*) from events where type = 'm.room.message' or type = 'm.room.encrypted' and sender like '@%:tim-alpha.staging.famedly.de';, where the like query matches local events vs remote events.
• synapse_events_by_source: Same as the above but not filtered by type.
• synapse_encrypted_by_source: Same as the above, but only m.room.encrypted messages.
• each of those having a local and a remote label:

[nico-famedly]

I think we want message metrics at least every 5 minutes. Otherwise this will have too large jumps and not be that useful.

[jason-famedly]

Query plan looks like this on my system(6.25 million rows):

This might be scary later. There are no indexes on either sender or type. Perhaps Nico would have some idea what he would like here. It only runs every 5 minutes, and even a few seconds isn't that awful(Mine took just over 1 second, for reference)

[itsoyou]

Query plan looks like this on my system(6.25 million rows):

This might be scary later. There are no indexes on either sender or type. Perhaps Nico would have some idea what he would like here. It only runs every 5 minutes, and even a few seconds isn't that awful(Mine took just over 1 second, for reference)

Thank you Jason for checking this! A second does not sounds so good. I think if we time-range the metrics, it would show much better performance.
d.g. here there are already some related query exists, but with daily count. @nico-famedly is that okay if we have label for time-range like 24h, 7days, 30days? Otherwise, we should create indexes.

[nico-famedly]

I think we want totals, so that we can create a time series manually. Running it every 5 minutes is probably fine, but creating an index doesn't sound too terrible either, but likely will have to happen as a background job?

[itsoyou]

I think we want totals, so that we can create a time series manually. Running it every 5 minutes is probably fine, but creating an index doesn't sound too terrible either, but likely will have to happen as a background job?

If we have to update metric on every events, I would consider adding count logic, since the table is pretty big.(Probably nice to have a sync logic to check if the value is equal to DB.) Otherwise if it's not too time-critical, I like to fetch info every 5 minutes from DB. Is there better approach to do it other than background job?

[nico-famedly]

I think we want totals, so that we can create a time series manually. Running it every 5 minutes is probably fine, but creating an index doesn't sound too terrible either, but likely will have to happen as a background job?

If we have to update metric on every events, I would consider adding count logic, since the table is pretty big.(Probably nice to have a sync logic to check if the value is equal to DB.) Otherwise if it's not too time-critical, I like to fetch info every 5 minutes from DB. Is there better approach to do it other than background job?

Both approaches sound fine to me :)

[itsoyou]

closing with #146