Данные не отображаются на панелях аналитики

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

Симптом

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

No traffic in the selected date range

Сообщения об ошибках

Эта проблема не приводит к наблюдаемым ошибкам.

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

В следующей таблице перечислены возможные причины этой проблемы:

Причина Для
Нет трафика API для организации-среды Edge для пользователей частного облака
Данные доступны в базе данных Postgres, но не отображаются в пользовательском интерфейсе. Edge для пользователей частного облака
Аналитические данные не передаются в базу данных Postgres Edge для пользователей частного облака
Неправильное развертывание аналитики Edge для пользователей частного облака
Устаревшие UUID сервера аналитики Edge для пользователей частного облака

Нет трафика API для организации-среды

Диагностика

  1. Проверьте, есть ли трафик для прокси-серверов API в конкретной среде организации в течение определенного периода времени, в течение которого вы пытаетесь просмотреть аналитические данные, используя один из следующих методов:
    1. Включите трассировку для любого из ваших API, которые в настоящее время используются вашими пользователями, и проверьте, можете ли вы получать какие-либо запросы в трассировке.
    2. Просмотрите журналы доступа NGINX ( /opt/apigee/var/log/edge-router/nginx/logs/access.log) и проверьте, есть ли какие-либо новые записи для прокси-серверов API за определенный период.
    3. Если вы записываете информацию с прокси-серверов API на сервер журналов, такой как Syslog, Splunk, Loggly и т. д., вы можете проверить, есть ли на этих серверах журналов какие-либо записи для прокси-серверов API за определенный период времени.
  2. Если в течение определенного периода времени нет трафика (нет запросов к API), данные аналитики недоступны. На панели аналитики вы увидите «Нет трафика в выбранном диапазоне дат».

Разрешение

  1. Сделайте несколько вызовов к одному или нескольким прокси-серверам API в конкретной среде организации.
  2. Подождите несколько секунд, а затем просмотрите панели аналитики на вкладке «Час» и посмотрите, появятся ли данные.
  3. Если проблема не устранена, перейдите к разделу «Данные доступны в базе данных Postgres, но не отображаются в пользовательском интерфейсе» .

Данные доступны в базе данных Postgres, но не отображаются в пользовательском интерфейсе.

Симптом

Сначала определите доступность последних данных Analytics в базе данных Postgres.

Чтобы проверить, доступны ли последние данные Analytics в главном узле Postgres:

  1. Войдите на каждый из серверов Postgres и выполните следующую команду, чтобы проверить, находитесь ли вы на главном узле Postgres: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-master
  2. На узле Master Postgres войдите в PostgreSQL: 
    psql -h /opt/apigee/var/run/apigee-postgresql -U apigee apigee
  3. Проверьте, существует ли таблица для вашей среды организации, используя следующий SQL-запрос в базе данных Postgres: 
    \d analytics."orgname.envname.fact"
  4. Проверьте, доступны ли последние данные в базе данных Postgres, используя следующий SQL-запрос: 
    select max(client_received_start_timestamp) from analytics."orgname.envname.fact";
  5. Если последняя временная метка очень старая (или равна нулю), это означает, что данные недоступны в базе данных Postgres. Вероятная причина этой проблемы заключается в том, что данные не передаются с сервера Qpid в базу данных Postgres. Перейдите к разделу «Данные аналитики не передаются в базу данных Postgres» .
  6. Если последние данные доступны в базе данных Postgres на главном узле, выполните следующие действия, чтобы определить, почему данные не отображаются в пользовательском интерфейсе Edge.

Диагностика

  1. Включите инструменты разработчика в браузере Chrome и получите используемый API с одной из аналитических панелей, выполнив следующие действия:
    1. Выберите вкладку «Сеть» в инструментах разработчика.
    2. Начать запись.
    3. Перезагрузите панель аналитики.
    4. На левой панели инструментов разработчика выберите строку с надписью «apiproxy?_optimized...».
    5. На правой панели инструментов разработчика выберите вкладку «Заголовки» и обратите внимание на «URL-адрес запроса».
  2. Вот пример вывода инструментов разработчика:

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

  3. Запустите вызов API управления напрямую и проверьте, получаете ли вы результаты. Вот пример вызова API для вкладки «День» на панели мониторинга «Производительность прокси»: 
    curl -u username:password
  "http://management_server_IP_address:8080/v1/organizations/
  org_name/environments/env_name/stats/apiproxy?limit=14400&
  select=sum(message_count),sum(is_error),avg(total_response_time),
  avg(target_response_time)&sort=DESC&sortby=sum(message_count),sum(is_error),
  avg(total_response_time),avg(target_response_time)&timeRange=08%2F9%2F2017+
  18:00:00~08%2F10%2F2017+18:00:00&timeUnit=hour&tsAscending=true"
  4. Если вы видите успешный ответ, но без каких-либо данных, это означает, что сервер управления не может получить данные с сервера Postgres из-за проблем с сетевым подключением.
  5. Проверьте, можете ли вы подключиться к серверу Postgres с сервера управления: 
    telnet Postgres_server_IP_address 5432
  6. Если вы не можете подключиться к серверу Postgres, проверьте, есть ли какие-либо ограничения брандмауэра на порт 5432.
  7. Если существуют ограничения брандмауэра, это может быть причиной того, что сервер управления не может получить данные с сервера Postgres.

Разрешение

  1. Если существуют ограничения брандмауэра, удалите их, чтобы сервер управления мог взаимодействовать с сервером Postgres.
  2. Если ограничений брандмауэра нет, эта проблема может быть связана с сбоем сети.
  3. Если на сервере управления произошел какой-либо сетевой сбой, то его перезапуск может решить проблему.
  4. Перезапустите все серверы управления один за другим, используя следующую команду: 
    /opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
  5. Проверьте, можете ли вы видеть аналитические данные в пользовательском интерфейсе Edge.

Если вы по-прежнему не видите данные, обратитесь в службу поддержки Apigee Edge .

Аналитические данные не передаются в базу данных Postgres

Диагностика

Если данные не передаются с сервера Qpid в базу данных Postgres, как определено в разделе «Данные, доступные в базе данных Postgres», но не отображаются в пользовательском интерфейсе , выполните следующие шаги:

  1. Проверьте, работает ли каждый из серверов Qpid, выполнив следующую команду: 
    /opt/apigee/bin/apigee-service edge-qpid-server status
  2. Если какой-либо сервер Qpid не работает, перезапустите его. Если нет, перейдите к шагу №5. 
    /opt/apigee/bin/apigee-service edge-qpid-server restart
  3. Подождите некоторое время, а затем еще раз проверьте, доступны ли последние данные в базе данных Postgres.
    1. Войдите в PostgreSQL: 
      psql -h /opt/apigee/var/run/apigee-postgresql -U apigee apigee
    2. Запустите приведенный ниже SQL-запрос, чтобы проверить, доступны ли последние данные: 
      select max(client_received_start_timestamp) from analytics."orgname.envname.fact";
  4. Если доступны последние данные, пропустите следующие шаги и перейдите к последнему шагу в разделе «Решение». Если последние данные недоступны, выполните следующие действия.
  5. Проверьте, передаются ли сообщения из очередей сервера Qpid в базу данных Postgres.
    1. Выполните qpid-stat -q command и проверьте значения столбцов msgIn и msgOut .
    2. Вот пример вывода, который показывает, что msgIn и msgOut не равны. Это указывает на то, что сообщения не передаются с сервера Qpid в базу данных Postgres.

  6. Если есть несоответствие в столбцах msgIn и msgOut , проверьте журналы сервера Qpid /opt/apigee/var/log/edge-qpid-server/system.log и посмотрите, есть ли какие-либо ошибки.
  7. Вы можете увидеть сообщения об ошибках, такие как «Вероятно, PG все еще не работает» или «FATAL: извините, уже слишком много клиентов», как показано на рисунке ниже: 
    2017-07-28 09:56:39,896 ax-q-axgroup001-persistpool-thread-3
  WARN c.a.a.d.c.ServerHandle - ServerHandle.logRetry() : Found the exception to be
  retriable - . Error observed while trying to connect to
  jdbc:postgresql://PG_IP_address:5432/apigee Initial referenced UUID when
  execution started in this thread was a1ddf72f-ac77-49c0-a1fc-d0db6bf9991d
  Probably PG is still down. PG set used - [a1ddf72f-ac77-49c0-a1fc-d0db6bf9991d]
2017-07-28 09:56:39,896 ax-q-axgroup001-persistpool-thread-3
  WARN c.a.a.d.c.ServerHandle - ServerHandle.logRetry() : Could not get JDBC Connection;
  nested exception is org.postgresql.util.PSQLException: FATAL: sorry, too many clients already
2017-07-28 09:56:53,617 pool-7-thread-1
  WARN c.a.a.d.c.ServerHandle - ServerHandle.logRetry() : Found the exception to be
  retriable - . Error observed while trying to connect to
  jdbc:postgresql://PG_IP_address:5432/apigee
  Initial referenced UUID when execution started in this thread was
  a1ddf72f-ac77-49c0-a1fc-d0db6bf9991d Probably PG is still down. PG set used -
  [a1ddf72f-ac77-49c0-a1fc-d0db6bf9991d]
2017-07-28 09:56:53,617 pool-7-thread-1
  WARN c.a.a.d.c.ServerHandle - ServerHandle.logRetry() : Could not get JDBC Connection;
  nested exception is org.apache.commons.dbcp.SQLNestedException: Cannot create
  PoolableConnectionFactory (FATAL: sorry, too many clients already)

Это может произойти, если сервер Postgres выполняет слишком много запросов SQL или процессор перегружен и, следовательно, не может ответить серверу Qpid.

Разрешение

  1. Перезапустите сервер Postgres и PostgreSQL, как показано ниже: 
    /opt/apigee/bin/apigee-service edge-postgres-server restart

    /opt/apigee/bin/apigee-service apigee-postgresql restart
  2. Этот перезапуск гарантирует, что все предыдущие SQL-запросы остановлены и разрешат новые подключения к базе данных Postgres.
  3. Перезагрузите информационные панели Analytics и проверьте, отображаются ли данные Analytics.

Если проблема не устранена, обратитесь в службу поддержки Apigee Edge .

Неправильное развертывание аналитики

Диагностика

  1. Получите статус развертывания аналитики, используя следующий вызов API: 
    curl -u user_email:password http://management_server_host:port
/v1/organizations/orgname/environments/envname/provisioning/axstatus
  2. Проверьте состояние серверов Qpid и Postgres по результатам вызова API.
    1. Если статус серверов Qpid и Postgres отображается как «УСПЕХ», это означает, что серверы аналитики подключены правильно. Перейдите к UUID устаревшего аналитического сервера .
    2. Если статус серверов Qpid/Postgres отображается как «НЕИЗВЕСТНО» или «ОТКАЗ», это указывает на проблему с соответствующим сервером.

      Например, следующий сценарий показывает состояние серверов Postgres как «НЕИЗВЕСТНО»:

      Это может произойти, если при подключении аналитики произошел сбой. Этот сбой не позволяет сообщениям с серверов управления достигать серверов Postgres.

Разрешение

Эту проблему обычно можно решить путем перезапуска серверов, на которых отображается сообщение «ОТКАЗ» или «НЕИЗВЕСТНО».

  1. Перезапустите каждый из серверов, состояние проводки аналитики которых указано «ОТКАЗ» или «НЕИЗВЕСТНО», используя следующую команду: 
    /opt/apigee/apigee-service/bin/apigee-service component restart
  2. Например:
    1. Если вы видите проблему на серверах Qpid, перезапустите серверы Qpid: 
      /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
    2. Если вы видите проблему на серверах Postgres, перезапустите узлы главного и подчиненного сервера Postgres: 
      /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart
  3. В приведенном выше примере для серверов Postgres отображается сообщение «НЕИЗВЕСТНО», поэтому вам необходимо перезапустить как главный, так и подчиненный серверы Postgres: 
    /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart

Устаревшие UUID сервера аналитики

Диагностика

  1. Получите конфигурацию аналитики, используя следующий вызов API:
    curl -u user_email:password http://management-server-host:port/v1/analytics/groups/ax

    Вот пример вывода вышеуказанного API: 

    [ {
  "name" : "axgroup001",
  "properties" : {
    "consumer-type" : "ax"
  },
  "scopes" : [ "myorg~prod", "myorg~test" ],
  "uuids" : {
    "aries-datastore" : [ ],
    "postgres-server" : [ "6777...2db14" ],
    "dw-server" : [ ],
    "qpid-server" : [ "774e...fb23", "29f3...8c11" ]
  },
  "consumer-groups" : [ {
    "name" : "consumer-group-001",
    "consumers" : [ "774e...8c11" ],
    "datastores" : [ "6777...db14" ],
    "properties" : {
    }
  } ],
  "data-processors" : {
  }
} ]
  2. Убедитесь, что следующая информация в выводе верна:
    1. Имена org-env, перечисленные в элементе «scopes».
    2. UUID серверов Postgres и серверов Qpid.
      • Получите UUID сервера Postgres, выполнив следующую команду на каждом из узлов сервера Postgres: 
        curl 0:8084/v1/servers/self/uuid
      • Получите UUID сервера Qpid, выполнив следующую команду на каждом из узлов сервера Qpid: 
        curl 0:8083/v1/servers/self/uuid
  3. Если вся информация верна, перейдите к разделу «Данные аналитики не передаются в базу данных Postgres» .
  4. Если UUID серверов Postgres и/или Qpid неверны, возможно, серверы управления ссылаются на устаревшие UUID.

Разрешение

Чтобы удалить устаревшие UUID и добавить правильные UUID серверов, обратитесь в службу поддержки Apigee Edge .