Меня зовут Раиса. Я работаю в компании DINS старшим инженером по нагрузочному тестированию. Сегодня я хочу поговорить об энваройнментах. Ни для кого не секрет, что энвайронмент (environment) — это основная рабочая площадка тестировщика. Если у программиста — это любимая IDE, то у тестировщика — милый и родной энвайронмент.
Но что делать, если энв (здесь и далее энв, энвайронмент, окружение, стенд, подразумевают одно и то же) общедоступный? То есть и разработчики, и тестировщики, и даже другие команды, админы и прочие могут прийти и что-то на энве изменить, случайно или специально. Так было и у нас, но потом мы настроили мониторинг для наших окружений и теперь живем мирно и счастливо. Далее расскажу, как это было.
Спойлер
Это не про Zabbix и не про мониторинг приложений. Статья скорее про отслеживание пользовательских действий на окружении.
Внимание
В статье много английских терминов, написанных русским языком. Борцам за русский язык и противникам англицизмов рекомендовано воздержаться от прочтения =). А, если серьёзно, то я считаю неправильным переводить каждое слово на русский, ведь мы так в обычной айтишной жизни не разговариваем. Переводя каждый термин в русский эквивалент, мы даже иногда получаем подмену понятий. Я хочу сохранить оригинальность (не в смысле необычность, а в смысле точность) своей мысли, поэтому текст написан так, как написан.
Я уверена, что каждый из вас подумал: «Забрать у всех доступы!». И в целом это самое простое и очевидное решение. Нет бардаку! Или «You shall not pass» еще на доступах к энву.
Однако, я хочу показать, как мы никому ничего не запрещали и превратили «You shall not pass» в «You shall not pass without notification». А именно расскажу, как мы настроили мониторинг для наших окружений и живём мирно и счастливо.
Как я уже говорила, отнять права не совсем тот метод, который нам подходил, поэтому мы настроили мониторинг энва. И теперь знаем, кто и что на нем делает.
Чем это удобно?
Общая картина нотификаций
Бывают разные механизмы отправки таких сообщений — вебхуки, боты, API. Хоть что-то из этого есть в любом современном мессенджере.
Схематичная работа вебхука
То есть на стороне мессенджера в нужном чате мы создаем средствами этого мессенджера вебхук (по сути специальный URL), и теперь у нас есть возможность отсылать в этот чат из любых скриптов, систем, просто curl-ом или постманом сообщения. Сообщения эти должны содержать определённый пейлоад, который поддерживает вебхук.
Пример:
POST "https://hooks.some_massenger.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. Но этот способ меньше подходит для нотификаций, так как наш чат не будет содержать исторически верную и актуальную информацию.
[IMG alt="Схематичная работа чат-бота для нотификаций
"]https://habrastorage.org/r/w1560/ge...e0dd52b66f02bbae60889b4e.jpg[/IMG]Схематичная работа чат-бота для нотификаций
[IMG alt="Схематичная работа механизма API для нотификаций
"]https://habrastorage.org/r/w1560/ge...c8b0bb631b792a63ea540cca.jpg[/IMG]Схематичная работа механизма API для нотификаций
Примеры нотификаций
Давайте посмотрим примеры всех этих уведомлений.
Внимание
Событие: деплоймент на энве
Пример нотификации о деплойменте
При каждом деплое на окружение приходит уведомление. На картинке представлен стилизованный вариант, точный вид будет зависеть от того, какую информацию умеет отдавать система деплоя, и что поддерживает на входе «получатель» — мессенджер. В нашем случае уведомление содержит:
Событие: изменение конфигурации энва
Пример нотификации об изменении конфигурации на энве
Здесь мы также видим кто, какой параметр и на что изменил. Бывает даже полезно смотреть на историю. Сколько было случаев, когда кто-то поменял один параметр и тесты упали?! Когда у нас есть чат, мы видим, вот изменился параметр и следом был запуск тестов, которые упали. Возможно, параметр и не причина, но уже есть с чего начать исследование.
Событие: запуски автотестов
Пример нотификации о запуске прогона
Эти сообщения можно расширить. Например, добавить информацию о том, из какой ветки и с какими параметрами был произведен запуск.
Пример кода для 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-3d3c-4309-ba94-d380351340b7" \
--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_massenger.com/webhook/1ww4345345-3d3c-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_massenger.com/webhook/1ww4345345-3d3c-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"
Кроме таких уведомлений в чат (скорее о действиях на эвне, чем о состоянии) у нас ещё есть дашборд о состоянии самих сервисов. В нем отображаются следующие вещи:
Всё ли теперь мы знаем про энв? На самом деле нет. И вот почему:
Можно поспорить, что это не совсем мониторинг, а скорее алертинг. Но я исходила из логики, что в переводе «monitoring» — это наблюдение, отслеживание, контроль. И мы пристально следим за действиями на нашем энве, то есть мониторим его.
В финале хочется подсветить основную идею того, что можно не запрещать использовать энвайронмент, как этого хотелось изначально. Вместо этого имеет смысл настроить несложные оповещения о важных для вас событиях на энве, облегчив жизнь себе и другим.
You shall not pass without notification!
habr.com
Но что делать, если энв (здесь и далее энв, энвайронмент, окружение, стенд, подразумевают одно и то же) общедоступный? То есть и разработчики, и тестировщики, и даже другие команды, админы и прочие могут прийти и что-то на энве изменить, случайно или специально. Так было и у нас, но потом мы настроили мониторинг для наших окружений и теперь живем мирно и счастливо. Далее расскажу, как это было.
Спойлер
Это не про 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_massenger.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. Но этот способ меньше подходит для нотификаций, так как наш чат не будет содержать исторически верную и актуальную информацию.
[IMG alt="Схематичная работа чат-бота для нотификаций
"]https://habrastorage.org/r/w1560/ge...e0dd52b66f02bbae60889b4e.jpg[/IMG]Схематичная работа чат-бота для нотификаций
API мессенджера
API мессенджера — это программный интерфейс, который предоставляет мессенджер для работы с ним. Здесь необходимо напрямую получать ключи для доступа к API, класть их в системы, поддерживать формат постов, то есть контракт. Этот способ лучше использовать в чат-боте, а чат-ботом предоставить вебхук.[IMG alt="Схематичная работа механизма API для нотификаций
"]https://habrastorage.org/r/w1560/ge...c8b0bb631b792a63ea540cca.jpg[/IMG]Схематичная работа механизма API для нотификаций
Примеры нотификаций
Давайте посмотрим примеры всех этих уведомлений.
Внимание
Событие: деплоймент на энве
При каждом деплое на окружение приходит уведомление. На картинке представлен стилизованный вариант, точный вид будет зависеть от того, какую информацию умеет отдавать система деплоя, и что поддерживает на входе «получатель» — мессенджер. В нашем случае уведомление содержит:
- факт события,
- идентификацию того, кто совершил действие,
- статус деплоя,
- ссылку на более детальный статус.
Событие: изменение конфигурации энва
Здесь мы также видим кто, какой параметр и на что изменил. Бывает даже полезно смотреть на историю. Сколько было случаев, когда кто-то поменял один параметр и тесты упали?! Когда у нас есть чат, мы видим, вот изменился параметр и следом был запуск тестов, которые упали. Возможно, параметр и не причина, но уже есть с чего начать исследование.
Событие: запуски автотестов
Эти сообщения можно расширить. Например, добавить информацию о том, из какой ветки и с какими параметрами был произведен запуск.
Пример кода для 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-3d3c-4309-ba94-d380351340b7" \
--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_massenger.com/webhook/1ww4345345-3d3c-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_massenger.com/webhook/1ww4345345-3d3c-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!
You shall not pass, или Как мы настроили мониторинг тестовых окружений
Привет, Хабр! Меня зовут Раиса. Я работаю в компании DINS старшим инженером по нагрузочному тестированию. Сегодня я хочу поговорить об энваройнментах. Ни для кого не секрет, что энвайронмент...
habr.com