split brain что это
После разделения правого и левого полушария у каждого полушария будет свое собственное восприятие, концепции и импульсы к действию. Наличие двух «мозгов» в одном теле может создать некоторые интересные дилеммы. Когда один пациент с расщепленным мозгом одевался, он иногда стягивал штаны одной рукой (эта часть его мозга хотела одеться) и опускалась другой (эта сторона этого не делала). Он также сообщил, что схватил жену левой рукой и сильно потряс ее, после чего его правая рука пришла ей на помощь и схватила агрессивную левую руку. Однако такие конфликты случаются очень редко. Если возникает конфликт, одно полушарие обычно преобладает над другим.
Тот же эффект наблюдается для визуальных пар и рассуждений. Например, пациенту с расщепленным мозгом показывают изображение куриной лапки и снежного поля в отдельных полях зрения и просят выбрать из списка слов, которые лучше всего ассоциируются с изображениями. Пациент выбрал бы курицу, чтобы ассоциировать ее с куриной лапкой, и лопату, чтобы ассоциировать ее со снегом; однако, когда его просят объяснить, почему пациент выбрал лопату, ответ будет относиться к цыпленку (например, «лопата предназначена для очистки курятника»).
СОДЕРЖАНИЕ
История
Визуальный тест
Первый тест начался с доски с горизонтальным рядом огней. Испытуемому было предложено сесть перед доской и смотреть в точку в центре света, после чего лампочки мигали как в правом, так и в левом поле зрения. Когда пациентов попросили потом описать то, что они видели, они сказали, что загорелись только огни с правой стороны доски. Затем, когда Сперри и Газзанига мигали огнями с правой стороны доски на испытуемых с левой стороны их поля зрения, они утверждали, что вообще не видели никаких огней. Когда экспериментаторы снова провели тест, они попросили испытуемых указать на загорающиеся огни. Хотя испытуемые только сообщили, что видели мигающие огни справа, на самом деле они указали на все огни в обоих полях зрения. Это показало, что оба полушария мозга видели свет и были одинаково компетентны в визуальном восприятии. Испытуемые не говорили, что видели огни, когда они вспыхивали в левом поле зрения, хотя они видели их, потому что центр речи расположен в левом полушарии мозга. Этот тест поддерживает идею о том, что для того, чтобы сказать, что кто-то что-то видел, область мозга, связанная с речью, должна иметь возможность общаться с областями мозга, которые обрабатывают визуальную информацию.
Тактильный тест
Во втором эксперименте Сперри и Газзанига поместили небольшой предмет в правую или левую руку испытуемого, не имея возможности его видеть (или слышать). Помещенное в правую руку, изолированное левое полушарие воспринимало объект и могло легко описать и назвать его. Однако изолированное правое полушарие, помещенное в левую руку, не могло назвать или описать объект. Ставя под сомнение этот результат, исследователи обнаружили, что впоследствии испытуемые могли сопоставить его с несколькими похожими объектами; тактильные ощущения, ограниченные правым полушарием, точно воспринимались, но не могли быть вербализованы. Это дополнительно продемонстрировало очевидное расположение (или латерализацию) языковых функций в левом полушарии.
Комбинация обоих тестов
В последнем тесте экспериментаторы объединили тактильный и визуальный тест. Они представляли испытуемым изображение объекта только их правому полушарию, и испытуемые не могли назвать или описать его. Никаких словесных откликов на картинку не было. Однако, если испытуемый мог дотянуться до экрана левой рукой, чтобы прикоснуться к различным объектам, он мог выбрать тот, который был показан на картинке. Сообщалось также, что испытуемые могли выбирать объекты, связанные с представленной картинкой, если этот объект не находился под экраном.
Сперри и Газзанига продолжили проводить другие тесты, чтобы пролить свет на способность правого полушария к обработке речи, а также на слуховые и эмоциональные реакции. Значение результатов этих тестов, проведенных Сперри и Газзанигой, было чрезвычайно важным и важным для мира психологии. Их выводы показали, что две половины мозга обладают многочисленными функциями и специализированными навыками. Они пришли к выводу, что у каждого полушария действительно есть свои функции. Считается, что левое полушарие мозга лучше умеет писать, говорить, математические вычисления, читать и является основной областью для речи. Считается, что правое полушарие обладает способностями к решению проблем, распознаванию лиц, символическому мышлению, искусству и пространственным отношениям.
Полушарная специализация
Роль мозолистого тела
Исследования влияния на зрительный путь у пациентов с разделенным мозгом показали, что существует выигрыш от избыточности (способность обнаружения цели извлекать выгоду из нескольких копий цели) в простом времени реакции. При простой реакции на визуальные стимулы пациенты с разделенным мозгом испытывают более быстрое время реакции на двусторонние стимулы, чем предсказывает модель. Модель, предложенная Iacoboni et al. предполагает, что пациенты с разделенным мозгом испытывают асинхронную активность, которая вызывает более сильный сигнал и, следовательно, меньшее время реакции. Якобони также предполагает, что у пациентов с разделенным мозгом существует двойное внимание, что подразумевает, что каждое полушарие головного мозга имеет свою собственную систему внимания. Альтернативный подход, принятый Reuter-Lorenz et al. предполагает, что усиление избыточности в расщепленном мозге в первую очередь связано с замедлением реакции на односторонние стимулы, а не с ускорением ответов на двусторонние. Важно отметить, что время простой реакции у пациентов с разделенным мозгом, даже с усилением избыточности, медленнее, чем время реакции у нормальных взрослых.
Функциональная пластичность
Мозолистое тело
Благодаря функциональному картированию мозолистого тела частичная каллозотомия имеет меньшие пагубные последствия, поскольку при этом части мозолистого тела остаются нетронутыми. При частичной и полной каллозотомии у взрослых наблюдается небольшая функциональная пластичность, наибольшая нейропластичность наблюдается у маленьких детей, но не у младенцев.
Известно, что когда мозолистое тело разрывается во время экспериментальной процедуры, экспериментатор может задать каждой стороне мозга один и тот же вопрос и получить два разных ответа. Когда экспериментатор спрашивает правое поле зрения / левое полушарие, что они видят, участник ответит устно, тогда как если экспериментатор спросит левое поле зрения / правое полушарие, что они видят, участник не сможет ответить устно, но подберет соответствующий ответ. объект левой рукой.
объем памяти
Известно, что правое и левое полушарие выполняют разные функции, когда дело касается памяти. Правое полушарие лучше распознает предметы и лица, вспоминая уже полученные знания или вспоминая уже увиденные изображения. Левое полушарие лучше в умственных манипуляциях, производстве речи и семантическом праймировании, но было более восприимчивым к спутанности памяти, чем правое полушарие. Основная проблема для людей, перенесших каллозотомию, заключается в том, что, поскольку функция памяти разделена на две основные системы, человек с большей вероятностью запутается между знаниями, которые он уже знает, и информацией, которую он только предположил.
В тестах память в любом полушарии пациентов с разделенным мозгом обычно ниже нормы, хотя и лучше, чем у пациентов с амнезией, что позволяет предположить, что комиссур переднего мозга важны для формирования некоторых видов памяти. Это говорит о том, что задние мозолистые участки, включающие спайки гиппокампа, вызывают умеренный дефицит памяти (в стандартизированном тестировании свободного поля), связанный с распознаванием.
Контроль
В целом пациенты с раздвоенным мозгом ведут себя скоординированно, целенаправленно и последовательно, несмотря на независимую, параллельную, обычно разную и иногда конфликтующую обработку одной и той же информации из окружающей среды двумя несвязанными полушариями. Когда два полушария получают конкурирующие стимулы одновременно, режим ответа имеет тенденцию определять, какое полушарие контролирует поведение.
Часто пациенты с раздвоенным мозгом неотличимы от нормальных взрослых. Это связано с компенсаторными явлениями; Пациенты с расщепленным мозгом постепенно осваивают различные стратегии, позволяющие обойти дефицит межполушарного переноса. Одна проблема, которая может произойти с их контролем над телом, заключается в том, что одна сторона тела выполняет противоположную сторону другой стороны, что называется межручным эффектом.
Внимание
Тематические исследования пациентов с расщепленным мозгом
Пациент WJ
Пациент JW
Funnell et al. (2007) протестировали пациента JW незадолго до июня 2006 г. Они описали JW как
мужчина-правша, которому на момент тестирования было 47 лет. Он успешно окончил среднюю школу и не сообщал о проблемах с обучением. Первый приступ случился в 16 лет, в 25 лет, перенес двухэтапную резекцию мозолистого тела для купирования трудноизлечимой эпилепсии. Полное рассечение мозолистого тела подтверждено МРТ. Послеоперационная МРТ также не выявила признаков других неврологических повреждений.
Turk et al. (2002) проверили межполушарные различия в узнавании JW себя и знакомых лиц. Они использовали лица, которые были составными частями лица JW и лица доктора Майкла Газзаниги. Композитные материалы варьируются от 100% JW, через 50% JW и 50% Gazzaniga до 100% Gazzaniga. JW нажимал клавиши, чтобы сказать, похоже ли представленное лицо на него или на Газзанигу. Тюрк и др. Пришли к выводу, что в левом полушарии есть корковые сети, которые играют важную роль в самопознании.
Пациент В.П.
В одном из экспериментов с участием ВП была предпринята попытка систематического исследования типов зрительной информации, которая могла передаваться через сохраненные ВП волокна селезенки. Первый эксперимент был разработан для оценки способности VP делать межполевые перцепционные суждения об одновременно предъявляемых парах стимулов. Стимулы предъявлялись в различных положениях относительно горизонтальной и вертикальной средней линии, при этом зрение VP фиксировалось на центральном перекрестии. Суждения основывались на различиях в цвете, форме или размере. Процедура тестирования была одинаковой для всех трех типов стимулов; после представления каждой пары VP устно ответил «да», если два элемента в паре были идентичны, и «нет», если они не были идентичными. Результаты показывают, что не было перцептивного переноса цвета, размера или формы с биномиальными тестами, показывающими, что точность VP не превышает случайности.
Во втором эксперименте с участием В.П. была предпринята попытка выяснить, какие аспекты слов передаются между двумя полушариями. Установка была аналогична предыдущему эксперименту, при этом видение В.П. фиксировалось на центральном перекрестии. Пара слов была представлена по одному слову с каждой стороны перекрестия в течение 150 мс. Представленные слова относились к одной из четырех категорий: слова, которые выглядели и звучали как рифмы (например, шина и огонь), слова, которые выглядели так, как будто они должны были рифмоваться, но не рифмовались (например, кашель и тесто), слова, которые не выглядели так, как будто они должен рифмовать, но делал (например, запекать и болеть), и слова, которые не выглядели и не звучали как рифмы (например, ключи и форт). После представления каждой пары слов VP ответил «да», если два слова рифмуются, и «нет», если нет. Показатели VP были выше случайностей, и она смогла различить различные условия. Когда пары слов не звучали как рифмы, VP смогла точно сказать, что слова не рифмуются, независимо от того, выглядят ли они так, как будто они должны рифмовать. Когда слова рифмуются, VP с большей вероятностью скажет, что они рифмуются, особенно если слова также выглядели так, как будто они должны были рифмоваться.
Ким Пик
Хотя Пику не делали мозолистое тело, он считается естественным пациентом с расщепленным мозгом и имеет решающее значение для понимания важности мозолистого тела. Ким Пик умерла в 2009 году.
«Защита от split-brain при создании 2-х нодового кластера PostgreSQL» — Видеозапись доклада
В ноябре 2017 года состоялась конференция о системах, платформах и инструментах — « Linux Piter». С докладами выступили эксперты из США, Германии, Австрии, Швеции, Финляндии и конечно же из России. Компанию Postgres Professional представил старший администратор баз данных Игорь Косенков. Игорь выступил с докладом «Защита от split-brain при создании 2-х нодового кластера PostgreSQL».
Сегодня видеозаписи всех докладов уже доступны на сайте конференции «Linux Piter». А мы делимся здесь видеозаписью доклада Игоря Косенкова на русском языке и с английским переводом.
Русская версия:
Английская версия:
О докладе:
Split-brain является главным недостатком на пути использования двух-узлового кластера PostgreSQL. Многие известные механизмы защиты от split-brain не всегда могут быть применимы. В докладе Игорь Косенков расскажет об известных механизмах, и предложит свой механизм защиты от split-brain. Также вы узнаете о практическом использовании двух-узлового кластера в современных кластерах.
О докладчике:
Игорь Косенков старший администратор баз данных в компании Постгресс Профессиональный. Участвовал в разработке отечественной операционной системы военного назначения на базе Linux — ОС МСВС. Является специалистом в области построения отказоустойчивых решений для СУБД PostgreSQL.
Разъяснение по CAP-теореме
Условности
Для начала, договоримся об уровне абстракций.
В рамках теоремы бессмысленно заявлять, что в «реальном мире» не может быть гарантированной связи между узлами распределенной системы. С тем же успехом можно сказать, что такое свойство как «availability» недостижимо в принципе, поскольку любая система перестанет быть доступной при отказе достаточного числа узлов (например, при отказе всех ее узлов).
Поэтому давайте условимся, что речь идет все-таки о модели и в ней сделаны некоторые допущения.
Мы будем считать, что вероятность отказа критического числа узлов системы пренебрежимо мала — это даст нам возможность говорить, что гарантировать availability все-таки можно.
Мы не будем рассматривать устройство узлов и характер связи между ними — для теоремы это неважно.
Технически, мы можем создать систему, в которой вероятность потери связи между узлами будет еще меньше, чем вероятность отказа критического числа узлов (которую мы считаем пренебрежимо малой). Благодаря этому мы можем говорить, что распределенная система с гарантированной связью между узлами (невозможностью partitioning’а) — возможна.
Как конкретно этого добиться — неважно. Возможно, понадобится миллионократное дублирование систем связи или изобретение сверхнадежного гравитонного передатчика, который на тучу порядков устойчивей к любым воздействиям, чем наши грубые кремниевые поделки. Факт, что это можно сделать, если кому-то правда приспичит. Делают же компьютеры, в которых 4 процессора считают одно и то же только чтобы перепроверить друг друга. С той же тщательностью можно подойти к гарантиям обеспечения связи.
Смерть милее
Важно понимать, что смерть узла системы и потеря с ним связи не эквивалентны.
Разница проста — умерший узел не может совершать действий, которые «по неведению» окажутся деструктивными по отношению к остальной системе. Всегда можно устроить так, чтобы он умирал навсегда, или приходя в себя первым делом консультировался с остальной системой, чтобы ненароком ничего не сломать.
При разрыве связи все печальнее. Узел не может позволить себе умереть, потому что возможно только он и обеспечивает работоспособность (без связи с другими узлами невозможно понять, есть ли еще кто-то живой). Не может он и синхронизировать свою работу с остальными — связи-то нет. Остается действовать вслепую, на свой страх и риск.
Рассмотрим происходящее на конкретном примере
Допустим, в нашей системе ровно 2 совершенно одинаковых узла — A и B. Каждый из них хранит копию данных второго и может независимо обрабатывать запросы извне. Каждый, обрабатывая запрос, уведомляет второго об изменениях, чтобы данные оставались согласованы.
Вариант 1: узел A умирает.
Система продолжает работать как ни в чем не бывало — B продолжает обрабатывать запросы. Когда A приведут в чувство, он первым делом синхронизируется с B и они вдвоем продолжат работать дальше. Ни доступность, ни согласованность не страдают.
Вариант 2: A и B живы, но связь между ними прервана.
При этом каждый из них продолжает принимать запросы извне, но не может уведомить второго об изменениях. Для каждого узла все выглядит так, будто второй узел умер и он действует в одиночку. Эту ситуацию часто называют «split-brain» — мозг разделился на два полушария, каждое из которых считает себя единственным хозяином ситуации. Система заболела шизофренией.
Если в этот момент на A был обработан запрос на удаление некой записи R, а на B был обработан запрос на модификацию той же самой записи, то данные стали несогласованы. Когда связь между A и B восстановится, при синхронизации всплывет конфликт — удалить R или оставить модифицированную версию? Тут можно выкручиваться разными стратегиями разрешения конфликтов, но consistency мы уже потеряли.
Альтернативный способ решения проблемы — A и B, видя, что потеряли связь друг с другом, перестают обрабатывать запросы. В этом случае согласованность не нарушится, но будет потеряна availability.
Ближе к реальности
Конечно, системы ровно из двух узлов встречаются нечасто. Но то же самое верно, если считать что A и B не два отдельных узла, а два набора узлов. При этом считаем, что общение между двумя любыми узлами в пределах A и в пределах B осталось возможным, но узлы из A не могут взаимодействовать с узлами из B. При этом оба набора продолжают получать и обрабатывать запросы извне.
По сути это описание типичной ситуации, когда прервалась связь между двумя датацентрами. Split-brain надежно обеспечивает системе шизофрению даже в таком простом случае. Если же сплитов несколько или в разных группах оказались доступны неполные наборы данных, все может оказаться еще хуже.
Возвращаясь к теореме
Теорема гласит, что CA достигается только потерей устойчивости к нарушению связи между узлами. На практике это означает, что CA-системы правильно использовать в случаях, когда мы считаем вероятность потери связи пренебрежимо малой.
Какими путями мы этого добиваемся — теореме пофиг. Не нужно призывать «реальный мир», чтобы показать, что чуваки чего-то не догоняли. Теорема существует в рамках модели. Как она верна сейчас, также она будет верна и послезавтра, когда наконец изобретут гравитонный передатчик.
Но даже без гравитонного передатчика не так все плохо. Потеря связи между датацентрами — явление не столь частое. В пределах одного датацентра — еще реже. Да, если сплит возникнет, придется решать конфликты. Возможно даже руками, хотя огромное число задач позволяет разрешить многие конфликты автоматически. Но, возможно, прелести CA-системы привлекут нас гораздо больше, чем отпугнет необходимость чинить что-то руками в случае маловероятного сплита. В этом случае мы с чистым сердцем будем считать вероятность возникновения проблем пренебрежимо малой, даже не опираясь на супертехнологии будущего.
Ну а если в своем проекте вы считаете вероятность сплита достаточно высокой, можно переформулировать теорему таким образом: при возниконовении сплита остается только выбирать — A или C.
Лирическое отступление
Существуют приемы, позволяющие смягчить CAP-теорему в разных частных случаях. Человеку не обязательно нужна система, работающая идеально. Часто хватает того, чтобы она работала достаточно хорошо, хотя бы в большинстве случаев.
Эти приемы включают как попытки автоматического восстановления целостности, после того как страшное случилось, так и попытки недопустить потери целостности, при этом не скатываясь в полный отказ от доступности.
Простейший пример: каждый узел автоматически прекращает обрабатывать запросы извне, если видит меньше чем половину остальных узлов. Это гарантирует, что если система разделится на две неравные части, то одна из них продолжит работу, а другая автоматически совершит харакири, чтобы не наделать глупостей.
Другое дело, что оставшись с половиной мощности, система скорее всего целиком ляжет под нагрузкой. Но можно применить еще одну хитрость — узлы, оставшиеся в изоляции, могут продолжить работать на чтение, не создавая конфликтов. Для систем с интенсивным чтением вполне оправданный ход. Правда, отдаваемые данные не всегда будут актуальны, но часто это лучше чем ничего. Однако при разделении на несколько частей, уже ни одна из них не сможет обрабатывать запросы на запись. Хотя можно придумать что-нибудь и похитрее…
Как ни изворачивайся, в целом CAP-теорему не обойти. Но в большинстве проектов есть огромные просторы для поисков способа выкрутиться, сводя вероятность проблемных сценариев к минимуму.
PS javaspecialist, спасибо за повод для написания этой статьи.
Мониторинг Elasticsearch через боль и страдания
Мы наконец допинали функционал мониторинга elasticsearch до публичного релиза. Суммарно мы переделывали его три раза, так как результат нас не устраивал и не показывал проблемы, которые мы огребали на нашем кластере ES.
Под катом история про наш production кластер, наши проблемы и наш новый мониторинг ES.
Супер краткий курс по эластику
Elasticsearch — это распределенный само-масштабирующийся RESTful сервис полнотекстового поиска, построенный на базе библиотеки Apache Lucene.
Внутри каждый шард — это индекс, но уже в Lucene’овских терминах, и он делится на сегменты.
Как мы используем ES
У всех метрик в okmeter.io есть метки, проще говоря, идентификатором метрики в нашей системе является словарь ключ-значение, например:
Каждый такой словарь-идентификатор метрики — это документ в ES. Например, чтобы построить такой график
мы ищем в ES по такому (очень упрощенно) запросу
он возвращает сколько-то id метрик, по которым мы достаем значения метрик из кассандры.
Статус кластера
Сам ES считает, что кластер может находиться в трех состояниях:
Основной график нашего стандартного дашборда по ES мы выбирали исходя из этих же состояний:
Расскажу про этот день. Накануне мы добавили более мощные серверы в кластер, а теперь нужно было убрать две старые ноды. Приблизительно в 14:00 мне пришла в голову идея, а не провести ли учения? Обсудили и решили, что можно поэкспериментировать — выключить одну ноду и посмотреть, как такой эластичный эластик это отработает.
Выключили, и тут же заорал мониторинг, что на коллекторе метрик проблемы. Why??
Вернули ноду, подождали немного, всё наладилось. Странно, ну не может же быть такого, чтобы из-за выключения одного из нескольких эластиков мы прилегли. Наверное, что-то другое.
Выключили ноду опять где-то в 14:30 — опять алерты. Хмммм. Учения показали, что падение одного эластика делает нам больно — тоже результат, но нужно разбираться.
Сделали своего рода decommission — аккуратно вывели ноды по одной из кластера. Синее на графике в 15:10 — это оно, шарды перемещались на другие ноды. Обошлось без проблем.
Присмотрелись к количеству шардов: 140 — странно, number_of_shards у нас 20, number_of_replicas — 2, и еще одна мастер копия, т.е. должно быть 60 шардов на индекс. Индексов 3 — свой на каждый месяц, значит должно быть всего 180 шардов. Оказалось, что декабрьский индекс создался с number_of_replicas — 0, т.е. без реплик, поэтому выключение любой ноды полностью ломает работу с этим индексом!
Хорошо, что отсутствие реплик обнаружилось в контролируемом эксперименте. Если бы мы это не заметили, могли огрести большие проблемы в будущем — пришлось бы аврально делать полную переиндексацию по данным из основного хранилища.
Чтобы увидеть эту проблему в будущем, мы сделали автоматический триггер, который сообщит, если в каком-то индексе 0 реплик. Этот триггер выпустили в виде авто-триггера для всех клиентов сразу, мы же сервис мониторинга 🙂
Split brain
Самая пугающая и известная проблема с эластиком — это split brain, когда из-за проблем со связностью нод по сети, или если нода не отвечала долго (потому что застряла в GC например), в кластере может появиться вторая мастер-нода.
В этом случае получается как бы две версии индекса, какие-то документы попадают на индексацию в одну часть кластера, другие — в другую. Неконсистентность будет проявляться при поиске — на один и тот же запрос будут выдаваться разные результаты. Восстановление индекса в таком случае будет сложной задачей, скорее всего, потребуется либо полная переиндексация, либо восстановление из бэкапа и с последующей доливкой изменений до текущего момента.
В ES есть механизм защиты от сплит-брейна, самая важная настройка — minimum_master_nodes, но по-умолчанию discovery.zen.minimum_master_nodes: 1, т.е. никакой защиты нет.
Мы воспроизводили это на тестовом кластере ElasticSearch и по результатам сделали два авто-триггера: один сработает, если увидит более одной мастер ноды в кластере, второй предупредит, если значение параметра discovery.zen.minimum_master_nodes меньше, чем рекомендованное — кворум (N/2+1) от текущего размера кластера. Это нужно именно мониторить, потому что вы можете решить добавить нод и забыть подправить minimum_master_nodes.
Мониторинг запросов в elastic
C состоянием кластера вроде разобрались, дальше нужно понимать, сколько каких запросов обрабатывает кластер и как быстро они отрабатывают.
Любой поиск по нашему ES мы делаем сразу по трем индексам, каждый из которых поделен на 20 шардов. Из-за этого изначальные
250 запросов в секунду на поиск от нашего кода для ES превращаются в
Запросов на идексацию на самом деле у нас около 200 в секунду, но так как каждый шард хранится в трех копиях (основная + 2 реплики), то ES видит
По временам запросов ES дает достаточно скудную статистику: есть счетчик обработанных запросов и есть кумулятивная сумма времен запросов по типам. Таким образом, мы можем посчитать только среднее время ответа по каждому типу запросов, получаем график такого вида (мы вычисляем среднее прямо при отрисовке графика, так как сумма времен ответов тоже интересная метрика сама по себе):
Оранжевая линия — это поиск. Видно, что в какой-то момент он ускорился приблизительно в 3 раза.
Это мы всего лишь сделали force merge сегментов. У нас индекс порезан помесячно. Индексируется всегда (почти) в текущий месяц, ищется по трём. Так как из индексов за предыдущие месяцы идет только чтение, мы можем сделать на них force merge сегментов прямо под нагрузкой:
В итоге осталось по одному сегменту в каждом шарде, поиск по этим индексам стал заметно быстрее. Возможно, нам стоит сделать крон, который будет делать force merge индекса за прошедший месяц.
Background ops графики
Кроме того, мы отдельно вывели «background» операции — это то, что эластик делает в фоне сам или по запросу как с force merge. Отдельно, потому что логичнее видеть «пользовательские» запросы отдельно от «системных»: у них и совсем разные тайминги — секунды вместо милисекунд, поэтому на одном графике будет неудобно смотреть. И количество таких операций бывает очень маленьким и может теряться на фоне всех пользовательских реквестов.
Этот график показывает тот самый merge, который снизил нам время ответа поиска, но в этот раз удобнее смотреть на сумму времен ответа ES (мы как бы смотрим, на что в целом тратились вычислительные ресурсы кластера):
С точки зрения системных метрик линукса, этот merge выглядел как активная запись на диск процессом ES:
Для обеспечения скорости выполнения запросов в эластике есть кэши:
Подробнее что кешируется, когда кешируется, когда инвалидируется, как тюнить, лучше читать в документации.
Наш мониторинговый агент снимет для каждого из этих кэшей: размер, хиты, миссы, эвикшены (вытестения).
Вот, например, был случай — эластики у нас упали по OutOfMemory. По логам разобраться сложно, но потом, когда уже подняли, заметили на графике резкий рост использования памяти fielddata кэшем:
Вообще-то мы не используем агрегации elasticsearch, мы вообще используем только самый базовый функционал. Нам нужно без скоринга найти все документы, в которых у заданных полей заданные значения. Почему же так выросло использование fielddata кэша?
Оказалось, что это был тоже контролируемый эксперимент 🙂 Вручную curl’ом дёргали тяжелые запросы на агрегацию, и от этого всё попадало. По идее от этого можно было защититься правильной настройкой лимитов памяти для fielddata. Но или они не сработали, или баги эластика (мы тогда сидели на старой версии 1.7).
Системные метрики
В дополнении к внутренним метрикам эластика, стоит смотреть на него сверху, как на процесс в операционной системе. Сколько он потребляет процессорного времени, сколько памяти, сколько создает нагрузки на диск.
Когда мы затевали обновление ES с версии 1.7.5, то решили обновиться сразу на 2.4 (последнюю, пятёрку, пока побаиваемся). Мажорное обновление elastic по стандартной процедуре нам делать как-то стрёмно, мы обычно поднимаем второй кластер и делаем синхронную копию через наш код — он умеет индексировать в несколько кластеров сразу.
При включении нового кластера в индексацию, обнаружилось, что новый ES пишет на диск
350 раз в секунду, в то время как старый всего
es101 — это нода из старого кластера, а es106 — из нового. Плюс на новые ноды не стали ставить SSD (посчитали, что всё влезет в память), поэтому такое io уронило производительность очень сильно.
Пошли перечитывать все новинки версии 2 эластика и нашли index.translog.durability. Он по умолчанию стал request, при таком значении translog синкается на диск после каждого запроса на индексацию. Поменяли на async со стандартныйм sync_interval в 5 секунд и стало почти как раньше.
Помимо системных метрик для ES полезно смотреть за метриками JVM — gc, memory пулы и прочее. Наш агент автоматически подцепит всё это через jmx, и так же автоматически появятся графики.
Автоматическое обнаружение ES
Не так давно мы уже рассказывали, что очень много сил тратим на то, чтобы все сервисы на серверах наших клиентов включались в мониторинг автоматом, без настройки. Такой подход позволяет ничего не забыть замониторить и сильно ускоряет внедрение.
Автодетект для ES устроен примерно так:
Дальше дело техники — периодически снимаем метрики по стандартному API и отправляем их в облако.
Вместо заключения
Мы всегда стараемся исходить из реальных use case’ов. Чтобы запилить мониторинг какого-то сервиса, нам приходится досконально с ним разбираться, понимать, что и как там может сломаться. Поэтому в первую очередь мы делали поддержку тех сервисов, которые хорошо умеем готовить и которыми пользуемся сами.
Кроме того, очень помогают клиенты, которые рассказывают про свои проблемы. Мы постоянно дорабатываем дашборды/автотриггеры, чтобы в итоге показывать не какие-то графики, а сразу причины проблем.
Если у вас есть ES, который ждет, чтобы его замониторили, наш бесплатный 2х недельный триал — то, что вам нужно, ссылка на сайт чуть ниже 🙂