Единственно, что я не совсем понял, почему нельзя писать серелизованые сообщения (Json) напрямую в строковые логеры, вроде как elastic search их лихо парсит и индексирует, а в целом доклад понравился. Думаю воспользоваться советами, спасибо.
В этом случае, вы потеряете message template, человеко-читабельность данных (в читабельность json'а уже давно никто не верит). Конечно можно напрямую структуры писать в elastic и в mongo'у, но тогда у вас будут только данные для анализа, не будет понятных взгляду строк, бизнес-действий. А это тоже очень полезная часть. Serilog позволяет объединить два этих мира. Он даёт и машинные данные и человеческие. Ну и удобство в использовании Serilog'а и его расширений даёт огромное преимущество. У вас банально может не быть готового "сообщения" для сериализации в elastic, но для Serilog'а это не проблема.
Вы правы, Кибана хорошо решает задачу отображения графиков. Но вопрос был про различия в логировании простого JSON'а и Serilog message. Главное различие - это присутствие у последнего message template. И ELK не сможет эту информацию взять и отобразить ниоткуда. Вот и всё. Если для вашей задачи наличие message template не играет особой роли, то разницы нет.
Это нормальное поведение для любой БД (которой он по сути и является). Сравните с MSSQL, MondoDB и т.д. все они пытаются отожрать максимум оперативки, что бы работать быстрее и меньше свопиться на диск. Именно поэтому существует 2 способа использования любой БД, о которых стоит задуматься до её инсталяции: 1. мы отдаёт под неё всю машину (всю доступную оперативную память); 2. мы ограничиваем процесс определённым лимитом ресурсов, которые готовы ему отдать. У Seq существует флаг ram-target, который не просто умеет ограничивать память, но и динамически подстраивать этот лимит под текущую загруженность системы docs.getseq.net/discuss/564c8e993923ce1700da4d1c
Спасибо, что заметили :) Там не только ники. Например, в секции про Seq, там где разбирается одновременное редактирование документа, закодирована сцена из фильма: битва за "The Outer Limits". Жаль, что на видео не видно заголовков, полей документов и прочих мелочей.
+1 к карме. Очень толково по делу. Отдельное спасибо за серилог, все смотрел на него искал продакшен кейсе
Тоже уже давненько пришел к выводу что простые строковые логи это устаревший и малоэффективный подход.
Отличный доклад, спасибо большое.
Рад, что понравилось
Спасибо, очень хороший доклад, то что искал.
Очень интересный доклад. Спасибо!
Всегда пожалуйста :)
Мне показалось, или тут логирование смешалось с распределенной трассировкой?
Единственно, что я не совсем понял, почему нельзя писать серелизованые сообщения (Json) напрямую в строковые логеры, вроде как elastic search их лихо парсит и индексирует, а в целом доклад понравился. Думаю воспользоваться советами, спасибо.
В этом случае, вы потеряете message template, человеко-читабельность данных (в читабельность json'а уже давно никто не верит).
Конечно можно напрямую структуры писать в elastic и в mongo'у, но тогда у вас будут только данные для анализа, не будет понятных взгляду строк, бизнес-действий. А это тоже очень полезная часть. Serilog позволяет объединить два этих мира. Он даёт и машинные данные и человеческие.
Ну и удобство в использовании Serilog'а и его расширений даёт огромное преимущество. У вас банально может не быть готового "сообщения" для сериализации в elastic, но для Serilog'а это не проблема.
Да ну бросьте, кибана всё это решает. Графики, таблички, дэшборды, хоть heatmap, если захочется. Пишем прямо в эластик, смотрим кибаной. Довольны.
Вы правы, Кибана хорошо решает задачу отображения графиков. Но вопрос был про различия в логировании простого JSON'а и Serilog message. Главное различие - это присутствие у последнего message template. И ELK не сможет эту информацию взять и отобразить ниоткуда. Вот и всё. Если для вашей задачи наличие message template не играет особой роли, то разницы нет.
Сериализация в строку - это ощутимое выделение памяти и тормоза, которые приводят к тому, что логирование отключают.
@@tt0nix В последних версиях эластики шаблоны уже неактуальны, структура сообщений определяется на лету
Анатолий, а почему Вы не сказали, что Seq отжирает до 11Гб (гигабайт, Карл! ) оперативной памяти ?
Это нормальное поведение для любой БД (которой он по сути и является). Сравните с MSSQL, MondoDB и т.д. все они пытаются отожрать максимум оперативки, что бы работать быстрее и меньше свопиться на диск. Именно поэтому существует 2 способа использования любой БД, о которых стоит задуматься до её инсталяции:
1. мы отдаёт под неё всю машину (всю доступную оперативную память);
2. мы ограничиваем процесс определённым лимитом ресурсов, которые готовы ему отдать.
У Seq существует флаг ram-target, который не просто умеет ограничивать память, но и динамически подстраивать этот лимит под текущую загруженность системы
docs.getseq.net/discuss/564c8e993923ce1700da4d1c
Спасибо за ники из х/ф Хакеры :)
Спасибо, что заметили :) Там не только ники. Например, в секции про Seq, там где разбирается одновременное редактирование документа, закодирована сцена из фильма: битва за "The Outer Limits". Жаль, что на видео не видно заголовков, полей документов и прочих мелочей.