Ключевые метрики для общей проверки работоспособности

На диаграмме показан высокодоступный кластер StarVault с пятью узлами, распределенными между тремя зонами доступности. Интегрированное хранилище StarVault использует согласованный протокол для обеспечения синхронизации между узлами кластера. Ведущий (активный) узел отвечает за прием новых записей журнала, их репликацию на последующие (резервные) узлы и управление временем фиксации записи. Integrated Storage использует согласованный протокол для обеспечения синхронизации; поэтому, если лидер потерян, узлы выбирают нового лидера. Более подробную информацию см. в документации по Integrated Storage.

Метрика vault.core.leadership_lost измеряет продолжительность, в течение которой сервер занимал лидирующую позицию, прежде чем потерять ее. Стабильно низкое значение этого показателя свидетельствует о высокой сменяемости руководства, что указывает на потенциальную нестабильность в кластере.

С другой стороны, скачки метрики vault.core.leadership_setup_failed указывают на то, что резервные серверы не могут успешно взять на себя роль лидера, когда это требуется. Незамедлительно расследуйте эти сбои и проверьте, нет ли проблем с получением блокировки выборов лидера. Эти метрики являются важными предупреждениями и могут указывать на риски безопасности и надежности.

StarVault может использовать доверенные источники, такие как Kubernetes и Active Directory для проверки личности клиентов (пользователей или сервисов) перед предоставлением им доступа к секретам. Клиенты должны пройти аутентификацию, сделав запрос на вход с помощью команды starvault login или API. После успешной аутентификации StarVault выдает клиенту токен, который хранится локально на машине клиента и используется для авторизации последующих запросов. Если клиент предъявляет действительный токен, срок действия которого не истек, StarVault признает его аутентифицированным.

Усредненный показатель vault.core.handle_login_request измеряет, насколько быстро StarVault реагирует на запросы клиента на вход в систему. Если вы заметили значительное увеличение этого показателя, но не заметили существенного увеличения количества выпущенных токенов (vault.token.creation), важно немедленно выяснить причину этой проблемы.

Когда клиент отправляет запрос в StarVault, ему обычно необходимо пройти процедуру аутентификации, чтобы подтвердить свою личность и получить необходимые разрешения. Этот процесс аутентификации включает проверку учетных данных клиента, таких как имя пользователя и пароль или токен API, и обеспечение того, чтобы у клиента были соответствующие права доступа.

Если процесс аутентификации в StarVault выполняется медленно, StarVault требуется больше времени для проверки учетных данных клиента и авторизации запроса. Такая задержка в аутентификации напрямую влияет на время ответа StarVault на запрос клиента.

Необходимо отслеживать показатель vault.core.handle_request, который измеряет нагрузку на сервер. Этот показатель помогает определить, нужно ли расширять кластер для удовлетворения возросшего трафика. С другой стороны, внезапное снижение пропускной способности может указывать на проблемы с подключением между StarVault и его клиентами, которые следует изучить дополнительно.

Серверы StarVault могут находиться в одном из двух состояний:

Для обеспечения безопасности StarVault не доверяет бэкендам хранилищ и хранит данные в зашифрованном виде. После запуска StarVault должен пройти процесс распечатывания, чтобы получить root ключ в виде открытого текста, необходимый для чтения ключа расшифровки данных. После распечатывания StarVault выполняет различные операции, чтобы правильно настроить сервер, прежде чем он сможет начать отвечать на запросы.

Если вы заметили внезапное увеличение метрики vault.core.post_unseal, это означает, что на доступность вашего сервера во время процесса post-unseal могут влиять такие проблемы, как ошибки с аудитом или монтированием бэкенда пользовательского плагина. Чтобы диагностировать проблемы, обратитесь к журналам сервера StarVault.

Все аутентифицированные запросы StarVault требуют наличия действительного клиентского токена. Токены связаны с политиками, определяющими, какими возможностями обладает клиент (пользователь или система) для определенного пути. StarVault выпускает три типа токенов: сервисные, пакетные и токены восстановления.

Сервисные токены - это то, что пользователи обычно воспринимают как "обычные" токены StarVault. Они поддерживают все функции, такие, как обновление, отзыв, создание дочерних токенов и другие. Соответственно, их создание и отслеживание требует больших усилий.

