mempool: Add usdt event tracepoints and eBPF logging tool.

[russeree]

Added usdt tracepoints to mempool additions and eviction functions

Using the bitcoin usdt tracepoints api, two mempool event tracepoints were added to txmempool.cpp. These tracepoints are active upon tx additions and evictions to the mempool. This is useful for logging the mempool contents for analysis. Better fee estimation models and custom TXID lookup scripts are some of the first uses that come to mind,

The included bpftrace script logs all mempool additions and removals in a .csv format that can be viewed in realtime or piped to a file for analysis.

NOTES Ref.

• code included follows the USDT guidelines (no parsing or serialization) so near 0 effect on core performance.
• bpftace script log_mempool_activity.bt is included and generates a .csv log output of all additions and evictions within the mempool along with the reason, size, time, txid, fee, and value of the TX
• Documentation has been updated to reflect the new mempool context
• Tracepoint API is very reliable in testing, Logged mempool TXs for over 24 hours and the csv output was parsed with 0 errors.
• No env vars change needed to run bpftrace script

IMPOVEMENTS Ref,

• The included bpftrace script improves on all existing examples by using a single printf call. This enables the script to log 100s of mempool evictions without dropping events and destroying the output. This means that unlike the current log_utxos.bt whos output is corrupted while using bpftrace default parameters. The include bpftrace script uses a variety of methods to improve performance and can be ran successfully with default bpftrace environment variables.

[0xB10C]

In general, concept ACK on adding mempool tracepoints for additions and evictions. Thank you for picking this up.

However, I currently don't think this PR is up to Bitcoin Core standards. I've noted a few things below. Also, the commit message could be a bit more meaningful.

Additionally, I think there should be two distinct tracepoints (i.e. calls of the TRACEx macro). One for mempool additions and one for mempool evictions. This allows people e.g. only interested in mempool additions to only hook into a mempool:added tracepoint. No need to pass -1 as eviction reason on mempool addition and no need to pass an event string ("added", "evict").

It's not yet mentioned in the documentation, but we recently started adding tracepoint interface tests to make sure the tracepoints don't break. See e.g. #24358 and #24644 for examples for tests. We should add them for mempool tracepoints too.

[0xB10C]

As an alternative see

bitcoin/contrib/tracing/connectblock_benchmark.bt

Lines 116 to 122 in 1c6fcea

	/* Prints each byte of the block hash as hex in big-endian (the block-explorer format) */
	$p = $hash + 31;
	unroll(32) {
	$b = *(uint8*)$p;
	printf("%02x", $b);
	$p -= 1;
	}

[russeree]

The above unroll loop causes the printf statement to execute on each iteration. This causes dropped trace events that show up as visual artifacts or make for an usable output file. To get a perfect output there should be one printf statement per trace event.

This PRs bpftrace script may not be the best looking but it was implemented so that under the default bpftrace env. The output data will uncompromised and always product a usable result.

Edit: I believe the python script included largely obsoletes this .bt script.

[0xB10C]

IIRC @glozow had mempool tracepoints on her wishlist at some point too. Not sure if this also included tracepoints for mempool package acceptance. Probably out of scope for this PR, but ideas could be added to #20981 :)

[DrahtBot]

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

No conflicts as of last run.

[russeree]

In general, concept ACK on adding mempool tracepoints for additions and evictions. Thank you for picking this up.

However, I currently don't think this PR is up to Bitcoin Core standards. I've noted a few things below. Also, the commit message could be a bit more meaningful.

Additionally, I think there should be two distinct tracepoints (i.e. calls of the TRACEx macro). One for mempool additions and one for mempool evictions. This allows people e.g. only interested in mempool additions to only hook into a mempool:added tracepoint. No need to pass -1 as eviction reason on mempool addition and no need to pass an event string ("added", "evict").

It's not yet mentioned in the documentation, but we recently started adding tracepoint interface tests to make sure the tracepoints don't break. See e.g. #24358 and #24644 for examples for tests. We should add them for mempool tracepoints too.

Awesome, yeah I will work on my commit messages.

There are implemented 2 distinct tracepoints mempool:added and mempool:evicted so that people can hook into the tracepoints they need for their projects.

I will start working on mempool tracepoint tests.

Edit:

I am working on building tests right now, in the short term though I have added an additional python script to log mempool events in a .csv format. It's quite cool! This python script is optimized though the use of the map.queue(), multithreading, and python queue objects to not drop events.

[russeree]

Sorry,
The branch was renamed and the PR was immediately closed.