Sei Node Advanced Configuration & Monitoring

Optimize your Sei node’s performance with advanced system configurations, monitoring setup with Prometheus and Grafana, and effective alerting strategies for maintaining reliable node operations.

Optimizing system configuration

The number of possible setups is virtually unlimited, so this document cannot cover them all. Even similar builds and configurations can behave differently because of external factors. Your results may vary.

Use these general guidelines as a starting point. Be cautious and make incremental changes. Test and observe each change before you move forward.

Always focus on only one specific area at a time. Do not change the memory, storage, and CPU configurations all at once. Otherwise, it becomes nearly impossible to diagnose problems.

Memory management

These settings in /etc/sysctl.conf can optimize memory usage and disk I/O patterns:

# Minimize swapping
vm.swappiness = 1

# Control disk write behavior
vm.dirty_background_ratio = 3
vm.dirty_ratio = 10
vm.dirty_expire_centisecs = 300
vm.dirty_writeback_centisecs = 100

To apply the changes, run sudo sysctl -p.

Network stack

These settings in /etc/sysctl.conf may improve network performance:

# Increase connection handling capacity
net.core.somaxconn = 32768
net.core.netdev_max_backlog = 32768
net.ipv4.tcp_max_syn_backlog = 16384

# Optimize buffer sizes
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 87380 16777216

Storage configuration

For NVMe drives, optimize I/O scheduling:

Storage optimization commands

# Set IO scheduler
echo "none" > /sys/block/nvme0n1/queue/scheduler

# Set read-ahead buffer
blockdev --setra 4096 /dev/nvme0n1

# Set IO priority in systemd service
sudo tee -a /etc/systemd/system/seid.service << EOF
[Service]
IOSchedulingClass=realtime
IOSchedulingPriority=2
EOF

# Configure disk mount options
sudo tee -a /etc/fstab << EOF
/dev/nvme0n1p1 /data ext4 defaults,noatime,nosuid,nodev,noexec,commit=60 0 0
EOF

Infrastructure monitoring

Monitoring is one of the most critical components of network infrastructure. This page covers monitoring, performance tuning, and alerting configuration for Cosmos SDK and Tendermint nodes.

Prometheus setup

First, install Prometheus:

wget https://github.com/prometheus/prometheus/releases/download/v2.42.0/prometheus-2.42.0.linux-amd64.tar.gz
tar xvf prometheus-2.42.0.linux-amd64.tar.gz

This is an example Prometheus configuration:

global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: 'sei_node'
    static_configs:
      - targets: ['node1_ip:port']
    metrics_path: /metrics
  - job_name: 'node'
    static_configs:
      - targets: ['node2_ip:port']

Grafana integration

Install and configure Grafana:

sudo apt install -y apt-transport-https software-properties-common
sudo add-apt-repository "deb https://packages.grafana.com/oss/deb stable main"
sudo apt update && sudo apt-get install grafana

Sample Grafana dashboard JSON

