Логира во Кубернетес (и не само) денес: очекувања и реалност

2019 година е, а сè уште немаме стандардно решение за агрегација на дневници во Kubernetes. Во оваа статија, би сакале, користејќи примери од вистинската пракса, да ги споделиме нашите пребарувања, проблеми со кои се соочуваме и нивните решенија.

Сепак, прво, ќе направам резервација дека различни клиенти разбираат многу различни работи со собирање логови:

• некој сака да ги види дневниците за безбедност и ревизија;
• некој - централизирано сеча на целата инфраструктура;
• а за некои, доволно е да се соберат само дневници за апликации, со исклучок на, на пример, балансери.

Подолу е резимето подолу за тоа како имплементиравме различни „списоци на желби“ и какви потешкотии наидовме.

Теорија: за алатките за сеча

Позадина на компонентите на системот за сеча

Сечата помина долг пат, како резултат на што се развиени методологии за собирање и анализа на дневниците, што е она што го користиме денес. Во 1950-тите, Фортран воведе аналог на стандардни влезни/излезни текови, што му помогна на програмерот да ја дебагира својата програма. Ова беа првите компјутерски дневници што им го олеснија животот на програмерите од тоа време. Денес во нив ја гледаме првата компонента на системот за сеча - извор или „производител“ на трупци.

Компјутерската наука не застана: се појавија компјутерски мрежи, првите кластери... Почнаа да работат сложени системи составени од неколку компјутери. Сега системските администратори беа принудени да собираат логови од неколку машини, а во посебни случаи можеа да додаваат пораки од јадрото на ОС во случај да треба да истражат дефект на системот. За да се опишат централизираните системи за собирање дневници, во раните 2000-ти беше објавен RFC 3164, што го стандардизираше remote_syslog. Вака се појави уште една важна компонента: собирач на трупци и нивно складирање.

Со зголемувањето на обемот на дневници и широкото воведување на веб-технологии, се појави прашањето кои дневници треба да им се прикажат удобно на корисниците. Едноставните алатки за конзола (awk/sed/grep) се заменети со понапредни гледачи на дневници - трета компонента.

Поради зголемувањето на обемот на трупци, нешто друго стана јасно: потребни се трупци, но не сите. И различни трупци бараат различни нивоа на зачувување: некои може да се изгубат за еден ден, додека други треба да се чуваат 5 години. Значи, компонента за филтрирање и рутирање на тековите на податоци беше додадена во системот за евиденција - ајде да го наречеме филтер.

Складирањето, исто така, направи голем скок: од обични датотеки до релациони бази на податоци, а потоа до складирање ориентирано кон документи (на пример, Elasticsearch). Така складиштето беше одвоено од колекторот.

На крајот, самиот концепт на дневник се прошири на еден вид апстрактен тек на настани што сакаме да ги зачуваме за историјата. Или подобро кажано, во случај да треба да спроведете истрага или да изготвите аналитички извештај...

Како резултат на тоа, за релативно краток временски период, собирањето на дневници се разви во важен потсистем, кој со право може да се нарече еден од потсекциите во Big Data.

Ако некогаш обичните отпечатоци можеа да бидат доволни за „систем за сеча“, сега ситуацијата е многу променета.

Кубернети и трупци

Кога Кубернетес дојде до инфраструктурата, не ја заобиколи ниту веќе постоечкиот проблем со собирање трупци. На некој начин, стана уште поболно: управувањето со инфраструктурната платформа не само што беше поедноставено, туку и комплицирано во исто време. Многу стари услуги почнаа да мигрираат кон микросервисите. Во контекст на дневниците, ова се рефлектира во зголемениот број на извори на дневници, нивниот посебен животен циклус и потребата да се следат односите на сите компоненти на системот преку дневници...

Гледајќи напред, можам да констатирам дека сега, за жал, не постои стандардизирана опција за логирање за Kubernetes што би се споредувала поволно со сите други. Најпопуларните шеми во заедницата се како што следува:

• некој го одмотува оџакот ЕФК (Elasticsearch, Fluentd, Kibana);
• некој го пробува неодамна објавениот Локи или користи Оператор за логирање;
• нас (а можеби не само ние?..) Во голема мера сум задоволен од сопствениот развој - дневник...

