परिनियोजन

यह मार्गदर्शिका AgentEye सर्वर और डैशबोर्ड को उत्पादन में परिनियोजित करने को कवर करती है।

आर्किटेक्चर अवलोकन

  [ AI agent machines ]                  [ Your infrastructure ]

    Python SDK
       |  writes JSONL                       +----------------------+
       v                                +--->| PostgreSQL 15+       |
 agenteye-collector --HTTP--+           |    | (relational store)   |
                            |           |    +----------------------+
                            v           |
                       +--------+       |    +----------------------+
                       | Server |<------+--->| ClickHouse 24+       |
                       +--------+       |    | (events / analytics) |
                            ^           |    +----------------------+
                        API |           |
                            |           |    +----------------------+
                      +-----------+     +- - >| Redis 7+ (optional) |
                      | Dashboard |           +----------------------+
                      +-----------+

Server: Rust HTTP सेवा; ईवेंट बैच प्राप्त करता है, उन्हें ClickHouse में लिखता है, और PostgreSQL में संबंधपरक स्थिति को बनाए रखता है।
Dashboard: Next.js वेब ऐप्लिकेशन; विशेष रूप से सर्वर API के माध्यम से पढ़ता और लिखता है।
agenteye-collector: सर्वर होस्ट पर नहीं, एजेंट मशीनों पर परिनियोजित।
Postgres 15+: आवश्यक। (बहु-किरायेदार रिलीज़ में 14 से बढ़ाया गया; org-membership स्कीमा एक कॉलम-सूची 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 संपादक और AI एजेंट के लिए इंजन-लागू पृथक्करण सीमा)। यदि आप अपनी स्वयं की ClickHouse कॉन्फ़िग प्रदान करते हैं, तो इन सेटिंग्स को ले जाएं (देखें deploy/base/clickhouse/configmap.yaml)।
Redis 7+: वैकल्पिक साझा कैश + दर-सीमा बैकएंड। सर्वर और डैशबोर्ड दोनों REDIS_URL के माध्यम से कनेक्ट करते हैं। यदि अनुपस्थित है, तो दोनों केवल-Postgres पथों में सुंदरता से खराब हो जाते हैं। नीचे Redis (वैकल्पिक कैश) देखें।

सर्वर

छवि खींचें

echo $AGENTEYE_TOKEN | docker login ghcr.io -u x --password-stdin
docker pull ghcr.io/agenteye-enterprise/server:beta-latest

वर्तमान बिल्ड beta-latest के तहत प्रकाशित होते हैं; latest केवल स्थिर रिलीज़ को असाइन किया जाता है। उत्पादन के लिए, एक विशिष्ट :v<version> टैग को पिन करें; देखें Available Image Tags।

पर्यावरण चर

चर	आवश्यक	डिफ़ॉल्ट	विवरण
`DATABASE_URL`	हां	कोई नहीं	Postgres DSN। मानक libpq कनेक्शन स्ट्रिंग प्रारूप स्कीम `postgres://` के साथ। `?sslmode=require` और अन्य libpq पैरामीटर का समर्थन करता है। पासवर्ड में `/`, `+`, या `=` नहीं हो सकता; URL-सुरक्षित पासवर्ड उत्पन्न करने के लिए `openssl rand -hex` का उपयोग करें।
`ADMIN_KEY`	नहीं	कोई नहीं	बूटस्ट्रैप व्यवस्थापक API कुंजी। हर स्टार्टअप पर सभी अनुमतियों के साथ upsert किया जाता है। मान बदलकर और पुनरारंभ करके घुमाएं।
`LISTEN_ADDR`	नहीं	`0.0.0.0:8080`	बाइंड करने के लिए TCP पता
`MAX_BODY_BYTES`	नहीं	`134217728` (128 MB)	अधिकतम अनुरोध बॉडी आकार
`ADMIN_EMAIL`	नहीं	कोई नहीं	बूटस्ट्रैप व्यवस्थापक उपयोगकर्ता ईमेल। हर स्टार्टअप पर सभी अनुमतियों के साथ upsert किया जाता है और संरक्षित के रूप में चिह्नित किया जाता है: डैशबोर्ड/API के माध्यम से अक्षम नहीं किया जा सकता या अनुमतियों को संशोधित नहीं किया जा सकता। बूटस्ट्रैप व्यवस्थापक को घुमाने के लिए, `ADMIN_EMAIL` को बदलें और पुनरारंभ करें; नया ईमेल सुरक्षित के रूप में upsert किया जाता है, और पिछला वाला अपनी सुरक्षा को बनाए रखता है जब तक कि डेटाबेस में मैन्युअल रूप से साफ़ नहीं किया जाता।
`ALLOWED_EMAILS`	नहीं	कोई नहीं (सभी अवरुद्ध)	उपयोगकर्ता निर्माण और लॉगिन के लिए अनुमत ईमेल की अल्पविराम-विभाजित सूची। सटीक पते (`user@example.com`) और डोमेन वाइल्डकार्ड (`@example.com`) का समर्थन करता है। यदि सेट नहीं है, तो कोई उपयोगकर्ता बनाया नहीं जा सकता या लॉगिन नहीं कर सकता। पहली-बूट सीड केवल*: पहली बूट पर डिफ़ॉल्ट org के allowlist को सीड करता है; उसके बाद प्रत्येक org का `/<org>/settings` पृष्ठ सत्य का स्रोत है और इस env var को बदलने का कोई प्रभाव नहीं है।
`SMTP_HOST`	नहीं	कोई नहीं	OTP ईमेल भेजने के लिए SMTP सर्वर होस्टनाम। यदि सेट नहीं है, तो 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/घटना दोनों लिंक आपके डैशबोर्ड पर इंगित करें। नीचे Email magic-link URL देखें; अधिकांश ऑपरेटर को इसे सेट करने की आवश्यकता नहीं है।
`SESSION_TTL_SECS`	नहीं	`86400` (24 h)	डैशबोर्ड सत्र अवधि सेकंड में। पहली-बूट सीड केवल: `/<org>/settings` के माध्यम से पहली तैनाती के बाद प्रति org संपादित करें।
`OTP_TTL_SECS`	नहीं	`600` (10 मिनट)	OTP कोड वैधता अवधि सेकंड में। पहली-बूट सीड केवल: `/<org>/settings` के माध्यम से पहली तैनाती के बाद प्रति org संपादित करें।
`REDIS_URL`	नहीं	कोई नहीं	वैकल्पिक साझा कैश + दर-सीमा बैकएंड, उदाहरण `redis://redis:6379/0`। जब सेट किया जाता है, तो सर्वर प्रमाणित API-कुंजी लुकअप, डैशबोर्ड के `/models` एकत्रित, सत्र सूची, और env-list पहलू को कैश करता है; यह OTP-अनुरोध दर सीमा को Postgres COUNT से Redis INCR में भी स्थानांतरित करता है। यदि सेट नहीं है या अप्राप्य है, तो सर्वर कैश के बिना चलता है (OTP सीमा Postgres में वापस आती है, हर दूसरे कैश कॉल सत्य के स्रोत में पड़ता है)। नीचे Redis (वैकल्पिक कैश) देखें।
`CLICKHOUSE_URL`	हां	कोई नहीं	ClickHouse उदाहरण का आधार URL, उदाहरण `http://clickhouse:8123`। सर्वर हर स्टार्टअप पर इस डेटाबेस पर अपनी ईवेंट स्कीमा लागू करता है और यदि यह ClickHouse तक नहीं पहुंच सकता तो बूट करने से इंकार करता है। नीचे ClickHouse (आवश्यक विश्लेषण स्टोर) देखें।
`CLICKHOUSE_DATABASE`	नहीं	`agenteye`	ClickHouse डेटाबेस (स्कीमा) नाम। सर्वर स्टार्टअप पर इसे बनाता है यदि यह मौजूद नहीं है।
`ORG_CH_SECRET`	नहीं (एकल-किरायेदार) / हां (बहु-org)	dev डिफ़ॉल्ट	HMAC कुंजी जिससे प्रत्येक संगठन की प्रति-किरायेदार ClickHouse पासवर्ड व्युत्पन्न होता है। SQL संपादक और AI एजेंट के `run_query` org की अपनी केवल-पढ़ने योग्य ClickHouse उपयोगकर्ता के रूप में निष्पादित होते हैं, जिसकी पंक्ति नीति इंजन में किरायेदार अलगाव को लागू करती है। एकल-किरायेदार परिनियोजन निर्मित-में dev डिफ़ॉल्ट पर ठीक बूट करते हैं; दूसरा org प्रदान करने से पहले आपको एक मजबूत, स्थिर मान सेट करना होगा, क्योंकि `agenteye-orgctl org create` CLI निर्मित-में dev डिफ़ॉल्ट पर चलने से इंकार करता है। इसे घुमाना हर org के ClickHouse उपयोगकर्ता को तब तक अनाथ कर देता है जब तक अगली स्टार्टअप उन्हें पुनः प्रावधान न करे (बूट-समय समेटना इसे स्वचालित रूप से ठीक करता है)। इसे गुप्त रखें और प्रतिकृतियों में अपरिवर्तित रखें। Org प्रावधान ही ऑपरेटर-केवल है; नीचे Organizations (multi-tenancy) देखें।
`DEFAULT_ORG_NAME`	नहीं	`Default`	निर्मित-में डिफ़ॉल्ट org के लिए seeded प्रदर्शन नाम। पहली-बूट सीड केवल, और केवल जबकि org अभी भी इसे ताज़ा-माइग्रेट किए गए सामान्य पहचान से संभाले, स्टार्टअप पर लागू, फिर अनदेखा किया जाता है। एक बार जब आप org का नाम बदल देते हैं (`agenteye-orgctl org rename`) नाम बदलना सत्तामूलक हो जाता है और इस env var का आगे कोई प्रभाव नहीं है।
`DEFAULT_ORG_SLUG`	नहीं	`default`	निर्मित-में डिफ़ॉल्ट org के लिए URL slug, डैशबोर्ड पथ यह रहता है (`/<slug>/…`)। `DEFAULT_ORG_NAME` के समान पहली-बूट-केवल / कौवारी-केवल शब्दार्थ। 1-40 लोअरकेस अल्फान्यूमेरिक्स एकल आंतरिक हाइफन और आरक्षित शब्द नहीं होना चाहिए; एक अमान्य मान अनदेखा किया जाता है (org `default` को रखता है)। एकल-किरायेदार स्थापना को कोई पोस्ट-तैनात CLI चरण के बिना `/default` के बजाय उदाहरण के लिए `/acme` के रूप में प्रस्तुत करने देता है।
`RUST_LOG`	नहीं	`info`	लॉग verbosity (`debug`, `warn`, `error`, `agenteye_server=trace`)
`EVALUATOR_ENDPOINT`	नहीं	कोई नहीं	आपकी मूल्यांकन सेवा का आधार URL (उदाहरण `http://evaluator:9000`)। जब सेट न हो तो संपूर्ण मूल्यांकन पाइपलाइन एक no-op है; कोई कतार पंक्तियां लिखी नहीं जाती, कोई कार्यकर्ता नहीं चलते। देखें Evaluation Suite।
`EVALUATOR_TOKEN`	नहीं	कोई नहीं	मूल्यांकक को `Authorization: Bearer <token>` के रूप में भेजा जाता है। मूल्यांकक सेवा के साथ समान मान के बराबर होना चाहिए। केवल वैकल्पिक यदि आपका मूल्यांकक कोई टोकन के साथ कॉन्फ़िगर नहीं है।
`EVALUATOR_WORKERS`	नहीं	`2`	Concurrency: प्रति सर्वर उदाहरण worker कार्यों की संख्या जो मूल्यांकन dispatch करते हैं। क्षैतिज रूप से स्केल किए गए कई सर्वरों में चलाने के लिए सुरक्षित।
`EVALUATOR_CLAIM_BATCH`	नहीं	`4`	अधिकतम संख्या मूल्यांकन एक एकल worker प्रति टिक दावा करता है। बैच concurrently dispatch किए जाते हैं, इसलिए आपके मूल्यांकक endpoint पर कुल concurrency `EVALUATOR_WORKERS × EVALUATOR_CLAIM_BATCH` है।
`EVALUATOR_POLL_IDLE_SECS`	नहीं	`2`	जब कुछ भी कारण न हो तो worker कितने समय सोते हैं dispatch प्रयासों के बीच।
`EVALUATOR_POLLING_INTERVAL_SECS`	नहीं	`10`	अंतिम fallback cadence (सेकंड) `GET /evaluate/{id}` के लिए जब मूल्यांकक प्रति-प्रतिक्रिया `next_poll_secs` नहीं लौटाता और `GET /config` से `default_poll_interval_secs` का विज्ञापन नहीं करता।
`EVALUATOR_REQUEST_TIMEOUT_MS`	नहीं	`30000`	मूल्यांकक के विरुद्ध प्रति-HTTP-अनुरोध timeout (मिलीसेकंड)।
`EVALUATOR_MAX_ATTEMPTS`	नहीं	`5`	इस कई विफल प्रयासों के बाद एक मूल्यांकन टर्मिनल `error` (या `timeout` यदि विफलताएं request timeouts थीं) के रूप में दर्ज किया जाता है।
`EVALUATOR_CONFIG_REFRESH_SECS`	नहीं	`300` (5 मिनट)	सर्वर कितनी बार मूल्यांकक से `GET /config` को पुनः प्राप्त करता है।
`EVALUATOR_MAX_POLL_DURATION_SECS`	नहीं	`3600` (1 h)	अधिकतम wallclock समय एक सत्र पोलिंग कतार में रह सकता है इससे पहले कि AgentEye इसे `timeout` के रूप में समाप्त कर दे। एक मूल्यांकक के खिलाफ सुरक्षा जो `pending` को forever वापस लौटाता है।
`ALERT_WORKERS`	नहीं	`1`	Concurrency: प्रति सर्वर उदाहरण worker कार्यों की संख्या जो अलर्ट नियमों का मूल्यांकन करते हैं। देखें Alerts।
`ALERT_CLAIM_BATCH`	नहीं	`16`	अधिकतम संख्या अलर्ट एक एकल worker प्रति टिक दावा करता है।
`ALERT_POLL_IDLE_SECS`	नहीं	`5`	कितने समय एक alerts worker सोते हैं जब कतार खाली है।
`ALERT_REQUEST_TIMEOUT_MS`	नहीं	`15000`	प्रति-trigger मूल्यांकन timeout (ClickHouse queries + आउटबाउंड चैनल HTTP)।
`ALERT_MAX_ATTEMPTS`	नहीं	`5`	क्रमिक transient विफलताएं इससे पहले कि एक अलर्ट अपने सामान्य cadence पर reschedule करे exponential backoff के बजाय।
`AUDIT_WORKERS`	नहीं	`1`	Concurrency: प्रति सर्वर उदाहरण worker कार्यों की संख्या जो audits को निष्पादित करते हैं। देखें Audits।
`AUDIT_CLAIM_BATCH`	नहीं	`1`	अधिकतम संख्या due audits एक एकल worker प्रति टिक दावा करता है। एक agentic जांच एक लंबा लूप है, इसलिए डिफ़ॉल्ट 1 है।
`AUDIT_POLL_IDLE_SECS`	नहीं	`30`	कितने समय एक audits worker सोते हैं जब कोई audit due नहीं है।
`AUDIT_REQUEST_TIMEOUT_MS`	नहीं	`30000`	ClickHouse के विरुद्ध प्रति-policy-query timeout (मिलीसेकंड)।
`AUDIT_LLM_TIMEOUT_MS`	नहीं	`1440000`	AI सहायक सेवा के लिए agentic जांच कॉल के लिए timeout। एक पूर्ण agent लूप मिनटों के लिए चलता है; इसे agent के अपने `AGENTEYE_AUDIT_TIMEOUT_MS` के ऊपर रखें ताकि agent सर्वर देने से पहले अपनी आंशिक निष्कर्ष वापस लौटाए।
`AUDIT_MAX_ATTEMPTS`	नहीं	`5`	क्रमिक transient विफलताएं इससे पहले कि एक audit अपने सामान्य cadence पर reschedule करे exponential backoff के बजाय।
`AGENTEYE_AGENT_URL` / `AGENTEYE_AGENT_TOKEN`	नहीं	—	audit की agentic जांच AI-सहायक `agent` सेवा को कॉल करती है, सहायक के समान कनेक्शन का पुनः उपयोग करते हुए — इसलिए इन दोनों को सर्वर पर भी सेट करें (बंडल किए गए manifests/compose करते हैं)। दोनों सेट ⇒ audits AI जांच चलाते हैं; कोई भी सेट न हो ⇒ audits policy-only चलाते हैं (deterministic SQL policy pass अभी भी चलता है), प्रति-audit `llm_enabled` फ़्लैग की परवाह किए बिना। एजेंट के पास भी एक LLM कॉन्फ़िगर किया होना चाहिए — देखें assistant.md।

