Все ведь сильно упрощается, если в файл пишет ровно один писатель. И если после переименования в cat.log.old появился cat.log, то в cat.log.old уже никто не пишет.
Если после первой полосы появились мутанты, резистивные к антибиотику, то почему последующие полосы вообще являлись каким-либо препятствием для этого мутанта?
На данном этапе основной компилятор для Go меня устраивает. Лучшего ответа у меня нет.
Основной компилятор на то и основной. Вся разработка идет в нем. А Gccgo — это так, развлечение Ян-а, по моему мнению.
Мы так не делали и не делаем. Для tail заходим на конкретный сервер.
Но я предполагаю что такое делать нужно не в ELK, а до него. Транспорт должен такое поддерживать.
Эта проблема была решена чуть по-другому. Наши администраторы настроили очереди в rsyslog правильно. До какого-то момента они в памяти, потом на диске, а потом новые сообщения выкидываются.
Ваши замечания абсолютно верны, если строить всю инфраструктуру с нуля и у вас нет большого кол-ва уже существующих и работающих сервисов.
Когда вам нужно сделать что-то на летящем самолете, большую роль играет кол-во изменений которое придется сделать для достижения устраивающего всех результата.
Парни, ну это же азы...
Конечно азы. Но вы будете удивлены сколько разных подводных камней зарыто в libc. Выделение памяти в snprintf, если вы используете %f или блокировки для получения таймзоны в localtime_r(). Или как у нас, блокирующая запись в syslog(). Такие вещи не лежат на поверхности. Легко говорить "ну что же вы так" постфактум.
Скорее всего и сейчас между rsyslog-ами и сейчас идет tcp. На 100% не уверен. Возможно banuchka ответит.
UDP у нас только от сервиса к rsyslogd. Не потому что нам там так нужны свойства UDP или не нужен оверхед TCP, а потому что посылку по UDP проще сделать асинхронной.
У нас в Си отделе есть такие ситуации. Не так много, но есть. К примеру один узел кластера какого-либо сервиса может что-то спросить у другого узла или у под-сервиса. Но того, о чем вы говорите, у нас нет. Т.е. посмотреть что где тормозило можно только в большом масштабе, не по конкретному изначальному запросу. Но фича была бы классной, я согласен.
Пока что стектрейсы не идут в syslog. В обозримом будущем мы или сделаем запись стректрейсов в виде одной строки или будем препроцессить их перед записью в сислог.
Основной компилятор на то и основной. Вся разработка идет в нем. А Gccgo — это так, развлечение Ян-а, по моему мнению.
Большой такой камень в огород :-)
Но я предполагаю что такое делать нужно не в ELK, а до него. Транспорт должен такое поддерживать.
Не согласен.
У нас не допускаются такие вещи.
Когда вам нужно сделать что-то на летящем самолете, большую роль играет кол-во изменений которое придется сделать для достижения устраивающего всех результата.
Конечно азы. Но вы будете удивлены сколько разных подводных камней зарыто в libc. Выделение памяти в snprintf, если вы используете %f или блокировки для получения таймзоны в localtime_r(). Или как у нас, блокирующая запись в syslog(). Такие вещи не лежат на поверхности. Легко говорить "ну что же вы так" постфактум.
UDP у нас только от сервиса к rsyslogd. Не потому что нам там так нужны свойства UDP или не нужен оверхед TCP, а потому что посылку по UDP проще сделать асинхронной.