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

Мониторинг — это основная возможность группы инженеров по обеспечению надежности площадок (SRE). Вам нужно знать, если что-то происходит с вашим приложением, что влияет на работу конечного пользователя, как можно скорее. Кроме того, ваш мониторинг должен помочь вам как можно скорее определить основную причину. Вот основные функции мониторинга.

·Предоставляет информацию о работоспособности службы.

· Он позволяет создавать оповещения на основе настраиваемого порога.

· Вы можете использовать мониторинг для анализа тенденций и планирования загрузки.

· Он предоставляет подробные сведения о различных подсистемах, составляющих ваше приложение или службу.

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

· Визуализация и отчеты — это то, что делает анализ данных мониторинга эффективным и помогает вам поделиться найденным с другими.

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

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

Метрики — это золотой стандарт мониторинга, это численное измерение компонента.

Когда вы выбираете систему мониторинга для своей команды SRE, вы можете задать четыре вопроса, чтобы выбрать правильный инструмент.

1. Скорость: скорость относится как к тому, насколько быстро данные поступают в систему мониторинга, так и к тому, насколько быстро вы можете получить данные из системы мониторинга.

2. Разрешение: относится к разрешению данных.

3. Оповещение: возможности оповещения, которые может предоставить инструмент мониторинга.

4. Пользовательский интерфейс, насколько богатым и универсальным является пользовательский интерфейс.

Теперь давайте подробно рассмотрим каждый из этих вопросов.

Скорость: насколько свежими должны быть данные. Чем свежее данные, тем лучше. Вы не хотите просматривать данные двухчасовой давности. Вы хотите, чтобы данные были как можно более оперативными. Однако прием данных и оповещение о данных в реальном времени может быть дорогостоящим. Возможно, вам придется инвестировать в такие платформы, как Sumologic, Splunk или InfluxDB, чтобы реализовать это. Рассмотрите цели уровня обслуживания (SLO), чтобы определить, насколько быстрой должна быть система мониторинга.

Например, если ваш SLO составляет 2 часа, вам не нужно вкладывать средства в системы, которые обрабатывают машинные данные в режиме реального времени. Запросы больших объемов данных могут быть неэффективными. Опять же, вам, возможно, придется инвестировать в такие платформы, как Sumologic, Splunk, InfluxDB или Elasticsearch, если вам нужно очень быстрое извлечение данных.

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

Оповещения. Когда дело доходит до оповещений, убедитесь, что инструмент мониторинга можно интегрировать со многими сторонними инструментами. Например, может ли ваша система мониторинга пейджинговать кого-либо с помощью таких интеграций, как PagerDuty или VictorOps? В качестве другого примера, может ли ваша система мониторинга интегрироваться с ServiceNow для открытия заявки? Ваша система мониторинга должна иметь возможность классифицировать предупреждения в зависимости от их серьезности.

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

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

Мониторинг жестких ресурсов

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

Память необходимо контролировать. Здесь память указывает как на память приложения, так и на системную память. Память приложения, например, может быть размером кучи Java в приложении Java.

Дисковый ввод-вывод. Многие приложения сильно зависят от ввода-вывода, поэтому важно отслеживать дисковый ввод-вывод. Объем диска. Я столкнулся со многими сбоями из-за переполнения файловой системы. Вам необходимо следить за размерами всех ваших файловых систем.

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

Рекомендации по эффективному мониторингу

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

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

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

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

Нажмите кнопку "Подписаться", чтобы увидеть больше материалов по проектированию надежности сайта и DevOps.