Како по правило, ги користиме следните пакети во кластерите на K8s (за решенија кои сами се одржуваат):

• Fluentd + Elasticsearch + Kibana;
• Fluentd + ClickHouse + loghouse.

Сепак, нема да се задржувам на инструкциите за нивна инсталација и конфигурација. Наместо тоа, ќе се фокусирам на нивните недостатоци и поглобални заклучоци за состојбата со трупците воопшто.

Вежбајте со логови во K8s

„Секојдневни трупци“, колку од вас се таму?..

Централизираното собирање на трупци од прилично голема инфраструктура бара значителни ресурси, кои ќе бидат потрошени за собирање, складирање и обработка на дневниците. Во текот на работењето на различни проекти се соочивме со различни барања и оперативни проблеми кои произлегуваа од нив.

Ајде да го пробаме ClickHouse

Ајде да погледнеме во централизирано складирање на проект со апликација која генерира логови доста активно: повеќе од 5000 линии во секунда. Да почнеме да работиме со неговите логови, додавајќи ги во ClickHouse.

Штом е потребно максимално реално време, серверот со 4 јадра со ClickHouse веќе ќе биде преоптоварен на потсистемот на дискот:

Овој тип на вчитување се должи на фактот што се обидуваме да пишуваме во ClickHouse што е можно побрзо. И базата на податоци реагира на ова со зголемено оптоварување на дискот, што може да ги предизвика следните грешки:

DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts

Факт е дека MergeTree табели во ClickHouse (тие содржат податоци од дневникот) имаат свои тешкотии за време на операциите за запишување. Податоците вметнати во нив генерираат привремена партиција, која потоа се спојува со главната табела. Како резултат на тоа, снимката се покажува како многу напорна на дискот, а исто така е предмет на ограничувањето за кое добивме известување погоре: не може да се спојат повеќе од 1 подпартиции за 300 секунда (всушност, ова се 300 вметнувања во секунда).

За да се избегне ова однесување, треба да пишува на ClickHouse во што е можно поголеми парчиња и не повеќе од 1 пат на секои 2 секунди. Сепак, пишувањето во големи рафали сугерира дека треба да пишуваме поретко во ClickHouse. Ова, пак, може да доведе до прелевање на баферот и губење на дневниците. Решението е да се зголеми Fluentd баферот, но потоа ќе се зголеми и потрошувачката на меморија.

Имајте на ум: Друг проблематичен аспект на нашето решение со ClickHouse беше поврзан со фактот дека партиционирањето во нашиот случај (loghouse) се спроведува преку надворешни табели поврзани Спојување на табелата. Ова води до фактот дека при земање примероци на големи временски интервали, потребна е прекумерна RAM меморија, бидејќи мета-табелата се повторува низ сите партиции - дури и оние што очигледно не ги содржат потребните податоци. Меѓутоа, сега овој пристап може безбедно да се прогласи за застарен за тековните верзии на ClickHouse (в 18.16).

Како резултат на тоа, станува јасно дека не секој проект има доволно ресурси за собирање логови во реално време во ClickHouse (поточно, нивната дистрибуција нема да биде соодветна). Покрај тоа, ќе треба да користите акумулатор, на која ќе се вратиме подоцна. Случајот опишан погоре е реален. И во тоа време не можевме да понудиме сигурно и стабилно решение кое ќе одговара на клиентот и ќе ни овозможи да собираме трупци со минимално доцнење...

Што е со Elasticsearch?

Познато е дека Elasticsearch се справува со тешки оптоварувања. Ајде да го пробаме во истиот проект. Сега товарот изгледа вака:

Elasticsearch беше во можност да го свари протокот на податоци, меѓутоа, пишувањето такви томови во него во голема мера го користи процесорот. Ова се решава со организирање на кластер. Технички, ова не е проблем, но излегува дека само за да работиме со системот за собирање трупци веќе користиме околу 8 јадра и имаме дополнителна високо оптоварена компонента во системот...

Крајна линија: оваа опција може да се оправда, но само ако проектот е голем и неговото управување е подготвено да потроши значителни ресурси на централизиран систем за сеча.

