Регистриране в Kubernetes: как да събирате, съхранявате, анализирате и обработвате регистрационни файлове

Нека да преминем през основите на логването в Docker и Kubernetes и след това да разгледаме два инструмента, които могат безопасно да се използват в производството: Grafana Loki и стека EFK (Elasticsearch + Fluent Bit + Kibana).

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

Докер регистриране

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

Надявам се, че всеки читател знае: регистрационните файлове на приложението трябва да се записват в stdout / stderr, а не в контейнера. Регистрационните файлове се събират от Docker Daemon и той работи точно с тези регистрационни файлове, които се изпращат до stdout/stderr. В допълнение, записването на регистрационни файлове вътре в контейнера е изпълнено с проблеми: контейнерът се издува от нарастващия журнал (тъй като най-вероятно няма Logrotate в контейнера), а Docker Daemon не е наясно с този журнал.

Docker има няколко драйвера за регистриране или плъгини за събиране на регистриране на контейнери. Безплатното издание на общността на Docker (CE) има по-малко драйвери за регистрационни файлове от комерсиалното издание на Docker Enterprise (EE).

Никога не съм използвал Docker EE на практика: в Southbridge се опитваме да се придържаме към решения с отворен код и клиентите не се нуждаят от повечето допълнителни функции на Docker EE.

Регистрирайте драйвери в Docker CE:

местен - записване на логове във вътрешни файлове на Docker Daemon;
json файл - създаване на json-log в папката на всеки контейнер;
журнал - изпращане на регистрационни файлове към журнала.

Настройките за регистриране на Docker се намират във файла daemon.json.

Полето “log-driver” посочва приставката, а полето “log-opts” посочва неговите настройки. В примера по-горе е указан плъгинът „json-file“, ограничението за размер на журнала е „max-size“: „10m“; ограничение на броя на файловете (настройки за ротация) — „max-file“: „3“; както и стойностите, които ще бъдат прикачени към регистрационните файлове.

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

Ето как изглежда схемата за регистриране в Docker:

Как работи схемата: Дневник драйвер като json-файл създава файлове. Колекторите на журнали (Rsyslog, Fluentd, Logagent и други) събират тези файлове и ги прехвърлят в хранилище в Elastic, Sematext или други хранилища.

Характеристики на регистриране в Kubernetes

Опростено, схемата за логване в Kubernetes изглежда така: има под, в него работи контейнер, контейнерът изпраща журнали към stdout / stderr. След това Docker създава файл и записва регистрационни файлове, които след това може да ротира.

Обмислете характеристиките на регистриране в Kubernetes.

Запазване на регистрационни файлове между внедряванията. Това е предпоставка за правилни настройки за регистриране. Ако не запазвате регистрационни файлове между внедряванията, тогава, когато бъде пусната нова версия на приложението, регистрационните файлове на предишната ще бъдат презаписани, презареждането на контейнера също ще бъде изпълнено със загуба на регистрационни файлове. Kubernetes има ключ --previous, той ви позволява да преглеждате регистрационните файлове на приложението преди последното рестартиране на Pod, но не по-дълбоко.

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

Преди това нямаше удобни инструменти за събиране на регистрационни файлове както от системата, така и от микроуслугите. Обикновено единият инструмент събира системни регистрационни файлове (например Rsyslog), а вторият - регистрационни файлове от Docker (например journal-bit с драйвера за журнал на Docker, конфигуриран на journald). Опитахме се да използваме journal-bit - събирайте регистрационни файлове както от контейнери (посочете в драйвера за журнал на Docker, че трябва да пишете журнали в journald), така и от системата (CentOS 7 вече има systemd и journald). Решението работи, но не е перфектно. Ако има много регистрационни файлове, journal-bit започва да забавя, съобщенията се губят.

Експериментите продължиха - и беше намерен друг начин. В CentOS 7 основните системни регистрационни файлове (съобщения, проверка, защитени) се дублират във var-log като файлове. Docker може също да бъде конфигуриран да записва регистрационни файлове в json файлове. Съответно, тези файлове от CentOS 7 и Docker могат да бъдат сглобени заедно.

С течение на времето решението ELK Stack стана популярно. Това е комбинация от няколко инструмента: Elasticsearch, Logstash и Kibana.

Elasticsearch съхранява регистрационни файлове от контейнери, Logstash събира регистрационни файлове от инстанции, Kibana ви позволява да обработвате получените журнали и да изграждате графики въз основа на тях. ELK Stack се използва активно от известно време, но според мен времето му минава. По-късно ще ви кажа защо.

Добавете метаданни. Подове, приложения, контейнери могат да се изпълняват навсякъде. Освен това едно приложение може да има няколко екземпляра. Регистрационните файлове са записани в същия формат и ние трябва да разберем какъв вид реплика е, какво Pod го записва, в какво пространство от имена се намира. Ето защо регистрационните файлове трябва да добавят метаданни.

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

По правило не е необходимо да събирате и съхранявате всички регистрационни файлове, трябва да изпратите само част за съхранение - например регистрационни файлове със статус "предупреждение" или "грешка". Ако говорим за дневници на nginx или входен контролер, тогава за съхранение могат да бъдат изпратени само тези, чийто статус е различен от 200. Но това не е универсален съвет: ако по някакъв начин изградите анализи въз основа на дневници на Nginx, тогава те очевидно си струва да бъдат събрани.

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

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

Все още няма стандартно решение за регистриране. За разлика от мониторинга, където има едно най-разпространено решение на Prometheus, няма стандарт за регистриране.

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

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

Дневникът на контейнера остава, ротация, но се появява агент за събиране, който взима регистрите и ги изпраща за съхранение (на диаграмата - в Backend за регистриране). Агентът работи на всеки възел и обикновено се изпълнява на Kubernetes.

