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

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

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

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

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

Сделать это можно с помощью системных метрик (описаны ниже) и метрики доступности. Также контролировать работу сервиса можно с помощью логов Unimon-server, проверять их на наличие ошибок.

2. При выявлении нештатных ситуаций необходимо: a. проверить логи Unimon-server на наличии ошибок; b. проверить логи Unimon-filter на наличии ошибок; c. проверить логи Unimon-metadata на наличии ошибок.

3. В рамках выполнения требований безопасной работы системы Администратор выполняет следующие функции:

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

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

   • несет ответственность за качество проводимых им работ.

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

Необходимо контролировать работоспособность unimon-server, это возможно с помощью метрики unimon_server_health_status или способами описанными ниже.

1. Для проверки соединения Unimon-server с БД, есть несколько вариантов (можно выбрать в зависимости от наличия прав):

   • Выполнить в терминале pod Unimon-server запрос, в ответе будет указан статус соединения.  

   sh-4.4$ curl http://localhost:8080/mona/v1/instance/sender/list
   

   • Проверить наличие ошибок в pod Unimon-server.

   • В БД (Postgres) проверить соединение со схемой Unimon.

2. Для получения данных от сервера необходимо периодически осуществлять проверки соединения Unimon-sender c Unimon-server:

   • В логе sidecar Istio pod Unimon-sender должны присутствовать записи успешного ответа

   [2021-09-20T22:45:22.850Z] "GET /mona/v1/instance HTTP/1.1" 200 - "-" "-" 0 2931 78 78 "-" "Java/11.0.4" "e2fee4df-4092-914d-89b8-9aa1721239db" "ingress.unimon.ci01976100-idevgen2-unimon-ift.apps.dev-gen2.aa.ssss.ru" "XX.XX.XXX.XXX:XXXX" outbound|7071||egressgateway-monitoring-r3.ci01976100-idevgen2-unimon-ift.svc.cluster.local XX.XX.XXX.XXX:XXXXX XX.XXX.XXX.XX:XX XX.XX.XXX.XXX:XXXXX - -
   

3. Для проверки соединения Unimon-server с Abyss

   • Выполнить в терминале pod Unimon-server запрос, если будет получен ответ, то соединение с Abyss установлено

   sh-4.4$ curl http://localhost:8080/mona/v1/instance/
   

Необходимо контролировать работоспособность unimon-filter и unimon-metadata, это возможно с помощью метрик unimon_filter_health_status и unimon_metadata_health_status.

Используемые порты:

Описание парольной политики не применимо, так как Unimon не предполагает создание учетных записей/паролей пользователей, это действие происходит в рамках сервисов IAM Proxy в составе продукта Platform V IAM SE или Abyss. Резервное хранилище на стороне unimon-server не предусмотрено.

Примеры типовой конфигурации указаны в Руководстве по установке.

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

Конфигурирование#

Все параметры конфигурации подробно описаны в Справочнике конфигурационных файлов. Изменять или задавать параметры конфигурации можно с помощью редактирования файла конфигурации необходимого модуля в среде контейнеризации или в компоненте PACMAN (CFGA) продукта Platform V Configuration (CFG). На текущий момент в компоненте PACMAN (CFGA) продукта Platform V Configuration (CFG) доступно редактирование следующих конфигураций:

При редактировании параметров конфигурации в среде контейнеризации необходимо также использовать файлы указанные выше, для обеспечения синхронизации конфигурации в компоненте PACMAN (CFGA) продукта Platform V Configuration (CFG). Синхронизация параметров конфигурации работает в обе стороны, то есть при изменении в среде контейнеризации, будет выполнено обновление параметров в компоненте PACMAN (CFGA) продукта Platform V Configuration (CFG) и наоборот. При редактировании в среде контейнеризации иных файлов конфигурации (для модулей перечисленных выше) заданые значения не будут применены и синхронизированы с компонентом PACMAN (CFGA) продукта Platform V Configuration (CFG). С помощью параметров для unimon-server, unimon-filter, unimon-metadata можно задавать необходимые значения лимитов памяти и CPU. В конфигурационных файлах указаны рекомендованные значения, которые могут быть изменены на нужные в случае разного потока метрик.

unimon-server.openshift.cpuLimit=1
unimon-server.openshift.memLimit=1500Mi
unimon-server.openshift.cpuRequest=200m
unimon-server.openshift.memRequest=1500Mi

unimon-filter.openshift.cpuLimit=1
unimon-filter.openshift.memLimit=1500Mi
unimon-filter.openshift.cpuRequest=200m
unimon-filter.openshift.memRequest=1500Mi

unimon-metadata.openshift.cpuLimit=1
unimon-metadata.openshift.memLimit=1500Mi
unimon-metadata.openshift.cpuRequest=200m
unimon-metadata.openshift.memRequest=1500Mi

Создание подключения и объектов хранилища#

Если подразумевается использование подключения клиентской части к серверной (неавтономная работа), то необходимо выполнить подключение клиента к Unimon. После которого, клиент получит unimonId, соответсвующий объектам хранилица, который необходимо указывать при передачи метрик.
При создании подключения также задается квота для этого подключения, которая выделяется из квоты проекта. Подробное описание квотирования находится в архитектуре Unimon. При автономной работе (без подключения к серверной части) создание подключения и UnimonId не требуется. Каждому unimonId соответствует topic Kafka, в который Unimon будет писать метрики клиента. Для создания, просмотра, редактирования признака основного подключения для проекта, удаления одного или всех подключений проекта необходимо воспользоваться Unimon UI (подробное описание в инструкциях Indicator) или методами API Unimon (подробнее в описании API). Для создания, удаления, редактирования подключений пользователь должен обладать ролью MONA_CONNECTIONS_EDITOR. Для просмотра подключений в своем проекте необходимо обладать ролью MONA_CONNECTIONS_EDITOR. Для использования unimonid в запросах к хранилищу необходимо в Indicator создать Datasource (подробнее в Руководстве системного администратора Platform V Monitor Indicator).

Квотирование#

Подробное описание механизма квотирования находится в Детальной архитектуре. Квота на проект задается в UI Abyss. Квота на подключение задается при создании подключения, она выделяется из квоты проекта. Для задания квоты на подключение, а также для просмотра квот необходимо воспользоваться UI (подробное описание в инструкциях Indicator - Руководство оператора Unimon). Для редактирования квот подключений необходимо воспользоваться API Unimon (подробнее в описании API Unimon). Каждому уже существующему проекту будет выделена квота в размере MAX_INT и распределена равномерно между уже существующими подключениями по этому проекту. Свободным останется 20% квоты по проекту для возможности создания новых подключений. Нельзя задавать нулевое или дробное значение для квоты подключения. Если при создании подключения значение квоты не задано, подключение будет создано и ему будет назначена вся оставшаяся квота проекта.

Создание и редактирование правил выключения метрик#

Правила выключения метрик позволяют отключать передачу метрик в topic Kafka. Для создания, просмотра, редактирования правил необходимо воспользоваться Unimon UI (подробное описание в инструкциях Indicator) или методами API Unimon. Для создания, удаления, редактирования правил пользователь должен обладать ролью MONA_FILTER_EDITOR. Для просмотра правил выключения метрик в своем проекте необходимо обладать ролью MONA_FILTER_VIEWER.

Правила создания объектов в хранилище метрик#

1. Если флаг проставлен (NEED_CREATE_STORAGE = true): Unimon подключается к хранилищу метрик и создает новый topic в Kafka и новую задачу для индексации в проекте, указанном в STORAGE_PROJECT (при наличае прав у unimon).

   • Если указан TOPIC_KAFKA и ANALYTICAL_TASK - unimon создает для текущего подключения topic и задачу с указанными именами.

   • Если указан только TOPIC_KAFKA или только ANALYTICAL_TASK подключение не будет создано (необходимо указывать оба объекта).

   • Если не указан ни TOPIC_KAFKA, ни ANALYTICAL_TASK, unimon создает topic и задачу с такими же именами, что и UNIMON_ID.

2. Если флаг не проставлен (NEED_CREATE_STORAGE = false): Unimon не создает новые объекты в хранилище метрик (topic и задачу для индексации). При этом должны быть проставлены уже существующие в хранилище TOPIC_KAFKA и ANALYTICAL_TASK.

   • Если указан TOPIC_KAFKA и ANALYTICAL_TASK - unimon создает подключение с указанными значениями topic и задачи.

   • Если указан только TOPIC_KAFKA или только ANALYTICAL_TASK подключение не будет создано (необходимо указывать оба объекта).

   • Если не указан ни TOPIC_KAFKA, ни ANALYTICAL_TASK, unimon не создаст подключение.

Сбор метрик с узлов и виртуальных машин#

Так как целевая реализация Unimon предполагает сбор метрик в среде контейнеризации, для мониторинга узлов и виртуальных машин необходима отдельная настройка, после включения которой unimon-agent начнет осуществлять опрос приложений, установленных на виртуальных машинах, а затем отправку в хранилище. По умолчанию сбор с VM отключен. Для того, чтобы активировать сбор и продолжать его в автоматическом режиме, необходимо:

1. Сформировать json-файл - targets.json, содержащие IP-адреса на которых постятся метрики и положить его в репозиторий для возможного редактирования.

Внимание! Для подключения Unimon, требуется получить идентификатор подключения unimonId и указывать его в качестве label в targets.json. Если unimonId не указывать, отправка метрики будет производиться в topic по умолчанию (параметр KAFKA_TOPIC в namespace мониторинга). Если параметр KAFKA_TOPIC будет не заполнен либо отсутствовать, метрика будет игнорироваться.

Для того чтобы метрики с виртуальных машин отображались на дэшбордах в Grafana, необходимо чтобы для каждого набора таргетов присутствовал лейбл «app», в котором указывается имя приложения, публикующего метрики. Пример targets.json:

[
  {
    "labels": {
      "app": "app1",
      "unimonId": "tenant1"
    },
    "targets": [
      "XXX.XX.X.X:XXXXX",
      "YYY.YY.Y.Y:YYYYY"
    ]
  },
  {
    "labels": {
      "app": "app2",
      "unimonId": "tenant2"
    },
    "targets": [
      "XXX.XX.X.X:XXXXX",
      "YYY.YY.Y.Y:YYYYY"
    ]
  }                  
]

2. Затем необходимо запустить job в Jenkins create_configmap_se_vm со следующими параметрами:

   • REPO_URL - адрес репозитория в сервисе для хостинга систем управления версиями кода, где лежит файл targets.json;

   • REPO_BRANCH - ветка репозитория в сервисе для хостинга систем управления версиями кода;

   • REPO_CREDS - credentials для подключения к сервису для хостинга систем управления версиями кода;

   • JSON_VM_NAME - имя json-файла, в котором лежат IP-адреса, по которым постятся метрики (по умолчанию targets.json);

   • OSE_CLUSTER - cluster в среде контейнеризации, в котором развернут мониторинг (unimon);

   • OSE_PROJECT - namespace в среде контейнеризации, в котором развернут мониторинг (unimon);

   • OSE_CREDS - credentials для подключения в среде контейнеризации;

Данный job формирует и разворачивает ConfigMap в указанном namespace и заносит туда содержимое json-файла с IP-адресами VM, тем самым включая сбор метрик.

Сбор метрик с узлов и виртуальных машин по хосту(протокол HTTPs).#

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

1. Скопировать исходный код job из дистрибутива клиентской части(/scripts/jenkins/devops-opsmon-https). Создать репозиторий в сервисе для хостинга систем управления версиями кода (можно использовать уже существующий) и добавить код в него. Удостовериться, что папка scripts/jenkins/devops-opsmon-https/templates лежит в корне репозитория.

2. Сформировать json-файл - targets.json, содержащие IP-адреса на которых постятся метрики и положить его в репозиторий для возможного редактирования.

   Внимание! Для подключения Unimon, требуется получить идентификатор подключения unimonId и указывать его в качестве label в targets.json. Если unimonId не указывать, отправка метрики будет производиться в topic по умолчанию (параметр KAFKA_TOPIC в namespace мониторинга). Если параметр KAFKA_TOPIC будет не заполнен либо отсутствовать, метрика будет игнорироваться.

   Для того чтобы метрики с виртуальных машин отображались на дэшбордах в Grafana, необходимо чтобы для каждого набора таргетов присутствовал лейбл «app», в котором указывается имя приложения, публикующего метрики. Пример targets.json:

[
  {
    "labels": {
      "app": "app1",
      "unimonId": "tenant1",
      "__metrics_path__": "/metrics"
    },
    "targets": [
      "some.cloud.host:9443",
      "some2.cloud.host:9443"
    ]
  }                
]

3. Необходимо создать job в Jenkins со следующими параметрами:

   • REPO_URL - адрес репозитория в сервисе для хостинга систем управления версиями кода, где лежит файл targets.json;

   • REPO_BRANCH - ветка репозитория в сервисе для хостинга систем управления версиями кода;

   • REPO_CREDS - credentials для подключения к сервису для хостинга систем управления версиями кода;

   • MONITORING_VERSION - версия мониторинга;

   • JSON_VM_NAME - имя json-файла, в котором лежат IP-адреса, по которым постятся метрики (по умолчанию targets.json);

   • OSE_CLUSTER - cluster в среде контейнеризации, в котором развернут мониторинг (unimon);

   • OSE_PROJECT - namespace в среде контейнеризации, в котором развернут мониторинг (unimon);

   • OSE_CREDS - credentials для подключения в среде контейнеризации;

   В разделе Pipeline конфигурации job необходимо указать репозиторий в котором находится job (pipeline.groovy) и путь до нее.

4. Запустить созданный job.

   Данный job формирует и разворачивает ConfigMap в указанном namespace, заносит туда содержимое json-файла с хостами VM и создает необходимые компоненты Istio, тем самым включая сбор метрик по https.