Первоначально опубликовано на Serverless 26 сентября 2017 г.

Не так давно требование работы подтолкнуло меня в мир FaaS, и я был в восторге. Я мечтал об абстракции — избавлении от всей утомительной работы, которую не любит делать ни один разработчик. «Мы не инженеры по эксплуатации!» — гордо воскликнул я. «Нам не нужно заниматься темными искусствами Linux Shell».

Но мало ли я знал, как я был неправ. Мы, люди, — люди привычки, и одна из моих привычек как пользователя AWS — неукоснительно проверять консоль AWS. Это было мое центральное место для мониторинга всего, что мне нужно было знать о состоянии моих серверов.

Теперь возникает сложный вопрос: как работает мониторинг при использовании AWS Lambda и Serverless?

Мониторинг 101

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

Поверьте мне, время от времени я получаю гневные телефонные звонки и гневные письма. Так как же избежать криков клиентов? Отслеживайте свои ошибки и следите за своим программным обеспечением!

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

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

Примечание. Недавно я наткнулся на потрясающую статью на эту тему, написанную не кем иным, как техническим директором RisingStack, Питером Мартоном. Подробно объяснил, как правильно вести мониторинг. Я призываю вас заглянуть, это навсегда изменит ваше представление о мониторинге.

Накладные расходы?

Прошу прощения…? Можно мне немного мониторинга, пожалуйста? Но, не будучи обузой для моего приложения.

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

Как это переводится в Serverless?

В последние несколько лет революция без серверов набирает силу. Я не вижу причин, чтобы это останавливалось. Хайп настоящий.

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

Но, подождите минутку. Что еще нужно вырезать, чтобы это стало возможным?

Несколько вещей приходят на ум. Обзор производительности вашего кода и отслеживание ошибок на первом месте. Тихие провалы тоже. Как вы контролируете производительность сервера, который не является сервером? Сервер Шредингера? Хорошо, теперь моя голова болит.

Этот парадокс нуждается в новой перспективе. Мониторинг Serverless сам по себе является новым монстром. Традиционные методы не сработают. Новое мышление в порядке.

server != functions

Вместо того, чтобы указывать нашим функциям отправлять дополнительные данные при каждом вызове, почему бы просто не собрать их остаточные данные? Это крутая идея! Известно, что все функции AWS Lambda отправляют свои журналы в AWS CloudWatch.

Бессерверность неумолима

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

Давайте представим сценарий мониторинга простой функции на AWS Lambda. Цель — протестировать функцию и проверить детализацию журналов в CloudWatch.

После того, как я пару раз попал в конечную точку с помощью Postman, я уверен, что все работает нормально.

Открыв CloudWatch, я ясно вижу журналы. Перечислены все вызовы функций.

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

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

serverless logs -f my-function

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

Делаю мою жизнь менее несчастной

Что, если бы мне не нужно было отправлять код в AWS каждый раз, когда я хочу что-то протестировать? Все герои не носят плащей. Как рыцарь в сияющих доспехах, Serverless Offline врывается, чтобы спасти положение! По крайней мере, теперь я могу протестировать весь свой код локально, прежде чем отправлять его в AWS. Какое облегчение.

Настроить его на удивление легко. Установка одного модуля npm и добавление нескольких строк в файл serverless.yml бессерверной службы, и вуаля, шлюз API эмулируется локально для запуска функций Lambda.

Перейдя в каталог, в котором я создал образец функции и службы, я просто выполнил следующую команду в терминале:

npm install serverless-offline --save-dev

После установки serverless в автономном режиме я просто сослался на него в конфигурации serverless.yml:

Вернуться в мой терминал, работающий без сервера в автономном режиме, так же просто, как просто набрать:

serverless offline start

Вот и все, локальная симуляция разработки API Gateway и Lambda запущена!

Журналы все еще плохие, хотя…

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

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

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

Говорят, чтобы подключиться к вашей учетной записи AWS и быть готовым к работе, требуется всего 5 минут, но эй! Я скептик. Я замерил время.

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

Если хочешь знать, таймер остановился на отметке 4 минуты. Я впечатлен.

Тем не менее, я гораздо больше впечатлен Dashbird. Наконец-то я вижу, что происходит.

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

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

Последние мысли

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

Все сводится к мышлению разработчика. Требуется время, чтобы переключиться с мысленного образа сервера на FaaS. Бессерверная технология — это невероятная технология, и я вижу светлое будущее только в том случае, если мы продолжим расширять границы с помощью замечательных инструментов, таких как Serverless Offline, Dashbird, CloudWatch и многих других.

Я призываю вас проверить инструменты, которые я использовал выше, поскольку они очень помогли мне.

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

Как вы думаете, этот урок будет кому-то полезен? Не стесняйтесь поделиться. Если вам понравилось, дайте мне знать в комментариях ниже. Инструменты: Ресурсы:

Первоначально опубликовано на https://www.serverless.com.