נתונים לא מופיעים במרכזי בקרה של 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 for Private Cloud
נתוני Analytics לא מועברים למסד נתונים של Postgres משתמשי Edge for Private Cloud
פריסה שגויה של Analytics משתמשי Edge for Private Cloud
מזהי UUID של שרת Analytics שהנתונים שלהם לא עדכניים משתמשי Edge for Private Cloud

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

אבחון

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

רזולוציה

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

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

תיאור הבעיה

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

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

  1. מתחברים לכל אחד משרתי Postgres ומריצים את הפקודה הבאה כדי לוודא שאתם נמצאים בצומת ה-Master של 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. כדי לבדוק אם הנתונים העדכניים זמינים במסד הנתונים של Postgres, מריצים את שאילתת ה-SQL הבאה: 
    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. בחלונית השמאלית של הכלים למפתחים, בוחרים בכרטיסייה 'כותרות' ורושמים את 'כתובת ה-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 Server אל Postgres Database כמו שמתואר בקטע הנתונים זמינים ב-Postgres Database, אבל לא מוצגים בממשק המשתמש, צריך לבצע את השלבים הבאים:

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

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

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

רזולוציה

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

  1. מפעילים מחדש כל אחד מהשרתים שסטטוס החיבור שלהם ל-Analytics הוא 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. שמות של סביבות ארגוניות שמופיעים ברכיב 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.