> 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. >> >> --- >> >> >>
