Sensu. Modern Monitoring

Моніторинг - це важлива складова будь-якої серверної архітектури. Найбільш популярні варіанти його організації - це Nagios та Zabbix. Проте вони мають багато недоліків. Основні з них - це необхідність описувати кожен сервер, що потребує спостереження, окремо на сервері моніторингу; необхідність розміщення клієнта та сервера в прямій доступності та брак гнучкості. Процес автоматичного додавання хостів в моніторинги, на зразок Nagios, не дуже легко автоматизується, адже про це в 1999 році, підозрюю, особливо не думали. І це вже не кажучи про проблеми маштабування, убогість програмних інтерфейсів і т.п.

Поставивши собі за мету вирішення згаданих вище проблем, з'явився проект Sensu. Він має дві версії: Sensu Core (free, opensource) та Sensu Enterprise. Архітектура роботи Sensu досить цікава і змушує повірити в світле майбутнє. Основні особливості:

• Написаний на Ruby. Схоже люди поділяються на тих, хто любить Ruby, за його гнучкість синтаксису і ненавидить Python за його більшу строгість, і навпаки. Я відношусь до другого табору. :) Тому в кожного емоції щодо цього різні.
• Конфігураційні файли - JSON. Шкода, що не YAML.
• Може працювати з перевірками від Nagios. Що чудово - не треба все знову переписувати.
• Перевірка описується лише одноразово на сервері і підключається до аналогічної групи серверів. Кожен новий хост додається в моніторинг значно простіше і з мінімумом ручної роботи.
• Чудова архітектура, яка добре масштабується.

Зупинюсь детальніше на схемі роботи Sensu.

Sensu-server процес у якості сервера черг використовує RabbitMQ, а у якості місця збереження результатів відпрацювань чеків - Redis. Процес sensu-server має бути відповідно сконфігурований на їх використання. Одразу після старту процесу sensu-client на вузлі, що буде моніторитись, опитує sensu-server на предмет призначених для нього перевірок і надалі відсилає результати перевірок напряму в сервер черг RabbitMQ. Sensu-server підключається до останнього, робить обробку черги і записує дані в Redis. За певних обставин sensu-server може викликати відповідний handler. Handler - це деяка логіка сповіщення у разі певних проблем чи пересилки даних на окремі бекенди у разі їх появи і т.п. Sensu-api - процес, котрий надає інтерфейс взаємодії з іншими сторонніми скриптами чи сервісами. Якраз Uchiwa (frontend на схемі) і користується API задля відображення всього, що відбувається з моніторингом.

Grafana. Frontend to Graphite

Місяць тому я писав про налаштування та конфігурацію Graphite та пообіцяв незабаром розповісти про Grafana. І ось лише сьогодні я виконую свою обіцянку.

Справа в тому, що Graphite має не надто зручну панель відображення графіків. Звісно вона володіє необхідним мінімумом, але не більше (наприклад, не можна швидко збільшити регіон графіку). Можливо це і було поштовхом для появи Grafana.

Grafana - це фронтенд для відображення графіків, що має швидкий та зручний інтерфейс. З Graphite він працює через API, проте також, у якості джерела даних може використовувати InfluxDB, KairosDB, Elasticsearch, AWS Cloudwatch і т.п.

Установка графічної панелі Grafana не викликає труднощів, а для налаштування Graphite, як бази метрик, можна скористатись моєю попередньою статею, про яку згадано на початку.

Якщо ви лише тестуєте продукт для інтеграції з власною інфраструктурою - варто одразу спробувати останню бету, що ймовірно стане стейбл на момент вашої фінальної установки. Наступний мажорний реліз Grafana, з версією 3, матиме багато змін, серед яких платформа плагінів Grafana.net, які розширять можливості фронтенду додатковими джерелами данних, панелями відображення та додатками (вміщають в собі пакети джерел данних та панелей). Зовнішній вигляд також зазнав деяких змін та вдосконалень, проведено багато оптимізацій.

Ми будемо розглядати установку останньої стабільного релізу, що на момент написання статті має версію 2.6. Grafana поки що відутня у основних репозиторіях Ubuntu - тому додамо сторонній репозиторій:

# echo 'deb https://packagecloud.io/grafana/stable/debian/ wheezy main' |  sudo tee -a /etc/apt/sources.list

Graphite Configuration. Sending Metrics Using CollectD, StatsD

Збір статистики всіх систем - дуже важлива річ, адже дозволяє оперативно реагувати на будь-які відхилення в їх роботі, приймати рішення щодо збільшення потужностей чи оптимізацій. А представлення такої статистики у виді графіків зробить процес моніторингу більш наочним та зручним.

Раніше я вже писав про побудову графіків за допомогою Cacti, графічний бекенд до Nagios Nagiosgraph, в основі побудови графіків яких лежить RRDtool. Дуже можливо, що це саме те, що вам необхідно. Проте цього разу мова піде про Graphite, що має подібну до RRDtool логіку збереження даних для зображень графіків.