AI सहायक सेवा — audit + sandbox सेटिंग्स। agentic जांच और इसके in-pod Python sandbox एजेंट सेवा पर ट्यून किए जाते हैं (सर्वर पर नहीं), सभी AGENTEYE_AUDIT_* उपसर्ग पर और सभी वैकल्पिक:

चर	डिफ़ॉल्ट	अर्थ
`AGENTEYE_AUDIT_MAX_STEPS`	`200`	प्रति जांच max agent turns।
`AGENTEYE_AUDIT_TIMEOUT_MS`	`1200000`	एक जांच के लिए Wall-clock (20 मिनट)। सर्वर के `AUDIT_LLM_TIMEOUT_MS` के नीचे रहना चाहिए।
`AGENTEYE_AUDIT_MAX_CONCURRENCY`	`1`	एजेंट pod के साथ concurrent जांच (chat सहायक के बजट से अलग)।
`AGENTEYE_AUDIT_SANDBOX_TIMEOUT_MS` / `_MEM_MB` / `_CPU_SECS` / `_OUTPUT_MAX_BYTES` / `_SCRIPT_MAX_BYTES`	`20000` / `768` / `10` / `64000` / `64000`	bubblewrap sandbox के लिए प्रति-स्क्रिप्ट सीमाएं।

