Преди много време, когато се присъединих към бума на dot-com, бях въведен в изкуството на управлението на разположени сървъри, известно още като системна администрация. Бях направил справедлив дял от програмирането на C и Fortran чрез официалното си образование. Няколко стелажа със сървъри обаче бяха ново предизвикателство и по онова време най-голямата мистерия беше как ни таксуват за честотна лента. Получаваме „5 мегабита при 95-ия процентил“ или нещо подобно. Това означаваше, че на всеки пет минути нашето използване на мрежата се записва и ако тези петминутни прозорци бяха сортирани, 95% от тези прозорци ще трябва да измерват по-малко от 187,5 мегабайта за всеки 5-минутен прозорец, за да се избегнат такси за свръх. Този подход беше наречен „„burstable billing““.

Бързо напред с около 10 години до 2011 г. и Etsy пусна StatsD, който предостави възможност на потребителите да записват проби за латентност и да изчисляват 90-ия персентил за група проби с помощта на таймер StatsD. По онова време това беше подобрение от записването на латентност с инструменти като RRD и предоставяне на агрегации на средни, минимални и максимални стойности на латентност. P90 се превърна в дефакто подхода за измерване на латентността и разцъфтя сред практикуващите уеб. Стойността на латентността p90 за дадена услуга определя нейната производителност — „422ms p90“ би бил един такъв пример.

Това беше златната ера на монолитите, хоствани в среди с тежки метали. Спомням си как слушах приятел по това време, който беше водещ ръководител на акаунти в Salesforce, по телефона, предоставяйки нов акаунт — „Имам нужда от деветдесет настройка на сървърна среда“. Тръби, захранване и пинг. Всичко щеше да се промени скоро с възхода на Heroku и PAAS, но домакините все още бяха домашни любимци, а не говеда, и p90 подходът за измерване на латентността работеше достатъчно добре. Нюанси като способността за „осредняване на p90 агрегати“ не бяха проблем; един от дузината хостове, които се държаха неправилно, беше достатъчно лесен за идентифициране, а потребителската база предимно на лаптопи/настолни компютри и ограничените широколентови опции хомогенизираха производителността на уеб услугите от гледна точка на нововъзникващите DevOps практици.

С нарастването на употребата на StatsD сред практикуващите обаче, зад кулисите се появяват технологични пробиви. „Monarch в Google“, „HDR хистограма от Gil Tene“ и „сега OpenHistogram log linear хистограма“ възникват като подходи за измерване на латентността с помощта на хистограми, които осигуряват високо прецизни измервания на латентността в десетки и стотици хостове. Писах за „компромисите от използването на процентили за измерване на латентността“ преди три години.

Докато това е написано в услуга на доставчик на наблюдаемост, основният принцип е математически неизбежен; използването на процентили за измерване на латентността има ограничения. Процентилите като вектори за събиране и съхранение са обект на грешки не само поради грешка на потребителя (усредняване или други техники за агрегиране), но също така и вариация на обема на искане и прозорци. Почти всички доставчици на наблюдаемост (и всички инструменти с отворен код) позволяват на потребителите да осредняват процентили, което е математически неправилно. Когато процентили (и в някои случаи приблизителни хистограми) групират измерванията в обвързани с времето агрегации, вариациите в трафика могат да бъдат нормализирани и сигналите за латентност да бъдат отслабени. Събитие от типа Черен петък (може би за което сте се увеличили) може да донесе 500% повече трафик от нормалното, но с латентност, агрегирана в процентилни прозорци, тези сегменти на трафика се отчитат еднакво спрямо измерванията извън пиковия период. 5 минути влошено обслужване в непиковите часове се броят еднакво за 5 минути при екстремни събития.

