Как я контролирую шарды, диск и доступность поиска Elasticsearch/OpenSearch в Zabbix

Почему зелёного endpoint недостаточно

В наших внедрениях я начинаю не с одного ping до порта, а с вопроса, какой пользовательский результат мы защищаем. Elasticsearch или OpenSearch способен отвечать на корневой URL, пока часть индексов уже потеряла primary shard либо поиск возвращает частичный ответ. Обратная ситуация тоже важна: yellow не равен полной остановке, потому что primary назначены, а неназначенными остаются реплики. Поэтому на одной шкале я держу три разных слоя: достижимость REST API, распределение шардов и выполнение согласованного поискового запроса. Сначала фиксирую обычный профиль кластера и перечень критичных алиасов без раскрытия документов. Затем проверяю свежесть данных в Zabbix, чтобы старое зелёное значение не выглядело текущим. Такая декомпозиция не позволяет удобному индикатору подменить доступность сервиса и сразу показывает, где искать: в канале мониторинга, cluster state или поисковом пути приложения.

Как читаю cluster health без ложных выводов

Из GET /_cluster/health я забираю status, timed_out, number_of_nodes, number_of_data_nodes, active_primary_shards, relocating_shards, initializing_shards, unassigned_shards, delayed_unassigned_shards, number_of_pending_tasks и максимальное ожидание задачи. Green означает, что назначены primary и реплики; yellow — что все primary доступны, но часть реплик не назначена; red — что не назначен хотя бы один primary. Я применяю устойчивость условия и зависимости триггеров: короткая инициализация после согласованной операции не должна создавать каскад одинаковых аварий. Одновременно red требует привязки к затронутым индексам, а не вывода, будто исчезли все данные. Поле timed_out рассматриваю отдельно от цвета: ожидание заданного состояния могло истечь, хотя API вернул JSON. Изменение числа data nodes и длительные pending tasks дополняют картину, но не называются причиной до проверки allocation и журналов.

От счётчика unassigned к конкретному решению

Когда unassigned_shards больше обычного, я не начинаю с reroute. Read-only запрос _cat/shards с полями index, shard, prirep, state, node и unassigned.reason отделяет primary от replica и показывает область воздействия. Для одного характерного неназначенного шарда вызываю POST /_cluster/allocation/explain без команд изменения и сохраняю can_allocate, unassigned_info, allocate_explanation и решения deciders. Причиной может оказаться ушедший узел, задержанное назначение, фильтр allocation, awareness, ограничение числа шардов, несовместимость или отсутствие подходящей копии. Эти варианты требуют разных владельцев и разных действий. Я маскирую имена, если они раскрывают назначение данных, и не выгружаю содержимое индекса. В Zabbix оставляю агрегат для тревоги, а подробное объяснение получаю по событию: частый тяжёлый explain не нужен. Дополнительно сверяю, не совпало ли появление хвоста с созданием индекса, изменением replica count, перезапуском узла или восстановлением snapshot. Отметка такой операции на временной шкале помогает отличить ожидаемую переходную фазу от состояния, которое перестало сходиться самостоятельно. Восстановление подтверждаю переходом нужного шарда, отсутствием нового хвоста и успешным поисковым тестом.

Disk watermarks как цепочка, а не один порог

Диск я связываю с решениями allocator. Low watermark ограничивает новое размещение на заполненном узле, high заставляет кластер пытаться переносить шарды, а flood stage служит последней защитой и может установить index.blocks.read_only_allow_delete для индексов с шардами на таком диске. Проценты и абсолютные значения имеют разную семантику свободного места, поэтому я читаю фактически применённые cluster settings с defaults и храню единицы рядом с метрикой. Проверяю каждый data node: если все подходящие узлы уже выше low, переносу может быть просто некуда. Рост свободного места ниже high снимает дисковую причину и в актуальных реализациях освобождает защитный блок, но я всё равно подтверждаю состояние индекса. Не предлагаю отключать disk threshold или механически поднимать watermark: это откладывает реакцию, не создавая ёмкость. Прогноз строю по скорости расхода и плановым операциям, а пороги уведомления задаю с учётом размера диска и времени реакции.