Sandbox platform आवश्यकता। audit code sandbox model के Python को एक bubblewrap जेल में चलाता है, जिसे unprivileged user namespaces की आवश्यकता है। एजेंट pod को clone() फ़्लैग की अनुमति देनी चाहिए — seccompProfile: Unconfined (k8s) या security_opt: [seccomp:unconfined] (compose) को agent पर सेट करें। जहां node kernel unprivileged user namespaces को अक्षम करता है (उदाहरण कुछ GKE COS छवियां), sandbox preflight विफल हो जाता है और auditor स्वचालित रूप से SQL-only में downgrade हो जाता है — कोई त्रुटि नहीं, केवल agent के /health पर sandbox_available: false।

चलाएं

अपने वातावरण में DATABASE_URL सेट करें, फिर इसे कंटेनर में पास करें:

docker run -d --restart unless-stopped \
  --name agenteye-server \
  -e DATABASE_URL="$DATABASE_URL" \
  -e ADMIN_KEY="$ADMIN_KEY" \
  -p 8080:8080 \
  ghcr.io/agenteye-enterprise/server:beta-latest

सर्वर स्टार्टअप पर स्वचालित रूप से डेटाबेस माइग्रेशन चलाता है; कोई अलग migration चरण आवश्यक नहीं है।

स्वास्थ्य जांच

GET /health    # liveness  - हमेशा {"status":"ok"} एक बार प्रक्रिया ऊपर है
GET /ready     # readiness - 200 जब Postgres + ClickHouse पहुंचने योग्य हैं, अन्यथा 503

कोई प्रमाणीकरण आवश्यक नहीं है। liveness probes के लिए /health और readiness / load-balancer probes के लिए /ready का उपयोग करें। /ready उन कठोर निर्भरताओं की जांच करता है जो सर्वर बिना सेवा नहीं कर सकता (Postgres + ClickHouse), इसलिए एक सर्वर जो चल रहा है लेकिन अपने डेटाबेस तक नहीं पहुंच सकता है rotation से बाहर निकाला जाता है और NotReady के रूप में दिखाया जाता है; Redis रिपोर्ट किया जाता है लेकिन कभी readiness विफल नहीं करता। बंडल किए गए Kubernetes manifests पर readiness probe पहले से ही /ready की ओर इंगित करता है और liveness /health पर रहता है। पूर्ण चित्र के लिए देखें enterprise-docs/health-monitoring.md, Slack को opt-in Kubernetes-native pod-failure अलर्टिंग सहित।

ईमेल magic-link URL

OTP लॉगिन ईमेल में एक one-tap डैशबोर्ड खोलें बटन होता है। इस पर क्लिक करने से उपयोगकर्ता /login?token=<code>&email=<address> पर आते हैं; डैशबोर्ड उस जोड़ी को एक सत्र के लिए विनिमय करता है और ऐप में पुनर्निर्देशित करता है, कोई manual code re-entry के साथ नहीं। सर्वर तीन स्तरों में लिंक बनाने के लिए उपयोग किए जाने वाले डैशबोर्ड मूल को हल करता है:

