דלג לתוכן הראשי
מדריך זה מכסה את פריסת שרת AgentEye ולוח הבקרה בייצור.

סקירת ארכיטקטורה

  • Server: שירות HTTP בשפת Rust; מקבל אצוות אירועים, כותב אותן ל-ClickHouse ותמונת מצב יחסית שמורה ב-PostgreSQL.
  • Dashboard: אפליקציית Next.js; קוראת וכותבת בעקביות דרך API השרת בלבד.
  • agenteye-collector: מפורסת על מכונות agent, לא על מארח השרת.
  • Postgres 15+: נדרש. (הועלה מ-14 בהוצאה מרובה-דיירים; סכימת חברות הארגון משתמשת בעמודה ON DELETE SET NULL במפתח זר, שהוא Postgres 15+. שדרג את Postgres לפני פריסת גרסה זו.) מאחסן מצב OLTP: api_keys, users, sessions, evaluation_jobs (תור), dashboards, saved_queries, otp_codes, בתוספת טבלאות מרובות-דיירים orgs, org_memberships, org_settings.
  • ClickHouse 24+: נדרש. אחסן האנליטיקה לכל אירוע שנספג. מנוע: ReplacingMergeTree, מחולק לפי חודש, סדור לפי (session_id, ts, dedup_key). השרת מתחבר דרך CLICKHOUSE_URL; ה-deploy/base/clickhouse/ המצורף משדר תצורת יחיד-קשר עם כיוונון ביצועים. דרישת מרובה-דיירים: התצורה המצורפת מאפשרת ניהול גישה SQL + users_without_row_policies_can_read_rows=false כך שהשרת יכול ליצור משתמש ClickHouse לקריאה בלבד ממנהל שורות אחד לכל ארגון (גבול בידוד שנאכף במנוע לעורך SQL וביעילות agent). אם אתה מספק תצורת ClickHouse משלך, הנקל את ההגדרות הללו (ראה deploy/base/clickhouse/configmap.yaml).
  • Redis 7+: אופציונלי אחסן זיכרון משותף + בקצה שיעור הגבלה. שרת ולוח בקרה מתחברים דרך REDIS_URL. אם חסר, שניהם יורדים בחן לנתיבים Postgres בלבד. ראה Redis (אחסן זיכרון אופציונלי) למטה.

שרת

משוך את התמונה

בניות נוכחיות מפרסמות תחת beta-latest; latest מוקצה רק להוצאות יציבות. לייצור, הצמד גרסה ספציפית :v<version>; ראה תגיות תמונה זמינות.

משתני סביבה

