В Grafana я использую PromQL для запроса данных Prometheus для ElasticSearch о количестве документов. Я хотел бы изобразить график потребления документов, чтобы я мог видеть, в какое время дня ElasticSearch зашкаливает или прекращает потребление.
Я играю с временным диапазоном (10 м против 60 м), чтобы создать два разных графика, как показано ниже. Я ожидал бы, что скорость приема документов будет одинаковой в любой момент времени для обоих запросов, но ясно, что это не так (см. Графики ниже - скачок заканчивается в разное время).
Мои вопросы:
- Почему всплеск заканчивается в разное время для двух разных запросов?
- Как определить, что происходит в определенный момент в реальном времени с принятием моего документа?
- Правильны ли приведенные ниже запросы?
- Можете ли вы предложить лучший запрос?
GRAPH 1
Используемый запрос: sum (rate (asticsearch_indices_docs_total {cluster = ~ "asticsearch)-dev ", index = ~" containerlogs-dev. * "} [10m]))
GRAPH 2
Используемый запрос: sum (rate (asticsearch_indices_docs_total {cluster = ~ "asticsearch-dev ", index = ~" containerlogs-dev. * "} [60m]))
Обратите внимание на разницу - GRAPH1 в 10:51, но GRAPH2 в 11:40. Разница между запросами заключается во временном интервале, т.е. 10 м против 60 м
Полезные примечания:
Из документов Promql
rate()
rate(v range-vector) calculates the per-second average rate of increase of the time series in the range vector. Breaks in monotonicity (such as counter resets due to target restarts) are automatically adjusted for. Also, the calculation extrapolates to the ends of the time range, allowing for missed scrapes or imperfect alignment of scrape cycles with the range's time period.
The following example expression returns the per-second rate of HTTP requests as measured over the last 5 minutes, per time series in the range vector:
rate(http_requests_total{job="api-server"}[5m])
rate should only be used with counters. It is best suited for alerting, and for graphing of slow-moving counters.
Note that when combining rate() with an aggregation operator (e.g. sum()) or a function aggregating over time (any function ending in _over_time), always take a rate() first, then aggregate. Otherwise rate() cannot detect counter resets when your target restarts.