Metric to show incoming requests and transactions

hi all,

I hope this finds you well. I am trying to find a metric using:

curl localhost:PORT/metrics

On one of my relay nodes. The metric I am looking for is one that would show me attempted (and rejected) incoming connections. Is there one in the cardano-node metrics? Or should I look in the node_exporter?

Also, in the config.json for cardano-node: I have seen this:

“TraceTxInbound”: false,
“TraceTxOutbound”: false,

Are these tracers (once turned on) supposed to output a metric to show transactions moving through the nodes?

Any suggestions are greatly appreciated,



@Adrem just thought I would ask if you ever found answer to this (I’m only finding this topic now & believe it’s still relevant), since TraceMempool is so unattractive with respect to node memory use. Just looking for something quick & dirty that will verify the BP is getting transactions incoming from its relays. I’ll test this soon but hoping to hear your results in the meantime :sunglasses:

1 Like

Insufficient memory issue can be solved with SWAP file

Hi Robert,

Sorry for the late reply. Short answer is no; i ended up biting the bullet and exposing mempool tracing again. The servers can handle it, but as Alex hinted above sometimes jobs go to swap.

For me this is not too much of an issue, as the machines are monitored 24/7 and i can clear out the swap if needed. Mostly this occurs during db syncs.

Apologies for the lack of formatting but I’m currently on mobile. I look forward to hearing from you regarding the testing you are going to do.



1 Like

I booted our BP with these parameters today and didn’t find them useful to verify that the BP was receiving transactions properly from its relays.

The log messages from TraceTxInbound and TraceTxOutbound were too verbose for me to think they’d be useful to quote here… apparently relating to the timing & confirmation of the node propagating transactions, without enumerating those transactions at all. So I didn’t see how they could take the place of TraceMempool which provides clear confirmation in the logfiles & metrics of a proper transaction volume arriving at the BP.

So we’re back to the usual approaches of memory conservation, Haskell GC management, and waiting for a memory efficient version of the node. :stuck_out_tongue_closed_eyes: