Не удалось создать сеанс трассировки

Вы просматриваете документацию Apigee Edge .
Перейдите к документации Apigee X. информация

Симптом

Пользователь не может создать сеанс трассировки в пользовательском интерфейсе Edge.

Сообщение об ошибке

Вы получите сообщение об ошибке в пользовательском интерфейсе Edge, как показано ниже:

Error creating trace session for API proxy <api proxy name>, revision <revision number>, environment <environment name>.
Failed to create DebugSession <session number>

Вот снимок экрана с примером сообщения об ошибке, наблюдаемого в пользовательском интерфейсе Edge:

Возможные причины

Некоторые из возможных причин этой ошибки перечислены ниже:

Причина Описание Инструкции по устранению неполадок применимы для
Проблема с сетевым подключением Сбой связи между сервером управления и процессором сообщений из-за проблем с сетевым подключением или правил брандмауэра. Пользователи Edge частного облака
Среда не загружена в процессор сообщений Конкретная среда (в которой вы пытаетесь включить трассировку) не была загружена в процессор(ы) сообщений из-за ошибки.
Устаревшие записи процессора сообщений Сервер управления имеет ссылку на несуществующие (устаревшие) процессоры сообщений.
Процессор сообщений недоступен Процессор сообщений остановлен или стал недоступен.
Проблема с высоким использованием ресурсов Процессоры сообщений испытывают высокую загрузку ресурсов (ЦП, памяти или нагрузки).
Прокси-сервер API не развернут на одном или нескольких процессорах сообщений. Прокси-сервер API не может быть развернут на одном или нескольких процессорах сообщений из-за отсутствия уведомления о событии во время развертывания.
Проблема с пользовательским интерфейсом Edge Пользовательскому интерфейсу Edge не удалось создать сеанс трассировки из-за какой-то ошибки.

Общие этапы диагностики

  1. Выполните этот API управления:

    curl -v <management-server-host>:8080/v1/runtime/organizations/<org-name>/environments/<env-name>/apis/<apiproxy-name>/revisions/<revision-number>/debugsessions -u <user>

  2. Если вы обнаружите какие-либо ошибки, обратите на них внимание. Перейдите к разделу «Проблема с сетевым подключением» .

  3. Если вы получите успешный ответ, это означает, что сеанс трассировки можно создать через Management API. Однако возможна проблема с пользовательским интерфейсом Edge, из-за которой в пользовательском интерфейсе невозможно создать сеанс трассировки. Перейдите к разделу «Проблема с пользовательским интерфейсом Edge» .

Причина: Проблема с сетевым подключением.

Диагностика

  1. Проверьте журнал сервера управления /opt/apigee/var/log/edge-management-server/logs/system.log и проверьте, нет ли ошибок во время создания сеанса трассировки/отладки.

    Пример ошибки из журнала сервера управления

    2018-02-08 09:08:21,310 org:myorg env:uat  qtp1073741635-1074 ERROR DISTRIBUTION - DebugSessionAPI.createDebugSession() : createDebugSession : Unable to connect to the server with UUID cedeabd2-e4d1-40bb-8f18-d6afc8835e5b
org.apache.http.conn.HttpHostConnectException: Connect to 10.84.75.92:8082 [/10.84.75.92] failed: Connection refused
    at org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:140) ~[httpclient-4.3.5.jar:4.3.5]
    at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:318) ~[httpclient-4.3.5.jar:4.3.5]
    at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:363) ~[httpclient-4.3.5.jar:4.3.5]
...<snipped>
Caused by: java.net.ConnectException: Connection refused
    at java.net.PlainSocketImpl.socketConnect(Native Method) ~[na:1.8.0_65]
    at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) ~[na:1.8.0_65]
...<snipped>

  2. Пример ошибки выше показывает, что мы получаем ошибки «Соединение отклонено», когда сервер управления пытается подключиться к процессору сообщений через порт № 8082. Следовательно, сервер управления не может создать сеанс трассировки.

  3. Если вы не видите ошибок, связанных с сетевым подключением, или ошибок, аналогичных показанным в приведенном выше примере, перейдите в среду, не загруженную в процессор сообщений .

  4. Если вы заметили ошибки, связанные с сетевым подключением, или ошибку, аналогичную той, что показана в приведенном выше примере, выполните следующие действия.

  5. Проверьте подключение сервера управления к процессору сообщений через порт 8082, выполнив следующие действия:

    1. Если доступен telnet, используйте telnet:

      telnet <MessageProcessor_IP> 8082

    2. Если telnet недоступен, используйте netcat для проверки соединения следующим образом:

      nc -vz <MessageProcessor_IP> 8082

    3. Если вы получили ответ «Соединение отклонено» или «Время ожидания соединения истекло», перейдите к следующему шагу.

  6. Войдите в каждый из процессоров сообщений с соответствующим IP-адресом, на котором возникла ошибка, и выполните следующие шаги:

    1. Проверьте, прослушивает ли процессор сообщений порт 8082:

      netstat -an | grep LISTEN | grep 8082

    2. Если процессор сообщений прослушивает порт 8082, перейдите к шагу №7.

    3. Если процессор сообщений не прослушивает порт 8082, перезапустите процессор сообщений с помощью этой команды:

      /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

    4. Подождите, пока процессор сообщений полностью не начнет использовать эту команду:

      /opt/apigee/apigee-service/bin/apigee-service edge-message-processor wait_for_ready

    5. После включения процессора сообщений еще раз проверьте, прослушивает ли процессор сообщений порт 8082.

    6. Если процессор сообщений прослушивает порт 8082, перейдите к шагу №7.

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

  8. Если процессор сообщений работает и прослушивает порт 8082, но вы по-прежнему не можете подключиться с других серверов, таких как сервер управления, то, вероятно, существует брандмауэр, который должен блокировать внешние соединения.

  9. Используйте соответствующую команду для проверки правил брандмауэра. Например, вы можете выполнить команду iptables, чтобы просмотреть все правила брандмауэра, определенные в вашей системе:

    iptables -L -n

  10. Если для порта 8082 не установлены правила брандмауэра, перейдите к разделу «Проблема с высоким использованием ресурсов» .

  11. Если на порту 8082 настроены какие-либо правила брандмауэра, перейдите в раздел «Разрешение» ниже.

Разрешение

  1. Обратитесь к своему сетевому администратору, чтобы разрешить входящий/исходящий трафик через порт 8082 с внешних серверов.

Если проблема не устранена, перейдите к разделу «Необходимо собрать диагностическую информацию» .

Причина: среда не загружена в процессор сообщений.

Диагностика

  1. Проверьте журналы сервера управления /opt/apigee/var/log/edge-management-server/logs/system.log и проверьте, нет ли ошибок во время создания сеанса трассировки/отладки.

  2. Во время создания сеанса трассировки/отладки вы можете увидеть сообщение об ошибке типа « нет действительных ответов от MP(ов) », как показано ниже:

    2018-01-30 08:28:09,721 org:mynonprod env:uat  qtp2007599722-712162 ERROR DISTRIBUTION - DebugSessionAPI.createDebugSession() : no valid responses from MP(s), throwing error
2018-01-30 08:28:09,723 org:mynonprod env:uat  qtp2007599722-712162 ERROR REST - CustomJAXRSInvoker.performInvocation() : CustomJAXRSInvoker.performInvocation : Method com.apigee.distribution.DebugSessionAPI.createDebugSession threw an exception.
2018-01-30 08:28:09,724 org:mynonprod env:uat  qtp2007599722-712162 ERROR REST - ExceptionMapper.toResponse() : Error occurred : Failed to create DebugSession 1517297564678
2018-01-30 08:28:09,724 org:mynonprod env:uat  qtp2007599722-712162 ERROR REST - ExceptionMapper.toResponse() : Returning error response : ErrorResponse{errorCode = distribution.CreateDebugSessionFailed, errorMessage = Failed to create DebugSession 1517297564678}

    Эта ошибка указывает на то, что процессор(ы) сообщений по какой-то причине не отвечают серверу управления.

  3. Если вы не видите ошибку, аналогичную той, что показана в приведенном выше примере, перейдите к Stale Message Processor Entries .

  4. Если вы заметили ошибку, аналогичную той, что показана в приведенном выше примере, выполните следующие действия.

  5. Одной из наиболее вероятных причин этой ошибки является то, что среда, в которой вы пытаетесь создать сеанс трассировки, не загружена в процессор(ы) сообщений.

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

    curl -s http://localhost:8082/v1/runtime/organizations/<org-name>/environments

    Пример вывода:

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

    [ "препрод", "тест"]

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

  8. Если конкретная среда, скажем «dev», не указана в приведенной выше команде, проверьте файлы /opt/apigee/var/log/edge-message-processor/logs/system.log и /opt/apigee/var/log/edge-message-processor/logs/startupruntimeerrors.log в процессорах сообщений на предмет любых ошибок во время загрузки сред.

  9. Может возникнуть множество различных ошибок, которые могут привести к сбою загрузки среды в процессор сообщений. Решение зависит от возникшей ошибки.

Разрешение

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

  1. Если вы видите одну из следующих ошибок в журнале процессора сообщений, это вызвано проблемой, обнаруженной с сертификатами/ключами, которые были добавлены в указанное хранилище ключей/доверенное хранилище в указанной среде.

    Ошибка № 1: java.security.KeyStoreException: невозможно перезаписать собственный сертификат.

    2018-01-30 12:04:38,248 pool-47-thread-4 ERROR MESSAGING.RUNTIME - AbstractConfigurator.propagateEvent() : Error while handling the update for the Configurator 
com.apigee.kernel.exceptions.spi.UncheckedException: Failed to add certificate : mycert in key store : mytruststore in environment : test
at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:156) ~[config-entities-1.0.0.jar:na] 
at com.apigee.entities.configurators.KeyStore.handleUpdate(KeyStore.java:101) ~[config-entities-1.0.0.jar:na] 
at com.apigee.entities.AbstractConfigurator.propagateEvent(AbstractConfigurator.java:85) ~[config-entities-1.0.0.jar:na] 
at com.apigee.messaging.runtime.Environment.handleUpdate(Environment.java:238) [message-processor-1.0.0.jar:na] 
… 
Caused by: java.security.KeyStoreException: Cannot overwrite own certificate 
at com.sun.crypto.provider.JceKeyStore.engineSetCertificateEntry(JceKeyStore.java:355) ~[sunjce_provider.jar:1.8.0_151] 
at java.security.KeyStore.setCertificateEntry(KeyStore.java:1201) ~[na:1.8.0_151] 
at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:153) ~[config-entities-1.0.0.jar:na]
... 20 common frames omitted
2018-01-30 12:04:38,250 pool-47-thread-4 ERROR MESSAGING.RUNTIME - AbstractConfigurator.rollbackTransaction() : Error in processing the changes : Unknown resource type cert

    Ошибка № 2: java.security.KeyStoreException: невозможно перезаписать секретный ключ.

    2017-11-01 03:28:47,560 pool-21-thread-7 ERROR MESSAGING.RUNTIME - AbstractConfigurator.propagateEvent() : Error while handling the update for the Configurator 
com.apigee.kernel.exceptions.spi.UncheckedException: Failed to add certificate : mstore in key store : myTruststore in environment : dev 
at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:156) ~[config-entities-1.0.0.jar:na] 
at com.apigee.entities.configurators.KeyStore.handleUpdate(KeyStore.java:101) ~[config-entities-1.0.0.jar:na] 
... 
Caused by: java.security.KeyStoreException: Cannot overwrite secret key 
at com.sun.crypto.provider.JceKeyStore.engineSetCertificateEntry(JceKeyStore.java:354) ~[sunjce_provider.jar:1.8.0_144] 
at java.security.KeyStore.setCertificateEntry(KeyStore.java:1201) ~[na:1.8.0_144] 
at com.apigee.entities.configurators.KeyStore.setCertificateEntry(KeyStore.java:153) ~[config-entities-1.0.0.jar:na] 
... 20 common frames omitted 

2017-11-01 03:28:47,562 pool-21-thread-7 ERROR MESSAGING.RUNTIME - AbstractConfigurator.rollbackTransaction() : Error in processing the changes : Unknown resource type cert

  2. Получите сведения о хранилище ключей/хранилище доверенных сертификатов, указанном в сообщении об ошибке, показанное на предыдущем шаге, с помощью следующего вызова API управления:

    curl -v "http://<management-IPaddress>:8080/v1/organizations/<org-name>/environments/<env-name>/keystores/myTruststore" -u <user>

    Пример вывода:

    { 
"certs": [ 
"mycert", 
"mycert-new" 
], 
"keys": [ 
"mycert" 
], 
"name": "myTruststore" 
}

  3. Выходные данные примера показывают, что в хранилище доверенных сертификатов myTruststore есть два сертификата и ключ. Хранилище доверенных сертификатов обычно не содержит ключа. Если да, то лучше иметь один сертификат и один ключ.

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

    curl -s http://<management-IPaddress>:8080/v1/runtime/organizations/<org-name>/environments/<env-name>/keystores/<keystore-name>/certs/<cert-name>

  5. Проверьте дату истечения срока действия каждого сертификата и определите сертификат с истекшим сроком действия или более старый.

  6. Удалите просроченный или нежелательный сертификат из хранилища доверенных сертификатов «myTruststore».

Если проблема по-прежнему сохраняется или вы видите какую-либо ошибку, кроме упомянутых в шаге № 1 выше, перейдите к разделу «Необходимо собрать диагностическую информацию» .

Причина: устаревшие записи процессора сообщений ИЛИ процессоры сообщений недоступны.

Диагностика

  1. Если пользовательский интерфейс Edge занимает много времени и не может создать сеанс трассировки, вот некоторые из возможных причин:
    1. Сервер управления может ссылаться на несуществующие (устаревшие) процессоры сообщений.
    2. Процессор(ы) сообщений остановлен или стал недоступен
    3. Процессоры сообщений сильно используют память/ЦП.
  2. Проверьте журналы сервера управления /opt/apigee/var/log/edge-management-server/logs/system.log и проверьте, нет ли ошибок при создании сеанса трассировки/отладки.

  3. Вы можете увидеть сообщение об ошибке, например «сервер <UUID> либо недоступен, либо недоступен» во время создания сеанса трассировки/отладки, как показано ниже:

    2017-12-27 07:42:38,975 org:cocacola env:prod qtp2007599722-222063 INFO DISTRIBUTION - DebugSessionAPI.createDebugSession() : server 458b5910-2646-441c-a6e2-428b6d84e021 is either not up or reachable, skipping the server

    Через некоторое время может последовать еще одна ошибка «Тайм-аут соединения», как показано ниже:

    2017-12-27 07:44:46.000 UTC org:cocacola env:prod qtp2007599722-222063 ERROR DISTRIBUTION - DebugSessionAPI.createDebugSession() : createDebugSession : Unable to connect to the server with UUID {}, skipping it458b5910-2646-441c-a6e2-428b6d84e021 org.apache.http.conn.HttpHostConnectException: Connect to 192.168.101.7:8080 [/192.168.101.7] failed: Connection timed out (Connection timed out) at org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:140) ~[httpclient-4.3.5.jar:4.3.5] at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:318) ~[httpclient-4.3.5.jar:4.3.5] at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:363) ~[httpclient-4.3.5.jar:4.3.5] at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:219) ~[httpclient-4.3.5.jar:4.3.5] 
…<snipped>
Caused by: java.net.ConnectException: Connection timed out (Connection timed out) at java.net.PlainSocketImpl.socketConnect(Native Method) ~[na:1.8.0_144] at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) ~[na:1.8.0_144]
…<snipped>

  4. Эти две ошибки могут быть вызваны либо определенными процессорами сообщений:

    1. Быть устаревшим (больше не существующим)
    2. Недоступен/не доступен по какой-то причине

  5. Пожалуйста, следуйте соответствующему решению в зависимости от возникшего сценария.

Разрешение

Сценарий № 1. Процессоры сообщений устарели (не существуют).

  1. Получите список обработчиков сообщений, используя приведенный ниже API управления:

    curl -u <sysadmin> "http://<management-server-host>:8080/v1/servers?pod=<podName>&regions=<regionName>"

  2. Запишите IP-адрес или имя хоста, которые соответствуют UUID процессоров сообщений, упомянутых в сообщении об ошибке в журналах сервера управления (шаг № 3 в разделе «Диагностика» выше). Убедитесь, что это действительные процессоры сообщений, используя один из следующих способов:

    1. Последняя схема настройки топологии частного облака
    2. Последний IP-адрес пограничного сервера — таблица сопоставления имен хостов

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

  3. Удалите устаревшие (несуществующие) процессоры сообщений, используя указанные ниже API управления:

    1. Отмените регистрацию процессора сообщений в средах организации:

      curl -X POST http://<management-server-host>:8080/v1/o/<orgName>/e/<envName>/servers -d "uuid={uuid}&region=<regionName>&pod=<podName}&action=remove"

    2. Отменить регистрацию типа сервера:

      curl http://<management-server-host>:8080/v1/servers -X POST -d "type={message-processor}&region=<regionName>&pod=<podName>&uuid=<uuid>&action=remove"

    3. Удалить сервер:

      curl http://<management-ip>:8080/v1/servers/<uuid> -X DELETE

  4. Повторите шаг №3, если у вас возникла такая же проблема в любой другой среде вашей организации.

Сценарий 2: процессор(ы) сообщений недоступен.

  1. Войдите в каждый процессор сообщений, определив IP-адреса/имена хостов на основе UUID, наблюдаемых в сообщении об ошибке в журналах сервера управления.

  2. Перезапустите процессор сообщений:

    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

Еще раз проверьте, можете ли вы создать сеанс трассировки. Если проблема не устранена, перейдите к разделу «Необходимо собрать диагностическую информацию» .

Причина: проблема с высоким уровнем использования ресурсов.

Диагностика

  1. Войдите в каждый из процессоров сообщений и проверьте, нет ли высокой загрузки каких-либо ресурсов — ЦП, памяти или нагрузки. Вы можете использовать команду top в операционных системах на базе Unix, чтобы получить информацию об использовании ресурсов процесса процессора сообщений:

    top

  2. Если процессор(ы) сообщений не испытывают высокой загрузки ресурсов, перейдите к разделу «Необходимо собрать диагностическую информацию» .

  3. Если процессор(ы) сообщений испытывают высокую загрузку ЦП или памяти, это может быть причиной того, что процессор сообщений не отвечает вовремя серверу управления. В конечном итоге это лишает вас возможности создать сеанс трассировки.

    1. Если какой-либо процессор сообщений испытывает высокую загрузку ЦП, создайте три дампа потока каждые 30 секунд, используя следующую команду:

      sudo <JAVA_HOME>/bin/jstack -l <pid> > <filename>

    2. Если какой-либо процессор сообщений сильно использует память, создайте дамп кучи с помощью следующей команды:

      sudo -u apigee <JAVA_HOME>/bin/jmap -dump:live,format=b,file=<filename> <pid>

    3. Перейдите к разрешению.

Разрешение

  1. Перезапустите процессор сообщений, используя приведенную ниже команду. Это должно снизить использование процессора и памяти:

    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

  2. Отслеживайте вызовы API и подтвердите, существует ли проблема.

  3. Свяжитесь со службой поддержки Apigee Edge и предоставьте дампы потоков, дамп кучи и журналы процессора сообщений ( /opt/apigee/var/log/edge-message-processor/logs/system.log) чтобы помочь им выяснить причину высокой загрузки ЦП. использование памяти.

Причина: прокси-сервер API не развернут на одном или нескольких процессорах сообщений.

В редких случаях прокси-сервер API не может быть развернут на одном или нескольких процессорах сообщений. Это происходит в основном из-за отсутствия уведомления о событии от сервера управления к процессору сообщений во время развертывания конкретного прокси-сервера API. В этом случае вы также не сможете создать сеанс трассировки в пользовательском интерфейсе Edge.

Диагностика

  1. Войдите в каждый из процессоров сообщений и проверьте, развернута ли конкретная версия прокси-сервера API, с помощью следующей команды:

    curl -v localhost:8082/v1/runtime/organizations/<orgname>/environments/<envname>/apis/<apiname>/revisions

    Пример вывода:

    Вы увидите список редакций в результате выполнения приведенной выше команды. Например, если развернута версия 12, вы увидите следующий результат:

    [ "12" ]

  2. Если конкретная версия прокси-сервера API не отображается в выходных данных команды, упомянутой в шаге № 1 выше, перезапустите конкретный процессор сообщений, как описано в решении ниже.

  3. Повторите шаги 1–2 для всех процессоров сообщений.

  4. Если определенная версия прокси-сервера API развернута на всех процессорах сообщений, это не является причиной данной проблемы. Перейдите к разделу «Необходимо собрать диагностическую информацию» .

Разрешение

  1. Перезапустите определенные процессоры сообщений, на которых не развернута конкретная версия прокси-сервера API: 

    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

Причина: проблема с пользовательским интерфейсом Edge.

Диагностика

  1. Проверьте журналы пользовательского интерфейса Edge /opt/apigee/var/log/edge-ui/application.log и /opt/apigee/var/log/edge-ui/edge-ui.log и проверьте, нет ли ошибок.
  2. Свяжитесь со службой поддержки Apigee Edge и поделитесь этими файлами для дальнейшего изучения.

Необходимо собрать диагностическую информацию

Если проблема не устранена даже после выполнения приведенных выше инструкций, соберите следующую диагностическую информацию. Свяжитесь со службой поддержки Apigee Edge и поделитесь ими:

  1. Вывод команды:

    curl -v <management-server-host>:8080/v1/runtime/organizations/<org-name>/environments/<env-name>/apis/<apiproxy-name>/revisions/<revision-number>/debugsessions -u <user>

  2. Журнал сервера управления

    /opt/apigee/var/log/edge-management-server/logs/system.log.

  3. Журналы процессора сообщений

    /opt/apigee/var/log/edge-message-processor/logs/system.log.

  4. Вывод команд telnet/nc с сервера управления на процессор сообщений:

    telnet <MessageProcessor_IP> 8082
nc -vz <MessageProcessor_IP> 8082

  5. Вывод приведенной ниже команды netstat для процессоров сообщений:

    netstat -an > netstat.txt

  6. Если обнаружено, что проблема связана с пользовательским интерфейсом Edge, предоставьте журналы пользовательского интерфейса Edge /opt/apigee/var/log/edge-ui/application.log и /opt/apigee/var/log/edge-ui/edge-ui.log.

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