Tangle health metrics. Successor of Traveling IOTA project
Switch branches/tags
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.


About Tanglebeat

Tanglebeat is a lightweight yet highly configurable software agent with the main purpose to collect Tangle-related metrics to Prometheus TSDB to be displayed with such tools as Grafana.

It can be run in various standalone and distributed configurations to ensure high availability and objectivity of the metrics.

Demo Grafana dashboard can be found at tanglebeat.com

Tanglebeat is a successor of Traveling IOTA project, scaled up and, hopefully, more practical version of the latter.

Transfer confirmation metrics

Tanglebeat is performing IOTA value transfers from one address to the next one in the endless loop.
Tangle beat makes sure the bundle of the transfer is confirmed by promoting it and reattaching (if necessary). Tanglebeat starts sending whole balance of iotas to the next address in the sequence immediately after current transfer is confirmed. And so on.

Several sequences of addresses are run in parallel. Confirmation time and other statistical data is collected in the process of sending and, after some averaging, is provided as metrics.

Examples of the metrics are transfers per hour or TfPH, average PoW cost per confirmed transfer, average confirmation time.

Tanglebeat publishes much more data about transfers through the open message channel. It can be used to calculate other metrics and to visualize transfer progress.

ZeroMQ metrics

Tanglebeat also provides usual metrics derived from data of Zero MQ stream by IRI such as TPS, CTPS, Confirmation rate and duration between milestones

Configure and run

Tanglebeat is a single binary. It takes no command line arguments. Each Tanglebeat instance is configured through tanglebeat.yml file which must be located in the working directory where instance ir run. The config file contains seeds of sequences therefore should never be made public.

Each Tanglebeat instance consists of the following parts. Every part can be enabled, disabled and configured independently from each other thus enabling congfiguration of any size and complexity.

  • Sender
  • Update collector
  • Prometheus metrics collectors. It consists sender metrics part and ZMQ metrics part.

See picture in the end


Sender is running sequences of transfers. It generates transfer bundles, promotion and (re)attaches them until confirmed for each of enabled sequences of addresses. Sender is configured through sender section in the config file. It contains global and individual parameters for each sequence of transfers.

    enabled: true
        iotaNode: &DEFNODE https://field.deviota.com:443    
        iotaNodeTipsel: *DEFNODE              
        iotaNodePOW: https://api.powsrv.io:443
        apiTimeout: 15
        tipselTimeout: 15
        powTimeout: 15
        txTag: TANGLE9BEAT
        txTagPromote: TANGLE9BEAT
        forceReattachAfterMin: 15
        promoteEverySec: 10
        Sequence 1:
            enabled: true
            iotaNode: http://node.iotalt.com:14600
            seed: SEED99999999999999
            index0: 0
            promoteChain: true
        Another sequence:
            enabled: false
            seed: SEED9ANOTHER9999999999999
            index0: 0
            promoteChain: true
        # more sequences can be configured    

Sender generates updates with the information about the progress, per sequence. Each update contains all the data, about the event. Metrics are calculated from sender updates. It also allows visualisation of the sendinf process like Traveling IOTA does.

Update collector

If enabled, update collector gathers updates from one or many senders (sources) into one resulting stream of updates. This function allows to configure distributed network of Tanglebeat agents. The sender itself is on of sources. Data stream from update collector is used to calculate metrics for Prometheus.

    # sender update collector is enabled if at least one of sources is enabled
    # sender update collector collects updates from one or more sources to one stream
        # sources with the name 'local' means that all updates generated by this instance are collected into 
        # resulting stream. If 'local' source is disabled, it means that localy generated updates 
        # have no effect on metrics and are not published
            enabled: true
        # unlimited number of external tanglebeat instances can be specified. 
        # Each source is listened for published updates and collected into the resulting stream. 
            enabled: true
            target: "tcp://node.iotalt.com:3100"
    # if true, resulting stream of updates is published to outside through specified port
    # if false, resulting stream is not published and only used to calculate the metrics
    publish: true
    outPort: 3100

If publish=true resulting stream of updates is exposed through specified ports and can be collected by other Tanglebeat instances. Data is published over Nanomsg/Mangos sockets in the form of JSON messages.

Published sender updates can be subscribed by external consumers for expample in order to calculate own metrics.

Here's an example of a client (in Go) which calculates averaged confirmation time statistics to expose it as web service

Prometheus metrics collectors

If enabled, it exposes metrics to Prometheus. There are two independent parts:

  • Sender metrics. It exposes metrics calculated from sender update stream:

    • tanglebeat_confirmation_counter, tanglebeat_pow_cost_counter, anglebeat_confirmation_duration_counter, tanglebeat_pow_duration_counter, tanglebeat_tipsel_duration_counter
    • and metrics precalculated by Prometheus rules in tanglebeat.rules
  • Zero MQ metrics. If enabled, reads Zero MQ from IRI node, calculates and exposes TPS, CTPS etc metrics to Prometheus.


Picture of the main parts of Tanglebeat