@hckorkmaz01  @vafs provided a couple excellent options already. As a third option, you could utilize the SiteToSiteStatusReportingTask.  You can configure this NiFi reporting task to send metrics for only connections and you can add a regex to limited the number of connections returned (this requires renaming the desired connections so you have more granular control with the regex).  This Reporting task can be configured to send to a remote input port on on the same NiFi.   This Reporting task will execute the query on each host in your NiFi Cluster and send results to the the desired Site-To-Site remote input port.   So in a three node NiFi cluster three FlowFiles will be produced and sent with Json content for connection(s) you filtered on.   This way you can see what is queued per node.  Limitations to monitoring connections in this way exist.  Keep in mind that you are grabbing a snapshot at one specific moment in time.  So if the downstream component of this monitored connection is running, the connection stat would have likely changed by the time you got the last status details.   Now if you are using this to monitor flow dead-ends where you don't expect FlowFiles to ever accumulate, that is perhaps a valid use case. Example json output placed in FlowFile: [ { "statusId" : "27b01368-8280-4e5e-ac22-0e749c46fe17", "timestampMillis" : 1771336855410, "timestamp" : "2026-02-17T14:00:55.410Z", "actorHostname" : "nifi-node-1", "componentType" : "Connection", "componentName" : "Monitored-success", "parentId" : "603017c1-0197-1000-0000-000013171e7c", "parentName" : "test", "parentPath" : "NiFi Flow / test", "platform" : "nifi", "application" : "NiFi Flow", "componentId" : "508a2293-019a-1000-ffff-fffff15dc582", "sourceId" : "5089d4ab-019a-1000-ffff-ffff9b682ab3", "sourceName" : "UpdateAttribute", "destinationId" : "4dc23b89-25b0-1eff-b974-6fe5425c283f", "destinationName" : "UpdateAttribute", "maxQueuedBytes" : 0, "maxQueuedCount" : 0, "queuedBytes" : 30720, "queuedCount" : 30, "inputBytes" : 0, "inputCount" : 0, "outputBytes" : 0, "outputCount" : 0, "backPressureBytesThreshold" : 1073741824, "backPressureObjectThreshold" : 10000, "backPressureDataSizeThreshold" : "1 GB", "isBackPressureEnabled" : "false" } ]   IMPORTANT NOTE: I'd also like to point out that Apache NiFi 1.18 was released back in 2021 and newer releases have addressed many bugs and CVEs.  I strongly encourage you to transition to a newer version of Apache NiFi.  If you aren't ready to migrate to the newer Apache NiFi 2.x major release versions, you can still easily upgrade to last Apache NiFi 1.x major release version (1.28.0). Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@hckorkmaz01  While you are currently still using Apache NiFi 1.x major release version, it has reached end of life and is no longer receiving contributions.  As such components will not get library updates or security fixes going forward.   Apache NiFi 2.x is currently active major release being contributed to in the community.  The PrometheusReportingTask was deprecated in Apache NiFi 1.x and officially removed in Apache NiFi 2.x major release.   So I would avoid using it as you will eventually need to move to Apache NiFi 2.x to maintain a secure supported product release.  But technically, this reporting task, while not well maintained in the community, is capable of creating a prometheus endpoint which exposes metrics for all components (includes connections) for consumption. That being said, Cloudera has taken steps to create Cloudera versions of many of the deprecated and removed components in Apache NiFi 2.x; as well as, introduced many components not available at all in any Apache release version (PrometheusReportingTask is not one of them that was retained). https://docs.cloudera.com/cfm/4.11.0/nifi-components-cfm/components/ NOTE:  You are already using a considerably older Apache NiFI 1.18 release.  Many bug fixes and CVEs security issues have been addressed since that release.  If you cannot yet move to Apache NiFi 2.x, you should at least be on the most recent release of Apache NIFi 1.28. Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

Hi everyone, I hope you’re doing well. I am working on a dataflow in Apache NiFi 1.18, and I need to retrieve the queue size information (flowfile count and content size) directly within NiFi itself, not via an external script or Postman. I know that the NiFi REST API provides this data, and I can access it successfully using external tools. However, my goal is to access queue metrics from inside NiFi, for example through processors like InvokeScriptedProcessor, QueryNiFiReportingTask, or any other built-in mechanism, without sending an external REST API request from outside NiFi. Is there a recommended approach, processor, or reporting task that allows NiFi to read its own queue sizes internally? If not, what would be the best practice to achieve this? Any guidance or examples would be greatly appreciated. Thank you in advance!     ... View more