Building the NetStats System Dashboard for Ethereum-based platform

Originally posted by Erlang Solutions

2018–10–25 by Felipe Ripoll

During the last year, we have been working closely with POA Network improving one of the systems they run. Erlang Solutions Elixir/Erlang Developer and Architect Felipe Ripoll will look to explore the ins and outs of the NetStats System Dashboard in this latest post.

At Erlang Solutions we provide Erlang and Elixir consultancy but what does POA Network do?

Simply put, they are running an Ethereum-based network but with a new Consensus Mechanism type called Proof of Authority, and they have this to say:

POA Network is an Ethereum-based platform that offers an open-source framework for smart contracts. POA Network is a sidechain to Ethereum utilizing Proof of Authority as its consensus mechanism. POA provides developers with the flexibility to code in Ethereum standards with the added benefits of POA Network’s solutions to scalability and interoperability in blockchain networks.”

In this blog post, we will focus primarily on the dashboard we have created, however, if you want more information on the POA Network you can check their website where they concisely explain what they are doing, and you can also check the code! You’ll find info for this at the bottom of this post.

Netstats System

For this kind of system, it is critical to have a tool capable of checking the status of each Ethereum node in the network. That is why it has been already created. It is called the ‘Netstats’.

The first version of this tool was originally split into two different projects by POA Network: the Agent and the Dashboard. Both were written in Node JS.

  • • The Agent is a simple process running in each Ethereum node. Its task was to retrieve Ethereum metrics periodically and send them through a WebSocket connection to the Dashboard server.
  • • The Dashboard was in charge of receiving the Ethereum metrics from each Agent and serving an HTML webpage with those metrics displayed in real time.

The solution based on a NodeJS approach, although responding successfully to a number of critical requirements, exposed the following weaknesses:

  • • It wasn’t extensible. That means it was only working on Ethereum metrics. Instead, we were asked to make the system capable of handling more types of metrics. For example System metrics (disk space, memory usage…) or maybe others that might become relevant at a later stage.
  • • Persistence; POA Networks wanted a way to store the metrics in a database.
  • • It wasn’t scalable. Node JS is great for prototyping basic systems but it is not very good to sustain a growth from a few agents to thousands.

Our aim was to provide a solution which offers a response to the described weaknesses. Simple as that!

In order to fix the extensibility issue, we decided to provide the system with plugins so that one can easily create own plugins in order to get the specifically wanted metrics.

That plugins mechanism helps with the Persistence issue too. In fact, one can create a plugin which, instead of sending the data to the Dashboard, stores it into a database. One can then create another plugin for the Dashboard communication so the same metric would go through the two plugins in a pipeline.

For the Scalable issue, we decided to go with Elixir

Our Solution

We chose to continue with the system split into two parts; the Agent and a Backend Server. This server is called now the Warehouse. Agents collect data in the nodes and send them to the Warehouse periodically.

The Plugins mechanism are present in both the Agents and the Warehouse. With the agents, one can create plugins for different kinds of metrics. In the event that metrics need to be routed to different destinations, data can be sent directly to a warehouse server using one plugin and to a database through another plugin. With the warehouse, the plugins will be used to select the type of protocol to use while communicating with the Agents. In addition, we can use plugins to determine what to do with the data. For instance, send it to the Dashboard UI or store it into a database.

The Agent

The main role of the new Agent is the same as the original Node JS Agent — collecting data. In the previous version, the Agent would only read the Ethereum metrics and send them to the Dashboard UI. Now it has been made more extensible with the ability to read different types of metrics and send the data to different destinations like the Warehouse, the database or others.

In order to achieve this “extensible” feature, we designed the previously mentioned Plugins mechanism. This mechanism is simple, we divided the Agent into three parts; the Collectors, the Core and the Transfers where the collectors and the transfers are now plugins. That means we can create collectors (for collecting specific kind of metrics) and transfers (in order to process the metrics as we want. For example, sending it to the Dashboard UI, storing it in a database or whatever we want).

  • • The Collector is an Elixir process in charge of collecting a specific kind of metric. It can be an Ethereum metric, System metric or customised. We defined the Collector Plugin and one can implement specific ones in order to achieve a required behaviour. i.e if we need to check the local time in the Agent every 5 minutes we can create a collector for that easily and simply integrate it into the agent.
  • • The Core is the common code in charge of distributing the metrics to the transfers. It works similarly to a pub/sub pattern; the type of metrics each transfer must consume can be defined in the config file.
  • • The Transfers are similar to the collectors. They are Elixir processes subscribed to one or more Collectors. The most important Transfer is the Warehouse Transfer. It receives metrics from collectors and sends them to the Warehouse. The Transfer Plugin is also defined here so one can create custom transfers. i.e if we want to consume the local time metric and store it in a database, we can create a transfer which subscribes to that kind of metric and stores it in the database without affecting the rest of metrics in the system.

The Warehouse

The Warehouse is the Backend server. The Agents connect with this central server and send the metrics to it. The main task is to receive the metrics from agents and dispatch them to the final consumer.

Very similar to the Agent’s architecture, we split the Warehouse into three components to achieve the “extensible” feature; Custom Protocol Handlers, the Core and Receivers.

  • • The Agents speak with the Warehouse using a POA’s protocol. One can implement that protocol over different technologies — for now, we only implemented it over HTTP/REST. We created a Custom Protocol Handler for that technology and a running process in the warehouse that will handle the requests from the Agents.
  • • The Core is the software that is in charge of dispatching the metrics to the final Receivers.
  • • A Receiver is a process that is subscribed to one or many metrics. One example of Receiver can be a DynamoDB Receiver which will receive metrics and store them in a DynamoDB instance. Another example would be a Receiver for the Dashboard UI; it receives the Ethereum metrics and sends them to the Dashboard UI (the Node JS server).

The Dashboard UI Receiver

We have described the Agents and the Warehouse but, where is the webpage for the Dashboard UI? Well, actually we didn’t speak about it yet.

We decided to reuse the Node JS code we had for that Dashboard UI webpage so we had to make some changes:

  • • First, we created a Dashboard Receiver in the Warehouse, which is subscribed to the Ethereum metrics.
  • • We modified the existing Dashboard UI Node JS in order to communicate with this new Receiver instead of the Agents, so every new metric received in the Receiver will be forwarded to the Dashboard UI.

Now the client’s web browsers will connect to the same Dashboard UI and will continue having the same user experience.

More about POA Network and Erlang Solutions

Webinar: BlockScout — Open Source EVM Blockchain Explorer

If you’ve enjoyed this article, and wish to know more about our work with POA Network, our latest webinar on Blockscout is a must! We’ll be speaking to Project Lead Andrew Cravenho on how users are consuming blockchain, and the blockchain architecture surrounding this new project.

Blockchain 2018: Myths vs Reality

Our latest Blockchain article by Scalability Architect and Technical Lead Dominic Perini has already received high recommendations from the programming community. We’ve worked on a number of brilliant FinTech projects over the last year, and Dom (and a few others in the Erlang Solutions team) have created this in-depth overview. Find out what all the fuss is about…

About POA Network

All POA Network code is open source and available on github. Check out their website and follow on social for more update on POA and our collaborations! Their Twitter, in particular, is very active.

Additional Links:

Agent’s code -> Warehouse’s code ->

World-class solutions for issues of scale, reliability & performance. Passionate about Erlang & Elixir. MongooseIM & WombatOAM creators. Also RabbitMQ experts!