Комментарии 26
А ещё разные логи требуют разного уровня сохранности: одни можно потерять через день, а другие — надо хранить 5 лет.
Какие примеры логов, который нужно хранить 5 лет, вы бы могли привести из вашей практики?
Лог отправки справки на получение водительского удостоверения. Пригодится когда этот водитель окажется невменяем и у вас будет детально запрошено кто когда и откуда этот документ сформировал.
У меня 2 примера:
И то и другое клиенты вынуждены хранить до 5 лет по своим внутренним ТЗ.
- Логи платёжного шлюза
- Логи запросов к государственным API SMEV
И то и другое клиенты вынуждены хранить до 5 лет по своим внутренним ТЗ.
Так это бизнес информация, а не просто логи… И вообще возникает мысль, что это реально события, которые требует отдельной политики для обработки. Т.е. не получается вкинуть все в одну трубу, как бы этого и не хотелось.
Да, именно про это и статья — в дивном новом мире всё простое стало одновременно и простым и сложным. Это еще хорошо отражено у коллег из ЦИАН в статье про логи
Случайно вставил битую ссылку. Правильная ссылка на статью ЦИАН
Это отдельная категория, которая обычно управляется отдельно. Например, в самом Kubernetes есть audit logs для записи действий выполняемых через Kubernetes API.
Security/audit на случай, если прокурор придет.
У нас год-два хранились логи переключений в АСУТП. Иногда, для редких аварийный событий, они анализировались. Ну скажем аварию могут вызвать события А, B, C. Верно ли, что за 5 лет это было только событие B? И при аварии есть смысл действовать, как будто это точно событие B?
По таким логам считаются вероятности. А по ним — меняются эвристики в софте. Ну скажем B — это ложное срабатывание, можно игнорировать. А и C — истинные, ущепрб от игнорирования — такой-то. Ну вот считаем и понимаем, что лучше делать автоматике — останавливать стан или нет.
Аналогично отказы в разной транспортной технике. Если какая-то деталь часто изнашивается на отдельных устройствах — надо поднимать базу и смотреть корреляции. То ли не с того поставщика деталь брали, то ли условия эксплуатации чуть иные.
Короче в АСУТП, где реальное железо — такое бывает. Чисто в софте — тоже то, что связано с отказами дисков и заменой расходников.
По таким логам считаются вероятности. А по ним — меняются эвристики в софте. Ну скажем B — это ложное срабатывание, можно игнорировать. А и C — истинные, ущепрб от игнорирования — такой-то. Ну вот считаем и понимаем, что лучше делать автоматике — останавливать стан или нет.
Аналогично отказы в разной транспортной технике. Если какая-то деталь часто изнашивается на отдельных устройствах — надо поднимать базу и смотреть корреляции. То ли не с того поставщика деталь брали, то ли условия эксплуатации чуть иные.
Короче в АСУТП, где реальное железо — такое бывает. Чисто в софте — тоже то, что связано с отказами дисков и заменой расходников.
Это подходит, но не является ли сбор таких данные самостоятельной целью? Т.е. проектируем и пишем некий комплекс специально чтобы хранить (надежно) переключения, есть определенный формат данных и так далее. Т.е. базу переключений получаем не в качестве побочного эффекта от сканирования текстовой телеметрии систем, которые предназначены для другого, а именно как самостоятельный продукт.
Не совсем. Основная цель — разбор недавних аварий. Как пример — помните катастрофу SSJ-100 в Шереметьево? В отчете отмечалось:
Все-таки основная цель черного ящика — понять причину катастрофы. Но вот, пригодились и записи полетов, закончившихся благополучно.
Ну и хороший аналог — запись данных S.M.AR.T для контроля дисков в ДЦ. Тоже анализ за 5 лет дал интересные данные. Да и вообще, любая система анализа текущих аварий в ретроспективе может дать интересную статистику.
Аналогичные «размашистые» движения наблюдались и при заходах на посадку, выполнявшихся в режиме «DIRECT MODE» другими экипажами авиакомпании (Рис. 43). Причины данных особенностей пилотирования анализируются. Все-таки основная цель черного ящика — понять причину катастрофы. Но вот, пригодились и записи полетов, закончившихся благополучно.
Ну и хороший аналог — запись данных S.M.AR.T для контроля дисков в ДЦ. Тоже анализ за 5 лет дал интересные данные. Да и вообще, любая система анализа текущих аварий в ретроспективе может дать интересную статистику.
Почему не используете в буферы для записи в кликхаус в самом кликхаусе? Есть же буферный тип таблиц. Для 5000 строк в секунду нормально же работает.
В статье есть про это, правда вскользь — мы упоминаем, что наша схема работы с CH несколько устарела. Так же надо понимать, что Engine Buffer это не надёжное хранилище.
Судя по подробному roadmap на 2020 (пункт 1.6) можно ожидать решение проблемы с частыми мелкими вставками. Очень надеюсь на эту фичу, так как не придется работать с буферными таблицами или городить batcher'ы, увеличивающие latency и сложность системы.
Я работаю в страховой компании, у нас со всего кубера прибывает около 60Гб день логов (без основной BI там оракла она в облаках не живет). Используем стандартный стек Elasticsearch + Kibana + Filebeat (сбор с stdout конечно) + APM + Curator. Да, железо нужно нормальное, но удобство работы с логами не сравнимое. Бизнес в нашем понимании заинтересован, чтобы проблемы решались быстро и для нас альтернатив просто нет.
Пробовали все эти схемы с fluent-bit и fluentd + elastic. Работает, но если вы хотите свой эластик обновлять часто, то проблем у вас будет не мало. Плюс важные логи вы можете выпиливать в отдельный индекс на уровне эластика и хранить столько сколько нужно. И это я говорю про бесплатную версию. Плюс доп функционал можно добить с помощью плагинов opendistro.
Пробовали все эти схемы с fluent-bit и fluentd + elastic. Работает, но если вы хотите свой эластик обновлять часто, то проблем у вас будет не мало. Плюс важные логи вы можете выпиливать в отдельный индекс на уровне эластика и хранить столько сколько нужно. И это я говорю про бесплатную версию. Плюс доп функционал можно добить с помощью плагинов opendistro.
А вы сравнивали Elastic с альтернативами по требованиям к железу?
Сравнивали. Clickhouse выигрывал в этом плане. Он очень быстрый и легко расширяется горизонтально. Но с другой стороны, вокруг Elasticsearch выросла очень классная инфраструктура с кучей плагинов.
Clickhouse выигрывал в этом плане
А можно подробнее — насколько? На уровне «чтобы принимать и индексировать логи, Elastic нужен 16CPU/64GB, а Clickhouse 8CPU/32GB»?
Всё, конечно же, зависит от нагрузки и общей конфигурации системы логирования. Выше уже идёт обсуждение
В нашем сетапе Clickhouse использовал 2 ядра и 2Gb, после замены на Elasticsearch начала использоваться машинка с 8 ядрами и 32Гб памяти.
В нашем сетапе Clickhouse использовал 2 ядра и 2Gb, после замены на Elasticsearch начала использоваться машинка с 8 ядрами и 32Гб памяти.
1. Не совсем раскрыта тема формата логов.
Под
2. Допустим мы настроили приложение, и все логи идут в stdout в однострочных JSON. Но как быть с необработанными исключениями, которые насыпят много строк на одно событие в stderr. Есть ли какие-то идеи по сбору логов от таких событий в один объект в системе логгирования?
Под
Логи должны быть в машиночитаемом формате (например, JSON).JSON, я так понимаю, имелся ввиду именно однострочный? В целом как по мне, подходит любой формат позволяющий позволяющий разбирать себя с минимальными затратами ресурсов(без использования регулярных выражений?) Проводили ли вы исследования о влиянии формата лога на трату ресурсов для его разбора? Например логи nginx в json и в обычном виде.
2. Допустим мы настроили приложение, и все логи идут в stdout в однострочных JSON. Но как быть с необработанными исключениями, которые насыпят много строк на одно событие в stderr. Есть ли какие-то идеи по сбору логов от таких событий в один объект в системе логгирования?
- На самом деле особых проблем с тем, что именно разбирает система логгировнаия, нет. Говоря об удобстве логов в json-формате, когда одно событие явялется одним json, мы подразумеваем, что такие логи будут автоматически разобраны loghouse или EFK и, в дальнейшем, можно будет удобно составлять аналитические запросы по полям этих логов, строить диаграммы и не использовать регулярные выражения, так как все критичные данные будут определены соответствующими полями json-лога.
- Тут очень много вариантов. Например, можно ошибки выводить в stderr, не ломая stdout. Можно даже больше — настроить, например, sentry, так как почти любой язык программирования умеет навешивать глобальную функцию для исключений и проблемы с тем, что в потоках ввода-вывода будет каша опять таки отпадёт.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Логи в Kubernetes (и не только) сегодня: ожидания и реальность