Looks like mediawiki's logstash formatter sometimes emits logstash_formatter_key_conflict field, specifically popular entries are for ip fields (i.e. goodpass/badpass channels) or type for LoginNotify channel. See also https://logstash.wikimedia.org/goto/52ffc2e6294ec93b6f7e73ecabab5117
|Resolved||Reedy||T245280 logstash_formatter_key_conflict in mediawiki logs|
|Resolved||EBernhardson||T245303 CirrusSearch logging logs with reserved parameter message|
|Resolved||Reedy||T245305 Termbox uses reserved log parameter 'message'|
|Resolved||Reedy||T245306 Math logging uses reserved word 'url'|
This should be in a much better place now (the mediawiki-config patch fixed most).. I've fixed (or created a subtask) most of the ones showing in the logs, and a few others pre-emptively too
I don't see any point backporting MW core patches, so .20 should clear up most of the other ones
Also filed T245289 to pre-emptively prevent some of these in the future
@Reedy Can you confirm that this is only for making Logstash and code use the same key and not to resolve a problem with the key conflict as the task originally described? I ask because ensuring such conflicts don't ocurr should imho be core's responsibility first, and was fixed there (allegedly) in the LogststashFormatter class which rewrites these automatically to avoid that conflict indeed.
It's still nice to rename them in the code as well for consistency between them, but if a problem came up again, that would be good to know so we can also figure out why the rewrite stopped working.
EDIT: I thought this was an old task, but it's from yesterday. I guess that rules that out...
T245303: CirrusSearch logging logs with reserved parameter message is probably fixed now. Backported to .22... So after tomorrows train, the https://logstash.wikimedia.org/goto/52ffc2e6294ec93b6f7e73ecabab5117 log should go to zero... :)
ip is a bit annoying. In the other cases there are two genuinely different things logged. For IP, the processor and the context typically intend to provide the same data, except we don't do any XFF lookup in the processor for performance reasons, so that IP ends up being utterly useless. Maybe it would make more sense to just remove it?