Пакетные токены - это зашифрованные двоичные объекты большого размера (блобы), содержащие лишь достаточную информацию о клиенте. Хотя StarVault не хранит пакетные токены, он хранит токены сервисов. Объем пространства, необходимый для хранения служебного токена, зависит от метода аутентификации. Поэтому большое количество сервисных токенов может привести к проблеме нехватки памяти.

Токены восстановления используются исключительно для работы StarVault в режиме восстановления.

Отслеживая количество созданных токенов (vault.token.creation) и частоту запросов на вход (vault.core.handle_login_request, считая от общего числа), вы можете получить представление об общей загруженности системы. Если ваш сценарий предполагает запуск множества короткоживущих процессов, как, например, в бессерверных рабочих нагрузках, вы можете столкнуться с одновременным созданием и запросом секретов от сотен или тысяч функций. В таких случаях вы увидите коррелированные всплески в обеих метриках.

При работе с переходными рабочими нагрузками следует использовать пакетные токены, чтобы повысить производительность кластера. StarVault создает пакетный токен, который шифрует всю информацию клиента и предоставляет ее клиенту. Когда клиент использует этот токен, StarVault расшифровывает сохраненные метаданные и выполняет запрос. В отличие от сервисных токенов, пакетные не хранят информацию о клиенте и не реплицируются по кластерам. Эта особенность позволяет снизить нагрузку на бэкэнд хранилища и повысить производительность кластера.

Чтобы узнать больше о пакетных токенах, обратитесь к руководству по пакетным токенам.

StarVault создает договор аренды, когда генерирует динамический секрет или служебный маркер. Эта аренда содержит важную информацию, такую, как время жизни секрета или токена (TTL), а также возможность продления или обновления. StarVault хранит договор аренды в бэкенде хранилища. Если StarVault не продлит договор аренды до истечения TTL, он истечет и будет признан недействительным, что приведет к аннулированию связанного с ним секрета или токена.

Отслеживание количества активных договоров аренды на вашем сервере StarVault (vault.expire.num_leases) может дать ценную информацию об уровне активности сервера. Увеличение количества договоров аренды свидетельствует о повышении объема трафика для вашего приложения. В то же время внезапное снижение может указывать на проблемы с доступом к динамическим секретам, которые могут быть получены достаточно быстро для обслуживания входящего трафика.

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

Если вы не укажете TTL в явном виде, срок аренды по умолчанию составит 32 дня. Однако если произойдет резкий скачок нагрузки и будет сгенерировано множество аренд с таким длинным TTL по умолчанию, бэкэнд хранилища может быстро достичь своей максимальной емкости и выйти из строя, что приведет к его недоступности.

В зависимости от конкретного случая использования вам может потребоваться токен или секрет не на полные 32 дня, а на несколько минут или часов. Установив соответствующий TTL, вы сможете освободить место в хранилище для хранения новых секретов и маркеров. В случае StarVault Enterprise можно установить квоту на количество аренд, чтобы ограничить количество генерируемых аренд ниже определенного порога. Когда порог достигнут, StarVault ограничит создание новых аренд до тех пор, пока срок действия существующей аренды не истечет или она не будет отозвана. Это помогает управлять общим количеством аренд и предотвращает чрезмерное использование ресурсов.

Ознакомьтесь с руководством "Защита StarVault с помощью квот на ресурсы", чтобы узнать, как установить квоты на количество аренд.

Также можно использовать кэширование агента StarVault, чтобы передать управление жизненным циклом аренды агенту StarVault Agent.

StarVault автоматически отзывает доступ к секретам, предоставленный токеном, когда истекает время его жизни (TTL). Вы можете вручную отозвать токен, если есть признаки возможного нарушения безопасности. Когда токен становится недействительным (истек срок действия или отозван), клиент теряет доступ к секретам, управляемым StarVault. Поэтому клиент должен либо обновить токен до истечения срока его действия, либо запросить новый.

Контроль за своевременным выполнением операций отзыва (vault.expire.revoke) и обновления (vault.expire.renew-token) крайне важен для обеспечения валидности и доступности секретов. Некоторые приложения, работающие длительное время, могут потребовать продления срока действия токена вместо получения нового. В этом случае время, необходимое для обновления токена, может потенциально повлиять на доступ приложения к секретам. Кроме того, важно отслеживать время, необходимое для выполнения операции отзыва, чтобы обнаружить несанкционированный доступ к секретам, поскольку злоумышленники, получившие доступ, могут проникнуть в вашу систему и нанести вред.