Graphite складається з таких компонентів:

• Carbon - storage-бекенд, написаний на Twisted Framework. Приймає дані, по-замовчуванню на 2003 порту, та в певні проміжки часу записує їх на диск, використовуючи Whisper. Задля масштабування стандартний процес carbon-cache.py, котрого більш ніж досить у звичайних конфігураціях, може бути доповнений додатковими процесами carbon-relay.py та carbon-aggregator.py. Перший може виступати як балансувальника між декількома carbon-cache.py процесами, а другий - у якості проміжного буферу.

• Whisper - storage-engine, бібліотека бази Graphite, використовується для збереження даних. Відповідає за реорганізацію даних, що отримав Carbon: переважно перетворює більш точні серії даних в менш точні та довгострокові задля більшої ефективності використання дискового простору. У залежності від наявних серій, може показувати більш точні дані на коротких діапазонах часу, або менш точні на більш довгих. Політика точності, тип агрегації та тривалості збереження серій даних звісно може налаштовуватись. В перспективі Whisper планується замінити на Ceres. Суть в тому, що Whisper на початку створює файли серій метрик фіксованого розміру і з плином часу, в разі зменшення точності вимірів (rollup/downsampling/retention/storage aggregation/compaction) розмір цих файлів не зменшується. Окрім того Whisper, для запису нових метрик, створює на диску файли наперед визначеного розміру,  що веде до неефективного використання дискового простору. Ceres вже не володіє останнім недоліком та краще працює з розподіленими сховищами і, як наслідок, один файл метрик може лежати на декількох серверах. Але, на противагу, він менш стабільний. Є звісно і інші альтернативи для storage-engine.

• Веб-панель Graphite/API-сервер - панель/API для перегляду графіків, отриманих із серій даних Whisper. Також має можливість побудови панелей для швидкого перегляду груп графіків. Написана на Django з використанням бібліотеки Cairo.

Підсумуємо. Carbon отримує дані, та записує метрики кожний сталий проміжок часу, Whisper агрегує їх залежно від політики збереження, а веб-панель Graphite надає можливість їх переглядати.

Foreman. Setup and Configuration

Foreman - це інструмент управління повним життєвим циклом серверів. Проект розпочав 6 років тому Ohad Levy, співробітник RedHat в Ізраїлі. Проект розвивається дуже активно та має обширне співтовариство. По замовчуванню працює з Puppet, з певними зауваженнями також може інтегруватись з Chef, Salt, а через систему плагінів і з Ansible.

Під управлінням повним життєвим циклом вузла розуміються такі етапи:

• Установка - початкова установка операційної системи.
• Конфігурація - установка та налаштування усього необхідного програмного забезпечення та налаштування самої операційної системи (додавання користувачів, налаштування мережевих інтерфейсів і т.п.)
• Оновлення, Управління та Аудит - установка виправлень помилок софту, додавання змін до конфігурацій діючих програм, моніторинг вузлів на протязі усього життєвого циклу.

Щоб зрозуміти як Foreman забезпечує виконання цих етапів спочатку розглянемо його складові:

• Веб-панель Foreman - панель для зручного адміністрування Puppet-модулями, групами та ін.
• API - програмний інтерфейс Foreman.
• DB - база даних Foreman. У якості бази може виступати як PosgreSQl, так і MySQL.
• LDAP/AD - користувачі можуть авторизуватись через віддалені бази LDAP чи Active Directory, що дуже зручно навіть для відносно великих компаній.
• Smart Proxy (DHCP, DNS, TFTP, CA) - група сервісів Foreman, що можуть перебувати як на одному вузлі, так і на різних. Відповідають за різні дії: provisioning нових серверів, збереження та підписання сертифікатів та ін. Таких проксі може бути декілька, наприклад для зв'язку із різними підмережами.
• Puppet Master - майстер, що надає конфігурації за іменем хосту Puppet-агента. Foreman-інсталятор налаштовує майстер на роботу через Apache та Passenger.
• Puppet Agents - агенти, що мають бути установлені на серверах, що адмініструються за допомогою Foreman.

Puppet Masterless Setup. Heartbeat Configuration

Puppet - це одна із найбільш популярних систем управління конфігурацією. Декілька років тому я вже описував її основні ідеї, а цього разу розповім про masterless-конфігурацію та, як приклад її роботи, продемонструю налаштування та роботу кластеру Heartbeat.

Якщо ви лише плануєте використовувати подібні системи - то раджу звернути увагу на Ansible. Він більш дружній до початківців, має менше недоліків та і може виконувати ту ж роботу з аналогічним успіхом.

