Модуль доступен только в Deckhouse Enterprise Edition.

Общая информация

Основные сущности в системе:

  • Проект — сущность, которая позволяет хранить внутри себя мониторинговые данные. В зависимости от конфигурации это могут быть метрики, логи или трейсы. Конфигурация определяется типом приобретенной лицензии. В рамках проекта настраивается обработка триггеров (Alerting Rules) и правил уведомлений (конфигурация Alertmanager).
  • Рабочее пространство — логическое объединение проектов в группу.
  • Организация — логическое объединение рабочих пространств в группу.
  • API-токен — сущность, с помощью которой осуществляется доступ к API и мониторинговым данным, хранящимся в системе. С помощью API-токена можно выполнять различные операции, такие как чтение или запись метрик и управление Alerting Rules.
  • Пользователь — учётная запись в системе, обладающая различными правами доступа к различным сущностям системы.

Организация

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

Рабочие пространства

В данном подразделе пользователь может просматривать рабочие пространства и проекты, к ним относящиеся, а также управлять непосредственно рабочими пространствами: создавать и удалять их.

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

Дашборды

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

Иерархия дашбордов

В Deckhouse Observability Platform дашборды организованы в соответствии со следующей иерархией:

  1. Дашборды уровня установки — предустановленные дашборды, которые базируются на метриках от opAgent и метриках Deckhouse Kubernetes Platform. Они являются неотъемлемой частью поставки, ни пользователи, ни администраторы не могут вносить в них изменения или просматривать их список. Эти дашборды отображаются ситуативно, при наличии необходимой (ключевой) метрики для каждого из дашбордов.

  2. Дашборды уровня организации — дашборды, создаваемые в организации и доступные во всех проектах. Пользователи на уровне проектов не могут менять или удалять эти дашборды, что полезно для распространения стандартных дашбордов.

Важно: изменение в этом дашборде приведёт к тому, что он будет обновлен во всех проектах. Будьте осторожны при внесении изменений.

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

В этом подразделе пользователь может:

  • просматривать, редактировать и удалять дашборды уровня организации;
  • просматривать, редактировать и удалять директории для дашбордов уровня организации.
Действия с дашбордами

  1. Создание нового дашборда:

    • нажмите кнопку «Добавить»;
    • заполните следующие поля:
      • «Название» — укажите название дашборда;
      • «Директория» — выберите директорию для размещения дашборда;
      • «Редактировать JSON» — вставьте JSON-конфигурацию дашборда в формате Grafana;
    • сохраните дашборд.

Важно: перед созданием первого дашборда необходимо создать директорию, так как размещение дашбордов вне директорий невозможно.

  1. Редактирование дашборда:

    • откройте дашборд на редактирование;
    • скопируйте и вставьте обновлённую JSON-конфигурацию;
    • сохраните изменения.

  2. Удаление дашборда:

    • откройте дашборд на редактирование;
    • нажмите кнопку «Удалить».

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

Создание, редактирование и удаление директорий

  1. Создание новой директории:

    • нажмите кнопку «Добавить»;
    • введите название директории;
    • сохраните директорию.

  2. Редактирование директории:

    • откройте список директорий;
    • выберите директорию, которую хотите изменить;
    • внесите необходимые изменения;
    • сохраните изменения.

  3. Удаление директории:

    • откройте список директорий;
    • выберите директорию, которую хотите удалить;
    • нажмите кнопку «Удалить»;
    • подтвердите удаление.

Важно: при удалении директории все дашборды, находящиеся в ней, будут удалены без возможности восстановления.

Центр уведомлений

Центр уведомлений предоставляет пользователю возможность управлять триггерами и производными метриками на уровне организации, а также настраивать каналы доставки уведомлений.

Триггеры

Триггер — это правило, определяющее условия, при которых срабатывает определённое событие (алерт). В Deckhouse Observability Platform триггеры не приводят к непосредственной доставке уведомлений. Чтобы уведомления были доставлены, необходимо настроить каналы уведомлений и указать связь между триггерами и этими каналами.

Иерархия триггеров

В Deckhouse Observability Platform триггеры организованы в трёхуровневую модель:

  1. Триггеры уровня установки — предустановленные триггеры, настроенные разработчиками Deckhouse Observability Platform. Они созданы на базе метрик, которые собирает opAgent, и являются неотъемлемой частью ПО.
  2. Триггеры уровня организации — триггеры, создаваемые администраторами Deckhouse Observability Platform и доступные во всех проектах в пределах организации.
  3. Пользовательские триггеры — триггеры, которые создают пользователи в своих проектах.
Управление триггерами

В этом подразделе пользователь может:

  • просматривать, переопределять или отключать триггеры уровня установки. Изменения в этих триггерах влияют на все проекты;
  • создавать и управлять триггерами уровня организации. Эти триггеры доступны во всех проектах, и пользователи на уровне проекта могут их переопределять или отключать.

Важно: Будьте осторожны при внесении изменений в триггеры уровня установки и организации, так как они повлияют на все проекты в системе.

Просмотр триггеров

Триггеры в интерфейсе «Центра уведомлений» отображаются в двух секциях:

  • триггеры уровня установки отображаются в секции «По умолчанию»;
  • триггеры уровня организации отображаются в секции «Пользовательские».
Действия с триггерами

На уровне пользователя доступны следующие действия с триггерами:

  1. Отключение триггеров уровня установки:

    • найдите нужный триггер в списке «По умолчанию»;
    • нажмите кнопку «Отключить правило»;

Впоследствии триггер можно включить, нажав кнопку «Включить правило».

  1. Переопределение триггеров уровня инсталляции:

    • найдите нужный триггер в списке «По умолчанию»;
    • нажмите кнопку «Переопределить правило»;
    • внесите необходимые изменения и сохраните их;
    • переопределённый триггер переместится из списка «По умолчанию» в список «Пользовательские».

  2. Возврат триггера уровня организации к исходному значению:

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

  3. Создание триггера уровня организации:

  • нажмите кнопку «Добавить»;

  • заполните соответствующие поля:

    • «Название» — введите имя, которое будет использоваться в качестве названия триггера.
    • «Выражение» — напишите PromQL-выражение, которое будет выполняться для проверки триггера. Триггер считается сработавшим, если запрос вернул хотя бы одну серию.
    sum(rate(http_requests_total[5m])) > 10
    • «Задержка перед срабатыванием алерта» — укажите, как долго алерт не будет считаться активным после выполнения условия срабатывания. Это помогает избежать флапающих алертов.
    • «Продолжительность срабатывания после завершения» — укажите, как долго алерт будет считаться активным после прекращения выполнения условия. Это полезно для избегания флапающих алертов на пограничных значениях.
    • «Лейблы» — укажите пары ключ-значение для задания лейблов, которые будут добавлены к алерту.
    • «Аннотации» — укажите дополнительные метаданные или информацию, которые должны быть частью алерта (например, инструкции по решению проблемы или контактную информацию).

  1. Удаление триггера:

    • откройте триггер на редактирование;
    • нажмите кнопку «Удалить».

Производные метрики

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

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

Иерархия производных метрик

В Deckhouse Observability Platform производные метрики организованы в трёхуровневую модель:

  1. Производные метрики уровня установки — предустановленные метрики, настроенные разработчиками Deckhouse Observability Platform, основанные на данных, собираемых opAgent.
  2. Производные метрики уровня организации — создаются администраторами Deckhouse Observability Platform и доступны во всех проектах организации.
  3. Пользовательские производные метрики — создаются пользователями в рамках конкретных проектов.
Управление производными метриками

В этом подразделе пользователь может:

  • просматривать, переопределять и отключать производные метрики уровня установки;
  • создавать и управлять производными метриками уровня организации.

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

Просмотр производных метрик
  • «По умолчанию» — отображаются производные метрики уровня установки.
  • «Пользовательские» — отображаются производные метрики уровня организации.