Отдельный контроль доступности поиска

Для пользовательского слоя я выбираю с владельцем приложения стабильный алиас и дешёвый запрос, который не читает чувствительные поля. Проверка ограничивает size, задаёт timeout, не использует широкий wildcard и проверяет HTTP-код, timed_out, took, _shards.failed и заранее допустимый признак ответа. Если нужен строгий сигнал полноты, явно отключаю partial results там, где это поддержано и согласовано; иначе успешный код может соседствовать с отказом части шардов. Я не требую постоянного числа hits от изменяемых данных. Лучше искать технический маркер в выделенном контрольном документе либо проверять структуру ответа, если жизненный цикл маркера надёжно управляется. В Zabbix ошибка соединения, 401/403, некорректный JSON, тайм-аут запроса и отрицательный прикладной результат получают разные значения. Так дежурный видит, сломан ли доступ мониторинга, сам поиск или только резервирование, и не принимает latency одного запроса за итоговый анализ производительности.

Безопасный сбор через Zabbix

Я применяю HTTP agent master items для разрешённых JSON-ответов и dependent items с JSONPath для отдельных чисел и состояний. Это уменьшает число обращений и сохраняет общий timestamp среза. Учётная запись получает только cluster monitor и чтение согласованных индексов в минимальном объёме; права на settings update, reroute, удаление, закрытие и запись отсутствуют. Секрет хранится в защищённом макросе или внешнем хранилище, не попадает в URL, item key, историю и диагностический экспорт. TLS-проверка сертификата и имени остаётся включённой. Я ограничиваю тело ответа через filter_path, настраиваю разумный timeout и отдельно контролирую unsupported item и nodata. Ноды не опрашиваю все одним и тем же тяжёлым запросом без необходимости: cluster API даёт общий срез, node stats — только нужные дисковые поля. Перед вводом сравниваю один ответ Zabbix с разрешённым ручным чтением и проверяю preprocessing на обезличенном образце.

Контролируемая проверка цепочки сигналов

Controlled check я провожу в изолированном тестовом индексе или согласованном нерабочем контуре. Сначала сохраняю шаблон, macros, действующие настройки allocation и исходные графики. Без заполнения диска создаю безопасно управляемую ситуацию с неназначенной replica: например, задаю тестовому индексу число реплик, которое контур заведомо не может разместить. Ожидаю yellow, рост unassigned, понятное решение Allocation Explain и при этом успешный поиск по primary. Затем возвращаю исходное число реплик и подтверждаю green. Отдельно ломаю только учётные данные тестового item, чтобы убедиться, что 401 не маскируется под red, и выполняю отрицательную проверку контрольного маркера. Flood stage на рабочем диске не воспроизвожу: его ветку тестирую сохранённым обезличенным JSON и логикой preprocessing. Стоп-условиями служат воздействие на чужие индексы, неожиданный рост relocation, latency или ресурсов. Evidence включает времена, ответы API, события Zabbix и успешный откат.

Runbook, откат и границы результата

