Jan Novotný

We'we been recommended by Láďa Prskavec to stick to Prometheus metrics and don't use OTEL for database monitoring purposes. The recommendation was: - expose metrics via Prometheus endpoint - log...

Very minimal set of metrics published at: http://demo.evitadb.io:5557/observability/metrics ... when we get the prototype up and running, we'll expand the metrics list according to the set defined in the issue...

We probably don't need to suffix metrics with type - it's visible in the metrics as comment: ``` # HELP io_evitadb_core_metric_event_query_plan_step_executed_event_timegauge Time taken # TYPE io_evitadb_core_metric_event_query_plan_step_executed_event_timegauge gauge io_evitadb_core_metric_event_query_plan_step_executed_event_timegauge 72500.0 ```

Initial version of metrics is done and released in `2024.7` release:  The issue won't be closed since there are still some metrics missing and also we need to properly...

Most of the metrics is done by now. We have also pretty looking dashboard in Grafana that's getting useful. I postpone closing this issue to be finalized later. We still...

Hi @trustin - we're really positively surprised by your attitude and thank you very much for the support. The problem is currently on our side - we had to lower...

Only single step remaining - remeasuring in performance tests.

Migration to Armeria server merged to `dev` branch (canary). It will be base for `2024.10`

@lho the logic is prepared in method `io.evitadb.api.requestResponse.data.PricesContract#getPriceForSaleWithAccompanyingPrices` including basic tests. Please: - [ ] add the logic to GraphQL API - [ ] consider relevant support also in REST...

This issue changes behaviour of `allPricesForSale` and breaks backward compatibility for someone who relied on flawed implementation logic. Now the method mimics the calculation and behavior of `priceForSale`, which is...