We need to move Citoid to the new logging pipeline. The config should be updated similar to https://gerrit.wikimedia.org/r/#/c/mediawiki/services/change-propagation/deploy/+/500813 and newest node dependencies should be used (newest version of service-runner.
|Open||None||T227080 Deprecate all non-Kafka logstash inputs|
|Invalid||None||T225122 Migrate services using deprecated Gelf logstash input to Kafka enabled logging pipeline|
|Open||None||T225125 Migrate Elasticsearch from deprecated Gelf logstash input to rsyslog Kafka logging pipeline|
|Open||Pchelolo||T211125 Move service-runner to new logging infrastructure|
|Resolved||Mvolz||T219919 Move citoid logging to new logging pipeline|
|Open||None||T239459 service-runner apps running on kubernetes emit logs with log level 50|
Reminder/ping as we (SRE Observability) would like to deprecate all non-kafka inputs by end of Q4 FY19/20. If the service is moving (or has moved) to k8s then what's left to do is disable gelf log output and keep on stdout/stderr. If the service isn't moving to k8s then we'll also need to perform puppet-level changes. Thanks!
The patch above doesn't change anything in production. In general, having 'config.prod.yaml' in citoid source repo is misleading - that config is not what is used in production, and AFAIK that one is not used anywhere. I think it should be removed completely.
Citoid is running in k8s, so the logs are delivered automatically. It only needs to be logging to stdout. Change should be made to deployment-charts repo.
There are some things in config.prod.yaml that aren't in its chart in deployment-prep (i.e. the template to talk to mw-api) - is it inheriting some things from there at present? Would this have to be moved from citoid to deployment-prep then?
I think that's waiting on https://gerrit.wikimedia.org/r/c/operations/deployment-charts/+/594492 - which from the citoid standpoint is ready to merge, but is now quite stale. I don't know about eventgate and eventstreams.
But yeah if you want to do a pr to switch, as long as we pass the named-levels config in it, that's fine with me!