Здравствуйте, kaa.python, Вы писали:

KP>В новый проект нужно добавить логов. Желательно что бы логи были шустрые, но о микросекундах речи не идет. В теории я мог бы взять spdlog и радоваться жизни, но мне очень хочется получить структурные логи.
KP>Какие есть опции, кроме как городить структурные логи самому, на что у меня просто нет времени?

Не смотрел на binlog от Morgan-Stanley?

В новый проект нужно добавить логов. Желательно что бы логи были шустрые, но о микросекундах речи не идет. В теории я мог бы взять spdlog и радоваться жизни, но мне очень хочется получить структурные логи.
Какие есть опции, кроме как городить структурные логи самому, на что у меня просто нет времени?

UPD. немного о том, что такое структурные логи, т.к. похоже что в мире C++ это нечто из ряда вот выходящее. Обычно это лог, где каждая строка лога — это полноценная JSON (может быть другой формат) запись, что крайне полезно при автоматизации.

Классический пример из Go-мира. А вот немного о том, как подобное, но куда более сложное и специализированное решение, можно сделать в C++ и зачем оно бывает надо.

Что интересно, даже в Haskell есть активно развивающиеся библиотеки с таким функционалом, а в C++

Здравствуйте, K13, Вы писали:

K13>В чем проблема? Почти в каждой библиотеке логгирования можно прикрутить свое форматирование. Задать шаблон JSON -- не проблема.
K13>P7 вообще предлагает логи хранить в бинарном виде (скорее всего, protobuf) -- просмотрщик прилагается (вроде даже в исходниках), конвертация в любой формат тривиальна.
K13>Там вообще есть возможность логи лить по сети с изменением детализации "на лету".

Мне кажется это слишком много слов для передачи довольно простой мысли "я не встречал такого"

Здравствуйте, kaa.python, Вы писали:

KP>Здравствуйте, El Camino Real, Вы писали:

ECR>>spdlog/Boost Log + custom formatter. Извини, это не мы такие, это С++ такой. И ,кстати, хорошо.

KP>Это очень плохо. Вместо того что бы решать проблемы бизнеса, каждый "уважающий себя C++ разработчик" считает очень классной задачей написать очередной логгер

Я не думаю, что проблема в С++ программистах. Скорее в языке и его инфраструктуре — в С++ до сих пор нет ни стандартной систебы сборки, ни менеджера пакета итд
Пока найдешь логгер который делает то что тебе надо, пока прикрутишь его... Проще свой написать
Например, тебе нравится Cmake, а для меня это худшая система сборки итд

Здравствуйте, kaa.python, Вы писали:

KP>Что интересно, даже в Haskell есть активно развивающиеся библиотеки с таким функционалом, а в C++

О чем ты вообще говоришь?
Открой любой C++ проект и первое что ты увидишь — каждый пишет свой логгер. А ты спрашиваешь о единном формате...

Здравствуйте, 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++ если ты не написал очередной велосипед, то считай день не задался

Здравствуйте, Marty, Вы писали:

KP>>Это соверщенно нормальный, типичный подход для мира за пределами C++.
M>Я в джаве покушал этого. Лучше бы их не было вовсе
Java можно ругать за разное, но таки именно она используется для очень крупных корпоративных систем, и их тяжко нажитый опыт стоит учитывать.

В логгерах для Go это сделали, в С++ — до сих пор курят непонятно что.

KP>UPD. немного о том, что такое структурные логи, т.к. похоже что в мире C++ это нечто из ряда вот выходящее. Обычно это лог, где каждая строка лога — это полноценная JSON (может быть другой формат) запись, что крайне полезно при автоматизации.

В чем проблема? Почти в каждой библиотеке логгирования можно прикрутить свое форматирование. Задать шаблон JSON -- не проблема.
P7 вообще предлагает логи хранить в бинарном виде (скорее всего, protobuf) -- просмотрщик прилагается (вроде даже в исходниках), конвертация в любой формат тривиальна.
Там вообще есть возможность логи лить по сети с изменением детализации "на лету".

Здравствуйте, 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 читать.
Там где важна скорость никто не будет использовать текстовые форматы.

Здравствуйте, placement_new, Вы писали:

