נתונים לא מופיעים במרכזי בקרה של Analytics

אתם צופים במסמכי התיעוד של Apigee Edge.
כדאי לעיין במסמכי התיעוד של Apigee X. מידע

תיאור הבעיה

במרכזי הבקרה של ניתוח הנתונים (Proxy Performance,‏ Target Performance וכו') לא מוצגים נתונים בממשק המשתמש החדש של Edge. בכל מרכזי הבקרה מופיעה ההודעה הבאה:

No traffic in the selected date range

הודעות שגיאה

הבעיה הזו לא גורמת לשגיאות שאפשר לראות.

גורמים אפשריים

בטבלה הבאה מפורטות הסיבות האפשריות לבעיה הזו:

סיבה עבור
No API Traffic for Organization-Environment משתמשי Edge for Private Cloud
הנתונים זמינים במסד הנתונים של Postgres, אבל לא מוצגים בממשק המשתמש החדש של Edge משתמשי Edge for Private Cloud
נתוני Analytics לא מועברים למסד נתונים של Postgres משתמשי Edge for Private Cloud
פריסה שגויה של Analytics משתמשי Edge for Private Cloud
מזהי UUID של שרת Analytics שהנתונים שלהם לא עדכניים משתמשי Edge for Private Cloud

אין תנועת API בסביבה של הארגון

אבחון

  1. בודקים אם יש תנועה לשרתי ה-proxy ל-API בסביבה הספציפית של הארגון, למשך הזמן הספציפי שבו מנסים להציג את נתוני הניתוח, באחת מהשיטות הבאות:
    1. מפעילים את המעקב בכל אחד מממשקי ה-API שבהם המשתמשים משתמשים כרגע, ובודקים אם אפשר לקבל בקשות כלשהן במעקב.
    2. צריך לעיין ביומני הגישה של NGINX (/opt/apigee/var/log/edge-router/nginx/logs/access.log)) ולבדוק אם יש רשומות חדשות של proxy ל-API למשך הזמן הספציפי.
    3. אם אתם מבצעים רישום ביומן של מידע מ-proxy ל-API בשרת יומנים כמו Syslog,‏ Splunk,‏ Loggly וכו', תוכלו לבדוק אם יש רשומות בשרתי היומנים האלה לגבי proxy ל-API למשך זמן מסוים.
  2. אם אין תנועה (אין בקשות API) במשך פרק הזמן הספציפי, נתוני הניתוח לא זמינים. במרכז הבקרה של Analytics תופיע ההודעה "אין תנועה בטווח התאריכים שנבחר".

רזולוציה

  1. מבצעים כמה קריאות לשרת proxy אחד או יותר ל-API בסביבת הארגון הספציפית.
  2. ממתינים כמה שניות, ואז בודקים אם הנתונים מופיעים במרכזי הבקרה של Analytics בכרטיסייה Hour.
  3. אם הבעיה נמשכת, צריך לעבור אל הנתונים זמינים במסד הנתונים של Postgres, אבל לא מוצגים בממשק המשתמש החדש של Edge.

הנתונים זמינים במסד הנתונים של Postgres, אבל לא מוצגים בממשק המשתמש החדש של Edge

תיאור הבעיה

קודם כל, בודקים אם נתוני Analytics העדכניים זמינים במסד הנתונים של Postgres.

כדי לבדוק אם נתוני Analytics האחרונים זמינים בצומת הראשי של Postgres:

  1. מתחברים לכל אחד משרתי Postgres ומריצים את הפקודה הבאה כדי לבדוק אם אתם נמצאים בצומת הראשי של Postgres: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-master
  2. בצומת הראשי של Postgres, מתחברים ל-PostgreSQL: 
    psql -h /opt/apigee/var/run/apigee-postgresql -U apigee apigee
  3. כדי לבדוק אם הטבלה קיימת בסביבת הארגון, משתמשים בשאילתת ה-SQL הבאה במסד הנתונים של Postgres: 
    \d analytics."orgname.envname.fact"
  4. מריצים את שאילתת ה-SQL הבאה כדי לבדוק אם הנתונים העדכניים זמינים במסד הנתונים של Postgres: 
    select max(client_received_start_timestamp) from analytics."orgname.envname.fact";
  5. אם חותמת הזמן האחרונה ישנה מאוד (או null), זה מצביע על כך שהנתונים לא זמינים במסד הנתונים של Postgres. הסיבה הסבירה לבעיה הזו היא שהנתונים לא מועברים משרת Qpid למסד הנתונים של Postgres. עוברים אל נתוני Analytics לא נשלחים למסד הנתונים של Postgres.
  6. אם הנתונים העדכניים זמינים במסד הנתונים של Postgres בצומת הראשי, צריך לפעול לפי השלבים הבאים כדי לאבחן למה הנתונים לא מוצגים בממשק המשתמש החדש של Edge.

