Недавно я играл на нескольких платформах PAAS, и это несколько напомнило мне мои дни, когда я работал с серверами приложений J2EE, драйверами JDBC, реляционными БД и т. Д. О, как я помню развертывание серверов и баз данных, а затем проверил мой блестящий новый приложение, помните J2EE petstore кто-нибудь ??
Однако большая разница с PAAS по сравнению со старыми школьными серверами приложений заключается в том, что вам не нужно тратить несколько дней на их настройку и выяснение тонких различий между тем, как вы развертываете на платформах разных поставщиков — когда-либо пытайтесь переключиться с JBoss на Websphere менее чем за неделя 
PAAS выводит P (ain in) ASS из конфигурации и управления вашим промежуточным программным обеспечением и в значительной степени конфигурируется одним нажатием (хорошо, может быть, несколькими щелчками). Однако одно заметное различие между поставщиками PAAS заключается в доступе к базовому промежуточному ПО и серверу, на котором работает ваш код. Это варьируется от почти полного доступа (например, Engine Yard) до более ограниченного доступа или отсутствия доступа (например, Heroku, Google App Engine).
Естественно, есть плюсы и минусы в обоих случаях. Большим плюсом нулевого доступа к экземпляру сервера является аргумент «вам не нужно знать», т.е. не требуются навыки системного администрирования. Просто позвольте провайдеру PAAS беспокоиться об управлении вашими экземплярами, а вы беспокоитесь о написании своих приложений (что в наши дни некоторые называют NoOps ).
Однако, если, с другой стороны, вы хотели бы иметь больший контроль и предпочитаете время от времени совершенствовать свои навыки сисадмина, то вы можете предпочесть подход Engine Yard. С Engine Yard вы получаете полный ssh-доступ к вашему экземпляру и получаете нормальную серверную среду для случаев, когда вам нужно установить пакеты из репозиториев и т. Д. Обратите внимание, Engine Yard также предоставляет приятный интерфейс пользовательского интерфейса, поэтому вам не нужно иметь дело с командная строка, если вы действительно не хотите.
С точки зрения ведения журналов Engine Yard довольно хорош, поскольку вы получаете полный доступ к вашей папке / var / log /, в которой хранятся почти все важные журналы сервера, на которые вы, возможно, захотите посмотреть. Более подробная информация о ведении журнала Engine Yard будет продолжена …
Для сравнения, подобные Heroku и App Engine имеют ограниченный доступ, когда дело доходит до регистрации, то есть со стандартной регистрацией Heroku вы получаете доступ только к последним 500 событиям, что не очень хорошо, если вам нужно пойти и посмотреть на проблему, которая клиент сообщил за ночь, например. Тем не менее, Heroku недавно представила ряд дополнений, которые вы можете выбрать. Инфраструктура журналирования Heroku, Logplex , обеспечивает плавную интеграцию одним щелчком мыши с поставщиками надстроек, а это означает, что вы можете настроить управление журналами сразу после установки одним щелчком мыши. Если вы используете Logentries, вы получаете неограниченное хранилище журналов и предварительно настроенную подсветку ошибок / оповещения для Heroku, что означает, что вы можете легко найти и найти эту проблему, независимо от того, произошла ли она прошлой ночью, на прошлой неделе или в прошлом месяце.
App Engine также имеет ограниченный буфер журналирования. Однако в « дорожной карте» App Engine в настоящее время перечислены «улучшения системы ведения журнала для снятия ограничений по размеру и хранилищу», которые в настоящее время находятся на повестке дня, поэтому похоже, что эти ограничения также будут сняты довольно скоро. В то же время вы можете использовать это .
Engine Yard использует дистрибутив linux gentoo, поэтому большинство важных журналов хранятся в папке / var / log. Мы рассмотрим это через минуту. Тем не менее, одним из первых журналов, который вы можете в конечном итоге искать, является yourapp-deploy.log, который находится в вашей домашней папке. Он записывает события журнала, связанные с развертыванием, поэтому вы сможете посмотреть, были ли у вас проблемы с развертыванием. Он также доступен через панель управления Engine Yard, где к нему легко получить доступ. В представлении панели мониторинга также есть несколько других журналов, а именно журналы chef, содержащие информацию о базовом сценарии chef, запускаемом по умолчанию при запуске экземпляра Engine Yard (базовый журнал), и регистрируют события, генерируемые из любых пользовательских сценариев chef, которые вы используете. настроили для запуска (настраиваемый журнал).
Пост Шона Хонга дает хорошее представление о том, как начать отладку, когда сайт / приложение, размещенное на Engine Yard, выходит из строя, начиная с проверки журналов развертывания и шеф-повара. Однако, если это не решит проблему, он предлагает вам погрузиться глубже, чем панель управления Engine Yard, и ssh в ваш экземпляр.
Когда вы сделаете это, вам будет доступно множество полезных файлов журналов. Эти журналы могут быть полезны, если вы испытываете некоторое время простоя и выполняете рекомендуемый контрольный список диагностики двигателя . Вы можете получить к ним доступ из папки / var / log, как указано выше. Я перечислил некоторые из них ниже (в произвольном порядке) и дал некоторое представление о том, почему они могут представлять интерес:
- production.log : журнал производства полезен, если вам нужно посмотреть, что происходит на уровне рельсов. Он находится по адресу /var/log/engineyard/apps/yourapp/production.log. Если вам нужно отладить ваше приложение или выяснить, где есть проблемы с производительностью, это может быть место для поиска. Существуют также инструменты для «извлечения некоторой полезной информации» из производственного журнала, такие как logjuicer или Rails Analyzer Project . Вы также можете проверить некоторые из этих Railscasts, которые показывают, как использовать эти инструменты для анализа вашего produciton.log, чтобы выявить узкие места в вашем приложении, то есть выяснить, какие действия контроллера занимают больше всего времени выполнения — обычно лучшие кандидаты для оптимизации. Некоторые полезные, более общие советы по регистрации рельсов можно найти на Блог Майка Набережного
- Журналы nginx : Ваши журналы nginx находятся в / var / log / nginx /. События журнала Nginx хранятся в файлах yourapp.access.log и yourapp.error.log. Журнал доступа содержит записи запросов к веб-серверу, а любые связанные с этим ошибки отправляются в error.log. Дополнительную информацию о журналах nginx можно найти на nginx.org . Также у Мартина Фьордвалда есть хороший пост по настройке nginx для высоких нагрузок , хотя и в контексте php. Однако он охватывает как доступ, так и журнал ошибок и делает некоторые пункты актуальными для любых пользователей Nginx.
- Журналы mysql : Журналы базы данных могут быть полезны для расследования медленных запросов или ошибок, связанных с БД. Обратите внимание, что существует несколько разных мест хранения журналов mysql на Engine Yard в зависимости от версии сервера и продукта. На управляемой платформе журналы можно найти в / db / mysql / log /, где также находятся журналы в Engine Yard Cloud для MySQL 5.0. Для Cloud MySQL версий 5.1 и 5.5 журналы можно найти в / db / mysql / {major_version} / log / (/db/mysql/5.5/log). Если вы сомневаетесь, эту информацию всегда можно найти в любой среде в командной строке * nix, выполнив команду `mysqld –help –verbose | grep ‘^ log-slow-query’` (спасибо @tylerpoland за помощь в выяснении этого ). Как только вы перейдете к соответствующему местоположению, вы найдетеЖурналы MySQL сервера, которые включают, журнал ошибок, общие запросы и медленные журналы запросов. Ребята из Engine Yard предполагают, что медленный журнал запросов — это одно из лучших мест для поиска проблем с производительностью ROR и необходимости их оптимизации.
- Журналы Mongrel или Passenger : Если у вас есть журналы mongrel, они отправляются в / var / log / engineyard / mongrel / myapp /. Журналы пассажиров доступны из /var/log/nginx/passenger.log.
- Обычные старые журналы Linux : папка / var / log / также содержит все обычные файлы журналов Linux, которые вы любите знать. Обычно основной файл системного журнала — это файл, который вы хотите анализировать время от времени. Например, если вы используете Monit и Mongrel, а ваше приложение сжимает память и чувствует себя немного раздутым , то есть использует больше памяти, чем нужно, вам нужно проверить основной файл системного журнала. Мониторинг журналов в системном журнале и может сообщить вам, когда вы достигли предела памяти.
Aug 29 03:35:05 myserver monit[5194]: 'mongrel_myapp_5000' total mem amount of 133256kB matches resource limit [total mem amount>130360kB]
Однако основной файл системного журнала имеет тенденцию захватывать множество событий из разных источников (это зависит от конфигурации системного журнала , расположенной по адресу /etc/syslog.conf, которая указывает, какие события отправлять в различные файлы системного журнала), а в некоторых случаях вы Возможно, вам захочется погрузиться в один из более конкретных файлов, если вы знаете, что именно вас интересует. Например, файл auth.log фиксирует любой доступ по ssh или попытку ssh-доступа к вашему экземпляру. Рекомендуется регулярно просматривать этот файл и, возможно, даже устанавливать оповещения об успешных входах в систему, чтобы вы знали, когда кто-то входит в ваш ящик. На приведенном ниже снимке экрана показан пример того, как будет выглядеть успешная атака по словарю на экземпляр сервера. Вы можете видеть в моей учетной записи Logentries (ниже), я отметили неудачный и успешный вход в систему пытается выделить их. Если вы используете несколько облачных экземпляров, вы обнаружите, что ваши экземпляры почти ежедневно подвергаются атакам по словарю. Если вы ограничили свой экземпляр только доступом по ssh-ключу, у вас все в порядке, и это не удастся. Однако серверы с удаленным доступом по имени пользователя и паролю подвержены атакам. Любой сервер с доступом по паролю пользователя с некоторым логином по умолчанию (например, по умолчанию nagios или упрощенной комбинацией логин / пароль) будет иметь хороший шанс взлома. Если вы используете Engine Yard или AWS EC2, вы можете использовать только доступ по ssh-ключу, так что вы, скорее всего, будете в порядке. Тем не менее, я всегда считаю хорошей идеей следить за этим файлом журнала и предупреждать о входах в систему, даже для душевного спокойствия.
Наконец, если вам нужно проанализировать свои журналы и, например, просто повиснуть в командной строке, вы должны почерпнуть несколько полезных советов по grep из thegeekstuff . Они полезны для поиска и фильтрации шума, когда у вас много событий журнала.
В качестве альтернативы, если вы не хотите использовать ssh для каждого экземпляра, если считаете, что существует проблема, ознакомьтесь с нашим руководством по настройке Logentries с Engine Yard . Обратите внимание, что для этого мы предлагаем несколько сценариев chef, чтобы вы могли автоматизировать настройку для каждого запускаемого вами экземпляра.