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

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

Симптом

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

No traffic in the selected date range

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

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

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

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

Причина Для
Отсутствие API-трафика для организационной среды Edge для пользователей частного облака
Данные доступны в базе данных PostgreSQL, но не отображаются в пользовательском интерфейсе. Edge для пользователей частного облака
Аналитические данные не передаются в базу данных PostgreSQL. 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, но не отображаются в пользовательском интерфейсе» .

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

Симптом

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

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

  1. Войдите на каждый из серверов Postgres и выполните следующую команду, чтобы убедиться, что вы находитесь на главном узле Postgres: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-master
  2. На главном узле PostgreSQL войдите в 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 .

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

Диагноз

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

  1. Проверьте, запущен ли каждый из серверов Qpid, выполнив следующую команду: 
    /opt/apigee/apigee-service/bin edge-qpid-server status
  2. Если какой-либо из серверов Qpid недоступен, перезапустите его. В противном случае перейдите к шагу №5. 
    /opt/apigee/apigee-service/bin 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)

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

Разрешение

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

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

Если проблема не исчезнет, ​​обратитесь в службу поддержки 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 отображается как "SUCCESS", это означает, что серверы аналитики подключены правильно. Перейдите к разделу "Устаревшие UUID серверов аналитики" .
    2. Если статус серверов Qpid/Postgres отображается как "UNKNOWN" или "FAILURE", это указывает на проблему с соответствующим сервером.

      Например, в следующем сценарии статус серверов Postgres отображается как "UNKNOWN":

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

Разрешение

Как правило, эту проблему можно решить перезапуском серверов, на которых отображалось сообщение "FAILURE" или "UNKNOWN".

  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. Если проблема наблюдается на серверах PostgreSQL, перезапустите главный и подчиненный узлы сервера PostgreSQL: 
      /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart
  3. В приведенном выше примере для серверов Postgres отображается сообщение "UNKNOWN", поэтому необходимо перезапустить как главный, так и подчиненный серверы 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. Если вся информация верна, переходите к разделу «Аналитические данные не передаются в базу данных PostgreSQL» .
  4. Если UUID серверов Postgres и/или Qpid указаны неверно, то возможно, что серверы управления используют устаревшие UUID.

Разрешение

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