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.
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.
- Update collector
- Prometheus metrics collectors. It consists sender metrics part and ZMQ metrics part.
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.
sender: enabled: true globals: 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 sequences: 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.
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.
senderUpdateCollector: # 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: # 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 local: enabled: true # unlimited number of external tanglebeat instances can be specified. # Each source is listened for published updates and collected into the resulting stream. tanglebeat2: 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
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:
- 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.