Как да наблюдаваме златните сигнали SRE

Всъщност получаване на показателите от общи услуги

(Забележка: Безплатна PDF електронна книга за цялата тази серия от 6 части е достъпна тук)

Инженерингът за надеждност на сайта (SRE) и свързаните с него концепции са много популярни напоследък, отчасти благодарение на известната книга на Google SRE и други, които говорят за „Златните сигнали“, които трябва да наблюдавате, за да поддържате системите си бързи и надеждни, докато те мащабират.

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

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

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

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

И накрая, има списък на специфични за услугата ръководства за това как да следите сигналите, за зареждане на балансиращи устройства, сървъри за уеб и приложения, сървъри за DB и кеш, General Linux и други. Този списък и детайлите могат да се развият с течение на времето, тъй като непрекъснато търсим обратна връзка и по-добри методи за получаване на по-добри данни.

Първо, какви са SRE сигналите?

Има три общи списъка или методологии:

  • От книгата на Google SRE: закъснение, трафик, грешки и насищане
  • USE метод (от Brendan Gregg): използване, насищане и грешки
  • ЧЕРВЕН метод (от Том Уилки): Скорост, грешки и продължителност

Можете да видите припокриването и както отбелязва Барон Шварц в своя блог за наблюдение и наблюдение с USE и RED, всеки метод варира във фокуса. Той предполага, че USE е за ресурси с вътрешен изглед, докато RED е за заявки, реална работа и по този начин външен изглед (от гледна точка на потребителя на услугата). Те очевидно са свързани и също се допълват, тъй като всяка услуга консумира ресурси, за да свърши работа.

За нашите цели ще се съсредоточим върху обикновен набор от пет сигнала:

  • Rate - скорост на заявка, в заявки / сек
  • Грешки - честота на грешките в грешки / сек
  • Закъснение - Време за отговор, включително време за опашка / чакане, в милисекунди.
  • Наситеност - Колко е претоварено нещо, което е свързано с използване, но по-пряко се измерва с неща като дълбочина на опашката (или понякога едновременност). Като измерване на опашката това става ненулево, когато сте наситени, често не много преди. Обикновено брояч.
  • Използване - колко натоварен е ресурсът или системата. Обикновено се изразява 0–100% и е най-полезен за прогнози (тъй като наситеността вероятно е по-полезна). Забележете, че не използваме Закона за използване, за да получим това (~ Оцени x време за обслужване / работници), а вместо това търсим по-познати директни измервания.

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

Всички тези измервания могат да бъдат разделени и / или обобщени от различни неща. Например, HTTP може да се раздели на 4xx и 5xx грешки, точно както Latency или Rate могат да бъдат разбити по URL.

Освен това има по-сложни начини за изчисляване на нещата. Например, грешките често имат по-ниска латентност от успешните заявки, така че можете да изключите грешки от Latency, ако можете (често не можете).

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

Сега имаме своите сигнали, какво правим с тях?

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

Една от основните причини това са „Златните“ сигнали е, че те се опитват да измерват неща, които пряко засягат крайния потребител и произвеждащи работа части от системата - те са директни измервания на важни неща.

Това означава, на теория, те са по-добри и по-полезни от много по-малко директни измервания като процесор, RAM, мрежи, изоставане на репликацията и безкрайни други неща (трябва да знаем, тъй като често наблюдаваме 200+ елемента на сървър; никога Добро време).

Ние събираме Златните сигнали по няколко причини:

  • Сигнал - Кажете ни, когато нещо не е наред
  • Отстраняване на неизправности - Помогнете ни да намерим и отстраним проблема
  • Настройка и планиране на капацитет - Помогнете ни да подобрим нещата с течение на времето

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

Сигнализацията традиционно използва статични прагове в нашите любими (ха!) Системи Nagios, Zabbix, DataDog и др. Това работи, но е трудно да се настрои добре и генерира много алармен шум, тъй като вие (и всеки, с когото живеете) най-вероятно вероятно са наясно.

Но започнете със статично, ако трябва, въз основа на вашия опит и най-добри практики. Те често работят най-добре, когато са зададени на нива, при които сме почти сигурни, че нещо не е наред или поне се случва необичайно (напр. 95% процесор, латентност за 10 секунди, опашки за скромен размер, честота на грешки над няколко в секунда и т.н. )