Действия с производными метриками

  1. Отключение производной метрики уровня инсталляции:

    • нажмите кнопку «Отключить правило» рядом с нужной метрикой;
    • для повторного включения метрики нажмите «Включить правило».

  2. Переопределение производной метрики уровня установки:

    • нажмите кнопку «Переопределить правило» рядом с метрикой;
    • внесите необходимые изменения и сохраните их;
    • после сохранения метрика исчезнет из списка «По умолчанию» и появится в списке «Пользовательские»;
    • для возврата к исходному значению найдите метрику в списке «Пользовательские» и нажмите «Вернуть к исходному значению».

  3. Создание новой производной метрики уровня организации:

    • нажмите кнопку «Добавить»;

    • заполните необходимые поля:

      • «Название» — укажите название метрики;
      • «Выражение» — пропишите PromQL-выражение для расчёта метрики:
      avg_over_time(http_requests_total[5m])
      • «Лейблы» — задайте метки (пары ключ-значение) для дополнительной классификации и фильтрации метрик.

  4. Удаление производной метрики:

    • откройте метрику на редактирование;
    • нажмите кнопку «Удалить».

Каналы уведомлений

Каналы уведомлений позволяют настроить методы доставки уведомлений по различным каналам. Все настроенные каналы будут доступны при настройке доставки уведомлений на уровне проекта. Это позволяет централизованно управлять каналами уведомлений, скрывая доступ к чувствительным данным (например, имени пользователя и паролю для SMTP-сервера) и оставляя его только у администраторов организации. Пользователи могут быстро начать отправлять уведомления, не беспокоясь о конфигурации доступа.

На данный момент поддерживаются следующие каналы доставки:

  • Email — доставка по электронной почте;
  • Slack — доставка в мессенджеры, совместимые с API Slack;
  • Telegram — доставка в мессенджер Telegram;
  • Webhook — настройка произвольных вебхуков.
Создание канала

Для создания нового канала доставки выполните следующие шаги:

  • нажмите кнопку «Добавить»;
  • выберите тип канала, который хотите создать.
Настройка Email-канала
  • выберите «Создать Email-канал»;
  • заполните необходимые поля:
    • «Название канала» — укажите удобное название для канала;
    • «Отправитель» — адрес электронной почты, который будет указан как отправитель;
    • «Хост» — адрес SMTP-сервера;
    • «Имя пользователя» — имя для аутентификации на SMTP-сервере;
    • «Пароль» — пароль для аутентификации на SMTP-сервере;
    • «Ключ авторизации» — дополнительный ключ для аутентификации (если необходим);
    • «Секрет авторизации» — дополнительный секрет для аутентификации (если необходим);
    • «Необходимость TLS» — укажите, требуется ли TLS для подключения к SMTP-серверу.
Настройка Slack-канала
  • выберите «Создать Slack-канал»;
  • заполните необходимые поля:
    • «Название канала» — укажите удобное название для канала;
    • «API URL» — укажите URL API для интеграции со Slack.
Настройка Telegram-канала
  • выберите «Создать Telegram-канал»;
  • заполните необходимые поля:
    • «Название канала» — укажите удобное название для канала;
    • «API URL» — по умолчанию: https://api.telegram.org;
    • «Токен Telegram-бота» — токен, полученный при создании Telegram-бота.
Настройка Webhook-канала
  • выберите «Создать Webhook-канал»;
  • заполните необходимые поля:
    • «Название канала» — укажите удобное название для канала.

Создание этого канала позволяет выполнять произвольные запросы к вебхукам в проектах, предоставляя гибкость в интеграции системы с другими сервисами и приложениями.

Редактирование канала

Для редактирования существующего канала доставки выполните следующие шаги:

  • выберите канал, который хотите редактировать, и нажмите кнопку «Редактировать»;
  • внесите необходимые изменения в поля;
  • сохраните изменения.
Удаление канала

Для удаления существующего канала доставки выполните следующие шаги:

  • выберите канал, который хотите удалить;
  • откройте канал на редактирование;
  • нажмите кнопку «Удалить».

Статистика использования пространства организации

В этом разделе пользователь может просматривать статистику по использованию Deckhouse Observability Platform. Данные агрегированы по рабочим пространствам и представлены в виде различных графиков и метрик, позволяющих оценить производительность и объёмы данных.

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

  • «Metrics: Active Series» — количество активных серий. Активная серия — это количество уникальных метрик, поступивших за последние два часа.
  • «Metrics: Raw incoming rate» — входящий поток метрик в секунду. На этом графике отображаются данные после дедупликации.
  • «Metrics: Total count of samples» — суммарное количество сэмплов, хранящихся в долгосрочном хранилище. Сэмпл — это отдельное значение метрики, собранное в определённый момент времени.
  • «Metrics: Discarded samples» — ошибки при записи серий. Возможные причины ошибок включают:
    • sample_out_of_bounds — сэмпл находится за пределами допустимого диапазона значений;
    • sample_out_of_order — сэмпл пришёл в неправильном порядке;
    • sample_too_old — сэмпл слишком старый и не принимается системой;
    • sample_too_far_in_future — сэмпл находится слишком далеко в будущем;
    • new_value_for_timestamp — попытка записи другого значения для тех же временных меток;
    • per_user_series_limit — превышен лимит скорости поступления метрик для проекта;
    • metric_series_limit — превышен лимит, связанный с метрикой.
  • «Metrics: Storage usage» — объём пространства на диске, занимаемого метриками в долгосрочном хранилище.

Логи

  • «Logs: Raw incoming rate» — входящий поток логов.
  • «Logs: Discarded samples» — ошибки при записи логов. Возможные причины ошибок включают:
    • rate_limited — превышен лимит скорости, установленный для записи;
    • stream_limit — превышен лимит на количество потоков;
    • label_name_too_long — длина имени метки превышает допустимый лимит;
    • label_value_too_long — длина значения метки превышает допустимый лимит;
    • line_too_long — длина строки превышает допустимый лимит;
    • max_label_names_per_series — превышен лимит на количество имён меток в серии;
    • per_stream_rate_limit — превышен лимит на скорость записи в поток.
  • «Logs: Storage usage» — объём пространства на диске, занимаемого логами.

Пользователи

В этом разделе отображается список пользователей, имеющих доступ к организации. Возможности управления пользователями зависят от типа аутентификации, настроенного в Deckhouse Observability Platform.

Внешняя аутентификация

Если в Deckhouse Observability Platform включена аутентификация с помощью внешних систем (например, LDAP, OAuth и др.), то в этом разделе доступен только просмотр списка пользователей.

Внутренняя аутентификация

Если в Deckhouse Observability Platform используется внутренняя аутентификация (email и пароль), то в этом разделе доступны дополнительные возможности управления пользователями:

  • «Удаление пользователей» — удаление пользователей из системы.
  • «Изменение роли пользователя» — изменение роли пользователя. Подробнее о ролевой модели можно узнать в соответствующем разделе документации.

Важно: в этом разделе отображается роль пользователя на уровне организации. Пользователь может иметь различные роли с разным набором привилегий для других объектов в системе.

API-токены

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

Просмотр списка API-токенов

Пользователь может просматривать список всех API-токенов, выпущенных для проектов в рамках организации. Это позволяет контролировать текущие токены и предотвращать несанкционированный доступ.

Перевыпуск токена

Для перевыпуска токена:

  • найдите нужный токен в списке;
  • нажмите кнопку «Перевыпустить токен».

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

Создание токена

