Шест милиарда заявки на месец. Звучи ли ви голямо това число? Това число е общият брой заявки, направени за един месец на много популярен уебсайт, който всеки програмист познава: StackOverflow.

Два HAProxy сървъра и девет уеб сървъра са градивните елементи на StackOverflow, прилагайки добре позната и стабилна архитектура, известна като сървърни клъстери с висока достъпност.

В по-малък мащаб такива архитектури се внедряват от много компании, за да осигурят наличността на услуга дори в случай на хардуерни дефекти. Но в случай на спиране на сървъра, как човек може да бъде уведомен по ефективен начин, за да предприеме бързи действия за възстановяване на сървър?

Днес ще изградим пълно табло за управление на Grafana, наблюдаващо сървърен клъстер с помощта на InfluxDB и Telegraf.

I — Относно клъстерите с висока наличност

Преди да преминем към разработката на нашето табло за управление, нека накратко да кажем нещо за клъстери с висока достъпност, за какво се използват и защо ни е грижа да ги наблюдаваме (ако сте експерт по корпоративна архитектура, можете да пропуснете тази част)

Клъстер с висока достъпност е група от сървъри, проектирани и сглобени по начин, който осигурява постоянна наличност и излишъкна предоставяните услуги.

Да приемем, че създавате просто уеб приложение. При стартиране получавате трафик от хиляда показвания на страници на ден, натоварване, което всеки приличен HTTP сървър може да се справи без никакви проблеми. Изведнъж трафикът ви рязко се покачва и скача до милион показвания на страници на ден. В този случай основният ви HTTP сървър не може да се справи сам с натоварването и се нуждае от допълнителни ресурси.

Решение на този проблем би било внедряването на HA клъстерна архитектура.

Когато се получи HTTP заявка, инструментът за балансиране на натоварването ще прокси (т.е. препрати) заявката към съответния възел, за да гарантира, че натоварването е равномерно разпределено между клъстера. Балансиращите натоварване използват различни видове техники, за да решат към кой възел да изпратят, но в нашия случай ще използваме непретеглена конфигурация Round Robin: заявка ще бъде изпратена до първия сървър, след това до втория и скоро. Няма да се прави предпочитание по отношение на избрания възел.

След като дефинирахме всички технически термини, можем да започнем да прилагаме нашата система за наблюдение.

II — Избор на правилния стек

За този проект ще използвам машина Xubuntu 18.04 със стандартно ядро.

За да наблюдаваме нашия сървърен клъстер, трябва да изберем правилните инструменти. За визуализацията в реално време ще използваме Grafana v6.1.1

За наблюдение избрах InfluxDB 1.7 като източник на данни за Grafana, тъй като той представлява надежден източник на данни за Grafana. За да получа показатели за InfluxDB, избрах Telegraf — управляван от плъгин сървър агент, създаден от InfluxData. Този урок не обхваща инсталирането на инструментите, представени по-напред, тъй като съответната им документация го обяснява достатъчно добре.

Забележка: уверете се, че използвате същите версии като тези, използвани в този урок. Такива инструменти са склонни към чести промени и могат да променят валидността на тази статия.

III — Създаване на прост HA клъстер

За да наблюдаваме нашия HA клъстер, ще изградим негова проста версия, като използваме NGINX v1.14.0 и 3 Node HTTP сървърни екземпляри. Както е показано на диаграмата по-горе, NGINX ще бъде конфигуриран като устройство за балансиране на натоварването, предаващо прокси заявките към нашите екземпляри на Node.

Ако вече имате настройка на HA клъстер във вашата инфраструктура, не се колебайте да пропуснете тази част.

a — Задаване на NGINX като балансьор на натоварването

NGINX е конфигуриран да работи на порт 80, като изпълнява конфигурацията по подразбиране и прокси заявки към услуги, разположени на порт 5000, 5001 и 5002.

Обърнете внимание на частта /nginx_status от конфигурацията на сървъра. Важно е да не го пропускате, тъй като ще бъде използван от Telegraf за извличане на NGINX показатели по-късно.

b — Задаване на прости екземпляри на HTTP възел.

За тази част използвах много прост екземпляр на Node HTTP, като използвах библиотеката http и httpdispatcher, предоставена от Node първоначално.

Този сървър не предоставя никакви специални възможности, но ще се използва като основен уеб сървър за NGINX за прокси заявки.

За да стартирам три екземпляра на тези уеб сървъри, използвам pm2 : помощната програма за управление на процеси за екземпляри на Node на Linux системи.

Сега, когато NGINX е готов, нека стартираме нашите три екземпляра, като изпълним:

Правейки това с двата други екземпляра на Node сървъри, имаме готов и готов клъстер от три Node възела.

IV — Настройка на Telegraf за наблюдение

Сега, когато нашият HA клъстер е изграден и работи, трябва да настроим Telegraf да се свързва с различните компоненти на нашата архитектура.

Telegraf ще наблюдава нашия клъстер с помощта на два различни плъгина:

  • NGINX плъгин: използва се за извличане на показатели за NGINX сървъри като брой заявки, както и чакащи/активниили обработени заявки на нашия сървър за балансиране на натоварването.
  • HTTP_Response: използва се за периодично извличане на времето за отговор на всеки възел, както и HTTP кода, свързан със заявката. Този плъгин ще бъде много полезен за нас, за да наблюдаваме пикове на нашите възли, както и сривове на възли, които могат да се случат.

Преди да започнете, уверете се, че telegraf работи със следната команда: sudo systemctl status telegraf. Ако вашата услуга е маркирана като Active, вие сте готови!

