feat: add OpenTelemetry to node

[alexghr]

This PR adds OpenTelemetry to the monorepo and starts tracking the following metrics in the node:

• resource usage (CPU, system memory)
• block height
• average block size (how many txs per block)
• mempool status
• time taken to generate the witness and prove the protocol circuits
• time to simulate the circuits (only relevant if using mocked proofs)

The witgen/proving time are using gauges rather than histograms because of a quirk with how often Prometheus scrapes the metrics vs how many proofs we generate of the same type. In PromQL recreating the histogram quantile requires looking at the rate of change of the individual buckets but if proving takes tens-of-seconds it doesn't change often enough so it ends up dividing by 0. Using a guage gives us instantaneous values, but we potentially lose data (e.g. if two proofs finish in the same scrape interval) and in the dashboard the numbers won't "decay" (meaning if for some reason the node stop producing blocks the proof duration will stay at the previous value).

Three new components are added to the architecture:

• an instance of the OpenTelemetry collector (aggregates metrics pushed by the node)
• an instance of Prometheus to scrape to collector for data
• an instance of Grafana to chart the data

The top-level docker-compose has been updated to include these components under the metrics profile. To run the metrics stack:

$ docker compose --profile metrics up -d

Then e2e tests can be run with metrics being exported to Grafana:

OTEL_COLLECTOR_HOST=127.0.0.1:4318 yarn test e2e_block_building

Two Grafana dashboards are included with this PR.

Node stats:

Protocol circuit stats:

[AztecBot]

Benchmark results

Metrics with a significant change:

• proof_construction_time_sha256_30_ms (16): 1,809 (+29%)
• proof_construction_time_sha256_30_ms (32): 1,668 (+17%)
• protocol_circuit_witness_generation_time_in_ms (private-kernel-reset-small): 2,408 (+21%)
• protocol_circuit_witness_generation_time_in_ms (private-kernel-tail-to-public): 6,841 (-19%)
• protocol_circuit_witness_generation_time_in_ms (public-kernel-app-logic): 4,680 (+16%)

Detailed results

All benchmarks are run on txs on the Benchmarking contract on the repository. Each tx consists of a batch call to create_note and increment_balance, which guarantees that each tx has a private call, a nested private call, a public call, and a nested public call, as well as an emitted private note, an unencrypted log, and public storage read and write.

This benchmark source data is available in JSON format on S3 here.

Proof generation

Each column represents the number of threads used in proof generation.

Metric	1 threads	4 threads	16 threads	32 threads	64 threads
proof_construction_time_sha256_30_ms	11,524	3,149 (-1%)	⚠️ 1,809 (+29%)	⚠️ 1,668 (+17%)	1,517 (+3%)
proof_construction_time_sha256_100_ms	45,242 (-2%)	12,140 (-3%)	5,766 (-2%)	5,653 (-2%)	5,603 (-1%)
proof_construction_time_poseidon_hash_ms	78.0 (-1%)	34.0	35.0 (+3%)	59.0 (+2%)	87.0 (-1%)
proof_construction_time_poseidon_hash_30_ms	1,534	419 (-1%)	207 (+1%)	221	276 (+3%)
proof_construction_time_poseidon_hash_100_ms	5,756 (-1%)	1,574 (-2%)	731 (-1%)	789 (+2%)	811 (+1%)

L2 block published to L1

Each column represents the number of txs on an L2 block published to L1.

Metric	4 txs	8 txs	16 txs
l1_rollup_calldata_size_in_bytes	1,412	1,412	1,412
l1_rollup_calldata_gas	9,464	9,474	9,476
l1_rollup_execution_gas	610,285	610,295	610,297
l2_block_processing_time_in_ms	761 (+1%)	1,413	2,690
l2_block_building_time_in_ms	25,616	51,049	100,504
l2_block_rollup_simulation_time_in_ms	25,519	50,747	100,145
l2_block_public_tx_process_time_in_ms	21,938	46,978	96,402

L2 chain processing

Each column represents the number of blocks on the L2 chain where each block has 8 txs.

Metric	3 blocks	5 blocks
node_history_sync_time_in_ms	7,025 (+1%)	9,858
node_database_size_in_bytes	12,157,008	16,068,688
pxe_database_size_in_bytes	16,254	26,813

Circuits stats

Stats on running time and I/O sizes collected for every kernel circuit run across all benchmarks.

