Захотелось поиграться в Го, и наткнулся на неожиданное.
Как делать правильно логгирование и прочий мониторинг с трейсингом в го? Например, в .net есть пяток библиотек для структурного логгирования, в которых сотни плагинов для экспорта во что хочешь. Мне, например, нужно в loki, или в Application Insights, ну или в seq, на худой конец. В го же, такое ощущение, что все логгеры умеют в лучшем случае в файл. Ну в syslog, но если очень попросишь и то не все гладко. Не, понятно, что можно настроить promtail/filebit и забирать из файла в локи, но этож через дымоход.
С телеметрией тоже не фонтан, думал уж OpenTelemetry, который вроде как сам на го на писан, должен быть поддержан в полный рост — ан нет, одни только трейсы, мониторинг в процессе разработки, за логи даже не брались еще.
Как вы вообще живете без нормальной экосистемы, или я просто не туда смотрю?
Как и куда вообще принято логгировать в Го, и где и в чем собирать метрики?
Здравствуйте, IB, Вы писали:
IB>...В го же, такое ощущение, что все логгеры умеют в лучшем случае в файл...
И так надо делать в крайнем случае. Ну, например, если у тебя этих логов — несколько. Ну или если у тебя псевдогуй (типа mc)
А так — пиши в stdout/stderr. Админы дальше сами решат что с этим делать.
Здравствуйте, IB, Вы писали:
IB>Как и куда вообще принято логгировать в Го, и где и в чем собирать метрики?
В мире микросервисов (где сабж, в основном, и используется) есть священное писание — называется "The twelve-factor App" (https://12factor.net/).
Там, в разделе Logs (https://12factor.net/logs) навязывают рекомендуют:
A twelve-factor app never concerns itself with routing or storage of its output stream. It should not attempt to write to or manage logfiles. Instead, each running process writes its event stream, unbuffered, to stdout. During local development, the developer will view this stream in the foreground of their terminal to observe the app’s behavior.
In staging or production deploys, each process’ stream will be captured by the execution environment, collated together with all other streams from the app, and routed to one or more final destinations for viewing and long-term archival. These archival destinations are not visible to or configurable by the app, and instead are completely managed by the execution environment. Open-source log routers (such as Logplex and Fluentd) are available for this purpose.
Звучит логично, и я, в принципе, с этим согласен.
ПС: И нечего тут ржать — лучше по ссылкам почитайте.
Здравствуйте, Doom100500, Вы писали:
D>Звучит логично, и я, в принципе, с этим согласен.
Да, в целом к 12factors есть вопросики, но в плане логов — согласен.
Здравствуйте, Буравчик, Вы писали:
Б>Полно же информации в интернете
Спасибо, но это я все видел — думал может упустил что. Забавно, что не смотря на то, что Open Telemetry тулы написаны на go, поддержка go там в зачяточном состоянии.
Мы уже победили, просто это еще не так заметно...
