Комментарии 10
А это нормально что Promtail за localhost в google DNS пошел? Вроде у меня больше никто так не делает и все корректно настроено.
Небольшой лог на 15 тыс строк с внутреннего портала. 7 лейблов.
error="server returned HTTP status 429 Too Many Requests (429): Maximum active stream limit exceeded, reduce the number of active streams (reduce labels or reduce label values), or contact your Loki administrator to see if the limit can be increased, user: 'fake'"
чего-то как-то быстро оно сдохло :-(
Это тоже странно. Для тестов (чтоб не тащить логи с рабочего окружения ибо NDA) я написал бредо логогенератор, там типичная конфигурация была 100 строк в секунду и работало все без проблем.
Теперь по существу. Постановка диагноза по интернету задача сложная, но попробуйте поиграться с настройками. Для промтейла попробуйте включить profiling_enabled: и log_level:, возможно станет ясно в чем проблема.
Еще можно поменять вот это
# Maximum amount of time to wait before sending a batch, even if that # batch isn't full. [batchwait: <duration> | default = 1s]
и/или это
# Maximum batch size (in bytes) of logs to accumulate before sending # the batch to Loki. [batchsize: <int> | default = 1048576]
Еще есть целая секция в кофиге limits_config, но вообще говоря 15 тыщ строк должно прожевать и не заметить.
Еще по 429 ошибке. Совет что делать есть в самом сообщении "reduce labels or reduce label values", меток у вас 7 штук, значит слишком много разных значений. Поэтому прикиньте сколько у каких меток значений и убирайте по одной через - labeldrop: в конфиге.
С метками ситуация в некотором роде обратная индексу в базе данных. Если для СУБД чем больше разных значений в индексе, тем лучше (я знаю что есть разные типы индексов, но тут про "обычный"), то здесь все наоборот. Меньше разных значений у меток - лучше производительность.
Также в конфиге есть настройка для числа active streams
limits_config: max_global_streams_per_user: 10000
Но ИМХО лучше разобраться с метками.
Скорее всего, дело в количестве значений лейблов. Значения лейблов не должны быть high-cardinality. Потому что в Prometheus на каждый их набор будет создана отдельная time series (а-ля "таблица"). Из официальной документации:
The change of any labels value, including adding or removing labels, will create a new time series.
Еще вопросик - есть лог с датами вот такого вида:
2023-11-17 15:29:01+00:00
вроде RFC3339 только с пробелом вместо Т
ее надо как-то дополнительно преобразовывать в timestamp? В лоб не распознается...
format: "2006-01-02 15:04:05Z07:00"
сам и уговорил...
Еще вопросик - есть лог с датами вот такого вида:
2023-11-17 15:29:01+00:00
Весь стек написан на Go и где-то в недрах там вызывается гошная функция time.Parse, поэтому для отработки парсинга датовремени заходите на любой Go playground и запускаете вот такой код
package main
import (
"fmt"
"time"
)
// date time format layout
const YYYYMMDD = "2006-01-02 15:04:05-07:00"
func main() {
s := "2023-11-17 15:29:01+01:00"
t, err := time.Parse(YYYYMMDD, s)
if err != nil {
fmt.Println("apoj")
}
fmt.Println(t)
}формат для парсинга дат и времени в go на мой взгляд какой-то странный, вот шпаргалка с описанием. Для вашего формата должно подойти вот это const YYYYMMDD = "2006-01-02 15:04:05-07:00"
Делаем дашборд для логов используя Promtail Loki Grafana