Recently I found in the sp_Blitz output new finding 'Overall Events' in 'DBCC Events' findings group:
15278 DBCC events have taken place between Aug 8 2017 12:15AM and Aug 8 2017 8:17AM. This does not include CHECKDB and other usually benign DBCC events.
When I digged into this and checked the default trace, I found that every minute it records entries like this:
dbcc incrementinstance ("SQL Replication Distribution", "Dist:Delivered Cmds/sec", @agent_name, @new_delivered_commands)
dbcc setinstance ("SQL Replication Distribution", "Dist:Delivery Latency", @agent_name, @delivery_latency)
dbcc addinstance ("SQL Replication Logreader", @agent_name)
It's plainly visible this is replication related, but since these commands are undocumented I am not sure whether they should come up in the trace. However, basing purely on the output it just measures the amount of commands per seconds plus the latency. I think this is nothing harmful.
So if you could possibly check your servers where you run the replication and confirm if you have these entries and the frequency is more-less the same?
The separate question is if it's normal to see such commands (and I guess it is) in the default trace, perhaps it shouldn't be considered as a finding by sp_Blitz and it should be grouped with other harmless DBCC commands already excluded in sp_Blitz.
We use Sentry One to monitor SQL Server, but I don't think it's monitoring replication. I think it might be something internal. There are some default alerts defined when you deploy replication (SQL Agent -> Alerts, for example: Replication Warning: Transactional replication latency (Threshold: latency)) It is basing on SQL Server error log, but the entry in the error log has to be initially triggered by something.
I have opened an issue on Github to cover this.