Для создания нового API-токена выполните следующие шаги:

  • нажмите кнопку «Добавить»;
  • заполните необходимые поля:
    • «Название» — укажите название для токена, описывающее его назначение (например, Токен для Prometheus remote write);
    • «Срок действия» — определяет время, в течение которого токен остаётся действительным:
      • «Дата» — укажите конкретную дату и время, до которых токен будет действителен. По истечении этого времени токен перестаёт быть действительным;
      • «Бессрочный» — если дата не указана, токен остаётся действительным до тех пор, пока не будет удалён;
    • «Права» — выберите комбинацию прав доступа, соответствующую требуемому набору прав. Подробнее о ролевой модели можно узнать в соответствующем разделе документации;
    • «Область действия» — определяет, на какие сущности системы (организации, рабочие пространства и проекты) будет распространяться действие токена.

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

  • имеют ограничение только на чтение мониторинговых данных из выбранной области действия;
  • обеспечивают доступ к данным всех проектов в рамках указанной области;
  • запросы с использованием мультитенантного токена выполняются на всём объёме данных проектов в выбранной области, предоставляя комплексный доступ к мониторинговой информации.

Редактирование токена

Для редактирования существующего токена выполните следующие шаги:

  • найдите нужный токен в списке;
  • нажмите кнопку «Редактировать»;
  • внесите необходимые изменения:
    • измените название токена;
    • обновите срок действия или задайте его, если он не был установлен;
    • измените область действия или права.

Удаление токена

Для удаления существующего токена выполните следующие шаги:

  • найдите нужный токен в списке;
  • нажмите кнопку «Удалить».

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

Настройки

В разделе «Настройки» пользователи могут управлять основными параметрами организации, такими как название и т. д. Это предоставляет администраторам возможность поддерживать актуальность данных и при необходимости осуществлять удаление организации.

Изменение названия организации

Для изменения названия организации выполните следующие шаги:

  • перейдите в раздел «Настройки»;
  • найдите поле «Название организации»;
  • введите новое название для организации;
  • нажмите кнопку «Сохранить».

Удаление организации

Для удаления организации выполните следующие шаги:

  • перейдите в раздел «Настройки»;
  • нажмите кнопку «Удалить»;
  • подтвердите удаление, следуя инструкциям на экране.

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

Рабочее пространство

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

Проекты

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

Важно: пользователь видит только те проекты, к которым у него есть доступ.

Статистика использования рабочего пространства

В этом разделе пользователь может просматривать статистику по использованию Deckhouse Observability Platform. Данные агрегированы по проектам текущего рабочего пространства и представлены в виде различных графиков и метрик, позволяющих оценить производительность и объёмы данных.

Метрики рабочего пространства

  • «Metrics: Active Series» — количество активных серий. Активная серия — это количество уникальных метрик, поступивших за последние два часа.
  • «Metrics: Raw incoming rate» — входящий поток метрик в секунду. На этом графике отображаются данные после дедупликации.
  • «Metrics: Total count of samples» — суммарное количество сэмплов, хранящихся в долгосрочном хранилище. Сэмпл — это отдельное значение метрики, собранное в определённый момент времени.
  • «Metrics: Discarded samples» — ошибки при записи серий. Возможные причины ошибок включают:
    • sample_out_of_bounds — сэмпл находится за пределами допустимого диапазона значений;
    • sample_out_of_order — сэмпл пришёл в неправильном порядке;
    • sample_too_old — сэмпл слишком старый и не принимается системой;
    • sample_too_far_in_future — сэмпл находится слишком далеко в будущем;
    • new_value_for_timestamp— попытка записи другого значения для тех же временных меток;
    • per_user_series_limit — превышен лимит скорости поступления метрик для проекта;
    • metric_series_limit — превышен лимит, связанный с метрикой.
  • «Metrics: Storage usage» — объём пространства на диске, занимаемого метриками в долгосрочном хранилище.

Логи рабочего пространства

  • «Logs: Raw incoming rate» — входящий поток логов.
  • «Logs: Discarded samples» — ошибки при записи логов. Возможные причины ошибок включают:
    • rate_limited — превышен лимит скорости, установленный для записи;
    • stream_limit — превышен лимит на количество потоков;
    • label_name_too_long — длина имени метки превышает допустимый лимит;
    • label_value_too_long — длина значения метки превышает допустимый лимит;
    • line_too_long — длина строки превышает допустимый лимит;
    • max_label_names_per_series — превышен лимит на количество имён меток в серии;
    • per_stream_rate_limit — превышен лимит на скорость записи в поток.
  • «Logs: Storage usage» — объём пространства на диске, занимаемого логами.

Пользователи рабочего пространства

В этом разделе можно просматривать список пользователей, имеющих доступ к текущему рабочему пространству. Возможности управления пользователями зависят от типа аутентификации, настроенного в Deckhouse Observability Platform.

Внешняя аутентификация пользователя рабочего пространства

Если в Deckhouse Observability Platform включена аутентификация с помощью внешних систем (например, LDAP, OAuth и др.), то в этом разделе доступен только просмотр списка пользователей.

Внутренняя аутентификация пользователя рабочего пространства

Если в Deckhouse Observability Platform используется внутренняя аутентификация (email и пароль), в этом разделе доступны дополнительные возможности управления пользователями:

  • «Удаление пользователей» — возможность удалить пользователей из системы;
  • «Изменение роли пользователя» — возможность изменить роль пользователя. Подробнее о ролевой модели можно узнать в соответствующем разделе документации.

Важно: в этом разделе отображается роль пользователя на уровне организации. Пользователь может иметь различные роли с разным набором привилегий для других объектов в системе.

API-токены для пользователя рабочего пространства

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

Просмотр списка API-токенов пользователя рабочего пространства

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

Перевыпуск токена для пользователя рабочего пространства

Для перевыпуска токена:

  • найдите нужный токен в списке;
  • нажмите кнопку «Перевыпустить токен».

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

Создание токена для пользователя рабочего пространства

Для создания нового API-токена выполните следующие шаги:

  • нажмите кнопку «Добавить»;
  • заполните необходимые поля:
    • «Название» — укажите название для токена, описывающее его назначение (например, Токен для Prometheus remote write);
    • «Срок действия» — определяет время, в течение которого токен остаётся действительным:
      • «Дата» — укажите конкретную дату и время, до которых токен будет действителен. По истечении этого времени токен перестаёт быть действительным;
      • «Бессрочный» — если дата не указана, токен остаётся действительным до тех пор, пока не будет удален;
    • «Права» — выберите комбинацию прав доступа, соответствующую требуемому набору прав. Подробнее о ролевой модели можно узнать в соответствующем разделе документации;
    • «Область действия» — определяет, на какие сущности системы (организации, рабочие пространства и проекты) будет распространяться действие токена.

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

  • имеют ограничение только на чтение мониторинговых данных из выбранной области действия;
  • обеспечивают доступ к данным всех проектов в рамках указанной области;
  • запросы с использованием мультитенантного токена выполняются на всём объёме данных проектов в выбранной области, предоставляя комплексный доступ к мониторинговой информации.

Редактирование токена пользователя рабочего пространства

Для редактирования существующего токена выполните следующие шаги:

  • найдите нужный токен в списке;
  • нажмите кнопку «Редактировать»;
  • внесите необходимые изменения:
    • измените название токена;
    • обновите срок действия или задайте его, если он не был установлен;
    • измените область действия или права.

Удаление токена пользователя рабочего пространства

Для удаления существующего токена выполните следующие шаги:

  • найдите нужный токен в списке;
  • нажмите кнопку «Удалить».

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

Настройки пользователя рабочего пространства

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

Изменение названия рабочего пространства

Для изменения названия рабочего пространства выполните следующие шаги:

  • перейдите в раздел «Настройки»;
  • найдите поле «Название рабочего пространства»;
  • введите новое название для рабочего пространства;
  • нажмите кнопку «Сохранить».

Удаление рабочего пространства

Для удаления рабочего пространства выполните следующие шаги:

  • перейдите в раздел «Настройки»;
  • нажмите кнопку «Удалить»;
  • подтвердите удаление, следуя инструкциям на экране.

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

Проект

Дашборды уровня проекта проекта

Дашборды уровня проекта в Deckhouse Observability Platform позволяют пользователям создавать графики и панели на основе специфичных для проекта метрик, а также других метрик для визуализации ключевых аспектов работы сервисов, поступающих данных и состояния самого проекта. Кроме того, здесь отображаются дашборды уровня организации и уровня установки, доступные только для просмотра.

