Troubleshooting in Fuusion can mean many things, as with any other applications. It can mean you are having an issue standing up a virtual machine or container, it might mean a particular processor is not connecting to a database or is not passing the FlowFile to the next as it should. In this section, we will be outlining some of the ways NiFi provides to determine what went wrong, and where, to ensure a successful delivery.
When troubleshooting a Fuusion flow, it is important to focus on verifying each processor is performing as expected. This means you need to break down the flow into smaller segments to isolate and resolve the reasons causing the DataFlow to fail. Fuusion Architect provides tools and resources to assist you in your debugging effort. These include: ·
- NiFi Logs contains information regarding the NiFi App log, NiFi User Log as well as the NiFi Bootstrap log. These logs provide insight into the activities of the Apache NiFi, user events, and details pertaining to the actual launch and execution of the Apache NiFi.
- Monitoring Fuusion provides insight to the specific indicators provided on the Fuusion Architect Status Bar. This includes how many active threads there are, the queued data, number of processors running/stopped along with processors that need attention. This document also provides directions on Component Level Monitoring as well.
- Monitoring Using Reporting Tasks shows how to add a specific reporting task on the “Global” level of the Fuusion Architect to monitor specific resources like disk and memory utilization. This also provides insight into “Site to Site” reporting tasks that are useful when working with multiple cluster instances of Fuusion.
- Troubleshooting a Flow documents the recommended best practices when building or troubleshooting an existing Fuusion DataFlow. It shows you how to walk through each of the processors and ensure the data is flowing as expected.