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

В руководстве приведены инструкции по администрированию компонента Сервис управления конвейером DevOps (DPM/PipeWork) (DPMS) (далее по тексту документа — "компонент") продукта Platform V DevOps Pipeline Management (DPM).

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

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

1. Перезапуска.

2. Изменения параметров настройки компонента (например, смена адреса SMTP-сервера).

3. Контроля наличия и темпа расходования аппаратных ресурсов, а также их выделения по мере необходимости.

4. Просмотра журналов действий пользователя или логов Jenkins job.

Перезапуск#

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

• для перезапуска основных сервисов компонента (dpm-core и/или qgm-core) или иного отдельного конкретного сервиса — следует перезапустить соответствующий сервис;

• для полного перезапуска всех сервисов компонента — перезапустить все сервисы компонента в последовательности, идентичной установке — см. раздел "Установка" Руководства по установке.

Перезапуск сервиса осуществляется в панели администрирования WildFly:

1. Откройте браузер и перейдите по адресу http://{wf-host}:9990/console

2. Перейдите во вкладку Deployments.

3. Выберите перезапускаемый сервис.

4. Нажмите Disable.

5. Нажмите Enable.

Изменение параметров настройки#

Для изменения параметров настройки требуется:

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

   1. Для настройки DPM — в файл standalone_dpm.xml, согласно разделу "Порядок установки DPM" Руководства по установке;

   2. Для настройки QGM — в файл standalone_qgm.xml, согласно разделу "Порядок установки QGM" Руководства по установке.

2. Перезапустить DPM и/или QGM — посредством перезапуска сервисов dpm-core и/или qgm-core, см. выше сценарий "Перезапуск".

Управление аппаратными ресурсами#

Контроль доступности и темпа расходования аппаратных ресурсов (прежде всего, свободного пространства в разделах для хранения БД, загрузки ЦП и памяти) осуществлять:

• посредством анализа метрик мониторинга, выдаваемых актуаторами (в т.ч. текущие размеры выделенного и свободного дискового пространства) — см. ниже раздел "События мониторинга";

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

• посредством ручного контроля — не реже 1 раза в сутки, или чаще в течение 10 дней непосредственно после установки и начала эксплуатации компонента и в случаях значительного изменения нагрузки.

Минимальный размер (резерв) свободного дискового пространства в разделах для хранения БД рекомендуется поддерживать согласно нормативным документам эксплуатирующей организации, а при отсутствии таковых — не меньшим, чем обеспечивающим расход в течение 15 дней в темпе, максимальном за последний год эксплуатации компонента.

Просмотр журналов#

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

Для просмотра журналов, ведущихся компонентом (журнала действий пользователя, журнала логов Jenkins job) требуется выполнить действия, перечисленные в настоящем Руководстве в соответствующем подразделе раздела "События системного журнала" и "События мониторинга".

Просмотр метрик мониторинга#

Просмотр метрик мониторинга может осуществляться:

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

• просмотр текущих значений метрик мониторинга:

  • метрик, отражающих состояние ОС, БД и доступность аппаратных ресурсов — средствами применяемых ОС и БД;

  • метрик, относящихся к работе компонента как сервиса Java — посредством непосредственного обращения к актуаторам — см. ниже раздел "События мониторинга".

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

На системном уровне компонент обеспечивает протоколирование ошибок, предупреждений и информационных сообщений — см. ниже раздел "События системного журнала ОС".

На прикладном уровне компонент обеспечивает протоколирование логов выполнения Jenkins job из DPM — см. ниже раздел "Просмотр логов выполненной Jenkins job из DPM".

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

Компонент обеспечивает протоколирование в системном журнале ОС информации о работе компонента и обнаруженных ошибках.

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

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

• ERROR — протоколирование только ошибок;

• WARN — протоколирование ошибок и предупреждений;

• INFO — протоколирование ошибок, предупреждений и дополнительной информации;

• DEBUG — протоколирование ошибок, предупреждений, дополнительной и отладочной информации.

Настройка уровня протоколирования выполняется в разделе системных настроек (system properties) панели администрирования WildFly http://{wf-host}:9990/console/index.html#system-properties параметром уровень протоколирования (logging level).

Настройки протоколирования сохраняются в файлах logback.spring и log4j2.xml.

События системного журнала ОС регистрируются в файлах:

• /var/log/syslog — события запуска процессов

• /usr/{WF-directory}/WF_DPM/standalone/log — события приложения

• accesslog — события доступа в WildFly, включая входы в панель администрирования

• $JBOSS_HOME/standalone/log/server.log или $JBOSS_HOME/standalone/log/{имя_сервиса}/server.log — все не перехваченные события (место хранения по умолчанию)

• папка QGS

• /var/log/messages — прочие сообщения

Перечень событий, регистрируемых в системном журнале#

Применяемые сокращения:

• AS — проект;

• FSS — приложение;

• RAO — сервис;

• RC — релиз-кандидат (РК).

Нижеперечисленные события протоколируются в файлах server.log.

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

Встроенные средства мониторинга#

Компонент содержит следующие собственные встроенные средства мониторинга.
В составе DPM и QGM реализованы актуаторы, обеспечивающие выдачу (по запросу от внешней системы, например Prometheus) информации о состоянии сервисов.
Актуаторы обеспечивают выдачу следующей информации при обращении по соответствующим URL (ниже <адрес сервиса> = DNS-имя или IP-адрес сервиса), на примере QGM:

• перечень типов выдаваемой информации и URL соответствующих актуаторов — http://<DNS-имя или IP-адрес>:8080/qgm/actuator

• текущая версия компонента — http://<DNS-имя или IP-адрес>:8080/qgm/actuator/info

• состояние компонента — http://<DNS-имя или IP-адрес>:8080/qgm/actuator/health

В перечне типов выдаваемой информации возвращаются:

• тип информации

• URL для запроса соответствующей информации

Пример ответа актуатора с перечнем типов выдаваемой информации (на примере QGM):

{
  "_links": {
    "self": {
      "href": "http://<DNS-имя или IP-адрес>:8080/qgm/actuator",
      "templated": false
    },
    "health": {
      "href": "http://<DNS-имя или IP-адрес>:8080/qgm/actuator/health",
      "templated": false
    },
    "health-path": {
      "href": "http://<DNS-имя или IP-адрес>:8080/qgm/actuator/health/{*path}",
      "templated": true
    },
    "info": {
      "href": "http://<DNS-имя или IP-адрес>:8080/qgm/actuator/info",
      "templated": false
    }
  }
}

Пример ответа актуатора с информацией о текущей версии компонента (на примере QGM):

{
  "version":"<номер версии и дата и время сборки (*)>",
  "artifactId":"qgm"
}

(*) дата и время сборки возвращаются целым числом (время эпохи Unix = число миллисекунд с 1970-01-01 00:00:00+00)

В информации о состоянии компонента возвращаются значения метрик мониторинга:

Пример ответа актуатора с информацией о состоянии компонента (на примере QGM):

{
  "status": "UP",
  "components": {
    "db": {
      "status": "UP",
      "details": {
        "database": "PostgreSQL",
        "validationQuery": "isValid()"
      }
    },
    "discoveryComposite": {
      "status": "UP",
      "components": {
        "discoveryClient": {
          "status": "UP",
          "details": {
            "services": [
              "qg-applicability-service",
              "dpm-mail",
              "dpm-core",
              "dpm-processing",
              "dpm-eureka",
              "dpm-auth",
              "qg-elk-service",
              "dpm-artifact-sync",
              "dpm-jenkins-log",
              "dpm-atlassian-integration",
              "dpm-relay",
              "qg-core",
              "qg-eureka",
              "qg-validation-service"
            ]
          }
        },
        "eureka": {
          "description": "Remote status from Eureka server",
          "status": "UP",
          "details": {
            "applications": {
              "QG-APPLICABILITY-SERVICE": 1,
              "DPM-MAIL": 1,
              "DPM-CORE": 1,
              "QG-CORE": 1,
              "QG-VALIDATION-SERVICE": 1,
              "DPM-PROCESSING": 1,
              "DPM-EUREKA": 1,
              "DPM-AUTH": 1,
              "QG-ELK-SERVICE": 1,
              "QG-EUREKA": 1,
              "DPM-ARTIFACT-SYNC": 1,
              "DPM-JENKINS-LOG": 1,
              "DPM-ATLASSIAN-INTEGRATION": 1,
              "DPM-RELAY": 1
            }
          }
        }
      }
    },
    "diskSpace": {
      "status": "UP",
      "details": {
        "total": <возвращенное значение>,
        "free": <возвращенное значение>,
        "threshold": <возвращенное значение>,
        "exists": true
      }
    },
    "hystrix": {
      "status": "UP"
    },
    "ping": {
      "status": "UP"
    },
    "refreshScope": {
      "status": "UP"
    }
  }
}

Дополнительные средства мониторинга#

Поскольку основными составляющими компонента являются Java сервисы и БД — для мониторинга работы программно-аппаратных средств могут применяться типовые решения мониторинга работы оборудования, Java сервисов и БД, допустимые согласно регламентирующим документам организации, эксплуатирующей компонент.

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

Типовые проблемы не выявлены.

В случае общих ошибок (проявляющихся для пользователей в виде сообщений об ошибках или ошибках с кодом 500, преимущественно при попытке выполнения операций, предполагающих запись или изменение информации в БД, в частности, создания объектов или изменения свойств объектов) следует проверить:

• Наличие свободного пространства в разделах для хранения БД — см. выше подраздел "Управление аппаратными ресурсами" раздела "Сценарии администрирования". В случае отсутствия свободного дискового пространства следует:

  • обеспечить наличие свободного дискового пространства в разделах для хранения БД — согласно руководству по администрированию используемых ОС и БД;

  • перезагрузить компонент согласно разделу "Перезапуск" настоящего руководства.