Мы с Аней (@manabanana) — не тестировщики. Мы относимся к эволюционирующему классу IT-специалистов — системным администраторам или operations-инженерам. Но в нашей повседневной жизни мы тоже не обходимся без тестов. И сегодня мы хотим немного поговорить про Splunk. Точнее, вся наша статья будет именно про него.

С чего всё началось

Данная публикация «выросла» из нашего с Аней (@manabanana) выступления 1 августа 2019 года на седьмой встрече Общества анонимных тестировщиков, площадка для которой была любезно предоставлена технической командой Авито. И хотя с тех пор прошло довольно много времени, и мы приобрели новый опыт — с новыми системами, на новых задачах и в новых командах — мы считаем уместным ретроспективно осмыслить ещё раз этот совместный проект. Опыт, приобретённый в этом проекте, хоть и связан с эксплуатацией конкретного программного продукта, может быть перенесён на работу с другими большими высоконагруженными системами онлайн-аналитики и мониторинга. Это своего рода отчётное выступление о проделанной работе, которой было отдано много интеллектуальных (и эмоциональных) сил, и не безрезультатно.

Мы решили сохранить название, которое было дано нашему выступлению в анонсе встречи, и забегая вперёд, скажу, почему оно именно такое. Дело в том, что в процессе нашей работы со Splunk произошло два качественных перехода. Первый — из стабильного состояния в нестабильное, когда была достигнута критическая масса SPS (searches per second, поисков в секунду по данным, поступающим в систему). Второй качественный переход был обратным — снова в стабильность. И именно эту работу над вожделенной стабилизацией ситуации мы описываем в данном докладе. Помог нам в этом подход «test and learn» (вот почему мы оказались на встрече тестировщиков), а измерительными приборами послужили различные системы мониторинга: во-первых сам Splunk, имеющий замечательные возможности в части рефлексии и self-checking-а, а также некоторые другие, сторонние инструменты, о которых будет сказано в основном тексте.

Первую часть доклада подготовил я, в миру Михаил Ефремов — вычислительный шаман, зарабатывающий на хлеб автоматизацией процессов, а также поиском в красоты в сложном (что воплощается в постоянной работе по систематизации различных знаний, которыми я очень люблю делиться), в глубине души влюблённый в абстрактную математику, data science и науку вообще. Но моя часть на самом деле лишь вводная, описывающая общее положение вещей, картину «поля боя» с тактико-техническими характеристиками основного орудия.

Вторую, часть, содержащую основную суть доклада, подготовила и прочитала на встрече Анна Манакова, вклад которой в стабилизацию состояния описываемой системы нельзя переоценить. В связи с последним я бы предложил тем, кто замахнётся поставить плюс (если такие найдутся), поощрить ненулевой кармой прежде всего @manabanana— Аню, классного специалиста в области эксплуатации сложных систем и data processing, фаната своего дела.

Перейдём непосредственно к тексту.

Вступление

Вероятно, вы знаете, что компания Splunk всерьез и, возможно, надолго ушла с рынка этой страны. Но мы продолжаем работать со Splunk, я этим занимаюсь больше 5 лет, а Аня, @manabanana — второй год. Мы обросли практикой, рецептами, фишками и ощущениями от этой системы. (Факты и цифры, оставленные в этом абзаце и других местах текста без изменений следует воспринимать как актуальные по состоянию на 2019 год, когда был прочитан данный доклад. С тех пор многое изменилось, профессиональные интересы докладчиков, принявших в прошлом челленж Splunk, связаны в настоящее время с рядом других систем и сфер IT, подробности можно узнать в наших профилях или в личном диалоге.)

Я расскажу, как у нас устроен Splunk, а Аня поделится предельно конкретным кейсом по мониторингу нашей системы мониторинга, который она решила благодаря ее всепроникающей логике и изобретательности. Если конкретно — кейс будет про жизненный цикл данных внутри поискового индекса, как за этим можно смотреть, чем нас удивил мониторинг процессов и где в итоге мы нашли зацепку.

Думаю, что многие пошли в IT-сферу, исходя из кайфа, который испытываешь, когда напишешь офигенный код, построишь удачную архитектуру, и это всё здорово и эффективно работает. В дополнение вы покрываете свои системы тестами, и работа составляющих их звеньев становится абсолютно прозрачной и понятной.

Наша мотивация и цель сегодня такая же — поделиться ощущением от эксплуатации сложных систем. Тем удовольствием и кайфом, которые мы испытываем, когда такая система — с множеством степеней свободы, движущихся частей и параметров настройки — из неуправляемого хаотического нечто становится послушной, понятной и предсказуемой. Это очень приятное ощущение.

Часть 1. Мир Splunk

Итак, у нас есть разные системы мониторинга, которые покрывают различные нужды организации. Мы их эксплуатируем, а все остальные — используют. Чтобы мы с вами понимали друг друга, скажу, что мы делим мониторинг на две большие категории.

Во-первых, Splunk умеет собирать инфраструктурный мониторинг — это всё про железо, сбор метрик, низкоуровневые системные штуки, состояние сети и т.д. Но у нас и у наших коллег, в том числе русскоязычных, он чаще используется для бизнес-мониторинга — сбора состояния приложений, сервисов, сбора и фиксации каких-то аномалий.

По своей сути Splunk — это хранилище данных и средство разработки.

Splunk как хранилище данных

В Splunk могут поступать и храниться нужное нам время данные двух видов:

Логоподобные данные — это логи и всё, что похоже на них, то есть последовательность записей, параметризированных временем. Запись с временем, хранящуюся где-либо, мы называем логом, и логи можно отправлять в Splunk.
Справочники в общеизвестной терминологии (lookups в терминологии Splunk). В частности, в кластерах Splunk можно хранить файлы и коллекции в MongoDB.

Конкретно из этого списка мы существенно больше работаем с логоподобными данными. У нас есть и масса справочников, но логов — на несколько десятков порядков больше.

Splunk как средство разработки

У нас много задач именно по operations, но самая “конфетка” — это разработка вокруг Splunk. Во-первых, это приложения, работающие в контексте самого Splunk. А, во-вторых, это приложения, использующие REST API самого Splunk для интеграции с другими системами.

Приложения в контексте Splunk

Splunk как средство разработки предполагает, что в среде его инсталляции можно писать приложения, которые работают в контексте него самого на серверах (про них расскажу дальше). Приложения можно писать на чем угодно, в Splunk чего только нет.

Понятно, что поскольку это вебная штука, визуализация так или иначе упирается в JavaScript, но бэк разрабатываемых приложений внутри движка Splunk — дополнительные процессы и код — может быть написан на любом языке. Многие наши коллеги пишут на Python, также есть те, кто пишет на Java и Node.js — список можно продолжать. Можно даже бинарей накомпилить на Go или на С.

Приложения, работающие в контексте самого Splunk, в отличие от него самого, могут совершенно не быть проприетарными и распространяться под многими открытыми лицензиями. Есть открытый магазин (репозиторий) — официальное центральное приложение Splunk. В официальных репозиториях, помимо продуктов, заапрувленных компанией Splunk.com, есть множество приложений, которые разрабатывает сообщество. Эти приложения можно брать, ставить и модифицировать, поскольку большая часть из них — опенсорс, в отличие от самой системы.

REST API для интеграции

Этот API покрывает вообще все аспекты того, что есть в Splunk и он — прекрасное средство интеграции с чем угодно. Можно искать в тех самых логоподобных данных, можно брать что-то из справочников внутренней MongoDB. Можно как угодно фиксировать состояние самой системы, это огромное поле возможностей. Все это покрыто API.

Единственное, что этот API может быть непривычен в том плане, что сам ответ, который отдается эндпойнтами API — не всем уже привычный JSON, а XML. Но это особенный XML — это Atom feed. Наверное, многие знакомы с этим форматом. Вокруг этих эндпойнтов существует несколько официальных SDK, поддерживаемых самой компанией.

