🥇Дневници в Kubernetes (и не само) днес: очаквания и реалност

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

Първо обаче ще направя резервация, че различните клиенти разбират много различни неща, като събират регистрационни файлове:

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

По-долу е разрезът по-долу за това как внедрихме различни „списъци с желания“ и какви трудности срещнахме.

Теория: относно инструментите за регистриране

Предистория на компонентите на система за регистриране

Сечът измина дълъг път, в резултат на което бяха разработени методологии за събиране и анализ на регистрационни файлове, които използваме днес. Още през 1950-те години на миналия век Fortran въведе аналог на стандартни входно-изходни потоци, който помогна на програмиста да отстрани грешки в програмата си. Това бяха първите компютърни регистрационни файлове, които улесниха живота на програмистите от онези времена. Днес виждаме в тях първия компонент на системата за регистриране - източник или „производител“ на регистрационни файлове.

Компютърната наука не стоеше неподвижна: появиха се компютърни мрежи, първите клъстери... Започнаха да работят сложни системи, състоящи се от няколко компютъра. Сега системните администратори бяха принудени да събират регистрационни файлове от няколко машини и в специални случаи можеха да добавят съобщения на ядрото на ОС, в случай че трябва да разследват системна повреда. За да опише централизирани системи за събиране на регистрационни файлове, в началото на 2000-те години беше публикувана RFC 3164, който стандартизира remote_syslog. Ето как се появи друг важен компонент: събирач на трупи и тяхното съхранение.

С увеличаването на обема на регистрационните файлове и широкото въвеждане на уеб технологиите възникна въпросът какви регистрационни файлове трябва да се показват удобно на потребителите. Простите конзолни инструменти (awk/sed/grep) са заменени от по-усъвършенствани зрители на журнали - трети компонент.

Поради увеличаването на обема на трупите стана ясно още нещо: трупи са необходими, но не всички. А различните трупи изискват различни нива на съхранение: някои могат да бъдат загубени за един ден, докато други трябва да се съхраняват 5 години. И така, компонент за филтриране и маршрутизиране на потоци от данни беше добавен към системата за регистриране - нека го наречем филтър.

Съхранението също направи голям скок: от обикновени файлове към релационни бази данни и след това към документно-ориентирано съхранение (например Elasticsearch). Така хранилището беше отделено от колектора.

В крайна сметка самата концепция за дневник се разшири до един вид абстрактен поток от събития, които искаме да запазим за историята. Или по-скоро в случай, че трябва да проведете разследване или да съставите аналитичен доклад...

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

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

Kubernetes и трупи

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

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

някой разгръща стека EFK (Elasticsearch, Fluentd, Kibana);
някой опитва наскоро пуснатия Локи или използва Регистриращ оператор;
нас (а може би не само ние?..) До голяма степен съм доволен от собственото си развитие - дървена къща...

Като правило, ние използваме следните пакети в K8s клъстери (за самостоятелно хоствани решения):

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

Упражнявайте се с трупи в 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 (c 18.16).

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

Какво ще кажете за Elasticsearch?

Известно е, че Elasticsearch се справя с големи натоварвания. Нека опитаме в същия проект. Сега натоварването изглежда така:

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

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

Тогава възниква естествен въпрос:

Какви регистрационни файлове наистина са необходими?

Нека се опитаме да променим самия подход: регистрационните файлове трябва едновременно да бъдат информативни, а не да покриват всеки събитие в системата.

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

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

Понякога е достатъчно да конфигурирате, да речем, само размера на дневника на контейнера и колектора за грешки (например Sentry).
Известието за грешка и самият голям локален журнал често могат да бъдат достатъчни за разследване на инциденти.
Имахме проекти, които се задоволяваха с изключително функционални тестове и системи за събиране на грешки. Разработчикът не се нуждаеше от регистрационни файлове като такива - те видяха всичко от следите за грешки.

Илюстрация от живота

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

Беше необходимо да се „приятели“ на централизираната система за събиране на регистрационни файлове с корпоративния сензор за откриване на проблеми - QRadar. Тази система може да получава регистрационни файлове чрез протокола syslog и да ги извлича от FTP. Въпреки това не беше възможно веднага да се интегрира с приставката remote_syslog за fluentd (както се оказа, ние не сме сами). Проблемите с настройката на QRadar се оказаха от страна на екипа по сигурността на клиента.

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

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

Критерии за трупи

Такива примери водят до заключението, че освен да изберете система за събиране на трупи, трябва проектирайте и самите трупи! Какви са изискванията тук?

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

Неструктурираните регистрационни файлове могат да доведат до проблеми със зареждането на регистрационни файлове в хранилището и пълно спиране на тяхната обработка. Като илюстрация, ето пример с грешка 400, която много определено са срещали в fluentd регистрационните файлове:

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 завърта файла. Резултатът е, че критичните за бизнеса регистрационни файлове могат да бъдат загубени.

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

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

Данни

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

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

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

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

PS

Прочетете също в нашия блог:

Източник: www.habr.com

Дневници в Kubernetes (и не само) днес: очаквания и реалност