Graphite. Stack Based On ClickHouse

Graphite - це моніторингова система, що працює за push-моделлю, тобто отримує дані від вузлів, а не опитує їх. Вона чудово підходить для збирання та аналізу метрик і, завдяки вбудованому механізму ущільнення даних (storage aggregation/rollup/retention/downsampling), ці дані можуть зберігатись на протязі дійсно пристойного часу (декілька років).

Graphite був написаний Крісом Дейвісом (Chris Davis), співробітником компанії Orbitz в 2006 році. Мова програмування оригінального проекту - Python, але наразі майже всі компоненти Graphite можна замінити на сторонні, написані на мові Go. Більш того, навіть бібліотеку Whisper для роботи з базою Graphite можна замінити на альтернативні рішення зі збереженням даних в базі Cassandra, ClickHouse і т.п. Якраз про останній і піде мова цього разу.

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

Спершу пройдемось по кожному із компонентів та опишемо їх призначення.

• Carbon-clickhouse - демон, що працює у якості заміни оригінального Carbon та може писати отримані метрики від третіх систем в базу даних ClickHouse.
• ClickHouse - OLAP база даних, що була розроблена в компанії Yandex, проте із 2021 року вона розвивається в межах окремої одноіменної компанії. Пізніше розповім про неї детальніше.
• Graphite-clickhouse - проміжне програмне забезпечення для роботи між API сервісом та базою ClickHouse.
• Carbonapi - API-сервер Graphite, написаний на мові Go. Теоретично замість нього може бути використано Graphite-web (оригінальна імплементація API та веб-панель) чи Graphite-api (лише API на Flask фреймворку)
• Grafana - веб-панель на Go/NodeJS для побудови та відображення метрик. Вміє опитувати Graphite "із коробки", підтримує всі його API-функції. Для Grafana-и увесь описаний вгорі стек буде виглядати як звичайна інсталяція Graphite-у.

credits https://github.com/lomik/graphite-clickhouse#work-scheme

елементи наведені пунктиром - опціональні

У свою чергу Carbon-clickhouse та Graphite-clickhouse - по деяких опосередкованих даних розробки компанії Mail.ru, а Carbonapi - Booking.com.

Prometheus. From Metrics To Insight

Prometheus  - моніторингова система з відкритим вихідним кодом,  була створена та розроблялась в компанії Soundcloud з 2012, а в 2015 році представлена публічно і наразі розвивається незалежно.

Переважно написана на мові Go колишніми співробітниками компанії Google. Прототипом Prometheus виступала моніторингова система Borgmon. Ця моніторингова система має наступні переваги/недоліки/особливості:

• багатовимірну модель даних, з часовими рядами, що ідентифікуються назвою метрики та парою ключ/значення;
• гнучку мову запитів, що використовує цю модель;
• pull-модель роботи серверу, збирання даних відбувається опитуванням вузлів, що моніторяться, по протоколу HTTP (хоча існує також Pushgateway, що працює по push-моделі і призначений для збирання метрик з недовговічних вузлів);
• відсутність залежності від розподілених віддалених сховищ; кожен вузол Prometheus є автономним;
• об'єкти моніторингу можуть додаватись вручну до основного конфігураційного файлу Prometheus чи автоматично через service discovery (Consul, API/теги AWS, GCP, Kubernetes, Openstack та інші).

Як вже було згадано, Prometheus - це моніторингова система, що працює за pull-моделлю. Тобто сервер опитує власноруч кожен вузол, що потребує моніторингу. На думку авторів проекту, така модель дещо краща за push-модель (коли метрики відправляються самостійно на сервер моніторингу без жодних запитів). Чудовим прикладом останньої є Sensu, про яку я вже писав декілька років тому.

Kubernetes. Part VI: Setup HA Master Cluster on AWS With Kops

Раніше я вже робив огляд актуальних способів установки Kubernetes та описував досить детально його установку через Kubeadm і Kubespray. Цього ж разу мова піде про інший метод установки кластеру високої доступності - Kops.

