Сами логи у нас хранятся в связке Elasticsearch/Kafka, вот в этой статье наши коллеги DevOPS подробно рассказали как реализовали мощный кластер логирования.
Касательно метрик запросов - их собирает Prometheus. За какими графиками следим - зависит от бизнес-задачи.
С точки зрения надёжности сервисов - в первую очередь смотрим на возрастающее количество ответов 4xx и 5xx, чтобы заблаговременно видеть возникающую деградацию и не допускать её развития в проблему клиентов.
По поводу трассировки да, хорошая идея изначально закладывать какой-то один идентификатор на протяжении всего запроса на уровне всего IT-ландшафта. Это тоже удобно можно внедрить в стандартизированный API-клиент
Да, хорошая практика, можно добавить доп.обработчики на специфичную ошибку для ответа о том что сервис временно недоступен из-за перегрузки.
Согласен. Это как раз можно решить передачей отдельного логгера в инициализацию API-клиента и передавать туда отдельный LOGLEVEL, который можно, при желании, переопределить через ENV-переменные.
Думаю так и есть. Конечно же опыт важен для формирования предпочтений.
Статья отчасти про то, как форсированное помещение в иные обстоятельства заставляет адаптироваться и иначе посмотреть на ситуацию. Возможно это понимание пришло бы и потом, но не понятно как скоро.
А вы пробовали смешанный режим? Так и не довелось поучаствовать в экспериментах. Но, кажется, что есть свои подводные камни в плане необходимости адаптации под частую смену обстановки.
Насчет людей согласен. Как вариант - можно иногда собираться командно уже после работы. А еще "не одичать" помогают социальные связи вне работы - друзья, семья, отношения.
Сами логи у нас хранятся в связке Elasticsearch/Kafka, вот в этой статье наши коллеги DevOPS подробно рассказали как реализовали мощный кластер логирования.
Касательно метрик запросов - их собирает Prometheus. За какими графиками следим - зависит от бизнес-задачи.
С точки зрения надёжности сервисов - в первую очередь смотрим на возрастающее количество ответов 4xx и 5xx, чтобы заблаговременно видеть возникающую деградацию и не допускать её развития в проблему клиентов.
Спасибо за дополнение.
По поводу трассировки да, хорошая идея изначально закладывать какой-то один идентификатор на протяжении всего запроса на уровне всего IT-ландшафта. Это тоже удобно можно внедрить в стандартизированный API-клиент
Да, хорошая практика, можно добавить доп.обработчики на специфичную ошибку для ответа о том что сервис временно недоступен из-за перегрузки.
Согласен. Это как раз можно решить передачей отдельного логгера в инициализацию API-клиента и передавать туда отдельный LOGLEVEL, который можно, при желании, переопределить через ENV-переменные.
Думаю так и есть. Конечно же опыт важен для формирования предпочтений.
Статья отчасти про то, как форсированное помещение в иные обстоятельства заставляет адаптироваться и иначе посмотреть на ситуацию. Возможно это понимание пришло бы и потом, но не понятно как скоро.
Стало интересно, а есть ли какие-то причины кроме пандемии, которые заставляют "предпочитать" работу на удалёнке?
А вы пробовали смешанный режим? Так и не довелось поучаствовать в экспериментах. Но, кажется, что есть свои подводные камни в плане необходимости адаптации под частую смену обстановки.
Насчет людей согласен. Как вариант - можно иногда собираться командно уже после работы. А еще "не одичать" помогают социальные связи вне работы - друзья, семья, отношения.