Мы любим Python и используем питоновскую SDK, но есть SDK на Java, Node.js, C#, и это только самые распространенные.

Язык SPL (Search Processing Language)

SPL связывает между собой приложения и REST API, это, если угодно, высокоуровневый протокол доступа к данным внутри Splunk. Я отсортировал фичи этого языка по вау-эффекту.

Вычисляемые на лету поля. Не знаю, имеется ли в опенсорс-решениях (Kibana, Graylog) какой-то функционал, чтобы прямо на лету в том логе, в котором ты ищешь через вебку или через API, взять и сформировать новые поля без прикручивания какого-то внешнего кода. В Splunk такое есть.

Conditions. В Splunk можно прямо в строке запроса, в отправляемом запросе через API или в создаваемых бордах и отчетах сразу реализовать программу, которая предполагает полноту по Тьюрингу.

Regex. Понятно, куда же без Regex? Опять же в том же Graylog, не знаю, можно ли сходу Regex применить или нет, в Splunk - можно.

Статистические функции. Все, что вы знаете о статистике, реализовано в поисковом ядре Splunk.

Relational operators. В ванильных Kibana или в Graylog, мы не сможем сджойнить таблицы на лету, а Splunk это умеет.

Transactions processing. В Splunk мы можем с целыми транзакциями в логе, раскрашенными одним и тем же айдишником, работать как с отдельной сущностью, определенным образом их объединять и т.д.

Predictions. Это вообще замечательно, дальше уже идет Machine Learning. Кстати, в Splunk есть множество расширений и с функционалом ML, таким образом мы можем предсказывать что-то.

UI. UI удобный, и мы знаем, что это так. Потому что у нас огромное количество пользователей приходит каждый день и начинает его шатать. Можно сделать алерты, отчёты и реалтайм-дашборды на том самом языке SPL, даже без необходимости писать расширения, которые я описал в самом начале.

Всё, что я рассказываю, звучит как реклама Splunk, но на самом деле всё это разнообразие может удовлетворить все или почти все потребности бизнеса в аналитике. Хотите изощрённейшую аналитику за последний месяц по определенной услуге с красивыми картинками, статистикой, несколькими срезами и визуализацией? И сджойнить это всё с этим и с тем? И алерты по всему? И прямо сейчас? Со Splunk это возможно.

Конечно, можно взять замечательные опенсорсные инструменты типа того же ELK-стека (я ничего не имею против!), посадить парочку питонистов, один из которых обладает умом аналитика, а другой — хороший исполнитель, и они за недельку-другую или за месяц через спринты или что-то еще поставят задачи, пообсуждают и сделают. Но бизнес хочет прямо сейчас.

Поскольку мы с Аней все-таки ops-инженеры то расскажу, что у нас в Splunk в плане инфраструктуры

Splunk как аппаратно-программный комплекс

Помимо его ядра и вспомогательных процессов, в Splunk крутится MongoDB. Splunk — это кластерная система. В нашем случае это даже не один кластер, а система кластеров. В инсталляции Splunk есть такие категории машин:

Индексаторы (indexer на локальном жаргоне). Это те машины, куда данные приходят, где они индексируются и откуда они потом запрашиваются.
Search heads — то, чем Splunk смотрит в пользователя. Это отдельные машины, которые общаются с индексерами, беря оттуда свежие данные. Естественно, есть масса возможностей для реалтайма, и все проиндексированное тут же отдается пользователю, если ему это надо.
Связка служебных машин. Я сильно отвлекусь, если буду рассказывать про каждую из ее категорий.
Источники данных.

Это красивая картинка с официальных ресурсов Splunk, но у нас он выглядит так же. Наверху — search heads, дальше — indexers и источники данных, а с двух сторон зарезервированы определенным образом служебные машины.

Кроме того, у нас есть система балансировщиков, которая стоит перед search heads, потому что балансировщиков может быть несколько. Там все сессии шарятся, есть резервирование и внутри search heads, и внутри indexers, есть реплики внутри дата-центров. В нашем случае это еще парочка дата-центров. Можно ставить вообще single-instance. По масштабированию есть масса возможностей, и они тоже гибкие.

Индексеры

На каждом индексере живет полтора десятка железных серверов с сотнями гигов RAM. Для красного словца можно сказать, что на каждом по 0,5 Тб, но на самом деле она не вся используется. Мы взяли RAM с запасом, хотя он не очень требователен к оперативной памяти, но у нас остаётся свобода специальной конфигурации машин, добавлению RAM-дисктов и подобных вещей.

Также каждый индексер имеет десятки ядер (Xeon), NVME/SSD для горячих и тёплых данных и 10+ терабайтных локальных RAID. Это просто RAID из обычных хардов на каждом из индексеров, где хранятся холодные данные. Резервирование реализовано податацентровое + реплики внутри ДЦ

Search heads

Здесь примерно то же самое, но без забористых хранилок и, конечно, количество чуть-чуть отличается. В нашем случае их можно иметь чуть-чуть поменьше — не полтора десятка, а, условно говоря, 8. Реальные цифры сейчас не важны, потому что у нас динамически время от времени меняется топология нашей системы. Хранилки на Search heads не нужны, потому что все хранится на индексерах. Search heads просто носят данные от индексера к потребителю.

Источники

С источниками в Splunk тоже шикарно — они могут быть разные. Правда, нельзя сказать, что вообще любой источник подходит. Я их отсортировал по использованию у нас (наверху — самый неиспользуемый, внизу — самый используемый):

DBconnect. Мы его почти не используем, но наши коллеги в последнее время всё чаще просят его настроить для разных баз. С помощью DBconnect можно ходить в реляционные БД и брать оттуда данные. Это родной инструмент, но можно внутренними средствами сделать и неродной, кастомный, который вообще в любую БД будет ходить.
Syslog. Есть практика, например, UDP рассыпалось: потом днем с огнем не сыщешь эти пакетики, но так всё равно можно.
HTTP Event Collector. Это API-эндпойнт, куда мы можем просто постить. Эта практика у нас набирает обороты, поэтому она в конце списка. Под HTTP Event Collector обычно выделяется отдельная пачка машин, которые общаются с индексерами и принимают посты, перед ними тоже есть балансировщики.
Universal Forwarders. Самый жирный источник. Чуть более 90% всех данных поступают у нас от агентов, а Universal Forwarders — это агент Splunk. Он ставится на машины с приложениями или с чем угодно, и данные оттуда оказываются в индексах.

Повторю, что это наша практика. Есть коллеги, которые в основном используют DBconnect, а есть бедняги, которые пытаются собирать Syslog. Знаю точно, что HTTP Event Collector — это модная молодежная штука, которую многие в других компаниях используют как основную.

И напоследок - немного цифр.

Терабайты данных суммарно в сутки. Это немного, так как Splunk умеет собирать петабайты, если его правильно приготовить. Терабайты — это живой каждодневный интерес в большой компании. Если вам нужно быстро и хитро проанализировать какие-нибудь логи в таком объеме, мы сможем.
Несколько тысяч источников — у нас тысячи Universal Forwarders.
Сотни активных пользователей, которых мы горячо любим. Они каждый день приходят, и это видно по графикам — в 10 часов (все любят в это время приходить) все открывают Splunk и давай сёрчить!
Сотни RPS (request per second) и десятки SPS (search per seconds). Но некоторые из с .
Хранение в среднем пару недель. Храним мы недолго, но можем больше — что-то хранится месяцами, а что-то — несколько дней. Ну и конечно у нас есть некоторый резерв по хранению, «на вырост».

И вот однажды со всем этим хозяйством что-то пошло не так. Здесь ваш покорный слуга —@Ostrie_Brevna— заканчивает свою часть статьи, и дальше будет рассказ Ани (@manabanana).

Часть 2. Make Business Monitoring Great Again

Индексы и жизненный цикл данных в них

Индексеры — это хранилища проиндексированных данных, а индексы — это то, что там уже есть. Физически индексы — это директории в файловой системе индексера.

Данные у нас чаще всего делятся по системам или департаментам, и поступают в специально созданные для департаментов различные группы индексеров. Из четырех типов хранилищ — Hot Path, Cold Path, Thawed Path и Frozen Path — мы используем только два, Hot Path и Cold Path. Если есть достаточно ресурсов, то, конечно, можно выбрать, что Hot Path мы храним на очень быстрых дисках (NVME, SSD), или можно просто разделить (по сути — шардировать) хранилища, если на одном сервере не хватает ресурсов.

Каждый индекс представлен на самом деле несколкими директориями, соответствующими вышеупомянутым состояниям (эти директории называются бакетами):

Hot — директория, доступная для записи и чтения.

2-3. Warm / Cold — только чтение, записывать уже нельзя.

Frozen.
Thawed.

Самое главное — переход из состояния в состояние только последовательный. Из Hot можно перейти сначала в Warm, и только после этого — в Cold:

Для перехода используются различные триггеры (срабатывающие при достижении заданных в конфиге параметров). Например, на схеме упомянут параметр maxDataSize — соответствующий триггер срабатывает, когда директория, в которую записываются проиндексированные данные, достигла максимального, указанного в этом параметре, размера. Далее рассматривается параметр maxHotBucket, если больше нет доступных для записи и подходящих по временному интервалу директорий; какой-то из более ранних бакетов закрывается, переходит в теплое состояние, и открывается новый Hot-бакет.

Можно задать время жизни индекса — maxHotIdleSec и maxHotSpanSecs, разница между временем создания и текущим (то есть, сколько бакет будет в горячем состоянии). Или это может быть разница между последним пришедшим событием и текущим временем. Если указанный временной интервал превышается, то индекс переходит в следующее состояние.

По сигналу Reload Splunk (если на индексере происходит reload процессов Splunk), все горячие бакеты перейдут в теплое состояние, чтобы не повредить данные записью.

Кроме того есть другие внутренние триггеры, которые срабатывают, когда значения различных параметров состояния приближаются к заданным в конфиге пороговым значениям. Рассмотрим такие «пороги».

Параметр homePath.maxDataSizeMB показывает, какой максимальный объём может иметь директория Home Path, — общая директория для всех индексов. Если директория Home Path заполнена, то чтобы что-то записать, нужно что-то освободить — а значит, что-то переносится в Cold. При превышении этого порога срабатывает один из важных для нас триггеров.

Параметр maxWarmDBCount задаёт максимально возможное количество тёплых бакетов. При превышении этого значения срабатывает другой важный триггер. В остальных бакетах похожие триггеры. В настройках Cold-бакетов, например, есть параметры coldPath.maxDataSizeMB и frozenTimePeriodInSecs, задающие время хранения проиндексированных данных.

Мониторинг процессов

У самого Splunk внутри действительно очень мощный мониторинг состояния самого себя. Вы можете проследить весь процесс от начала и до конца: когда данные пришли на сервер и как они проиндексировались. Но, как говорится, доверяй, но проверяй: тем более, было бы очень странно, если бы мы только на мониторинг самого Splunk ориентировались. Это как сделать бэкапы и сохранить их на том же хосте.

Так что к Splunk мы приделали также очень богатый функциональностью инфраструктурный мониторинг на базе Prometheus exporter и прикрутили к нему графану.

И это при том, что все машины у нас по историческим причинам ещё и мониторятся при помощи Zabbix. В общем, мы хотели получить больше системных метрик, чтобы определиться, какие лучше и удобнее. Такой набор помогает в ситуациях, когда что-то идет не так.

Для нас самое интересное в мониторинге — количество дескрипторов, Это и коннекты форвардеров к индексеру и открытые файлы индексных директорий (поскольку, как мы знаем, в UNIX всё — файл).

Prometheus process exporter собирает характеристики выполняющихся процессов splunkd, в него можно собрать около 24 метрик. Корневые процессы splunkd порождает множество других процессов — в основном это его помощники, хелперы, которые занимаются разными задачами. Если это индексер, то он складывает свои данные по-простому, как любят те, кто проектирует свою систему по методологии UNIX-way. Внутрянка не только читабельна для машины, но и понятна человеку. (Внутри бакетов множество заархивированных CSV-файлов.)

Но Splunk — это не та система, где вы один раз кластер подняли и больше его не трогаете, всё хорошо работает. При этом Splunk беспощаден — он не прощает ошибок, и это оказалось в нашей ситуации ключевым. В какой-то момент мы увидели множество разнообразных «горок» среди разных системных метрик, в частности в количествах открытых файловых дескрипторов. Я выбрала лучшие картинки из тех, которые нам удалось сохранить той зимой:

Мы наблюдали горки, которые медленно поднимались, а у пользователей это были медленные поиски

При этом в самой системе периодически, на каком-нибудь индексере, аварийно прерывался корневой процесс splunkd. Конечно, мы сделали скрипт-супервизор, автоматически поднимающий сервис Splunk, но это был уже костыль. Из-за того, что были задержки с приходом данных срабатывали ложные алерты, а злые пользователи (очень злые) каждый раз писали: «Что, Splunk умер?!»

Внутренний health check, который есть в Splunk, показал, что было создано очень большое количество маленьких бакетов:

Health check с индексера показывает, что с бакетами что-то не так

Но причиной мог быть как сбой, из-за чего и увеличился поток данных, так и «исторически сложившаяся ситуация». Вопрос — что было не так? Как так исторически сложилось?

Откуда росли горки

Исторически конфиги большинства индексов выглядели так:

Чтобы посчитать, сколько нужно места, есть простая формула. Домашняя директория — это сумма горячих и теплых бакетов, умноженная на максимальный размер бакета:

homePath.maxDataSizeMB = (maxWarmDBCount + maxHotBuckets) * maxDataSize
Выделяемое место под индекс, без учета homePath:
coldPath.maxDataSizeMB = maxTotalDataSizeMB - homePath

Видим, что maxDataSize — это размер одного бакета (по умолчанию auto_high_volume — это 10 Гб), а выделено ему 500 Мб. Понятно, что невозможно «сестрам Золушки влезть в ее туфельку» (c). Из-за этого и появляются неразрешенные процессы, которые могут висеть очень долго:

Что делать?

Мы выбрали не супер-математику, а, скорее, условности: как минимум, что сделать, чтобы был корректный конфиг, в котором все сходится, а переходы из одного состояния в другое были бы более контролируемыми. В итоге мы выбрали более упрощенный вариант — просто ориентируемся на место на диске.

Например, нужно очень-очень хорошо подумать, чтобы настроить все 5 параметров перехода из горячего в теплое:

С точки зрения времени жизни индексы как бы делаются бессмертными

Результат

Положительный результат у нас после всех расчетов все-таки получился:

После этой перенастройки мы больше не увидели злополучных «горок» на графиках системных метрик (графиках количества дескрипторов открытых файлах).

На то, чтобы получить результат — стабильную работу нашего Splunk — нам потребовалось немалое время. И во всём этом нам помогло то, что у нас были а) встроенный self-мониторинг самого Splunk; б) внешние системы мониторинга, такие как Zabbix и Prometheus и в) наш исследовательский подход к происходящему на хостах, подкрепляемый внимательным чтением обширно документации по Splunk и, главное, тщательным коллективным обдумыванием полученных системных метрик и знаниями функционирования Unix-подобный систем.

Конференция об автоматизации тестирования TestDriven Conf 2022 пройдёт в Москве, 28-29 апреля 2022 года. Кроме хардкора об автоматизации и разработке в тестировании, будут и вещи, полезные в обычной работе. Расписание уже готово, а купить билет можно здесь.

Мониторинг системы мониторинга, или Жизнь внутри индекса