Lamoda metric responder

, _(*1)

Features

Metric responder with lazy sourcing
Multiple metric response formats
- Telegraf JSON
- Prometheus exporter
Symfony bundle [optional]
Doctrine and redis/predis integration out of the box

Installation

install with composer

composer require lamoda/metrics:^2.0

Usage examples

Main terms

Metric is a named value, representing system running state, health check or cumulative measurement, optionally tagged, _(*2)
Metric response is a set of metrics collected for the fixed moment of time, formatted for single input format, _(*3)
Metric responder is a http endpoint used to render collected metrics into suitable web response format, _(*4)
Metrics can be sourced in the terms of dynamic spawning for collection generation, _(*5)
- The general advice is to have metrics as lazy as possible, resolving to the fixed at the time of generation response
- Usually Source is implemented as an instance of \Traversable object to embed into collection

Metric are generally of two types: * Precomputed metrics are usually generated outside of responding process, like counters * Runtime metrics are generated on call, representing the current state of the system, _(*6)

From the point of metric responding the difference between types is nominal since PHP has share nothing architecture and most stored values should be obtained from storage in any case (and thus waste some caller time), so in general Precomputed metrics are just very fast Runtime metrics, _(*7)

But from the point of metric storing Precomputed metrics have more significant difference - some of them can be retrieved from metric storage for update, _(*8)

Mutable metric is the Metric, which can be updated with either with some delta or with absolute value according to business rules:, _(*9)
- Counters
- Accumulated total
- Balance
Precomputed metrics MAY NOT be Mutable since precomputing can be part of the responder performance optimization process and there is no sense in adjusting such value as it is overwritten during metric computation, _(*10)
Mutable Metric Storage is the general storage interface which allows end user to mutate some metric by name and tags. It's depends on internal storage implementation, what happens if the metric is not found. If the storage allows dynamic metric generation - new metric would be stored silently with given value, _(*11)

Supplementary terms

Collector is the generic class serving the metric Source to other parts of the library, _(*12)
- Responder to render
- Storage receiver to cache them
- Debug utilities for metric profiling and inspection
In general Collector could just keep preconfigured Source or retrieve data from other sources (API, DB, Cache), _(*13)
Materializing is the process of resolving single metric Collector into precomputed metric Source and storing it in a resolved form for fast access to some Storage (Cache, DB, etc), _(*14)
Storage is the metric storing driver. It is responsible for the following actions, _(*15)
- Create new metric instance by its primary parts - name, value and tags
- Find metric by name and tags
- Work as a Source of metrics
- Work as a receiver accepting Source to be materialized in it