Skip to content
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

File log #2325

Closed
ginnavaram opened this issue Apr 3, 2017 · 11 comments · Fixed by #2437
Closed

File log #2325

ginnavaram opened this issue Apr 3, 2017 · 11 comments · Fixed by #2437
Labels
task/needs-investigation Requires investigation and reproduction before classifying it as a bug or not.

Comments

@ginnavaram
Copy link

I started using the file log plugin in kong. Is there a way to rotate the logs based on threshold (once it reaches 5mb or so) or rotate the log file daily?

@p0pr0ck5
Copy link
Contributor

p0pr0ck5 commented Apr 4, 2017

A simple logrotate config could handle this for you (http://www.linuxcommand.org/man_pages/logrotate8.html).

@cosmopetrich
Copy link

What's the correct method to signal to Kong that it should reopen the log file post-rotation?

Kong will continue to write to the same file until nginx is restarted or reloaded. A SIGUSR1 will cause nginx to reopen its own logs, but Kong will continue to write to the old one. The file-log plugin appears to only determine the file descriptor the first time it writes a log message.

@coopr coopr added area/plugins task/needs-investigation Requires investigation and reproduction before classifying it as a bug or not. labels Apr 6, 2017
@p0pr0ck5
Copy link
Contributor

@cosmopetrich currently there is support for Kong to close and re-open the FD. We are discussing the appropriate approaches here: in the meantime, you could use the copytruncate logrotate directive to avoid the stale descriptor problem.

@deepshrift
Copy link

@p0pr0ck5 HI. if we use copytruncate,there is a very small time slice between copying the file and truncating it, so some logging data might be lost. How to solve this problem?

@Tieske
Copy link
Member

Tieske commented Aug 1, 2017

@deepshrift by not using the file log plugin

It is not recommended to use this plugin in production, it would be better to use another logging plugin, for example syslog, in those cases. Due to system limitations this plugin uses blocking file i/o, which will hurt performance, and hence is an anti-pattern for Kong installations.

see https://getkong.org/plugins/file-log/

@satishmane
Copy link

satishmane commented Apr 8, 2019

@Tieske
Hi,
Issue with syslog plug-in is that syslog truncates messages. I tried using rsyslog, it improved message length, but still same problem of truncation. I found that this is due to message string length hard coded in alpine linux image libc. I tried increasing MaxMessageSize in rsyslog.conf, but no luck. Kong says this is syslog issue. And we can not fix alpine docker image issue. In short, logging in kong is an issue one way or another. Do you have any workaround/solution for syslog like logging or resolve syslog issue

@Tieske
Copy link
Member

Tieske commented Apr 8, 2019

@satishmane I wasn't aware of that limitation, have you tried the CentOS image?

@satishmane
Copy link

@Tieske
Yes tried centos image too. But same issue.

@Tieske
Copy link
Member

Tieske commented Apr 8, 2019

seems to me this is a syslog issue. There is nothing Kong can do to work around those limitations. You could try any of the other logging solutions, tcp/http based?

PS. What Kong version are you using?

@satishmane
Copy link

@Tieske
Kong version : 1.0.3
Other logging solutions introduce another moving part. Hence needed local logging option like syslog.

@Tieske
Copy link
Member

Tieske commented Apr 8, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
task/needs-investigation Requires investigation and reproduction before classifying it as a bug or not.
Projects
None yet
8 participants