В новый проект нужно добавить логов. Желательно что бы логи были шустрые, но о микросекундах речи не идет. В теории я мог бы взять spdlog и радоваться жизни, но мне очень хочется получить структурные логи.
Какие есть опции, кроме как городить структурные логи самому, на что у меня просто нет времени?
UPD. немного о том, что такое структурные логи, т.к. похоже что в мире C++ это нечто из ряда вот выходящее. Обычно это лог, где каждая строка лога — это полноценная JSON (может быть другой формат) запись, что крайне полезно при автоматизации.
Классический пример из Go-мира. А вот немного о том, как подобное, но куда более сложное и специализированное решение, можно сделать в C++ и зачем оно бывает надо.
Что интересно, даже в Haskell есть активно развивающиеся библиотеки с таким функционалом, а в C++
KP>UPD. немного о том, что такое структурные логи, т.к. похоже что в мире C++ это нечто из ряда вот выходящее. Обычно это лог, где каждая строка лога — это полноценная JSON (может быть другой формат) запись, что крайне полезно при автоматизации.
В чем проблема? Почти в каждой библиотеке логгирования можно прикрутить свое форматирование. Задать шаблон JSON -- не проблема.
P7 вообще предлагает логи хранить в бинарном виде (скорее всего, protobuf) -- просмотрщик прилагается (вроде даже в исходниках), конвертация в любой формат тривиальна.
Там вообще есть возможность логи лить по сети с изменением детализации "на лету".
Здравствуйте, K13, Вы писали:
K13>В чем проблема? Почти в каждой библиотеке логгирования можно прикрутить свое форматирование. Задать шаблон JSON -- не проблема. K13>P7 вообще предлагает логи хранить в бинарном виде (скорее всего, protobuf) -- просмотрщик прилагается (вроде даже в исходниках), конвертация в любой формат тривиальна. K13>Там вообще есть возможность логи лить по сети с изменением детализации "на лету".
Мне кажется это слишком много слов для передачи довольно простой мысли "я не встречал такого"
Здравствуйте, kaa.python, Вы писали:
KP>В новый проект нужно добавить логов. Желательно что бы логи были шустрые, но о микросекундах речи не идет. В теории я мог бы взять spdlog и радоваться жизни, но мне очень хочется получить структурные логи. KP>Какие есть опции, кроме как городить структурные логи самому, на что у меня просто нет времени?
spdlog/Boost Log + custom formatter. Извини, это не мы такие, это С++ такой. И ,кстати, хорошо.
KP>UPD. немного о том, что такое структурные логи, т.к. похоже что в мире C++ это нечто из ряда вот выходящее. Обычно это лог, где каждая строка лога — это полноценная JSON (может быть другой формат) запись, что крайне полезно при автоматизации.
Повбивав бы, если честно. Их читать неудобно. А подход, когда с устройства мне приходит лог и нужна специальная софтинка его посмотреть — на этапе прототипирования и отладки раздражает. Потом в производстве всё равно бинарный формат какой-нибудь с protobuf по традиции используют. Трафик экономят в машине, ага. Хотя там и гигабитный канал связи может уже есть.
KP>А вот немного о том, как подобное, но куда более сложное и специализированное решение, можно сделать в C++ и зачем оно бывает надо.
О, я помню это презентацию. Интересно, но стартапно.
KP>Что интересно, даже в Haskell есть активно развивающиеся библиотеки с таким функционалом, а в C++
Это ты ещё не дошёл до реализации всех своих правильных хотелок согласно ISO 26262.
Здравствуйте, El Camino Real, Вы писали:
ECR>spdlog/Boost Log + custom formatter. Извини, это не мы такие, это С++ такой. И ,кстати, хорошо.
Это очень плохо. Вместо того что бы решать проблемы бизнеса, каждый "уважающий себя C++ разработчик" считает очень классной задачей написать очередной логгер
ECR>Повбивав бы, если честно. Их читать неудобно.
Их нормально читать. Смотри:
{"level":"warning","msg":"The group's number increased tremendously!", "number":122,"omg":true,"time":"2014-03-10 19:57:38.562471297 -0400 EDT"}
У тебя всегда есть цельное сообщение, просто данные отдельно идут. И это очень удобно для автоматизации и всяких интеграционных тестов.
ECR>О, я помню это презентацию. Интересно, но стартапно.
Это соверщенно нормальный, типичный подход для мира за пределами C++. Если бы не страстное желание каждый раз писать свой "правильный" логгер — и в плюсах было бы. Но NIH в плюсовой разработке просто неистребим.
KP>>Что интересно, даже в Haskell есть активно развивающиеся библиотеки с таким функционалом, а в C++ ECR>Это ты ещё не дошёл до реализации всех своих правильных хотелок согласно ISO 26262.
Дошел, как слышу ASIL-D так сразу в пот бросает. Но всё же надо признать, что 95% кода под QM, в худшем случае под ASIL-B.
Здравствуйте, El Camino Real, Вы писали:
ECR>Повбивав бы, если честно. Их читать неудобно. А подход, когда с устройства мне приходит лог и нужна специальная софтинка его посмотреть — на этапе прототипирования и отладки раздражает. Потом в производстве всё равно бинарный формат какой-нибудь с protobuf по традиции используют. Трафик экономят в машине, ага. Хотя там и гигабитный канал связи может уже есть.
Софтина нужна в любом случае, я не много знаю людей которые могут тот же UTF8 читать.
Там где важна скорость никто не будет использовать текстовые форматы.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, El Camino Real, Вы писали:
ECR>>spdlog/Boost Log + custom formatter. Извини, это не мы такие, это С++ такой. И ,кстати, хорошо.
KP>Это очень плохо. Вместо того что бы решать проблемы бизнеса, каждый "уважающий себя C++ разработчик" считает очень классной задачей написать очередной логгер
Я не думаю, что проблема в С++ программистах. Скорее в языке и его инфраструктуре — в С++ до сих пор нет ни стандартной систебы сборки, ни менеджера пакета итд
Пока найдешь логгер который делает то что тебе надо, пока прикрутишь его... Проще свой написать
Например, тебе нравится Cmake, а для меня это худшая система сборки итд
Здравствуйте, placement_new, Вы писали:
_>Я не думаю, что проблема в С++ программистах. Скорее в языке и его инфраструктуре — в С++ до сих пор нет ни стандартной систебы сборки, ни менеджера пакета итд
Я могу конечно ошибаться, но есть ощущение что именно в C++ программистах и смотри почему. Вот тут говорят
утверждают что из за двух библиотек добавить одну строчку в conan-файл это фу, и лучше эти библиотек написать самому. И таких примеров просто море, в мире C++, и скорее исключение из правил в мире какого нибудь Go, Python и даже экзотического Elixir (для примера взял те языки с которыми недавно работал). Как бы следует что это типичный образ мышления C++ разработчика, был бы тут Go/Python/Elixir разработчик, то он бы посчитал такую ситуацию проблемой
_>Пока найдешь логгер который делает то что тебе надо, пока прикрутишь его... Проще свой написать
spdlog обычно всех устраивает, и его добавить — это одна строка в conan-файле или конфиге для vcpkg. Потом еще одна строка в CMake или какой-то другой системе сборке, что в проекте используется.
_>Например, тебе нравится Cmake, а для меня это худшая система сборки итд
Я бы сказал что CMake — это полное говно, но при этом лучшее что есть "на рынке" и мы это заслужили
Здравствуйте, kaa.python, Вы писали:
KP>В новый проект нужно добавить логов. Желательно что бы логи были шустрые, но о микросекундах речи не идет. В теории я мог бы взять spdlog и радоваться жизни, но мне очень хочется получить структурные логи. KP>Какие есть опции, кроме как городить структурные логи самому, на что у меня просто нет времени?
Я вот тоже искал, с требованием, чтобы можно было делать вложенные логгеры, как у меня в Go:
logger := logger.WithNodeId("123")
logger.Print("Something bad happened")
// На выходе: {"node": "123", "msg": "Something bad happened"}
Не нашёл ничего. Всё уродливо. Пока остановился на Boost.Log, который хотя бы написан нормально (без жёсткой завязки на глобальне переменные).
Здравствуйте, Cyberax, Вы писали:
C>Не нашёл ничего. Всё уродливо. Пока остановился на Boost.Log, который хотя бы написан нормально (без жёсткой завязки на глобальне переменные).
Как видишь, в мире C++ если ты не написал очередной велосипед, то считай день не задался
Здравствуйте, kaa.python, Вы писали:
C>>Не нашёл ничего. Всё уродливо. Пока остановился на Boost.Log, который хотя бы написан нормально (без жёсткой завязки на глобальне переменные). KP>Как видишь, в мире C++ если ты не написал очередной велосипед, то считай день не задался
Я привычный. Мы тут уже думаем, не писать ли сервисы на Go, с завязкой C++ кода через Cgo/SWIG.
Здравствуйте, Максим, Вы писали:
М>Немного в сторону вопрос, c гугловым логером (https://github.com/google/glog) не работали? Интересно было бы сравнить glog vs spdlog.
Нет, я его ни разу не пробовал. Выглядит "богаче" как минимум, но надо ли всё вот это в логах вопрос отдельный:
CHECK(fp->Write(x) == 4) << "Write failed!";
VLOG_IF(1, (size > 1024))
<< "I’m printed when size is more than 1024 and when you run the "
"program with --v=1 or more";
Но что интересно, опять нет ни структуры, ни возможности сделать вложенный логгер
Здравствуйте, kaa.python, Вы писали:
KP>Но что интересно, опять нет ни структуры, ни возможности сделать вложенный логгер
А, кстати, платформа какая? В Линуксе systemd умеет логгировать в json, например. Если какой-то системный сервис пишешь, то можно через такое извращение попробовать. Ну, и фетиш с объединением логгирования как процесса и формата представления данных в одну библиотеку, честно, не понимаю.
Здравствуйте, El Camino Real, Вы писали:
ECR>А, кстати, платформа какая? В Линуксе systemd умеет логгировать в json, например.
Собственная сборка Linux.
ECR>Если какой-то системный сервис пишешь, то можно через такое извращение попробовать.
Пишу сервисы в ROS-подобной системе и занимаюсь развитием самой это системой. К сожалению такой вариант не подойдет по куче причин, ну а что конкретно желательно иметь я описал в изначальном посте.
ECR>Ну, и фетиш с объединением логгирования как процесса и формата представления данных в одну библиотеку, честно, не понимаю.
В мире C++ с автоматизацией тестирования ПО и автоматизацией диагностики ошибок всё из рук вон плохо и не понимание более чем ожидаемо. А иметь структурные логи нужно в основном для этого.
Здравствуйте, kaa.python, Вы писали:
KP>В мире C++ с автоматизацией тестирования ПО и автоматизацией диагностики ошибок всё из рук вон плохо и не понимание более чем ожидаемо. А иметь структурные логи нужно в основном для этого.
Я ж и говорю, фетишист. Неудобно в твоём джсоне матрицы с векторами смотреть, и не переубеждай. А на проде все равно protobuf+encryption и в облако. Там fluentd сам разберётся чем анализатор кормить.
Здравствуйте, El Camino Real, Вы писали:
ECR>Я ж и говорю, фетишист. Неудобно в твоём джсоне матрицы с векторами смотреть, и не переубеждай. А на проде все равно protobuf+encryption и в облако. Там fluentd сам разберётся чем анализатор кормить.
Здравствуйте, kaa.python, Вы писали:
KP>В новый проект нужно добавить логов. Желательно что бы логи были шустрые, но о микросекундах речи не идет. В теории я мог бы взять spdlog и радоваться жизни, но мне очень хочется получить структурные логи. KP>Какие есть опции, кроме как городить структурные логи самому, на что у меня просто нет времени?
А обязательно прямо сразу в JSON писать? Плоская запись + filebeat + logstash не подойдет?
Здравствуйте, _const_, Вы писали:
__>А обязательно прямо сразу в JSON писать? Плоская запись + filebeat + logstash не подойдет?
Частично подойдет, конечно, и скорее всего так и будет, но это не то что реально нужно. Подобная связка прижилась скорее по причине кривых систем логирования как таковых. Да, ты так можешь анализировать логи, следить за системой и т.д., но не упрощаешь себе разработку модульных/интеграционных тестов. А меня в первую очередь интересуют именно они.