Ако използвате статично алармиране, не забравяйте сигналите от долната граница, като близо до нула заявки в секунда или закъснение, тъй като това често означава, че нещо не е наред, дори в 15:00, когато трафикът е лек.

Средна ли сте или процента?

Тези сигнали обикновено използват средни стойности, но направете си услуга и се опитайте да използвате средни стойности, ако можете, тъй като те са по-малко чувствителни към големи / малки стойности.

Средните стойности имат и други проблеми, както Optimizely посочва в своя блог. Все пак средните стойности / медианите са лесно разбираеми, достъпни и доста полезни като сигнал, стига вашият измервателен прозорец да е кратък (например 1–5 минути).

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

Въпреки това, процентилите са по-сложни, отколкото изглежда, и разбира се Vivid Cortex има блог за това: Защо Percentiles не работят по начина, по който мислите, където например той предупреждава, че вашата система наистина прави процентил от средно за времето на измерване (напр. 1 или 5 минути). Но все пак е полезно за сигнализиране и трябва да го опитате, ако можете (и често ще бъдете шокирани колко са лоши процентните ви проценти).

Аномалия ли си, или просто странна?

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

Откриването на аномалии обаче може да бъде доста предизвикателно, тъй като малко локални решения за мониторинг дори могат да го направят (Zabbix не може). Освен това е сравнително ново, все още се развива и е трудно да се настрои добре (особено със сезонността и тенденцията, толкова често срещана в нашите Златни сигнали).

За щастие, по-новите решения за мониторинг на SaaS / Cloud като DataDog, SignalFX и др. Могат да направят това, както и новите локални системи като Prometheus & InfluxDB.

Независимо от инструментите ви за аномалия, Барон Шварц има добра книга за това, която трябва да прочетете, за да разберете по-добре различните опции, алгоритми и предизвикателства: Откриване на аномалията за мониторинг.

Може ли да те видя?

В допълнение към алармата, вие също трябва да визуализирате тези сигнали. Weave Works има приятен формат, с две графични колони, а Splunk има хубава гледка. Отляво графичен график на тарифите за заявки и грешки, а вдясно графики за забавяне. Можете да добавите и в трета смесена графика на насищане / използване.

Можете също така да обогатите показателите си с етикети / събития, като разгръщане, събития с автоматично мащабиране, рестартиране и т.н. И в идеалния случай да покажете всички тези показатели на карта на архитектурата на системата, както прави Netsil.

Поправете ме, поправете ви

Като последна бележка за алармирането, ние открихме сигналите за Златен сигнал SRE по-трудно да реагираме, защото те всъщност са симптоми на основен проблем, който рядко е пряко изложен на сигнала.

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

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

Един от проблемите, които Златните сигнали помагат да се реши е, че твърде често имаме само полезни данни за няколко услуги и проблемът в предния край създава дълъг лов на виновника. Събирането на сигнали за всяка услуга помага да се определи коя услуга е най-вероятната причина (особено ако имате информация за зависимостта) и по този начин къде да се съсредоточите.

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

Получаване на данните от всяка услуга

По-долу са статиите от приложението за различни популярни услуги и ние работим за добавяне на повече с течение на времето. Отново приветстваме отзивите за тях.

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

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

Моля, вижте тези връзки за следващи статии как да събирате данни за всяка услуга:

  • Балансиращи натоварвания - AWS ALB / ELB, HAProxy
  • Уеб сървъри - Apache & Nginx
  • Приложни сървъри - PHP, FPM, Java, Ruby, Node, Go, Python
  • Сървъри на бази данни - MySQL & AWS RDS
  • Сървъри на бази данни - AWS Aurora
  • Linux сървъри - като основни ресурси

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

(Забележка: Безплатна PDF електронна книга за цялата тази серия е достъпна тук)

Ако ви хареса тази статия, моля, помогнете на приятелите си с пляскане или дял.

Стив Мушеро е световен технолог със седалище в Шанхай и Сан Франциско. Той е главен изпълнителен директор на Siglos.io и ChinaNetCloud, като се фокусира върху големи системни операции в Интернет. Свържете се с него в LinkedIn или поздравете в Twitter.

Присъединете се към нашата общност Slack и прочетете нашите седмични теми на Faun ⬇

Ако тази публикация беше полезна, моля, кликнете върху бутона the по-долу няколко пъти, за да покажете вашата подкрепа за автора! ⬇