Руководство по системному администрированию#

Полное название компонента Единый коллектор телеметрии (COTE) в составе продукта Platform V Monitor, далее по тексту используется сокращение – Единый коллектор.

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

Данное руководство предназначено для роли Администратор PVM.

Термины и определения#

Общие термины и определения, используемые в данном документе, представлены в общей документации продукта Platform V Monitor (OPM).

Сценарии администрирования#

Проверка работоспособности#

Администратору рекомендуется регулярно выполнять:

• контроль состояния работы системы Единый коллектор;

• мониторинг производительности системы Единый коллектор;

• контроль свободного места на жестких дисках всех серверов системы, а также в файловой системе;

• администрирование пользователей.

Сделать это можно с использованием самомониторинга сервиса – метрик и дашбордов (описаны ниже). Также контролировать работу сервиса можно с помощью лога (компонент Журналирование (LOGA) в составе продукта Platform V Monitor (OPM)), проверять его на наличие ошибок.

При регулярном контроле и проверке необходимо обращать внимание на следующее:

• Для контроля состояния pod необходимо использовать healthcheck. См. описание в разделе «События мониторинга» данного документа. Необходимо следить, чтобы в ответ не приходило ошибок и у pod был статус «UP», то есть pod запущены;

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

• Проверка метрик. Если метрики фиксируются в topic Apache Kafka, то система работает в штатном режиме. Также обращайте внимание на высокое потребление CPU/RAM, на изменения числа активных pipeline сбора телеметрически данных и на повышенное потребление квот.

Действия при возникновении нештатной ситуации#

При выявлении нештатных ситуаций необходимо:

1. Проверить логи сервисов на наличие ошибок:

   • При возникновении проблем с сетевой доступностью следует смотреть логи pod Egress и Ingress (уровня WARN и выше);

   • При возникновении прочих проблем необходимо смотреть логи pod telemetry-collector-management-app, telemetry-collector-pull, telemetry-collector-push (уровня WARN и выше).

   • При необходимости просмотра более подробных логов, можно изменить уровень логирования (в режиме runtime) в configmap cote-cm-logback-xml в корневом аппендере следующим образом:

   <root level="DEBUG">
        <appender-ref ref="STDOUT"/>
        <appender-ref ref="JSON"/>
   </root>
   

2. Проверить доставку данных самомониторинга в хранилище Abyss:

а. Сбор логов от Client Module осуществляется Push Collector-ом:

• Пользователь активирует pipeline сбора логов;

• Client Module осуществляет вызов API единого коллектора согласно параметрам для подключения к HTTP-API PUSH;

• Агенты осуществляют вызов API единого коллектора согласно параметрам для подключения к HTTP-API PUSH;

• Шаблон адреса API POST push/project/{projectName}/pipeline/{pipelineName} (для бинарных данных push/project/{projectName}/pipeline/{pipelineName}/prometheus-proto), где projectName – это имя проекта, в рамках которого выполняется прием логов, а pipelineName – это имя соответствующего pipeline единого коллектора;

• Если Push Collector доступен и искомый pipeline и проект найдены, то в коллекторе осуществляется обработка входящего обращения согласно Пассивной модели сбора телеметрических данных (PUSH) с использованием input-компонента «standard-http-api» для приема телеметрии в формате JSON. Учитываются требования к авторизации и аутентификации в рамках обращения;

• Полученные логи/трейсы передаются в output-компонент «kafka-output» – вывод в Apache Kafka;

• Осуществляется вывод и сохранение логов/трейсов в Abyss (работа с хранилищем Abyss описана в документе «Руководство оператора» комопнента Abyss (LGDB), входящего в состав продукта Platform V Monitor(OPM)).

b. Сбор трейсов/спанов от OpenZipkin осуществляется Push Collector-ом:

• Пользователь активирует pipeline сбора трейсов/спанов;

• OpenZipkin осуществляет вызов API единого коллектора согласно параметрам для подключения к HTTP-API PUSH;

• Агенты осуществляют вызов API единого коллектора согласно параметрам для подключения к HTTP-API PUSH;

• Шаблон адреса API POST push/project/{projectName}/pipeline/{pipelineName}, где projectName – это имя проекта, в рамках которого выполняется прием логов, а pipelineName – это имя соответствующего pipeline единого коллектора;

• Если Push Collector доступен и искомый pipeline и проект найдены, то в едином коллекторе осуществляется обработка входящего обращения согласно Пассивной модели сбора телеметрических данных (PUSH) с использованием input-компонента «standard-http-api» для приема телеметрии в формате JSON. Учитываются требования к авторизации и аутентификации в рамках обращения;

• Производится преобразование формата в плоский JSON (процессинговый блок флэтирования);

• Полученные логи/трейсы передаются в output-компонент «kafka-output» - вывод в Apache Kafka;

• Осуществляется вывод и сохранение трейсов в Abyss (работа с хранилищем Abyss описана в документе «Руководство оператора» комопнента Abyss (LGDB), входящего в состав продукта Platform V Monitor(OPM)).

3. Проверить дашборды бизнес и системных метрик (высокое потребление CPU, частые запуски GC, интервалы с отсутствием метрик любого типа);

