| In Logary | In Exometer | Comment |
|---|---|---|
| Metric | Metric | For example transactions per second or memory usage. Create through exometer:new(), update through exometer:update() or on its own initiative through exometer_probe:sample behaviour impl. |
| implicit | Data Point | For Logary: implicit in the metric implementations. It is up to the metric to specify which data points are available under itself. |
| TODO? | Metric Type | "The metric type, in other words, is only used to map a metric to a configurable exometer_entry callback." |
logger.Measure |
Entry Callback | Compiles a measure reported through a [exometer:update() OR call to logger.Measure] into one or many data points. Logary doesn't map Entry Callbacks directly to metrics; this is under construction -- either as a pipeline that is configured or similar to exometer. |
| Measure | Value | As demonstrated in Logary's measure, which has value : float, value' : int64 and value'' : bigint. The separation into different types is taken from riemann's protocol. |
| HealthCheck | Probe | exometer: Probes are a further specialization of exometer entries that run in their own Erlang processes and have their own state (like a gen_server). A probe is implemented through the exometer_probe behavior. Logary: HealthChecks run in their own actors and have their own state, implemented by HealthCheck.fromFn |
| TODO? | Caching | A probe read-through cache with timeouts |
| Rule ⇒ Logger (implicit) | Subscription | exometer: A subscription allows metrics and their data points to be sampled at given intervals and delivered to one or more recipients. Logary: A logger is a subscription from a path/name to a target in the Registry. |
| Target | Reporter | The message sink of the above logger/subscription. |
| Registry | exometer_admin?? |
Similar in its entry maps to what the rules do, but instead of being a subscription, is a path ⇒ exometer entry references. In Logary this is requested from the Registry at runtime. |
The exometer_report subsystem samples metrics at intervals and deliver that to one or more recipients (Logary: target). Exometer splits them into two sorts: callbacks or processes (Logary: only processes/actors/targets).
Subscriptions in exometer exometer_report:subscribe() are in Logary created from the Rule module and given as config. Both subscriptions and rules aim to bind entries/loggers to recipients/targets (exometer/logary respectively).
In Logary, the config is immutable, so there's no runtime subscriptions, but you can create arbitrary runtime loggers, so it's functionally equivalent as rules specify the mapping of a logline or measure to a Target, resolved when the logger is, when exometer represents that mapping explicitly as a subscription. Logary's idea is that it's more declarative to set up a rule than it is to have a subscription; and besides, that rules are best set up when the service starts.
Future work in Logary could be runtime updateable LogaryConf values and proper re-configuration of the framework without losing messages in the targets.
source ⇒ entry callback ⇒ entry ⇒ (output) metric's data points
- A probe backs a metric (same as in Logary). It is up to the metric to specify which data points are available under itself.
- A guage is a push measure originating in the service itself. Otherwise it's a second-order event/sampled metric.
- A subscription ties a metric-datapoint pair to a reporter and an interval.
- Look into making the registry's/metrics data model be more similar to the hierarchial model, with declarative bindings of entry maps, in Logary.
- Both Logary and exometer use declarative configuration-as-a-value, except there are two possible layers above that in Logary; the
Logary.Configurationnamespace and its functions, as well as theCSharpnuget and its usage of theFactoryApi. exometer can read toml, while Logary is for now fully configured in code (but on wish-list to change).