X-AgentEye-Dashboard-Url हेडर: डैशबोर्ड के अपने /api/auth/otp/request proxy द्वारा अपने स्वयं के सार्वजनिक मूल से स्वचालित रूप से सेट किया जाता है। एक same-origin परिनियोजन में (सर्वर और डैशबोर्ड एक होस्ट को साझा करते हैं जो proxy हेडर को forward करता है), कोई कॉन्फ़िगरेशन आवश्यक नहीं है।
DASHBOARD_URL env var: यदि आपका डैशबोर्ड एक अलग मूल पर पहुंचने योग्य है (विभाजन api.example.com / app.example.com), या यदि आपका ingress सार्वजनिक होस्ट को डैशबोर्ड pod में propagate नहीं करता (ताकि request.nextUrl.origin अन्यथा एक wildcard bind जैसे 0.0.0.0:3000 में हल करेगा)। उदाहरण: DASHBOARD_URL=https://app.example.com।
Default: https://app.befailproof.ai, केवल यदि उपरोक्त में से कोई भी मौजूद नहीं है।

हेडर मान सत्यापित किया जाता है: केवल https://* और loopback (http://localhost*, http://127.0.0.1*) मूल स्वीकार किए जाते हैं, और wildcard bind पते (0.0.0.0, [::]) को https:// स्कीम के साथ भी अस्वीकार किया जाता है। कुछ और भी टियर 2 में पड़ता है। एक-लाइनर के साथ एक चल रहे क्लस्टर पर इसे सेट करें; कोई फ़ाइल नहीं, कोई kustomize पुनर्निर्माण नहीं:

kubectl set env deployment/server -n agenteye \
  DASHBOARD_URL=https://app.example.com

यह एक rollout ट्रिगर करता है; नई pods पहली अनुरोध पर मान उठाते हैं। ध्यान दें कि override केवल Deployment पर रहता है; kustomize build | kubectl apply के बाद के खिलाफ overlay को लागू करने से इसे मिटा दिया जाएगा जब तक आप अपने overlay के server-env.yaml patch को समान env var जोड़ते हैं।

डैशबोर्ड

छवि खींचें

docker pull ghcr.io/agenteye-enterprise/dashboard:beta-latest

पर्यावरण चर

चर	आवश्यक	डिफ़ॉल्ट	विवरण
`AGENTEYE_SERVER_URL`	हां	कोई नहीं	सर्वर का आधार URL, उदाहरण `http://localhost:8080`
`AGENTEYE_API_KEY`	हां	कोई नहीं	API कुंजी डैशबोर्ड सर्वर के लिए प्रमाणीकरण के लिए उपयोग करता है। सभी अनुमतियों की आवश्यकता है (admin key अनुशंसित)।
`AE_LOG_LEVEL`	नहीं	`info`	सर्वर-साइड लॉग verbosity: `debug`, `info`, `warn`, `error`। समस्याओं के निदान में upstream-request/response लाइनों और सत्र-validation ट्रेस को देखने के लिए `debug` पर सेट करें।
`AE_LOG_JSON`	नहीं	auto	`1` JSON-प्रति-लाइन आउटपुट को बाध्य करता है; `0` मानव-पठनीय आउटपुट को बाध्य करता है। जब सेट न हो, तो JSON स्वचालित रूप से सक्षम होता है यदि `NODE_ENV=production`। JSON उत्पादन में अनुशंसित है इसलिए लॉग `jq` या लॉग एकत्रक के साथ स्वच्छ रूप से parse करते हैं।
`AE_ANALYTICS_DISABLED`	नहीं	कोई नहीं	डैशबोर्ड के anonymous product-usage telemetry को अक्षम करने के लिए `1`/`true` पर सेट करें। नीचे Telemetry & privacy देखें।
`REDIS_URL`	नहीं	कोई नहीं	वैकल्पिक साझा कैश बैकएंड, उदाहरण `redis://redis:6379/0`। जब सेट किया जाता है, तो डैशबोर्ड प्रतिकृतियों में `validateSession()` परिणामों को कैश करता है और latency-aggregate / env-list proxy routes के लिए Next.js fetch cache को साझा करता है। Edge-साइड OTP अनुरोध और verify rate limits मौजूद होने पर भी Redis का उपयोग करते हैं (यदि Redis अप्राप्य है तो खुले में विफल; सर्वर-साइड सीमा security backstop है)। नीचे Redis (वैकल्पिक कैश) देखें।
`AGENTEYE_AGENT_URL`	नहीं	कोई नहीं	वैकल्पिक AI-सहायक `agent` सेवा का आधार URL, उदाहरण `http://agent:9100`। इसे सहायक को पूरी तरह छिपाने के लिए सेट न करें: डैशबोर्ड में कोई सहायक बुलबुला दिखाई नहीं देता। देखें enterprise-docs/assistant.md।
`AGENTEYE_AGENT_TOKEN`	नहीं	कोई नहीं	साझा गुप्त डैशबोर्ड `agent` सेवा को प्रस्तुत करता है। एजेंट पर कॉन्फ़िगर किए गए `AGENTEYE_AGENT_TOKEN` से मेल खाना चाहिए। देखें enterprise-docs/assistant.md।

चलाएं

