> ## Documentation Index > Fetch the complete documentation index at: https://docs.befailproof.ai/llms.txt > Use this file to discover all available pages before exploring further. # परिनियोजन > AgentEye परिनियोजन दस्तावेज़। यह मार्गदर्शिका 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 (वैकल्पिक कैश)** देखें। *** ## सर्वर ### छवि खींचें ```bash theme={null} echo $AGENTEYE_TOKEN | docker login ghcr.io -u x --password-stdin docker pull ghcr.io/agenteye-enterprise/server:beta-latest ``` > वर्तमान बिल्ड `beta-latest` के तहत प्रकाशित होते हैं; `latest` केवल स्थिर रिलीज़ को असाइन किया जाता है। उत्पादन के लिए, एक विशिष्ट `:v` टैग को पिन करें; देखें [Available Image Tags](#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 का [`//settings`](#operational-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) | डैशबोर्ड सत्र अवधि सेकंड में। **पहली-बूट सीड केवल**: [`//settings`](#operational-settings) के माध्यम से पहली तैनाती के बाद प्रति org संपादित करें। | | `OTP_TTL_SECS` | नहीं | `600` (10 मिनट) | OTP कोड वैधता अवधि सेकंड में। **पहली-बूट सीड केवल**: [`//settings`](#operational-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, डैशबोर्ड पथ यह रहता है (`//…`)। `DEFAULT_ORG_NAME` के समान पहली-बूट-केवल / कौवारी-केवल शब्दार्थ। 1-40 लोअरकेस अल्फान्यूमेरिक्स एकल आंतरिक हाइफन और [आरक्षित शब्द](#organizations-multi-tenancy) नहीं होना चाहिए; एक अमान्य मान अनदेखा किया जाता है (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](/hi/agenteye/evaluation-suite)। | | `EVALUATOR_TOKEN` | नहीं | कोई नहीं | मूल्यांकक को `Authorization: Bearer ` के रूप में भेजा जाता है। **मूल्यांकक सेवा के साथ समान मान के बराबर होना चाहिए।** केवल वैकल्पिक यदि आपका मूल्यांकक कोई टोकन के साथ कॉन्फ़िगर नहीं है। | | `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](/hi/agenteye/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](/hi/agenteye/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](/hi/agenteye/assistant)। | **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` सेट करें, फिर इसे कंटेनर में पास करें: ```bash theme={null} 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](/hi/agenteye/health-monitoring), Slack को opt-in Kubernetes-native pod-failure अलर्टिंग सहित। ### ईमेल magic-link URL OTP लॉगिन ईमेल में एक one-tap **डैशबोर्ड खोलें** बटन होता है। इस पर क्लिक करने से उपयोगकर्ता `/login?token=&email=
` पर आते हैं; डैशबोर्ड उस जोड़ी को एक सत्र के लिए विनिमय करता है और ऐप में पुनर्निर्देशित करता है, कोई manual code re-entry के साथ नहीं। सर्वर तीन स्तरों में लिंक बनाने के लिए उपयोग किए जाने वाले डैशबोर्ड मूल को हल करता है: 1. **`X-AgentEye-Dashboard-Url` हेडर**: डैशबोर्ड के अपने `/api/auth/otp/request` proxy द्वारा अपने स्वयं के सार्वजनिक मूल से स्वचालित रूप से सेट किया जाता है। एक same-origin परिनियोजन में (सर्वर और डैशबोर्ड एक होस्ट को साझा करते हैं जो proxy हेडर को forward करता है), **कोई कॉन्फ़िगरेशन आवश्यक नहीं है**। 2. **`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`। 3. **Default**: `https://app.befailproof.ai`, केवल यदि उपरोक्त में से कोई भी मौजूद नहीं है। हेडर मान सत्यापित किया जाता है: केवल `https://*` और loopback (`http://localhost*`, `http://127.0.0.1*`) मूल स्वीकार किए जाते हैं, और wildcard bind पते (`0.0.0.0`, `[::]`) को `https://` स्कीम के साथ भी अस्वीकार किया जाता है। कुछ और भी टियर 2 में पड़ता है। एक-लाइनर के साथ एक चल रहे क्लस्टर पर इसे सेट करें; कोई फ़ाइल नहीं, कोई kustomize पुनर्निर्माण नहीं: ```bash theme={null} 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 जोड़ते हैं। *** ## डैशबोर्ड ### छवि खींचें ```bash theme={null} 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](#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](/hi/agenteye/assistant)। | | `AGENTEYE_AGENT_TOKEN` | नहीं | कोई नहीं | साझा गुप्त डैशबोर्ड `agent` सेवा को प्रस्तुत करता है। एजेंट पर कॉन्फ़िगर किए गए `AGENTEYE_AGENT_TOKEN` से मेल खाना चाहिए। देखें [enterprise-docs/assistant.md](/hi/agenteye/assistant)। | ### चलाएं ```bash theme={null} 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=@/`, 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](/hi/agenteye/assistant)** में हैं। *** ## 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](/hi/agenteye/kubernetes-deployment) की **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 करता है। ```bash theme={null} 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 ``` ```bash theme={null} docker compose up -d ``` **रोकें (डेटा volume को रखता है):** ```bash theme={null} docker compose down ``` **रोकें और सभी डेटा को wipe करें:** ```bash theme={null} docker compose down -v ``` *** ## ऑपरेशनल सेटिंग्स एक छोटा सेट operational knobs जो env vars द्वारा pinned हुआ करते थे अब dashboard के **`//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](/hi/agenteye/api-keys) के तहत 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 को फिर से जांचता है, इस |