Производительность бэкэнда хранилища влияет на общую производительность StarVault. Поэтому очень важно отслеживать производительность бэкэнда хранилища, чтобы обнаружить и отреагировать на любую аномалию. Мониторинг бэкэнда позволяет убедиться в том, что инфраструктура хранения функционирует исправно. Отслеживание производительности позволяет собрать подробную информацию о работе бэкэнда и выявить области, требующие улучшения или оптимизации.

Если StarVault требует больше времени для доступа к бэкенду при выполнении таких операций, как извлечение (vault.<STORAGE>.get), хранение (vault.<STORAGE>.put), создание списка (vault.<STORAGE>.list) или удаление (vault.<STORAGE>.delete) элементов, клиенты StarVault могут наблюдать задержки, вызванные ограничениями хранения. Чтобы решить эту проблему, вы можете настроить оповещения, которые будут автоматически уведомлять вашу команду, когда доступ StarVault к бэкенду хранилища замедляется. Это позволит принять меры, например обновить диски с более высокой производительностью ввода-вывода (I/O), до того, как увеличение задержек негативно скажется на работе пользователей приложения.

Если вы используете интегрированное хранилище, читайте следующие статьи с дополнительными рекомендациями:

Устройства аудита играют важную роль в обеспечении соответствия нормативным требованиям, записывая полный журнал аудита запросов и ответов StarVault. Для производственного развертывания в кластере StarVault должно быть включено как минимум одно устройство аудита, чтобы вы могли отслеживать все входящие запросы и исходящие ответы, связанные с кластером. Если вы полагаетесь только на одно устройство аудита, то столкнетесь с такими проблемами:

StarVault может перестать реагировать на запросы и их обрабатывать. Включение хотя бы одного дополнительного устройства аудита необходимо для обеспечения бесперебойной работы и оперативного реагирования StarVault.

Для обеспечения бесперебойной работы важно отслеживать любое необычное увеличение количества отказов в журнале запросов аудита (vault.audit.log_request_failure) и отказов в ответах (vault.audit.log_response_failure). Эти сбои могут указывать на блокировку устройства. При возникновении подобных проблем, изучение журналов аудита может помочь определить проблемное устройство и дать дополнительные подсказки об основной проблеме.

Если StarVault не может записать журналы аудита в syslog, сервер будет генерировать журналы ошибок, как показано в следующем примере:

Для каждого неудачного ответа журнала следует ожидать несколько ошибок от модулей аудита и ядра. Если вы получаете сообщение об ошибке, содержащее write: message too long, это означает, что записи, которые StarVault пытается записать в устройство аудита syslog, превышают размер буфера отправки сокета узла syslog. В таких случаях необходимо выяснить, что является причиной создания больших записей журнала, например обширный список групп Active Directory или LDAP.

Сборка мусора в среде выполнения Go временно приостанавливает все операции. Обычно эти паузы кратковременны, но при высоком уровне использования памяти сборка мусора происходит чаще. Увеличение частоты сбора мусора может привести к задержкам в работе StarVault.

Анализ взаимосвязи между использованием памяти StarVault (в процентах от общего объема доступной памяти на хосте) и временем паузы сборки мусора (измеряется vault.runtime.gc_pause_ns). Эта метрика может дать ценные сведения об ограничении ресурсов и помочь в эффективном распределении вычислительных ресурсов.

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

[[in\out-processor]] === Время ожидания ввода/вывода процессора

StarVault масштабируется горизонтально путем добавления новых экземпляров или узлов, однако практические пределы масштабируемости все же существуют. Чрезмерное время ожидания процессора при выполнении операций ввода-вывода может указывать на то, что система достигает пределов масштабируемости или чрезмерно использует определенные ресурсы. Отслеживая эти показатели, администраторы могут оценить масштабируемость системы и предпринять соответствующие действия, например оптимизировать операции ввода-вывода или добавить дополнительные ресурсы, чтобы поддерживать производительность по мере роста системы.