docker run -d --restart unless-stopped \
  --name agenteye-dashboard \
  -e AGENTEYE_SERVER_URL="http://your-server-host:8080" \
  -e AGENTEYE_API_KEY="$ADMIN_KEY" \
  -p 3000:3000 \
  ghcr.io/agenteye-enterprise/dashboard:beta-latest

Telemetry & privacy

डैशबोर्ड anonymous product-usage analytics Exosphere की analytics सेवा (PostHog) को भेजता है: कौन से डैशबोर्ड पेज देखे जाते हैं और UI actions की एक मुट्ठी जैसे एक API key बनाना या एक सत्र का पुनः मूल्यांकन करना। यह उपयोग सिग्नल सूचित करता है कि कौन से features को प्राथमिकता दी जाती है।

कोई एजेंट, सत्र, या ईवेंट डेटा कभी आपके infrastructure को नहीं छोड़ता। केवल डैशबोर्ड UI उपयोग रिपोर्ट किया जाता है। पेज URLs भेजने से पहले identifiers से छीन दिए जाते हैं, और ऑपरेटरों को केवल एक opaque internal id द्वारा पहचाना जाता है, कभी ईमेल द्वारा नहीं।
Telemetry डिफ़ॉल्ट रूप से सक्षम है। इसे पूरी तरह बंद करने के लिए, डैशबोर्ड कंटेनर पर AE_ANALYTICS_DISABLED=1 सेट करें और पुनरारंभ करें।
Analytics डैशबोर्ड के अपने /ingest पथ को भेजे जाते हैं, जो डैशबोर्ड PostHog को reverse-proxy करता है (https://us.i.posthog.com)। अनुरोधों को first-party रखना मतलब ब्राउज़र ad-blockers उन्हें नहीं छोड़ते। डैशबोर्ड कंटेनर को PostHog के लिए आउटबाउंड एक्सेस की आवश्यकता है; यदि यह अवरुद्ध है, तो telemetry चुप रहकर कुछ नहीं करता है और डैशबोर्ड अप्रभावित है।

AI सहायक (वैकल्पिक)

एक in-dashboard AI सहायक आपकी टीम को उनके एजेंट डेटा को साधारण भाषा में (सत्र summarizing, /queries संपादक के लिए SQL का मसौदा तैयार करना, और सहेजे गए queries को डैशबोर्ड tiles में बदलना) डैशबोर्ड को छोड़े बिना सवाल पूछने देता है। यह एक अलग internal agent कंटेनर (Claude Agent SDK पर) के रूप में चलता है जो केवल डैशबोर्ड तक पहुंच सकता है, और तब तक अक्षम रहता है जब तक आप एक LLM endpoint कॉन्फ़िगर नहीं करते। इसे सक्षम करने के लिए आप agent सेवा पर, एक LLM कनेक्शन (Portkey via PORTKEY_API_KEY + एक model-catalog slug AGENTEYE_AGENT_MODEL=@<slug>/<model>, direct Anthropic via ANTHROPIC_API_KEY, दूसरा gateway via ANTHROPIC_BASE_URL, या Bedrock/Vertex), एक dedicated डेटा key, और एक साझा AGENTEYE_AGENT_TOKEN मिलान डैशबोर्ड सेट करते हैं। डैशबोर्ड उपयोगकर्ताओं को अतिरिक्त रूप से agent:use अनुमति की आवश्यकता है। सहायक के डेटा key के लिए आप हाथ से कुछ भी mint नहीं करते: एक random secret चुनें, इसे agent पर AGENTEYE_API_KEY के रूप में और server पर AGENT_API_KEY के रूप में सेट करें, और सर्वर स्टार्टअप पर fixed permission set के साथ इसे seed करता है। इसका डेटा एक्सेस read-only है (events:read, evaluations:read, dashboards:read, queries:read), और इसके अतिरिक्त approval-gated authoring scopes (dashboards:write, queries:write, queries:run) को होल्ड करता है ताकि यह उपयोगकर्ता की ओर से सहेजे गए queries का मसौदा तैयार और validate कर सकता है और डैशबोर्ड tiles बना सकता है; सभी SQL अभी भी org के read-only ClickHouse role के माध्यम से चलते हैं, इसलिए यह सहायक को क्या डेटा तक पहुंच सकता है, न कि क्या डेटा तक पहुंच सकता है, को चौड़ा करता है। scopes code में fixed हैं और configuration द्वारा चौड़ा नहीं किया जा सकता। वह key संरक्षित है; इसे API के माध्यम से अक्षम या regenerate नहीं किया जा सकता, केवल मान बदलकर और पुनरारंभ करके rotated किया जा सकता है। कभी admin/dashboard key को इसके लिए reuse न करें। पूर्ण सेटअप, पूर्ण environment-variable reference, telemetry विकल्प, और security model enterprise-docs/assistant.md में हैं।

ClickHouse (आवश्यक विश्लेषण स्टोर)

ClickHouse आपके डैशबोर्ड को उच्च ईवेंट volume पर responsive रखता है और /queries SQL संपादक को events, evaluations, और sessions के across join करने देता है एक एकल store में। यह प्रत्येक ingested event, प्रत्येक terminal evaluation outcome, और derived per-session aggregates के लिए आवश्यक canonical store है। PostgreSQL relational / mutable-state tables को रखता है (api_keys, users, otp_codes, evaluation_jobs, dashboards, saved_queries); analytical surface ClickHouse में रहता है ताकि डैशबोर्ड के rollups और आपके स्वयं के SQL queries बिना cross-database round-trips के नेटिवली स्कैन और join कर सकें। सर्वर CLICKHOUSE_URL के बिना बूट करने से इंकार करता है।

स्कीमा

तीन ClickHouse objects सर्वर स्टार्टअप पर बनाए जाते हैं, सभी idempotent (CREATE IF NOT EXISTS):

agenteye.events: ReplacingMergeTree(ingested_at), toYYYYMM(ts) द्वारा विभाजित, (session_id, ts, dedup_key) द्वारा आदेशित। Duplicate inserts (collector retries) merge समय पर एक पंक्ति में collapse हो जाते हैं; सर्वर हर ईवेंट के लिए एक deterministic SHA-256 dedup_key computes करता है इसलिए retries सुरक्षित हैं।
agenteye.evaluations: ReplacingMergeTree(ingested_at), toYYYYMM(finished_at) द्वारा विभाजित, (session_id, finished_at, dedup_key) द्वारा आदेशित। प्रति terminal evaluation outcome evaluator pipeline द्वारा एक बार लिखा गया। events के समान dedup-key model।
agenteye.agent_sessions: एक VIEW agenteye.events के over, एक भौतिक table नहीं। हर स्तंभ व्युत्पन्न है (started_at = min(ts), last_event_at = max(ts), ended_at = max(if event_type='agent_end', ts, NULL), event_count = count(), आदि)। कोई per-event upsert और कोई अलग backfill नहीं; view auto-reflects जो कुछ भी events में है।

saved queries के साथ backwards-compat के लिए जो analytics.evaluations / analytics.sessions को reference करते हैं, सर्वर एक analytics ClickHouse database भी बनाता है agenteye.* tables के over views के साथ; analytics.events, analytics.evaluations, analytics.agent_sessions, analytics.sessions सभी सही तरीके से resolve करते हैं।

कॉन्फ़िगरेशन

बंडल किया गया docker-compose और deploy/base/clickhouse/ AgentEye के workload के लिए ट्यून किए गए एक ClickHouse सेवा को शिप करते हैं:

2 GiB requested / 4 GiB limit memory shipped base overlay में (छोटे POC/staging nodes को fit करने के आकार का); production customers को overlay up करना चाहिए — recommended floor 2c / 4Gi request, 6c / 8Gi limit है। max_server_memory_usage_to_ram_ratio=0.9
5 GiB mark cache + 8 GiB uncompressed cache
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 (supported kernels पर io_uring)
fsync_metadata=0: at-least-once ingest + ReplacingMergeTree dedup के कारण स्वीकार्य
query_log enabled 30-day TTL के साथ; query_thread_log removed (high QPS पर महंगा)
max_execution_time=30 user-साइड queries के लिए
StatefulSet template पर 100 GiB PVC (customer overlays को production के लिए fast SSD storage class में override करना चाहिए)

बैकअप

आपकी पूरी dataset एक एकल restorable archive में nightly कैप्चर की जाती है, इसलिए एक cluster या storage loss recoverable है। ClickHouse को स्वचालित रूप से daily agenteye-backup CronJob द्वारा backed up किया जाता है, जो एक pass में PostgreSQL और ClickHouse दोनों को dumps करता है। ClickHouse को इसके HTTP API के over पढ़ा जाता है: agenteye.events और agenteye.evaluations ClickHouse-native format में dumped होते हैं (views और row policies सर्वर स्टार्टअप पर recreate किए जाते हैं, इसलिए table data पूरी तस्वीर है) और Postgres dump के साथ एक एकल compressed archive में bundled आपकी object storage में uploaded। गंतव्य bucket और cloud credentials प्रति overlay कॉन्फ़िगर किए जाते हैं। upload configuration और restore steps के लिए देखें enterprise-docs/kubernetes-deployment.md की Backups section।

Redis (वैकल्पिक कैश)

Redis एक वैकल्पिक साझा कैश + दर-सीमा बैकएंड है जो सर्वर और डैशबोर्ड द्वारा उपयोग किया जाता है। Redis deployed और दोनों सेवाओं पर REDIS_URL सेट के साथ:

सर्वर authenticated API-key lookups, /events/environments + /evaluations/environments lists, /events/latency_aggregate rollup (सबसे भारी query डैशबोर्ड polls करता है), /sessions list को कैश करता है, और OTP-request rate limiting को Postgres COUNT(*) से Redis INCR + EXPIRE में स्विच करता है।
डैशबोर्ड validateSession() परिणामों को कैश करता है ताकि एक typical page load जो 10-20 authed API calls issues करता है वह सभी एक upstream सत्र जांच साझा करते हैं। यह Dashboard edge पर OTP-request और OTP-verify को भी rate-limit करता है।

दोनों सेवाएं gracefully downgrade करते हैं यदि Redis अप्राप्य है। हर कैश कॉल एक bounded timeout के भीतर Err लौटाता है और caller सत्य के स्रोत में fallback करता है (सर्वर पर Postgres, डैशबोर्ड पर upstream Rust server)। OTP rate limiting सर्वर पर Postgres COUNT(*) पथ में fallback करता है (security property संरक्षित है); डैशबोर्ड का edge OTP limit जबकि सर्वर-साइड limit अभी भी holds fail open करता है। Redis down होना latency को downgrade करता है, correctness को नहीं।

कॉन्फ़िगरेशन

docker-compose bundle पहले से ही एक Redis सेवा को शामिल करता है और REDIS_URL=redis://redis:6379/0 को सर्वर और डैशबोर्ड में wires करता है। एक external Redis का उपयोग करने के लिए, REDIS_URL को अपने endpoint में सेट करें और compose file से redis service को हटा दें।

मेमोरी + persistence

बंडल किया गया Redis image --appendonly yes --appendfsync everysec --maxmemory 256mb --maxmemory-policy allkeys-lru के साथ चलता है। AOF persistence मतलब cache container restarts से survive करता है; everysec सही durability/perf balance है क्योंकि cache writes के last second को खोना harmless है। LRU eviction मेमोरी growth को cap करता है।

कब Redis को deploy न करें

Single-instance dev/QA। सर्वर पर in-process caches अकेले per-replica benefit के अधिकांश को deliver करते हैं; Redis एक cross-replica sharing जोड़ता है जो single-instance setups को नहीं चाहिए।
Air-gapped installs जहां एक service अधिक चलाने का operational cost latency win से outweigh करता है।

Docker Compose (अनुशंसित)

एक docker-compose.yml agenteye-enterprise/releases repo में उपलब्ध है। यह एक एकल कमांड के साथ Postgres, सर्वर, और डैशबोर्ड को up करता है।

GITHUB_TOKEN=$AGENTEYE_TOKEN gh release download \
  --repo agenteye-enterprise/releases \
  --pattern 'docker-compose.yml' \
  --dir ./agenteye
cd agenteye

.env के माध्यम से defaults को override करें:

# URL-safe पासवर्ड का उपयोग करें (कोई /, +, या = characters नहीं)।
# Generate करें: openssl rand -hex 24
POSTGRES_PASSWORD=your-db-password
ADMIN_KEY=your-admin-secret

# डैशबोर्ड प्रमाणीकरण
ADMIN_EMAIL=admin@yourcompany.com
ALLOWED_EMAILS=*@yourcompany.com

# OTP emails के लिए SMTP (OTP codes को stdout में log करने के लिए omit करें)
# SMTP_HOST=smtp.yourprovider.com
# SMTP_PORT=587
# SMTP_USERNAME=your-smtp-user
# SMTP_PASSWORD=your-smtp-password
# SMTP_FROM=noreply@yourcompany.com

RUST_LOG=info

docker compose up -d

रोकें (डेटा volume को रखता है):

docker compose down

रोकें और सभी डेटा को wipe करें:

docker compose down -v

ऑपरेशनल सेटिंग्स

एक छोटा सेट operational knobs जो env vars द्वारा pinned हुआ करते थे अब dashboard के /<org>/settings पृष्ठ से प्रति organization संपादन योग्य हैं; प्रत्येक org अपनी configure करता है। परिवर्तन कुछ सेकंड के भीतर effect लेते हैं, restart और redeploy के बिना।

सेटिंग	Bootstrap env var	इसे क्या नियंत्रित करता है
Allowed साइन-इन	`ALLOWED_EMAILS`	ईमेल (या `*@domain.com` wildcards) OTP प्राप्त करने और उपयोगकर्ताओं के रूप में जोड़े जाने की अनुमति
Default user अनुमतियां	`DEFAULT_USER_PERMISSIONS`	जब एक admin + new user खोलता है तो Comma-separated permission tokens प्रीसिलेक्ट किए जाते हैं। प्रत्येक token API key permissions के तहत listed strings में से एक होना चाहिए। डिफ़ॉल्ट `standard` preset: read-only access plus everyday on-call actions (trigger re-evaluations, run queries, ack incidents, use the assistant)।
Session जीवनकाल	`SESSION_TTL_SECS`	डैशबोर्ड login कितने समय valid रहता है इससे पहले re-auth। डैशबोर्ड हर 5 सेकंड upstream session को फिर से जांचता है, इस

​आर्किटेक्चर अवलोकन

​सर्वर

​छवि खींचें

​पर्यावरण चर

​चलाएं

​स्वास्थ्य जांच

​ईमेल magic-link URL

​डैशबोर्ड

​छवि खींचें

​पर्यावरण चर

​चलाएं

​Telemetry & privacy

​AI सहायक (वैकल्पिक)

​ClickHouse (आवश्यक विश्लेषण स्टोर)

​स्कीमा

​कॉन्फ़िगरेशन

​बैकअप

​Redis (वैकल्पिक कैश)

​कॉन्फ़िगरेशन

​मेमोरी + persistence

​कब Redis को deploy न करें

​Docker Compose (अनुशंसित)

​ऑपरेशनल सेटिंग्स

आर्किटेक्चर अवलोकन

सर्वर

छवि खींचें

पर्यावरण चर

चलाएं

स्वास्थ्य जांच

ईमेल magic-link URL

डैशबोर्ड

छवि खींचें

पर्यावरण चर

चलाएं

Telemetry & privacy

AI सहायक (वैकल्पिक)

ClickHouse (आवश्यक विश्लेषण स्टोर)

स्कीमा

कॉन्फ़िगरेशन

बैकअप

Redis (वैकल्पिक कैश)

कॉन्फ़िगरेशन

मेमोरी + persistence

कब Redis को deploy न करें

Docker Compose (अनुशंसित)

ऑपरेशनल सेटिंग्स