При событии я сначала подтверждаю свежесть items и доступ REST API, затем определяю цвет, число неназначенных primary и replica и затронутые индексы. Следом читаю Allocation Explain для одного представительного шарда, проверяю диск всех подходящих data nodes, фактические watermarks, блокировки индексов, правила allocation и уход узлов. Параллельно запускаю только согласованный контрольный поиск и смотрю failed shards, а не рабочие документы. Исправление выбирает владелец по доказанной причине: освободить или добавить ёмкость, восстановить узел, скорректировать ошибочное правило либо вернуть допустимое резервирование. До изменения сохраняются persistent и transient settings, шаблон и права; откат возвращает только изменённый параметр и повторяет health, shards, blocks и search checks. После нормализации я наблюдаю полный цикл обновления Zabbix и убеждаюсь, что событие закрылось по новым данным, а не вручную. В рабочей записи остаются исходный симптом, решение decider, выполненное действие и четыре контрольных ответа без адресов, токенов и названий закрытых индексов. Такая запись полезна для следующего дежурства и пересмотра ёмкости. Эта схема не гарантирует качество выдачи, сохранность данных или достаточную производительность под пиковой нагрузкой. Если требуется внедрить такой контроль с понятными правами и проверкой восстановления, свяжитесь с IT Fresh: https://itfresh.ru/, https://t.me/ITfresh_Boss, tel:+79037296241.

Отвергнутые альтернативы

• Считать любой yellow недоступностью поискаПри yellow назначены все primary, но отсутствует часть реплик; риск отказоустойчивости реален, однако доступность конкретного запроса нужно проверять отдельно.
• Тревожиться только по проценту заполнения файловой системыРешение распределителя зависит от применённых watermarks, доступного места на подходящих узлах, ролей и правил allocation, а процент не показывает блокировки индекса.
• Автоматически выполнять reroute для каждого unassigned shardAllocation Explain может указать на отсутствие валидной копии, фильтры, awareness, лимит шардов или диск; слепое размещение способно скрыть причину и увеличить риск.
• Проверять поиск только обращением к корневому URLУспешный HEAD или GET подтверждает доступность HTTP endpoint, но не выполнение запроса по нужному индексу и не отсутствие отказавших шардов.
• Передавать Zabbix административную учётную записьДля чтения health, shard, node и ограниченного поиска достаточно отдельного минимального набора прав; административные операции мониторингу не нужны.

Конфигурация и сбор

Отдельная TLS-учётная запись только для чтения cluster health, shard allocation, node disk statistics и согласованного поискового индекса; в Zabbix — доступ к выделенному шаблону и защищённым макросам без административных операций кластера.

• Получить Cluster Health API с filter_path и сохранить status, timed_out, узлы и состояния шардов.
• При unassigned прочитать CAT Shards и выполнить Allocation Explain только для одного характерного шарда без reroute.
• Сопоставить node disk statistics с фактическими low, high, flood-stage settings и блокировками индексов.
• Выполнить ограниченный контрольный поиск, проверить HTTP-код, timed_out, failed shards и свежесть всех dependent items.

Контролируемая проверка и свидетельство

В изолированном тестовом индексе временно создаётся безопасно неназначаемая replica; проверяются yellow, unassigned, Allocation Explain и сохранение поиска по primary. Затем исходное число реплик возвращается и подтверждаются назначение, green, работа поиска и закрытие событий Zabbix. Дисковое заполнение не имитируется.

Фрагмент рабочего регламента

• Проверить timestamp items, достижимость API и отличить HTTP/auth/preprocessing error от состояния cluster health.
• Разделить unassigned primary и replica, определить затронутые индексы и прочитать одно Allocation Explain.
• Сопоставить свободный диск data nodes с действующими watermarks, allocation rules и index blocks.
• Запустить согласованный read-only search check и зафиксировать timed_out и failed shards без чтения рабочих документов.

Откат

До controlled check сохраняются число реплик тестового индекса, persistent и transient cluster settings, версия Zabbix template, macros и права роли. Откат возвращает изменённое число реплик и конфигурацию единичными обратными действиями; затем повторяются health, shard allocation, index blocks, контрольный поиск и проверка свежести items.

Ограничения вывода

Cluster health описывает распределение шардов, но не гарантирует доступность каждого запроса, полноту частичного ответа, релевантность выдачи или требуемую задержку. Универсальные watermarks и пороги времени не назначаются без размера дисков, темпа роста, правил allocation, версии продукта и окна реакции. Мониторинг не заменяет snapshots и план восстановления.