Привет, Хабр! Меня зовут Раиса. Я работаю в компании DINS старшим инженером по нагрузочному тестированию. Сегодня я хочу поговорить об энваройнментах. Ни для кого не секрет, что энвайронмент (environment) — это основная рабочая площадка тестировщика. Если у программиста — это любимая IDE, то у тестировщика — милый и родной энвайронмент.
Но что делать, если энв (здесь и далее энв, энвайронмент, окружение, стенд, подразумевают одно и то же) общедоступный? То есть и разработчики, и тестировщики, и даже другие команды, админы и прочие могут прийти и что-то на энве изменить, случайно или специально. Так было и у нас, но потом мы настроили мониторинг для наших окружений и теперь живем мирно и счастливо. Далее расскажу, как это было.
Спойлер
Это не про Zabbix и не про мониторинг приложений. Статья скорее про отслеживание пользовательских действий на окружении.
Внимание
В статье много английских терминов, написанных русским языком. Борцам за русский язык и противникам англицизмов рекомендовано воздержаться от прочтения =). А, если серьёзно, то я считаю неправильным переводить каждое слово на русский, ведь мы так в обычной айтишной жизни не разговариваем. Переводя каждый термин в русский эквивалент, мы даже иногда получаем подмену понятий. Я хочу сохранить оригинальность (не в смысле необычность, а в смысле точность) своей мысли, поэтому текст написан так, как написан.
Я уверена, что каждый из вас подумал: «Забрать у всех доступы!». И в целом это самое простое и очевидное решение. Нет бардаку! Или «You shall not pass» еще на доступах к энву.
Однако, я хочу показать, как мы никому ничего не запрещали и превратили «You shall not pass» в «You shall not pass without notification». А именно расскажу, как мы настроили мониторинг для наших окружений и живём мирно и счастливо.
Проблема
В нашей компании очень большие стенды. Эти стенды включают в себя компоненты не только команды, в которой мы работаем, но и компоненты других команд, которые постоянно релизятся, то есть их нужно обновлять. Кроме того, эти компоненты могут иметь зависимости, а значит обновление одного компонента может повлечь за собой обновление всего стенда или проблемы несовместимости. Процесс этот, как вы понимаете, занимает время. Но это ещё не вся проблема. С энвами работают много инженеров — разработчики могут прийти что-то потраблушутить, в процессе изменив конфиги. Тестировщиков в команде несколько. Работать они могут распределено и над разными задачами, то есть необходимы разные конфигурации. И частые проблемы, с которыми мы сталкиваемся, — это мисконфигурации (ошибки конфигурации) или одновременная работа, когда один обновляет энв, а другой решил потестировать и т.п.
Как я уже говорила, отнять права не совсем тот метод, который нам подходил, поэтому мы настроили мониторинг энва. И теперь знаем, кто и что на нем делает.
Что можно мониторить?
Давайте прикинем, что именно можно мониторить.
Деплойменты на энве
Узнаем, кто, когда и что задеплоил, чтобы не пропустить процесс установки обновлений и не запустить в это время свои тесты.Изменение конфигурации энва
Апликейшены конфигурируются через деплоймент системы, а значит, можно следить и за этим, ведь от одного параметра могут зависеть судьбы целых фич.Запуски автотестов
Если запуски происходят через специальные инструменты (например, gitlab CI, Jenkins, TeamCity), то можно и их отслеживать. Запустились тесты — все знают, что бежит прогон и лучше энв не трогать.Репорты от автотестов
Лень — двигатель прогресса. Зачем ходить смотреть, когда прогон закончится, когда можно мониторить это автоматом, а ещё в придачу слать короткий репорт — успешно, не успешно.Логи (ошибки в логах)
Представьте, вы запустили прогон или гоняете тесты, а серверов у вас несколько сотен (кстати, актуальная проблема для перфоманс-тестирования). Долго и неудобно ходить на каждый сервер и смотреть, нет ли в логах ошибок. Это могут быть ошибки нескольких видов: Uncaught Exceptions, Null Pointer Exceptions и другие. Можно написать скрипт, который будет ходить за вас и проверять. А можно следить за базовыми критическими ошибками с помощью специальных инструментов и получать нотификации сразу, когда они возникают. Речи о таких инструментах в данной статье не будет (попрошу коллег-экспертов про это написать).
Как мониторить?
Итак, мы определились с тем, что хотели бы мониторить. Теперь можно подумать, как именно это делать? Ну, и в век мессенджеров грех не воспользоваться API мессенджеров и интеграциями, чтобы отслеживать состояние энва.
Чем это удобно?
Во-первых, нет необходимости специально куда-то ходить. Ведь чатами мы пользуемся постоянно. Таким образом, если с энвом что-то происходит, то нотификация придет в настроенный чат, и вы сразу об этом узнаете.
Во-вторых, у вас появляется история работы с энвом, причем в хронологическом порядке. Это может быть полезно при инвестигации возникающих проблем.
В-третьих, все заинтересованные люди могут подписаться на этот чат и следить на энвом вместе с вами.
Именно так мы и сделали (тем более что пользуемся корпоративным мессенджером) — мы стали слать хуки в наш мессенджер от всех сервисов: внутренней деплоймент-системы, «Гитлаба», «Дженкинса» и др. Теперь, когда у нас кто-то изменяет значение переменной в деплоймент-системе, мы об этом сразу узнаем. Когда кто-то нажимает даже кнопку «Построить деплоймент-план» — мы тоже об этом знаем. Запустили прогон автотестов — нотификация, закончился прогон — нотификация. И всё это в одном чате.
Реализация
Как выглядит общая картина наших нотификаций? У нас есть командный энвайронмент, который деплоится специальной системой. Тесты запускаются из другой системы, и на энве находятся другие скрипты. Во все эти системы мы встроили отправку уведомлений в наш специальный чат для нотификаций, как показано на картинке ниже.
Бывают разные механизмы отправки таких сообщений — вебхуки, боты, API. Хоть что-то из этого есть в любом современном мессенджере.
Механизм вебхуков
Вебхук (webhook) — это автоматическая отправка сообщения о событии.
То есть на стороне мессенджера в нужном чате мы создаем средствами этого мессенджера вебхук (по сути специальный URL), и теперь у нас есть возможность отсылать в этот чат из любых скриптов, систем, просто curl-ом или постманом сообщения. Сообщения эти должны содержать определённый пейлоад, который поддерживает вебхук.
Пример:
POST "https://hooks.some_messenger.com/webhook/1ww4345345"
{
"icon":"https://icon-library.com/images/gitlab-icon/gitlab-icon-19.jpg",
"activity":"Gitlab pipeline start/stop environment",
"body":"Run graceful shutdown; Current EC pool: $INSTANCE_ID"
}Механизм чат-ботов
Чат-бот — это программа, которая ведёт себя как пользователь, может писать в чат сообщения, выполнять логику. В случае с чат-ботом есть несколько способов реализации. Например, когда вы по сути реализуете вебхук в чат-боте и дальше работаете с ним как с вебхуком.
Второй способ, это когда чат-бот сам опрашивает системы в заданном интервале времени. Это так называемый Polling. Но этот способ меньше подходит для нотификаций, так как наш чат не будет содержать исторически верную и актуальную информацию.
API мессенджера
API мессенджера — это программный интерфейс, который предоставляет мессенджер для работы с ним. Здесь необходимо напрямую получать ключи для доступа к API, класть их в системы, поддерживать формат постов, то есть контракт. Этот способ лучше использовать в чат-боте, а чат-ботом предоставить вебхук.
Примеры нотификаций
Давайте посмотрим примеры всех этих уведомлений.
Внимание
Часть информации на картинках будет скрыта или написана русскими буквами, чтобы не было понятно, что там скрывается на самом деле. Это сделано из соображений безопасности и NDA. Прошу понять и простить!
Событие: деплоймент на энве
При каждом деплое на окружение приходит уведомление. На картинке представлен стилизованный вариант, точный вид будет зависеть от того, какую информацию умеет отдавать система деплоя, и что поддерживает на входе «получатель» — мессенджер. В нашем случае уведомление содержит:
факт события,
идентификацию того, кто совершил действие,
статус деплоя,
ссылку на более детальный статус.
Можно добавить креатива: кастомные сообщения, картинки, данные о том, как меняются версии компонент и т.п.
Событие: изменение конфигурации энва
Здесь мы также видим кто, какой параметр и на что изменил. Бывает даже полезно смотреть на историю. Сколько было случаев, когда кто-то поменял один параметр и тесты упали?! Когда у нас есть чат, мы видим, вот изменился параметр и следом был запуск тестов, которые упали. Возможно, параметр и не причина, но уже есть с чего начать исследование.
Событие: запуски автотестов
Эти сообщения можно расширить. Например, добавить информацию о том, из какой ветки и с какими параметрами был произведен запуск.
Пример кода для gitlab-ci конфига, чтобы такие нотификации поддержать:
.run_custom_test:
stage: run
script:
- |
curl -H "Content-Type:application/json" \
-X POST "https://hooks.some_messenger.com/webhook/1ccc3456-56456-7687-ba435" \
--data "{\"icon\":\"https://gitlab.com/uploads/-/system/project/avatar/1045538/runner_logo.png\", \
\"activity\":\"Gitlab pipeline performance run\",\"body\":\"custom test ${TEST} STARTED\"}"
cd performance && ./custom_test.bash -t \"${TEST}\" -p \"${PARAMS}\" -l \"${LOGGING}\""
- mkdir $CI_PROJECT_DIR/report
- |
curl -H "Content-Type:application/json" \
-X POST "https://hooks.some_messenger.com/webhook/1ccc7f26-ba94-d38" \
--data "{\"icon\":\"https://pbs.twimg.com/profile_images/676931722437619713/ut7aoBH3_400x400.png\", \
\"activity\":\"Gitlab pipeline performance run\",\"body\":\"custom test ${TEST} FINISHED\"}"
allow_failure: false
artifacts:
paths:
- report
Событие: репорты или отчёты о прогонах
Можно выводить репорты от любых прогонов с любыми кастомными полями.
Здесь не слишком подробные репорты. Все только самое важное (об этом ещё поговорим в конце). Здесь есть ссылка на прогон и базовая статистика. Вывели только то, что хотим мониторить, что важно в текущих реалиях нашей разработки.
Событие: ошибки в логах
Тут выведен сервер, на котором случилась ошибка, и выведена сама ошибка. Есть вся необходимая информация для того, чтобы пойти изучать возникшую проблему.
Вроде есть много информации о состоянии энва. Но что, если часть энва (как у нас) задеплоена в Амазоне (AWS Amazon) и включается, выключается, частично конфигурится, изменяется с помощью Terraform-скриптов и Ansible.
Здесь тоже не оказалось проблемы — в пайплайны, запускающие эти скрипты, мы дописали строчки для отправки хуков в наш мониторинг чат. Ниже представлен пример такого уведомления.
Пример кода такой же, как и для запуска тестов через «Гитлаб»:
graceful_shutdown:
stage: graceful_shutdown
variables: ANSIBLE_CONFIG: ansible.cfg
script:
- |
curl -H "Content-Type:application/json" \
-X POST "https://hooks.some_messenger.com/webhook/1ww-4309-ba94" \
--data "{\"icon\":\"https://icon-library.com/images/gitlab-icon/gitlab-icon-19.jpg\", \
\"activity\":\"Gitlab pipeline start/stop environment\",\"body\":\"Run graceful shutdown; Current EC pool: $INSTANCE_ID\"}"
- ansible-playbook services.yml -v --extra-vars "service_state=$STATE" --tags "stop"
- |
curl -H "Content-Type:application/json" \
-X POST "https://hooks.some_messenger.com/webhook/1ww-4309-ba94" \
--data "{\"icon\":\"https://icon-library.com/images/gitlab-icon/gitlab-icon-19.jpg\", \
\"activity\":\"Gitlab pipeline start/stop environment\",\"body\":\"All services shutdown successfully; Current EC pool: $INSTANCE_ID\"}"
tags:
- docker
- ansible
- perf
only:
refs:
- web
- schedules
variables:
- $STATE == "off"Кроме таких уведомлений в чат (скорее о действиях на эвне, чем о состоянии) у нас ещё есть дашборд о состоянии самих сервисов. В нем отображаются следующие вещи:
определяется состояние: включен или выключен.
Запрашиваются сервис чеки.
Определяется состояние зависимостей каждого компонента.
Так, например, если сам сервис включен и работает, а его критичная зависимость нет, то он будет помечен как неработающий.
Выводы
О чем важно сказать ещё? Про сами нотификации и их содержимое. Они должны быть лаконичными и показывать что, где, когда и кто сделал определенное действие. Здесь, наверное, тот момент, когда лучшее враг хорошего. В попытках вывести много полезной информации можно засорить и чат, и восприятие. И суперполезный чат может превратиться в бесполезный.
Всё ли теперь мы знаем про энв? На самом деле нет. И вот почему:
мы не отслеживаем, если кто-то выключит или изменит машины напрямую (не через Terraform и Python скрипты), а в Amazon консоли. В этом случае мы останемся в неведении. То же самое распространяется на активности на самих машинах.
Если кто-то выключит что-то руками, включит, изменит — мы об этом не узнаем.
Если кто-то запустит вручную тесты — мы тоже об этом не узнаем.
Можно ли это тоже мониторить? Можно. Но стоит ли игра свеч? Я считаю, что пока нет, и поэтому эти действия остаются на совести каждого, кто использует наш энвайронмент.
Можно поспорить, что это не совсем мониторинг, а скорее алертинг. Но я исходила из логики, что в переводе «monitoring» — это наблюдение, отслеживание, контроль. И мы пристально следим за действиями на нашем энве, то есть мониторим его.
В финале хочется подсветить основную идею того, что можно не запрещать использовать энвайронмент, как этого хотелось изначально. Вместо этого имеет смысл настроить несложные оповещения о важных для вас событиях на энве, облегчив жизнь себе и другим.
You shall not pass without notification!
Спасибо, что прочитали! Пишите в комментариях, мониторите ли свои энвы? Может быть у вас есть другие способы решения этой задачи?
P.S.: Напоследок хочу сказать спасибо всем, кто помогал вычитывать эту статью и предлагал идеи по улучшению. А также команде Glip за огромное количество чатов с нотификациями =)
