Devin,
Make sure you are compressing your logs when they roll by adding a
.gz. The logs will compress quite nicely and safe you considerable disk
space. As far as production goes, you want to maintaining enough log
history so that problem can be inventoried and resolved. In many cases the
default logger for NiFi is changed from INFO to WARN. This will also reduce
the amount of logging. The other thing you should be doing is winding logs
someplace other then where NiFi lives. If it should still fill that disk it
will have less of an impact on your NiFi application.
Matt
On Mar 25, 2016 6:52 PM, "Devin Fisher" <[email protected]>
wrote:
> I'm still early in the usage of Nifi at my company (no production usage
> yet). But in developing some custom processors and other components I've
> run both my dev machine and virtual machines out of disk space from verbose
> logs. In all of these cases they have been my fault (turn debug level on
> and left it running over the weekend and processor with a bug). But this
> has left wondering what are people's experiences with the logging and what
> are the best practice.
>
> From what I can tell Nifi uses logback (not much in the documentation
> about it). And the default configuration for the app log is
> a TimeBasedRollingPolicy that rolls the log every hour (or more often if
> needed) and keeps logs for the last 30 hours. Is this what most people are
> using in production? Any issues?
>
> I'm considering changing the configuration to a FixedWindowRollingPolicy.
> With reasonable large files (100 MB) and a reasonable number of them (15).
> I'm considering this because if there is something misbehaving I don't have
> to worry about it filling my disk space. Thoughts about this approach?
>
> Anyway, I'd love to hear what people are doing in production before I go
> that way.
>
> Devin
>
