Member since
04-29-2021
11
Posts
4
Kudos Received
2
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
300 | 08-07-2024 03:30 AM | |
1209 | 06-20-2023 09:03 AM |
08-07-2024
03:30 AM
1 Kudo
Just figured it out by using the service Raw Message Field 🙂
... View more
09-16-2023
01:38 PM
Are you or have you considered leveraging ES bulk API? Bulk API | Elasticsearch Guide [8.9] | Elastic
... View more
06-20-2023
09:03 AM
2 Kudos
No worries, I've found a fix. Setting the jsonwriter to line by line instead of array. 🙂
... View more
05-16-2022
03:39 PM
@robnew , It would be easier if you could provide an example of what you're trying to explain. Cheers, André
... View more
07-28-2021
10:07 AM
2 Kudos
@robnew In addition to what @janis-ax suggested about setting bulletin level to none on the processor to stop WARN and ERROR level log output from that processor from being sent to the bulletin board, you could also suppress the logging of this processor class via the NiFi logback.xml file. Changing the bulletin level on a processor does not disable logging being produced by your processor code. That logging will still find it way in to the NiFi logs via the logback.xml even with bulletin level set to known. So though processor you can stop the bulletins and through NiFi's logback.xml you have additional options to send logging produced by your processor class to its own appender or one of the existing appenders already defined in that file. If you found the feedback provided to your query helped, please take a moment to login and click "Accept" on all solutions that helped. Thank you, Matt
... View more
05-07-2021
06:28 AM
Thanks, I tried something just like this yesterday, and it would work, but these logs don't have a file extension like what would be needed, (.gz) but I think I have an issue somewhere else, so will carry on trying to fix the overall issue.
... View more