FAQs
Here are some common questions we receive. If you have further questions that are not addressed here, feel free to reach out to us at support@metrika.co.
Where can I find more information about Metrika’s Node Monitoring capabilities and partnership with Flow?
In case you aren't familiar with Metrika, a brief overview of our Node Monitoring capabilities and partnership with Flow can be found in the link here.
Has the Node Agent been tested?
Over the last couple of months, the Flow team has been testing the Metrika Node Agent and Platform on the Canarynet, Testnet, and Mainnet networks. We’re happy to report that no issues were found. If you’d like to test the Metrika agent before deploying it on Mainnet, the Metrika Platform supports all of Flow’s networks, including localnet.
What steps has Metrika taken to ensure the Node Agent is secure?
In addition to testing the Node Agent across all the Flow networks, the Metrika Node Agent has been audited by a third-party auditor. No major issues were found, and the minor issues have already been addressed.
With a Docker reverse proxy, will the Metrika agent have access to the private keys belonging to the Flow nodes? If Metrika has access to the Docker socket, would it still be able to access anything inside the Flow containers?
When Caddy is used to proxy requests to the Docker daemon, the Metrika agent is configured to run as a user that does not belong to the docker group. In this case, only requests to paths allowed by the proxy configuration will end up to the docker daemon's non-networked UNIX socket, and the agent cannot access anything inside the node container (since its user does not have permissions to write commands to the daemon's socket file under /var/docker/docker.sock).
The following are the Docker API operations the agent relies upon to discover containerized nodes:
GET /containers/json. To list containers for container discovery purposes.
GET /containers/(id or name)/json. To match against container id or name for node discovery purposes.
GET /events. To subscribe to docker's events filtered by the discovered container's name.
GET /containers/(id or name)/logs. To stream container logs for event generation (i.e.
agent.node.down) and metadata extraction (i.e. network, chain, node role).
Is there an overview of what information Metrika is collecting from Flow and how that data is made available?
The Metrika agent collects system metrics from the host and Prometheus metrics & logs from Flow nodes
Logs are emitted to stdout as JSON formed strings. On systemd systems, the logs will be sent to the system journal daemon journald. Other systems may log to /var/log.
Flow nodes produce health metrics in the form of Prometheus metrics, exposed from the node software on /metrics.
The data collected by the agent is published to your private workspace in the Metrika Platform where it powers our Node Monitoring dashboard, alerts, and analytical intelligence.
More details on how each metric is calculated can be found here
To access the raw agent data, the agent provides an Exporter API which allows developers to implement their own exporter (i.e. JSON file, publish to a custom server)
Is there a way to get the necessary data through an API that would allow us to install Metrika on a different machine?
At the moment, there's no way to install the Metrika agent on another machine and get the necessary data through an API. In addition to the node metrics and logs we collect, the agent captures system metrics from the host.
Our Node Monitoring services synthesize these 3 data sources and provide a unified view into system, node and network health for alignment and easy correlation.
In the future, we’ll be able to amplify the value of these data sources and identify anomalies that help Node Operators identify performance issues before they impact the lifecycle duties of a node.
If all the Flow Node Operators have Metrika installed, would the whole Flow network be impacted if Metrika is somehow compromised?
We take our role within the Flow ecosystem very seriously. We’re doing everything we can to mitigate any risks involved with the Metrika agent
The agent is open source. Anyone can access the code, review it and contribute to it if they wish. We welcome contributions and feedback from the community!
The Metrika Agent is currently _read-only, _i.e. it is only monitoring the nodes, and does/should not have the privileges required to affect them in any way. Initially limiting the agent to ‘monitoring’ (vs. actively managing a node) was a decision we made when we started the project, precisely because we take security very seriously. As such, if someone managed to exploit the agent, that should never result in a node being compromised.
The agent does NOT expose an API to the world, it initiates connections not vice versa. Similarly, penetration of the Metrika backend should not result in nodes being compromised.
As mentioned above, it’s undergone a security audit by one of the most respected auditors in the space.
The agent will continue to be regularly audited and the results will be made public.
In the future, we’ll be rolling out a bug bounty program to leverage the collective wisdom of the community in our efforts to identify any potential security-related issues.
In addition to the above, more information on the steps we’ve taken to build our agent in line with industry wide standards and best practices can be found in the document here (page #4).
How do I setup alerts for a node?
By default, a node is automatically subscribed to all the alerts for that specific node role.
Last updated