משתנהנדרשברירת מחדלתיאור
DATABASE_URLכןללאDSN של Postgres. מחרוזת חיבור libpq סטנדרטית עם סכימה postgres://. תומך ב-?sslmode=require ופרמטרים libpq אחרים. הסיסמה לא חייבת להיות מכילה /, +, או =; השתמש ב-openssl rand -hex ליצירת סיסמאות בטוחות-URL.
ADMIN_KEYלאללאמפתח API אדמין bootstrap. מוערך עם כל ההרשאות בכל הפעלה. סובב על ידי שינוי הערך והפעלה מחדש.
LISTEN_ADDRלא0.0.0.0:8080כתובת TCP שתיקשור אליה
MAX_BODY_BYTESלא134217728 (128 MB)גודל גוף בקשה מרבי
ADMIN_EMAILלאללאכתובת דוא”ל של משתמש admin bootstrap. מוערך עם כל ההרשאות בכל הפעלה וסומן מוגן: לא ניתן להשבית או לשנות הרשאות דרך לוח הבקרה/API. כדי לסובב את admin bootstrap, שנה ADMIN_EMAIL והפעל מחדש; הדוא”ל החדש מוערך כמוגן, והקודם שומר על הגנתו עד לניקיון ידני במסד הנתונים.
ALLOWED_EMAILSלאללא (הכל חסום)רשימה מופרדת בפסיקים של דוא”לים מורשים ליצירה וכניסה של משתמש. תומך בכתובות מדויקות (user@example.com) ותעדול דומיין (*@example.com). אם אינו מוגדר, אין משתמשים יכולים ליצור או להיכנס. זריעה בהפעלה ראשונה בלבד: זורע את רשימת ההרשאות של הארגון ברירת המחדל בהפעלה ראשונה; לאחר מכן עמוד /<org>/settings של כל ארגון הוא מקור האמת ושינוי משתנה env זה אין השפעה.
SMTP_HOSTלאללאשם מארח שרת SMTP לשליחת דוא”לי OTP. אם אינו מוגדר, קודי OTP מתועדים ל-stdout.
SMTP_PORTלא587יציאת שרת SMTP
SMTP_USERNAMEלאללאשם משתמש אימות SMTP
SMTP_PASSWORDלאללאסיסמת אימות SMTP
SMTP_FROMלאללאכתובת דוא”ל של השולח לדוא”לי OTP
SMTP_TLSלאSTARTTLSSTARTTLS משמש אלא אם אתה כבה אותו במפורש: false או 0 שולח טקסט רגול (ללא TLS); כל ערך אחר — כולל אינו מוגדר — מאפשר STARTTLS.
DASHBOARD_URLלאברירת מחדל מובניתמקור לוח בקרה המשמש לבניית קישור קסום בדוא”ל OTP וקישורים קסומים בהודעות התריעות. אם אינו מוגדר זה חוזר לברירת מחדל מובנית (ובעבור OTP בלבד, למקור הנגזר מלוח הבקרה תחילה). הגדר זאת לעיצובי תחום-מפוצל כך שקישורי דוא”ל ו-Slack/התרעה מצביעים על לוח הבקרה שלך. ראה URL קישור קסום דוא”ל למטה; רוב המפעילים לא צריכים להגדיר את זה.
SESSION_TTL_SECSלא86400 (24 ש”א)משך הפעלת לוח בקרה בשניות. זריעה בהפעלה ראשונה בלבד: ערוך לכל ארגון דרך /<org>/settings אחרי ההפעלה הראשונה.
OTP_TTL_SECSלא600 (10 דק’)תקופת תוקף קוד OTP בשניות. זריעה בהפעלה ראשונה בלבד: ערוך לכל ארגון דרך /<org>/settings אחרי ההפעלה הראשונה.
REDIS_URLלאללאאחסן זיכרון משותף אופציונלי + בקצה שיעור הגבלה, למשל redis://redis:6379/0. כשנקבע, השרת שומר מחשבים התייקדויות API-key, הצבירה /models של לוח הבקרה, רשימת הפעילויות וקצה תחום env; זה גם מעביר שיעור הגבלת בקשות OTP מ-Postgres COUNT ל-Redis INCR. אם לא מוגדר או לא מושג, השרת פועל ללא אחסן זיכרון (הגבלת OTP חוזרת ל-Postgres, כל קריאת אחסן זיכרון נופלת דרך למקור האמת). ראה Redis (אחסן זיכרון אופציונלי) למטה.
CLICKHOUSE_URLכןללאURL בסיס של מכונת ClickHouse, למשל http://clickhouse:8123. השרת מיישם את סכימת האירועים שלו למסד נתונים זה בכל הפעלה ומסרב לטעון אם הוא לא יכול להגיע ל-ClickHouse. ראה ClickHouse (אחסן אנליטיקה נדרש) למטה.
CLICKHOUSE_DATABASEלאagenteyeשם מסד נתונים (סכימה) של ClickHouse. השרת יוצר אותו בהפעלה אם הוא לא קיים.
ORG_CH_SECRETלא (דיירים-יחיד) / כן (מרובה-ארגון)ברירת מחדל devמפתח HMAC שממנו נגזר סיסמת ClickHouse לכל דיירים של כל ארגון. עורך SQL וביעילות agent של run_query מבצעים כמשתמש ClickHouse לקריאה בלבד של הארגון, שמנהל השורות שלו אוכף בידוד דיירים במנוע. פריסות דיירים-יחיד אתחול בסדר על ברירת המחדל dev מובנית; לפני הפקת ארגון שני אתה חייב להגדיר ערך חזק יציב, מכיוון ש-CLI agenteye-orgctl org create מסרב להיות ברירת המחדל dev מובנית. סיבוב זה משריד כל משתמש ClickHouse של הארגון עד להפעלה הבאה שסידרה מחדש אותו (סידור boot-time מרפא זה באופן אוטומטי). שמור את זה בסוד וללא שינוי על כל השכפלים. הפקת ארגון עצמה היא-פעיל-בלבד; ראה ארגונים (רב-דיירים) למטה.
DEFAULT_ORG_NAMEלאDefaultשם תצוגה שנזרע לארגון ברירת המחדל המובנה. זריעה בהפעלה ראשונה בלבד, ורק בזמן שהארגון עדיין נושא את זהותו הגנרית טרי-מהוגרה, מיושמת בהפעלה, ואז התעלמות. ברגע שתשנה את שם הארגון (agenteye-orgctl org rename) השינוי הוא סמכותי והמשתנה env זה אין עוד השפעה.
DEFAULT_ORG_SLUGלאdefaultתעד URL לארגון ברירת המחדל המובנה, נתיב לוח הבקרה שהוא חי בו (/<slug>/…). אותם סמנטיקה זריעה-בהפעלה-ראשונה / טהורה-בלבד כמו DEFAULT_ORG_NAME. חייב להיות 1-40 alphanumerics קטנים עם מקפים פנימיים יחידים ולא מילה שמורה; ערך לא חוקי התעלם (הארגון שומר default). מאפשר התקנה דיירים-יחיד להציג כמו /acme במקום /default ללא שום שלב CLI פוסט-קומפוזיציה.
RUST_LOGלאinfoרמת עלבון יומן (debug, warn, error, agenteye_server=trace)
EVALUATOR_ENDPOINTלאללאURL בסיס של שירות ההערכה שלך (למשל http://evaluator:9000). כשלא מוגדר כל קו האורך הערכה הוא no-op; שום שורות תור אינן כתובות, אין עובדים. ראה Evaluation Suite.
EVALUATOR_TOKENלאללאנשלח כ-Authorization: Bearer <token> להערכה. חייב להיות שווה לערך זהה בו שירות ההערכה מוגדר. אופציונלי רק אם ההערכה שלך מוגדרת ללא אסימון.
EVALUATOR_WORKERSלא2בקצה: מספר משימות עובד לכל מכונת שרת שמשגרת הערכות. בטוח להיות מקבוצות מרובות אופקיות שרתים.
EVALUATOR_CLAIM_BATCHלא4מספר הערכות מרבי שעובד יחיד תוביע לכל טיק. אצוות משגרות במקביל, אז סך הקצה על נקודת הקצה שלך ההערכה הוא EVALUATOR_WORKERS × EVALUATOR_CLAIM_BATCH.
EVALUATOR_POLL_IDLE_SECSלא2כמה זמן עובד ישן בין ניסיונות שליחה כשכלום הוא בעתיד.
EVALUATOR_POLLING_INTERVAL_SECSלא10קצב נופל סופי (שניות) לסקר GET /evaluate/{id} כשההערכה לא מחזירה next_poll_secs לכל תגובה ולא מפרסמת default_poll_interval_secs מ-GET /config.
EVALUATOR_REQUEST_TIMEOUT_MSלא30000timeout לכל בקשה HTTP כנגד ההערכה (אלפיות שנייה).
EVALUATOR_MAX_ATTEMPTSלא5אחרי כל כך הרבה ניסיונות שנכשלו הערכה מתועדת כטרמינל error (או timeout אם הכישלונות היו timeouts בקשה).
EVALUATOR_CONFIG_REFRESH_SECSלא300 (5 דק’)כמה בתדירות השרת מחזיר GET /config מההערכה.
EVALUATOR_MAX_POLL_DURATION_SECSלא3600 (1 שעה)זמן קיר מרבי שפעילות ניסיון יכולה להישאר בתור הסקר לפני AgentEye מסיימת אותו כ-timeout. מגנים נגד הערכה שמחזירה pending לנצח.
ALERT_WORKERSלא1בקצה: מספר משימות עובד לכל מכונת שרת שמערכות כללי התריעה. ראה התריעות.
ALERT_CLAIM_BATCHלא16מספר התריעות מרבי שעובד יחיד תוביע לכל טיק.
ALERT_POLL_IDLE_SECSלא5כמה זמן עובד התריעות ישן כשהתור ריק.
ALERT_REQUEST_TIMEOUT_MSלא15000timeout הערכה התריעה לכל טריגר (ClickHouse שאילתות + HTTP ערוץ יוצא).
ALERT_MAX_ATTEMPTSלא5כישלונות חולפים עוקבים לפני התריעה מתוזמנת מחדש בקצבה הרגילה שלה במקום backoff מעריכי.
AUDIT_WORKERSלא1בקצה: מספר משימות עובד לכל מכונת שרת שמבצעות ביקורות. ראה ביקורות.
AUDIT_CLAIM_BATCHלא1מספר ביקורות בעתיד מרבי שעובד יחיד תוביע לכל טיק. חקירה סוכנית היא לולאה ארוכה אחת, אז ברירת המחדל היא 1.
AUDIT_POLL_IDLE_SECSלא30כמה זמן עובד ביקורות ישן כשאף ביקורת אינה בעתיד.
AUDIT_REQUEST_TIMEOUT_MSלא30000timeout לכל שאילתה-מדיניות כנגד ClickHouse (אלפיות שנייה).
AUDIT_LLM_TIMEOUT_MSלא1440000timeout לשיחת חקירה סוכנית לשירות עוזר AI. לולאת סוכן מלאה פועלת לדקות; שמור את זה מעל שלך הסוכן שלו AGENTEYE_AUDIT_TIMEOUT_MS אז הסוכן מחזיר ממצאים חלקיים לפני השרת מוותר.
AUDIT_MAX_ATTEMPTSלא5כישלונות חולפים עוקבים לפני ביקורת מתוזמנת מחדש בקצבה הרגילה שלה במקום backoff מעריכי.
AGENTEYE_AGENT_URL / AGENTEYE_AGENT_TOKENלאהשיחה החקירה הסוכנית של ביקורת קוראת שירות עוזר AI agent, משימוש בחיבור זהה כמו העוזר — אז הגדר את אלה שתיים גם בשרת (פריסות משודרות/compose עושה). שניהם להגדיר ⇒ ביקורות הפעלת חקירת AI; או לא מוגדר ⇒ ביקורות הפעלת מדיניות-רק (עבור SQL דטרמיניסטי מדיניות עדיין פועל), בעלות דגל llm_enabled לכל ביקורת. הסוכן חייב גם LLM מוגדר — ראה assistant.md.
עוזר AI שירות — ביקורת + הגדרות חממה. החקירה הסוכנית והחממה Python בתוך-פוד שלה מכוונות שירות סוכן (לא השרת), הכל בתחילית AGENTEYE_AUDIT_* והכל אופציונלי:
משתנהברירת מחדלמשמעות
AGENTEYE_AUDIT_MAX_STEPS200טיפול סוכן מרבי לחקירה.
AGENTEYE_AUDIT_TIMEOUT_MS1200000קיר-שעון לחקירה אחת (20 דק’). חייב להישאר תחת השרת שלך AUDIT_LLM_TIMEOUT_MS.
AGENTEYE_AUDIT_MAX_CONCURRENCY1חקירות במקביל לכל פוד סוכן (נפרד מתקציב העוזר הצ’אט).
AGENTEYE_AUDIT_SANDBOX_TIMEOUT_MS / _MEM_MB / _CPU_SECS / _OUTPUT_MAX_BYTES / _SCRIPT_MAX_BYTES20000 / 768 / 10 / 64000 / 64000לתסריט גבולות אחד לחממה bubblewrap.
דרישת פלטפורמה חממה. חממה קוד ביקורת פעלנית Python של המודל בתוך כלא bubblewrap, הזקוק מרחבי משתמש ללא הרשאות. פוד הסוכן חייב להרשות דגלי clone() — הגדר seccompProfile: Unconfined (k8s) או security_opt: [seccomp:unconfined] (compose) בסוכן. איפה קרנל הצומת מנטרל מרחבי משתמש ללא הרשאות (למשל כמה GKE COS תמונות), חממה preflight כשל וביקורת שפלה SQL-רק באופן אוטומטי — אף טעות, רק sandbox_available: false בסוכן שלך /health.

הרץ

הגדר DATABASE_URL בסביבה שלך, ואז העבר את זה דרך למכל:
השרת מריץ הנדסות מסד נתונים באופן אוטומטי בהפעלה; אין שלב הנדסה נפרד נדרש.

בדיקת בריאות

אין אימות נדרש. השתמש ב-/health ל-liveness בחדשות ו-/ready ל-readiness / עומס מאזן בחדשות. /ready בודקות התלויות הקשות שהשרת לא יכול להשרת ללא (Postgres + ClickHouse), אז שרת שפעיל אך לא יכול להגיע למסד הנתונים שלו מוצא מהסיבוב ומוצג כ-NotReady; Redis מדווח אך לעולם לא נכשל readiness. על פריסות Kubernetes משודרות פגם readiness כבר מצביע על /ready ו-liveness נשאר ב-/health. ראה enterprise-docs/health-monitoring.md לתמונה המלאה, כולל opt-in ניטור כשל פוד Kubernetes-ילידי ל-Slack.

URL קישור קסום דוא”ל

דוא”לי כניסה OTP כוללים כפתור לפתוח את לוח הבקרה בעלויות לכל דבר. לחיצה בו נוחתת המשתמש על /login?token=<code>&email=<address>; לוח הבקרה מחליף זוג זה לפעילות וניתוב ל-אפליקציה, ללא re-entry קוד ידני. השרת פותר את מקור לוח הבקרה שמשמש לבניית הקישור בשלוש רמות:
  1. כותר X-AgentEye-Dashboard-Url: הגדר באופן אוטומטי על ידי פרוקסי /api/auth/otp/request של לוח הבקרה מהמקור הציבורי שלו. בפריסה same-origin (שרת ולוח בקרה חלוקים מארח מאחורי ingress אחד שהכותרות פרוקסי מעבר), אין תצורה נדרשת.
  2. DASHBOARD_URL env var: הגדר זאת אם לוח הבקרה שלך מושג ב-origin אחר מזה שנקודת הקשה OTP של השרת רואה (split api.example.com / app.example.com), או אם ingress שלך לא מתפשר את המארח הציבורי לתוך פוד לוח הבקרה (אז request.nextUrl.origin יפתור אחרת כמו 0.0.0.0:3000). דוגמה: DASHBOARD_URL=https://app.example.com.
  3. ברירת מחדל: https://app.befailproof.ai, משומש רק אם לא אחד משני הלעיל קיים.
ערך הכותר מאומת: רק https://* ו-loopback (http://localhost*, http://127.0.0.1*) origins מקובלים, וכתובות wildcard bind (0.0.0.0, [::]) דחויים גם עם התוכנית https://. כל דבר אחר נופל דרך לרמה 2. הגדר אותו על אשכול רץ עם בר תיל; אין קובץ, אין kustomize שיבוא מחדש:
זה מפעיל rollout; הפודים החדשים תופסים את הערך בבקשה הראשונה. שים לב שה-override חי רק על ה-Deployment; kustomize build | kubectl apply עוקב נגד ה-overlay ימחוק את זה אלא אם אתה מוסיף את משתנה env זהה ל-patch server-env.yaml של ה-overlay שלך.

לוח בקרה

משוך את התמונה

משתני סביבה

משתנהנדרשברירת מחדלתיאור
AGENTEYE_SERVER_URLכןללאURL בסיס של השרת, למשל http://localhost:8080
AGENTEYE_API_KEYכןללאמפתח API בו לוח הבקרה משתמש כדי להצטייד לשרת. צריך כל הרשאות (מפתח admin מומלץ).
AE_LOG_LEVELלאinfoרמת עלבון יומן בצד שרת: debug, info, warn, error. הגדר ל-debug לראות שורות בקשה/תגובה עלות זרם וטרייסות אימות פעילות כשאתה אבחון בעיות.
AE_LOG_JSONלאאוטו1 כופה פלט JSON-לכל-שורה; 0 כופה פלט קריא לאדם. כשלא מוגדר, JSON מופעל באופן אוטומטי אם NODE_ENV=production. JSON מומלץ בייצור כך יומנים נתחתו בנקיוות עם jq או מפתח לוג.
AE_ANALYTICS_DISABLEDלאללאהגדר ל-1/true להשבית טלמטריה שימוש מוצר אנונימיות של לוח הבקרה. ראה טלמטריה & פרטיות למטה.
REDIS_URLלאללאאחסן זיכרון משותף אופציונלי, למשל redis://redis:6379/0. כשנקבע, לוח הבקרה משמור validateSession() תוצאות על כל השכפלים וחלוקה ה-Next.js השלך שומר אחסן לנתיבי צבירה זמן-חזון / env-רשימה. גם קצבה תור ומאמת OTP בצד גופן משתמשים Redis כשקיים (נופל פתוח אם Redis לא מושג; ניטור בצד שרת הוא backstop בטיחות). ראה Redis (אחסן זיכרון אופציונלי) למטה.
AGENTEYE_AGENT_URLלאללאURL בסיס של שירות עוזר AI אופציונלי agent, למשל http://agent:9100. השאר את זה לא מוגדר להסתיר את העוזר לחלוטין: אף בועת עוזר מופיעה בלוח הבקרה. ראה enterprise-docs/assistant.md.
AGENTEYE_AGENT_TOKENלאללאסוד משותף ב-לוח הבקרה מציג לשירות agent. חייב להתאים AGENTEYE_AGENT_TOKEN מוגדר בסוכן. ראה enterprise-docs/assistant.md.

הרץ

טלמטריה & פרטיות

לוח הבקרה שולח ניתוח שימוש מוצר אנונימי לשירות ניתוח של Exosphere (PostHog): איזה עמודי לוח בקרה יוצגו וקבוצה של פעולות UI כמו יצירת מפתח API או הערכה מחדש של פעילות. אות שימוש זה מהמידע איזה תכונות יעדיפו.
  • אף אחד סוכן, פעילות, או נתונים אירוע לעולם עוזב את התשתית שלך. רק שימוש UI לוח בקרה מדווח. כתובות דף מעלות זיהוי לפני שליחה, ומפעילים מזוהים רק על ידי id פנימי אטום, לעולם לא על ידי דוא”ל.
  • טלמטריה מופעלת כברירת מחדל. כדי להכבות זאת לחלוטין, הגדר AE_ANALYTICS_DISABLED=1 בתא לוח הבקרה והפעל מחדש.
  • אנליטיקה נשלחה ללוח הבקרה שלה בעצמו /ingest נתיב, בו לוח הבקרה reverse-proxies ל-PostHog (https://us.i.posthog.com). שמירת בקשות first-party אומר חוסמי פרסומות בדפדפן לא טרופים אותם. תא לוח הבקרה צריך גישה יוצאת ל-PostHog; אם זה חסום, טלמטריה שמחרישת ולוח הבקרה לא מושפע.

עוזר AI (אופציונלי)

עוזר AI בתוך-לוח בקרה מאפשר לצוות שלך לשאול שאלות של נתוני agent שלהם בשפת טבע (סיכום פעילויות, טיוטה SQL לעורך /queries, וטיוטה שמורה שאילתות ללוח בקרה מרות) ללא עזוב את לוח הבקרה. זה פועל כתא פנימי נפרד agent (ב-Claude Agent SDK) שרק לוח הבקרה יכול להגיע, ונשאר מושבת עד שתורכל סוף LLM. כדי להפעיל את זה אתה הגדרת, ב-שירות agent, חיבור LLM (Portkey דרך PORTKEY_API_KEY + קטלוג-מודל slug AGENTEYE_AGENT_MODEL=@<slug>/<model>, Anthropic ישיר דרך ANTHROPIC_API_KEY, שער אחר דרך ANTHROPIC_BASE_URL, או Bedrock/Vertex), ייעודי מפתח נתונים, וMiDARK AGENTEYE_AGENT_TOKEN התאמה לוח הבקרה. משתמשי לוח הבקרה בנוסף צריכים הרשאה agent:use. לנתוני מפתח של העוזר אתה לא מטבע כלום ביד: בחר סוד אקראי, הגדר את זה כמו AGENTEYE_API_KEY בסוכן ו כמו AGENT_API_KEY בשרת, והשרת זורע אותו בהפעלה עם כמה הרשאות קבועות. גישת נתונים שלו היא read-only (events:read, evaluations:read, dashboards:read, queries:read), ובנוסף מחזיק אישור-gated כתיבה scopes (dashboards:write, queries:write, queries:run) כך זה יכול לטיוטה ותמונות שאילתות שמורות ובניה מרות לוח בקרה בעבור המשתמש; כל SQL עדיין הפעלה דרך תפקיד ClickHouse read-only של הארגון, אז זה מרחיב מה העוזר יכול יוצר, לא נתונים אותו יכול הגיע. Scopes קבועים בקוד ולא יכול להיות מורחב בתצורה. מפתח זה מוגן; זה לא יכול מושבת או regenerated דרך ה-API, רק rotated על ידי שינוי הערך והפעלה מחדש. לעולם לא השתמש מחדש admin/dashboard מפתח לכך. הגדרה מלאה, ה-משתנה סביבה כללו התייחסות, טלמטריה אפשרויות, וביטחון הדגם הם ב-enterprise-docs/assistant.md.

ClickHouse (אחסן אנליטיקה נדרש)

ClickHouse שומר לוחי בקרה שלך הגיוני בכרכים אירוע גבוה ומאפשר SQL של עורך /queries צירוף על אירועים, הערכות, ופעילויות בחנות יחידה. זה את החנות קנוני נדרש לכל אירוע שנספג, כל פעילות מסוף תוצאה, והנגזר לכל-פעילות צבירות. PostgreSQL מחזיק את יחסית / mutable-מצב טבלאות (api_keys, users, otp_codes, evaluation_jobs, dashboards, saved_queries); ה-משטח אנליטי חי ב-ClickHouse כך לוח הבקרה’s rollups וה-SQL שלך שאילתות יכול סריקה וצירוף זה בעצמו, ללא cross-database סיבובים. השרת מסרב טעון ללא CLICKHOUSE_URL.

סכימה

שלוש ClickHouse עצמים נוצרים בהפעלת שרת, כל idempotent (CREATE IF NOT EXISTS):
  • agenteye.events: ReplacingMergeTree(ingested_at), חולק לפי toYYYYMM(ts), סדור לפי (session_id, ts, dedup_key). כפול insert (collector ניסיונות) קוטע שורה יחידה בהתמזגות זמן; השרת מחשב קובע SHA-256 dedup_key לכל אירוע אז ניסיונות בטוחים.
  • agenteye.evaluations: ReplacingMergeTree(ingested_at), חולק לפי toYYYYMM(finished_at), סדור לפי (session_id, finished_at, dedup_key). כתובה פעם אחת לכל טרמינל הערכה תוצאה על ידי קו האורך evaluator. אותם dedup-key דגם כמו events.
  • agenteye.agent_sessions: VIEW על agenteye.events, לא טבלה פיזית. כל עמודה נגזרת (started_at = min(ts), last_event_at = max(ts), ended_at = max(if event_type='agent_end', ts, NULL), event_count = count(), וכו’). אף לא לכל-אירוע upsert ולא ממלא נפרד; ה-view auto-מחזיר איך הוא בתוך events.
לעבור-compat עם שמורה שאילתות שהגיע analytics.evaluations / analytics.sessions, השרת גם יוצר analytics ClickHouse מסד נתונים עם נבטים על agenteye.* טבלאות; analytics.events, analytics.evaluations, analytics.agent_sessions, analytics.sessions כל התמיד בנקיוות.

תצורה

ה-משודר docker-compose וגם deploy/base/clickhouse/ משדר שירות ClickHouse כיוונון לעומס עבודה של AgentEye:
  • 2 GiB בקשה / 4 GiB כחוג זיכרון בבסיס משודר overlay (בגודל לעמוד קטן POC/staging צמתים); ייצור לקוחות צריכים overlay עד — הרצפה מומלצת היא 2c / 4Gi בקשה, 6c / 8Gi כחוג. max_server_memory_usage_to_ram_ratio=0.9
  • 5 GiB סימן אחסן + 8 GiB דחוסu אחסן
  • background_pool_size=16, background_merges_mutations_concurrency_ratio=2
  • MergeTree: parts_to_throw_insert=3000, parts_to_delay_insert=1500, non_replicated_deduplication_window=1000
  • local_io_method=auto (io_uring בתמיכת צמתים)
  • fsync_metadata=0: קביל כי לפחות-פעם ingest + ReplacingMergeTree dedup
  • query_log מופעל עם 30-יום TTL; query_thread_log הוסר (יקר בגבוה QPS)
  • max_execution_time=30 לשאילתות בצד משתמש
  • 100 GiB PVC בתבנית StatefulSet (לקוח overlays צריך לעלות מהיר SSD סוג אחסן לייצור)

גיבויים

הנתונים המלאים שלך נתפסים כל לילה בארכיון תערוקה יחיד, אז אשכול או אובדן אחסן ניתן להחזיר. ClickHouse נתמך באופן אוטומטי על ידי הagenteye-backup CronJob יומי, דפדפן אחוות PostgreSQL וClickHouse בעבור. ClickHouse קרא על ה-HTTP API שלה: agenteye.events וגם agenteye.evaluations דפדפן ב-ClickHouse-ילידי פורמט (ה-נבטים וקצבה מדיניות יוצרו מחדש על ידי השרת בהפעלה, אז נתונים טבלה הוא תמונה מלאה) וקיבוץ עם מצע Postgres לארכיון דחוסu יחיד מוספות לאחסן עצמים שלך. ה-bucket היעד וערבון מהוד מוגדרים לכל overlay. ראה סעיף גיבויים של enterprise-docs/kubernetes-deployment.md לעלות תצורה וחזור שלבים.

Redis (אחסן זיכרון אופציונלי)

Redis היא אופציונלי אחסן זיכרון משותף + בקצה שיעור הגבלה בשימוש על ידי השרת ולוח הבקרה. עם Redis פרוסה ו-REDIS_URL קבוע על שני שירותים:
  • Server משמור התייקדויות API-key, ה-/events/environments + /evaluations/environments רשימות, ה-/events/latency_aggregate rollup (הכבד ביותר שאילתה לוח הבקרה סקרים), ה-/sessions רשימה, וסוויץ’ שיעור הגבלה בקשה OTP מ-Postgres COUNT(*) ל-Redis INCR + EXPIRE.
  • Dashboard משמור validateSession() תוצאות אז ה-10-20 authed API מטלות עלות דף טיפול שכל חלוקה משותף אחד בדיקה זרם שרת. זה גם משעות מקצב OTP-בקשה וOTP-עד זה קצה לוח הבקרה.
שני שירותים יורדים בחן אם Redis לא מושג. כל קריאת אחסן זיכרון מחזירה Err בתוך timeout קשור וקורא חוזר ל-מקור האמת (Postgres בשרת, הנחמד Rust שרת בלוח הבקרה). OTP שיעור הגבלה חוזר ל-Postgres COUNT(*) נתיב בשרת (הביטחון רכוש שמור); לוח הבקרה’s קצה OTP הגבלה נופל פתוח בזמן השרת בצד הגבלה עדיין ממשיכה. Redis הווה למטה פוגע זמן-חזון, לא תקינות.

תצורה

ה-docker-compose צרור כבר כולל שירות Redis וקווי REDIS_URL=redis://redis:6379/0 לשרת ולוח הבקרה. כדי להשתמש ב-Redis חיצוני, הגדר REDIS_URL לנקודה הקצה שלך והסר את redis שירות מקובץ הרכבה.

זיכרון + התמשכות

ה-משודר Redis תמונה פועלת עם --appendonly yes --appendfsync everysec --maxmemory 256mb --maxmemory-policy allkeys-lru. AOF התמשכות מקבל אחסן זיכרון מן שרת תא; everysec הוא הנכון קביעות/ביצועים איזון מכיוון שאבד אחרון שנייה של אחסן זיכרון כתיבה harmless. LRU eviction תקווה זיכרון גדילה.

מתי לא פרוס Redis

  • יחיד-instance dev/QA. ה-in-process אחסנים בשרת לבד לספק כמו כל לכל-חזרה טובה; Redis מוסיף את כל-חזרה שיתוף עומס שיחיד-instance להגדרות לא צורך.
  • אויר-מנותק התקנות איפה שהם תפעול עלות של הפעלה אחד יותר שירות משקל הזמן-חזון.

Docker Compose (מומלץ)

ה-docker-compose.yml זמין בריפו agenteye-enterprise/releases. זה עלויות Postgres, השרת, ולוח הבקרה עם פקודה יחידה.
עלויות ברירות מחדל דרך .env:
עצור (שומר נתונים כרך):
עצור וחזל כל הנתונים:

הגדרות תפעול

כמה קבוצה של קבוצת תפעול הצמד להיות משודר על ידי env vars הם כעת editable לכל ארגון מ-/<org>/settings דף לוח הבקרה; כל ארגון מורכב משלה. שינויים ייכנסו ליום שניות, עם אף restart ו-אף redeploy.
הגדרהBootstrap env varמה זה בקרה
מורשה sign-insALLOWED_EMAILSדוא”לים (או *@domain.com תעדול) בהיתר OTP לקבל וליהיות יצור כמו משתמשים
המשתמש הרשאות ברירת מחדלDEFAULT_USER_PERMISSIONSפסיק-מופרדים הרשאה אסימונים preselected מתי admin פועל + חדש משתמש. כל אסימון חייב להיות אחד מ-מחרוזות תחת API key הרשאות. ברירות ל-standard preset: read-only גישה בתוספת בכל-יום on-call פעולות (טריגר re-הערכות, הפעלה שאילתות, ack התרעות, השתמש העוזר).
פעילות lifetimeSESSION_TTL_SECSכמה זמן לוח בקרה כניסה נשאר תקף לפני re-auth. לוח הבקרה re-בדיקות זרם שרת פעילות כל 5 שניות, אז הרשאה update על /<org>/users בעלויות השפעו משתמש הבא בקשה, ללא relogin.
חד-פעמי-קוד lifetimeOTP_TTL_SECSכמה זמן OTP / קסום-קישור נשאר usable
התריעה הודעות ערוציםALERTS_ENABLED_CHANNELSפסיק-מופרדים רשימה ערוץ סוגים מפזר התריעה היא בהיתר להשתמש: email, slack, webhook. לכל-התריעה תצורה עדיין יוצר על /<org>/alerts/<id>, אך מפזר משפעות כל משלוח יוצא דרך סט זה; ערוץ מנוטרל כאן קצר-מעגלים עם skipped_disabled ביקורת שורה. ה-dashboard ערוץ (המקום ביקורת הדחק) תמיד בהיתר. ברירות ל-כל שלוש בעל.

כיצד bootstrap עבודות

הגדרות מאוחסנות לכל ארגון ב-org_settings. בהפעלה ראשונה, השרת זורעות בברירת המחדל ארגון דפופים שורות מ-התאמה env var (או קוונטי ברירת מחדל אם env var הוא unset). אחרי כך, מאוחסן ערך הוא מקור האמת ו-env var התעלם; שינוי env var עם מאוחר restart לא ישפיעו ב-אורך ארגון חי ערך, וקבוצות בנוסף התחלה מ-ברירות ותורכל משלהם. זה אומר:
  • ל-טרי redeploy, קבוע env vars כמו לעיל ו-ברירת המחדל ארגון קוראים אותם בהפעלה ראשונה.
  • כדי שנה ערך מאוחר, היכנס לוח הבקרה ו-עריכה זה תחת /<org>/settings. השינוי מיושם בתוך שניות על כל שרת חזרות; אף restart נדרש.
  • הפעלה יומן ישר רשמות מה זרע לעומת מה היה כבר קיים, אז אתה יכול לבטח bootstrap לקח אפקט:

Sign-in סמנטיקה על פני ארגונים

פעילות ו-OTP היא גלובלי ל-משתמש, לא ל-יחיד ארגון, אז שניים כללים התמיר לכל-ארגון הגדרות ב-sign-in זמן:
  • פעילות / OTP lifetime: הקפיד (הקצרה) lifetime בין ארגונים משתמש שייכות לחמש.
  • מורשה sign-ins: ה-קרית OR כל-ארגון allowlist יחד עם ארגון חברות: משתמש יכול בקשה OTP אם כל-ארגון allowlist יחמנים דוא”ל או הם כבר חברות של כל-ארגון.

הרשאות

גישה ל-/<org>/settings עמוד gated על ידי שניים הרשאות:
  • settings:read: ראה העמוד וערכים נוכחיים.
  • settings:write: שמור שינויים.
ה-bootstrap admin משתמש (זורע מ-ADMIN_EMAIL) מקבל שניהם באופן אוטומטי יחד עם כל הרשאה אחרת. תן אותם משתמשים אחרים מ-/<org>/users כמו יש צורך.

ארגונים (רב-דיירים)

פריסה יחידה יכול להשרת מרובה מבודדות ארגונים (דיירים); כל שורה נתונים שייכות בדיוק אחד ארגון ובידוד אוכף בצד מסד הנתונים. דיירים-יחיד התקנה צורך כלום כאן; כל נתונים חי בבנוי default ארגון. (אתה יכול לתן ארגון זה chatty שם וURL תעד, אז זה חי ב-, /acme במקום /default, על ידי הגדרה DEFAULT_ORG_NAME / DEFAULT_ORG_SLUG לפני הראשון boot, או על ידי שינוי שם זה בכל זמן עם agenteye-orgctl org rename.) Tenant הפקה הוא תפעול-רק. ארגונים וחברות שלהם יוצרות וניהול עם agenteye-orgctl CLI, זה משודר בתוך שרת תמונה (יחד עם agenteye-server) והפעלות בתוך שרת קיים פוד; יש אף נפרד פוד/עבודה, אף HTTP API, וא לוח בקרה כפתור. זה השתמש מחדש בשרת DATABASE_URL, CLICKHOUSE_URL, וגם ORG_CH_SECRET.
זמין פעלים: org create | list | rename | delete | purge וגם member add | list | update | remove, עם הגדרות הרשאות מובנות admin, standard, וגם read-only. יצור חברות ממש OTP בהפעלה לוח הבקרה ראשון. לפני יצירת שניה ארגון: הגדר חזק, יציב ORG_CH_SECRET (ה-org create פקודה מסרב להפעלה בברירת המחדל dev מובנית) ותמונה בטוח Postgres