-
Notifications
You must be signed in to change notification settings - Fork 325
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rsyslog request.log.gz problem #324
Comments
I've unfortunately seen the same problem on our servers, which makes this I haven't had a chance to figure where the issue lies, but I suspect it's somehow related to rsyslog and log rotation (the file starts out as valid gzip, but after log rotation kicks in, it seems to become corrupted). But I'm planning to look into this to try and make sure we can resolve it before the next v0.14 release. In the mean time, it should be possible to restore some of the missing data based on the nginx access logs (which shouldn't have this corruption problem). The nginx logs won't have all the normal detail (it's missing various timing information, and request/response headers), but it should give you the basic request analytics. However, restoring from the nginx logs will require some custom scripts to parse the nginx access log format and load it into elasticsearch. I have some scripts somewhere that I've used to do this previously that I'm happy to dig up and share. I'm actually needing to do a similar restore task for one of our API Umbrella instances, so hopefully I'll be tackling this sometime in the next week and I can share the scripts when I get to that task. |
Thanks @GUI, I'm gonna take a look too, and if I found the solution I'm gonna push it. |
@mafiu: I've added some scripts to restore missing analytics based on the nginx logs. Details on how to use the scripts (and caveats) are here: https://github.com/NREL/api-umbrella/tree/master/scripts/import_access_logs Hope that helps! More generally, I still do want to make sure we get the corrupt gzip files from rsyslog fixed for the next API Umbrella release. Having those log files would make restoring the analytics much easier and more complete in the event things go awry. I think the gzip corruption issue is a bug with rsyslog and log rotation, since some other people seem to be reporting similar issues with rsyslog here: rsyslog/rsyslog#933 |
See #324 This fixes the issue by sending the SIGHUP signal to rsyslog after rotation. In order to send the SIGHUP signal, we needed to disable the runtrap handling around rsyslog that was intercepting signals. However, I don't think runtrap is needed anymore, since I think the shutdown bug has since been fixed with rsyslog. Also turn on async writing for the rsyslog request.log.gz file and align the buffer, flush, and gzip settings with our nginx access.log output settings. Also update the logrotate scripts to account for the nginx access logs now being gzipped.
These corrupt files request.log.gz files should be fixed in v0.14.0. |
Dear @GUI,
Some day I had a problem with my instance of ES, so I looked at the backup of the request log sended to ES in
/opt/api-umbrella/var/log/rsyslog/requests.log.gz
But this file is unreadeable... or I don't know how to read it...
[api-02 rsyslog]$ file requests.log.gz
requests.log.gz: data
[api-02 rsyslog]$ gzip -d requests.log.gz
gzip: requests.log.gz: not in gzip format
I'm using API-Umbrella v0.13
Thanks
The text was updated successfully, but these errors were encountered: