Перейти к содержанию

Эксплуатация и мониторинг

Резервное копирование и восстановление

Резервное копирование

Для резервного копирования AppSec.Track достаточно сделать копию базы данных PostgreSQL любым наиболее подходящим для вас способом. Например, можно использовать следующий официальный способ бэкапирования:

pg_dump dbname > dumpfile

Восстановление из резервной копии

Для восстановления AppSec.Track из резервной копии можно использовать любой наиболее подходящий для вас инструмент для восстановления базы данных PostgreSQL. Например, можно использовать следующий официальный способ восстановления:

psql dbname < dumpfile

Подробнее с дополнительными возможностями использования приведенных в данном разделе команд можно ознакомиться на странице официальной документации PostgreSQL.

Логирование

Начиная с версии 3.20.0, Система логирует события бэкендов в формате CEF, совместимом с Syslog, для SIEM-систем.

Описание настроек SIEM приведено в соответствующем разделе.

Логи записываются в отдельные файлы для каждого бэкенда.

Система логирует события двух типов:

  1. Действия пользователей.
  2. События OSA.

Логи располагаются в директории бэкенда, в общем случае:

<backend_directory>/logs/<log_name>.log

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

CEF:0|AppSec Solutions|AppSec.Track|3.20|15|User Event|6|start=2025-07-01T14:30:45Z src=192.168.1.100 suid=42 act=RULE changed () oldValue= newValue={\"id\":695,\"host\":\"184.118.240.71\",\"port\":9999,\"login\":\"1sb9MjLbs8\"} objectId=2358 objectType=RULE

Перечень логируемых событий:

  • PLUGIN changed
  • PLUGIN created
  • PLUGIN deleted
  • PROXY changed
  • PROXY created
  • PROXY deleted
  • REPO changed
  • REPO deleted
  • ROLE changed
  • ROLE created
  • ROLE deleted
  • ROLE_AUTHORITY changed
  • RULE changed
  • RULE created
  • RULE deleted
  • RULE_DISABLED changed
  • RULE_DISABLED created
  • RULE_DISABLED deleted
  • RULE_EXCLUSION changed
  • RULE_EXCLUSION created
  • USER changed
  • USER created
  • USER deleted
  • USER logout
  • USER login

Метрики в Prometheus/Grafana

Начиная с версии 3.16.0, Система предоставляет данные для метрик в формате, совместимом с Prometheus/Grafana.

Настройка

Для того чтобы начать работу с метриками, необходимо обновить Систему до версии 3.16.0 или выше (см. раздел «Обновление 3.15.0 до 3.16.0» для Docker или Kubernetes).

После обновления метрики станут доступны в Prometheus.

Для отображения метрик в Grafana можно использовать базовый дашборд JVM Micrometer. Этот дашборд «из коробки» будет работать только с метриками /actuator/prometheus. Чтобы были видны остальные метрики, необходимо провести кастомизацию дашборда.

Список метрик

  1. Список активных метрик в /actuator:

    • GET /actuator - вывод всех доступных endpoints метрик.
    • GET /actuator/metrics - вывод всех доступных метрик.
    • GET /actuator/health - состояние всех сервисов.
    • GET /actuator/prometheus - доступные метрики в формате Prometheus.
    • GET /actuator/info - общие сведения о приложении: версия, дата билда, имя билда.

  2. Основные метрики о состоянии БД PotgreSQL:

    • GET /actuator/health/r2bdc - состояние PostgreSQL (status, version).

    a. Группа метрик о состоянии БД PotgreSQL:

    • GET /actuator/metrics/r2dbc.pool.acquired
    • GET /actuator/metrics/r2dbc.pool.allocated
    • GET /actuator/metrics/r2dbc.pool.idle
    • GET /actuator/metrics/r2dbc.pool.max.allocated
    • GET /actuator/metrics/r2dbc.pool.max.pending
    • GET /actuator/metrics/r2dbc.pool.pending

    b. Группа метрик о состоянии БД PotgreSQL в формате Promeheus:

    • GET //prometheus?includedNames=r2dbc_pool_...

  3. Основные метрики о состоянии Redis:

    • GET /actuator/health/redis - состояние Redis (status, version)

    a. Группа метрик о состоянии Redis:

    • GET /actuator/metrics/lettuce.command.completion
    • GET /actuator/metrics/lettuce.command.firstresponse

    b. Группа метрик о состоянии Redis в формате Promeheus:

    • GET /actuator/prometheus?includedNames=lettuce_command_...

  4. Используемые оперативная память / дисковое пространство:

    • GET /actuator/health/diskSpace - состояние дискового пространства.

    a. Группа метрик с информацией о дисковом пространстве:

    • GET /actuator/metrics/disk.free - свободное место на диске в байтах.
    • GET /actuator/metrics/disk.total - общий размер дискового пространства в байтах.

    b. Группа метрик с информацией об оперативной памяти:

    • GET /actuator/metrics/jvm.memory.used - используемый объем оперативной памяти в байтах.
    • GET /actuator/metrics/jvm.memory.max - выделенный объем оперативной памяти в байтах.
    • GET /actuator/metrics/jvm.memory.committed - подтвержденный объем оперативной памяти в байтах.
    • GET /actuator/metrics/jvm.memory.usage.after.gc - объем оперативной памяти после работы Garbage collection в %.

    c. Группа метрик с информацией о дисковом пространстве в формате Promeheus:

    • GET /actuator/prometheus?includedNames=disk_total_bytes,disk_free_bytes - где disk_total_bytes - общий размер диска, disk_free_bytes - свободное место на диске.

    d. Группа метрик с информацией об оперативной памяти в формате Promeheus:

    • GET /actuator/prometheus?includedNames=jvm_memory_used_bytes,jvm_memory_committed_bytes,jvm_memory_max_bytes,jvm_memory_usage_after_gc_percent - описание см. выше в пункте 3.b.

  5. Текущий используемый URL Сервиса данных (Track.Feed):

    • GET /actuator/metrics/actual_feed_core_url - информация об актуальном адресе Сервиса данных.
    • GET /actuator/actuator/prometheus?includedNames=actual_feed_core_url - информация об актуальном адресе Сервиса данных (feed) в формате Prometheus.

  6. Количество запросов в Сервис данных:

    • GET /actuator/metrics/history_log_count - количество запросов.
    • GET /actuator/prometheus?includedNames=history_log_count - количество запросов в формате Promeheus.

  7. Остальные метрики:

    • GET /actuator/metrics/logback.events - количество событий в логах приложения по уровням: warn, trace, debug, error, info.
    • GET /actuator/metrics/system.cpu.count - информация о процессоре. Количество процессоров.
    • GET /actuator/metrics/system.cpu.usage - информация о процессоре. Загруженность процессора.

Кеширование ответов Track.Feed

При большом количестве последовательных запросов и/или низком качестве сетевого соединения возможно заметное снижение производительности AppSec.Track. Во избежание этого для кеширования ответов Track.Feed используется Redis.

Примечание

Время хранения данных в кеше — 24 часа. При создании/удалении/редактировании политик, исключений, правил, пользователей, ролей и изменении настроек сервиса данных происходит очистка кеша.

При необходимости кеш можно очистить принудительно следующими способами:

  1. В пользовательском интерфейсе AppSec.Track с помощью кнопки Сбросить кэш на вкладке Сервис данных на странице Настройки.

  2. Через API, выполнив следующий запрос: 

    curl --location '<<Track_BASE_URL>>/api/cache/reset' --header 'Cookie: X-Auth=<<Cookie_auth>>'

  3. В браузере в пользовательском интерфейсе AppSec.Track после авторизации можно перейти на страницу по ссылке: <<Track_BASE_URL>>/api/cache/reset. После этого система автоматически вернется на главную страницу пользовательского интерфейса AppSec.Track, а кеш будет очищен.

В качестве минимально рекомендуемых можно рассматривать следующие параметры.

resources:
    limits:
        cpu: 250m
        memory: 2Gi
    requests:
        cpu: 50m
        memory: 64Mi

Примечание

Объем виртуальной памяти, выделяемой для Redis, не должен превышать объем физической памяти, в противном случае возможно существенное снижение производительности.

Примечание

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

Отключение кеширования

  1. В конфигурационном файле application-prod.yml удалите следующие строки.

    redis:
    host: ${TRACK_REDIS_HOST}
    port: ${TRACK_REDIS_PORT}
    connect-timeout: 500ms
    timeout: 500ms
    client-type: lettuce
    lettuce:
        pool:
            min-idle: 1

  2. В конфигурационном файле docker-compose.yml удалите следующие строки.

    appsec-track-redis:
    container_name: appsec-track-redis
    hostname: appsec-track-redis
    image: ${redis_image}
    ports:
        - "6379"
    networks:
        - track_net
    volumes: 
        - ./redis/data:/data
    environment:
        - TZ=Europe/Moscow      
    restart: always

Настройка параметров Java

Инструкция по добавлению параметров Java в docker-compose.yml

  1. Откройте файл docker-compose.yml и добавьте строку с параметрами Java в секцию appsec-track-backend.environment.

    services:
    ...
    appsec-track-backend:
        environment:
            - TZ=Europe/Moscow
            - pgsql_url=${pgsql_url}
            ...
            # Параметры Java: начальный размер кучи (-Xms)
            # и максимальный размер кучи (-Xmx)
            - JAVA_TOOL_OPTIONS=-Xms2g -Xmx4g

    Важно:

    • Не используйте кавычки вокруг значения (иначе Java воспримет строку как один аргумент).
    • Максимальный размер кучи (-Xmx) не должен превышать лимит памяти контейнера. Если для контейнера указан лимит памяти в секции deploy.resources.limits.memory, то -Xmx должен быть меньше этого лимита. Рекомендуется оставлять запас 20-30% от лимита для других нужд JVM (Metaspace, стеки потоков, code cache) и операционной системы внутри контейнера.

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

    docker-compose down
docker-compose up -d

Инструкция по добавлению параметров Java в Helm-чарт

  1. Откройте файл values.yaml в директории Helm-чарта.

  2. Найдите секцию backend, раскомментируйте параметр java_tool_options и укажите необходимые параметры.

    backend:
    ...
    resources: {}
    # Параметры Java: начальный размер кучи (-Xms)
    # и максимальный размер кучи (-Xmx)
    java_tool_options: "-Xms2g -Xmx4g"
    ...

    Важно:

    • В Helm-чарте значение должно быть в кавычках, так как это строка YAML, которая будет передана как переменная окружения JAVA_TOOL_OPTIONS.
    • Максимальный размер кучи (-Xmx) не должен превышать лимит памяти контейнера. Если для контейнера указан лимит памяти в секции backend.resources.limits.memory, то -Xmx должен быть меньше этого лимита. Рекомендуется оставлять запас 20-30% от лимита для других нужд JVM (Metaspace, стеки потоков, code cache) и операционной системы внутри контейнера.

  3. После изменения примените обновления:

    helm upgrade <release-name> <chart-path> -f values.yaml

    или, если используете helm install:

    helm install <release-name> <chart-path> -f values.yaml