Самомониторинг производится стандартными средствами Spring Boot. Через актуатор можно получить результат проб Liveness и Readyness.
Пример запросов:

GET /actuator/health/liveness
RESPONSE:

{ 
  "status": "UP", 
  "components": { 
    "livenessstate": { 
      "status": "UP" 
    } 
  } 
} 

GET /actuator/health/readiness
RESPONSE:

{ 
  "status": "OUT_OF_SERVICE", 
  "components": { 
    "readinessstate": { 
      "status": "OUT_OF_SERVICE" 
    } 
  } 
}

События аудита#

Информацию о событиях аудита см. в разделе «Аудит» документа «Руководство по безопасности».

Обязанности администратора#

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

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

При этом производится разделение обязанностей между разработчиками АС, тестирующим персоналом и сотрудниками, непосредственно эксплуатирующими уже введенные в промышленную эксплуатацию компонент Единый коллектор (COTE), входящий в продукт Platform V Monitor (OPM).

Рекомендации по заданию стойких паролей#

Управление учетными записями выполняется с помощью OIDC-провайдера, например, компонент IAM Proxy (AUTH), входящий в состав Platform V IAM SE. За процесс администрирования учетных записей отвечает администратор OIDC-провайдера.

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

• длина пароля не менее восьми символов;

• периодическая принудительная смена паролей не реже, чем раз в 40 дней;

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

• возможность самостоятельного изменения пользователями своего пароля в любое время;

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

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

1. первая – фиксированная системная часть, служащая признаком того, что это пароль нового пользователя;

2. вторая – задается произвольно Администратором.

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

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

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

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

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

1. Минимальная длина 9 символов;

2. Наличие специальных символов (от 1);

3. Отсутствие повторяющихся паролей в рамках одной УЗ (минимум 3 последних);

4. Наличие цифр и отсутствие повторяющихся подряд;

5. Наличие латинских букв разных регистров;

6. Отсутствие простых буквенных выражений (qwerty и т.п.);

7. Ограничение времени жизни пароля.

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

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

• при вводе пароля пользователем на запрос системы символы пароля на экране не отображаются (отображается только число введенных символов);

• при смене пароля должен запрашиваться старый пароль;

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

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

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

Рекомендации по настройке механизмов безопасности#

Для работы с паролями и секретами Platform V DevOps Tools может использовать файл _passwords.conf, который хранится в зашифрованном виде в common-репозитории.

ssl.ose.keyStore.mq.password=PWD
ssl.kubernetes.keyStore.mq.password=PWD
ssl.istio.keyStore.ingress.password=PWD
ssl.istio.keyStore.egress.password=PWD
ssl.ose.istio.keyStore.ingress.password=PWD
ssl.ose.istio.keyStore.egress.password=PWD
ssl.kubernetes.istio.keyStore.ingress.password=PWD
ssl.kubernetes.istio.keyStore.egress.password=PWD
kafka.internal.sslKeystorePassword=PWD
kafka.internal.sslTruststorePassword=PWD
kafka.internal.pull.sslKeystorePassword=PWD
kafka.internal.pull.sslTruststorePassword=PWD
database.pvm_collector.password=PWD
database.shedlock.password=PWD
spring.liquibase.password=PWD
service.core.secure.auth.basic.pass=admin
ott.certstore.private.key.pwd=PWD
ott.certstore.pwd=PWD
ott.trust.store.pwd=PWD
collector.http.client.ssl-store.trustStorePassword=PWD
collector.http.client.ssl-store.keyStorePassword=PWD
collector.http.client.ssl-store.keyStoreKeyPass=PWD
authentication.enabled.api-key.validation.auth.basic.pass=PWD

Таблица со списком секретов:

Сертификаты сервиса#

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

• Сертификат внутренней Apache Kafka;

• Сертификат OTT;

• Сертификат Pull-коллектинга;

• Сертификат ISTIO.

Все сертификаты кроме ISTIO необходимо положить в common-репозиторий, для того чтобы Platform V DevOps Tools (DOT) смог их найти и установить в инфраструктуру. ISTIO-сертификат настраивается отдельно, стандартно для Platform V DevOps Tools (DOT) способом. В случае, когда установка выполняется в ручном режиме – сертификат ISTIO конфигурируется администратором облачной инфраструктуры Kubernetes или OpenShift.

События системного журнала#

Ошибки и события, возникающие при работе сервисов Единого коллектора логируются в компоненте Журналирование (LOGA), входящего в состав продукта Platform V Monitor (OPM):

• с уровнем ERROR, если произошла критическая ошибка (или exception), не позволяющая продолжить процесс;

• с уровнем WARN, если произошла ошибка, которая позволяет продолжить процесс;

• с уровнем INFO, если произошло важное событие.

События мониторинга#

Микросервисы предоставляют метрики в формате Prometheus. Метрики собираются с помощью Prometheus-агента (компонент Объединенный мониторинг Unimon (MONA), входящий в состав продукта Platform V Monitor) и доставляются с помощью средств Platform V Monitor (OPM).

Системные метрики#

Бизнес метрики#

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

См. подробнее раздел «Часто встречающиеся проблемы и пути их устранения» в документе «Руководство по установке».