Класична система роботи Puppet - клієнт-серверна (standalone). Певні проміжки часу (по замовчуванню кожні 30 хвилин) Puppet-клієнт запитує дані щодо власної конфігурації в Puppet-сервера, сервер компілює їх в проміжний результат та віддає клієнту. Вузьке місце такої системи - це сам Puppet-сервер: у разі виходу його із ладу, одразу всі клієнти не зможуть отримати зміни конфігурації. Також з часом ймовірно необхідно буде масштабувати сервер, адже потужностей сервера може бути недостатньо.

Тож задля підвищення рівня доступності варто звернути увагу на інший варіант роботи Puppet - masterless, тобто архітектуру без Puppet-сервера. У такому разі всі файли конфігурації будуть зберігатись в репозиторії, а кожен клієнт певні проміжки часу буде запитувати зміни з репозиторію і локально їх застосовувати. У якості репозиторію модулів/маніфестів Puppet краще всього підійдуть системи контролю версій, наприклад Git.

Перейдемо до суті. Як я вже говорив розбиратись із masterless конфігурацією ми будемо на прикладі автоматичної конфігурації Heartbeat. Це можливо не найтривіальніший приклад, проте досить цікавий. Суть роботи Heartbeat полягає в міграції (переміщенні) IP адреси з непрацюючого серверу кластера на працюючий і, таким чином, підвищувати рівень доступності. З деталями використання Heartbeat можна ознайомитись на офіційній сторінці проекту:

http://www.linux-ha.org/doc/users-guide/users-guide.html

Про щось подібне я також вже писав раніше. Для конфігурації Heartbeat кластеру необхідно як мінімум дві ноди та 3 вільні IP-адреси однієї мережі. У якості ОС я обрав Ubuntu 14.04, а серверам призначив такі адреси та хостнейми:

192.168.1.21 - hb1.me
192.168.1.22 - hb2.me

192.168.1.20 - віртуальний IP (VIP), що буде мігрувати на робочу ноду у разі падіння попередньої.

Elasticsearch Cluster: Overview And Setup

Elasticsearch - це пошукова платформа майже реального часу (near real time, NRT). На практиці це означає, що існує лише мінімальна затримка (зазвичай біля секунди) між часом додавання документу до індексу і часом, коли він стає доступним для пошуку.

Elasticsearch, як і його основний конкурент Solr, базується на бібліотеці Lucene. Сам по собі Apache Lucene не являється повноцінним сервісом: це просто бібліотека для побудови пошукових систем, вона займається лише індексом та пошуком. А, власне, за введення даних, налаштування сервісу, кластеризацію, маршрутизацію пошукових запитів та ін. відповідає Elasticsearch чи інша "обгортка".

Використання та налаштування (переважно) здійснюється за допомогою RESTful API запитів. У випадку з unix-подібною OC з цим може допомогти curl. Але про це дещо далі.

Спочатку почнемо з базової термінології Elasticsearch.

Кластер (Cluster)

Сервери, що обслуговують один набір даних та забезпечують індексацію та їх пошук по всіх серверах. Кластер також може складатись лише з єдиного сервера, проте в цьому випадку не може йти мова про високу доступність.

Про те як створити кластер я напишу нижче.

LXC Сontainers. Part II: Network Configuration

У попередній статті я описав, що таке LXC та чому ця технологія може вас зацікавити.

Перед прочитанням тексту нижче, бажано звісно розуміти базові речі про LXC чи просто про контейнеризацію, тому дуже раджу хоча б переглянути статтю, згадану вище.
У цій статті спробуємо розібратись які можливості надає LXC для конфігурації мережевого стеку та і що власне ОС Linux може запропонувати для цього.

Конфігурація з'єднання з мережею описується окремо для кожного контейнера в /var/lib/lxc/<container_name>/config. По замовчуванню, мережевий зв’язок для контейнерів LXC налаштовується за рахунок додаткової приватної мережі 10.0.3.0/24, що NAT-иться на хост машині: всі пакети, що приходять на інтерфейс lxcbr0 (10.0.3.1, gateway) за допомогою маскарадингу динамічно транслюються в публічний айпі і навпаки. Видає IP-адреси dnsmasq, що працює на LXC-хості, а діапазон можливих адрес описаний в /etc/default/lxc-net. На практиці це виглядає так:

# vim /etc/default/lxc-net
...
USE_LXC_BRIDGE="true"

LXC_BRIDGE="lxcbr0"
LXC_ADDR="10.0.3.1"
LXC_NETMASK="255.255.255.0"
LXC_NETWORK="10.0.3.0/24"
LXC_DHCP_RANGE="10.0.3.2,10.0.3.254"
LXC_DHCP_MAX="253"
...

Налаштування Iptables на хості, одразу після установки lxc, мають такий вигляд:

# iptables-save
...
-A POSTROUTING -s 10.0.3.0/24 ! -d 10.0.3.0/24 -j MASQUERADE
...
COMMIT