Обзор лесозаготовительной экосистемы в 2017 году

Логирование. Справедливо сказать, что это фундаментальный принцип современных вычислений. Это помогает разработчикам отлаживать приложения, а системные администраторы и сотрудники DevOps отлаживают сбои сервера. Следовательно, журналы имеют решающее значение для предоставления информации и контекста, необходимых для решения проблем, как по мере их возникновения, так и для понимания их в историческом контексте.

Но, как и все в вычислительной технике, состояние журналирования никогда не стоит на месте. Существующие концепции выходят из моды, а новые занимают их место, в то время как другие идеи оказываются вне времени — иногда они сохраняются годами. Та же самая схема применяется к инструментам и услугам, коммерческим или открытым исходным кодом, размещенным на или вне сайта.

Так где мы сейчас? Какие тенденции, инструменты и принципы в настоящее время господствуют и почему? Что ж, сегодня я рассмотрю три области экосистемы лесозаготовок, чтобы оценить, где находится отрасль в середине 2017 года.

В частности, я собираюсь взглянуть на некоторые из наиболее заметных:

• философий
• лучшие практики
• варианты обслуживания и инструмента

Прежде чем мы углубимся в это, я откровенно скажу: я считаю себя в первую очередь разработчиком, а затем системным администратором и разработчиком DevOps. В результате моя точка зрения и выбор, который я делаю в этой статье, окрашены соответствующим образом. Пожалуйста, имейте это в виду.

Тем не менее, давайте идти.

Философия лесозаготовительной экосистемы

Первая область, которую я хочу охватить, это лесозаготовки. В рамках этого я хочу взглянуть на две концепции: хранение журналов и культура ведения журналов.

Где и как хранить журналы?

Должны ли журналы храниться в службе, которой вы управляете сами, в своей организации? Или вы должны использовать SaaS, такой как Loggly, или один из других инструментов, о которых мы расскажем позже , для хранения данных журнала вне вашего прямого контроля?

Из того, что я понял, главное отличие — это вопрос безопасности и чувствительности данных. У вас есть информация, которую абсолютно никто не может увидеть за пределами вашей организации?

Если это так, то, вероятно, лучше разместить решение самостоятельно и войти в него, например, в Apache Kafka или в стек Elastic (ранее ELK) . Если ваши данные не так чувствительны, то лучшим решением может стать хост- решение от одного из коммерческих поставщиков, такого как Loggly , Graylog , SumoLogic и ElasticSearch .

Другое соображение, которое все еще кажется наполненным дискуссиями, такими как это в Hacker News , — это вопрос эффективности. В частности, стоит ли нам, как организации, усилий, чтобы создать собственное решение для ведения журналов, например, основанное на Elastic Stack, и управлять им? Или лучше разместить наши данные у поставщика?

На такой вопрос нет однозначного, универсального ответа. И самый последовательный ответ, который я продолжаю видеть до сих пор, это «это зависит». Нет двух одинаковых организаций или приложений. То, что работает для одного, не обязательно работает для другого. Можно было бы иметь больше ресурсов и опыта, доступных для назначения на задачу. Другой не может.

Таким образом, если в 2017 году в экосистеме лесозаготовок есть ключевая философская константа, все равно остается вопрос, где хранить данные журнала.

Приложение коляски

Новым — по крайней мере для меня — является концепция, называемая приложением коляски . Если вы не слышали об этом раньше, это в основном относится к развертыванию приложений с использованием контейнеров, поскольку оно сильно относится к развертыванию на основе контейнеров.

Гирлянда Кан из Loggly выражает это очень кратко, когда он описывает это как:

… Концепция соединения контейнера приложения и контейнера регистрации.

Voxxed обеспечивает большую глубину, когда они описывают это так:

Параллельное приложение развертывается рядом с каждым микросервисом, который вы разработали и развернули на экземпляре сервера / хостинга. Он концептуально привязан к «родительской» службе, так же, как к мотоциклу прикреплена коляска для мотоцикла — отсюда и название. Коляска работает вместе с вашим сервисом как второй процесс и предоставляет «функции инфраструктуры платформы», предоставляемые через однородный интерфейс, такой как REST-подобный API через HTTP.

В контексте ведения журнала в развернутый стек будет добавлен дополнительный контейнер, в котором будут храниться журналы приложения, и который также может пересылать эти журналы во внешнюю службу, такую ​​как LogEntries или Splunk. Из того, что я понимаю, концепция может хорошо работать для небольших приложений, но может быть трудно эффективно масштабировать. Тем не менее, это интересная концепция все же.

Культура лесозаготовок

Теперь давайте посмотрим на культуру — слишком важный аспект любой инициативы. Чтобы перейти к сути, недавно меня поразила цитата из Stackify , когда они сказали:

… мы создали «культуру лесозаготовок» …

Я считаю это одним из лучших улучшений за последние годы, потому что без поддержки культуры идеи и концепции, скорее всего, будут в лучшем случае преходящими. Я уверен, что большинство из нас могут относиться к тому, что в прошедшие годы, когда началось тестирование. Сначала оно всегда работало великолепно. Но если поддерживающей культуры не было, она быстро отошла на второй план, когда сроки и другие нагрузки начали накапливаться.

В этой статье Stackify продолжает:

[Культура лесозаготовок] ставит своей целью достижение следующих целей:

Войти все вещи. Регистрируйте столько, сколько возможно, чтобы всегда иметь релевантные контекстные журналы, которые не добавляют накладных расходов. Работай умом, а не силой. Консолидация и агрегирование всех наших лесозаготовок в центральном месте, доступном для всех разработчиков и легко перегонять. Кроме того, чтобы найти новые способы для наших данных регистрации и исключений, чтобы помочь нам активно улучшать наш продукт.

Здесь есть несколько отличных моментов, два из которых, в частности, стоит распаковать.

Зарегистрируйте столько, сколько возможно

Вопреки тому, что я видел и испытывал в предыдущие годы, это выражает важность регистрации больше, а не меньше — до тех пор, пока эта информация является контекстной. Это хорошо согласуется с тем, что Сумологик написал в апреле 2017 года, когда они сказали:

Ваши журналы должны рассказать историю.

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

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

Вход в центральное место, доступный для всех разработчиков

То, что информация доступна всем, является еще одним отрадным событием, которое становится все более и более сильным.

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

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

Зарегистрируй бесплатный аккаунт Codeship

Лучшие практики

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

Кажется, все согласны с тем, что люди лучше работают с данными, которые не логичны, непротиворечивы или обладают стандартным шаблоном, а компьютеры — нет. И наоборот, люди не умеют обрабатывать большие объемы данных, а компьютеры — хороши. Учитывая это, перед нами стоит задача: мы создаем журналы, с которыми люди могут работать на индивидуальной основе, или мы делаем их эффективными для компьютерной обработки, а затем делаем их читаемыми?

Я обнаружил, что, если вы не регистрируете только небольшое количество информации, все согласны с тем, что лучше сосредоточиться на эффективности обработки с максимально возможным контекстом, а не на удобочитаемости человеком.

Но как выглядит эффективная, богатая контекстом запись в журнале? Дэн Рейхарт (из SumoLogic) приводит в качестве примера следующее из вымышленной службы бронирования авиабилетов:

Подводя итог, каждый элемент в записи разделен -последовательностью. И элементы по порядку:

1. Временная метка журнала
2. Имя пользователя покупателя
3. IP-адрес пользователя
4. Метод запроса
5. Запрашиваемый ресурс
6. Шлюз запроса или путь
7. Запрашиваемый статус
8. Количество купленных рейсов
9. Общая стоимость полета

Если бы у нас была какая-то часть этой информации, мы бы смогли узнать только часть истории, если что-нибудь. Но, храня всю эту информацию, которая, кстати, довольно хорошо сжимается, мы в состоянии узнать все, что нам нужно знать, чтобы решить проблему. Журнал краткий, но читаемый, рассказывает историю и следует стандартному предсказуемому шаблону. Есть и другие способы выразить себя, но это только один из них.

Но коммерческие поставщики не единственный выбор в 2017 году. Некоторые инструменты с открытым исходным кодом также растут в зрелости. Фактически, в третьем ежегодном отчете Руководства по Open Cloud от Linux Foundation были выделены два: Fluentd , сборщик данных для унифицированных слоев журналирования, и LogStash , конвейер обработки данных на стороне сервера. Другими инструментами с открытым исходным кодом, которые стоит рассмотреть, являются syslog-ng , LOGalyze и Apache Flume .

Учитывая, что, в зависимости от вашего опыта, потребностей и бюджета, у вас не будет недостатка в выборе в этом году. Там будет несколько вариантов, из которых вы можете выбрать тот, который наилучшим образом соответствует вашим потребностям.

Вывод

И это широкий обзор нескольких ключевых факторов в экосистеме лесозаготовок в 2017 году.

Мы рассмотрели текущие принципы, такие как, где и как должны храниться журналы, и концепцию приложения коляски. Мы обсудили, насколько важна культура ведения журнала для успеха ведения журнала в организации, и как больше контекстной регистрации лучше, чем меньше. И мы закончили, посмотрев на некоторых из ключевых игроков на рынке в 2017 году.

Я что-то пропустил? Вы не согласны? Поделитесь своими мыслями в комментариях.