[
https://issues.apache.org/jira/browse/NIP-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18017775#comment-18017775
]
Adam Taft commented on NIP-10:
------------------------------
In a perfect world, there wouldn't be any stack traces to begin with. So I
don't think the bloat of the bulletin message with the addition of the stack
trace outweighs the value of having the stack trace available outside of the
log. I have experienced many times (too many) where dataflow management teams
don't necessarily have the capability to find the main log to extract the
stacktrace.
Usually if one stacktrace occurs, it's possible that many will occur in short
order. So as a slight improvement, if bloat of the bulletin message size is
concerned, then maybe only allowing one stacktrace per some number of messages
or time period, reducing the number of messages carrying full traces. You'd
risk losing some trace information, but it would be a balance between none or
all.
> Add stackTrace to Bulletin
> --------------------------
>
> Key: NIP-10
> URL: https://issues.apache.org/jira/browse/NIP-10
> Project: NiFi Improvement Proposal
> Issue Type: Improvement
> Reporter: Pierre Villard
> Assignee: Pierre Villard
> Priority: Major
>
> As a NiFi user, it is not always easy to quickly access the logs. Bulletins
> are a good way to surface potential errors when data is being processed in
> the flow but in case this requires deeper debugging, the information
> currently provided in a bulletin is not always enough.
> In such a case the NiFi user may not have permissions or easy access to the
> logs of the NiFi instance and would need to get in touch with a NiFi admin
> able to retrieve the underlying log message for the bulletin and provide the
> full stack trace. This can make the overall troubleshooting process longer.
> It could be useful to add a stackTrace String to the Bulletin object in
> nifi-api and provide the option to expand a bulletin in the Bulletin Board
> view in order to see and easy copy in the clipboard the potential stack trace
> associated to the bulletin.
> We want to use a String instead of a Throwable to make sure we do not have
> serialisation issues across the NiFi nodes but we want to make we retain the
> proper format of the stacktrace for proper rendering in the UI.
> Additionally, it may be good to evaluate if we should specifically remove the
> value of this new field when being called via APIs that are not for the
> bulletin board. This may not be necessary though as we never retrieve a large
> number of bulletins anyway.
> Expected changes:
> * The API change would be to add a stackTrace String field to the Bulletin
> object in nifi-api
> * In the implementations of LogObserver, convert the throwable into the
> string representing the stack trace and add it to the bulletin
> * In the UI, improve the bulletin board to properly render the stack trace
--
This message was sent by Atlassian Jira
(v8.20.10#820010)