סקירת ארכיטקטורה
- 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 | לא | STARTTLS | STARTTLS משמש אלא אם אתה כבה אותו במפורש: 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 | לא | 30000 | timeout לכל בקשה 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 | לא | 15000 | timeout הערכה התריעה לכל טריגר (ClickHouse שאילתות + HTTP ערוץ יוצא). |
ALERT_MAX_ATTEMPTS | לא | 5 | כישלונות חולפים עוקבים לפני התריעה מתוזמנת מחדש בקצבה הרגילה שלה במקום backoff מעריכי. |
AUDIT_WORKERS | לא | 1 | בקצה: מספר משימות עובד לכל מכונת שרת שמבצעות ביקורות. ראה ביקורות. |
AUDIT_CLAIM_BATCH | לא | 1 | מספר ביקורות בעתיד מרבי שעובד יחיד תוביע לכל טיק. חקירה סוכנית היא לולאה ארוכה אחת, אז ברירת המחדל היא 1. |
AUDIT_POLL_IDLE_SECS | לא | 30 | כמה זמן עובד ביקורות ישן כשאף ביקורת אינה בעתיד. |
AUDIT_REQUEST_TIMEOUT_MS | לא | 30000 | timeout לכל שאילתה-מדיניות כנגד ClickHouse (אלפיות שנייה). |
AUDIT_LLM_TIMEOUT_MS | לא | 1440000 | timeout לשיחת חקירה סוכנית לשירות עוזר 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. |
AGENTEYE_AUDIT_* והכל אופציונלי:
| משתנה | ברירת מחדל | משמעות |
|---|---|---|
AGENTEYE_AUDIT_MAX_STEPS | 200 | טיפול סוכן מרבי לחקירה. |
AGENTEYE_AUDIT_TIMEOUT_MS | 1200000 | קיר-שעון לחקירה אחת (20 דק’). חייב להישאר תחת השרת שלך AUDIT_LLM_TIMEOUT_MS. |
AGENTEYE_AUDIT_MAX_CONCURRENCY | 1 | חקירות במקביל לכל פוד סוכן (נפרד מתקציב העוזר הצ’אט). |
AGENTEYE_AUDIT_SANDBOX_TIMEOUT_MS / _MEM_MB / _CPU_SECS / _OUTPUT_MAX_BYTES / _SCRIPT_MAX_BYTES | 20000 / 768 / 10 / 64000 / 64000 | לתסריט גבולות אחד לחממה 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 קוד ידני. השרת פותר את מקור לוח הבקרה שמשמש לבניית הקישור בשלוש רמות:
- כותר
X-AgentEye-Dashboard-Url: הגדר באופן אוטומטי על ידי פרוקסי/api/auth/otp/requestשל לוח הבקרה מהמקור הציבורי שלו. בפריסה same-origin (שרת ולוח בקרה חלוקים מארח מאחורי ingress אחד שהכותרות פרוקסי מעבר), אין תצורה נדרשת. DASHBOARD_URLenv var: הגדר זאת אם לוח הבקרה שלך מושג ב-origin אחר מזה שנקודת הקשה OTP של השרת רואה (splitapi.example.com/app.example.com), או אם ingress שלך לא מתפשר את המארח הציבורי לתוך פוד לוח הבקרה (אזrequest.nextUrl.originיפתור אחרת כמו0.0.0.0:3000). דוגמה:DASHBOARD_URL=https://app.example.com.- ברירת מחדל:
https://app.befailproof.ai, משומש רק אם לא אחד משני הלעיל קיים.
https://* ו-loopback (http://localhost*, http://127.0.0.1*) origins מקובלים, וכתובות wildcard bind (0.0.0.0, [::]) דחויים גם עם התוכנית https://. כל דבר אחר נופל דרך לרמה 2.
הגדר אותו על אשכול רץ עם בר תיל; אין קובץ, אין kustomize שיבוא מחדש:
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-256dedup_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.
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 dedupquery_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_aggregaterollup (הכבד ביותר שאילתה לוח הבקרה סקרים), ה-/sessionsרשימה, וסוויץ’ שיעור הגבלה בקשה OTP מ-PostgresCOUNT(*)ל-RedisINCR + EXPIRE. - Dashboard משמור
validateSession()תוצאות אז ה-10-20 authed API מטלות עלות דף טיפול שכל חלוקה משותף אחד בדיקה זרם שרת. זה גם משעות מקצב OTP-בקשה וOTP-עד זה קצה לוח הבקרה.
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-ins | ALLOWED_EMAILS | דוא”לים (או *@domain.com תעדול) בהיתר OTP לקבל וליהיות יצור כמו משתמשים |
| המשתמש הרשאות ברירת מחדל | DEFAULT_USER_PERMISSIONS | פסיק-מופרדים הרשאה אסימונים preselected מתי admin פועל + חדש משתמש. כל אסימון חייב להיות אחד מ-מחרוזות תחת API key הרשאות. ברירות ל-standard preset: read-only גישה בתוספת בכל-יום on-call פעולות (טריגר re-הערכות, הפעלה שאילתות, ack התרעות, השתמש העוזר). |
| פעילות lifetime | SESSION_TTL_SECS | כמה זמן לוח בקרה כניסה נשאר תקף לפני re-auth. לוח הבקרה re-בדיקות זרם שרת פעילות כל 5 שניות, אז הרשאה update על /<org>/users בעלויות השפעו משתמש הבא בקשה, ללא relogin. |
| חד-פעמי-קוד lifetime | OTP_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: שמור שינויים.
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