Сега разгледайте инструментите за регистриране.

Графана Локи

Графана Локи се появи наскоро, но вече стана доста известен. Неговите предимства: лесен за инсталиране, консумира малко ресурси, не изисква инсталиране на Elasticsearch, тъй като съхранява данни в TSDB (база данни с времеви редове). В миналата статия писах, че Prometheus съхранява данни в такава база данни и това е една от многото прилики между двата продукта. Разработчиците дори твърдят, че Локи е „Прометей за света на дърводобива“.

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

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

Архитектурата на Loki изглежда така:

С помощта на DaemonSet се внедрява агент на всички клъстерни сървъри - Promtail или Fluent Bit. Агентът събира дневници. Локи ги взема и ги съхранява в своята TSDB. Метаданните се добавят веднага към регистрационните файлове, което е удобно: можете да филтрирате по подове, пространства от имена, имена на контейнери и дори етикети.

Инструкции за инсталиране на Loki

Loki работи в познатия интерфейс на Grafana. Loki дори има свой собствен език за заявки, наречен LogQL, който е подобен по име и синтаксис на PromQL в Prometheus. Интерфейсът на Loki има подкани със заявки, така че не е необходимо да ги знаете наизуст.

LogQL документация

Локи в интерфейса на Grafana

Използвайки филтри, Локи може да намери кодове („400“, „404“ и всякакви други); преглед на регистрационни файлове от целия възел; филтрирайте всички регистрационни файлове, съдържащи думата "грешка". Ако щракнете върху дневника, ще се отвори карта с цялата информация за събитието.

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

Elastic + Fluent Bit + Kibana (EFK Stack)

EFK стекът е по-класически, но също толкова популярен инструмент за регистриране.

В началото на статията беше споменат ELK (Elasticsearch + Logstash + Kibana), но този стек е остарял поради не много продуктивния и в същото време ресурсоемък Logstash. Вместо това те започнаха да използват по-лекия и продуктивен Fluentd и след известно време той дойде на помощ Плавен бит - още по-лек и още по-продуктивен агент-колектор.

Според разработчиците, Fluent Bit е повече от 100 пъти по-добър в производителността от Fluentd: „където Fluentd консумира 20 MB RAM, Fluent Bit ще консумира 150 KB“ - директен цитат от документацията. Гледайки това, Fluent Bit стана по-широко използван.

Fluent Bit има по-малко функции от Fluentd, но покрива основните нужди, така че използваме предимно Fluent Bit.

Как работи стекът EFK: агентът събира регистрационни файлове от всички подове (обикновено DaemonSet, работещ на всички клъстерни сървъри) и ги изпраща в хранилище (Elasticsearch, PostgreSQL или Kafka). Kibana се свързва с хранилището и извлича цялата необходима информация от там.

Kibana представя информация в удобен за потребителя уеб интерфейс. Има диаграми, филтри и др.

Дневниците могат да се използват за създаване на цели табла за управление.

Функции на Fluent Bit

Тъй като Fluent Bit обикновено се чува по-малко от Logstash, нека го разгледаме по-отблизо. Fluent Bit може логически да бъде разделен на 6 модула, като към някои от модулите могат да бъдат прикачени добавки, които разширяват възможностите на Fluent Bit.

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

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

Парсер модул привежда дневниците в общ изглед. По подразбиране регистрационните файлове на Nginx са низ. С помощта на приставката този низ може да бъде преобразуван в JSON: задайте полетата и техните стойности. Работата с JSON е много по-лесна от дневника на низове, тъй като има по-гъвкави опции за сортиране.

Филтърен модул. На това ниво се елиминират ненужните регистрационни файлове. Например регистрационните файлове се изпращат за съхранение само със стойността „предупреждение“ или с определени етикети. Избраните регистрационни файлове се буферират.

Буферен модул. Fluent Bit има два типа буфер: буфер на паметта и буфер на диска. Буферът е временно хранилище на регистрационни файлове, необходимо в случай на грешки или повреди. Всеки иска да спести от RAM, така че обикновено избира дисков буфер. Но имайте предвид, че преди да отидат на диска, регистрационните файлове все още се разтоварват в паметта.

Модул за маршрутизиране/изход съдържа правила и адреси за изпращане на регистрационни файлове. Както вече споменахме, регистрационните файлове могат да се изпращат до Elasticsearch, PostgreSQL или, например, Kafka.

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

Ако планирате да използвате Elasticsearch...

И накрая, два съвета за тези, които планират да използват Elasticsearch като хранилище на журнали в производството.

1. Настройте сигнали с ElastAlert. Тази програма изолира важни съобщения от общия поток от регистрационни файлове и изпраща предупреждения за тях в пощата или друг канал. Вярно, не толкова отдавна тъжна новина, че проектът може скоро да спре да съществува.
2. Завъртете регистрационни файлове с приложението попечител или извиквания към API на Elasticsearch. Самата Elastic по принцип вече предприема значителни стъпки за управление на живота на индексите без използването на инструменти на трети страни. Като цяло няма смисъл да се съхраняват дневници дълго време: малко вероятно е да има нужда от дневник след две седмици - ако е наистина критичен, той определено ще бъде разработен за две седмици. В екстремни случаи старите регистрационни файлове могат да бъдат архивирани и изпратени някъде за дългосрочно съхранение. Чух за специални дневници, които по закон трябва да се пазят до 5 години. Лично аз не съм срещал това, но не бих приравнявал такава информация с обикновените регистрационни файлове и може би дори да ги съхранявам отделно.

За да се продължи ...

Автор: Марсел Ибраев, сертифициран Kubernetes администратор, практикуващ инженер в компанията Southbridge, лектор и разработчик на курсове Шурм.

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