Може да са добре, ако се опитвате да осигурите няколко деветки надеждност, но p90, p99 или дори p99.9 няма да ви отведат там с разпределени системи и сложни профили на натоварване. Проблемът не е само в границите на грешките на квантилните структури (t-дайджест, GK скица и т.н.); слабостта е в ограниченията на системите, които ги прилагат. Архитектурните детайли в имплементациите (като модели за съгласуваност на TSDB), съчетани с мащабни случаи на производствена употреба, в крайна сметка извеждат пропускливи абстракции на информирани крайни потребители. Когато използвате процентили в мащаб, си струва да разберете точно „как се прави наденицата“ за каквато и система за наблюдение да използвате.

Процентилите са страхотни индикатори при измерване на изпълнението на заявката „щастлив път“; бенчмарковете са повтаряеми и хомогенни за разлика от производствения трафик с висока кардиналност. Когато оптимизирате тестови случаи на производителност, те обикновено са добър индикатор за успешни усилия. Трябва обаче да се има предвид каква е целта на усилията за оптимизация; в мултимодален профил на латентност просто преместване наляво е груба техника. Идентифицирането на режими на латентност, които съответстват на случаи на бизнес употреба с висока стойност, е по-хирургичен и ефикасен подход.

Какво тогава трябва да направи един практик DevOps? Първо, когато е възможно, използвайте HDR хистограми за улавяне на данни за латентност; „възможно е да се генерират процентили с висока точност от тези, ако е необходимо“. Той също така улеснява използването на обратни квантили и латентни ленти, обсъдени по-долу. Това обаче е най-подходящо за подхода на зелено поле - прилагането на HDR хистограми в големи сложни наследени системи може да бъде предизвикателство.

Алтернативен подход „използване на метрични маркери за прилагане на хистограми със съществуващи данни от времеви серии чрез подход, базиран на брояч“. Това може да се постигне с всяка система, която използва броячи тип StatsD. Или по-простият случай на избиране на праг на латентност (да речем 500 ms) и преброяване на броя на заявките над и под този праг е достатъчен, за да се осигурят висококачествени измервания на латентността. И двата подхода, както и подходът HDR, предоставят възможността да се използват така наречените обратни квантили (обратни процентили).

Вместо да търсим да разберем каква е латентността при определен процент от заявките (напр. p90 е 435 ms), човек трябва да търси обратни квантили, за да разбере какъв процент от заявките отговаря на дадено забавяне (96% от заявките са под 500 ms). Ако се очаква услугата за удостоверяване да върне отговор в рамките на 20 ms, може да искаме да разберем какъв процент от заявките попадат в този праг - това е обратен квантил (за разлика от квантил/персентил, който определя латентността при даден процент, като например 90, 95 и т.н.). Това ни позволява да проектираме системи с оглед на това очаквано забавяне, което може да се приложи с тактики като прекъсвачи на веригата, за да се наложи качество на услугата при заявка. Обратните квантили са значително по-лесни за правилно прилагане от квантилите — трябва само да се броят заявките в рамките на определени ленти на латентност.

Перцентилен (Квантилен) подход — p95 (q(0,95)) за месец е 455ms
Обратен квантилен подход — 97% от заявките за месец под 500ms

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

Как човек прави това точно? Има „няколко ресурса“, „достъпни“ за „практикуващите“, но това се свежда до обратния квантилен подход за съхраняване на измерванията на латентността или с хистограми, или като брой заявки над или под даден праг. Подходът, базиран на хистограма, е най-добрият в класа си, тъй като ни позволява да оценим ефективността на услугата спрямо различни исторически прагове. Използвайки този подход, можем лесно да определим количествено забавянето на услугата с много висока степен на точност. Можем лесно да кажем дали услугата X е успяла да достави отговори под 100 ms за 99,95% от заявките. И тези подходи все още ни дават възможността да разглеждаме p90 за нашата услуга като нещо, с което сме свикнали (и такова, което вероятно е по-точно от приблизителна хистограма или средна стойност на перцентили на хост).

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

Инверсна квантилна измамна таблица — изберете вашия праг на латентност, пребройте броя на заявките по-бързо от това. #fast_events/#total_events = XX,XXX%. Лесен за изпълнение, висока точност, ниска грешка. Работи и за наследени системи.

Благодаря на Jacob D’Onofrio за редакционната рецензия.