Привет.
Мы постоянно улучшаем систему и что-то из статьи устаревает :)
При учёте шести недель это был редкий кейс, сейчас мы стали брать в обучающую выборку больше 6 недель, чем ближе неделя к текущему дню, тем выше её вес.
Класс! Спасибо.
Что-то мне подсказывает, что у вас тут опечатка:
«Другими словами, в бесконечной серии попыток вероятность никогда не вытащить чёрный мяч равна 0»
Не 0, а 1.
Или я ошибаюсь?
Я бы сказал так, что операционные показатели серверов этим методом мониторить плохо (это моё мнение, возможно я что-то не знаю). К примеру, даже на вашем графике по памяти, если будет плавный рост без провалов, то система не будет алярмить, но память закончится :(. Я бы предложил поиграться с обучающими данными, к примеру, брать значения за день, 2, 3 и т.д. в этот момент времени (также можно добавить соседние значения).
Из операционных показателей серверов, наверное, можно анализировать так трафик.
Лучше всего таким образом анализировать бизнес метрики.
Мы анализируем пятиминутные данные, сервис работает в 20 потоков (ядер на машине 24), в данный момент анализируем порядка 160000 числовых последовательностей.
Данные по разным таблицам приходят и анализируются асинхронно, так что памяти используется мало.
Вопрос не совсем по теме.
1) 132T сжатых данных на всю историю на 3х2 hdfs-машинах (+3х1 namenodes) + 2x3 — бекап = 15 HDFS
12.6T несжатых hot данных (за последний месяц) на 3x7 машинах = 21
180T несжатых cold данных (за последние 2 года) на 3х6 машинах = 18
=192.6T на 3х13 = 39 машин
+3x3 brokers
+3х12 realtime
+3х1 coordinator
+3x1 newsql
+3x2 tarantool-memcached cache
=3x19 = 57 машин
=324.6T на 3х37 = 111 машин
+63 временные под миграцию.
2) realtime ноды выкачивают данные из самописанных лог буферных баз (собирающих данные непосредственно с приложений) самописным загрузчиком
3) Не особо, периодически мы смотрим тренды и определяемся сколько добавить железа, в основном это нужно для hot, cold и hdfs, расширяем дисковое пространство. Пока, за 2 года, кроме дисков ничего не наращивали.
4) Без трудностей не бывает:
Сложно искать проблемы из-за большого количества нод. Пришлость сделать централизованную консоль, куда сваливаются все ошибки и самодиагностика (которую сами же и сделали).
Пофикшено много узких мест по производительности (в запросах, в индексации), много впилено параллельной обработки.
Пришлось много фиксить по нашим HA-требованиям: в каждом ДЦ должна быть копия данных, потеря одного ДЦ целиком не влияет на работоспособность, выход/вывод машины из строя не должен вызывать переезд данных на другие машины (предполагается что машину починят и вернут), HDFS пришлось «починить» для репликации данных по более 2 ДЦ. mysql был заменен на наш newsql (кассандра) для RF=3. memcached заменен на tarantool-memcached и допилен RF=3 и read-repair для кеша.
Конфигурация realtime на файлах => сделали полу-динамическую конфигурацию, по-прежнему на файлах, но они генерятся из системы управления конфигурацией приложений (PMS) и раскидываются по всем realtime.
Практически полностью статическая конфигурация => мы прицепили нашу систему управления конфигурацией приложений (PMS) и сделали много параметров динамическими (в основном это нужно для экспериментов, решения инцедентов, и создания/перенастройки DSN).
5) Рассматривали несколько вариантов, в том числи druid и «что-то своё». Все, кроме двух последних, были отброшены как не отвечающие требованиям по HA или они вообще не были похожи на production систему (честно говоря, уже и не помним названия остальных вариантов). В итоге выбрали druid.
На данный момент мы не планируем открывать исходники. Но этот вопрос мы слышим очень часто, поэтому задумались об этом. Если это произойдёт, то не в ближайшие пол года.
Да, мы действительно описали кухню Одноклассников. Смотрите, в данном случаи нам не нужно детектить аномалии, нам нужно показывать тренды, а с этим хорошо справляется линейный прогноз. Да, это может выглядеть очень примитивно, но в данном случае нет смысла применять какой-то суперсложный алгоритм.
То, что вы советуете, у нас работает в другом месте — на оперативном мониторинге бизнес-логики портала (как будет время напишу про эту систему), там происходит анализ около 100 000 графиков в режиме реального времени.
В статье описано решение того, как мы заранее узнаём о возможных проблемах в инфраструктуре. Zabbix для этой задачи не годится, потому что он плохо работает с таким кол-вом исторических данных, мы там храним только короткий (оперативный) промежуток времени.
Хотя Zabbix у нас используется для оперативного мониторинга, причем на срабатывания какого-либо триггера автоматически создаётся инцидент в JIRA.
Мы постоянно улучшаем систему и что-то из статьи устаревает :)
При учёте шести недель это был редкий кейс, сейчас мы стали брать в обучающую выборку больше 6 недель, чем ближе неделя к текущему дню, тем выше её вес.
Что-то мне подсказывает, что у вас тут опечатка:
«Другими словами, в бесконечной серии попыток вероятность никогда не вытащить чёрный мяч равна 0»
Не 0, а 1.
Или я ошибаюсь?
Из операционных показателей серверов, наверное, можно анализировать так трафик.
Лучше всего таким образом анализировать бизнес метрики.
Данные по разным таблицам приходят и анализируются асинхронно, так что памяти используется мало.
1) 132T сжатых данных на всю историю на 3х2 hdfs-машинах (+3х1 namenodes) + 2x3 — бекап = 15 HDFS
12.6T несжатых hot данных (за последний месяц) на 3x7 машинах = 21
180T несжатых cold данных (за последние 2 года) на 3х6 машинах = 18
=192.6T на 3х13 = 39 машин
+3x3 brokers
+3х12 realtime
+3х1 coordinator
+3x1 newsql
+3x2 tarantool-memcached cache
=3x19 = 57 машин
=324.6T на 3х37 = 111 машин
+63 временные под миграцию.
2) realtime ноды выкачивают данные из самописанных лог буферных баз (собирающих данные непосредственно с приложений) самописным загрузчиком
3) Не особо, периодически мы смотрим тренды и определяемся сколько добавить железа, в основном это нужно для hot, cold и hdfs, расширяем дисковое пространство. Пока, за 2 года, кроме дисков ничего не наращивали.
4) Без трудностей не бывает:
Сложно искать проблемы из-за большого количества нод. Пришлость сделать централизованную консоль, куда сваливаются все ошибки и самодиагностика (которую сами же и сделали).
Пофикшено много узких мест по производительности (в запросах, в индексации), много впилено параллельной обработки.
Пришлось много фиксить по нашим HA-требованиям: в каждом ДЦ должна быть копия данных, потеря одного ДЦ целиком не влияет на работоспособность, выход/вывод машины из строя не должен вызывать переезд данных на другие машины (предполагается что машину починят и вернут), HDFS пришлось «починить» для репликации данных по более 2 ДЦ. mysql был заменен на наш newsql (кассандра) для RF=3. memcached заменен на tarantool-memcached и допилен RF=3 и read-repair для кеша.
Конфигурация realtime на файлах => сделали полу-динамическую конфигурацию, по-прежнему на файлах, но они генерятся из системы управления конфигурацией приложений (PMS) и раскидываются по всем realtime.
Практически полностью статическая конфигурация => мы прицепили нашу систему управления конфигурацией приложений (PMS) и сделали много параметров динамическими (в основном это нужно для экспериментов, решения инцедентов, и создания/перенастройки DSN).
5) Рассматривали несколько вариантов, в том числи druid и «что-то своё». Все, кроме двух последних, были отброшены как не отвечающие требованиям по HA или они вообще не были похожи на production систему (честно говоря, уже и не помним названия остальных вариантов). В итоге выбрали druid.
То, что вы советуете, у нас работает в другом месте — на оперативном мониторинге бизнес-логики портала (как будет время напишу про эту систему), там происходит анализ около 100 000 графиков в режиме реального времени.
Хотя Zabbix у нас используется для оперативного мониторинга, причем на срабатывания какого-либо триггера автоматически создаётся инцидент в JIRA.
Работает вот так: return x(1-x)