Мониторинг / сбор показателей для системных коллективов, которые сильно меняются во времени (также известное как облако)
Когда ваш парк серверов не меняется со временем, например, когда вы используете хостинг без операционной системы, классические решения для мониторинга и сбора данных (Nagios, Munin) работают хорошо.
Но если количество систем сильно меняется во времени, а на самом деле может быстро меняться, классическое программное обеспечение сложнее настроить и использовать. Например, попытка заставить Nagios (мониторинг) идти в ногу с быстро развивающейся облачной инфраструктурой может быть обременительной. То же самое для Мунина (метрическая коллекция). Дело не только в конфигурации, но и в способе передачи или отображения информации пользователю неадекватно для облака.
Какие возможные альтернативы хорошо работают с облаком? Цели состоят в том, чтобы собирать и отображать метрики (аналог Munin) и генерировать предупреждения, когда определенные метрики выходят за границы или когда определенные сервисы недоступны (аналог Nagios), и делать все в удобной для облака манере.
Некоторые облачные провайдеры предлагают мониторинг / сбор метрик как услуги, но не всегда, и если вы используете более одного провайдера, вы не хотите становиться слишком зависимым только от одного поставщика. Поэтому требуются независимые от провайдера решения.
РЕДАКТИРОВАТЬ: я задаю этот вопрос в общем виде - не ограничиваясь какой-либо конкретной облачной инфраструктурой (например, OpenStack), но в общем случае использования произвольных облачных провайдеров.
Для систем, которые недолговечны или в которых часто меняется инфраструктура, я использую два разных инструмента для мониторинга. Я добавил комментарий, спрашивая, какие показатели были для вас наиболее важны, и похоже, что вы ищете базовые "что случилось когда?"мониторинг статистики с некоторыми предупреждениями ...
Поскольку системы и оборудование в большей степени абстрагируются с помощью облачных сервисов и виртуализации, некоторые из традиционных инструментов мониторинга менее полезны, поскольку вам могут быть безразличны физические ресурсы и работоспособность оборудования. Важны приложения и виртуальные ресурсы (с точки зрения ВМ / экземпляра / контейнера).
Оба примера, которые я приведу ниже, полностью автоматизированы и используются по умолчанию в моей среде. С помощью Puppet я могу гарантировать, что все системы фиксируют свою работу и сообщают о ней.
Выберите # 1 - Новая реликвия
Мониторинг New Relic основан на агентах и довольно легко внедряется в систему управления инициализацией или конфигурацией. В моем случае каждый сервер, который я развертываю, получает Кукольная конфигурация новой реликвии, регистрируется в моей учетной записи New Relic и становится доступным на панели мониторинга примерно через 30-60 секунд после установки. Хост передает данные через стандартные порты, поэтому это хорошо работает в разных средах. Система может отменить регистрацию при разрыве.
Основными преимуществами являются 60-секундная детализация, просмотр панели управления / киоска в реальном времени, это свободно для мониторинга сервера, чистый и презентабельный, приемлемый для конечных пользователей и клиентов.
Выберите # 2 - Монит и М / Монит
Monit невероятно удобен для мониторинга приложений и базовой системы. Monit - это агент, который легко устанавливается в целевых системах с помощью встроенного управления пакетами ОС. Его можно настроить для мониторинга пользовательских приложений и их соответствующих параметров, а также для выполнения действий на основе этих показателей. M / Monit добавляет степень централизации к проверкам Monit и позволяет агрегировать данные для анализа и построения световых графиков.
На основе агента также легко отправлять конфигурации на хосты в автоматическом режиме. Я также использую для этого Puppet, с некоторым искушением создать файлы с ошибками. После инициализации новые серверы будут регистрироваться в центральном демоне M / Monit через порты http / https, поэтому брандмауэры и мониторинг нескольких местоположений не являются проблемой.
Если вы говорите о стандартном облачном программном обеспечении, также известном как Openstack, компоненты хорошо известны.
Чтобы собрать исторические данные в облачном масштабе: https://wiki.openstack.org/wiki/Ceilometer
Мониторинг - sensu
РЕДАКТИРОВАТЬ:
Ceilometer специфичен для openstack, но sensu - это общая среда мониторинга. Кроме того, collectd - вполне стандартная система для сбора метрик, которые вы, в свою очередь, можете передать в кактусы или графит для создания графиков трендов. Для чего-то еще более расширенного вы можете включить сервер отчетов, например Jasper Reports, но вам придется сделать свой собственный CTL. Короче говоря, существует множество вариантов, и этот вопрос действительно слишком широк, чтобы на него можно было ответить кратко.
На самом деле я не уверен, что за это можно ответить, поскольку облачные системы настолько разнообразны (я на самом деле пометил это как слишком широкое), но мои мысли ниже.
Что касается системных метрик, вам понадобится агент на ваших серверах, который подталкивает метрики к центральной конечной точке сбора, чтобы гарантировать, что новые серверы добавляются автоматически, а старые серверы либо удаляются, либо просто прекращают передачу метрик после их завершения.
Вы можете либо использовать свой собственный (но это также имеет потенциальную ловушку для мониторинга облачной инфраструктуры с облачной инфраструктурой - что произойдет, когда Amazon решит списать ваш сервер collectd?), Либо вы можете использовать одного из нескольких сторонних поставщиков услуг хостинга. (StackDriver, NewRelic, Граница, РазмещенныйГрафит и это лишь некоторые из них - решения SaaS обычно идут рука об руку с платформами IaaS).
Конечно, вы можете управлять своим собственным сервером Nagios в своей облачной инфраструктуре и что-то вроде Марионетка с использованием экспортированных ресурсов может сделать это очень легко - вы, по крайней мере, уже должны использовать какой-то инструмент автоматизации, если используете облачные технологии.
Если вам нужна нисходящая платформа мониторинга / оповещения инфраструктуры, как NewRelic, так и StackDriver имеют эту функциональность, по крайней мере, для облака Amazon, и могут подключаться к таким механизмам уведомлений, как PagerDuty - пока я не знаю о глобальном «одно решение, чтобы править всеми».