Привет, Хабр!

Меня зовут Рустем, являюсь Senior DevOps Engineer в компании IBM, город Краков.

Недавно я рассказал, как можно задеплоить приложение в кластер Openshift в IBM Cloud, а сегодня я хотел бы рассказать, как за этим всем следить. Что же нам понадобится? Нам сегодня понадобится кластер в IBM Cloud и LogDNA для мониторинга и алертинга.

Давайте начнем с вводной, что же это за инструменты?

IBM Cloud

IBM Cloud — это набор услуг облачных вычислений для бизнеса, предлагаемых компанией информационных технологий IBM . Он объединяет платформу как услугу (PaaS) с инфраструктурой как услуга (IaaS). Платформа масштабируется и поддерживает как небольшие группы разработчиков и организации, так и крупные предприятия. Он глобально развернут в центрах обработки данных по всему миру. Основными конкурентами IBM на рынке облачных вычислений являются Amazon Web Services , Microsoft Azure и Google Cloud Platform.

LogDNA

LogDNA — это платформа наблюдения для управления вашими данными и выполнения действий с ними. Он принимает, обрабатывает и направляет данные журналов для обеспечения разработки и доставки приложений на уровне предприятия, обеспечения безопасности и соответствия требованиям.

LogDNA был воплощен в жизнь трехкратными соучредителями Крисом Нгуеном и Ли Лю и включен в зимнюю партию Y Combinator 2015 года. В 2018 году LogDNA заключила партнерское соглашение с технологическим гигантом IBM, чтобы стать единственным поставщиком журналов для IBM Cloud.

Распределенное ведение журналов с помощью LogDNA и OpenShift в IBM Cloud

Облачное приложение, основанное на микросервисах, содержит множество частей, которые пишут логи. Обычно хорошей практикой будет использовать службу сбора логов, которая может собирать все распределенные логи в одном месте. Существует множество решений для сбора и анализа логов, которые можно установить непосредственно в кластер Kubernetes или OpenShift, но тогда у вас появится дополнительное приложение, которое необходимо поддерживать, и еще одно, которому также требуется постоянное хранилище для хранения логов в течение определенного периода времени.

IBM Cloud предлагает «Службу ведения логов как услугу» в форме IBM Log Analysis с LogDNA. Он предлагает функции для фильтрации, поиска и сбора логов, алертинга и создания настраиваемых правил для мониторинга приложений и системных логов.

Время практики!

Шаг 1. Создадим службу LogDNA.

  1. В браузере войдем в панель управления IBM Cloud.

  2. В бургерном меню выберем «Observability».

Шаг 2. Создадим экземпляр «IBM Log Analysis с LogDNA».

  1. Выберем «Logging» слева.

  2. Нажмем «Create a logging instance».

Шаг 3. В следующем диалоговом окне:

  1. Выберем регион, близкий к нашему кластеру OpenShift.

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

  3. Прокрутим немного вниз.

  4. Оставим имя службы и группу ресурсов «По умолчанию».

  5. Нажимаем «Создать» в нижней части диалогового окна.

Шаг 4. Нажмем на “Edit log sources”

Шаг 5. Выберем вкладку «OpenShift». Скопируем и выполним следующие команды в IBM Cloud Shell:

Шаг 6. Давайте проверим, запущен ли агент логирования в нашем кластере.

Вводим команду в наш IBM CloudShell: oc get all -n ibm-observe

Шаг 7. Перейдем в наш LogDNA.

Вернемся в наш дэшборд IBM Cloud.

В бургерном меню выберем «Observability».

В меню ««Observability»» выберем «Logging».Ё

Нажмем «View LogDNA».

Шаг 8. Просмотрим наш дэшборд LogdNA.

Откроем выпадающее меню «All apps» и выберем поды, которые мы хотим промониторить.

Шаг 9. Создадим правило алертинга, пусть наш сервис будет отправлять нам алерт, когда наше приложение отдает 500-е ошибки.

Введем в поисковое меню внизу следующее: response:(>=500 <600)

Как мы видим, таких ошибок еще не было зарегистрировано.

Теперь нажимаем на “Unsaved view” в левом верхнем углу и сохраняем наш “View” и выбираем “Save as a new view”.

Даем название нашему “View” и категоризируем его как “Error” и сохраняем.

Шаг 10. Создадим наш алерт. Нажмем на “Attach an alert”.

Выбираем “View-specific alert” и выбираем куда будем отправлять наш алерт (slack, email, sysdig, pagerduty или webhook для стороннего приложения).

Будем слать наши алерты в Slack в канал “Operation team”.

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

Наш алерт сохранен и увидеть его можно в левом меню во вкладке “Errors”.

Готово! Мы подняли мониторинг в нашем кластере и настроили алертинг.


Уже сегодня в 20:00 в OTUS состоится открытое занятие, на котором попытаемся разобраться в контейнеризации и рассмотрим ее отличие от виртуализации. Также рассмотрим самый популярный инструмент по работе с контейнеризацией — docker. Регистрация — по ссылке.

Комментарии (0)