אבחון

  1. מפעילים את הכלים למפתחים בדפדפן Chrome ומקבלים את ה-API שבו נעשה שימוש מאחת מלוחות הבקרה של ניתוח הנתונים באמצעות השלבים הבאים:
    1. בוחרים בכרטיסייה 'רשת' מתוך 'כלים למפתחים'.
    2. אפשר ללחוץ כדי להתחיל בהקלטה.
    3. טוענים מחדש את מרכז הבקרה של Analytics.
    4. בחלונית הימנית של הכלים למפתחים, בוחרים בשורה עם apiproxy?_optimized...‎.
    5. בחלונית השמאלית של הכלים למפתחים, בוחרים בכרטיסייה Headers (כותרות) ומציינים את Request URL (כתובת ה-URL של הבקשה).
  2. הנה דוגמה לפלט מהכלים למפתחים:

    פלט לדוגמה שבו מוצג ה-API שבו נעשה שימוש בלוח הבקרה 'ביצועי שרת proxy' מהכרטיסייה 'רשת' של הכלים למפתחים עבור לוח הבקרה 'ביצועי שרת proxy'

  3. מריצים את הקריאה ל-Management API ישירות ובודקים אם מקבלים את התוצאות. דוגמה לקריאה ל-API בכרטיסייה Day בלוח בקרה לביצועי הענן Proxy Performance: 
    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.

נתוני Analytics לא מועברים למסד נתונים של Postgres

אבחון

אם הנתונים לא נשלחים משרת Qpid למסד הנתונים של Postgres, כפי שנקבע בקטע הנתונים זמינים במסד הנתונים של Postgres, אבל לא מוצגים בממשק המשתמש החדש של Edge, מבצעים את השלבים הבאים:

  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. יכול להיות שיוצגו הודעות שגיאה כמו "Probably PG is still down" או "FATAL: sorry, too many clients already", כמו שמוצג באיור שלמטה: 
    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 או שהמעבד (CPU) פועל ברמה גבוהה ולכן לא יכול להגיב לשרת 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.

הטמעה שגויה של Analytics

אבחון

  1. כדי לקבל את סטטוס הפריסה של Analytics, משתמשים בקריאה הבאה ל-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) לא עדכניים של שרת Analytics.
    2. אם הסטטוס של שרתי Qpid/Postgres הוא UNKNOWN או FAILURE, סימן שיש בעיה בשרת המתאים.

      לדוגמה, בתרחיש הבא מוצג הסטטוס של שרתי Postgres כ-UNKNOWN:

      זה יכול לקרות אם יש כשל במהלך ההצטרפות ל-Analytics. הכשל הזה מונע מההודעות משרתי הניהול להגיע לשרתי Postgres.

רזולוציה

בדרך כלל אפשר לפתור את הבעיה הזו על ידי הפעלה מחדש של השרתים שבהם מופיעה השגיאה FAILURE או UNKNOWN.

  1. מפעילים מחדש כל אחד מהשרתים שסטטוס החיווט של ניתוח הנתונים שלהם הוא FAILURE או UNKNOWN, באמצעות הפקודה הבאה: 
    /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. בדוגמה שלמעלה, ההודעה "UNKNOWN" מוצגת לשרתי Postgres, לכן צריך להפעיל מחדש את שרתי Postgres הראשי והמשני: 
    /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart

מזהים ייחודיים אוניברסליים (UUID) לא עדכניים של שרתי Analytics

אבחון

  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.
      • מריצים את הפקודה הבאה בכל אחד מצומתי שרת Postgres כדי לקבל את מזהי ה-UUID של שרת Postgres: 
        curl 0:8084/v1/servers/self/uuid
      • כדי לקבל את ה-UUID של שרת Qpid, מריצים את הפקודה הבאה בכל אחד מצמתי השרת של Qpid: 
        curl 0:8083/v1/servers/self/uuid
  3. אם כל המידע נכון, ממשיכים אל נתוני Analytics לא נדחפים למסד הנתונים של Postgres.
  4. אם מזהי ה-UUID של שרתי Postgres או Qpid שגויים, יכול להיות ששרתי הניהול מתייחסים למזהי UUID ישנים.

רזולוציה

כדי להסיר את מזהי ה-UUID הישנים ולהוסיף את מזהי ה-UUID הנכונים של השרתים, פנו אל התמיכה של Apigee Edge.