Журналы — важная часть системы, позволяющая понять, что она работает (или не работает) как положено.
В микросервисной архитектуре работа с логами становится отдельной дисциплиной специальной олимпиады.
Необходимо решить сразу кучу вопросов:
- как писать логи из приложения;
- куда писать логи;
- как сдавать логи на хранение и обработку;
- как обрабатывать и хранить журналы.
Именно об этом и идет стенограмма доклада Юрия Бушмелева «Карта граблей в области сбора и доставки бревен».
Кому интересно, смотрите кат. Меня зовут Юрий Бушмелев.
Я работаю в Лазаде.
Сегодня я расскажу о том, как мы делали наши логи, как их собирали и что там пишем.
Откуда мы? Кто мы? Lazada — интернет-магазин №1 в шести странах Юго-Восточной Азии.
Все эти страны распределены по нашим дата-центрам.
Всего на данный момент имеется 4 дата-центра.
Почему это важно? Потому что некоторые решения были обусловлены тем, что между центрами очень слабая связь.
У нас микросервисная архитектура.
Я был удивлен, обнаружив, что у нас уже есть 80 микросервисов.
Когда я запускал задачу с логами, их было всего 20 штук.
Плюс есть довольно большой кусок PHP-наследия, с которым мне тоже приходится жить и мириться.
Все это на данный момент генерирует более 6 миллионов сообщений в минуту для системы в целом.
Дальше я покажу, как мы пытаемся с этим жить, и почему это так.
С этими 6 миллионами сообщений надо как-то жить.
Что нам с ними делать? 6 миллионов сообщений, которые вам нужны:
- отправить из приложения
- принять к доставке
- доставить на анализ и хранение.
- анализировать
- сохрани как-нибудь.
Когда появилось три миллиона сообщений, я выглядел примерно так же.
Потому что мы начали всего с нескольких копеек.
Понятно, что туда пишутся логи приложений.
Например, я не смог подключиться к базе данных, я смог подключиться к базе данных, но ничего не смог прочитать.
Но помимо этого каждый наш микросервис еще пишет журнал доступа.
Каждый запрос, поступающий в микросервис, записывается в журнал.
Зачем мы это делаем? Разработчики хотят иметь возможность отслеживать.
В каждом журнале доступа содержится поле трассировки, с помощью которого специальный интерфейс затем разматывает всю цепочку и красиво отображает трассировку.
Трассировка показывает, как прошел запрос, и это помогает нашим разработчикам быстро разобраться с любым неопознанным мусором.
Как с этим жить? Теперь кратко опишу поле возможностей — как вообще решается эта проблема.
Как решить проблему сбора, передачи и хранения логов.
Как написать из приложения? Понятно, что есть разные пути.
В частности, есть передовая практика, как говорят нам наши модные товарищи.
Есть два типа старой школы, как говорили нам наши деды.
Есть и другие способы.
Ситуация со сбором логов примерно такая же.
Вариантов решения этой конкретной части не так много.
Их уже больше, но пока не так много.
Но с доставкой и последующим анализом количество вариантов начинает стремительно расти.
Я не буду сейчас описывать каждый вариант. Думаю, основные варианты хорошо известны всем, кто интересуется темой.
Я покажу вам, как мы это сделали в Lazada и с чего все началось.
Год назад я пришел в Лазаду и меня отправили на проект про логи.
Это было что-то вроде этого.
Журнал приложения записывался на stdout и stderr. Все было сделано по моде.
Но потом разработчики выбросили это из стандартных потоков, а дальше как-нибудь инфраструктурщики разберутся.
Между инфраструктурщиками и разработчиками тоже есть релизеры, которые говорят: «эээ… ладно, давайте их просто в файл с оболочкой завернём, и всё».
А так как все это было в контейнере, то завернули прямо в сам контейнер, нанесли каталог внутрь и положили туда.
Я думаю, всем довольно очевидно, что из этого вышло.
Давайте посмотрим немного дальше.
Как мы доставили эти журналы? Кто-то выбрал td-agent, который на самом деле флюентен, но не совсем флюентд. Я до сих пор не понимаю связи между этими двумя проектами, но вроде бы они об одном и том же.
А этот fluentd, написанный на Ruby, читал логи, парсил их в JSON с какой-то закономерностью.
Затем я отправил их Кафке.
Более того, в Kafka у нас было 4 отдельные темы для каждого API. Почему 4? Потому что есть live, есть промежуточный формат, а также потому что есть stdout и stderr. Их создают разработчики, а разработчики инфраструктуры должны создавать их в Kafka. Более того, Кафку контролировало другое ведомство.
Поэтому нужно было создать тикет, чтобы по каждому апи создавали по 4 темы.
Все забыли об этом.
В общем, был треш и суета.
Что мы с этим делали дальше? Мы отправили его Кафке.
Потом половина логов из Кафки улетела в Логсташ.
Другая половина бревен была разделена.
Кто-то летал в один Грейлог, кто-то в другой Грейлог.
В результате всё это ушло в один кластер Elasticsearch. То есть весь этот бардак оказался там.
Не делай этого! 
Вот как это выглядит, если посмотреть на него сверху.
Не делай этого! Здесь проблемные места сразу отмечены цифрами.
На самом деле их больше, но 6 действительно проблемных, с которыми нужно что-то делать.
О них я сейчас расскажу отдельно.
Сюда (1,2,3) пишем файлы и соответственно здесь сразу три грабли.
Первый (1) заключается в том, что нам нужно их где-то записать.
Не всегда желательно предоставлять API возможность записи непосредственно в файл.
Желательно, чтобы API был изолирован в контейнере, а еще лучше — чтобы он был доступен только для чтения.
Я системный администратор, поэтому у меня несколько альтернативный взгляд на эти вещи.
Второй момент (2.3) — к нам в API поступает очень много запросов.
API записывает в файл много данных.
Файлы растут. Нам нужно их повернуть.
Потому что иначе вы не сможете там запастись никакими дисками.
Ротировать их плохо, потому что они производятся путем перенаправления через оболочку в каталог.
У нас нет возможности его пересмотреть.
Вы не можете указать приложению повторно открыть дескрипторы.
Потому что разработчики посмотрят на тебя как на дурака: «Какие дескрипторы? Обычно мы пишем на стандартный вывод».
Разработчики инфраструктуры превратили copytruncate в logrotate, который просто создает копию файла и транскрибирует оригинал.
Соответственно, между этими процессами копирования обычно заканчивается место на диске.
(4) В разных API у нас были разные форматы.
Они немного отличались, но регулярное выражение пришлось писать по-другому.
Так как все это контролировалось Puppet, там была большая куча классов со своими тараканами.
Плюс, большую часть времени td-agent мог съедать память, быть глупым, он мог просто делать вид, что работает, и ничего не делать.
Со стороны невозможно было понять, что он ничего не делает. В лучшем случае он упадет и его потом кто-нибудь подберет. Точнее, придет тревога, и кто-то пойдет и поднимет ее руками.
(6)А самым хламом и отходами был эластичный поиск.
Потому что это была старая версия.
Потому что у нас тогда не было преданных мастеров.
У нас были разнородные журналы, поля которых могли перекрываться.
Разные логи из разных приложений могли быть записаны с одинаковыми именами полей, но внутри могли быть разные данные.
То есть один лог приходит с целым числом в поле, например, уровень.
Другой журнал содержит строку в поле уровня.
В отсутствие статического картографирования это просто замечательная вещь.
Если после поворота индекса в elasticsearch первым приходит сообщение со строкой, то живем нормально.
Но если первое пришло от Integer, то все последующие сообщения, пришедшие от String, просто отбрасываются.
Потому что тип поля не совпадает. 
Мы начали задавать эти вопросы.
Мы решили не искать виноватых.
Но что-то нужно делать! Очевидно, что нам необходимо установить стандарты.
У нас уже были некоторые стандарты.
Мы начали немного позже.
К счастью, на тот момент уже был утвержден единый формат журналов для всех API. Это прописано непосредственно в стандартах взаимодействия сервисов.
Соответственно, желающие получать логи должны писать их в таком формате.
Если кто-то не пишет логи в таком формате, то мы ничего не гарантируем.
Далее хотелось бы создать единый стандарт методов записи, доставки и сбора логов.
Собственно, куда их писать и как доставлять.
Идеальная ситуация — когда проекты используют одну и ту же библиотеку.
Существует отдельная библиотека журналирования для Go и отдельная библиотека для PHP. Все, кто у нас есть, должны ими пользоваться.
На данный момент я бы сказал, что нам это удается на 80 процентов.
Но некоторые люди продолжают есть кактусы.
А там (на слайде) едва начинает появляться «SLA на доставку бревен».
Его пока нет, но мы над этим работаем.
Потому что очень удобно, когда в инфраструктуре написано, что если вы напишете в таком-то формате в такое-то место и не более N сообщений в секунду, то мы, скорее всего, доставим его в такое-то место.
Это избавляет от многих головных болей.
Если есть SLA, то это вообще замечательно! 
Как мы начали решать проблему? Основная проблема была с тд-агентом.
Непонятно было, куда делись наши логи.
Они доставлены? Они собираются? Где они вообще? Поэтому первым пунктом было решено заменить тд-агент. Варианты, на что его заменить, я кратко изложил здесь.
Свободно.
Во-первых, я столкнулся с ним на предыдущей работе, и он тоже там периодически выпадал.
Во-вторых, это то же самое, только в профиль.
Файлбит. Насколько нам было удобно? Потому что это игра в Го, а у нас большой опыт в Го.
Соответственно, если бы что-то случилось, мы могли бы как-то добавить к этому себе.
Поэтому мы его не взяли.
Чтобы не было даже никакого соблазна начать переписывать его под себя.
Очевидным решением для системного администратора являются всевозможные системные журналы в таком количестве (syslog-ng/rsyslog/nxlog).
Или написать что-то свое, но это мы отбросили, как и filebeat. Если вы что-то пишите, лучше пишите что-нибудь полезное для бизнеса.
Для доставки логов лучше взять что-то готовое.
Поэтому выбор фактически сводился к выбору между syslog-ng и rsyslog. Я склонялся к rsyslog просто потому, что классы для rsyslog у нас уже были в Puppet, и явной разницы между ними я не нашел.
Что такое системный журнал, что такое системный журнал.
Да, у кого-то документация хуже, у кого-то лучше.
Этот может сделать так, а другой – по-другому.
И немного о rsyslog. Прежде всего, это круто, потому что у него много модулей.
Он имеет удобочитаемый RainerScript (современный язык конфигурации).
Отличный бонус, что мы смогли эмулировать поведение td-agent стандартными средствами, а для приложений ничего не изменилось.
То есть меняем td-agent на rsyslog, а все остальное пока оставляем в покое.
И мы сразу получаем рабочую поставку.
Далее, mmnormalize — замечательная вещь в rsyslog. Он позволяет анализировать журналы, но не с помощью Grok и регулярных выражений.
Он создает абстрактное синтаксическое дерево.
Он анализирует журналы почти так же, как компилятор анализирует источники.
Это позволяет работать очень быстро, мало потреблять процессор и вообще это очень крутая штука.
Есть еще куча бонусов.
Я не буду на них останавливаться.
У rsyslog есть много других недостатков.
Они примерно такие же, как бонусы.
Основные проблемы в том, что нужно знать, как его готовить, и выбирать вариант. 
Мы решили, что будем писать логи в unix-сокет. И не в /dev/log, потому что там каша системных логов, в этом конвейере есть Journald. Итак, давайте напишем в собственный сокет. Мы вынесем его в отдельный набор правил.
Давайте не будем ни во что вмешиваться.
Все будет прозрачно и понятно.
Именно это мы и сделали.
Каталог с этими сокетами стандартизируется и пересылается всем контейнерам.
Контейнеры могут видеть нужный им сокет, открывать его и писать в него.
Почему не файл? Потому что все это прочитали статья о Бадушечке , который пытался переслать файл в докер, и было обнаружено, что после перезапуска rsyslog изменился дескриптор файла, и докер потерял этот файл.
Он оставляет открытым что-то еще, но не сокет, в который они пишут. Мы решили, что обойдем эту проблему, а заодно обойдем и проблему блокировки.
Rsyslog выполняет действия, указанные на слайде, и отправляет журналы либо в ретранслятор, либо в Kafka. Кафка следует старому пути.
Реле — я пытался использовать чистый rsyslog для доставки журналов.
Без очереди сообщений, используя стандартные инструменты rsyslog. В принципе, это работает. 
Но есть нюансы, как их запихнуть в эту часть (Logstash/Graylog/ES).
Эта часть (rsyslog-rsyslog) используется между центрами обработки данных.
Вот сжатая tcp-ссылка, которая позволяет нам сэкономить пропускную способность и соответственно как-то повысить вероятность того, что мы получим какие-то логи из другого дата-центра при засорении канала.
Потому что у нас Индонезия, где все плохо.
Вот в этом и заключается постоянная проблема.
Мы подумали о том, как на самом деле мы можем отслеживать, насколько вероятно, что логи, которые мы записывали из приложения, дойдут до конца? Мы решили создать метрики.
У rsyslog есть собственный модуль сбора статистики, который содержит своеобразные счетчики.
Например, он может показать вам размер очереди или сколько сообщений поступило при таком-то действии.
У них уже можно что-то взять.
Кроме того, у него есть собственные счетчики, которые можно настроить, и они покажут вам, например, количество сообщений, записанных каким-либо API. Далее я написал rsyslog_exporter на Python, и мы отправили все это в Прометей и построили графики.
Нам очень хотелось получить метрики Graylog, но у нас пока не было времени их настроить.
Какие были проблемы? Проблемы возникли, когда мы обнаружили (ВНЕЗАПНО!), что наши Live API пишут 50 тысяч сообщений в секунду.
Это всего лишь Live API без промежуточного исполнения.
А Graylog показывает нам всего 12 тысяч сообщений в секунду.
И возник резонный вопрос: где останки? Из чего мы сделали вывод, что Graylog просто не справляется.
Мы посмотрели, и действительно, Graylog и Elasticsearch не смогли справиться с этим потоком.
Далее, другие открытия, которые мы сделали по пути.
Запись в сокет заблокирована.
Как это произошло? Когда я использовал для доставки rsyslog, в какой-то момент канал между дата-центрами сломался.
Доставка остановилась в одном месте, доставка остановилась в другом месте.
Все это дошло до машины с API, записывающими в сокет rsyslog. Там была очередь.
Затем заполнилась очередь на запись в unix-сокет, которая по умолчанию составляет 128 пакетов.
И следующая запись() в приложении блокируется.
Когда мы посмотрели библиотеку, которую используем в приложениях Go, там было написано, что запись в сокет происходит в неблокирующем режиме.
Мы были уверены, что ничего не заблокировано.
Потому что мы читаем статья о Бадушечке кто об этом написал.
Но есть момент. Вокруг этого вызова также существовал бесконечный цикл, в котором происходила постоянная попытка отправить сообщение в сокет. Мы его не заметили.
Пришлось переписать библиотеку.
С тех пор оно несколько раз менялось, но теперь мы избавились от блокировок во всех подсистемах.
Поэтому вы можете остановить rsyslog, и ничего не выйдет из строя.
Необходимо следить за размером очередей, что помогает не наступать на эти грабли.
Во-первых, мы можем отслеживать, когда начинаем терять сообщения.
Во-вторых, мы можем отслеживать, что у нас есть проблемы с доставкой.
И еще неприятный момент — усиление в 10 раз в микросервисной архитектуре происходит очень легко.
У нас не так много входящих запросов, но из-за графа, по которому эти сообщения путешествуют дальше, из-за логов доступа мы фактически увеличиваем нагрузку на логи примерно в десять раз.
К сожалению, подсчитать точные цифры у меня не было времени, но микросервисы такие, какие они есть.
Это необходимо иметь в виду.
Оказывается, на данный момент подсистема сбора логов является самой загруженной в Lazada. 
Как решить проблему эластичного поиска? Если вам нужно быстро получить логи в одном месте, чтобы не бегать по всем машинам и собирать их там, используйте файловое хранилище.
Это гарантированно сработает. Это можно сделать с любого сервера.
Нужно просто воткнуть туда диски и установить системный журнал.
После этого у вас гарантированно будут все логи в одном месте.
Потом можно потихоньку настроить elasticsearch, Graylog и что-то еще.
Но все логи у вас уже будут, и, более того, вы сможете их хранить, насколько хватит дисковых массивов.
На момент моего доклада схема стала выглядеть так.
Мы практически перестали писать в файл.
Теперь, скорее всего, отключим остальное.
На локальных машинах, на которых работает API, мы прекратим запись в файлы.
Во-первых, есть файловое хранилище, которое работает очень хорошо.
Во-вторых, этим машинам постоянно не хватает места; за этим нужно постоянно следить.
Эта часть с Logstash и Graylog действительно набирает обороты.
Поэтому нам нужно от него избавиться.
Вам придется выбрать что-то одно.
Мы решили выкинуть Логсташ и Кибану.
Потому что у нас есть отдел безопасности.
Какая связь? Связь в том, что Кибана без X-Pack и без Shield не позволяет разграничить права доступа к логам.
Вот почему мы взяли Грейлог.
Здесь есть все.
Мне это не нравится, но это работает. Мы купили новое железо, установили туда свежий Graylog и перенесли все логи строгих форматов в отдельный Graylog. Проблему с разными типами одинаковых полей мы решили организационно.
Что именно включено в новый Graylog. Мы просто записали все в докер.
Мы взяли кучу серверов, развернули три экземпляра Kafka, 7 серверов Graylog версии 2.3 (потому что хотели Elasticsearch версии 5).
Всё это подхватывалось во время рейдов с HDD. Мы увидели скорость индексации до 100 тысяч сообщений в секунду.
Мы увидели цифру, что 140 терабайт данных в неделю.
И снова грабли! Нас ждут две продажи.
Мы вышли за рамки 6 миллионов сообщений.
У Грейлога нет времени жевать.
Каким-то образом нам придется снова выжить.
Вот как мы выжили.
Мы добавили еще несколько серверов и SSD. На данный момент мы живем именно так.
Сейчас мы уже пережевываем 160к сообщений в секунду.
Мы еще не достигли предела, поэтому неясно, сколько мы сможем на самом деле получить от этого.
Это наши планы на будущее.
Из них наиболее важным, вероятно, является высокая доступность.
У нас его еще нет. Несколько машин настраиваются одинаково, но пока всё происходит через одну машину.
Для настройки переключения между ними требуется время.
Собирайте метрики из Graylog. Установите ограничение скорости, чтобы у нас был один сумасшедший API, который не убивал бы нашу пропускную способность и все остальное.
И, наконец, подпишите с разработчиками какое-то соглашение об уровне обслуживания, чтобы мы могли столько-то обслуживать.
Если напишете больше, то извините.
И писать документацию.
Коротко о результатах всего, что мы пережили.
Во-первых, стандарты.
Во-вторых, системный журнал — это пустяк.
В-третьих, rsyslog работает именно так, как написано на слайде.
И перейдем к вопросам.
Вопросы .
Вопрос : Почему ты решил не брать.
(filebeat?) Отвечать : Нам нужно записать в файл.
Я действительно не хотел.
Когда ваш API пишет тысячи сообщений в секунду, даже если вы ротируете его раз в час, это все равно не вариант. Вы можете писать в трубе.
На что разработчики меня спросили: «Что будет, если процесс, в который мы пишем, упадетЭ» Я просто не нашел, что им ответить, и сказал: «Ну ок, давайте не будем так делать».
Вопрос : Почему бы вам просто не писать логи в HDFS? Отвечать : Это следующий этап.
Мы думали об этом в самом начале, но так как на данный момент ресурсов для этого нет, то это зависает в нашем долгосрочном решении.
Вопрос : Формат столбца был бы более подходящим.
Отвечать : Я понимаю.
Мы за это обеими руками.
Вопрос : Вы пишете в rsyslog. Там вы можете использовать как TCP, так и UDP. А если UDP, то как гарантировать доставку? Отвечать : Есть два момента.
Во-первых, сразу всем говорю, что мы не гарантируем доставку бревен.
Потому что когда приходят разработчики и говорят: «Давайте начнем писать туда финансовые данные, а вы нам их куда-нибудь поместите, если что-то произойдет», мы им отвечаем: «Отлично! Давайте начнем блокировать запись в сокет, и сделаем это в транзакциях, чтобы вы гарантированно поместили это для нас в сокет и были уверены, что мы получим это с другой стороны».
И в этот момент всем это сразу становится не нужно.
Если нет необходимости, то какие вопросы нам следует задать? Если вы не хотите гарантировать запись в сокет, то зачем нам гарантировать доставку? Мы делаем все возможное.
Мы действительно стараемся доставить как можно больше и в лучшем виде, но 100% гарантии не даем.
Поэтому нет необходимости записывать туда финансовые данные.
Для этого существуют базы данных с транзакциями.
Вопрос : Когда API генерирует какое-то сообщение в журнале и передает управление микросервисам, вы сталкивались с проблемой, что сообщения от разных микросервисов приходят в неправильном порядке? Это вызывает путаницу.
Отвечать : Это нормально, что они приходят в разном порядке.
Вам нужно быть к этому готовым.
Потому что любая сетевая доставка не гарантирует порядок, либо на это придется тратить специальные ресурсы.
Если брать файловые хранилища, то каждый API сохраняет логи в свой файл.
Вернее, там rsyslog сортирует их по каталогам.
У каждого API есть свои логи, куда вы можете зайти и посмотреть, а затем сравнить их по временной метке в этом журнале.
Если они зайдут в Graylog, то там они будут отсортированы по временной метке.
Там все будет хорошо.
Вопрос : временная метка может варьироваться в миллисекундах.
Отвечать : временная метка генерируется самим API. В этом, собственно, и вся суть.
У нас есть НТП.
API генерирует временную метку в самом сообщении.
rsyslog не добавляет его.
Вопрос : Взаимодействие между дата-центрами не очень понятно.
В дата-центре понятно, как собирались и обрабатывались журналы.
Как происходит взаимодействие между дата-центрами? Или каждый дата-центр живет своей жизнью? Отвечать : Почти.
В нашей стране каждая страна расположена в одном дата-центре.
На данный момент у нас нет разброса, чтобы одна страна находилась в разных дата-центрах.
Поэтому нет необходимости их объединять.
Внутри каждого центра есть реле регистрации.
Это сервер Rsyslog. Фактически две машины управления.
У них такое же отношение.
Но пока трафик просто идет через один из них.
Он объединяет все журналы.
На всякий случай у нее есть очередь на диске.
Он загружает логи и отправляет их в центральный дата-центр (Сингапур), откуда они затем передаются в Graylog. И каждый дата-центр имеет свое файловое хранилище.
На случай потери соединения у нас есть все логи.
Они останутся там.
Они будут храниться там.
Вопрос : В случае нештатных ситуаций вы получаете логи оттуда? Отвечать : Можешь зайти туда (в файловое хранилище) и посмотреть.
Вопрос : Как вы следите, чтобы логи не терялись? Отвечать : Мы их фактически теряем и отслеживаем это.
Мониторинг был запущен месяц назад. Библиотека, которую используют API Go, имеет метрики.
Она может подсчитать, сколько раз ей не удалось выполнить запись в сокет. В настоящее время там есть хитрая эвристика.
Там есть буфер.
Он пытается записать сообщение от него в сокет. Если буфер переполняется, он начинает их удалять.
И он считает, сколько их он уронил.
Если там счетчики начнут переливаться, мы об этом узнаем.
Они сейчас тоже приходят в Прометей, и графики можно посмотреть в Графане.
Вы можете настроить оповещения.
Но пока не ясно, кому их направить.
Вопрос : В elasticsearch вы храните логи с избыточностью.
Сколько у вас реплик? Отвечать : Одна линия.
Вопрос : Это всего лишь одна строка? Отвечать : Это мастер и реплика.
Данные хранятся в двух копиях.
Вопрос : Вы как-то настраивали размер буфера rsyslog? Отвечать : Мы записываем датаграммы в специальный сокет Unix. Это сразу накладывает на нас ограничение в 128 килобайт. Мы не можем написать об этом больше.
Мы прописали это в стандарте.
Желающие попасть в хранилище пишут 128 килобайт. Библиотеки при этом отключаются, и ставится флаг, что сообщение отключено.
В нашем стандарте для самого сообщения есть специальное поле, которое показывает, было ли оно обрезано при записи или нет. Так что у нас есть возможность отследить и этот момент. Вопрос : Вы пишете битый JSON? Отвечать : неработающий JSON будет отброшен во время ретрансляции, поскольку пакет слишком велик.
Или Graylog будет отброшен, поскольку он не может анализировать JSON. Но есть нюансы, которые необходимо исправить, и они в основном завязаны на rsyslog. Я там уже оформил несколько вопросов, над которыми еще нужно работать.
Вопрос : Почему Кафка? Вы пробовали RabbitMQ? Не выходит ли Graylog из строя при таких нагрузках? Отвечать : С Graylog у нас не получается.
И Грейлог обретает для нас форму.
Он действительно проблемный.
Он особенный.
И, по сути, это не нужно.
Я бы предпочел писать из rsyslog напрямую в elasticsearch, а затем смотреть на Kibana. Но нам нужно решить вопрос с охранниками.
Это возможный вариант нашего развития, когда мы выкинем Graylog и будем использовать Kibana. Нет смысла использовать Logstash. Потому что я могу сделать то же самое с rsyslog. И у него есть модуль для записи в elasticsearch. Пытаемся как-то жить с Грейлогом.
Мы даже немного доработали его.
Но есть еще возможности для улучшения.
О Кафке.
Так произошло исторически.
Когда я приехал, он уже был там, и в него уже писались логи.
Мы просто подняли наш кластер и переместили в него логи.
Мы его руководство, мы знаем, что он чувствует. Что касается RabbitMQ. с RabbitMQ у нас не получается.
И RabbitMQ обретает для нас форму.
Он у нас в производстве, и с ним были проблемы.
Сейчас, перед продажей, его очаровали, и он начал нормально работать.
Но до этого я не был готов выпустить его в производство.
Есть еще один момент. Graylog может читать версию AMQP 0.9, а rsyslog может записывать версию AMQP 1.0. И нет ни одного Теги: #Системное администрирование #Администрирование сервера #DevOps #kafka #ведение журнала #сбор журналов #elasticsearch #graylog #rsyslog
-
Хотите Стать Тестером Видеоигр?
19 Oct, 24 -
Как Скопировать Dvd На Новый Ipad На Mac
19 Oct, 24 -
Deepmemo — Социальный Цитатник
19 Oct, 24 -
Seo: Деньги Не Пахнут?
19 Oct, 24