Для обеспечения оптимальной производительности рекомендуется поддерживать время ожидания ввода-вывода на уровне менее 10 процентов. Если вы заметили слишком большое время ожидания, это означает, что клиенты испытывают задержки при ожидании ответа StarVault на их запросы. Такая задержка может негативно сказаться на производительности приложений, которые полагаются на StarVault. В таких ситуациях необходимо проверить, правильно ли настроены ресурсы для работы с нагрузкой и равномерно ли распределены запросы по всем процессорам. Эти шаги помогут устранить потенциальные проблемы с производительностью и обеспечить бесперебойную работу StarVault и зависимых от него приложений.

Мониторинг пропускной способности сети кластеров StarVault позволяет оценить их загруженность. Внезапное снижение входящего или исходящего трафика может указывать на проблемы со связью между StarVault и его клиентами или зависимостями. И наоборот, если вы наблюдаете неожиданный всплеск сетевой активности, это может быть признаком атаки типа "отказ в обслуживании" (DoS). Знание этих сетевых закономерностей может дать ценные сведения и помочь выявить потенциальные проблемы или угрозы безопасности.

Вы можете устанавливать квоты на ограничение скорости, чтобы обеспечить общую стабильность и работоспособность StarVault. Когда сервер достигнет этого порога, StarVault будет отклонять все новые запросы клиентов и отвечать ошибкой HTTP 429, а именно "Слишком много запросов".

Эти отклоненные запросы будут записаны в журналы аудита и отобразят сообщение, как в этом примере: "error: request path kv/app/test: rate limit quota exceeded."

Выбор подходящего предела для квоты скорости очень важен, чтобы не блокировать легитимные запросы и не вызывать замедления работы приложений. Чтобы отслеживать частоту таких нарушений и соответствующим образом корректировать лимит, вы можете следить за метрикой quota.rate_limit.violation, которая увеличивается при каждом нарушении квоты лимита скорости.

Обратитесь к руководству по защите StarVault с помощью квот на ресурсы, чтобы узнать, как установить квоты на ограничение скорости для вашего StarVault.

Для поддержания высокой производительности в StarVault используется сборщик мусора, который периодически удаляет старые журналы записи (WAL), чтобы освободить память на внутреннем хранилище. Однако при неожиданных скачках трафика накопление WAL может происходить быстро, что приводит к увеличению нагрузки на бэкэнд хранилища. Такие скачки могут негативно повлиять на другие процессы в StarVault, которые полагаются на тот же бэкэнд хранилища. Поэтому важно оценить влияние репликации на производительность бэкэнда хранилища. Это позволит лучше понять, как процесс репликации влияет на общую производительность системы.

Рекомендуется следить за двумя метриками: vault.wal_flushready и vault.wal.persistWALs.

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

Вторая - время, необходимое для персистирования WAL в бэкенд хранилища.

Для обеспечения эффективной работы рекомендуется настроить оповещения, которые будут уведомлять вас, когда метрика vault.wal_flushready превысит 500 миллисекунд или когда метрика vault.wal.persistWALs превысит 1 000 миллисекунд. Эти предупреждения служат индикаторами того, что обратное давление замедляет работу бэкенда хранилища.

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

Журнал StarVault с опережающей записью (WAL) - это механизм долговременного хранения и восстановления данных. WAL - это файл журнала, в который записываются все изменения, внесенные в хранилище данных StarVault, прежде чем StarVault сохранит их в базовом бэкенде хранилища. WAL обеспечивает дополнительный уровень надежности и гарантирует целостность данных в случае системных сбоев или отказов.

При развертывании StarVault Enterprise с настройками Performance Replication и/или Disaster Recovery Replication необходимо следить за тем, чтобы данные реплицировались с первичного на вторичные кластеры. Чтобы обнаружить, что первичный и вторичный кластеры теряют синхронизацию, можно сравнить последний индекс Write-Ahead Log (WAL) на обоих кластерах.

Поэтому, если вы заметили недостающие значения в WAL, необходимо выяснить возможные причины, которые могут включать:

Чтобы выявить такие проблемы, изучите журналы операций и хранения хранилища, в которых содержится подробная информация о проблемных ключах, вызывающих сбои в синхронизации.

Чтобы узнать больше, обратитесь к руководству по мониторингу репликации хранилища.