_>Я не думаю, что проблема в С++ программистах. Скорее в языке и его инфраструктуре — в С++ до сих пор нет ни стандартной систебы сборки, ни менеджера пакета итд

Я могу конечно ошибаться, но есть ощущение что именно в C++ программистах и смотри почему. Вот тут говорят

Автор: El Camino Real
Дата: 08.12.20

что надо писать свой форматтер и это хорошо, вот тут

Автор: K13
Дата: 08.12.20

без хорошо, но тоже надо свой форматтер писать и это не проблема, а вот тут

Автор: denisko
Дата: 08.12.20

утверждают что из за двух библиотек добавить одну строчку в conan-файл это фу, и лучше эти библиотек написать самому. И таких примеров просто море, в мире C++, и скорее исключение из правил в мире какого нибудь Go, Python и даже экзотического Elixir (для примера взял те языки с которыми недавно работал). Как бы следует что это типичный образ мышления C++ разработчика, был бы тут Go/Python/Elixir разработчик, то он бы посчитал такую ситуацию проблемой

_>Пока найдешь логгер который делает то что тебе надо, пока прикрутишь его... Проще свой написать

spdlog обычно всех устраивает, и его добавить — это одна строка в conan-файле или конфиге для vcpkg. Потом еще одна строка в CMake или какой-то другой системе сборке, что в проекте используется.

_>Например, тебе нравится Cmake, а для меня это худшая система сборки итд

Я бы сказал что CMake — это полное говно, но при этом лучшее что есть "на рынке" и мы это заслужили

Здравствуйте, kaa.python, Вы писали:

C>>Не нашёл ничего. Всё уродливо. Пока остановился на Boost.Log, который хотя бы написан нормально (без жёсткой завязки на глобальне переменные).
KP>Как видишь, в мире C++ если ты не написал очередной велосипед, то считай день не задался
Я привычный. Мы тут уже думаем, не писать ли сервисы на Go, с завязкой C++ кода через Cgo/SWIG.

KP>я мог бы взять spdlog и радоваться жизни

Немного в сторону вопрос, c гугловым логером (https://github.com/google/glog) не работали? Интересно было бы сравнить glog vs spdlog.

Здравствуйте, Максим, Вы писали:

М>Немного в сторону вопрос, 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 не подойдет?

Частично подойдет, конечно, и скорее всего так и будет, но это не то что реально нужно. Подобная связка прижилась скорее по причине кривых систем логирования как таковых. Да, ты так можешь анализировать логи, следить за системой и т.д., но не упрощаешь себе разработку модульных/интеграционных тестов. А меня в первую очередь интересуют именно они.

Здравствуйте, kaa.python, Вы писали:

KP>Это соверщенно нормальный, типичный подход для мира за пределами C++.

Я в джаве покушал этого. Лучше бы их не было вовсе

Здравствуйте, Marty, Вы писали:

KP>>Это соверщенно нормальный, типичный подход для мира за пределами C++.

M>Я в джаве покушал этого. Лучше бы их не было вовсе

А что именно тебе не понравилось? Как вы вообще использовали логи?

Здравствуйте, Nuzhny, Вы писали:

N>Не смотрел на binlog от Morgan-Stanley?

Привет, нет, не видел, спасибо. Я что-то не пойму почему они это структурным логом назвали, если на их примеры посмотреть

BINLOG_INFO("My foo: {}", Foo{1, "two"});

// Outputs: My foo: Foo{ a: 1, b: two, c: true }

Еще и формат бинарный... для прода оно хорошо, конечно, но вот на этапе разработки скорее минус это

Здравствуйте, Cyberax, Вы писали:

KP>>>Это соверщенно нормальный, типичный подход для мира за пределами C++.
M>>Я в джаве покушал этого. Лучше бы их не было вовсе
C>Java можно ругать за разное, но таки именно она используется для очень крупных корпоративных систем, и их тяжко нажитый опыт стоит учитывать.

Ну, я конечно может и погорячился, и высказался излишне категорично, но мне эти логи а) мешают б) эти портянки часто нифига не помогают в) пока их настроишь — устаёшь приседать

А Java вообще гавно
Котлин на фоне джавы — ничего, но до плюсиков ему всё равно как пешком до Луны
Инфраструктура, конечно, впечатляет. Запилили бы managed С++ для JVM, как МС для шарпа, я бы первый перешел, бегом, роняя штаны.
Но вот структура проекта — это такое то ещё. "src/main/java|kotlin/com/mydomain/app"