{
	"annotations": {
		"list": [
			{
				"builtIn": 1,
				"datasource": "-- Grafana --",
				"enable": true,
				"hide": true,
				"iconColor": "rgba(0, 211, 255, 1)",
				"name": "Annotations & Alerts",
				"type": "dashboard"
			}
		]
	},
	"editable": true,
	"gnetId": null,
	"graphTooltip": 0,
	"id": 1,
	"links": [],
	"panels": [
		{
			"alerting": {},
			"aliasColors": {},
			"bars": false,
			"dashLength": 10,
			"dashes": false,
			"datasource": null,
			"fieldConfig": {
				"defaults": {
					"custom": {}
				},
				"overrides": []
			},
			"fill": 1,
			"fillGradient": 0,
			"gridPos": {
				"h": 8,
				"w": 12,
				"x": 0,
				"y": 0
			},
			"hiddenSeries": false,
			"id": 2,
			"legend": {
				"avg": false,
				"current": false,
				"max": false,
				"min": false,
				"show": true,
				"total": false,
				"values": false
			},
			"lines": true,
			"linewidth": 1,
			"nullPointMode": "null",
			"options": {
				"alertThreshold": true
			},
			"percentage": false,
			"pluginVersion": "7.2.0",
			"pointradius": 2,
			"points": false,
			"renderer": "flot",
			"seriesOverrides": [],
			"spaceLength": 10,
			"stack": false,
			"steppedLine": false,
			"targets": [
				{
					"expr": "tendermint_consensus_height",
					"interval": "",
					"legendFormat": "",
					"refId": "A"
				}
			],
			"thresholds": [],
			"timeRegions": [],
			"title": "Block Height",
			"tooltip": {
				"shared": true,
				"sort": 0,
				"value_type": "individual"
			},
			"type": "graph",
			"xaxis": {
				"buckets": null,
				"mode": "time",
				"name": null,
				"show": true,
				"values": []
			},
			"yaxes": [
				{
					"format": "short",
					"label": null,
					"logBase": 1,
					"max": null,
					"min": null,
					"show": true
				},
				{
					"format": "short",
					"label": null,
					"logBase": 1,
					"max": null,
					"min": null,
					"show": true
				}
			],
			"yaxis": {
				"align": false,
				"alignLevel": null
			}
		}
	],
	"schemaVersion": 26,
	"style": "dark",
	"tags": [],
	"templating": {
		"list": []
	},
	"time": {
		"from": "now-6h",
		"to": "now"
	},
	"timepicker": {},
	"timezone": "",
	"title": "Sei Node Metrics",
	"uid": "sei_metrics",
	"version": 1
}

Alert management

Install Alertmanager:

wget https://github.com/prometheus/alertmanager/releases/download/v0.25.0/alertmanager-0.25.0.linux-amd64.tar.gz
tar xvf alertmanager-0.25.0.linux-amd64.tar.gz

Create alert rules configuration

groups:
  - name: validator_alerts
    rules:
      - alert: NodeDown
        expr: up == 0
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: 'Node {{ $labels.instance }} down'

      - alert: BlockProductionSlow
        expr: rate(tendermint_consensus_height[5m]) < 0.1
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: 'Block production is slow on {{ $labels.instance }}'
      - alert: ValidatorMissedBlocks
        expr: increase(tendermint_consensus_validator_missed_blocks[1h]) > 0
        labels:
          severity: critical
        annotations:
          summary: 'Validator missing blocks'

      - alert: ValidatorJailed
        expr: tendermint_consensus_validator_status == 0
        labels:
          severity: critical
        annotations:
          summary: 'Validator has been jailed'

      - alert: ConsensusStalled
        expr: tendermint_consensus_height_status == 0
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: 'Consensus has stalled'

Log management

Loki setup

Use Loki for log aggregation:

wget https://github.com/grafana/loki/releases/download/v2.8.0/loki-linux-amd64.zip
unzip loki-linux-amd64.zip

Promtail configuration

server:
  http_listen_port: 9080

positions:
  filename: /tmp/positions.yaml

clients:
  - url: http://localhost:3100/loki/api/v1/push