Circuit	simulation_time_in_ms	witness_generation_time_in_ms	proving_time_in_ms	input_size_in_bytes	output_size_in_bytes	proof_size_in_bytes	num_public_inputs	size_in_gates
private-kernel-init	129	477 (-2%)	13,076 (+3%)	20,634	67,190	92,352	2,819	524,288
private-kernel-inner	393	1,004 (+8%)	50,027 (-1%)	94,902	67,190	92,352	2,819	2,097,152
private-kernel-tail	370	1,785	50,016 (-4%)	99,121	71,733	14,912	399	2,097,152
base-parity	6.19 (+1%)	1,831	2,755	128	64.0	2,208	2.00	131,072
root-parity	48.9	72.4 (+7%)	40,768 (-4%)	27,100	64.0	2,720	18.0	2,097,152
base-rollup	7,910	4,810 (+12%)	83,685 (-2%)	170,330	756	3,648	47.0	4,194,304
root-rollup	110	90.4 (+16%)	24,822 (+8%)	25,309	620	3,456	41.0	1,048,576
public-kernel-setup	714 (+1%)	3,660 (+13%)	45,327 (+2%)	116,905	93,334	125,344	3,850	2,097,152
public-kernel-app-logic	611	⚠️ 4,680 (+16%)	48,701 (+1%)	116,905	93,334	125,344	3,850	2,097,152
public-kernel-tail	1,412	35,717 (-1%)	189,471	511,910	10,014	14,912	399	8,388,608
private-kernel-reset-small	593 (+1%)	⚠️ 2,408 (+21%)	44,678 (-5%)	123,313	67,190	92,352	2,819	2,097,152
public-kernel-teardown	616 (+1%)	4,661 (+13%)	48,215 (+2%)	116,905	93,334	125,344	3,850	2,097,152
merge-rollup	28.9	N/A	N/A	16,542	756	N/A	N/A	N/A
private-kernel-tail-to-public	N/A	⚠️ 6,841 (-19%)	97,173 (-5%)	N/A	N/A	125,344	3,850	4,194,304

Stats on running time collected for app circuits

Function	input_size_in_bytes	output_size_in_bytes	witness_generation_time_in_ms	proof_size_in_bytes	proving_time_in_ms	size_in_gates	num_public_inputs
ContractClassRegisterer:register	1,344	9,944	404 (-4%)	N/A	N/A	N/A	N/A
ContractInstanceDeployer:deploy	1,408	9,944	40.3 (+1%)	N/A	N/A	N/A	N/A
MultiCallEntrypoint:entrypoint	1,920	9,944	1,808 (+1%)	N/A	N/A	N/A	N/A
GasToken:deploy	1,376	9,944	947 (-3%)	N/A	N/A	N/A	N/A
SchnorrAccount:constructor	1,312	9,944	1,449 (+2%)	N/A	N/A	N/A	N/A
SchnorrAccount:entrypoint	2,304	9,944	2,816	16,768	54,235 (-4%)	2,097,152	457
Token:privately_mint_private_note	1,280	9,944	1,643 (-1%)	N/A	N/A	N/A	N/A
FPC:fee_entrypoint_public	1,344	9,944	355 (+1%)	16,768	11,186 (-3%)	524,288	457
Token:transfer	1,312	9,944	4,443 (+1%)	16,768	45,304 (-4%)	2,097,152	457
AuthRegistry:set_authorized (avm)	21,043	N/A	N/A	87,200	1,378 (+2%)	N/A	N/A
FPC:prepare_fee (avm)	28,841	N/A	N/A	88,032	5,795 (+1%)	N/A	N/A
Token:transfer_public (avm)	44,971	N/A	N/A	87,865	4,759 (+1%)	N/A	N/A
AuthRegistry:consume (avm)	34,973	N/A	N/A	87,616	2,981	N/A	N/A
FPC:pay_refund (avm)	33,573	N/A	N/A	88,448	10,985 (+1%)	N/A	N/A
Benchmarking:create_note	1,344	9,944	1,400	N/A	N/A	N/A	N/A
SchnorrAccount:verify_private_authwit	1,280	9,944	73.8 (+1%)	N/A	N/A	N/A	N/A
Token:unshield	1,376	9,944	3,677 (+2%)	N/A	N/A	N/A	N/A
FPC:fee_entrypoint_private	1,376	9,944	4,643 (+3%)	N/A	N/A	N/A	N/A

