В продолжение вчерашнего.
В одном подкасте я слышал фразу: "Вам будет очень сложно находиться в технической тусовке без Twitter". И это, кстати, правда. Очень много всего приходит именно оттуда. Да и вообще такое впечатление, что это основной способ общения инженеров из Долины.
Поэтому я вам иногда буду подкидывать интересных людей оттуда. И первой в списке пойдёт Джулия Еванс aka @b0rk — инженер и художница, которая рисует прекрасные скетчи по технической тематике и даже выпускает свой самиздатный журнал. И ведёт блог
Ну а по этой ссылке статья про Kubernetes (конечно же со скетчами!)
#kubernetes #twitter #people
Журнал, кстати, можно заказать в бумаге. Правда, я боюсь предположить, сколько будет стоить доставка из США.
В одном подкасте я слышал фразу: "Вам будет очень сложно находиться в технической тусовке без Twitter". И это, кстати, правда. Очень много всего приходит именно оттуда. Да и вообще такое впечатление, что это основной способ общения инженеров из Долины.
Поэтому я вам иногда буду подкидывать интересных людей оттуда. И первой в списке пойдёт Джулия Еванс aka @b0rk — инженер и художница, которая рисует прекрасные скетчи по технической тематике и даже выпускает свой самиздатный журнал. И ведёт блог
Ну а по этой ссылке статья про Kubernetes (конечно же со скетчами!)
#kubernetes #twitter #people
Журнал, кстати, можно заказать в бумаге. Правда, я боюсь предположить, сколько будет стоить доставка из США.
X (formerly Twitter)
🔎Julia Evans🔍 (@b0rk) on X
find me on Mastodon or Bluesky
И в завершение темы, хочется поделиться прекрасно написанной историей в двух частях о том, почему контейнеры так и не стали "серебряной пулей".
Часть I: История внедрения, что может пойти не так, чего необъодимо избегать и чем Docker заменить.
Часть II: где запускать Docker. Плюсы, минусы, подводные камни разных Host OS
Ну и дополнительным действием поделюсь небольшим проектиком для управления контейнерами на локальном хосте.
Часть I: История внедрения, что может пойти не так, чего необъодимо избегать и чем Docker заменить.
Часть II: где запускать Docker. Плюсы, минусы, подводные камни разных Host OS
Ну и дополнительным действием поделюсь небольшим проектиком для управления контейнерами на локальном хосте.
The HFT Guy
Docker in Production: A History of Failure
Introduction My first encounter with docker goes back to early 2015. Docker was experimented with to find out whether it could benefit us. At the time it wasn’t possible to run a container [i…
P.S.
А ещё мы сегодня выловили интересный баг Джавы. Про него как-нибудь позже напишу
А ещё мы сегодня выловили интересный баг Джавы. Про него как-нибудь позже напишу
Forwarded from Devops Talks
Эволюция деплоя в Reddit - отличная статья которую стоит прочесть и скажем сравнить прогресс админов Reddit с вашим - https://redditblog.com/2017/06/02/the-evolution-of-code-deploys-at-reddit/
Как бы Telegram не был хорош, используют его в основном на постсоветском пространстве.
В Европе же и Северной Америке эту роль на себя берут другие мессенджеры. А в технической сфере особо популярны Slack-community. Преимущество их в том, что мало того, что Sack позволяет создавать кучу каналов внутри одного чата, так ещё и имеет возможность давать фидбэк, в отличии от тех же каналов Telegram.
Поэтому делюсь с вами сборником из тысячи Slack-communities на различную тематику.
Ну автор сборника утверждает, что тысяча — сам я не считал.
Ну и бонусом карта самых популярных мессенджеров по регионам
#slack #people #culture #tech
В Европе же и Северной Америке эту роль на себя берут другие мессенджеры. А в технической сфере особо популярны Slack-community. Преимущество их в том, что мало того, что Sack позволяет создавать кучу каналов внутри одного чата, так ещё и имеет возможность давать фидбэк, в отличии от тех же каналов Telegram.
Поэтому делюсь с вами сборником из тысячи Slack-communities на различную тематику.
Ну автор сборника утверждает, что тысяча — сам я не считал.
Ну и бонусом карта самых популярных мессенджеров по регионам
#slack #people #culture #tech
Medium
The Full List of 1000 Slack Communities
The number of Slack communities grew by 2.5 times since 2016. Explore them all.
Сегодня у нас достаточно старая статья (ей больше года) про сетевой уровень Интернет.
Статься большая: ~ 7000 слов, но очень интересная. Особенно в мире, где люди работают на высоких уровнях абстракции и не всегда задумываются о том, как сигнал идёт по кабелю, как сделать сеть между миром и Австралией и почему кабель не грызут акулы.
#hardware #internet #networking
Статься большая: ~ 7000 слов, но очень интересная. Особенно в мире, где люди работают на высоких уровнях абстракции и не всегда задумываются о том, как сигнал идёт по кабелю, как сделать сеть между миром и Австралией и почему кабель не грызут акулы.
#hardware #internet #networking
Ars Technica
How the Internet works: Submarine fiber, brains in jars, and coaxial cables
A deep dive into Internet infrastructure, plus a rare visit to a subsea cable landing site.
И вопрос вдогонку: имеет ли смысл переводить статьи (хотя бы некоторые)?
Негативные стороны такого подхода очевидны: я ни разу не лингвист и не переводчик — моя версия скорее всего будет местами нескладной и корявой. Кроме того, перевод будет занимать какое-то время и я просто не смогу оперативно делиться интересными материалами. Плюс, оригинал читать всегда лучше.
С другой стороны, я подозреваю, что кому-то из подписчиков читать по-русски будет удобнее. Отсюда, собственно, и опрос.
➕ - переводы Ок
➖ - и так сойдёт
Ну и сразу хочу предупредить, что переводить вот прямо всё я не буду — это просто бессмысленно для простых анонсов, репозиториев на GitHub и некоторых других штук
Негативные стороны такого подхода очевидны: я ни разу не лингвист и не переводчик — моя версия скорее всего будет местами нескладной и корявой. Кроме того, перевод будет занимать какое-то время и я просто не смогу оперативно делиться интересными материалами. Плюс, оригинал читать всегда лучше.
С другой стороны, я подозреваю, что кому-то из подписчиков читать по-русски будет удобнее. Отсюда, собственно, и опрос.
➕ - переводы Ок
➖ - и так сойдёт
Ну и сразу хочу предупредить, что переводить вот прямо всё я не буду — это просто бессмысленно для простых анонсов, репозиториев на GitHub и некоторых других штук
Сегодня я бы хотел рассказать про системы управления конфигурацией.
Это то, что играет огромную роль в подходе
Pets vs Cattle: статья, которая наглядно объясняет саму концепцию и для чего всё она нужна.
По три слова о самых популярных сервисах: Chef, Puppet, Ansible, Salt, PowerShell, Cobber (не совсем управление конфигурацией), CFEngine
Размышления о том, каким должен бы был быть инструмент для управления конфигурацией. В двух словах: stateless & declarative
Система управления конфигурациями, написанная на Go. С интересной идеей, но ужасной реализацией (там куча багов). Так что это скорее для общего ознакомления. GitHub
Ещё одна сравнительная статья. На этот раз на русском и только про Ansible vs Salt. Однако, в этой статье присутствует фраза о первичном назначении Ansible: закрытии бреши между Cobbler и Puppet. Хотя с тех пор проект сильно вырос.
И наконец, видео выступления с OpenStack Summit 2015. Да, давно это было (зато футболка с саммита жива до мих пор!) Однако, основные концепции то не поменялись.
#configManagement #puppet #chef #ansible #salt
Это то, что играет огромную роль в подходе
Infrastructure as s code, хотя, в принципе, можно обходиться без неё, но в большинстве компаний вы что-то подобное вы таки найдёте.Pets vs Cattle: статья, которая наглядно объясняет саму концепцию и для чего всё она нужна.
По три слова о самых популярных сервисах: Chef, Puppet, Ansible, Salt, PowerShell, Cobber (не совсем управление конфигурацией), CFEngine
Размышления о том, каким должен бы был быть инструмент для управления конфигурацией. В двух словах: stateless & declarative
Система управления конфигурациями, написанная на Go. С интересной идеей, но ужасной реализацией (там куча багов). Так что это скорее для общего ознакомления. GitHub
Ещё одна сравнительная статья. На этот раз на русском и только про Ansible vs Salt. Однако, в этой статье присутствует фраза о первичном назначении Ansible: закрытии бреши между Cobbler и Puppet. Хотя с тех пор проект сильно вырос.
И наконец, видео выступления с OpenStack Summit 2015. Да, давно это было (зато футболка с саммита жива до мих пор!) Однако, основные концепции то не поменялись.
#configManagement #puppet #chef #ansible #salt
Express news, так сказать.
В версии Terraform 0.10 все провайдеры собираются вынести из единого бинарника (terraform-core).
Собственно что такое Terraform: ещё один продукт HashiCorp, который добавляет ещё один уровень абстракции над API облачных платформ и позволяет вам указывать состояние инфраструктуры в виде файла(ов) конфигурации. Infrastructure as a Code as is. Если вам знаком Vagrant (тоже продукт Hashicorp) то вы можете представить, как это выглядит. Разница в том, что Vagrant обращается непосредственно к гипервизору, так что он хорош для локальных экспериментов, но не для большой инфраструктуры.
За время своего существования, Terraform вырос и кроме поддержка API известных платформ (AWS, Azure, OpenStack, GCE) у них есть поддержка других вещей, например, DNS (Neustar) и почие.
По большому счёту, всем, что имеет API, можно манипулировать с помощью провайдеров. Вот заметка моего бывшего сотрудника о том, как написать Terraform provider своими руками.
И ещё один хороший блог в том числе о Terraform. Его автор даже книгу о нём написал. Правда, я не дошёл до неё ещё, всё в рид-листе висит, но вот к записям в блоге частенько обращался.
И ещё один технический блог от Charity Majors — интересного человека в Twitter — о впечатлениях, связанных с сабжем.
#terraform #hashicorp
В версии Terraform 0.10 все провайдеры собираются вынести из единого бинарника (terraform-core).
Собственно что такое Terraform: ещё один продукт HashiCorp, который добавляет ещё один уровень абстракции над API облачных платформ и позволяет вам указывать состояние инфраструктуры в виде файла(ов) конфигурации. Infrastructure as a Code as is. Если вам знаком Vagrant (тоже продукт Hashicorp) то вы можете представить, как это выглядит. Разница в том, что Vagrant обращается непосредственно к гипервизору, так что он хорош для локальных экспериментов, но не для большой инфраструктуры.
За время своего существования, Terraform вырос и кроме поддержка API известных платформ (AWS, Azure, OpenStack, GCE) у них есть поддержка других вещей, например, DNS (Neustar) и почие.
По большому счёту, всем, что имеет API, можно манипулировать с помощью провайдеров. Вот заметка моего бывшего сотрудника о том, как написать Terraform provider своими руками.
И ещё один хороший блог в том числе о Terraform. Его автор даже книгу о нём написал. Правда, я не дошёл до неё ещё, всё в рид-листе висит, но вот к записям в блоге частенько обращался.
И ещё один технический блог от Charity Majors — интересного человека в Twitter — о впечатлениях, связанных с сабжем.
#terraform #hashicorp
HashiCorp - Cloud Infrastructure Automation
Upcoming Provider Changes in Terraform 0.10
HashiCorp enables organizations to have consistent workflows to provision, secure, connect, and run any infrastructure for any application.
Forwarded from DevOps News
Появились видеозаписи докладов с monitorama pdx 2017. Рекомендуется к просмотру всем кому не безразличен мониторинг и/или time series.
https://vimeo.com/channels/1255299
#monitorama #monitoring #video #tsdb #timeseries
https://vimeo.com/channels/1255299
#monitorama #monitoring #video #tsdb #timeseries
Vimeo
Monitorama PDX 2017 - Portland, OR
Join the web’s most supportive community of creators and get high-quality tools for hosting, sharing, and streaming videos in gorgeous HD with no ads.
Вот мне начали приходить запросы о темах. И первая звучала как: "что нужно знать о DevOps бекэнд программисту, чтобы наступило вселенское счастье".
Во-первых, DevOps — это методология, а не какая-то абстрактная должность. Соответственно, чтобы любому разработчику получить наибольшую отдачу от этого, надо даную методологию принять. Проблема в том, что при упоминании DevOps, каждый представляет что-то своё. Так что существует огромное число мнений на счёт того, как делать правильно.
Однако, есть несколько моментов, в которых практически все сходятся. С точки зрения разработчика, вы должны подумать хотя бы вот о чём:
- вы в ответе за то, что написали. Перебрасывать код через забор в надежде, что там разберутся — провальная тактика. Для того, чтобы так не происходило, надо иметь налаженную петлю обратной связи. Это может быть баг треккер, Джира и прочее.
- сокращайте срок релиза. Релиз вообще не должен быть каким-то событием. Аж в 2009 году John Allspaw и Paul Hammond из Flickr представили доклад 10 deploys per day. Это было 8 лет назад и сейчас колличество деплоев в компаниях возрало в разы. Короткие релизы позволяют быстрее найти проблему (если появится) исправить её или в крайнем случае релиз откатить
- для того, чтобы уверенно продвигаться вперёд, надо в первую очередь не бояться что-либо сломать. Во-первых, для этого у вас должен быть полноценный dev-environmet, который можно спокойно шатать. Во-вторых, очень важно развивать в компании культуру без взаимных обвинений
- общайтесь между собой. С одной стороны, офисы open space особо не улучшают общение в коллективе, с другой вам и не надо быть закадычным другом для всех коллег, вам не обязательно ходить вместе пить пиво. Достаточно понимать, что вы преследуете одну цель.
- учитесь на своих ошибках. Amazon представил. Есть метод "5ти почему". Например, недавние проблемы с AWS S3 был спровоцирован человеческим фактором, но никого после этого не уволили. Потому что как говорится "мы только что вложили несколько миллионов в твоё обучение"
- автоматизируйте это. Это к слову об ускорении времени между релизами. Для этого уже есть куча инструментов: CI/CD сервисы (о них как-нибудь напишу отдельно), сервисы для Continuous Code Analysis и прочее
- измеряйте это. Редко когда системой мониторинга и сбора статистики занимаются непосредственно разработчики, но только вы знаете, какие метрики для вас актуальны для анализа работоспособности приложения. Сложность современных систем соизмерима со сложностью летательных аппаратов. Не думать о мониторинге - всё равно, что строить самолёт без приборной доски
В довесок рекомендую вам почитать The Phoenix Project — единственную известную мне художественную книгу о DevOps. Плюс, Site Reliability Engineering. Есть ещё куча книг по данной тематике. Которыми я буду с вами по ходу пьесы делиться.
И да, как я говорил, мне можно писать и спрашивать об интересующих вещах. Ну а я в свою очередь расскажу о чём смогу в силу своей экспертизы. Вот вам даже специальный бот для этого: @AskCatOpsBot
#culture #devops
Во-первых, DevOps — это методология, а не какая-то абстрактная должность. Соответственно, чтобы любому разработчику получить наибольшую отдачу от этого, надо даную методологию принять. Проблема в том, что при упоминании DevOps, каждый представляет что-то своё. Так что существует огромное число мнений на счёт того, как делать правильно.
Однако, есть несколько моментов, в которых практически все сходятся. С точки зрения разработчика, вы должны подумать хотя бы вот о чём:
- вы в ответе за то, что написали. Перебрасывать код через забор в надежде, что там разберутся — провальная тактика. Для того, чтобы так не происходило, надо иметь налаженную петлю обратной связи. Это может быть баг треккер, Джира и прочее.
- сокращайте срок релиза. Релиз вообще не должен быть каким-то событием. Аж в 2009 году John Allspaw и Paul Hammond из Flickr представили доклад 10 deploys per day. Это было 8 лет назад и сейчас колличество деплоев в компаниях возрало в разы. Короткие релизы позволяют быстрее найти проблему (если появится) исправить её или в крайнем случае релиз откатить
- для того, чтобы уверенно продвигаться вперёд, надо в первую очередь не бояться что-либо сломать. Во-первых, для этого у вас должен быть полноценный dev-environmet, который можно спокойно шатать. Во-вторых, очень важно развивать в компании культуру без взаимных обвинений
- общайтесь между собой. С одной стороны, офисы open space особо не улучшают общение в коллективе, с другой вам и не надо быть закадычным другом для всех коллег, вам не обязательно ходить вместе пить пиво. Достаточно понимать, что вы преследуете одну цель.
- учитесь на своих ошибках. Amazon представил. Есть метод "5ти почему". Например, недавние проблемы с AWS S3 был спровоцирован человеческим фактором, но никого после этого не уволили. Потому что как говорится "мы только что вложили несколько миллионов в твоё обучение"
- автоматизируйте это. Это к слову об ускорении времени между релизами. Для этого уже есть куча инструментов: CI/CD сервисы (о них как-нибудь напишу отдельно), сервисы для Continuous Code Analysis и прочее
- измеряйте это. Редко когда системой мониторинга и сбора статистики занимаются непосредственно разработчики, но только вы знаете, какие метрики для вас актуальны для анализа работоспособности приложения. Сложность современных систем соизмерима со сложностью летательных аппаратов. Не думать о мониторинге - всё равно, что строить самолёт без приборной доски
В довесок рекомендую вам почитать The Phoenix Project — единственную известную мне художественную книгу о DevOps. Плюс, Site Reliability Engineering. Есть ещё куча книг по данной тематике. Которыми я буду с вами по ходу пьесы делиться.
И да, как я говорил, мне можно писать и спрашивать об интересующих вещах. Ну а я в свою очередь расскажу о чём смогу в силу своей экспертизы. Вот вам даже специальный бот для этого: @AskCatOpsBot
#culture #devops
17 июня (эта суббота) пройдёт очередной Kyiv DevOps meetup
У меня, к сожалению, быть там не получится. Однако, на таких меропритиях можно встретить кучу интересных людей, которые с радостью поделятся боевым опытом и всякими best practices. Да и докладчики интересные.
В общем, будет полезно не только матёрым 0дминам, но и разного рода разработчикам, студентам и желающим "вАйти". Кроме того, вся эта движуха бесплатна, по крайней мере раньше так было. Главное — зарегистрироваться через MeetUp. Ссылку я скинул.
Welcome!
#event
У меня, к сожалению, быть там не получится. Однако, на таких меропритиях можно встретить кучу интересных людей, которые с радостью поделятся боевым опытом и всякими best practices. Да и докладчики интересные.
В общем, будет полезно не только матёрым 0дминам, но и разного рода разработчикам, студентам и желающим "вАйти". Кроме того, вся эта движуха бесплатна, по крайней мере раньше так было. Главное — зарегистрироваться через MeetUp. Ссылку я скинул.
Welcome!
#event
Meetup
Kyiv DevOps
Come to the Kyiv DevOps meetup to learn more about and share information on the DevOps movement - culture, practices and tools.
This is a group for profess
This is a group for profess
Как-то мне рассказали о такой интересно штуке, как exception driven development. Это когда вы начинаете налавливать эксепшены и просто таки строить на них всю логику приложения. После такого в логе можно найти что-то типа:
Так вот, такого делать не надо. Анти-патерны окружают нас на самом деле повсюду и не только в сфере разработки приложений. Это я к тому, что завтра я бы хотел написать либо о анти-паттернах, либо о логах — ещё не решил.
А пока почитайте про другие пагубный паттерны в статье с прекрасным названием "Asshole-driven development"
#anti-pattern #development
This is not an error. Even foobar captured
Так вот, такого делать не надо. Анти-патерны окружают нас на самом деле повсюду и не только в сфере разработки приложений. Это я к тому, что завтра я бы хотел написать либо о анти-паттернах, либо о логах — ещё не решил.
А пока почитайте про другие пагубный паттерны в статье с прекрасным названием "Asshole-driven development"
#anti-pattern #development
Scott Berkun
Asshole-driven development
[Since this was originally posted commenters have added 100+ addition methods – see the comments below. There’s more commentary on reddit] The software industry might be the world’…
У меня выдался крайне загруженный день, поэтому написать что-либо вразумительное ни про логи, ни про анти-паттерны я тупо не успел.
Зато Puppetlabs тут сделали опрос, по которому вы можете определить, насколько глубоко DevOps практики засели в вашей компании.
Там всего 17 вопросов и мне выпало 'Advanced'. Хотя у нас далеко не все хорошо, там такой опрос, что получить не 'Advanced', наверное, сложно
С другой стороны, на основании подобных опросов они скорее всего делают ежегодный отчёт, так что ваш голос улучшит выборку
Зато Puppetlabs тут сделали опрос, по которому вы можете определить, насколько глубоко DevOps практики засели в вашей компании.
Там всего 17 вопросов и мне выпало 'Advanced'. Хотя у нас далеко не все хорошо, там такой опрос, что получить не 'Advanced', наверное, сложно
С другой стороны, на основании подобных опросов они скорее всего делают ежегодный отчёт, так что ваш голос улучшит выборку
Puppet
DevOps Assessment
Forwarded from Linuxgram 🐧 via @like
This media is not supported in your browser
VIEW IN TELEGRAM
Atom Editor 1.18 Released with Rich Git Integration
😁 goo.gl/3v7YVr
😁 goo.gl/3v7YVr
Forwarded from DevOps News
Опубликованы видеозаписи докладов с SREcon 2017 Asia. Отдельно хотел бы обратить внимание на доклад Golang's Garbage про некоторые особенности работы сборщика мусора в Golang.
Список докладов со ссылками на видео можно найти на официальной странице конференции:
https://www.usenix.org/conference/srecon17asia/program
#srecon #videos #sre
Список докладов со ссылками на видео можно найти на официальной странице конференции:
https://www.usenix.org/conference/srecon17asia/program
#srecon #videos #sre
Так вот, о логах. Я бы не хотел зострять на них внимания с точки хрения разработчика. Уже очень много было сказано о том, что логгировать необходимо только значимые события, дифференцировать разные уровни (ERROR, WARN, INFO, DEBUG, etc) и стараться стандартизировать сообщения. Об этом вы можете почитать здесь или тут
Я бы хотел акцентировать на том, что как бы вы их не писали, ходить и вручную собирать сообщения по серверам — плохая идея. Да и вообще, хранить их там долго — не очень хорошо. Логи могут тупо забить весь диск. Думаю, все слышали про ELK (elasticsearch + logstash+ kibana) для сбора, поиска и визуализации системных сообщений.
Это удобно, во-первых, потому что вам не надо рыскать по пачке машин в поисках ошибки, во-вторых, потому что упрощает capacity planning. Вы без проблем сможете прикинуть, сколько места вам понадобится под это дело, как часто надо чистить старые сообщения и т.д
Но всё-таки иногда в компаниях работают "по-старинке". Из моей практики, при этом подходе есть пару советов:
- ротируйте логи не по времени, а по размеру. Допустим, вы проводите ротацию раз в сутки и держите записи за неделю. Не исключён вариант, что произойдёт непредвиденное событие или же кто-то включит DEBUG mode и всего за пару часов лог вырастет до нескольких Гигабайт.
- не делайте ротацию логов внешней зависимостью. Да, существует logrotate, можно чистить логи по крону, но много лучше, когда этим занимается само приложение. По крйней мере, log4j в Java прекрасно это умеет
И да, всё же задумайтесь о централизованном логгировании. Конечно, это потребует дополнительных ресурсов, как на инфраструктуру, так и на людей, для поддержания этого дела. Но потом это сильно упростит вам жизнь при скейлинге. Или же можно просто купить поддержку готового решения, где головную боль о настройке и поддержании работоспособности возьмут на себя третьи лица (ествественно за деньги) Благо, таких решений хватает.
Ну и под конец, статья JetRuby со сравнительным обзором Graylog и ELK, наверное, самых известных системах централизованного хранения логов for free
#logs #elk #graylog
Я бы хотел акцентировать на том, что как бы вы их не писали, ходить и вручную собирать сообщения по серверам — плохая идея. Да и вообще, хранить их там долго — не очень хорошо. Логи могут тупо забить весь диск. Думаю, все слышали про ELK (elasticsearch + logstash+ kibana) для сбора, поиска и визуализации системных сообщений.
Это удобно, во-первых, потому что вам не надо рыскать по пачке машин в поисках ошибки, во-вторых, потому что упрощает capacity planning. Вы без проблем сможете прикинуть, сколько места вам понадобится под это дело, как часто надо чистить старые сообщения и т.д
Но всё-таки иногда в компаниях работают "по-старинке". Из моей практики, при этом подходе есть пару советов:
- ротируйте логи не по времени, а по размеру. Допустим, вы проводите ротацию раз в сутки и держите записи за неделю. Не исключён вариант, что произойдёт непредвиденное событие или же кто-то включит DEBUG mode и всего за пару часов лог вырастет до нескольких Гигабайт.
- не делайте ротацию логов внешней зависимостью. Да, существует logrotate, можно чистить логи по крону, но много лучше, когда этим занимается само приложение. По крйней мере, log4j в Java прекрасно это умеет
И да, всё же задумайтесь о централизованном логгировании. Конечно, это потребует дополнительных ресурсов, как на инфраструктуру, так и на людей, для поддержания этого дела. Но потом это сильно упростит вам жизнь при скейлинге. Или же можно просто купить поддержку готового решения, где головную боль о настройке и поддержании работоспособности возьмут на себя третьи лица (ествественно за деньги) Благо, таких решений хватает.
Ну и под конец, статья JetRuby со сравнительным обзором Graylog и ELK, наверное, самых известных системах централизованного хранения логов for free
#logs #elk #graylog