据我了解,在使用NiFi构建一些数据库提取PoC之后,整个数据流都作为流文件流运行。并且在任何特定时间,执行控制可以同时在一个或多个处理器上。
所以我真的很困惑如何调试任何失败的复杂数据流。
当我们使用生产用例时,它会变得比这复杂得多。所以我有几个问题。
如何知道数据流的状态。如果说有10个分支流文件中有4个在GenerateTableFetch
上由于数据库池错误而失败,那么我如何知道哪些失败了,以及如何快速重播这些文件而无需进行数据来源和一个接一个的处理。
是否有一种方法可以通过查看数据流来知道哪个处理器在哪个流文件中失败。
对于使用NiFi调试数据流,我还有更多的疑问/困惑,如果有人可以请我指向一些文档或分享最佳实践,那将会很有帮助。
谢谢。
答案 0 :(得分:3)
1-如何知道数据流的状态。如果说10 4 分叉流文件在GenerateTableFetch用于数据库池时失败 错误,我如何知道哪些失败,以及如何快速重播它们 无需进行数据治理并一一对应。
您可以通过将类型为失败的关系或任何其他类型的关系进行管理,具体取决于要发送到进程组以处理错误的处理器的类型。
因此,就像布莱恩(Bryan)提到的那样,除非您不在乎,否则他们不希望它们自动终止。
2-是否有一种方法可以通过查看数据流来了解 处理器出现故障的流文件。
是的-您必须设置“公告级别”以更改日志级别
如何管理失败的NiFi流量?
好吧,您需要与BuletinBoard成为最好的朋友,请参见此处SiteToSiteStatusReportingTask ,也可以将 InvokeHttp 与原生的 NiFI Rest Api 和 GET 调用 http://nifi-server:port/nifi-api/flow/bulletin-board ,这将响应并解析一个详细的json对象,然后将其推送到 PutSlack / PutEmail / PutSNS 任何错误。
同样理想的是让 Shared Process Group 来处理任何传入的错误流文件,该PG将使用规则和路由构建,以应用于您的NiFi服务器中的所有数据流逻辑。拥有特定于PG的属性至关重要,该属性将随您的所有流一起携带,并将在数据流的整个过程中使用。
例如:
进程组“演示” 具有名为 Set PG Attributes 的处理器,该处理器设置 PGName 服装 PGType attibute, FailEmailTitle 属性等。如果我的流程在任何时候失败,则失败关系将基于 Set PG Attributes 处理器
中设置的Attributes之一的值来路由我失败的流程其他选项
如果您认为buletin仅能保留5分钟是一个问题,则可以使用 nifi-app.log ,可以将其设置为由 / opt / nifi / conf / logback.xml 文件
<logger name="org.apache.nifi" level="ERROR"/>
<logger name="org.apache.nifi.processors" level="DEBUG"/>
<logger name="org.apache.nifi.processors.standard.LogAttribute" level="ERROR"/>
<logger name="org.apache.nifi.processors.standard.LogMessage" level="ERROR"/>
<logger name="org.apache.nifi.controller.repository.StandardProcessSession" level="ERROR" />
因此,您可以使用tailFile处理器来查看您的本地日志文件,并获取错误信息或您认为有用的信息,并从中获得一些意义。
答案 1 :(得分:2)
每个处理器都应具有一个或多个故障关系。由您决定如何处理故障...在某些情况下,您可以将故障关系路由回同一处理器以继续重试,在其他情况下,您可以将其路由至PutFile处理器并写出到本地磁盘以检查内容,也可以将其路由到PutEmail处理器以向某人发送电子邮件。
您不想做的是自动终止故障关系,因为这实际上是在说您要忽略它。