Насочете се към местоположението по подразбиране на Telegraf за конфигурация ( /etc/telegraf ), редактирайте файла telegraf.conf и добавете следните изходни конфигурации към него.

Когато приключите с промяната на конфигурацията на Telegraf, не забравяйте да рестартиратеуслугата, за да бъдат взети предвид промените. ( sudo systemctl restart telegraf ).

След като Telegraf стартира, той трябва да започне периодично да изпраща метрики към InfluxDB (работещ на порт 8086) в базата данни telegraf, създавайки метрика, наречена от името на приставката, която я изпълнява. (така че или nginx или http_response).

Ако такива бази данни и измервания не са създадени на вашето копие на InfluxDB, уверете се, че нямате проблеми с конфигурацията и че услугата telegraf работи правилно на машината.

Сега, когато различните ни инструменти работят, нека да разгледаме окончателната ни архитектура, преди да преминем към Grafana.

V — Настройка на Grafana — Най-накрая!

Сега, когато всичко е настроено на вашата машина, време е да играете с Grafanaи да създадете най-готиното табло за управление за наблюдение на нашата инфраструктура.

Като се има предвид таблото за управление, представено по-горе, имате три опции за визуализация:

  • Диаграма на наличността: показва връзките между възлите, текущите им състояния и времето за реакция.
  • Датчици, показващи времена за реакция, или съобщение за грешка, че услугата е неуспешна.
  • Графика на всеки възел време за реакция и конфигурируем сигнал, ако услугата се провали.

Можете да преминете към частите, които смятате за подходящи за вашето собствено табло.

0 — Предварителни стъпки

Трябва да имате напълно празно табло, като намерите бутона Create Dashboard от лявото меню на Grafana.

а — Диаграма на наличността

Тази опция за визуализация показва връзката между различните части на нашата архитектура, както и цветни възли за представяне на статусите на всеки отделен възел.

Малко конфигурация, тъй като плъгинът за диаграми не е наличен първоначално в Grafana, но не би трябвало да е твърде трудно за инсталиране.

Във вашия команден ред стартирайте sudo grafana-cli plugins install jdbranham-diagram-panel и рестартирайте Grafana. Сега, след като успешно инсталирахте плъгина, той трябва да е наличен в лентата за визуализация на Grafana.

Панелът с диаграми използва синтаксиса Mermaid, който ще използваме, за да изобразим нашата архитектура. За улеснение съм сглобил конфигурацията на една снимка.

Синтаксисът на mermaid за този плъгин трябва да бъде конфигуриран, както е описано по-долу

Важна забележка: има малък параметър, който трябва да промените в Grafana, за да получите желания резултат. По подразбиране, ако дефинирате заявката като представената по-горе, Grafana ще вземе последната стойност спрямо интервала от време на прозореца. Това е проблем, защото ако настроите таблото си за управление на Grafana на Last 15 minutes с опция Refresh every five seconds, ще получите известие, че услугата ви спира 15 минути по-късно.

За да се противопоставите на това, трябва да намерите този ред във вашата конфигурация:

По този начин ще получите предупреждението само 20 секунди след спирането на услугата.

И сме готови с диаграмата за наличност! Нека да разгледаме диаграмата, ако спрем една от услугите до pm2 stop server

Точно това, което очаквахме! За съжаление, панелът с диаграми не предоставя никаква система за предупреждение, но ще можем да изпращаме предупреждения чрез панела с графики.

б — Панел за габарити

Този панел с измервателен уред е нов панел, наличен в Grafana v6.0, и е конфигуриран като такъв:

Панелът за измерване е обвързан с полето response_time и праговете са конфигурирани да уведомяват, когато определен възел отнема твърде много време за отговор. Сигналите все още не могат да се конфигурират на панела с измервателния уред.

c — Графичен панел

Панелът с графики показва времена за реакция и е доста подобен в сравнение с панела с измервателни уреди, показан по-горе. Основна разлика с панела за измерване е, че той предоставя конфигурации за предупреждение, когато определена стойност не е налична.

Всички джаджи, представени по-горе, могат да бъдат променени, за да се приспособят към вашите нужди и трябва да бъдат! Тяхната конфигурация изобразява много специалния случай на HA клъстер, но те може да се различават, ако използвате HAProxy или друга техника за балансиране на натоварването.

VI — Заключение

Необходимостта от мониторинг през 2019 г. определено е тенденция, която никой инженер вече не може да пренебрегне. Има нарастваща нужда от решения за мониторинг, но също и от инструменти, които консолидират агенти за мониторинг, инструменти за визуализация и инструменти за пост-анализ.

Идват някои страхотни инструменти за DevOps: InfluxDB вече мигрира към версия 2.0 с езика Flux и нещата изглеждат много обещаващи.



SQL е мъртъв, здравей на Flux
Представяме ви Flux, нов скриптов език, създаден от InfluxData. SQL внимавайте, това може да е една от най-големите технологични тенденции…medium.com



Въпреки това InfluxData не е единственият доставчик на база данни за времеви серии на пазара: Amazon определено иска своя дял и обявиAmazon Timestream по време на re:Invent 2018. Бяха разкрити някои функции, но може да представлява много солидна алтернатива на InfluxCloud.

Времето ще покаже!

Надявам се, че сте прекарали страхотно време, докато четете и изграждате това табло за наблюдение на клъстери с мен: ако искате конкретни теми да бъдат обхванати в бъдеще, не се колебайте да ми обърнете внимание.

До следващия път.

любезно,

Антоан Солничкин.