Kops (Kubernetes Operation) - це програмне забезпечення написане на мові Go, що дозволяє вирішувати проблеми установки та обслуговування кластеру Kubernetes. Серед його особливостей та переваг можна відзначити наступні:

• Підтримує установку кластерів для cloud-платформ AWS, GCE (beta статус), DigitalOcean (зі значними обмеженнями), VMWare Vsphere (alpha статус).
• Здатний інсталювати кластери високої доступності (HA), може налаштовувати мульти-майстер конфігурації з урахуванням можливостей та сервісів cloud-платформ. 
• Підтримує ідемпотентність операцій над кластером; перед застосуванням змін здатен інформувати, що саме буде змінено (dry-runs).
• Опис інфраструктури може зберігати в Terraform темплейтах чи CloudFormation.
• Підтримує установку додатків Kubernetes (Dashboard, EFK, Prometheus Operator, Ingress і інші). У свою чергу вони можуть бути дещо змінені задля кращої інтеграції з функціоналом cloud-платформи.
• Налаштування зберігає в форматі YAML.
• Підтримує 8 різних плагінів для опису оверлейної мережі pod-to-pod/pod-to-service (CNI Networking)

Як і Kubespray, для установки та налаштування кластеру "під капотом" Kops використовує Kubeadm. Якщо ж існують плани в недалекому майбутньому мігрувати з AWS на інші платформи (в т.ч. baremetal) можливо ліпше буде одразу інвестувати час в Kubespray, адже це набір Ansible-ролей, котрі, за необхідності, відносно легко відредагувати під власні потреби. Знову ж, він підтримує значно обширніший список підтримуваних платформ.

1. PREREQUIREMENTS

Для того щоб перейти до установки Kubernetes кластеру спочатку необхідно встановити awscli та kops. Перший розповсюджується як python-пакет, котрий із легкістю можна встановити через pip:

$ pip install awscli --upgrade --user

$ aws --version
aws-cli/1.15.37 Python/3.6.3 Linux/4.13.0-43-generic botocore/1.10.37

OpenLDAP Server. Part II: FusionDirectory LDAP Browser

Нещодавно я оновив статтю про установку та налаштування OpenLDAP серверу, де також торкнувся теми підвищення безпеки інсталяції та використання панелі адміністрування phpLDAPadmin. Цього ж разу я хочу приділити увагу іншій веб-інтерфейсу FusionDirectory.

FusionDirectory - програмний комплекс, що забезпечує зручне управління даними в LDAP-каталозі. Це форк проекту Gosa², який відбувся в 2011 році через обмежений доступ до коду та процесу розробки оригінального продукту. Таким чином FusionDirectory хотів залучити в проект сторонніх розробників та покращити документацію.

У 2010 році Gosa² була обрана як фронтенд управління LDAP інфраструктурою німецького міста Мюнхен у межах проекта LiMux. На жаль, проект планують згорнути до 2020 на користь продуктів компанії Microsoft. Та і самій Gosa² пощастило не більше: останній реліз датується 2012 роком, хоча варто визнати, що пакети для її установки і досі присутні в офіційних репозиторіях Ubuntu.

1. INSTALLATION

Проте її форк FusionDirectory і досі відносно активно розвивається: останній реліз з версією 1.2 відбувся влітку 2017 року. Для того, щоб виконання подальших інструкцій в цій статті мало сенс, спочатку необхідно встановити OpenLDAP сервер, про інсталяцію якого я вже писав і згадував. Спершу встановимо пакети-залежності, які потребує FusionDirectory, але не запитує явно:

# apt install make
# cpan -i Archive::Extract

На відміну від Gosa², останні пакети FusionDirectory не присутні в стандартних репозиторіях Ubuntu, тому необхідно додати сторонні:

# cat << EOF > /etc/apt/sources.list.d/fusiondirectory.list
# FusionDirectory
deb http://repos.fusiondirectory.org/fusiondirectory-current/debian-wheezy wheezy main
deb http://repos.fusiondirectory.org/fusiondirectory-extra/debian-jessie jessie main
EOF