Иерархия дашбордов проекта

В Deckhouse Observability Platform дашборды организованы в следующую иерархию:

  1. Дашборды уровня установки — предустановленные дашборды, которые базируются на метриках от opAgent и метриках Deckhouse Kubernetes Platform. Они являются неотъемлемой частью поставки, и пользователи и администраторы не могут вносить в них изменения или просматривать их список. Эти дашборды отображаются ситуативно, при наличии необходимой (ключевой) метрики для каждого из дашбордов.

  2. Дашборды уровня организации — дашборды, создаваемые в организации и доступные во всех проектах. Пользователи на уровне проектов не могут менять или удалять эти дашборды, что полезно для распространения стандартных дашбордов.

    Важно: изменение в этом дашборде приведёт к тому, что он будет обновлён во всех проектах. Будьте осторожны при внесении изменений.

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

Управление дашбордами проекта

В этом подразделе пользователь может:

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

Дашборды в интерфейсе отображаются в трёх секциях:

  1. «Серверы» — отображается список хостов, на которых установлен opAgent:

    • «Активные» — список хостов, с которых поступали данные в течение последнего часа;

    • «Устаревшие» — список хостов, с которых ранее приходили данные, но сейчас данные не поступают.

      После прекращения поступления данных хост перемещается из «Активных» в «Устаревшие» через час.

  2. «Дашборды» — список пользовательских дашбордов и дашбордов уровня организации и установки (доступны только для просмотра).
  3. «Интеграции» — список дашбордов, сгруппированных по интеграциям (базы данных, менеджеры очередей и т.д.). В этой секции отображаются дашборды на основе сервисов, найденных opAgent.
Действия с серверами проекта

  1. Просмотр дашбордов для сервера:

    • нажмите на название сервера.

Доступные дашборды для всех серверов:

  • «Common» — основные сведения о сервере: CPU, LA, потребление памяти;
  • «Disk» — использованные и свободные ресурсы дискового пространства;
  • «Network» — сетевые интерфейсы и их активность;
  • «Netstat» — статистика сетевых соединений;
  • «Process» — состояние активных процессов на сервере;
  • один или несколько дополнительных дашбордов (в зависимости от обнаруженных сервисов opAgent).

  1. Удаление хоста:

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

    • «Удаление хоста из списка устаревших» — если данные по хосту больше не нужны и данные с него не поступают, его можно скрыть из списка. Для этого нажмите кнопку «Удалить».

  2. Просмотр активных алертов:

    • Рядом с каждым сервером отображается количество активных алертов. Нажав на эту иконку, можно перейти в раздел «Центр уведомлений», где вывод будет отфильтрован по выбранному серверу.
Действия с интеграциями проекта

  1. Просмотр дашбордов для интеграции:

    • найдите нужный сервис в списке и нажмите на его название.

  2. Просмотр активных алертов:

    • рядом с каждым сервисом отображается количество активных алертов. Нажав на эту иконку, можно перейти в раздел «Центр уведомлений», где вывод будет отфильтрован по выбранному сервису.
Действия с дашбордами проекта

  1. Создание нового дашборда:

    • нажмите кнопку «Добавить».

Важно: перед созданием первого дашборда необходимо создать директорию, так как размещение дашбордов вне директорий невозможно.

  • заполните следующие поля:
    • «Название» — название дашборда;
    • «Директория» — директория для размещения дашборда;
    • «Редактировать JSON» — JSON-конфигурация дашборда в формате Grafana, если она у вас есть, или оставьте значение по умолчанию;
    • сохраните дашборд.

В результате откроется интерфейс для составления дашборда.

  1. Просмотр дашборда:

    • найдите нужный дашборд и нажмите на его название.

  2. Редактирование дашборда:

    • откройте дашборд на редактирование;
    • скопируйте и вставьте обновлённую JSON-конфигурацию;
    • измените название (если нужно);
    • измените директорию размещения (если нужно);
    • сохраните изменения.

Альтернативный вариант: откройте нужный дашборд, отредактируйте или добавьте нужные панели, сохраните изменения.

  1. Удаление дашборда:

    • откройте дашборд на редактирование;
    • нажмите кнопку «Удалить».
Создание, редактирование и удаление директорий проекта

  1. Создание новой директории:

    • нажмите кнопку «Создать»;
    • введите название директории;
    • сохраните директорию.

  2. Редактирование директории:

    • откройте список директорий;
    • выберите директорию, которую хотите изменить;
    • внесите необходимые изменения;
    • сохраните изменения.

  3. Удаление директории:

    • откройте список директорий;
    • выберите директорию, которую хотите удалить;
    • нажмите кнопку «Удалить»;
    • подтвердите удаление.

Важно: при удалении директории все дашборды, находящиеся в ней, будут удалены без возможности восстановления.

Обзор данных

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

Возможности

  • запросы к метрикам и логам — выполнение запросов на чтение данных, хранящихся в Deckhouse Observability Platform;
  • запросы к внешним хранилищам — если настроены дополнительные источники данных, пользователи могут выполнять запросы к внешним системам.

Языки запросов

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

  • метрики — для запроса данных метрик используется язык PromQL (Prometheus Query Language);
  • логи — для запроса данных логов используется язык LogQL (Loki Query Language).

Примеры запросов:

  • Запрос к метрикам с использованием PromQL:
sum(rate(http_requests_total[5m])) by (job)
  • Запрос к логам с использованием LogQL:
{job="varlogs"} |= "error"

Центр уведомлений проекта

Центр уведомлений предоставляет пользователю возможность просматривать текущие активные триггеры, а также управлять триггерами и производными метриками проекта.

Уведомления проекта

В этом разделе пользователи могут просматривать список активных алертов. Алерты сгруппированы по уровню критичности, которая определяется на основании лейбла severity. Доступны следующие группы:

  • «Активные» — все активные алерты, включая те, у которых не установлено значение severity;
  • «Критичные» — алерты с severity: critical;
  • «Предупреждение» — алерты с severity: warning;
  • «Информационные» — алерты с severity: info;
  • «Настройка» — алерты с severity: info, специализированные алерты, которые сигнализируют о незавершённой настройке opAgent;
  • «Завершённые» — список всех завершённых алертов.

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

Действия с алертами проекта

Для каждого алерта предоставлены следующие возможности:

  • Просмотр графика алерта — на графике отображаются изменения значений и пороговых значений (threshold). Чтобы просмотреть график, найдите нужный алерт и нажмите кнопку «График алерта».

  • Отключение алерта — возможность на время остановить получение данного алерта (например, в случае проведения плановых работ). Чтобы отключить алерт, найдите его и нажмите кнопку «Отключить». Подробнее об отключении алертов можно узнать в разделе документации.

  • Просмотр триггера — просмотр правила уведомления, которое привело к срабатыванию алерта. Нажмите «Просмотреть правило уведомления» для получения этой информации.

  • Принудительное завершение алерта — для триггеров, у которых настроена двойная проверка, есть возможность их принудительного завершения. Для этого найдите нужный алерт и нажмите «Завершить». Подробнее о двойной проверке можно прочитать в разделе документации.

Триггеры проекта

Триггер — это правило, определяющее условия, при которых срабатывает определённое событие (алерт). В Deckhouse Observability Platform триггеры не приводят к непосредственной доставке уведомлений. Чтобы уведомления были доставлены, необходимо настроить каналы уведомлений и указать связь между триггерами и этими каналами.

Иерархия триггеров проекта

В Deckhouse Observability Platform триггеры организованы в трёхуровневую модель:

  1. Триггеры уровня установки — предустановленные триггеры, настроенные разработчиками Deckhouse Observability Platform. Они созданы на базе метрик, которые собирает opAgent, и являются неотъемлемой частью ПО.
  2. Триггеры уровня организации — триггеры, создаваемые администраторами Deckhouse Observability Platform, доступные во всех проектах в пределах организации.
  3. Пользовательские триггеры — триггеры, которые создают пользователи в своих проектах.
