These files will be helpful in debugging the stress test...
-rw-r----- 1 www-data www-data 433820 Sep 12 19:27 main.log
I'd like for the ores-admin members to have read access.
These files will be helpful in debugging the stress test...
-rw-r----- 1 www-data www-data 433820 Sep 12 19:27 main.log
I'd like for the ores-admin members to have read access.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| chmod uwsgi logs to 0644 | operations/puppet | production | +6 -5 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | akosiaris | T162039 Prepare to service applications from kubernetes | |||
| Resolved | akosiaris | T162041 Expand the infrastructure to codfw | |||
| Resolved | RobH | T161700 CODFW: (4) hardware access request for kubernetes | |||
| Resolved | RobH | T142578 codfw/eqiad:(9+9) hardware access request for ORES | |||
| Unknown Object (Task) | |||||
| Resolved | akosiaris | T165170 rack/setup/install ores2001-2009 | |||
| Resolved | None | T176324 Scoring platform team FY18 Q2 | |||
| Declined | None | T179501 Use external dsh group to list pooled ORES nodes | |||
| Resolved | akosiaris | T168073 Switch ORES to dedicated cluster | |||
| Resolved | Halfak | T185901 Preliminary deployment of ORES to new cluster | |||
| Resolved | akosiaris | T171851 Reimage ores* hosts with Debian Stretch | |||
| Resolved | awight | T169246 Stress/capacity test new ores* cluster | |||
| Resolved | None | T175736 Give ores admins read access to /srv/log/ores/main.log* |
I'd be happy to write the patch, if an Ops engineer wants to suggest the preferred way to give us access?
The preferred way would be if logs can be read using systemd's journalctl and in the admin module in the section for ores-admin, a line like this is added to sudo privileges:
'ALL = NOPASSWD: /bin/journalctl *'
Another way would be a specific sudo privileges line to tail -f /srv/log/ores/main.log specifically
I would suggest AGAINST giving access to all logs. We should have a tail-ores command that specifically tails the ores logs, like we do with other services.
Change 377794 had a related patch set uploaded (by Alexandros Kosiaris; owner: Alexandros Kosiaris):
[operations/puppet@production] chmod uwsgi logs to 0644
The above gerrit change should make the main.log files readable by everyone and should fix the issue while aligning with the rest of the files for the various applications without the need for weird tricks. Note that these logs also make it logstash at all levels so it should be easy to view them from there too. The celery logs are not yet though
@akosiaris Could you point me to the config that propagates those log messages to logstash? I was looking at error messages from yesterday that didn't appear in logstash, see T175653 for details.
Since there are variables there here's the resulting uwsgi config on a host for your convenience
log-encoder=format:local [${strftime:%%Y-%%m-%%dT%%H:%%M:%%S}] ${msgnl}
log-encoder=json:logstash {"@timestamp":"${strftime:%%Y-%%m-%%dT%%H:%%M:%%S}","type":"ores","logger_name":"uwsgi","host":"%h","level":"INFO","message":"${msg}"}
log-route=local .*
log-route=logstash .*
logformat=[pid: %(pid)] %(addr) (%(user)) {%(vars) vars in %(pktsize) bytes} [%(ctime)] %(method) %(uri) => generated %(rsize) bytes in %(msecs) msecs (%(proto) %(status)) %(headers) headers in %(hsize) bytes (%(switches) switches on core %(core)) user agent "%(uagent)"
logger=local file:/srv/log/ores/main.log
logger=logstash socket:logstash1001.eqiad.wmnet:11514@akosiaris Thanks, I see the messages in logstash now! I'll tweak the ORES dashboard to include them.
Correction to my last comment—the logs are already in the ORES dashboard of logstash.
Change 377794 abandoned by Alexandros Kosiaris:
chmod uwsgi logs to 0644
Reason:
Funnily enough, this won't work. logfile-chmod, logfile-chown have nothing to do with the logfile plugin but rather with the --log parameters. Abandoning