fixup! [core] add docs for metrics

Author: Michal Tichák

docs/metrics.md

@@ -151,19 +151,22 @@ by appending strings to the name of original field:
 
 ### Aggregation
 
-In order to save network bandwidth and RAM usage we are aggregating all metrics.
-This aggregation is done by grouping metrics per second intervals based on timestamps
-rounded to seconds, measurement name and tags. This aggregating is the same of both
-types of metrics. This means that if you send metrics with
-same measurement name and tags, but different timestamps (unix in nanoseconds)
-but difference under one second all of them will be aggregated into
-one bucket, where timestamp is rounded down at seconds.
-If either measurement or tags are different, than the metrics
-wont' be grouped but every one of these metrics will be separate. If metric
-is missing one of the tags compared to the other metrics it won't be aggregated
-with the others. Following example describes aggregating different metrics.
-Metrics in influxdb line format will be used to demonstrate aggregation
-of simple Counter metrics.
+To reduce network bandwidth and RAM usage, we aggregate all metrics.
+This is done by grouping them into one-second intervals based on:
+
+- Timestamps rounded down to the nearest second
+- Measurement name
+- Tags
+
+This aggregation method applies to all metric types.
+
+If multiple metrics share the same measurement name and tags but have timestamps
+less than one second apart, they will be grouped into a single bucket, using the
+timestamp rounded down to the nearest second.
+
+However, if the measurement name or tags differ—even slightly—the metrics
+will not be grouped and will remain separate. Also, if a metric is missing
+a tag present in the others, it won't be aggregated with them.
 
 ```
 notaggregated,tag1=val1 fields1=1i 1000000123
@@ -203,7 +206,7 @@ In order to send metrics from unlimited amount of goroutines, we need to have
 robust and thread-safe mechanism. It is implemented in [common/monitoring/monitoring.go](../common/monitoring/monitoring.go)
 as event loop (`eventLoop`) that reads data from two buffered channels (`metricsChannel` and `metricsHistosChannel`)
 with one goroutine. Apart from reading messages from these two channels event loop also handles
-scraping requests from `http.Server` endpoint. As the http endpoint is called
+scraping requests from `http.Server` endpoint. As the http endpoint is called by a
 different goroutine than the one processing event loop, we use another two channels:
 `metricsRequestedChannel` which is used by the endpoint to request current metrics.
 Transformed metrics are sent via `metricsExportedToRequest` back to the endpoint.