Управление триггерами проекта

В этом подразделе пользователь может:

  • просматривать, переопределять или отключать триггеры уровня инсталляции и организации;
  • создавать и управлять триггерами уровня проекта.
Просмотр триггеров проекта

Триггеры в интерфейсе «Центра уведомлений» отображаются в двух секциях:

  • триггеры уровня установки и организации отображаются в секции «По умолчанию».
  • триггеры уровня проекта отображаются в секции «Пользовательские».
Действия с триггерами проекта

На уровне пользователя доступны следующие действия с триггерами:

  1. Отключение триггеров уровня инсталляции и организации:

    • найдите нужный триггер в списке «По умолчанию»;
    • Нажмите кнопку «Отключить правило».

Впоследствии триггер можно включить, нажав кнопку «Включить правило».

  1. Переопределение триггеров уровня инсталляции и проекта:

    • найдите нужный триггер в списке «По умолчанию»;
    • нажмите кнопку «Переопределить правило»;
    • внесите необходимые изменения и сохраните их.

Переопределённый триггер переместится из списка «По умолчанию» в список «Пользовательские».

  1. Возврат триггера уровня инсталляции или организации к исходному значению:

    • найдите нужный триггер в списке «Пользовательские»;
    • нажмите кнопку «Вернуть к исходному значению».

Триггер переместится обратно в список «По умолчанию».

  1. Создание триггера уровня проекта:

    • нажмите кнопку «Добавить»;

    • заполните соответствующие поля:

      • «Название» — имя, которое будет использоваться в качестве названия триггера;
      • «Выражение» — PromQL-выражение, которое будет выполняться для проверки триггера. Триггер считается сработавшим, если запрос вернул хотя бы одну серию. Пример:
      sum(rate(http_requests_total[5m])) > 10
      • «Задержка перед срабатыванием алерта» — время, в течение которого алерт не будет считаться активным после выполнения условия срабатывания. Это помогает избежать флапающих алертов;
      • «Продолжительность срабатывания после завершения» — время, в течение которого алерт будет считаться активным после прекращения выполнения условия. Это полезно для избегания флапающих алертов на пограничных значениях;
      • «Лейблы» — пары ключ-значение для задания лейблов, которые будут добавлены к алерту;
      • «Аннотации» — дополнительные метаданные или информация, которые должны быть частью алерта (например, инструкции по решению проблемы или контактная информация).

  2. Удаление триггера

    • откройте триггер на редактирование;
    • нажмите кнопку «Удалить».

Двойная проверка триггеров проекта

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

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

Настройка двойной проверки проекта

Для включения двойной проверки в триггере следует добавить следующие лейблы:

  • double_check — указывает, нужна ли дополнительная проверка (true|false);
  • resolve_double_check_metric — имя метрики, которая будет дополнительно проверяться;
  • resolve_double_check_labels — список лейблов, вызвавших срабатывание триггера, значения которых будут взяты из серии и подставлены в запрос к метрике из resolve_double_check_metric.
Логика работы

Когда включена двойная проверка, система выполняет дополнительный запрос для проверки, действительно ли триггер перестал быть активным или метрика пропала. Если метрика пропала, триггер останется активным. Триггер перестаёт быть активным в двух случаях:

  • метрика снова появилась и не удовлетворяет условиям срабатывания;
  • пользователь принудительно завершил алерт (например, если база данных была удалена с сервера).

Производные метрики проекта

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

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

Иерархия производных метрик проекта

В Deckhouse Observability Platform производные метрики организованы в трёхуровневую модель:

  1. Производные метрики уровня установки — предустановленные метрики, настроенные разработчиками Deckhouse Observability Platform, основанные на данных, собираемых opAgent.
  2. Производные метрики уровня организации — создаются администраторами Deckhouse Observability Platform и доступны во всех проектах организации.
  3. Пользовательские производные метрики — создаются пользователями в рамках конкретных проектов.
Управление производными метриками проекта

В этом подразделе пользователь может:

  • просматривать, переопределять и отключать производные метрики уровня инсталляции и организации;
  • создавать и управлять производными метриками уровня проекта.
Просмотр производных метрик проекта
  • «По умолчанию» — отображаются производные метрики уровня инсталляции и организации;
  • «Пользовательские» — отображаются производные метрики уровня проекта.
Действия с производными метриками проекта

  1. Отключение производной метрики уровня установки или организации:

    • нажмите кнопку «Отключить правило» рядом с нужной метрикой;
    • для повторного включения метрики нажмите «Включить правило».

  2. Переопределение производной метрики уровня инсталляции или организации:

    • нажмите кнопку «Переопределить правило» рядом с метрикой;
    • внесите необходимые изменения и сохраните их;

После сохранения метрика исчезнет из секции «По умолчанию» и появится в секции «Пользовательские».

Для возврата к исходному значению найдите метрику в списке «Пользовательские» и нажмите «Вернуть к исходному значению».

  1. Создание новой производной метрики уровня проекта:

    • нажмите кнопку «Добавить»;

    • заполните необходимые поля:

      • «Название» — название метрики;
      • «Выражение» — PromQL-выражение для расчета метрики:
      avg_over_time(http_requests_total[5m])
      • «Лейблы» — метки (пары ключ-значение) для дополнительной классификации и фильтрации метрик.

  2. Удаление производной метрики:

    • откройте метрику на редактирование;
    • нажмите кнопку «Удалить».

Отключённые уведомления

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

Создание отключения уведомлений

Для создания нового отключения уведомлений выполните следующие шаги:

  • нажмите кнопку «Добавить»;
  • заполните необходимые поля:
    • «Начинается» — дата и время начала отключения уведомлений;
    • «Заканчивается» — дата и время окончания отключения;
    • «Комментарий» — комментарий, описывающий причину отключения;
    • «Фильтры» — фильтры для применения отключений к конкретным алертам:
      • «Название лейбла» — названия лейблов, которые будут использоваться для фильтрации;
      • «Знак выбора» — оператор фильтрации (например, =, !=, =~);
      • «Значение лейбла» — значения лейблов для фильтрации.
  • Нажмите «Сохранить», чтобы создать отключение уведомлений.

Редактирование отключений уведомлений

Для редактирования существующего отключения выполните следующие шаги:

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

Удаление отключений уведомлений

Для удаления существующего отключения выполните следующие шаги:

  • найдите нужное отключение в списке;
  • нажмите кнопку «Удалить»;
  • подтвердите удаление, следуя инструкциям на экране.

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

Пересоздание отключений уведомлений

Для создания нового отключения на основе завершённого выполните следующие шаги:

  • найдите нужное отключение в списке завершённых;
  • нажмите кнопку «Пересоздать»;
  • отредактируйте период отключения (начало и завершение), если необходимо;
  • нажмите «Сохранить», чтобы создать новое отключение на основе завершённого.

Правила уведомлений

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

Создание правила уведомлений

Для создания нового правила уведомлений выполните следующие шаги:

  • нажмите кнопку «Добавить»;
  • выберите один из доступных каналов уведомлений;
  • заполните необходимые поля:
    • «Название» — название правила для его идентификации;
    • «Отправка об окончании» — включите, если необходимо отправлять уведомления об окончании события;
    • «Продолжить обработку» — включите, если необходимо отправить информацию по одному алерту в несколько каналов или нескольким получателям;
    • «По умолчанию» — установите, если это правило должно применяться ко всем алертам, которые не попали под другие правила. Рекомендуется всегда иметь такое правило, чтобы не пропустить алерты;
  • настройте фильтры для правила:
    • «Название лейбла» — название лейбла;
    • «Знак выбора» — оператор фильтрации (например, =, !=, =~);
    • «Значение лейбла» — значение для лейбла;
  • настройте маршруты для доставки уведомлений по каналам:
    • «Slack» — Slack-каналы для отправки уведомлений;
    • «Email» — адреса электронной почты, на которые будут отправляться уведомления;
    • «Telegram» — ID Telegram-чатов для отправки сообщений;
    • «Webhook» — URL’ы вебхуков для отправки данных;
  • нажмите «Сохранить», чтобы сохранить созданное правило.

