мониторинг

Я тут сегодня вот чего посмотрел на муниновский эвераджах - там есть наборы колебаний параметра, отображающего качество работы системы. Когда колебания совпадают они могут вызвать резонанс при достижении суммарного воздействия (суммы амплитуд) некоторого порогового значения.

Дык вот - очень интересно понаходить все эти колебания и эти пороговые значения. Колебания должны быть объяснены - увязаны, хотя бы статичтически, с изменениями внешних параметров. Если получится указать механизм привязки - то задача решена чисто - по критериям древних греков. Внешние параметры системы тоже могут иметь несколько колебаний - суточная, недельная, месячная активность пользователей. Их можно выделять и рассматривать отдельно. Поскольку они свято соблюдают принцип суперпозиции. С учетом пороговости конечно же - если дневной прирост нагрузки и пятничный наплыв жаждущих отдыха по отдельности забивают канал в два раза каждый, то вместе они его могут положить наглухо.

Это то, от чего всегда предостерегают простыми числами в таймаутах и интервалах. Но они не спасут от набегания часовых волн кронджобов на суточную волну активности пользователей.

В каком-то смысле весь набор таких зависимостей - и есть набор проблем проекта. Структурная схема происхождения пиздеца на проекте. Это когда резонанс колебаний превышает какой-нибудь порог. Вот и схема распространения проблем.

Я очень-очень хотел бы иметь такую под рукой. И привязать ее к дереву деплоя на проекте. Дерево деплоя - почти как дерево комитов продакшн-ветки, только со сдвинутыми точками. И с добавлением не-кодовых операций - смены версии исполдьзуемых интерпретаторов, ввода в строй новых элементов системы, дополнительных значимых модификаций системы.

Параллельно наличие такой модели системы позволит проводить предсказания на тему того, как поведет себя система в тех или иных случаях. Но даже в сыром виде она позволит уже видеть "бутылочные горлышки". И укажет на зависимость порогов друг от друга. И даст методику рассчета предельных значений внешних колебаний, основываясь на имеющихся в системе порогах.

Додумать: Самое смешное то, что похожую модель можно получить переписав спарк с "чистым функциональным подходом". В итоге у нас будут монадные цепочки. Из которых некоторые основные, они исходят из бизнес-логики:

• по регистрации клиента мы создаем imap2apn-соединение и удерживаем его пока клиент не отменит это действие. Дополнительно клиент управляет одним из фильров в этом туннеле и получает 2 типа нотификаций - о письме и о смене бейджа. Помимо имапа поддерживается ews
• клиент в рамках imap2apn туннеля (зачем блядь???) может отправить письмо и интересуется результатами отправки
• нотификейшн - по запросу клиента или при отправке мы создаем еще один туннель view2apn с накоплением данных для отдачи по запросу клиента

Явно можно заметить что туннели могут быть сращены так, что самый интересный imap2apn получится

• по получению письма из imap или ews мы его прогоняем через послоедовательность фильтров и модифицируем его в пуш;
• тут разрыв, поскольку количество пушей и количество писем несовпадают by design;
• пуш прогоняется через ENQL - единственный фильтр на этом участке. при его непрохождении дальше летит только бейдж, не письмо.
• здесь разрыв потому что сюда входит поток пушей других типов - бейдж и counter
• пуши прогоняется через общие фильры и модификаторы и отправляется в apns
• система логгирования, мониторинга и саппорта

И пороги здесь только одни - пропускная способность каналов, равная пропускной способности самого медленного элемента. Который можно распараллелить, даже по сети.

Все! На этом текущая бизнес-логика спарка заканчивается и начинается адовый, леденящий душу пиздец, созданный нами. База. Очереди. Расчленение на несколько серверов по не до конца формализованным критериям. Монадовое описание реальных процессов просто убивает любой разум. А уж скока там багов!

А уж какая задержка в исполнении! Здесь же будут оптимизации типа: бейдж нужно устанавливать после проверки ENQL, чтобы лишнюю операцию присваивания не сделать. И иф лишний уберется на пути данных. Чувствуете, мы экономим такты процессора. И это позволит нам обрабатывать значительное количество писем быстрее, за десятки милисекунд. А не секунды как сейчас. Предсказуемо, с внутренними очередями выполнения с известными пропускными способностями. Рассчитать количество необходимой для хранения enql в скомпилированоом и нескомпилированном виде - функцией или текстом. Может сжать его как-то или оптимизировать? Сгруппировать по хостам?

Получить интервал колебания временной числовой величины можно путем двоичного преобразования Фурье над потоком входных данных. Единичка получится на той позиции в байте равной длину периода колебаний в тактах, гармоника которых присутствует в исходной послоедовательности чисел. Там по котельникову должен быть конечный предел такой последовательности джля восстанорвления с конечной точностью (помехой, ограниченной по значению сверху)

Механизм двоичного преобразования Фурье: преобразование ряда в числовую последовательность следующего вида. 0-й член: среднее значение по последовательности;1-й рассчитывается как среднее 1-й половины минус среднее 2-й половины. Размах, две амплитуды, минус 0-й; n-й как в общем случае как среднее всех разностей при разбитии последовательности на 2^n частей.

Необходимо искать последовательности, порождающие сами себя циклично. через раз, например. как электромагнитные поля, как материальные кварки и изгиб пространства. А у преобразования Коши правильного, не двоичного, все последовательности будут такие. Значит правильная функция обладает более широкой кормовой базой.

Там что-то о пределе Коши как условии сходимости ряда. Кста! Для нашего случая сходимость в результате преобразования говорит о конечном спектре для бесконечной последовательности.

В теории эволюции вообще сходимость исторического ряда параметров эволюционирующего элемента говорит об однократном возмущении и постпепенном сглаживании рассматриваемого параметра. Метод отжига для избегания локальных минимумов оптимизации.

Для спарка:

• события: деплой, новый инстанс фишер/воркер, смена типов таблиц в БД, обновление пакетов на серверах;
• внешние колебания - количество писем с суточным, часовым и недельным колебаниями, количество запросов с дневным и недельным колебанием;

TODO: вспомнить что такое преобразование Коши. Выше везде в виду имелось преобразование Фурье.