high volume monitoring with graphite

Основи Graphite The Plan Цялостна система Демонстрация Въпроси?

High Volume monitoring with GraphiteGraphs Galore

Владимир Витков

2015.05.16 / Plovdivconf

High Volume monitoring with Graphite Владимир Витков

Всеки бизнес има нужда от мониторинг. Всеки бизнес иманужда от гъвкав мониторинг който му позволява да си извадидобри изводи. Днес ще ви разкажа как го постигнахме при нас.


Кой е пред вас

• Владимир• Системен Администратор• Привърженик на FOSS но не и зеалот• Експериментатор• Относително приятен човек за разговор*



Основи



Що е това мониторинг

• Система/и които събират данни• Използва се от OPS• Използва се от бизнеса• използва се от мениджърите• Използва се за известяване


Мониторинг системите са необходимо зло. Без тях не знаемкакво се случва в нашата система. С тях ... вече знаем че всичкое счупено и не добре. Мониторинг системите се използват несамо от администраторите и хората на смяна. Ползват се отбизнес мениджъри, от дирекни мениджъри, рекламисти, и койли още не. Добрата мониторинг система се използва и заизвестяване.


Защо ни трябва мониторинг

• Без мониторинг сме слепи• Имаме ли капацитет• Държи ли се добре приложението ни• А имаме ли място• А колко плащаме за всичко• Има ли някой който ни атакува


Мониторинг системите имат множество приложения. Както занаблюдаване и проследяване на текущото състояние, така и запредсказване на бъдещо такова. Могат да бъдат много добърпризнак че нещо не е наред (някой ни атакува), да се позлват заизчисляване на сметки и още милиони неща.


Какво е добър мониторинг

• Там където ти трябва• Такъв който не ти пречи• Гъвкав за да може да се използва за различни цели• Лесен за ползване• Лесен за работа


Добрият мониторинг представлява ненатрапчива система коятопозволява свободна работа с нея. Позволява да бъдеразширявана и не ти се пречка когато ти трябва. Гъвкав е отгледна точка на възможности и начини за употреба. И може бинай важното удобен е както за системните администратори такаи за не особенно запознатите хора.


Що е това система за метрики

• Част от мониторинг системите• Цифрово изражение на нещата• Централно място за предвиждания• . . . и планиране• . . . Следене на странности


Системите за метрики са необходими за да имаме цифровоизражение на нашата услуга. Основната им цел обикновенно еда се използват за планиране на бъдещо натоварване, анализ натекущото. Откриване на проблеми. ПРОДАЖБИ и какво ли ощене.

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


Трябват ли ни метрики

• на кратко да• По нашироко

• Да разбира се• Освен ако нямаме дребен сайт с няколко посетителя

дневно• . . . и огромно количество хардуер да го движи• И тогава даже пак ни трябват


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


Graphite



Какво е Graphite

• Йерархична система за събиране на метрики• Python• Бърза• Позволява използване за различни цели• Удобен интерфейс за експерименти• Фиксирано изискване на мястото*


Graphite e йерархична система за събиране на метрики. Написане на питон. Може да бъде захранен с данни по различни начини.Доста бърза. С фиксирани изисквания за място (ако епомислено разумно). Има много удобен интерфейс заексперименти с вашите данни и е ужасно удобна при дизайн


Защо Graphite

• It’s hip (nope)• It’s fast and flexible (Hell yes)• Подкарва се бързо• Позволява много възможности


Избрали сме Graphite не защото е модерно а порадифункционалността му


The Plan



Какво ще покажем

• Събиране на данни от много машини• Обработка на данните• Методики за определяне структурата на метриките• Изграждане на надеждна система• Оптимизация на цялото нещо



Събиране на данни

• POLL• Центранел колектор(и)• Разпределени колектори

• PUSH• Разпределени или балансирани колектори• UDP is a friend


Има две основни архитектури. POLL или PULL базирана прикоято колекторите на данните питат за тях. Това не е особенноскалируемо тъй като колекторите рано или късно се претоварват.Другият вариант е PUSH архитектура при която клиентитедокладват данните. Обикновенно имаме няколко колектораскрити зад балансер който разпределя натоварването. По тозиначин много по лесно разпределя натоварването. Също така незабравявйте разликата в цената на TCP и UDP. Да при UDPможе да имате загуби но печелите скорост. Ако това не еприемливо работете с TCP.


Събиране на данни

• APP и OS• Collectd (client)• Collectd (server)• Graphite (a few/lot)• Има и други варианти


В моя конкретен случай приложенията и ОС-a докладватданните си на локален collectd процес където подлежат набуфериране при желание. От там се изпращат нацентрализирания collectd сървър. Той от своя страна ги подавана серия от graphite процеси които ги обработват докатонай-накрая се окажат върху дисковете. Това не е единственият ивероятно не е и най-добрият начин, така че почетете.


collectd.conf

LoadPlugin network<Plugin Network>

Listen "0.0.0.0" "3011"</Plugin>LoadPlugin write_graphite<Plugin write_graphite>

