You got it. NIFI-634 and NIFI-635 created, as per output from this discussion. Comments welcome.
On Tue, May 26, 2015 at 3:32 PM, Joe Witt <[email protected]> wrote: > > it would likely make sense as well to provide the tooling to enable > "grepping" of the provenance event logs, so that unix style commands can be > piped together in the same way you'd do with plain text logs > > -- That would make for a good JIRA. > > > On Tue, May 26, 2015 at 3:25 PM, Adam Taft <[email protected]> wrote: > > Yes, agreed. Should have included the caveat, "this is a developer's > point > > of view." But my point of view is definitely not at the expense of > > "appreciating" the operations side as well. Your point that the > provenance > > tooling mitigates the need for verbose logging of individual flowfiles is > > spot on. Before the provenance tracking, logging the history a flowfile > > (via its uuid) across the entire flow was critical for both developers > and > > especially operations. Now, not so much. > > > > My comments were definitely made in the context of having the provenance > > repository to track the life of a flowfile event. Having the provenance > > event database clearly shifts the utility of the log files way over to > the > > developer side and less the operations side. Perhaps identifying what > > useful operations-based logging still remains would be a good thing. > > > > And since we're talking about provenance events, it would likely make > sense > > as well to provide the tooling to enable "grepping" of the provenance > event > > logs, so that unix style commands can be piped together in the same way > > you'd do with plain text logs. Perhaps a command line provenance client > > would be useful to the operations toolkit and would further reduce the > > (ab)use of the log files? > > > > Adam > > > > > > > > On Tue, May 26, 2015 at 3:12 PM, Joe Witt <[email protected]> wrote: > > > >> It is important to keep in mind the logs have served two worlds: > >> 1) The needs of a developer who wants to know when their stuff broke > >> and needs context to figure out why > >> 2) The needs of an operations person who does at times need the > >> minutiae of starts/stops/statuses and how objects flowed through the > >> system or what given processors did even when it isn't error or warn > >> worthy. > >> > >> I believe the comments reflect a developer centric view at the expense > >> of an appreciation for what operations folks have expressed needs for. > >> Just as the developer doesn't care about all the items mentioned the > >> operations person doesn't want those details drowned out by endless > >> streams of stack traces. Having said this... Our usage of the logs > >> and their value have diminished extensively thanks to the rise in > >> capability and value of the provenance functions. The entire notion > >> of logging at this point could be reviewed. > >> > >> On Tue, May 26, 2015 at 2:58 PM, Adam Taft <[email protected]> wrote: > >> > Sorry in advance for not cross posting this on github, but mine is > more a > >> > discussion oriented comment, not feedback on the pull request. > >> > > >> > Just to play devil's advocate a little... I have found the default > NiFi > >> > logging configuration to be almost always logging the wrong things. I > >> most > >> > definitely always want stack traces to be logged, because it's > sometimes > >> > very hard to recreate the state by which the stacktrace was thrown. > And > >> > it's a pain to have to change the logging level (even at runtime) > just to > >> > hope that the stacktrace happens again. > >> > > >> > Whereas I almost never want all the existing framework INFO messages > >> > logged. I don't care anything about how many wali objects were > garbage > >> > collected, what the current state of each processor is, or if a > heartbeat > >> > was sent or received from a cluster configuration. The things that > one > >> > must ignore when grepping a log often hinders the ability of finding > the > >> > thing you are looking for. > >> > > >> > A stacktrace, by definition, is more than a DEBUG level event. It is > at > >> > minimum a WARN if not ERROR condition in almost all standard cases. > And > >> > you definitely can't argue that infrequent stack traces are going to > >> bloat > >> > the log files anymore than the exist default logging configuration, > which > >> > is already very verbose. > >> > > >> > In short: I want to know when things go wrong, not when they go > right. > >> > > >> > If there's anything that might be done to help with stracktrace > >> verbosity, > >> > it would be suppress the stacktrace if it was seen x number of times > in > >> the > >> > same period. Thus, the first stacktrace would be logged, but all > similar > >> > stacks would be suppressed/minimized. This strategy is used in a few > >> > logging implementations (unsure if logback has direct support for > this or > >> > not). > >> > > >> > Hopefully, this discussion could lead to a more balanced default > logback > >> > configuration, one with more signal and less noise. > >> > > >> > Recommend: > >> > - always log stacktraces > >> > - change default org.apache.nifi.* to WARN level > >> > > >> > > >> > Adam > >> > > >> > > >> > > >> > > >> > > >> > On Tue, May 26, 2015 at 11:14 AM, joewitt <[email protected]> wrote: > >> > > >> >> Github user joewitt commented on the pull request: > >> >> > >> >> > >> >> > https://github.com/apache/incubator-nifi/pull/59#issuecomment-105560569 > >> >> > >> >> Brian, > >> >> > >> >> The issue with this proposal is that it takes away the > >> administrators > >> >> ability to control whether stack traces are provided or not. The > >> reason we > >> >> used 'isDebugEnabled' was because that was the use case in which the > >> stack > >> >> trace was necessary (because they were debugging). Given that you > can > >> >> edit logback config on the fly this seems like a reasonable approach. > >> But > >> >> taking away their ability to control this as the effect of this > proposal > >> >> means they're getting the stack traces whether they want them or not. > >> This > >> >> can cause very excessive and noisy output in the logs. > >> >> > >> >> Do you have an alternative proposal for how we can retain the > >> >> flexibility of letting the administrator toggle the stack traces? > >> >> > >> >> Thanks > >> >> Joe > >> >> > >> >> > >> >> --- > >> >> If your project is set up for it, you can reply to this email and > have > >> your > >> >> reply appear on GitHub as well. If your project does not have this > >> feature > >> >> enabled and wishes so, or if the feature is enabled but not working, > >> please > >> >> contact infrastructure at [email protected] or file a JIRA > >> ticket > >> >> with INFRA. > >> >> --- > >> >> > >> >
