Часто встречающиеся проблемы и пути их устранения#

Порядок контроля компонентов Platform V Audit SE (AUD) и методы решения их проблем#

Контроль Cloudera Manager и HDFS#

Контроль того, с какой скоростью заканчивается место на HDFS.

Необходим инфраструктурный мониторинг или регулярный контроль метрики для HDFS в Cloudera Manager.

  1. Выставить оповещение при заполнении 60% места на HDFS. Для этого:

    1. Выполнить анализ роста нагрузки за последние два месяца: Для этого можно выполнить команды на HDFS, указав правильные месяцы hdfs dfs -du -h -s /events_avro/2022-12* hdfs dfs -du -h -s/events_avro/2022-11* В результате выполнения будет размер папок на HDFS по суткам (чистые данные и отреплицированные). Оценить скорость заполнения, рассчитать на сколько дней хватит оставшегося хранилища.

      Если хранилища хватит менее чем на полгода, то необходимо:

      1. Если нагрузка росла равномерно и была запланирована, то необходимо заказать серверы с ролью DataNode, по характеристикам идентичные включенным в кластер. Количество серверов должно быть таким, чтобы свободного места хватило минимум на полгода. При учете дискового пространства новых серверов учитывать их, разделив на 3 (фактор репликации на HDFS).

      2. После получения серверов, включить их в кластер Hadoop, выполнить рестарт кластера (временно будет прекращен доступ на чтение данных через UI).

      3. Установить на новых серверах роль HDFSDataNode.

      4. Запустить процедуру ребаланса HDFS.

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

      1. Внедрение новых серверов АС, подключенных к Platform V Audit SE (AUD).

      2. Внедрение новой функциональности АС, которая повлекла рост нагрузки на Platform V Audit SE (AUD). При необходимости, отключить аудит этих АС (через перекрытие в PACMAN).

      3. Определить модули, от которых идет максимальная нагрузка. Это можно сделать с помощью запросов к Solr через SolrServer WEB UI, с фасетным поиском по module (включить флаг facet и заполнить поле facet.field значением module). Результаты поиска необходимо сообщить владельцу Platform V Audit SE (AUD) для дальнейших выяснений причин нагрузки модулей из верхней части списка.

  2. Выставить оповещение при заполнении 80%.

    Действия аналогичны оповещению о 60% с той лишь разницей, что сначала требуется заказать серверы, а затем выполнять анализ.

Контроль проблем с серверами Cloudera#

Контроль процесса утилизации RAM на NameNode. Требуется, чтобы не возникло ограничение записи на HDFS.

Необходим инфраструктурный мониторинг или контроль метрики RAM для серверов с ролью NameNode, Secondary NameNode, StandBy NameNode в Cloudera Manager.

Необходимо выставить предупреждение при достижении 80% использования RAM серверов Cloudera.

Действия по решению проблемы:

  • Обратиться к владельцу Platform V Audit SE (AUD) для получения утилиты уплотнения файлов данных на HDFS.

  • Это позволит множество маленьких файлов уплотнить в большие (приведет к уменьшению количества файлов HDFS) и, как следствие, использование RAM сервисом HDFS NameNode.

Контроль Kafka#

  1. Контроль того, справляется ли Kafka со входящим потоком и хватает ли дискового пространства.

    Для этого нужно выставить регулярные оповещения при заполнении 60% или 80% дисков.

    Выполнить следующие действия:

    1. Определить топики, содержащие максимальный объем данных. Определить значение retention.hours для данных топиков. Совместно с владельцем Platform V Audit SE (AUD) рассмотреть возможность временного уменьшения значения retention.hours для данных топиков.

    2. Определить, что дает максимальную нагрузку. Если нагрузка идет на топики вида audit-global-*, то нужно выполнить запрос к Solr через SolrServer WEB UI с фасетным поиском по module (включить флаг facet и заполнить поле facet.field значением module). Результаты поиска необходимо сообщить владельцу Platform V Audit SE (AUD) для дальнейших выяснений причин нагрузки модулей из верхней части списка. Если нагрузка идет на другие топики, то необходимо совместно с владельцем Platform V Audit SE (AUD) определить критерии для выполнения анализа.

    3. Если нагрузка возросла планово, то выполнить заказ серверов для добавления в кластер Corax (Kafka), по характеристикам аналогичные имеющимся. После получения дополнительных серверов с ПО Kafka той же версии, необходимо сконфигурировать server.properties аналогично имеющимся брокерам.

  2. Контроль входящего потока сообщений (tps, ГБ/сутки)

    Если есть превышение tps сверх заявленного по SLA (5000 tps), то требуется:

    1. Анализ метрик брокеров Kafka.

    2. Превышение метрики tps на панели «SLA»

    Выяснить утилизацию HDD, CPU, RAM. Совместно с владельцем Platform V Audit SE (AUD) рассмотреть включение throttling. Рассмотреть необходимость заказа дополнительных серверов. Само по себе превышение tps не является плохим индикатором, нужно смотреть метрики характеризующие пропускную способность сервиса и наполнение хранилища.

  3. Контроль исходящего потока сообщений (количество в единицу времени, lags)

    Контроль доступен на панели «Метрики компонента Pipeline» Если метрики CurrentLagPerFlumeNode превышают значение 3.000.000, выполнить следующие действия:

    1. Предоставить логи всех сервисов Flume и значение метрики tps с панели «SLA» для владельца Platform V Audit SE (AUD) для сравнения скорости чтения и записи в Kafka.

    2. Наблюдать в течение суток состояние метрики на панели «Метрики компонента Pipeline» метрики CurrentLagPerFlumeNode. Определить минимальное и максимальное значение.

Контроль проблем с доступностью серверных метрик Cloudera#

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

  1. Убедитесь, что в PACMAN указаны корректные параметры.

  2. Проверьте корректность настройки jmx-портов на всех Flume. Для параметра audit2@flume.jmx.servers можно указать только один IP, на котором есть все агенты Flume, но нужно перечислить все порты всех Flume.

  3. Проверьте параметры подключения к Cloudera Manager:

audit2@cloudera.manager.server = IP сервера Cloudera (master node)
audit2@cloudera.manager.login = логин пользователя Cloudera
audit2@cloudera.manager.password = пароль пользователя Cloudera

  1. Проверьте подключение к Kafka и при необходимости исправьте порт для сбора метрик Kafka по jmx.

4.1 Используется один порт для всех брокеров, адреса брокеров указаны в audit2@kafka.consumer.bootstrap.servers:

audit2@kafka.bootstrap.servers.jmx.port = по умолчанию, если вы не меняли, 9876

