# Metrics adventure (aka Meeting-log) November 22, 2021

Update before metric rc1.

__The last meeting has no meeting-log!__

Partecipants: Vincent, Christian Decker.

### Table of Content

- [x] Update on the actual status
- Twitter/reddit research question result, [tweet link](https://twitter.com/PalazzoVincenzo/status/1461277860946141184?s=20), [reddit link](https://www.reddit.com/r/lightningnetwork/comments/qwmtm7/important_information_about_the_lightning_network/?utm_content=post&utm_medium=twitter&utm_source=share&utm_name=submit&utm_term=t3_qwmtm7);
- [x] What would be cool to have
- [x] The major informations that the user on tweeter asks
- [x] Discussion on db data model change
- [x] With leveldb and the new db data model the retrieval performance are very bad.
- [x] With this model we can calcalate the update on the node metric. In particular, each update receive from the node (from server side) can update the metric of the node, this avoid the big calculation over all the data. P.S: True for stupind metric
- [x] [Metric Spec](https://github.com/LNOpenMetrics/lnmetrics.rfc) discussion
- [x] First draft of the json schema for the metric one ([link](https://github.com/LNOpenMetrics/lnmetrics.rfc/blob/main/schemas/metric_1.schema.json))
- [x] Discussion on additional proprieties in th metrics ([link](https://github.com/LNOpenMetrics/lnmetrics.rfc/issues?q=is%3Aopen+is%3Aissue+label%3A%22%3Abulb%3A+brainstorming%22))
- [x] What is the core idea under the CLTV-delta?
- [x] Appendix (if there is time)

### Meeting discussion

#### :pushpin: Update on the actual status

##### :bulb: Twitter/Reddit research

Give to the user some metrics that he want; can help us to improve the adoption the plugin usage. In addition, we will be cool have some report status on social, like twitter or telegram.

#### :pushpin: Discussion on db data model change

##### :turtle: Performance problem

The index node id/metric_one/index can be the bottleneck, we can use the Iterator pattern (in the leveldb)
to iterate over the keys because we know that the iterator are in sorted in the lexical order

##### :bulb: In fly metrics calculation

In order to avoid that the user will call the raw method to get all the `metric_one` payload, we can implement
some useful metrics with the data that we have, and calculate them in fly. Because, we can
calculate the metrics at time `t`, with the data store at time `t - 1`. This required on server to store
the information to calculate these metrics. In this way, we know the metrics at time `t - 1` and the
information from how this metrics are calculated, and at time t we need just to accumulate what we have at
time `metric(t - 1) + metric(t)`.

#### :pushpin: Metric Spec discussion

##### :bulb: Metrics one JSON schema

Overall the schema looks good, and it is ready to be put in production. In addition, we have some small property adds before the first release

##### :bulb: Additional properties in the metrics

##### :question: What is the core idea under the clvt-delta?

With a small clvt-delta we need a very good up time, because the node have small time to react.

###### N.B: appendix track skipped