AVM Simulation

Time to simulate various public functions in the AVM.

Function	time_ms	bytecode_size_in_bytes
GasToken:_increase_public_balance	66.4 (-8%)	13,873
GasToken:set_portal	17.1 (+2%)	3,495
Token:constructor	94.3 (+5%)	24,207
FPC:constructor	60.9 (-2%)	13,893
GasToken:mint_public	53.2 (+4%)	10,241
Token:mint_public	70.1 (-11%)	19,216
Token:assert_minter_and_mint	221 (+2%)	13,034
AuthRegistry:set_authorized	34.8 (+10%)	7,869
FPC:prepare_fee	187 (-1%)	15,187
Token:transfer_public	32.9 (+6%)	31,425
FPC:pay_refund	140 (+21%)	20,080
Benchmarking:increment_balance	2,689	15,465
Token:_increase_public_balance	58.1 (-19%)	15,089
FPC:pay_refund_with_shielded_rebate	162 (-1%)	21,167

Public DB Access

Time to access various public DBs.

Function	time_ms
get-nullifier-index	0.184 (+17%)

Tree insertion stats

The duration to insert a fixed batch of leaves into each tree type.

Metric	1 leaves	16 leaves	64 leaves	128 leaves	256 leaves	512 leaves	1024 leaves
batch_insert_into_append_only_tree_16_depth_ms	10.3	16.7 (+1%)	N/A	N/A	N/A	N/A	N/A
batch_insert_into_append_only_tree_16_depth_hash_count	16.8	31.7	N/A	N/A	N/A	N/A	N/A
batch_insert_into_append_only_tree_16_depth_hash_ms	0.598	0.515 (+1%)	N/A	N/A	N/A	N/A	N/A
batch_insert_into_append_only_tree_32_depth_ms	N/A	N/A	48.3	75.8	133 (+2%)	245	471
batch_insert_into_append_only_tree_32_depth_hash_count	N/A	N/A	95.9	159	287	543	1,055
batch_insert_into_append_only_tree_32_depth_hash_ms	N/A	N/A	0.493	0.466	0.456 (+1%)	0.444	0.439
batch_insert_into_indexed_tree_20_depth_ms	N/A	N/A	59.4	112 (-1%)	183	353	692
batch_insert_into_indexed_tree_20_depth_hash_count	N/A	N/A	109	207	355	691	1,363
batch_insert_into_indexed_tree_20_depth_hash_ms	N/A	N/A	0.502	0.502	0.484	0.478	0.474
batch_insert_into_indexed_tree_40_depth_ms	N/A	N/A	72.6	N/A	N/A	N/A	N/A
batch_insert_into_indexed_tree_40_depth_hash_count	N/A	N/A	133	N/A	N/A	N/A	N/A
batch_insert_into_indexed_tree_40_depth_hash_ms	N/A	N/A	0.517	N/A	N/A	N/A	N/A

Miscellaneous

Transaction sizes based on how many contract classes are registered in the tx.

Metric	0 registered classes	1 registered classes
tx_size_in_bytes	85,672	670,983

Transaction size based on fee payment method

| Metric | |
| - | |

[just-mitch]

If the meter is Archiver, is it redundant to call the gauge "ARCHIVER_"? Should/Could it be the case that components other than the Archiver want to use a more generic Metrics.BLOCK_HEIGHT?

[alexghr]

👍 makes sense to keep it generic.

Unforunatley the meter name isn't captured by Prometheus as an attribute. (the OTEL data model is hierarchical: the meter "archiver" owns the gauge but that relationship doens't make it into the prom data)

[just-mitch]

Just a thought: this reminds me of react prop-drilling. Might it be better for a global like this to have a global getter that returns a "real" or "no-op" client based on environment variables? Then components can request it ad-hoc in their constructors.

[alexghr]

I had thought about it, but didn't implement it because we don't have other global instances. After drilling the instance in so many places, I think it makes sense to make it global

[just-mitch]

Does this also shut down the hostMetrics?

[alexghr]

The host metrics does not expose a stop method :(

[just-mitch]

Where is the config for the e2e tests defined? As I understand, this is going to use the no-op client if collector is not defined, but then where do the stats go?

[alexghr]

I'll make it clearer (although if we switch to a global instance it might not be needed).

[just-mitch]

Did your design change? Should we move that design to implemented?

[PhilWindle]

Just one comment