4.2. Проверьте, что порт рабочий - telnet <kafka_ip> 9876. 4.3. Проверьте, что в PACMAN указан корректный jmx port Kafka: при старте Kafka в логах должна быть строчка: EXTRA_ARGS=${EXTRA_ARGS-'-name kafkaServer -loggc -Djava.rmi.server.hostname= -Dcom.sun.management.jmxremote.port=9876

Если используется другой порт, например, 7010, запишите его в конфигурацию audit2@kafka.bootstrap.servers.jmx.port.

  1. Для проверки подключения к Flume по jmx для сбора метрик, выполните следующие шаги:

5.1. Выберите один сервер в кластере Cloudera, на котором размещены и запущены все агенты всех Flume. Допустим это IP1.

5.2. Зайдите в конфигурацию jmx-портов и пропишите уникальные порты для каждого размещенного на этом сервере Flume:

Cloudera Manager > Flume-XXX > вкладка Configuration > Параметр Java Configuration Options for Flume Agent.

Должно быть прописано три строки:

-Dcom.sun.management.jmxremote.port=(уникальное значение для узла и для Flume)
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false

Cкрипты развертывания автоматически настраивают порты по правилу 12345, где вместо 12 автоматически ставится номер pipeline (например, для flume-export 26, для flume-solr 25), вместо 3 ставится порядковый номер кластера Kafka, вместо 45 порядковый номер Flume в списке всех Flume, подключенных к конкретному кластеру Kafka, описаны в файле inventory kafka-clusters-list.yml.

Пропишите такие порты, как если бы их прописывали скрипты:

CL0-Flume-Converter-V4-To-V6 20003
CL0-Flume-Export 26000
CL0-Flume-KeyValue 29001
CL0-Flume-PKB-Export 33002
CL0-Proxy-Converter-V5-to-V6 21004
CL0-Proxy-Flume-Hive-Event 22005
CL0-Proxy-Flume-Invalid-Message 23006
CL0-Proxy-Flume-Metamodel 24007
CL0-Proxy-Flume-Solr-Event 25008
CL0-Migration-Flume-Hive 27009

Аналогично для Flume, относящихся к кластеру Kafka СL1 и CL2, поставив в портах в третьем разряде вместо 0 числа 1 и 2 соответственно. Те Flume, по которым не нужно собирать метрики, можно не настраивать jmx-порт в целях экономии времени администратора.

5.3. Зайдите в PACMAN и укажите значения для параметра:

audit2@flume.jmx.servers=IP1:20003,IP1:26000,IP1:29001,IP1:33002,IP1:21004,IP1:22005,IP1:23006,IP1:24007,IP1:25008,IP1:27009

5.4. Выполните рестарт всех Flume на сервере IP1.

5.5. Выполните рестарт модуля UI (audit2-server-ear.ear) на WildFly.

5.6. Для удобства в панели Splunk укажите в поле "Сервер ТС Аудит" значение "IP_адрес_сервера_WildFly:1111", чтобы видеть только метрики, собираемые одним instance UI.

Контроль проблем с процессорами, оперативной памятью серверов для компонентов Platform V Audit SE (AUD)#

Контроль утилизации CPU, RAM серверов Hadoop, Kafka.

При срабатывании инфраструктурной метрики, предоставить владельцу Platform V Audit SE (AUD) соответствующие графики этой метрики.

Приоритетный порядок контроля серьезных проблем в компонентах Platform V Audit SE (AUD)#

В таблице приведены компоненты Platform V Audit SE (AUD) в приоритетном порядке их контроля при возникновении в них фатальных проблем:

Порядок контроля компонентов Platform V Audit SE (AUD)

Компонент Platform V Audit SE (AUD)

Приоритет

Комментарий

OpenShift

0

При недоступности proxy-приложения Platform V Audit SE (AUD) в OpenShift нет возможности регистрировать события аудита, работа АС блокируется

Kafka (Kafka) \ ZooKeeper (Kafka)

1

При регистрации синхронных событий работа модуля блокируется. Асинхронные события некоторое время могут сохраняться в локальном буфере. Далее возможна потеря событий Platform V Audit SE (AUD). Старт модулей, использующих Platform V Audit SE (AUD) невозможен

Сервисы Cloudera:
•ZooKeeper;
•Flume;
•Solr;
•Hive;
•HBase

2

При возникновении проблем с сервисами Cloudera некоторое время события накапливаются в Kafka. Далее события Platform V Audit SE (AUD) будут утеряны

Сервер Platform V Audit SE (AUD) (WildFly)

3

Недоступен UI модуля. Регистрация событий происходит в штатном режиме (при недоступном UI события аудита продолжают регистрироваться. Просмотр событий доступен через панель управления СУБД)

Рекомендации при ошибках и сбоях Platform V Audit SE (AUD)#

Общие рекомендации по анализу администратором проблем в Platform V Audit SE (AUD)#

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

Модуль (клиентская АС) не может записать данные в Platform V Audit SE (AUD) Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

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

Примеры проблем/сбоев Platform V Audit SE (AUD), их диагностика и рекомендации по устранению#

Ошибка установки SSL соединения (клиентский модуль не подключается к Kafka, закрытой SSL)#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

Проверить контейнер с сертификатом (jks).

В промышленном SSL сертификате есть поле — Extended Key Usage, у которого может быть значение «Для клиентской аутентификации», «Для серверной аутентификации» или сразу оба. Сертификат, с которым клиент подключается к Kafka Platform V Audit SE (AUD), должен быть для клиентской аутентификации (либо для обеих). В противном случае Kafka при SSL handshake разорвет соединение с ошибкой вида «Сертификат не предназначен для клиентской аутентификации». Можно проверить это поле на машине с Linux командой keytool –keystore keystore_name.jks –list –v.

События от прикладного модуля не пишутся в Platform V Audit SE (AUD)#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

  1. Проверьте параметры, с которыми стартовала клиентская часть Platform V Audit SE (AUD). Если на стенде SSL, то убедитесь, что сертификат включен в ACL Kafka Platform V Audit SE (AUD). Детальное описание параметров есть в документации.

  2. Зайдите в UI Platform V Audit SE (AUD) и выполните поиск с пустой поисковой строкой. Убедитесь, что есть хотя бы одно свежее событие. Если свежих событий нет, то проблема общая для всех модулей. Информация о действиях в этом случае расположена ниже.

  3. Выполните поиск в UI Platform V Audit SE (AUD) в формате Lucene по тексту module:audit. Убедитесь, что событие поиска из п.2 записано в Platform V Audit SE (AUD).

Если проблема с событиями только от одного модуля, то:

  1. Требуются логи WildFly этого модуля.

  2. Требуются логи с Kafka с сервисов Flume-Solr-Event и Flume-Operation.

  3. Выполнить поиск в UI Solr с помощью запроса module:"MODULENAME", отсортировав по времени createdAt DESC.

  4. Выполнить поиск по подстроке module:\"MODULENAME в Hue по Hbase в таблицах audit_invalid_events, audit_invalid_operations.

    В таблице в строке поиска написать запрос (точка в начале запроса обязательна):

    .*{SingleColumnValueFilter('payload', 'payload', =, 'substring:IDмодуля')}

    Если нужно вывести более 1 события или операции, то в конце запроса напишите +10.

  5. Проанализировать содержимое топиков audit-global-events, audit-global-operations на наличие событий и операций от модуля MODULENAME.

    В логах WildFly необходимо искать ошибки записи в Kafka.

    В логах Flume необходимо искать ошибки валидации событий.

Если проблема для событий по всем модулям, то необходимо проверять pipeline.

  1. Проверить работоспособность Kafka Platform V Audit SE (AUD).

  2. Зайти в Cloudera Manager и проверить состояние сервисов. Наиболее важные: Flume*, Solr, ZooKeeper, Hbase, Hive, HDFS. Устранить неисправности.

  3. Проверить версию агентов Flume. Поиск в Cloudera Manager по логам Flume* подстроки version с уровнем INFO.

  4. Проверить конфигурационные файлы Flume. Могут быть ошибки конфигурации.

  5. Проверить параметры конфигурации клиентских модулей Platform V Audit SE (AUD).

  6. Проверить доступность Kafka Platform V Audit SE (AUD). Можно по логам прикладного модуля смотреть сообщения от клиентского модуля Platform V Audit SE (AUD). Можно по логам WildFly серверной части Platform V Audit SE (AUD).

Данные регистрируются с большой задержкой#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

Нужно смотреть offsets consumer audit-events-solr на Kafka Platform V Audit SE (AUD). Если они большие, то проблема с вычиткой данных из Kafka.

В первую очередь нужно посмотреть версию агентов Flume. Поиск в Cloudera Manager по логам Flume подстроки version с уровнем INFO. Она должна быть актуальная.

Далее требуется посмотреть логи Flume-Solr-Event. Скорее всего, в них обнаружится много ошибок обработки.

Далее необходимо проверить, что в solr/configs/audit-events отсутствует файл schema.xml. Если файл есть, необходимо удалить эту схему в ZooKeeper, удалить в Solr коллекцию и выполнить скриптами обновление Cloudera.

Обратитесь к администраторам соответствующего стенда.

Не удается найти данные по модулю#

Ошибка не приводит к нарушению конфиденциальности, целостности или доступности информации.

  1. UI Platform V Audit SE (AUD) предоставляет возможность поиска по событиям. Убедитесь, что вы ищете именно события. При этом в Platform V Audit SE (AUD) еще регистрируется сущность «операция», которая является группирующей для событий. Поиска по операциям на текущий момент нет, команда разработки Platform V Audit SE (AUD) работает над этим.

  2. Поиск в UI Platform V Audit SE (AUD) имеет три режима, каждый из которых обладает своими особенностями. Например, в режиме Lucene спецсимволы имеют свое предназначение. В поиске «По словам» происходит дробление фразы на слова, и поиск выполняется по И. В поиске «По фразе целиком» ищется точное вхождение фразы. Ознакомьтесь с документацией по поиску, чтобы убедиться в том, что ваши ожидания соответствуют поисковому алгоритму.

  3. Бывает, что данные пишут в один стенд (среду), а искать их пытаются на другом.

Модуль не смог стартовать, ошибка Error occurred while sender.sending metamodel#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

Полный текст ошибки:

_"Caused by: <...>.AuditTransportException: Error occurred while sender.sending metamodel_
_Caused by: <...>.AuditTransportException: Could not send data to topic audit-***-metamodels_
_Caused by: java.util.concurrent.ExecutionException: shade.org.apache.kafka.common.errors.TimeoutException: Failed to update metadata after 60000 ms._
_Caused by: shade.org.apache.kafka.common.errors.TimeoutException: Failed to update metadata after 60000 ms.",_

Пример ошибки из лога:

_19:48:43,022 INFO [stdout] (ServerService Thread Pool -- 155) <...>.AuditTransportException: Could not send data to topic audit-currency-rates-metamodels_
_19:48:43,022 INFO [stdout] (ServerService Thread Pool -- 155) at <...>.service.transport.impl.AuditClientKafkaProducer.sendSync(AuditClientKafkaProducer.java:172)_
_19:48:43,022 INFO [stdout] (ServerService Thread Pool -- 155) at <...>.service.transport.impl.AuditClientKafkaProducer.send(AuditClientKafkaProducer.java:150)_
_19:48:43,022 INFO [stdout] (ServerService Thread Pool -- 155) at <...>.service.transport.impl.AuditClientKafkaProducer.sendMetamodel(AuditClientKafkaProducer.java:99)_
_19:48:43,022 INFO [stdout] (ServerService Thread Pool -- 155) at <...>.AuditClientFactoryImpl.sendMetamodel(AuditClientFactoryImpl.java:210)_
_19:48:43,022 INFO [stdout] (ServerService Thread Pool -- 155) at <...>.AuditClientFactoryImpl.<init>(AuditClientFactoryImpl.java:81)_
_19:48:43,022 INFO [stdout] (ServerService Thread Pool -- 155) at <...>.cfg.Configuration.buildAuditClientFactory(Configuration.java:37)_
...
_19:48:43,023 INFO [stdout] (ServerService Thread Pool -- 155) Caused by: java.util.concurrent.ExecutionException: shade.org.apache.kafka.common.errors.TimeoutException: Failed to update metadata after 60000 ms._
_19:48:43,023 INFO [stdout] (ServerService Thread Pool -- 155) at shade.org.apache.kafka.clients.producer.KafkaProducer$FutureFailure.<init>(KafkaProducer.java:1108)_
_19:48:43,023 INFO [stdout] (ServerService Thread Pool -- 155) at shade.org.apache.kafka.clients.producer.KafkaProducer.doSend(KafkaProducer.java:808_)
_19:48:43,023 INFO [stdout] (ServerService Thread Pool -- 155) at shade.org.apache.kafka.clients.producer.KafkaProducer.send(KafkaProducer.java:745)_
_19:48:43,023 INFO [stdout] (ServerService Thread Pool -- 155) at shade.org.apache.kafka.clients.producer.KafkaProducer.send(KafkaProducer.java:634)_
_19:48:43,023 INFO [stdout] (ServerService Thread Pool -- 155) at <...>.service.transport.impl.AuditClientKafkaProducer.sendSync(AuditClientKafkaProducer.java:166)_
_19:48:43,023 INFO [stdout] (ServerService Thread Pool -- 155) ... 111 common frames omitted_

Диагностика и решение:

Причина ошибки в том, что отсутствует связь с Kafka Platform V Audit SE (AUD).

  1. Проверить физ.доступ с серверов WildFly до серверов Kafka.

  2. Проверить наличие топика, в который отправляется метамодель.

  3. Проверить наличие живого лидера партиции.

  4. Проверить по серверу старые перекрытия, что прописаны актуальные для Kafka.

  5. Необходимо убедиться, что в артефакте audit2-client прописаны корректные параметры подключения к Kafka Platform V Audit SE (AUD).

  6. Если параметры корректные, необходимо убедиться в том, что Kafka Platform V Audit SE (AUD) работает.

Модуль не смог стартовать, ошибка Unable to init buffer#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

Caused by: <…>.buffer.exception.BufferInitializationException: Unable to init buffer

Caused by: java.lang.IllegalStateException: Cannot start audit client library buffer is in invalid state: there must be two files for buffer: data file and meta file"}}

Решение:

Проверить наличие свободного места в папке, в которой размешены файлы буфера modulename -node.id_audit.data и modulename -node.id_meta.data. Чтобы понять в какой папке они размещены, требуется посмотреть параметр audit2-client@buffer.directoryInTemp. Если этот параметр пустой, то посмотреть параметр audit2-client@buffer.directory. Если и он пустой, то буфер создается в папке \tmp. Свободного места требуется столько, сколько указано в параметре audit2-client@buffer.maxSize. Также надо учитывать, что в эту папку могут писать буферы для других модулей и вообще говоря произвольные данные. Также следует учесть, что при изменении параметра audit2-client@buffer.maxSize требуется место, в сумме превышающее старое + новое значение, т.к. при старте модуля производится перенос данных из старого файла в новый.

  1. Если свободного места недостаточно, необходимо реализовать один из вариантов:

    • удалить ненужные файлы в папке буфера;

    • создать перекрытие в PACMAN и указать там подходящее значение audit2-client@buffer.directory;

    • удалить некоторые пары файлов *_audit.data + *_meta.data.

  2. Если свободного места достаточно, то необходимо проверить наличие двух файлов modulename_audit.data и modulename_meta.data. Если какого-то из них нет, то буфер поврежден и требуется удалить оставшийся и снова стартовать модуль.

События аудита WildFly не отправляются в Platform V Audit SE (AUD) с узла ХХХ#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

Решение:

Необходимо выполнить в UI Platform V Audit SE (AUD) поиск Lucene по строке module:"audit2-wildfly-agent" AND nodeId:"ХХХ" за длительный период.

  1. Если ни одного события нет, следует проверить наличие установленных модулей audit2-wildfly-agent и audit2-client-platform. Если модули присутствуют и запущены, то необходимо проверить правильность значений конфигурации в PACMAN для компонентов audit2-client, audit2-wildfly-agent.

  2. Если события имеются, но последнее событие содержит в дополнительных атрибутах operation: Start execution и errorDescription:wildfly audit log-file not found /usr/WF2/wildfly-23.0.2/standalone/log/audit-log.log, значит модуль audit2-wildfly-agent при старте не нашел файл Platform V Audit SE (AUD) и требуется проверить наличие этого файла на данном узле, а также доступ к этому файлу. Если файла нет, то требуется у администраторов сервера WildFly запросить информацию из standalone.xml о настройках логов аудита WildFly. В частности, проверить имя файла, оно должно быть audit-log.log.

EmptyTagValueKeyException и ConcurrentModificationException в Platform V Audit SE (AUD) при запуске ПМ#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

Неработоспособность метрик Platform V Audit SE (AUD).

Решение:

Перепроверить идентификаторы module, передаваемые в фабрику Platform V Audit SE (AUD). При наличии двух и более работающих модулей с одинаковым названием возникает конфликт при публикации клиентских метрик.

Фатальная ошибка с сообщением ClassNotFoundException#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

Caused by: java.lang.ClassNotFoundException:org.joda.time.format.DateTimeFormatterBuilderfrom[Module "deployment.audit-cloudera" from Service Module Loader]"}}

Решение:

Рестарт WildFly.

В веб-интерфейсе Platform V Audit SE (AUD) отображается ошибка 503 Сервер не отвечает#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

При нажатии на Подробно выводится сообщение:

Не удалось выполнить операцию, т.к. не удалось зарегистрировать событие аудита о выполнении операции. upstream connect error or disconnect/reset before headers. reset reason: connection failure.

Решение:

Ошибка сообщает о невозможности записать событие аудита в Kafka. Следует проверить доступность кластера Kafka (на которую нацелен audit client proxy), это наиболее частая проблема. Более подробную информацию можно получить из логов клиентского прокси (обратите внимание, что у каждого pod Proxy свои логи и ошибка будет только в логах того pod, который обрабатывал запрос). Ошибку можно найти с помощью uuid_error, который есть в тексте ошибки.

Дополнительно можно проверить конфигурацию в OpenShift (при наличии доступа):

  1. Home - Search - Resources, в поле поиск ввести ServiceEntry, перейти в kafka-audit -> YAML, найти host и port для Kafka.

  2. В Project проверить ConfigMaps для audit2-client-proxy. YAML -> найти host и port для Kafka.

    Данные host и port для Kafka в п.1 и п.2 должны быть одинаковые.

В веб-интерфейсе Platform V Audit SE (AUD) отображается ошибка 503 Сервер не отвечает#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

При нажатии на Подробно выводится сообщение:

Не удалось выполнить операцию, т.к. не удалось зарегистрировать событие аудита о выполнении операции. {"code":"503.2","message":"Transport is not available, uuid_error = 87c1e0bc-92e5-4bdf-8a00-efeb0e5c5665","description":null}

Решение:

Ошибка сообщает о невозможности записать событие аудита в Kafka. Следует проверить доступность кластера Kafka (на которую нацелен audit client proxy), это наиболее частая проблема. Более подробную информацию можно получить из логов клиентского прокси (обратите внимание, что у каждого pod Proxy свои логи и ошибка будет только в логах того pod, который обрабатывал запрос). Ошибку можно найти с помощью uuid_error, который есть в тексте ошибки.

Дополнительно можно проверить конфигурацию в OpenShift (при наличии доступа):

  1. Home - Search - Resources, в поле поиск ввести ServiceEntry, перейти в kafka-audit -> YAML, найти host и port для Kafka.

  2. В Project проверить ConfigMaps для audit2-client-proxy. YAML -> найти host и port для Kafka. Данные host и port для Kafka в п.1 и п.2 должны быть одинаковые.

В веб-интерфейсе Platform V Audit SE (AUD) отображается ошибка 503 Сервер не отвечает#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

При нажатии на Подробно выводится сообщение:

Ошибка при получении данных из Solr

Решение:

Ошибка сообщает о невозможности получить данные из Solr.

  1. Следует проверить доступность Solr, это наиболее частая проблема.

  2. Необходимо проверить, что конфигурация модуля audit2-admin заполнена корректно.

Более подробную информацию можно получить из логов WildFly, Solr, и логов модуля audit2-admin.

В веб-интерфейсе Platform V Audit SE (AUD) отображается ошибка 408 Превышен таймаут ожидания сервера#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

При нажатии на Подробно выводится одно из сообщений:

  • Ошибка при получении данных из Solr

  • Нарушен формат взаимодействия с сервером

Решение:

Ошибка сообщает об одной из следующих проблем:

  1. Невозможно получить данные из Solr.

  2. Проблемы с Cloudera.

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

  1. Проверить доступность Solr, это наиболее частая проблема. Более подробную информацию можно получить из логов WildFly и Solr.

  2. Если после выполнения п.1 проблема не устранена, проверить в UI Solr наличие aliases.

  3. Если после выполнения п.2 проблема не устранена, выполнить следующее:

    Если на Solr включен SSL, то необходимо проверить, что на серверах, где установлены backend и frontend Platform V Audit SE (AUD) размещены файлы сертификатов Solr. Важно: сертификаты должны быть размещены в папках с правами доступа 555 или выше (755, 777); solr.ssl.keystore.password должен совпадать с паролем, который был задан для ключа, хранящегося в keystore, т.е. при генерации keystore необходимо задать одинаковые пароли для keystore и для key. Настройки с указанием пути размещения файлов сертификатов и пароли указываются в конфигурации модуля audit2-admin.

В веб-интерфейсе Platform V Audit SE (AUD) отображается ошибка 503 Сервер не отвечает#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

При нажатии на Подробно выводится сообщение:

Не удалось выполнить операцию, т.к. не удалось зарегистрировать событие аудита о выполнении операции. no healthy upstream.

Решение:

Ошибка сообщает о недоступности Proxy. Необходимо проверить доступность Proxy и Pod.

В веб-интерфейсе Platform V Audit SE (AUD) отображается ошибка 503 Сервер не отвечает#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

При нажатии на Подробно выводится сообщение:

Не удалось выполнить операцию, т.к. не удалось зарегистрировать событие аудита о выполнении операции. I/O error on POST request for "<…>": Remote host closed connection during handshake; nested exception is javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake.

Решение:

Ошибка сообщает о недоступности Proxy.

Необходимо проверить работоспособность Proxy, в частности audit-istio-egress и audit-istio-ingressgw.

В веб-интерфейсе Platform V Audit SE (AUD) отображается ошибка 500 Внутренняя ошибка сервера#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

При нажатии на Подробно выводится следующее сообщение:

\u041F\u0440\u043E\u0438\u0437\u043E\u0448\u043B\u0430 \u043D\u0435\u0438\u0437\u0432\u0435\u0441\u0442\u043D\u0430\u044F \u043E\u0448\u0438\u0431\u043A\u0430: 403 Forbidden. \u041E\u0431\u0440\u0430\u0442\u0438\u0442\u0435\u0441\u044C \u0432 \u0441\u043B\u0443\u0436\u0431\u0443 \u043F\u043E\u0434\u0434\u0435\u0440\u0436\u043A\u0438.

Решение:

Ошибка 500 сообщает, что доступ запрещен. Необходимо проверить сертификаты в OpenShift.

В веб-интерфейсе Platform V Audit SE (AUD) нет описаний параметров или описаний событий#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

Решение:

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

  1. Не зарегистрирована метамодель.

  2. Производилась чистка таблицы метамоделей в Hbaseaudit:audit_metamodels. Это нештатная ситуация и недопустимая для любых стендов с потребителями.

  3. Недоступен HBase или таблица метамоделей в HBase.

  4. Метамодель зарегистрирована, но у отправляемого события и у метамодели не совпадают поля module и metamodelVersion.

  5. В метамодели нет события с кодом, с которым вы отправляете событие. Ситуация нештатная и маловероятная.

В веб-интерфейсе Platform V Audit SE (AUD) отображается пустая панель после аутентификации#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

После ввода логина и пароля в UI Platform V Audit SE (AUD) отображается пустая панель.

Решение:

Ошибка возникла для UI Platform V Audit SE (AUD) с настроенным Kerberos + SSL и была связана с тем, что в конфигурационном файле ssl.keystore.password/ssl.truststore.password стоял пробел после значения (видно при отображении символа переноса строки).

Убедитесь в правильности заполнения конфигурации SSL, в том числе для сервиса Solr.

На клиентской части имеются логи о переполнении буфера#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

На клиентской части имеются логи вида:

_2021-02-08 18:40:25.589 WARN [ms-audit,,,] 1 --- [pool-1-thread-1] c.s.audit2.buffer.impl.AuditFileBuffer : Buffer /tmp/audit/10.128.205.147_audit.data has exceeded threshold limit 900000 bytes_
_2021-02-08 18:40:25.589 ERROR [ms-audit,,,] 1 --- [pool-1-thread-1] c.s.audit2.buffer.impl.AuditFileBuffer : Spare disk buffer (/tmp/audit/10.128.205.147_audit.data) is full_
_2021-02-08 18:40:25.589 ERROR [ms-audit,,,] 1 --- [pool-1-thread-1] c.s.a.t.kafka.AuditSendAlgorithm : Error while writing audit data to spare disk buffer_
_<...>.buffer.exception.BufferHasNoSpaceForMessageException: Spare disk buffer (/tmp/audit/10.128.205.147_audit.data) is full_
_at <...>.buffer.impl.AuditFileBuffer.handleState(AuditFileBuffer.java:494) ~[audit2-cyclic-buffer-9.2.1.hf1.jar:9.2.1.hf1]_
_at <...>.buffer.impl.AuditFileBuffer.updateBufferStateOnWrite(AuditFileBuffer.java:466) ~[audit2-cyclic-buffer-9.2.1.hf1.jar:9.2.1.hf1]_
_at <...>.buffer.impl.AuditFileBuffer.doWrite(AuditFileBuffer.java:515) ~[audit2-cyclic-buffer-9.2.1.hf1.jar:9.2.1.hf1]_
_at <...>.buffer.impl.AuditFileBuffer.write(AuditFileBuffer.java:155) ~[audit2-cyclic-buffer-9.2.1.hf1.jar:9.2.1.hf1]_
_at <...>.transport.kafka.AuditSendAlgorithm.writeDataToBuffer(AuditSendAlgorithm.java:167) [audit2-client-common-9.2.1.hf1.jar:9.2.1.hf1]_
_at <...>.transport.kafka.AuditSendAlgorithm.logAndWriteToBuffer(AuditSendAlgorithm.java:148) [audit2-client-common-9.2.1.hf1.jar:9.2.1.hf1]_
_at <...>.transport.kafka.AuditSendAlgorithm.lambda$null$0(AuditSendAlgorithm.java:96) [audit2-client-common-9.2.1.hf1.jar:9.2.1.hf1]_
_at shade.org.apache.kafka.clients.producer.KafkaProducer.doSend(KafkaProducer.java:804) ~[shaded-kafka_2.11-0.11.0.2.jar:na]_
_at shade.org.apache.kafka.clients.producer.KafkaProducer.send(KafkaProducer.java:745) ~[shaded-kafka_2.11-0.11.0.2.jar:na]_
_at <...>.transport.kafka.AuditSendAlgorithm.sendAsync(AuditSendAlgorithm.java:129) [audit2-client-common-9.2.1.hf1.jar:9.2.1.hf1]_
_at <...>.transport.kafka.AuditSendAlgorithm.lambda$sendAsync$1(AuditSendAlgorithm.java:91) [audit2-client-common-9.2.1.hf1.jar:9.2.1.hf1]_
_at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[na:1.8.0_191]_
_at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[na:1.8.0_191]_
_at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) ~[na:1.8.0_191]_
_at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) ~[na:1.8.0_191]_
_at java.lang.Thread.run(Thread.java:748) ~[na:1.8.0_191]_

