Contact Sales

Structure Your Farm

Structure Your Farm for Good Observability

For a bigger farm, users might want to group miners into some logical groupings so that performance by individual components can be seen. The grouping might differ depending on the size and structure of the farm, some of the most typical elements in the farm topology are:

  • Building
  • Section
  • Tank
  • Aisle
  • Row

To achieve this you have the following options:

  • Define ranges in the metrics-exporter: user can define the whole topology or its part in the configuration file ./monitoring/metrics_exporter/metrics-exporter.toml.
[ranges]
A20 = ["10.2.0.*"] # building A, section 2, tank 0
A21 = ["10.2.1.*"] # building A, section 2, tank 1
A30 = ["10.3.0.*"] # building A, section 3, tank 0
B10 = ["12.1.0.*"] # building B, section 1, tank 0
  • Use subnets and parse octets of IP addresses: If you have static IP addresses and you are using these to organize your miners, the alternative way to prepare data for reporting is to enhance Prometheus configuration with relabels derived from IP addresses. The example below shows how to do it. You can obviously use different names than section, tank, miner.
relabel_configs:
    # Extract the second octet of IPv4 address
    - source_labels: ['__address__']
      regex: "\\d+\\.(\\d+)\\.\\d+\\.\\d+.*"
      target_label: 'section'
    # Extract the third octet of IPv4 address
    - source_labels: ['__address__']
      regex: "\\d+\\.\\d+\\.(\\d+)\\.\\d+.*"
      target_label: 'tank'
    # Extract the last octet of IPv4 address
    - source_labels: ['__address__']
      regex: "\\d+\\.\\d+\\.\\d+\\.(\\d+).*"
      target_label: 'miner'
  • Use separate jobs together with optional custom label: One configuration of Prometheus (stored in prometheus.yml) can contain multiple jobs. For example, you can create separate jobs for each building or container. Each metric has a job label, making it a very convenient approach to group instances (miners). In case when you have other (non-mining) jobs in your configuration, you might want to add a custom label to each job so that you can use that label for filtering/grouping. An example that could be used in relabel_configs section to add building label to each instance that is monitored by the job with value "Building A":
- target_label: 'building'
  replacement: 'Building A'

  • Use multiple Prometheus instances: In the case of thousands or more miners it might be easier to set up a separate Prometheus instance for each group of miners. Refer to Prometheus documentation on how to set up a federation.

  • Use username/workername and re-labels (not recommended): Using username/workername for encoding the information about the physical location of miners is a typically used approach with legacy monitoring applications. This approach does not work well with how Prometheus manages and stores time-series, which is nothing like a traditional relational database. We do not recommend using username/workername for structuring you farm with prometheus for the following reasons:

    • The majority of metrics do not have worker name as labels and joins would need to be created in queries (slows things down, prone to errors)
    • There can be multiple usernames / workernames associated with a single miner; this makes the joins even more difficult (necessary pre-aggregation with logic which value to choose).
Was this helpful?