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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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