Решение:

Локальный буфер переполнился, т.к. не доступна Kafka Platform V Audit SE (AUD).

Восстановить связь с Kafka Platform V Audit SE (AUD).

При отправке метамодели через egress c ОТТ возвращается ошибка HTTP 403#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

При отправке метамодели через egress c ОТТ возвращается ошибка HTTP 403 feign.FeignException$Forbidden: [403 Forbidden] during [POST] to [<…>] [AuditProxyClient#sendMetamodel(AuditMetamodel)]: [com.<…>.ott.base.api.OttClientException: Hash of body is not valid.]

Решение:

Необходимо поправить фильтры ОТТ, чтобы можно было отправлять метамодель размером 2097152 (2 МБ).

{code}
kind: EnvoyFilter
metadata:
name: audit-istio-auth-filter
{code}
audit-proxy-ingress-template.yaml параметру *max_request_bytes* установить значение 2097152
{code}
kind: EnvoyFilter
metadata:
name: audit-egress-auth-filter
{code}
audit-proxy-egress-template.yml параметру *max_request_bytes* установить значение 2097152

Кроме того, если используются зависимости audit2-proxy-client-ott или audit2-proxy-client, то необходимо убедиться, что их версии: 4.2.14 или новее, 4.3.8 или новее.

В HDFS не закрываются файлы / В Hive не отображаются события#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

Решение:

  1. Проверить в конфигурации flume-hive для каждого из hdfsSink параметр hdfs.rollInterval = 3600 и rollcount=0 (значит файлы в папке tmp будут закрываться каждый час и перекладываться в /events_proxy_avro/%Y-%m-%d/ или /events_avro/%Y-%m-%d/). Если присутствует настройка idleTimeout = 600, то удалить.

  2. Проверить логи flume-hive на наличие ошибок. Если есть предупреждения/сообщения об отсутствии прав, то дать права администратора командой export HADOOP_USER_NAME=hdfs, добавить flume в группу hive командой sudo usermod -aG hive flume, дать права на папку hdfs dfs -chmod -R 775 /events_proxy_avro.

  3. На папках с датами должны быть права drwxrwxr-x.

    Такие права как drwxr-xr-x не подойдут, будет ошибка в логах flume-hive:

    Renaming file: /events_avro/2021-02-25//…/…/tmp/events_avro_tmp/EventsData-local.1614237644695.avro.tmp failed. Will retry again in 180 seconds.

    org.apache.hadoop.security.AccessControlException: Permission denied: user=flume, access=WRITE, inode="/events_avro/2021-02-25":hive:hive:drwxr-xr-x

У всех клиентов Audit-Proxy приходит ответ 403 Forbidden#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

У всех клиентов Audit-Proxy приходит ответ 403 Forbidden.

Лог у Ingress-pod без ошибок. В sidecar OTT на ingress много ошибок о неправильном токене. При этом с сертификатами все в порядке.

Решение:

Вариант 1:

В терминале Pod ingress, контейнер istio-proxy выполнить команду:

curl localhost:15000/config_dump | grep ext_authz -A 10 -B 10

Убедиться, что фильтр один.

Завести заявку на администраторов тестового стенда, завести заявку на Synapse.

Вариант 2:

Бывает, что у ISTIO для пространства имен Platform V Audit SE (AUD) появляется лишний EnvoyFilter, который отправляет весь трафик с обычного роута на проверку OTT.

Проверить это можно в конфигурации Pod ingress. Зайти в его command-line, и выполнить команды:

  • Скачать конфигурационный файл:

    curl -X POST 'http://localhost:15000/config_dump' >> /tmp/ingress-config-dump

  • Просмотреть конфигурационный файл:

    vi /tmp/ingress-config-dump

Найти в конфигурационном файле строку kind: EnvoyFilter. Таких строк должно быть столько же, и такие же, как в файле ingress-template.yml для данного стенда.

Чтобы передать данный конфигурационный файл другим людям, необходимо с какой-то физической машины отправить запрос "скачать конфигурацию" прямиком на Pod в OS. Сделать это можно с помощью OpenShift Client:

  • Для Windows:

    oc exec <имя_Pod> -c istio-proxy "curl -X POST http://localhost:15000/config_dump" 1> /tmp/ingress-config-dump

  • Для Linux:

    oc exec <имя_Pod> -c istio-proxy "curl -X POST http://localhost:15000/config_dump" >> /tmp/ingress-config-dump

  • В терминале Pod ingress, контейнер istio-proxy:

    curl localhost:15000/config_dump | grep ext_authz -A 10 -B 10

Ошибка "Unrecognized SSL message, plaintext connection executing POST"#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

При регистрации метамодели ошибка: Unrecognized SSL message, plaintext connection executing POST

Решение:

Platform V Audit SE (AUD) слушает порт 443. Нужно настроить Egress так, чтобы запрос пришел по 443 порту. По вопросам конфигурирования Egress следует обращаться к официальной документации или команде поддержки Istio.

Ошибка "TLS error" при регистрации метамодели#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

При регистрации метамодели ошибка вида:

[2021-07-19T12:35:01.405Z] "POST /v2/metamodel/ HTTP/1.1" 503 UF,URX "-" "TLS error: 336130315:SSL routines:ssl3_get_record:wrong version number" 8287 91 1635 - "-" "Apache-HttpClient/4.5.12 (Java/1.8.0_191)" "689774f4-c8ea-99bb-b069-cba07eef4556" "<IP-адрес>" "<IP-адрес>:8080" outbound|8080||egressgateway-svc.ci02577564-idevgen2-sberopros.svc.cluster.local - <IP-адрес>:8080 <IP-адрес>:51568 - -
[2021-07-19T12:35:03.253Z] "POST /v2/metamodel/ HTTP/1.1" 503 UF,URX "-" "TLS error: 336130315:SSL routines:ssl3_get_record:wrong version number" 8287 91 93 - "-" "Apache-HttpClient/4.5.12 (Java/1.8.0_191)" "43168433-096a-923b-8c07-c45aacf002ca" "<IP-адрес>" "<IP-адрес>:8080" outbound|8080||egressgateway-svc.ci02577564-idevgen2-sberopros.svc.cluster.local - <IP-адрес>:8080 29.64.113.109:51568 - -

Решение:

mTLS блокирует отправку запроса, необходимо отключить его.

Ошибка AuditSecurityException#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

Ошибка аудита в логах фабрики: AuditSecurityException: User login wasn't specified:

com.sbt.audit2.security.AuditSecurityException: User login wasn't specified
                at com.sbt.audit2.AuditClientImpl.createOperation(AuditClientImpl.java:354
                at com.sbt.audit2.AuditClientImpl.auditOperation(AuditClientImpl.java:69)
                at ru.sbt.cs.audit.impl.AuditService.audit(AuditService.java:141)
                at ru.sbt.controllers.async.AsyncKafkaTransportControllerEdsAsyncImpl.auditMessage(AsyncKafkaTransportControllerEdsAsyncImpl.java:173)
                at ru.sbt.controllers.async.AsyncKafkaTransportControllerEdsAsyncImpl.sendMessageToCS(AsyncKafkaTransportControllerEdsAsyncImpl.java:152)
                at ru.sbt.controllers.async.AsyncKafkaTransportControllerEdsAsyncImpl.verify(AsyncKafkaTransportControllerEdsAsyncImpl.java:128)
                at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

Решение:

AuditSecurityException: User login wasn't specified.

Ошибка возникает, если нет информации о тикете или логине пользователя при создании операции аудита.

Данная ошибка возникает, если UserProvider, который вы передаете фабрике аудита при ее создании, возвращает null при вызове метода getUserLogin, и реализация UserProvider выполнена не на стороне Platform V Audit SE (AUD).

Ошибка с кодом 403 от UAEX#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

События регистрируются корректно. При регистрации метамоделей из кода приложения в некоторых случаях возникает ошибка с кодом 403 от UAEX. Код ошибки:

[libprotobuf ERROR external/com_google_protobuf/src/google/protobuf/wire_format_lite.cc:584] String field 'envoy.service.auth.v2.AttributeContext.HttpRequest.body' contains invalid UTF-8 data when serializing a protocol buffer. Use the 'bytes' type if you intend to send raw bytes.
[2021-08-27T08:38:30.382Z] "POST /v1/metamodel HTTP/1.1" 403 UAEX "" 12397 0 1 - "10.128.23.78" "Apache-HttpClient/4.5.13 (Java/1.8.0_272)" "ac5e1e2f-d9c9-4f15-9122-4dcac4717668" "audit2-proxy-psi.apps.test.enablers.<...>.ru" "-" - - 10.128.37.66:8704 10.128.23.78:34008 - -

Решение:

Наиболее вероятно, в коде происходит конвертация данных в JSON, при конвертации в метамодель подставляются символы в кодировке, отличной от UTF-8.

Для локализации проблемы предложено:

  1. Выполнить curl на endpoint Platform V Audit SE (AUD) с пустым JSON метамодели.

  2. Выполнить curl на endpoint Platform V Audit SE (AUD) с метамоделью в виде JSON.

  3. Выполнить curl на endpoint Platform V Audit SE (AUD) с метамоделью в виде файла из исходников прикладного модуля.

Способы настройки audit-client-core2 для работы с PACMAN#

Инициализация audit-client-core2 с использованием модуля audit2-client-platform

  1. Необходимо прописать в pom.xml dependency на клиентский модуль аудита audit-client-core2, а также оставить зависимость на "старый" клиентский модуль Platform V Audit SE (AUD).

    <dependency>
<groupId>sbp.ts.audit2</groupId>
<artifactId>audit-client-core2</artifactId>
<version>${audit.version}</version>
</dependency>

<dependency>
<groupId>sbp.ts.audit2</groupId>
<artifactId>audit2-api</artifactId>
<version>${audit.version}</version>
<scope>provided</scope>
</dependency>

  2. Добавить в код проекта класс, инициализирующий фабрику Platform V Audit SE (AUD).

    package com.sbt.qa.audit.infra.components;

import com.sbt.audit.core.config.AuditConfig;
import com.sbt.audit.core.service.AuditServiceFactory;
import com.sbt.audit2.spi.AuditService;
import com.sbt.core.commons.api.PlatformCommonsFactory;
import com.sbt.core.commons.config.xml.utils.ConfigNotValidException;
import com.sbt.core.commons.config.xml.utils.ConfigStructureParseException;
import com.sbt.qa.audit.infra.impl.exceptions.AuditTestModuleException;
import lombok.Getter;

import javax.annotation.PostConstruct;
import java.util.Properties;

public class AuditServiceBean {

   private final PlatformCommonsFactory platformCommonsFactory;
   @Getter
   private AuditServiceFactory auditServiceFactory;

   public AuditServiceBean(PlatformCommonsFactory platformCommonsFactory) {
       this.platformCommonsFactory = platformCommonsFactory;
   }

   @PostConstruct
   public void initAuditServiceFactory() throws AuditTestModuleException {
       Properties oldAuditProperties;
       try {
           oldAuditProperties = platformCommonsFactory
                   .createPlatformPropertyLoader("audit2-client", AuditService.class.getClassLoader())
                   .loadProperties();
       } catch (ConfigStructureParseException | ConfigNotValidException e) {
           throw new AuditTestModuleException("Context uploading error", e);
       }
       AuditConfig auditConfig = new AuditConfig();
       auditConfig.setMockEnabled(Boolean.parseBoolean(oldAuditProperties.getProperty("mockEnabled")));
       auditConfig.getNetworkConfig().setMainServer(oldAuditProperties.getProperty("kafka.producer.bootstrap.servers"));
       auditConfig.getNetworkConfig().setFallbackServer(oldAuditProperties.getProperty("kafka.producer.bootstrap.servers"));
       auditConfig.getNetworkConfig().getSslConfig().setSecurityProtocol(oldAuditProperties.getProperty("kafka.producer.security.protocol"));
       /*
       Добавление других, необязательных настроек в AuditConfig в случае необходимости. Если не требуется дополнительного
       конфигурирования клиента Platform V Audit SE (AUD), то передавать такие настройки из oldAuditProperties в auditConfig НЕ РЕКОМЕНДУЕТСЯ,
       так как в Platform V Audit SE (AUD) 3го и 4го поколения могут различаться значения настроек по умолчанию.
        */
       auditServiceFactory = new AuditServiceFactory(auditConfig);
   }
}

  3. Развернуть компоненты, необходимые для работы Platform V Audit SE (AUD).

    • audit2-client-platform-*.war

    • custodian-distr-impl-ear-*.ear

Ошибка при построении дерева операций в пользовательском интерфейсе Platform V Audit SE (AUD)#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

В UI Platform V Audit SE (AUD) при построении дерева операций получена ошибка:

Получение дерева операций с UUID 114650fd-7fe6-4b0e-9fee-0d8fb1c05bbf завершилось неуспешно: Ошибка при получении данных из HBase.

В логах flume Geo-Local-Flume-Operation и Geo-Remote-Flume-Operation ошибки вида:

[lifecycleSupervisor-1-2] Unable to start SinkRunner: { policy:org.apache.flume.sink.DefaultSinkProcessor@31943000 counterGroup:{ name:null counters:{} } } - Exception follows.
java.lang.IllegalArgumentException: Please call stop before calling start on an old instance.
         at com.google.common.base.Preconditions.checkArgument(Preconditions.java:122)
         at org.apache.flume.sink.hbase2.HBase2Sink.start(HBase2Sink.java:136)

Решение:

  1. Выполнить вход в HUE — HBase.

  2. Проверить наличие таблицы audit:audit_operations.

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

Падение приложения при обновлении через Install_Eip с ошибкой Cannot get property 'rollback' on null object#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

При обновлении через Install_Eip приложение падает с ошибкой:

DEPLOY TEMPLATES SUCCESS
Error=Cannot get property 'rollback' on null object

В полном логе видно, что не задан порядок выполнения параллелей шагов:

Порядок выполнения параллелей шагов:
0: [Audit_OpenShift_Clean_Namespace, Audit_Deploy_to_OpenShift]

И задания друг друга перебивают.

Решение:

Необходимо в Install_Eip в файле actions.xml выставить :

<Action name="Audit_Deploy_OpenShift_Client" visible="true">
           <context/>
           <mode>all</mode>
           <default>false</default>
           <Description>Установка приложения на OpenShift</Description>
           <Dependency onFail="Skip">Audit_OpenShift_Clean_Namespace</Dependency>
           <type>groovy</type>
           <Script>bin/deploy_to_openshift_multi.groovy</Script>
       </Action>

Фатальная ошибка при обновлении Cloudera Manager#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

При обновлении Cloudera Manager средствами Install_Eip при выборе двух шагов: шаг_1 - Пересоздание набора flume в кластере Cloudera 6; шаг_2 - Обновление Cloudera 6 возникает ошибка:

TASK [cloudera-cluster : cloudera_manager]
fatal: [audit-local]: FAILED! => {"ansible_facts":
{"discovered_interpreter_python": "/usr/bin/python"}
, "changed": false, "module_stderr": "", "module_stdout": "HTTP 302 Found\n", "msg": "MODULE FAILURE\nSee stdout/stderr for the exact error", "rc": 1}
PLAY RECAP
audit-local                : ok=1    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0

Решение:

HTTP код перенаправления 302 Found означает, что запрошенный ресурс был временно перемещен по адресу, указанному в заголовке Location (en-US). Получив такой ответ браузер перенаправляется на новую страницу.

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

Необходимо проверить inventory стенда на наличие несоответствий. В частности, параметры:

  • cloudera_host : cloudera.server.FQDN.ru # FQDN хоста, на котором находится Cloudera Manager Server

  • cloudera_port : 7180

  • cloudera_https : False

  • cloudera_cluster : "My Super Cluster" # Имя кластера в Cloudera Manager

Падение приложения при обновлении через Install_Eip с фатальной ошибкой#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

При обновлении через Install_Eip приложение падает с ошибкой:

fatal: [audit-cloudera]: FAILED! => {"changed": true, "cmd": "hbase shell /var/sbt/audit/scripts/hbase/00000-hbase-install.rb", "delta": "0:00:47.240555", "end": "2021-12-07 06:35:33.094559", "msg": "non-zero return code", "rc": 1, "start": "2021-12-07 06:34:45.854004", "stderr": "LoadError: no such file to load -- /var/sbt/audit/scripts/hbase/00000-hbase-install\n    load at org/jruby/RubyKernel.java:974\n  <main> at /opt/cloudera/parcels/CDH-6.3.1-1.cdh6.3.1.p0.1470567/lib/hbase/bin/../bin/hirb.rb:186", "stderr_lines": ["LoadError: no such file to load -- /var/sbt/audit/scripts/hbase/00000-hbase-install", "    load at org/jruby/RubyKernel.java:974", "  <main> at /opt/cloudera/parcels/CDH-6.3.1-1.cdh6.3.1.p0.1470567/lib/hbase/bin/../bin/hirb.rb:186"], "stdout": "", "stdout_lines": []}

Решение:

Ошибка говорит, что у пользователя Hbase нет прав.

Ошибка java.security.UnrecoverableKeyException#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

В логах присутствуют записи вида "Caused by: java.security.UnrecoverableKeyException: Cannot recover key"

Решение:

Некорректно указан пароль для хранилища. Необходимо проверить конфигурацию.

Ошибка в логах flume-solr#

Ошибка не приводит к нарушению конфиденциальности и целостности информации, но приводит к нарушению доступности информации.

В логах flume-solr ошибка:

[conf-file-poller-0] Sink eventsSolrSink2 has been removed due to an error during configuration
java.lang.IllegalStateException: Sink eventsSolrSink2 is not connected to a channel
        at org.apache.flume.node.AbstractConfigurationProvider.loadSinks(AbstractConfigurationProvider.java:460)
        at org.apache.flume.node.AbstractConfigurationProvider.getConfiguration(AbstractConfigurationProvider.java:106)
        at org.apache.flume.node.PollingPropertiesFileConfigurationProvider$FileWatcherRunnable.run(PollingPropertiesFileConfigurationProvider.java:145)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

Решение:

Проверить, нет ли в конфигурации flume-solr placeholders {… вместо конкретных значений.

Во время работы сервиса divider возникают предупреждения#

Ошибка не приводит к нарушению конфиденциальности, целостности или доступности информации.

В логах ошибка:

022-11-09 11:01:14,754 [taskScheduler-1-SendThread(dev-audt-cloudera-03.opsmon.sbt:2181)] [WARN] (org.apache.zookeeper.ClientCnxn) [org.apache.zookeeper.ClientCnxn$SendThread::run:1279] mdc:(myid=dev-audt-cloudera-03.opsmon.sbt:2181)| An exception was thrown while closing send thread
for session 0xff845b56cf330378.
org.apache.zookeeper.ClientCnxn$EndOfStreamException: Unable to read additional data from server sessionid 0xff845b56cf330378, likely server has closed socket
at org.apache.zookeeper.ClientCnxnSocketNIO.doIO(ClientCnxnSocketNIO.java:77)
at org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:350)
at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1275)
2022-11-09 11:01:14,857 [taskScheduler-1] [INFO] (org.apache.zookeeper.ZooKeeper) [org.apache.zookeeper.ZooKeeper::close:1619] mdc:()| Session: 0xff845b56cf330378 closed

Решение:

Данное сообщение не является ошибкой или ее признаком, так как именно на этом уровне логирования (WARN) разработчики Zookeeper пишут сообщения о закрытии сессии клиента. Следует читать такое сообщение как "Подключение к Solr успешно закрыто, все в порядке".

Проблемы с аутентификацией сервисов через Kerberos#

При наличии проблем с аутентификацией сервисов через Kerberos можно включить debug-режим этих соединений.

kerberos:
   debug.enabled: true # признак включенного debug-режима для протокола kerberos

Перезапустите Pod и посмотрите ошибку.

Решение:

Некорректно настроен DNS сервер, на котором не работает reverse DNS-resolve. Необходимо добавить в /etc/hosts записи о хостах, к которым не удается подключиться.

Для OpenShift можно добавить в Deployment-конфигурацию:

spec:
 template:
spec:
 hostAliases:
  - ip: IP_1
hostnames:
  - FQDN_1
  - ip: IP_2
hostnames:
 - FQDN_2

В логах Flume ошибка Caused by: javax.security.auth.login.LoginException: Unable to obtain password from user#

Решение:

Проверьте, что в Configuration File Flume (и Install_EIP) имя principal совпадает с тем именем, для которого выпускали keytab. Также проверьте, что в параметре cache_kerberos_master_keytab присутствует principal, указанный в параметре cache_kerberos_master_principal.

Рекомендации при обращении администратора в техническую поддержку#

При обращении с проблемами Platform V Audit SE (AUD) в техническую поддержку, администратору необходимо собрать следующую информацию:

  1. (обязательно) Логи сервера WildFly, где выполняется модуль, у которого наблюдаются проблемы с Platform V Audit SE (AUD).

  2. (обязательно) Логи Flume, которые можно получить через Cloudera Manager (сервис Flume).

Дополнительно администратору при обращении к технической поддержке необходимо указать:

  1. (желательно, но не обязательно) Наименование стенда/среды, где установлен Platform V Audit SE (AUD).

  2. (обязательно) Адрес Cloudera Manager, к которому подключен стенд/среда, а также (желательно, но не обязательно) логин и пароль для доступа.

  3. (обязательно) Адрес интерфейса пользователя Platform V Audit SE (AUD), а также (желательно, но не обязательно) логин и пароль для доступа.