scrape_configs:
  - job_name: sei_logs
    static_configs:
      - targets:
          - localhost
        labels:
          job: seid_logs
          __path__: /var/log/seid/*.log

Log rotation

Configure logrotate to manage log files:

sudo tee /etc/logrotate.d/sei << EOF
/var/log/sei/*.log {
    daily
    rotate 14
    compress
    delaycompress
    notifempty
    create 0640 sei sei
    sharedscripts
    postrotate
        systemctl reload seid
    endscript
}
EOF

Security configuration

Network security

Configure the UFW firewall:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 26656/tcp comment 'Sei P2P'
sudo ufw allow 26657/tcp comment 'Sei RPC'
sudo ufw allow 9090/tcp comment 'Sei gRPC'
sudo ufw enable

Rate limiting

Example Nginx configuration with rate limiting

http {
    limit_req_zone $binary_remote_addr zone=sei_rpc:10m rate=10r/s;

    server {
        listen 26657;
        location / {
            limit_req zone=sei_rpc burst=20 nodelay;
            proxy_pass http://localhost:26657;
        }
    }
}

Validator-specific monitoring

Status query

Query the validator status through the SDK:

seid query staking validator $(seid keys show --bech val -a <validator_keyfile_name>)

Query the status through the REST API:

curl -s "http://localhost:1317/cosmos/staking/v1beta1/validators/<valoper_address>"

Validator "status" query script

#!/bin/bash

MONIKER="$1"
API_URL="http://localhost:1317/cosmos/staking/v1beta1/validators?pagination.limit=500"

echo "Querying validators from $API_URL..."

VALIDATOR_DATA=$(curl -s "$API_URL" | jq -c --arg MONIKER "$MONIKER" '.validators[] | select(.description.moniker == $MONIKER)')

if [[ -z "$VALIDATOR_DATA" ]]; then
    echo "❌ No validator found with moniker: $MONIKER"
    exit 1
fi

echo "Validator details:"
echo "$VALIDATOR_DATA" | jq '.'

Critical metrics

Monitor these validator-specific metrics:

# Check signing status
seid query slashing signing-info $(seid tendermint show-validator)

# Check current delegations
seid query staking delegations-to $(seid keys show -a $VALIDATOR_KEY)

Backup management

Complete automated backup script

#!/bin/bash
BACKUP_DIR="/backup/sei"
DATE=$(date +%Y%m%d)
NODE_HOME="/root/.sei"

# Create backup directory
mkdir -p $BACKUP_DIR

# Stop service
systemctl stop seid

# Backup configuration
tar czf $BACKUP_DIR/sei-config-$DATE.tar.gz $NODE_HOME/config

# Backup data directory
tar czf $BACKUP_DIR/sei-data-$DATE.tar.gz $NODE_HOME/data

# Backup key files
tar czf $BACKUP_DIR/sei-keys-$DATE.tar.gz $NODE_HOME/keyring-file

# Start service
systemctl start seid

# Remove backups older than 7 days
find $BACKUP_DIR -type f -mtime +7 -name '*.tar.gz' -delete

# Log backup completion
echo "Backup completed successfully on $(date)" >> $BACKUP_DIR/backup.log

Host system monitoring

Resource usage tracking

Install and configure node_exporter:

wget https://github.com/prometheus/node_exporter/releases/download/v1.5.0/node_exporter-1.5.0.linux-amd64.tar.gz
tar xvf node_exporter-1.5.0.linux-amd64.tar.gz

Add node_exporter to the Prometheus configuration:

scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['localhost:9100']

Seed node Prometheus metrics

Since v6.7.0, seed nodes serve Prometheus metrics like other nodes. A seed serves no RPC, so its p2p metrics, such as tendermint_p2p_peers, are the only way to watch it. Enable them in the [instrumentation] section of config.toml:

[instrumentation]
prometheus = true
prometheus-listen-addr = ":26660"

If a seed node cannot open the Prometheus listener, the seed fails to start. For example, the port can be in use, or the address can be invalid. A full node logs the error and continues to run.

Metrics server limits

The metrics server uses a 10s read header timeout, a 10s read timeout, a 30s write timeout, and a 60s idle timeout.

max-open-connections under [instrumentation] is not a connection limit. It caps the number of scrapes that the server handles at the same time. Requests over the cap get HTTP 503. The server does not queue them. A slow scraper holds its slot until it finishes or reaches the write timeout. 0 means no limit. The default is 3. Set the value higher than the number of scrapers that can overlap, such as an HA Prometheus pair, probes, and manual curl requests.

chain_id label on metrics

Since v6.7.0, the node adds a chain_id label to every metric that it exports. This includes the Tendermint Prometheus metrics, the Cosmos SDK telemetry, and the OpenTelemetry metrics (evmrpc_*, flatkv_*, litt_*, and pebble_*). If you already set chain_id in global-labels under [telemetry], the Cosmos SDK telemetry keeps your value.

Update PromQL that aggregates across series, such as sum(...) without (...) or by (...), to account for the new label. To scope a query to one chain, add a chain_id match.

Tendermint internal metrics

The tendermint namespace also has these subsystems:

Subsystem prefix	Description
tendermint_internal_autobahn_avail_*	Autobahn availability metrics: the commit road index, the commit global block number, the proposal-to-commit latency, and the commit-to-commit latency (with a timeouts label).
tendermint_internal_autobahn_data_*	Autobahn data metrics: latency (time from the production of a resource to each stage, with resource and stage labels), next_block (the next block to process in each stage), gas_used (gas used by executed blocks), and tx_size (size of executed transactions in bytes).
tendermint_internal_p2p_mux_*	p2p mux stream metrics: the stream latency, the number of open streams (in_flight), and the per-stream counters send_msgs, recv_msgs, send_bytes, and recv_bytes. These metrics have role and kind labels.

EVM RPC OpenTelemetry metrics

The EVM RPC layer emits OpenTelemetry metrics through the process-wide MeterProvider (for example, a Prometheus exporter). It emits these metrics in parallel with the legacy sei_* metrics, so you can migrate dashboards incrementally.

Available EVM RPC metrics

Metric	Type	Description
evmrpc_request_latency_seconds	Histogram	EVM RPC request latency in seconds.
evmrpc_websocket_connects_total	Counter	Number of new WebSocket connections.
evmrpc_redirected_requests_total	Counter	Number of EVM RPC requests forwarded to another validator. Labeled by endpoint and connection.
evmrpc_historical_debug_trace_attempts_total	Counter	Number of debug_trace* requests that target historical blocks beyond the configured max block lookback. Labeled by endpoint and connection.
evmrpc_requests_rejected_total	Counter	Number of JSON-RPC requests that admission control rejected. Labeled by protocol (http or ws) and reason. For HTTP, reason is oversize (larger than max_request_body_bytes, HTTP 413), budget_midread (the max_concurrent_request_bytes budget ran out, HTTP 429), slow_body, rate_limited, unparseable, or read_error. For WebSocket, reason is oversize (close code 1009) or busy (no budget within ws_admission_timeout, JSON-RPC error -32005). See Frame size and concurrency limits.

The evmrpc_request_latency_seconds histogram carries these labels:

Label	Description
endpoint	The RPC method that the node serves (for example, eth_getBalance).
connection	The connection type that serves the request (for example, http or websocket).
success	Boolean that indicates whether the request succeeded.
error_class	A low-cardinality classification of the failure. An empty string means success. Possible values include panic, execution_reverted, evm_not_supported, sei_legacy_disabled, association_missing, jsonrpc_error, and unknown.
jsonrpc_code	A low-cardinality bucket for the JSON-RPC error code: spec (predefined range -32700..-32600), server (server-defined range -32099..-32000), or other. An empty string means no code (success or an untyped error).

Migrating from legacy EVM RPC metrics

These legacy sei_* metrics remain available today but are deprecated. They are scheduled for removal after dashboards migrate to the evmrpc_* OpenTelemetry metrics:

Legacy metric	Replacement
sei_rpc_request_latency_ms	evmrpc_request_latency_seconds
sei_websocket_connect	evmrpc_websocket_connects_total
sei_rpc_request_counter	evmrpc_request_latency_seconds (use the histogram count with the success and error_class labels)

Before the legacy metrics are removed, update your Prometheus and Grafana dashboards to use the evmrpc_* metrics. The latency unit changed from milliseconds (sei_rpc_request_latency_ms) to seconds (evmrpc_request_latency_seconds). Adjust any thresholds and panel formatting to match.

FlatKV OpenTelemetry metrics

The FlatKV state store emits OpenTelemetry metrics through the process-wide MeterProvider (for example, a Prometheus exporter). With these metrics, you can observe commit throughput, catchup progress, snapshotting, rollbacks, and snapshot imports.

Available FlatKV metrics

Metric	Type	Description
flatkv_open_latency	Histogram	Time taken to open the FlatKV store (seconds).
flatkv_apply_changesets_latency	Histogram	Time taken to apply changesets to FlatKV (seconds).
flatkv_commit_latency	Histogram	Time taken to commit FlatKV changes (seconds).
flatkv_commit_batch_latency	Histogram	Time taken to commit a FlatKV data DB batch (seconds).
flatkv_batch_read_old_values_latency	Histogram	Time taken to batch read old FlatKV values (seconds).
flatkv_num_kv_pairs	Counter	Number of key-value pairs applied to FlatKV.
flatkv_pending_writes	Gauge	Current number of pending FlatKV writes.
flatkv_current_version	Gauge	Current committed FlatKV version.
flatkv_catchup_latency	Histogram	Time taken to replay FlatKV WAL entries (seconds).
flatkv_catchup_replay_num_blocks	Counter	Number of FlatKV WAL entries replayed during catchup.
flatkv_snapshot_write_latency	Histogram	Time taken to write a FlatKV snapshot (seconds).
flatkv_snapshot_prune_latency	Histogram	Time taken to prune FlatKV snapshots (seconds).
flatkv_snapshot_prune_attempts	Counter	Total number of FlatKV snapshot prune attempts.
flatkv_current_snapshot_height	Gauge	Current FlatKV snapshot height.
flatkv_rollback_latency	Histogram	Time taken to roll back FlatKV state (seconds).
flatkv_import_latency	Histogram	Time taken to import FlatKV snapshot data (seconds).
flatkv_import_kv_pairs	Counter	Number of key-value pairs imported into FlatKV.
flatkv_import_worker_flush_latency	Histogram	Time taken to flush a FlatKV import worker batch (seconds).
flatkv_flush_latency	Histogram	Time taken to flush a FlatKV data DB (seconds).

Labels

FlatKV metrics carry these labels where applicable:

Label	Description
db	The data DB that the measurement applies to (account, code, storage, or misc). Present on per-DB metrics such as flatkv_commit_batch_latency, flatkv_flush_latency, flatkv_num_kv_pairs, flatkv_pending_writes, flatkv_import_kv_pairs, and flatkv_import_worker_flush_latency.
success	Boolean that indicates whether the operation succeeded. Present on latency and attempt metrics that can fail.
read_only	Boolean, present on flatkv_open_latency, that indicates whether the store was opened read-only.

Pebble internal metrics

FlatKV turns on Pebble’s internal metrics for each data DB by default. The node does not apply an enable-pebble-metrics key from app.toml.

Pebble estimated read/write metrics

SeiDB can count estimated logical reads and writes on its PebbleDB databases. The counters are off by default. They cost less than Pebble’s full internal metrics, and you can use them to estimate read amplification (reads divided by writes).

Metric	Type	Description
pebble_estimated_reads	Counter	Estimated logical PebbleDB reads.
pebble_estimated_writes	Counter	Estimated logical PebbleDB writes.

Both counters have a db attribute. Its value is the name of the data directory, so you can tell the FlatKV data DBs, the state store, and the receipt store apart. Turn the counters on per store in app.toml:

Config key	Section	Store
enable-read-write-metrics	[state-commit.flatkv]	FlatKV data DBs
ss-enable-read-write-metrics	[state-store]	State store, when ss-backend = "pebbledb"
enable-read-write-metrics	[receipt-store]	Pebble-based receipt store

[state-commit.flatkv]
enable-read-write-metrics = true

Log query parallelism for littidx

With the littidx receipt store, each eth_getLogs query scans several blocks at the same time. Results stay in block and transaction order. log-filter-parallelism under [receipt-store] sets how many blocks one query scans at once. The default is 16, and a value of 0 or less uses the default. The setting has no effect on pebbledb.

[receipt-store]
log-filter-parallelism = 16

Per-block hash logger

The state-commit store writes a CSV file of named hashes for each block. Each row has the memIAVL module and root hashes and the FlatKV DB and root hashes. It also has the app hash, the block hash, the results hash (the next block’s LastResultsHash), and the changeset hash. To find where two nodes diverged, compare their logs with seidb hashlog compare.

The hash logger is on by default. It writes to data/hash.log under the state-commit directory, which is <home>/data/hash.log by default. With the default settings, it keeps up to 16 GiB of closed log files. Configure it in the [state-commit] section of app.toml:

Config key	Default	Description
sc-hash-logger-enable	true	Turns the hash logger on or off.
sc-hash-logger-directory	empty	Directory for the log files. Empty means data/hash.log under the state-commit directory.
sc-hash-logger-blocks-to-retain	0	Number of recent blocks to keep. 0 turns off the block limit.
sc-hash-logger-target-file-size	16777216 (16 MiB)	Size in bytes at which the logger closes a file and starts a new one. 0 uses the default.
sc-hash-logger-max-disk-size	17179869184 (16 GiB)	Maximum total size in bytes of closed log files. 0 turns off the size limit.

If you set both sc-hash-logger-blocks-to-retain and sc-hash-logger-max-disk-size to 0, the logs grow without limit. To turn the hash logger off:

[state-commit]
sc-hash-logger-enable = false

LittDB OpenTelemetry metrics

LittDB emits its metrics through the process-wide OpenTelemetry MeterProvider instead of a private Prometheus client. If MetricsEnabled is true, LittDB records its metrics in that provider. By default (MetricsServeEndpoint = false), the application that uses LittDB exports the metrics, and LittDB does not start a /metrics server. If MetricsServeEndpoint is true, LittDB serves /metrics on MetricsPort (default 9101). LittDB no longer has the MetricsNamespace and MetricsRegistry config fields, and all metric names use a fixed litt_ prefix.

Available LittDB metrics

Metric	Type	Unit	Description
litt_table_size_bytes	Gauge	bytes	The size of individual tables in the database.
litt_table_key_count	Gauge	count	The number of keys in individual tables in the database.
litt_open_iterator_count	Gauge	count	The number of currently open iterators for individual tables in the database. A persistently nonzero value indicates a leaked iterator. Garbage collection still runs, but a leaked iterator keeps the segment files it reads on disk until it closes.
litt_bytes_read	Counter	bytes	The number of bytes read from disk since startup.
litt_keys_read	Counter	count	The number of keys read from disk since startup.
litt_cache_hits	Counter	count	The number of cache hits since startup.
litt_cache_misses	Counter	count	The number of cache misses since startup.
litt_read_latency_seconds	Histogram	seconds	Read latency of the database, including both cache hits and cache misses.
litt_cache_miss_latency_seconds	Histogram	seconds	Read latency measured only when a cache miss occurs.
litt_bytes_written	Counter	bytes	The number of bytes written to disk since startup (values only, not metadata).
litt_keys_written	Counter	count	The number of keys written to disk since startup.
litt_write_latency_seconds	Histogram	seconds	Write latency of the database.
litt_flush_count	Counter	count	The number of times a flush operation has been performed.
litt_flush_latency_seconds	Histogram	seconds	Latency of a flush operation.
litt_segment_flush_latency_seconds	Histogram	seconds	Segment flush latency, a subset of the time spent during a flush operation.
litt_keymap_flush_latency_seconds	Histogram	seconds	Keymap flush latency, a subset of the time spent during a flush operation.
litt_garbage_collection_latency_seconds	Histogram	seconds	Latency of garbage collection operations.
litt_chunk_cache_key_count	Gauge	count	The number of keys in the chunk cache.
litt_chunk_cache_weight_bytes	Gauge	bytes	The weight of the chunk cache in bytes.
litt_chunk_cache_keys_added	Counter	count	The number of keys added to the chunk cache.
litt_chunk_cache_weight_added_bytes	Counter	bytes	The weight of the entries added to the chunk cache.
litt_chunk_cache_eviction_latency_seconds	Histogram	seconds	Eviction latency of the chunk cache.
litt_compression_latency_seconds	Histogram	seconds	Time to compress a batch of values before LittDB writes them. Emitted only for tables with compression enabled.
litt_compression_uncompressed_bytes	Counter	bytes	Value bytes sent to compression since startup.
litt_compression_compressed_bytes	Counter	bytes	Compressed bytes produced since startup. Divide by litt_compression_uncompressed_bytes to get the overall compression ratio.
litt_compression_ratio	Histogram	ratio	Compressed bytes divided by uncompressed bytes, per batch. Lower is better.

Attributes

Attribute	Description
table	The table that the observation applies to. Present on per-table metrics such as litt_bytes_read, litt_read_latency_seconds, litt_table_size_bytes, and the flush/GC latency histograms.
cache	The cache instance that the observation applies to (chunk_read or chunk_write). Present on the litt_chunk_cache_* metrics, which distinguish read and write caches by this attribute instead of by separate metric names.

Migrating from legacy LittDB metrics

The OpenTelemetry migration changed the metric names, units, and shape. You must update your existing Prometheus and Grafana dashboards:

• Latency metrics moved from millisecond summaries (for example, {namespace}_read_latency_ms) to second histograms (litt_read_latency_seconds). Change thresholds and panel formatting from milliseconds to seconds.
• Counters and gauges gained a fixed litt_ prefix and explicit units. For example, bytes_read became litt_bytes_read, and the cache weight gauge became litt_chunk_cache_weight_bytes.
• The per-cache series that previously had separate metric names (for example, chunk_read_cache_* and chunk_write_cache_*) are now the shared litt_chunk_cache_* metrics. The cache attribute distinguishes them.
• The MetricsNamespace and MetricsRegistry config fields no longer exist. Metric names are fixed, and the global OTel provider always backs the metrics. Set the scrape port with MetricsPort.

Performance testing

Example benchmark script using eth_getLogs

import { ethers } from 'ethers';

// Configuration
const EVM_RPC_URL = 'http://localhost:8545'; // EVM RPC endpoint to test
const CONTRACT_ADDRESS = '0x0000000000000000000000000000000000001002'; // replace with very active contract for best results
const INITIAL_BLOCK_RANGE = 50; // range of blocks to query using 'eth_getLogs'
const RANGE_INCREMENT = 10; // additional blocks to query each consecutive round
const MAX_TESTS = 50; // total number of rounds for testing

// Store metrics for final analysis
const metrics = [];

function getResponseSize(logs) {
  return Buffer.byteLength(JSON.stringify(logs), 'utf8');
}

function formatBytes(bytes) {
  if (bytes === 0) return '0 B';
  const k = 1024;
  const sizes = ['B', 'KB', 'MB', 'GB'];
  const i = Math.floor(Math.log(bytes) / Math.log(k));
  return `${parseFloat((bytes / Math.pow(k, i)).toFixed(2))} ${sizes[i]}`;
}

function padString(str, length) {
  return String(str).padEnd(length);
}

function analyzeResults(metrics) {
  console.log('\nPerformance Analysis');
  console.log('='.repeat(50));

  // Filter out queries with no logs for meaningful statistics
  const queriesWithLogs = metrics.filter((m) => m.logsCount > 0);
  const totalQueries = metrics.length;

  console.log(`\nGeneral Statistics:`);
  console.log(`Total Queries Run: ${totalQueries}`);
  console.log(`Queries with Logs: ${queriesWithLogs.length}`);
  console.log(`Empty Responses: ${totalQueries - queriesWithLogs.length}`);

  if (queriesWithLogs.length > 0) {
    const avgResponseTime = queriesWithLogs.reduce((acc, m) => acc + m.responseTime, 0) / queriesWithLogs.length;
    const avgLogsPerQuery = queriesWithLogs.reduce((acc, m) => acc + m.logsCount, 0) / queriesWithLogs.length;
    const maxLogs = Math.max(...queriesWithLogs.map((m) => m.logsCount));
    const maxLogsQuery = queriesWithLogs.find((m) => m.logsCount === maxLogs);

    console.log(`\nPerformance Metrics:`);
    console.log(`Average Response Time (with logs): ${avgResponseTime.toFixed(2)}ms`);
    console.log(`Average Logs per Query: ${avgLogsPerQuery.toFixed(2)}`);
    console.log(`Maximum Logs in Single Query: ${maxLogs}`);
    if (maxLogsQuery) {
      console.log(`- At Range Size: ${maxLogsQuery.rangeSize} blocks`);
      console.log(`- Response Time: ${maxLogsQuery.responseTime}ms`);
      console.log(`- Efficiency: ${maxLogsQuery.logsPerMs.toFixed(3)} logs/ms`);
    }

    // Identify optimal range size based on logs/ms
    const bestEfficiency = queriesWithLogs.reduce((best, m) => (m.logsPerMs > best.logsPerMs ? m : best));
    console.log(`\nOptimal Performance:`);
    console.log(`Best Efficiency: ${bestEfficiency.logsPerMs.toFixed(3)} logs/ms`);
    console.log(`- At Range Size: ${bestEfficiency.rangeSize} blocks`);
    console.log(`- Retrieved ${bestEfficiency.logsCount} logs in ${bestEfficiency.responseTime}ms`);
  }
}

async function testEthGetLogs() {
  const provider = new ethers.JsonRpcProvider(EVM_RPC_URL);

  try {
    const latestBlock = await provider.getBlockNumber();
    console.log(`Latest block: ${latestBlock} (0x${latestBlock.toString(16)})`);

    let currentToBlock = latestBlock;
    let currentRange = INITIAL_BLOCK_RANGE;
    let testCount = 0;

    // Column headers with fixed widths
    console.log('\nBlock Range         Time  Logs    Size     B/ms   Logs/ms  KB/Log  Range');
    console.log('='.repeat(80));

    while (testCount < MAX_TESTS && currentToBlock > 0) {
      const fromBlock = Math.max(0, currentToBlock - currentRange);

      try {
        const startTime = Date.now();
        const filter = {
          fromBlock: fromBlock,
          toBlock: currentToBlock,
          address: CONTRACT_ADDRESS
        };

        const logs = await provider.getLogs(filter);

        const endTime = Date.now();
        const responseTime = endTime - startTime;
        const logsCount = logs.length;
        const responseSize = getResponseSize(logs);

        // Calculate metrics
        const bytesPerMs = (responseSize / responseTime).toFixed(1);
        const logsPerMs = (logsCount / responseTime).toFixed(3);
        const kbPerLog = logsCount > 0 ? (responseSize / 1024 / logsCount).toFixed(2) : 'N/A';

        // Store metrics for analysis
        metrics.push({
          rangeSize: currentRange,
          responseTime,
          logsCount,
          responseSize,
          bytesPerMs: parseFloat(bytesPerMs),
          logsPerMs: parseFloat(logsPerMs),
          kbPerLog: kbPerLog !== 'N/A' ? parseFloat(kbPerLog) : 0
        });

        // Format block range
        const rangeDisplay = `${fromBlock.toString(16)}-${currentToBlock.toString(16)}`;

        // Log with fixed column widths
        console.log(padString(rangeDisplay, 17) + padString(responseTime, 6) + padString(logsCount, 8) + padString(formatBytes(responseSize), 9) + padString(bytesPerMs, 8) + padString(logsPerMs, 9) + padString(kbPerLog, 8) + currentRange);

        if (logsCount === 10000) {
          console.log(`\nWarning: Hit 10000 log limit at range ${currentRange}`);
        }

        currentToBlock = fromBlock - 1;
        currentRange += RANGE_INCREMENT;
        testCount++;
      } catch (error) {
        console.log(`Error at range ${currentRange}: ${error.message}`);
        currentRange = Math.max(INITIAL_BLOCK_RANGE, currentRange - RANGE_INCREMENT);
        currentToBlock = fromBlock - 1;
        testCount++;
      }

      await new Promise((resolve) => setTimeout(resolve, 1000));
    }

    // Perform final analysis
    analyzeResults(metrics);
  } catch (error) {
    console.error('Failed to initialize or get latest block:', error);
    process.exit(1);
  }
}

// Run the test
testEthGetLogs();

For specific customizations or other metrics, ask the Sei technical communities on Telegram or Discord.