Если первый пример еще читаемый и делает его читаемым то что массивы имеют схожий функционал, а не использование монад, то второй имхо не читаемый вообще.
Я лично еще не встретил не одного явного плюса в использовании всего этого, кроме пожалуй выучить еще один подход, но для написания чистый функций не обязательно использовать монады(в вашем случае хватит static методов на классах(потому что без typescript это без ошибок не написать) или просто передавать аргументы в функции все зависит от проекта
Спасибо большое за идею, я совершенно про такое забыл, я добавлю в поля optional параметр который будет лестинца с приоритетом(первый который не пустой будет выбран) Понимаю не все это решит в коде все таки легче условия описать, но чуток упростит
У нас есть один постоянный клиент(который использует уже в течение года), но с остальными ничего не получилось, демку мы переводим на новый домен, скоро будет
В нашей реализации они не нужны, вы можете написать правила с многими map/reduce функциями поэтому нам группы не нужны, плюс так же есть временные функции такие как n измерений подарят итд.
Ну мое мнение система мониторинга служит для того чтобы добавить устойчивость системе, и чем больше задач она решает тем лучше, по факту принципе не важно что как и что сделал. Главное чтоб она улучшала время реакции на инциденты. Мы когда начинали писать тоже думали по факту все можно сделать прикрутив уже готов, но тем не менее с момента первой строчки кода я уже 3 новых видел. Мне кажется причин несколько:
1. Кусочничество (большинство делают солянку из нескольких, но качество получается разное)
2. Комплексы NewRelic/sentry платные
3. Ограниченность функционала, поскольку комплексы почти все закрытые, то все ищут новые куски(маленькие системы с интеграцией к большой).
Вот эти задачи мы и пытаемся решить, open-source потому что мы пишешь большой комплекс, в котором стараемся покрыть все, но пока понемножку, но open-source в теории дает коммьюнити развивать. Self-host — никто не должен хранить ваши внутренние данные, даже о инфраструктуре(а без исходного кода понять что он собирает не слишком легко), я так считаю.
Ложные срабатывания будут всегда, но чем правильнее ты можешь описать инциденты тем меньше их будет, допустим нагрузка на ЦП за последние 7 подряд измерений 80% плюс, допустим выросло количество памяти
Добавил такую возможность в инструмент
Если первый пример еще читаемый и делает его читаемым то что массивы имеют схожий функционал, а не использование монад, то второй имхо не читаемый вообще.
Я лично еще не встретил не одного явного плюса в использовании всего этого, кроме пожалуй выучить еще один подход, но для написания чистый функций не обязательно использовать монады(в вашем случае хватит static методов на классах(потому что без typescript это без ошибок не написать) или просто передавать аргументы в функции все зависит от проекта
Ну тоесть таких абстракций много, я больше пока склоняюсь к jsonnet, для более юзабельной конфигурации
Спасибо большое, это принципе очень похоже на YAML который уже поддерживается(я больше говорил про сложность понимания вариантов, чем про размер)
Ну и у вас опущена, ну и они не совместимы в вашем случае это подошло бы для запуска бинарника Firefox, а в нашем случае Firefox как часть playwright
Но все таки я имел ввиду понимание его неделе размер(согласен чем меньше размер легче понять, попозже перепишу на yaml)
Спасибо большое за идею, я совершенно про такое забыл, я добавлю в поля optional параметр который будет лестинца с приоритетом(первый который не пустой будет выбран)
Понимаю не все это решит в коде все таки легче условия описать, но чуток упростит
По статистикe рабочии блоги читают в середину дня в среду :)
У нас есть один постоянный клиент(который использует уже в течение года), но с остальными ничего не получилось, демку мы переводим на новый домен, скоро будет
В нашей реализации они не нужны, вы можете написать правила с многими map/reduce функциями поэтому нам группы не нужны, плюс так же есть временные функции такие как n измерений подарят итд.
Но то что сентри не комплекс, да datatog комплекс тогда уж. Думаю суть понятно
1. Кусочничество (большинство делают солянку из нескольких, но качество получается разное)
2. Комплексы NewRelic/sentry платные
3. Ограниченность функционала, поскольку комплексы почти все закрытые, то все ищут новые куски(маленькие системы с интеграцией к большой).
Вот эти задачи мы и пытаемся решить, open-source потому что мы пишешь большой комплекс, в котором стараемся покрыть все, но пока понемножку, но open-source в теории дает коммьюнити развивать. Self-host — никто не должен хранить ваши внутренние данные, даже о инфраструктуре(а без исходного кода понять что он собирает не слишком легко), я так считаю.
Ложные срабатывания будут всегда, но чем правильнее ты можешь описать инциденты тем меньше их будет, допустим нагрузка на ЦП за последние 7 подряд измерений 80% плюс, допустим выросло количество памяти
Спасибо за отзыв, да у нас будет возможность создавать плагины; да у нас это ближайших планах
www.zabbix.com/documentation/current/ru/manual/acknowledges — где тут инциденты? тут. ложных срабатываний будет очень много, по факту у вас допустим загрузка CPU 80%, но почему это вдруг инцидент
www.zabbix.com/documentation/current/ru/manual/config/notifications — с ними согласен проглядел.
Мониторинг приложений в нашей понимании: resource usage + transaction + metric + tracing
Zabbix покрывает только агентов и external/internal чеки, нет мониторинга приложений, нет инцидентов, уведомлений, мониторинга web приложений