Some random GrafanCon EU 2k18 Notes – Telegram
Some random GrafanCon EU 2k18 Notes
73 subscribers
312 photos
9 files
54 links
Заметки по докладам на которые я пошел (начинаются с #talk) и флуд фоточками.

Связаться с автором можно так: @Civiloid
Download Telegram
Мы захотели проверить каковы же плюсы и минусы каждого варианта
для этого провели мысленный эксперимент - написали программу, которая эмулирует падение серверов и замеряет разные параметры
И вот что мы тут получилиН
Первый график это колличество потерянных данных в худшем случаи, в процентах.
Худший случай для replication factor 1 - потеря сервера с тем же набором метрик
Как можно заметить, для rf1 она максимальна
для replication factor 2 - минимально
А теперь давайте посмотрим на вероятности потери данных
Как можно видеть, в случаи Replication factor 2 мы будем терять данные при падении любых двух серверов
А на 5-и серверах мы будем терять данные во всех случаях
replication factor 1 же наоборот, имеет хорошие шансы пережить падение двух сервера и даже в общем трех из 8 без потерь
И мы решили что доступность данных для пользователей нам важнее
Поэтому перешли на replication factor 1
Собственно что мы имеем сейчас?
- 32 фронтэнд сервера
- nginx на фронтэнде получает 200 RPS
- Это выливается в 30000 чтений метрик (в секунду конечно)
- Трафик в процессе записи примерно 11 Гбит в секунду.
- У нас более 200 стораджей в двух ДЦ
- Мы получаем 2 миллиона уникальных метрик в секунду (с учетом репликации получается все 8 на хранение)
- Общий объем виспер-файлов - 130 ТБ
- Мы переписали почти весь графит, кроме carbon-cache'а. Да, мы все еще используем виспер
И у нас есть планы по тому что с этим всем делать
- Поиск с учетом метаданных. Внутри букинга есть команда, которая сейчас этим занимается. Они хотят при сохранении полной совместимости добавить возможность выборки данных по запросам вида "Дай мне все сервера такой роли в статусе live"
- Решить проблему с кэшом. К сожалению в процессе создания zipper stack'а мы потеряли возможность чтения данных из памяти carbon-cache. Для нас это не проблема, мы из-за ошибки конфигурации не могли этого делать никогда, но сейчас вопрос встает более остро. Люди начали делать мониторинг по графитным данным и если для графиков задержка в 3-4 точки допустима, то для мониторинга уже нет.