add stdout appender, refactor

[karle0wne]

No description provided.

[karle0wne]

@tolkonepiu
по поводу параметров вывода
щас вывод выглядит так

строка

{
  "@timestamp": "2022-02-22T09:31:04.497Z",
  "@severity": "INFO",
  "thread_name": "main",
  "application": "app",
  "commit_id": "a1e962a",
  "logger_name": "org.springframework.boot.web.embedded.tomcat.TomcatWebServer",
  "method": "start",
  "line": "220",
  "message": "Tomcat started on port(s): 8023 (http) with context path ''"
}

тут хочется понять, почему параметры , которые ты перечислил выше не нужны:
1)

{
 "application": "app",
}

этот параметр у нас щас используется как самый популярный в кибане, основной разделитель для сервиса

{
 "commit_id": "a1e962a",
}

этот мне кажется можно включить, тк фильтрация по этому параметру позволит фильтровать логи в разрезе последней выкатки

{
  "method": "start",
  "line": "220",
}

тут конечно не уверен, но возможно наличие информации о названии метода и номера строки может помочь при разборе инцидентов при поиске конкретного участка кода с проблемой

[vilorij]

application - может популярный, но не универсальный между явой, эрлангом и инфрой.

Универсальные
kubernetes.labels.app_kubernetes_io/name | payouter
kubernetes.labels.selector_cilium/release | payouter

В кибане заведен алиас для универсального - service, по которому можно искать

О коммите есть инфа в кубере:
kubernetes.container.image | docker.io/rbkmoney/payouter:a0e37ad47ee5563008d2af47c58a9f117e941db0

[tolkonepiu]

этот параметр у нас щас используется как самый популярный в кибане, основной разделитель для сервиса

Не используется, мы используем либо service (alias на универсальные), либо универсальные теги кубера.

этот мне кажется можно включить, тк фильтрация по этому параметру позволит фильтровать логи в разрезе последней выкатки

У нас уже есть kubernetes.container.image, не вижу особого смысла плодить лишние, специфичные под язык, теги

тут конечно не уверен, но возможно наличие информации о названии метода и номера строки может помочь при разборе инцидентов при поиске конкретного участка кода с проблемой

Сомневаюсь, разбивка на такие теги будет полезна только для фильтрации и поиска чего либо. В данном случае method и line будут неиспользуемыми. В целом и так есть logger name, который скажет, где именно писали лог например.