Комментарии 7
После пары неудачных попыток мы остались на готовом образе от разработчиков Promscale.
Не уловил из статьи, каким образом обеспечивается высокая доступность сервиса хранилища, можете пояснить?
у нас несколько геораспределённых реплик, которые мы мониторим и, в случае чего, мы на них переключаемся. С другой стороны, если мастер баз не доступен, то запись не происходит и данные копятся на источнике. Как только появится возможность произвести запись — данные доедут в базу. В дальнейшем мы хотим уйти от ручного failover на автоматику, решение пока что готовим.
Можете поделиться ресурсами выделенными под сторадж и статистику его использования? Интересует использование cpu, ram, дискового пространства, кол-во уникальных рядов, кол-во собранных точек, скорость их вставки и средний «вес» точки в байтах, кол-во обрабатываемых запросов на чтение. Спасибо!
Посмотрел статистику. У нас используется 7% одного ядра CPU (Xeon E-2274G), 300мб оперативки и еще 2.8Гб cache памяти. На диске база занимает 36Гб. Статистика базы — порядка 40 точек в секунду, на чтение — иногда заходят коллеги за статистикой, можно считать — один запрос на чтение в секунду. У нас всего 30 рядов, собираем раз в 5 минут. Количество точек во всех метриках разное, суммарно — около миллиарда.
В остальном сложно подсчитать — при вставке ведь мы добавляем 8 байт на число (double или int64), а labels у нас неизменные и мы просто к ним привязываемся. Этот момент требует уточнения.
В остальном сложно подсчитать — при вставке ведь мы добавляем 8 байт на число (double или int64), а labels у нас неизменные и мы просто к ним привязываемся. Этот момент требует уточнения.
А почему не взяли VictoriaMetrics как хранилище и их же VM Agent для сбора метрик? Эффективность вплоть до х50 от решения на постгресе
Благодарю вас за интерес к теме!
В первую очередь выбор хранения в Postgres был продиктован желанием «начать с известного и понятного», и что немало важно — наличием экспертизы по нему у нас, пониманием как обеспечить его доступность и резервное копирование.
В ходе разработки нам так же пришло осознание, что есть более подходящие хранилища по многим пунктам (в том числе я упоминал в статье про last_over_time в VM), но делать такой лихой разворот в процессе работ, не достигнув явного результата, показалось опасным. На данный момент мы делаем шаги в сторону «ощупывания» VM в вопросах сбора метрик в наших кластерах и в какой-то момент свитчнемся либо на него (или может что-то другое) и для этой задачи.
В первую очередь выбор хранения в Postgres был продиктован желанием «начать с известного и понятного», и что немало важно — наличием экспертизы по нему у нас, пониманием как обеспечить его доступность и резервное копирование.
В ходе разработки нам так же пришло осознание, что есть более подходящие хранилища по многим пунктам (в том числе я упоминал в статье про last_over_time в VM), но делать такой лихой разворот в процессе работ, не достигнув явного результата, показалось опасным. На данный момент мы делаем шаги в сторону «ощупывания» VM в вопросах сбора метрик в наших кластерах и в какой-то момент свитчнемся либо на него (или может что-то другое) и для этой задачи.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Как мы собираем общие сведения о парке из Kubernetes-кластеров