Тогаш се поставува природно прашање:

Кои логови се навистина потребни?

Ајде да се обидеме да го промениме самиот пристап: дневниците треба истовремено да бидат информативни и да не покриваат секој настан во системот.

Да речеме дека имаме успешна онлајн продавница. Кои логови се важни? Собирањето што е можно повеќе информации, на пример, од портал за плаќање, е одлична идеја. Но, не сите дневници од услугата за сечење слики во каталогот на производи се клучни за нас: доволни се само грешки и напредно следење (на пример, процентот од 500 грешки што ги генерира оваа компонента).

Значи дојдовме до заклучок дека централизираното сеча не е секогаш оправдано. Многу често клиентот сака да ги собере сите дневници на едно место, иако всушност, од целиот дневник, потребни се само условни 5% од пораките кои се критични за бизнисот:

• Понекогаш е доволно да се конфигурира, да речеме, само големината на дневникот на контејнерот и собирачот на грешки (на пример, Sentry).
• Известувањето за грешка и самиот голем локален дневник често може да бидат доволни за да се истражат инцидентите.
• Имавме проекти кои се задоволуваа со исклучиво функционални тестови и системи за собирање грешки. На развивачот не му требаа дневници како такви - тие видоа сè од трагите на грешки.

Илустрација од животот

Друга приказна може да послужи како добар пример. Добивме барање од безбедносниот тим на еден од нашите клиенти кој веќе користеше комерцијално решение кое беше развиено долго пред воведувањето на Kubernetes.

Беше неопходно да се „дружиме“ со централизираниот систем за собирање дневници со корпоративниот сензор за откривање проблеми - QRadar. Овој систем може да прима дневници преку протоколот syslog и да ги преземе од FTP. Сепак, не беше можно веднаш да се интегрира со приклучокот remote_syslog за fluentd (како што се испостави, не сме сами). Проблемите со поставувањето на QRadar се покажаа на страната на безбедносниот тим на клиентот.

Како резултат на тоа, дел од бизнис-критичните дневници беа поставени на FTP QRadar, а другиот дел беше пренасочен преку далечински системски дневник директно од јазлите. За ова дури и напишавме едноставна табела - можеби тоа ќе помогне некому да реши сличен проблем... Благодарение на шемата што се појави, самиот клиент прими и анализираше критични дневници (користејќи ги неговите омилени алатки), а ние успеавме да ги намалиме трошоците за системот за сеча, заштедувајќи само претходниот месец.

Друг пример е сосема индикативен за тоа што не треба да се прави. Еден од нашите клиенти за обработка од секоја настани кои доаѓаат од корисникот, направени повеќелиниски неструктуриран излез информации во дневникот. Како што може да претпоставите, таквите логови беа крајно незгодни и за читање и за складирање.

Критериуми за логови

Ваквите примери доведуваат до заклучок дека покрај изборот на систем за собирање трупци, треба да исто така дизајнирајте ги самите трупци! Кои се барањата овде?

• Дневниците мора да бидат во машински читлив формат (на пример, JSON).
• Дневниците треба да бидат компактни и со можност за промена на степенот на логирање со цел да се дебагираат можните проблеми. Во исто време, во производните средини треба да стартувате системи со ниво на логирање како Предупредување или грешка.
• Дневниците мора да се нормализираат, односно во објектот за дневник, сите линии мора да имаат ист тип на поле.

Неструктурираните дневници може да доведат до проблеми со вчитување на дневниците во складиштето и целосно прекинување на нивната обработка. Како илустрација, еве еден пример со грешка 400, која многумина дефинитивно ја сретнале во течни дневници:

2019-10-29 13:10:43 +0000 [warn]: dump an error event: error_class=Fluent::Plugin::ElasticsearchErrorHandler::ElasticsearchError error="400 - Rejected by Elasticsearch"

Грешката значи дека испраќате поле чиј тип е нестабилен до индексот со готово мапирање. Наједноставниот пример е поле во дневникот на nginx со променлива $upstream_status. Може да содржи или број или низа. На пример:

{ "ip": "1.2.3.4", "http_user": "-", "request_id": "17ee8a579e833b5ab9843a0aca10b941", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staffs/265.png", "protocol": "HTTP/1.1", "status": "200", "body_size": "906", "referrer": "https://example.com/staff", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.001", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "127.0.0.1:9000", "upstream_status": "200", "upstream_response_length": "906", "location": "staff"}
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "47fe42807f2a7d8d5467511d7d553a1b", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staff", "protocol": "HTTP/1.1", "status": "200", "body_size": "2984", "referrer": "-", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.010", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "10.100.0.10:9000, 10.100.0.11:9000", "upstream_status": "404, 200", "upstream_response_length": "0, 2984", "location": "staff"}

Дневниците покажуваат дека серверот 10.100.0.10 одговорил со грешка 404 и барањето е испратено до друго складирање содржина. Како резултат на тоа, вредноста во дневниците стана вака:

"upstream_response_time": "0.001, 0.007"

Оваа ситуација е толку вообичаена што дури и заслужува посебна референци во документацијата.

Што е со сигурноста?

Има моменти кога сите дневници без исклучок се од витално значење. И со ова, типичните шеми за собирање дневници за K8 предложени/дискутирани погоре имаат проблеми.

На пример, fluentd не може да собира трупци од краткотрајни контејнери. Во еден од нашите проекти, контејнерот за миграција на базата на податоци живееше помалку од 4 секунди, а потоа беше избришан - според соодветната прибелешка:

"helm.sh/hook-delete-policy": hook-succeeded

Поради ова, дневникот за извршување на миграцијата не беше вклучен во складиштето. Политиката може да помогне во овој случај. before-hook-creation.

Друг пример е ротација на дневникот на Docker. Да речеме дека постои апликација која активно пишува во дневници. Во нормални услови, успеваме да ги обработиме сите дневници, но штом се појави проблем - на пример, како што е опишано погоре со погрешен формат - обработката запира, а Docker ја ротира датотеката. Резултатот е дека бизнис-критичните дневници може да се изгубат.

Затоа важно е да се одделат тековите на дневниците, вградување испраќање на највредните директно во апликацијата за да се обезбеди нивната безбедност. Покрај тоа, не би било излишно да се создадат некои „акумулатор“ на трупци, што може да преживее кратка недостапност за складирање додека зачувува критични пораки.

Конечно, тоа не смееме да го заборавиме Важно е правилно да се следи секој потсистем. Во спротивно, лесно е да се залеташ во ситуација во која флуентд е во состојба CrashLoopBackOff и не испраќа ништо, а тоа ветува губење на важни информации.

Наоди

Во оваа статија, не ги разгледуваме решенијата за SaaS како Datadog. Многу од проблемите опишани овде веќе се решени на еден или друг начин од комерцијални компании специјализирани за собирање дневници, но не секој може да користи SaaS од различни причини (главните се трошоците и усогласеноста со 152-FZ).

Централизираното собирање на дневници на почетокот изгледа како едноставна задача, но воопшто не е. Важно е да се запамети дека:

• Само критичните компоненти треба детално да се најават, додека следењето и собирањето грешки може да се конфигурираат за други системи.
• Дневниците во производството треба да бидат минимални за да не се додаде непотребно оптоварување.
• Дневниците мора да бидат машински читливи, нормализирани и да имаат строг формат.
• Навистина критичните дневници треба да се испратат во посебен тек, кој треба да се одвои од главните.
• Вреди да се размисли за акумулатор на трупци, кој може да ве спаси од изливи на големо оптоварување и да го направи товарот на складиштето порамномерен.

Овие едноставни правила, доколку се применат насекаде, ќе им овозможат на кола опишани погоре да работат - иако им недостасуваат важни компоненти (батеријата). Ако не се придржувате до таквите принципи, задачата лесно ќе ве одведе вас и инфраструктурата до друга високо оптоварена (и во исто време неефикасна) компонента на системот.

PS

Прочитајте и на нашиот блог:

• «Воведување на loghouse - систем со отворен код за работа со дневници во Kubernetes";
• «Изданија за екосистемот Kubernetes од KubeCon'19: JFrog Container Registry, Kui од IBM, Loki 1.0.0…";
• «Мониторинг и Kubernetes (преглед и видео извештај)".

Извор: www.habr.com