Здравствуйте, Marty, Вы писали:

M>Ну, я конечно может и погорячился, и высказался излишне категорично, но мне эти логи а) мешают б) эти портянки часто нифига не помогают в) пока их настроишь — устаёшь приседать
Стоит понимать, что отладка и production — это разные вещи. JSON в отладке мне тоже не нравится. Потому у меня один и тот же лог на Go выглядит при отладка вот так:

2020-12-21T12:50:13.532-0800    INFO    HTTP    terra/service.pb.lv.go:43       Twirp request   {"dd.trace_id":
"0","dd.span_id":"0","service":"TerraData",
"method":"ListDatasets","input_size":0,"input":{}}
2020-12-21T12:50:13.532-0800    INFO    HTTP    visibility/traced_gorilla.go:164        Request failed  {
"bytes_in":0,"bytes_out":50,"host":"localhost:8080","latency":"456.944µs","latency_human":"456.944µs",
"dd.span_id":"0","dd.trace_id":"0","method":"POST","panic":"BAD", "path":"/twirp/terra.TerraData/ListDatasets",
"referer":"","status":500, "uri":"/twirp/terra.TerraData/ListDatasets", "user_agent":"Go-http-client/1.1"}
Panic: BAD
        terra/server/api_impl.go:72 (*TerraApi).ListDatasets
        terra/gen/terra/service.pb.lv.go:123 (*TerraDataLogValidate).ListDatasets
        terra/gen/terra/service.twirp.go:1045 (*terraDataServer).serveListDatasetsProtobuf.func1
        terra/gen/terra/service.twirp.go:1046 (*terraDataServer).serveListDatasetsProtobuf
        terra/gen/terra/service.twirp.go:958 (*terraDataServer).serveListDatasets
        terra/gen/terra/service.twirp.go:773 (*terraDataServer).ServeHTTP
        github.com/!n!y!times/gziphandler@v1.1.1/gzip.go:338 GzipHandlerWithOpts.func1.1
        net/http/server.go:2042 HandlerFunc.ServeHTTP
        net/http/server.go:2042 HandlerFunc.ServeHTTP
        github.com/gorilla/mux@v1.7.3/mux.go:212 (*Router).ServeHTTP
        net/http/server.go:2843 serverHandler.ServeHTTP
        net/http/server.go:1925 (*conn).serve

И вот так в production (только в виде одной длинной строчки, я разбил руками, чтобы RSDN не взорвался):

{"level":"info","ts":1608583882.759157,"logger":"HTTP","caller":"terra/service.pb.lv.go:43",
"msg":"Twirp request","dd.trace_id":"0","dd.span_id":"0","log.trace_id":"0","log.span_id":"0",
"service":"TerraData","method":"ListDatasets","input_size":0,"input":{}}
{"level":"info","ts":1608583882.759427,"logger":"HTTP","caller":"visibility/traced_gorilla.go:164",
"msg":"Request failed","dd.trace_id":"0","dd.span_id":"0","log.trace_id":"0","log.span_id":"0",
"stacktrace":"terra/server/api_impl.go:72 (*TerraApi).ListDatasets\n
terra/gen/terra/service.pb.lv.go:123 (*TerraDataLogValidate).ListDatasets\n
terra/gen/terra/service.twirp.go:1045 (*terraDataServer).serveListDatasetsProtobuf.func1\n
terra/gen/terra/service.twirp.go:1046 (*terraDataServer).serveListDatasetsProtobuf\n
terra/gen/terra/service.twirp.go:958 (*terraDataServer).serveListDatasets\n
terra/gen/terra/service.twirp.go:773 (*terraDataServer).ServeHTTP\n
github.com/!n!y!times/gziphandler@v1.1.1/gzip.go:338 GzipHandlerWithOpts.func1.1\n
net/http/server.go:2042 HandlerFunc.ServeHTTP\n
net/http/server.go:2042 HandlerFunc.ServeHTTP\n
github.com/gorilla/mux@v1.7.3/mux.go:212 (*Router).ServeHTTP\n
net/http/server.go:2843 serverHandler.ServeHTTP\nnet/http/server.go:1925 (*conn).serve\n",
"panic":"BAD","path":"/twirp/terra.TerraData/ListDatasets","host":"localhost:8080",
"method":"POST","uri":"/twirp/terra.TerraData/ListDatasets","referer":"",
"user_agent":"Go-http-client/1.1","status":500,"latency":0.000375389,
"latency_human":"375.389µs","bytes_in":0,"bytes_out":50}

