При использовании UDP в качестве транспорта для событий есть одна мелочь, на которую я нарывался. Протокол syslog предполагает необязательность поля TIMESTAMP. В этом случае метку времени обычно проставляет принимающая сторона, но UDP может задержаться в пути и так как никакого контроля очередности (как в TCP) нет, то пакеты обработаются в другом порядке, что может сильно осложнить исследование логов. Поэтому приложение должно проставлять таймстамп при генерации события, а принимающая сторона не должна эти стампы игнорить (а есть соблазн так сделать, чтоб синхронизировать логи от разных источников). Оригинальный код libc проставляет время, но сторонние реализации могут на это забить, а зря.
Вообще со временем в syslog засада. Поле таймстамп это просто текст. В этот текст должно вставляться смещение относительно GMT. Но на деле эта информация бывай кем-нибудь да дропится (особенно в собственных костылях), и в результирующий текстовый лог попадает локальное время клиента не пересчитаное во время принимающей стороны. Если у вас куча серверов работает в разных таймозонах тут вам придется походить по граблям. Ну или перевести все сервера в GMT (не всегда возможно, к сожалению).
Многие банки такую услугу предоставляют: карта, которой можно пользоваться только для онлайн платежей. Стоит обычно около 1 доллара в месяц, а то и бесплатно, если вы привилегированный клиент. Закидываете на эту карту ровно 20 долларов, в минус на ней нельзя уйти (впрочем читайте мануал вашего банка, мало ли что). Ну а пополнение онлайн с другой карты или счета в том же аккаунте это дело нескольких минут.
Я к тому, что ваша проблема с каскадным отказом возможно решалась не написанием "собственного syslog по UDP", а просто переключением связи между главным демоном цода и демоном машины в UDP режим. Да, вы бы теряли логи, но не теряли стабильность. Честно говоря я ни разу не видел случая, что кто-нибудь включал TCP на передачу syslog в сети.
Я правильно понял, что между локальными для физической машины rsyslog демоном и центральным демоном ЦОДа у вас был TCP? Ведь протокол syslog изначально подразумевает UDP.
Я видел этот запрос на официальном форуме некоторое время назад и допускаю, что это совсем не кому не нужно, но все же продублирую здесь. Нельзя ли кнопку управления кешем картинок привязать к домену, чтоб сохранять состояние (на одном сайте картинки выключены, на другом закешированы).
Ну или как минимум сделать настраиваемым дефолтное положение этой кнопки (я бы выставил везде в кеш)?
Это относительно понятный код. Хотя весьма любопытно что там под капотом. Я так понимаю, что на уровне машинных кодов мы здесь просто обновляем значения в стеке.
Несколько раз пытался разобраться в Erlang/OTP и кроме недостатка литературы, о котором сказано в статье, натыкался на то, что я совсем не понимаю, как работать с состояниями и вводом-выводом (допускаю, что я просто глуп).
По какой-то причине большинство статей о функциональных языках описывают разнообразные простые понятия: чистые функции, рекурсия, частичное применение, каррирование и так далее. В лучшем случае, про Erlang напишут как использовать gen_server. Все это любопытно, но не является чем-то действительно необычным или сложным для человека, который писал на современных языках.
А вот как правильно хранить состояние, когда оно реально необходимо? Знаю есть несколько способов, но какой лучше и в каких условиях? Может лучше вообще всегда отдавать состояние на сторону (в Redis, например)? Или как платформа переваривает обращение к «грязным» функциям из модуля file? Это же невозможно (точнее не гарантирован корректный результат) в чистом функциональном языке, значит есть какой-то обходной путь? Я нашел всего несколько статей на эту тему, они были полезны, но я по-прежнему не могу сказать, что эта тема стала мне понятна.
Вообще со временем в syslog засада. Поле таймстамп это просто текст. В этот текст должно вставляться смещение относительно GMT. Но на деле эта информация бывай кем-нибудь да дропится (особенно в собственных костылях), и в результирующий текстовый лог попадает локальное время клиента не пересчитаное во время принимающей стороны. Если у вас куча серверов работает в разных таймозонах тут вам придется походить по граблям. Ну или перевести все сервера в GMT (не всегда возможно, к сожалению).
Ну или как минимум сделать настраиваемым дефолтное положение этой кнопки (я бы выставил везде в кеш)?
В смысле возврат функции с новым состоянием? Что-то типа:
Это относительно понятный код. Хотя весьма любопытно что там под капотом. Я так понимаю, что на уровне машинных кодов мы здесь просто обновляем значения в стеке.
По какой-то причине большинство статей о функциональных языках описывают разнообразные простые понятия: чистые функции, рекурсия, частичное применение, каррирование и так далее. В лучшем случае, про Erlang напишут как использовать gen_server. Все это любопытно, но не является чем-то действительно необычным или сложным для человека, который писал на современных языках.
А вот как правильно хранить состояние, когда оно реально необходимо? Знаю есть несколько способов, но какой лучше и в каких условиях? Может лучше вообще всегда отдавать состояние на сторону (в Redis, например)? Или как платформа переваривает обращение к «грязным» функциям из модуля file? Это же невозможно (точнее не гарантирован корректный результат) в чистом функциональном языке, значит есть какой-то обходной путь? Я нашел всего несколько статей на эту тему, они были полезны, но я по-прежнему не могу сказать, что эта тема стала мне понятна.