<Node "localhost">Host "localhost"Port "10001"Protocol "tcp"AlwaysAppendDS false

</Node></Plugin>


Зареждаме необходимите плъгини (network и write_graphite)като ги конфигурираме съответно да слушат и да изпращатданните.


Обработка на данните

• Преименуване на данните• Агрегиране• Понижаване на точността (защо ли)• Други магии


След като получим данните може да ги подложим на обработа.Обработката в общия случай бива три вида. Преименуване наданните за да пасната на схемата на нашите метрики.Агрегиране на няколко метрики в една (сървъри). Понижаванена точността чрез усредняване на няколко поредни метрики.Основната цел на това усредняване (roll-up) е да се сместимясто. Отделно Graphite позволява дописване на функции скоито може да се реализира каквото ви душа желае.


Преименуване (rewrite-rules.conf)

От

prod.i-123.p_pi-cust:srv:inst.metric

До

prod.customer.service.instance.id.metric


Има случаи при които данните не идват във вид удобен заграфит и цялото нещо трябва да се преименува. Много добърпример е когато данните идват от collectd. Collectd поддържахост, плъгин, инстанция на плъгина. Ако структурата ви несъвпада с идеята обикновенно си добавяте къстъм сепараторикоито в последстви трябва да си разпарсите. За целта сеизползва rewrite-rules.conf където има 2 секции (pre и post) катосе използват в различни слЗа целта се използваrewrite-rules.conf където има 2 секции (pre и post) като сеизползват в различни случаи.


Агрегиране (aggregation-rules.conf)

• Правила за агрегиране на данни• OUT (freq) = method IN

<srv>.<srvid>.all (20) = <srv>.<srvid>.x*.qps


В случай че имате множество машини може да агрегиратеданните за да не товарите фронтенда. Това се постига чрезaggregation-rules.conf


Roll-UP (понижаване на точността)

• Данни с висока точност са ни нужни за кратко време• Пести се дисково пространство• Улеснява изчертаването• По-полезни са на мениджмънт хората• storage-aggregation.conf


Данни с висока резолюция са полезни но за съжалениеконсумират доста пространство. Също така са трудни запредставяне


Структуриране на метриките

• Измислете си схема и я следвайте• environment.application.instance.metric.dimension• production.retriever.high-prio.pages.per-second• Не се страхувайте да задълбаете• Изисквайте унифицирани метрики (min, avg, max,persec)

• Blacklist и Whitelist• Не е грешка да кривнете.


Един от основните фактори за успеха/провала на тази висистема е структурирането на метриките ви. Подредете ги поначин който е удобен за вас и вашия бизнес. Ако приложение неможе да ви даде метриките във вид който ви интересувапомислете или да преименувате метриките от сървърна странаили да смените библиотеката/приложението. Не се страхувайтеда нарушите схемата (поне в по ниските нива) ако това есмислено за случая. Настоявайте метрики да се генерират поопределен начин и да се подават с определени имена (ще сиспестите не малко главоболия). Не се притеснявайте даотхвърляте метрики.


Цялостна система


Ще покажем как изглежда нашата система и защо е изграденапо този начин.


Изграждане на надеждна система

• Много копия• Разпределено• Кешове• Възстановяване?• Тестове, тестове, тестове


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


Изграждане на надеждна система (2)

• Graphite е CPU ограничен• Превърнете го в ограничен по диск• Много кешове• Буфери• Опашки


По дизайн самият графит е ограничен до една процесорнанишка. Което сътветно го спъва в конфигурацията поподразбиране. За да избегнем това трябва да пуснем множествоинстанции за да оползотворим всички налични процесори ипостепенно да го превърнем в ограничен по диск. Имайтепредвид че метода по който графит записва данните на дискаводи до не малко количество операции. За да се избегне товаизползвайте много кешове с либерални буфери и опашки. Другтрик е да вкарате графит в режим при който той записваданните пакетно (а не точка по точка). Като цяло това се случвапочти от само себе си.


Системата


Системата ни е изградена от N+1 броя нодове като даннитемежду тя са разпределени със резервираност. Показан еопростен вариант със само 2 нода. Тази система поне спореднашите скромни наблюдения спокойно може да понесе около2000 метрики в секунда. Системата е изградена на множествонива с цел да може да се подменя/рестартира/разширява всякоедно ниво само за себе си. Нивата които имаме са: * Главенколектор - collectd * Първичен relay - carbon-relay - използва сеза осъществяване на репликация на данните и реализация набуфер * Вторичен relay - carbon-relay - използва се за бъдещоразширяване на системата и реализира буфер * агрегатор наданни - carbon-aggregator - използва се за пресмятане на някоистойности и пестене на диск + буфер * кешофе - carbon-cache -записват данните на диска


Демонстрация


Малка демонстрация как работят нещата.


Въпроси?



Връзки

• Слайдове: http://bit.ly/1JMShuv• Demo: http://bit.ly/1PIcMKF• mail: [email protected]• GPG: A162 1211 8ACB 4CC5


high volume monitoring with graphite

Technology