Редактирование правил уведомлений

Для редактирования существующего правила уведомлений выполните следующие шаги:

  • найдите нужное правило в списке;
  • нажмите кнопку «Редактировать»;
  • внесите необходимые изменения в поля;
  • нажмите «Сохранить», чтобы сохранить изменения.

Удаление правил уведомлений

Для удаления существующего правила уведомлений выполните следующие шаги:

  1. Найдите нужное правило в списке.
  2. Нажмите кнопку «Удалить».
  3. Подтвердите удаление, следуя инструкциям на экране.

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

Статистика использования проекта

В этом разделе пользователь может просматривать статистику по использованию Deckhouse Observability Platform. Отображаются данные только для текущего проекта, они представлены в виде различных графиков и метрик, позволяющих оценить производительность и объёмы данных.

Метрики проекта

  • «Metrics: Active Series» — количество активных серий. Активная серия — это количество уникальных метрик, поступивших за последние два часа.
  • «Metrics: Raw incoming rate» — входящий поток метрик в секунду. На этом графике отображаются данные после дедупликации.
  • «Metrics: Total count of samples» — суммарное количество сэмплов, хранящихся в долгосрочном хранилище. Сэмпл — это отдельное значение метрики, собранное в определённый момент времени.
  • «Metrics: Discarded samples» — ошибки при записи серий. Возможные причины ошибок включают:
    • sample_out_of_bounds — сэмпл находится за пределами допустимого диапазона значений;
    • sample_out_of_order — сэмпл пришёл в неправильном порядке;
    • sample_too_old — сэмпл слишком старый и не принимается системой;
    • sample_too_far_in_future — сэмпл находится слишком далеко в будущем;
    • new_value_for_timestamp— попытка записи другого значения для тех же временных меток;
    • per_user_series_limit — превышен лимит скорости поступления метрик для проекта;
    • metric_series_limit — превышен лимит связанный с метрикой.
  • «Metrics: Storage usage» — объём пространства на диске, занимаемого метриками в долгосрочном хранилище.

Логи проекта

  • «Logs: Raw incoming rate» — входящий поток логов.
  • «Logs: Discarded samples» — ошибки при записи логов. Возможные причины ошибок включают:
    • rate_limited — превышен лимит скорости, установленный для записи;
    • stream_limit — превышен лимит на количество потоков;
    • label_name_too_long — длина имени метки превышает допустимый лимит;
    • label_value_too_long — длина значения метки превышает допустимый лимит;
    • line_too_long — длина строки превышает допустимый лимит;
    • max_label_names_per_series — превышен лимит на количество имён меток в серии;
    • per_stream_rate_limit — превышен лимит на скорость записи в поток.
  • «Logs: Storage usage» — объём пространства на диске, занимаемого логами.

Пользователи проекта

В этом разделе пользователь может просматривать список пользователей, имеющих доступ к текущему проекту. Возможности управления пользователями зависят от типа аутентификации, настроенного в Deckhouse Observability Platform.

Внешняя аутентификация пользователя проекта

Если в Deckhouse Observability Platform включена аутентификация с помощью внешних систем (например, LDAP, OAuth и др.), то в этом разделе доступен только просмотр списка пользователей.

Внутренняя аутентификация пользователя проекта

Если в Deckhouse Observability Platform используется внутренняя аутентификация (email и пароль), в этом разделе доступны дополнительные возможности управления пользователями:

  • удаление пользователей — возможность удалить пользователей из системы;
  • изменение роли пользователя — возможность изменить роль пользователя. Подробнее о ролевой модели можно узнать в соответствующем разделе документации.

API-токены пользователя проекта

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

Просмотр списка API-токенов пользователя проекта

Пользователь может просматривать список всех API токенов, выпущенных для текущего проекта. Это позволяет контролировать токены и предотвращать несанкционированный доступ.

Перевыпуск токена пользователя проекта

Для перевыпуска токена:

  • найдите нужный токен в списке;
  • нажмите кнопку «Перевыпустить токен».

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

Создание токена для пользователя проекта

Для создания нового API-токена выполните следующие шаги:

  • нажмите кнопку «Добавить»;
  • заполните необходимые поля:
    • «Название» — укажите название для токена, описывающее его назначение (например, Токен для Prometheus remote write);
    • «Срок действия» — определяет время, в течение которого токен остаётся действительным:
      • «Дата» — укажите конкретную дату и время, до которых токен будет действителен. По истечении этого времени токен перестаёт быть действительным;
      • «Бессрочный» — если дата не указана, токен остаётся действительным до тех пор, пока не будет удалён;
    • «Права» — выберите комбинацию прав доступа, соответствующую требуемому набору прав. Подробнее о ролевой модели можно узнать в соответствующем разделе документации;
    • «Область действия»: определяет, на какие сущности системы (организации, рабочие пространства и проекты) будет распространяться действие токена.

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

  • имеют ограничение только на чтение мониторинговых данных из выбранной области действия;
  • обеспечивают доступ к данным всех проектов в рамках указанной области;
  • запросы с использованием мультитенантного токена выполняются на всём объёме данных проектов в выбранной области, предоставляя комплексный доступ к мониторинговой информации.

Редактирование токена пользователя проекта

Для редактирования существующего токена выполните следующие шаги:

  • найдите нужный токен в списке;
  • нажмите кнопку «Редактировать»;
  • внесите необходимые изменения:
    • измените название токена;
    • обновите срок действия или задайте его, если он не был установлен;
    • измените область действия или права.

Удаление токена пользователя проекта

Для удаления существующего токена выполните следующие шаги:

  • найдите нужный токен в списке;
  • нажмите кнопку «Удалить».

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

Источник данных

В разделе «Источник данных» пользователь может просматривать, создавать, редактировать и удалять дополнительные источники данных. Источники данных позволяют подключать данные из внешних систем или получать данные из нескольких проектов, используя мультитенантные API-токены. На данный момент поддерживаются следующие системы:

  • Prometheus;
  • Loki;
  • Elasticsearch;
  • Postgres;
  • MySQL.

Создание источника данных

Для добавления нового источника данных выполните следующие шаги:

  • нажмите кнопку «Добавить»;

  • заполните необходимые поля:

    • «Название» — название источника данных. Это название будет отображаться в разделе «Просмотр данных» и доступно при создании дашбордов в качестве доступного datasource;

    • «Тип» — тип источника данных из доступного списка (Prometheus, Loki, Elasticsearch, Postgres, MySQL);

    • «Базовая авторизация» — необходимость базовой авторизации для подключения к источнику данных;

    • «Пользователь» — имя пользователя для авторизации (если применимо);

    • «Ссылка» — URL-адрес для подключения к источнику данных;

    • «Редактировать dataJson» — параметры конфигурации в формате JSON. Например, для Prometheus:

      {
  "timeInterval":"30s
}

    • «Редактировать secureJsonData» — параметры конфигурации безопасности в формате JSON. Например, для Prometheus:

      {
  "basicAuthPassword": "password"
}

  • нажмите кнопку «Добавить», чтобы сохранить новый источник данных.

Удаление источника данных

Для удаления существующего источника данных выполните следующие шаги:

  • найдите нужный источник данных в списке;
  • нажмите кнопку «Удалить»;
  • подтвердите удаление, следуя инструкциям на экране.

Редактирование источника данных

Для редактирования существующего источника данных выполните следующие шаги:

  • найдите нужный источник данных в списке;
  • нажмите кнопку «Редактировать»;
  • внесите необходимые изменения в поля;
  • нажмите кнопку «Сохранить».

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

Примеры конфигурации источников данных