Здравствуйте, Cyberax, Вы писали:

M>>Ну, я конечно может и погорячился, и высказался излишне категорично, но мне эти логи а) мешают б) эти портянки часто нифига не помогают в) пока их настроишь — устаёшь приседать
C>Стоит понимать, что отладка и production — это разные вещи. JSON в отладке мне тоже не нравится. Потому у меня один и тот же лог на Go выглядит при отладка вот так:

Спасибо, КЭП

Здравствуйте, _const_, Вы писали:

__>А обязательно прямо сразу в JSON писать? Плоская запись + filebeat + logstash не подойдет?

Здравствуйте, Nuzhny, Вы писали:

N>Не смотрел на binlog от Morgan-Stanley?

Как хорошо что решил полистать и нашел этот топик!

Сейчас почти такая же задача:
Есть бинарные логи в своём обычном виде написания.
Есть ELK + Graphana. logstah'a нет.
И есть желание записи в логах(может быть, какие-то) видеть в Графане.

Правильно понимаю, что нужно:
1) Переделывать записи в определенный json формат, который прописан у filebeat.
2) Делать txt формат из бинарного

Но вот как это делать?
Допустим, буду формировать записи в бинарном логе в json виде:
bin_log.log {
json...
json...
json...
}
Далее, сделаю питон скрипт, который будет периодически из бинарного делал текстовой:
bin_log.log -> text_log.txt
И класть в место, откуда читает filebeat.

Почему-то, мне не кажется это идеальным решением.
(каждые 100мб создается новый лог сейчас, делать логику по отслеживанию конца записи или нового файла лога, увеличение места из-за такого копирования при конвертации)
Подскажите, как упростить, облегчить?

А ТС, тебе же норм бинарный лог? У нас на проекте он для того, чтобы обеспечить:
1) Скорость записи
2) Сразу в память писать(mmap)
3) Экономия места
Чтобы в случае "бац!" ничего не пропало с HDD.
Правда, пока не смотрел, как он реализует многопоточность. Что каждый компонент, поток вызывает заветную LogInfo("%1%", "hello") и записи пишутся последовательно(как то с mmap связано).

Что по spdlog успел посмотреть, что данные складываются для отправки и если "бац!" то, вроде бы, отправленные в логгер записи не факт что будут сохранены на HDD.
На митапе С++ спрашивал про логгеры. Сказали, что в таком случае, можно с корки считать. Но я в этом не мастер. Кажется, что это не лучшее решение.

A>Есть ELK + Graphana. logstah'a нет.
A>И есть желание записи в логах(может быть, какие-то) видеть в Графане.
Может тогда бери Grafana Loki? Loki и json хавает (правда с ограничениями), и алерты с метриками сразу в графану прилетают.

Здравствуйте, hi_octane, Вы писали:

A>>Есть ELK + Graphana. logstah'a нет.
A>>И есть желание записи в логах(может быть, какие-то) видеть в Графане.
_>Может тогда бери Grafana Loki? Loki и json хавает (правда с ограничениями), и алерты с метриками сразу в графану прилетают.

Интересно, спасибо за наводку!

Здравствуйте, kaa.python, Вы писали:

KP>UPD. немного о том, что такое структурные логи, т.к. похоже что в мире C++ это нечто из ряда вот выходящее. Обычно это лог, где каждая строка лога — это полноценная JSON (может быть другой формат) запись, что крайне полезно при автоматизации.

К примеру, есть сервис, который прогоняет через себя сообщения.
Можно сделать json запись, в которой отобразить характеристики сообщения, откуда пришло, куда ушло, успешно ли.
Тогда лог будет из таких однотипных записей.

Но есть еще записи старта сервиса с диагностической информацией:
-Прочитал конфиг
-Приконектился к...
-Стартанул то-то
...

Еще в процессе могут быть ошибки отправки, и попытки рекконекта.

Что с этим делать?