For certain type of anticipated frequent system messages, the log lines will add meaningless noise for all services on all pods. E.g. frequent periodic broadcast of the current queue sizes, as can be done by MatsBrokerMonitor.
Suggested name of traceProperty: "mats.SuppressLogging"
Use a "last 15 minutes, we suppressed xx loglines of this type".
The value of this traceProperty should be something "type-unique", to base this "last 15 minutes, xx lines suppressed"-evaluation on.
The "last 15 minutes" should be done via a separate thread, so that if there is only 1 logline ever, it should not be forgotten (a small security aspect).
Security: An endpoint should have to opt in to partake in this suppression. Otherwise, if you ever got an adversary onto your network, he could send messages, set this traceproperty, and effectively have pre-erased his logs. The "log number of suppressed log lines" could possibly have given a hint that something was afoot, but it would be way harder. Making suppression dependent on the targeted endpoint having agreed to suppression pretty much eliminates this problem, assuming that such endpoints aren't dangerous in a business/security sense.
For certain type of anticipated frequent system messages, the log lines will add meaningless noise for all services on all pods. E.g. frequent periodic broadcast of the current queue sizes, as can be done by MatsBrokerMonitor.
Suggested name of traceProperty: "mats.SuppressLogging"
Use a "last 15 minutes, we suppressed xx loglines of this type". The value of this traceProperty should be something "type-unique", to base this "last 15 minutes, xx lines suppressed"-evaluation on. The "last 15 minutes" should be done via a separate thread, so that if there is only 1 logline ever, it should not be forgotten (a small security aspect).
Security: An endpoint should have to opt in to partake in this suppression. Otherwise, if you ever got an adversary onto your network, he could send messages, set this traceproperty, and effectively have pre-erased his logs. The "log number of suppressed log lines" could possibly have given a hint that something was afoot, but it would be way harder. Making suppression dependent on the targeted endpoint having agreed to suppression pretty much eliminates this problem, assuming that such endpoints aren't dangerous in a business/security sense.