Этот раздел содержит инструкции по настройке различных систем для отправки данных (метрик или логов) в Deckhouse Observability Platform. Набор инструкций может отличаться в зависимости от конфигураций установки, таких как наличие хранилища логов или поддержка opAgent.

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

PostgreSQL

Смотрите документацию PostgreSQL data source для получения подробной информации.

  • Тип: postgres

jsonData:

{
  "connMaxLifetime": 14400,
  "database": "database_name",
  "maxIdleConns": 100,
  "maxIdleConnsAuto": true,
  "maxOpenConns": 100,
  "postgresVersion": 1400,
  "sslmode": "disable"
}

secureJsonData:

{"basicAuthPassword": "password"}
Elasticsearch

Смотрите документацию Elastic search для получения подробной информации.

  • Тип: elasticsearch

jsonData:

{
    "includeFrozen": false,
    "index": "mindex",
    "logLevelField": "",
    "logMessageField": "",
    "maxConcurrentShardRequests": 5,
    "timeField": "date"
}

Базовая авторизация:

  • установите галочку «Use basic auth» в положение true;
  • заполните поле «Username».

secureJsonData:

{"basicAuthPassword": "password"}

Сертификат:

Добавьте в jsonData:

{
    ...
    "oauthPassThru": false,
    "serverName": "server_name",
    "sigV4Auth": false,
    "tlsAuth": true,
    "tlsAuthWithCACert": false,
    "tlsSkipVerify": true
}

Добавьте сертификат и PEM-файл в secureJsonData:

{
    ...
    "basicAuthPassword": "password",
    "tlsClientCert": "certificate content",
    "tlsClientKey": "PEM file content"
}
Prometheus

Смотрите документацию Prometheus data source grafana для получения подробной информации.

  • Тип: prometheus

jsonData:

{
  "httpMethod": "POST",
  "manageAlerts": true,
  "prometheusType": "Prometheus",
  "prometheusVersion": "2.44.0",
  "incrementalQueryOverlapWindow": "10m"
}

Пример добавления источника для доступа к данным нескольких проектов Deckhouse Observability Platform

jsonData:

{
  "manage_alerts": "false",
  "time_interval": "30s",
  "prometheus_type": "Mimir",
  "http_header_name1": "X-Auth-Token",
  "prometheus_version": "2.4.0"
}

secureJsonData:

{
  "http_header_value1": "<TOKEN_FOR_READING_METRICS>"
}

Предварительно необходимо создать API-токен с доступом к требуемым проектам.

Настройки основных параметров проекта

В разделе «Настройки» пользователи могут управлять основными параметрами проекта, такими как изменение названия или удаление. Это предоставляет администраторам возможность поддерживать актуальность данных и при необходимости осуществлять удалении проектов.

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

Изменение названия проекта

Для изменения названия проекта выполните следующие шаги:

  • перейдите в раздел «Настройки»;
  • найдите поле «Название проекта»;
  • введите новое название для проекта;
  • нажмите кнопку «Сохранить».

Удаление проекта

Для удаления проекта выполните следующие шаги:

  • перейдите в раздел «Настройки»;
  • нажмите кнопку «Удалить»;
  • подтвердите удаление, следуя инструкциям на экране.

Важно: удаление проекта приведёт к удалению всех связанных данных, метрик и логов, дашбордов и триггеров. Все интеграции, связанные с этим проектом, перестанут работать. Будьте осторожны и убедитесь, что вы хотите удалить проект, прежде чем подтверждать действие.

Настройка лимитов

Каждый проект в Deckhouse Observability Platform имеет настройки лимитирования ресурсов, что позволяет квотировать и планировать ресурсы для всей системы.

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

Метрики лимитов

Лимиты записи
  • ingestion_rate:
    • Определяет максимальное количество сэмплов, которые могут быть записаны в секунду для одной серии. При достижении этого лимита система проверяет значение, установленное в параметре ingestion_burst_size.
    • Значение по умолчанию: 1,000,000.
  • ingestion_burst_size:
    • Устанавливает максимально допустимое превышение для ingestion_rate. Это значение должно быть равно или превышать ingestion_rate, так как оно представляет собой абсолютное ограничение. При превышении этого лимита Okmeter Хранилище возвращает HTTP-код 400 на POST-запрос к /api/v1/push.
    • Значение по умолчанию: 1,100,000.
  • max_global_series_per_user:
    • Задаёт общий максимальный лимит активных серий для проекта. Серии считаются активными, если они были добавлены в течение последних 2 часов. При достижении этого лимита Okmeter Хранилище возвращает HTTP-код 400 на POST-запрос к /api/v1/push.
    • Значение по умолчанию: 1,000,000.
  • max_global_series_per_metric:
    • Устанавливает лимит на максимальное количество активных серий по имени метрики на уровне всего кластера до его репликации. При превышении этого лимита Okmeter Хранилище возвращает HTTP-код 400 на POST-запрос к /api/v1/push.
    • Значение по умолчанию: 20,000.
  • max_global_exemplars_per_user:
    • Определяет максимальное количество уникальных exemplars, которые могут быть записаны для одного проекта.
    • Значение по умолчанию: Не ограничено (0).
Лимиты чтения
  • max_total_query_length:
    • Ограничивает общий временной диапазон запроса, определяемый разницей между конечным и начальным временем. Этот лимит применяется до шардирования запроса по времени.
    • Значение по умолчанию: Не ограничено (0s).
  • max_partial_query_length:
    • Ограничивает временной диапазон для подзапросов, полученных в результате шардирования исходного запроса. Значение этого параметра должно быть меньше или равно значению max_total_query_length.
    • Значение по умолчанию: Не ограничено (0s).
  • max_fetched_chunk_bytes_per_query:
    • Задаёт максимальный размер в байтах всех блоков данных, который может быть получен запросом от каждого компонента ingester и хранилища S3.
    • Значение по умолчанию: Не ограничено (0).
  • max_fetched_series_per_query:
    • Определяет максимальное количество уникальных серий, которое может быть возвращено в ответ на запрос.
    • Значение по умолчанию: 100,000.
Лимиты для Alert и Record Rules
  • ruler_max_rule_groups_per_tenant:
    • Определяет максимальное количество rule groups, доступных для каждого проекта. Фактическое количество правил, которое может быть установлено для проекта, равно произведению ruler_max_rule_groups_per_tenant на ruler_max_rules_per_rule_group. Рекомендуется корректировать это значение в зависимости от количества экземпляров Ruler в вашей системе.
    • Значение по умолчанию: 35.
  • ruler_max_rules_per_rule_group:
    • Определяет максимальное количество правил в каждой rule group. Ограничение количества правил в каждой группе помогает равномерно распределять нагрузку между экземплярами Ruler и обеспечивать более эффективное использование ресурсов.
    • Значение по умолчанию: 50.
Лимиты отправки уведомлений
  • alertmanager_notification_rate_limit:
    • Определяет максимальное количество уведомлений (учитывается общее количество уведомлений по всем каналам доставки) в проекте, которое может быть отправлено в секунду.
    • Значение по умолчанию: 0 (не ограничено).
Глубина хранения данных
  • compactor_blocks_retention_period:
    • Определяет срок, в течение которого данные будут храниться.
    • Значение по умолчанию: 400 дней.

Логи лимитов

Лимиты записи логов
  • ingestion_rate_mb:
    • Ограничивает скорость записи логов в мегабайтах в секунду.
  • ingestion_burst_size_mb:
    • Устанавливает максимально допустимое превышение для ingestion_rate_mb.
  • per_stream_rate_limit:
    • Ограничивает скорость записи данных в конкретный поток логов.
  • per_stream_rate_limit_burst:
    • Устанавливает максимально допустимое превышение для per_stream_rate_limit.
Лимиты чтения логов
  • max_chunks_per_query:
    • Определяет максимальное количество блоков данных, которые могут быть возвращены в результате одного запроса.
  • max_streams_per_user:
    • Определяет максимальное количество потоков логов, которые могут быть возвращены в результате одного запроса для одного пользователя.
  • max_entries_limit_per_query:
    • Определяет максимальное количество записей логов, которые могут быть возвращены в результате одного запроса.
  • max_query_length:
    • Ограничивает временной диапазон запроса логов.
  • max_queriers_per_tenant:
    • Ограничивает количество запросов, которые могут выполняться одновременно для одного проекта.
Глубина хранения логов
  • retention_period:
    • Определяет срок, в течение которого данные логов будут храниться.
    • Значение по умолчанию: 14 дней.

Веб-интерфейс администратора

Общие настройки

Любые изменения в этом пункте меню можно проводить только по согласованию со специалистами «Фланта».

В этом пункте меню указываются различные feature flags-параметры для включения и выключения различных функциональностей системы. В большинстве случаев производить изменения в этом разделе не требуется.

Базовые лимиты

Каждый проект в Deckhouse Observability Platform имеет настройки лимитирования ресурсов, что позволяет квотировать и планировать использование ресурсов в системе.

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

Важно: изменение базовых лимитов может повлиять на работу всех проектов, использующих эти настройки. Убедитесь в правильности внесённых изменений перед сохранением.

Базовые лимиты метрик

Лимиты записи метрик
  • ingestion_rate:
    • Определяет максимальное количество сэмплов, которые могут быть записаны в секунду для одной серии. При достижении этого лимита система проверяет значение, установленное в параметре ingestion_burst_size.
    • Значение по умолчанию: 1,000,000.
  • ingestion_burst_size:
    • Устанавливает максимально допустимое превышение для ingestion_rate. Это значение должно быть равно или превышать ingestion_rate, так как оно представляет собой абсолютное ограничение. При превышении этого лимита Okmeter Хранилище возвращает HTTP-код 400 на POST-запрос к /api/v1/push.
    • Значение по умолчанию: 1,100,000.
  • max_global_series_per_user:
    • Задаёт общий максимальный лимит активных серий для проекта. Серии считаются активными, если они были добавлены в течение последних 2 часов. При достижении этого лимита Okmeter Хранилище возвращает HTTP-код 400 на POST-запрос к /api/v1/push.
    • Значение по умолчанию: 1,000,000.
  • max_global_series_per_metric:
    • Устанавливает лимит на максимальное количество активных серий по имени метрики на уровне всего кластера до его репликации. При превышении этого лимита Okmeter Хранилище возвращает HTTP-код 400 на POST-запрос к /api/v1/push.
    • Значение по умолчанию: 20,000.
  • max_global_exemplars_per_user:
    • Определяет максимальное количество уникальных exemplars, которые могут быть записаны для одного проекта.
    • Значение по умолчанию: Не ограничено (0).
Лимиты чтения метрик
  • max_total_query_length:
    • Ограничивает общий временной диапазон запроса, определяемый разницей между конечным и начальным временем. Этот лимит применяется до шардирования запроса по времени.
    • Значение по умолчанию: Не ограничено (0s).
  • max_partial_query_length:
    • Ограничивает временной диапазон для подзапросов, полученных в результате шардирования исходного запроса. Значение этого параметра должно быть меньше или равно значению max_total_query_length.
    • Значение по умолчанию: Не ограничено (0s).
  • max_fetched_chunk_bytes_per_query:
    • Задаёт максимальный размер в байтах всех блоков данных, который может быть получен запросом от каждого компонента ingester и хранилища S3.
    • Значение по умолчанию: Не ограничено (0).
  • max_fetched_series_per_query:
    • Определяет максимальное количество уникальных серий, которое может быть возвращено в ответ на запрос.
    • Значение по умолчанию: 100,000.
Лимиты для Alert и Record Rules
  • ruler_max_rule_groups_per_tenant:
    • Определяет максимальное количество rule groups, доступных для каждого проекта. Фактическое количество правил, которое может быть установлено для проекта, равно произведению ruler_max_rule_groups_per_tenant на ruler_max_rules_per_rule_group. Рекомендуется корректировать это значение в зависимости от количества экземпляров Ruler в вашей системе.
    • Значение по умолчанию:35.
  • ruler_max_rules_per_rule_group:
    • Определяет максимальное количество правил в каждой rule group. Ограничение количества правил в каждой группе помогает равномерно распределять нагрузку между экземплярами Ruler и обеспечивать более эффективное использование ресурсов.
    • Значение по умолчанию: 50.
Лимиты отправки уведомлений
  • alertmanager_notification_rate_limit:
    • Определяет максимальное количество уведомлений (учитывается общее количество уведомлений по всем каналам доставки) в проекте, которое может быть отправлено в секунду.
    • Значение по умолчанию: 0 (не ограничено).
Глубина хранения метрик
  • compactor_blocks_retention_period:
    • Определяет срок, в течение которого данные будут храниться.
    • Значение по умолчанию: 400 дней.

Базовые лимиты логов

Лимиты записи логов
  • ingestion_rate_mb:
    • Ограничивает скорость записи логов в мегабайтах в секунду.
  • ingestion_burst_size_mb:
    • Устанавливает максимально допустимое превышение для ingestion_rate_mb.
  • per_stream_rate_limit:
    • Ограничивает скорость записи данных в конкретный поток логов.
  • per_stream_rate_limit_burst:
    • Устанавливает максимально допустимое превышение для per_stream_rate_limit.
Лимиты чтения логов
  • max_chunks_per_query:
    • Определяет максимальное количество блоков данных, которые могут быть возвращены в результате одного запроса.
  • max_streams_per_user:
    • Определяет максимальное количество потоков логов, которые могут быть возвращены в результате одного запроса для одного пользователя.
  • max_entries_limit_per_query:
    • Определяет максимальное количество записей логов, которые могут быть возвращены в результате одного запроса.
  • max_query_length:
    • Ограничивает временной диапазон запроса логов.
  • max_queriers_per_tenant:
    • Ограничивает количество запросов, которые могут выполняться одновременно для одного проекта.
Глубина хранения логов
  • retention_period:
    • Определяет срок, в течение которого данные логов будут храниться.
    • Значение по умолчанию: 14 дней.

Настройка маппинга ролей

Этот раздел доступен при использовании внешней аутентификации.

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

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

Кластер

Любые изменения в этом пункте меню можно проводить только по согласованию со специалистами «Фланта».

В этом разделе перечислены кластеры, которые добавлены в систему репликации конфигурации. Если выбран вариант установки «катастрофоустойчивый», здесь может быть более одного кластера. Каждый кластер представляет собой отдельную установку системы, чаще всего размещённую в отдельном центре обработки данных (ЦОД).

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

Пользователи

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

Важно: изменение связей пользователей, ролей и сущностей системы происходит в момент авторизации пользователя. Поэтому при изменении маппинга пользователю (или пользователям) требуется выйти и зайти заново в систему.

Аудит логов

Раздел «Аудит логов» позволяет просматривать и анализировать журнал аудита, содержащий записи обо всех изменениях, происходящих в системе. Это включает в себя изменения объектов, действий пользователей и источников изменений. Анализ этих логов помогает отслеживать безопасность и целостность системы, а также выявлять любые подозрительные действия.

Фильтры для просмотра аудит логов

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

Доступные параметры фильтрации:

  • «ID объекта» — уникальный идентификатор объекта;
  • «Тип объекта» — тип объекта для фильтрации (например, проект, пользователь, роль и т. д.);
  • «Создано с» — начальная дата и время для периода поиска (формат: dd.mm.yyyy, –:–);
  • «Создано до» — конечная дата и время для периода поиска (формат: dd.mm.yyyy, –:–);
  • «ID пользователя» — уникальный идентификатор пользователя;
  • «Источник изменений» — источник изменений (если известен);
  • «Действие» — тип действия (например, создание, редактирование, удаление);
  • «Измененное поле» — конкретное поле, изменения в котором вы хотите просмотреть;
  • «Измененное значение» — конкретное значение, на которое было изменено поле.