टेनेंट प्रबंधन (संगठन और सदस्य)

एक एकल AgentEye स्थापन कई पूर्ण रूप से अलग-थलग संगठनों (टेनेंट) को सेवा प्रदान करता है, इसलिए एक उदाहरण अलग-अलग टीमों, व्यावसायिक इकाइयों, या ग्राहकों को होस्ट कर सकता है बिना किसी एक टेनेंट के डेटा को दूसरे को उजागर किए। डेटा की प्रत्येक पंक्ति (इवेंट्स, मूल्यांकन, सेशन, डैशबोर्ड, सहेजी गई क्वेरीज़, सतर्कताएं, API कुंजियाँ, और सदस्य) बिल्कुल एक संगठन से संबंधित है। प्राथमिक अलगाव एप्लिकेशन कोड में लागू किया जाता है: हर अनुरोध अपने संगठन के दायरे में होता है स्पष्ट org_id प्रेडिकेट्स के साथ। ClickHouse पर — जहाँ उच्च-मात्रा इवेंट्स और मूल्यांकन रहते हैं — यह मजबूत इंजन-स्तरीय प्रवर्तन द्वारा समर्थित है: प्रत्येक संगठन को एक समर्पित केवल-पढ़ने के लिए ClickHouse उपयोगकर्ता मिलता है प्रति-संगठन पंक्ति नीति के साथ, इसलिए यहां तक कि अविश्वसनीय विश्लेषण SQL कभी भी किसी अन्य टेनेंट की पंक्तियों को नहीं पढ़ सकता। PostgreSQL पर, पंक्ति-स्तरीय सुरक्षा केवल-पढ़ने के लिए क्वेरी पथ (/queries/run) पर रक्षा-गहराई जोड़ता है, संकीर्ण करता है कि पथ क्या देख सकता है भले ही एक एप्लिकेशन-स्तरीय फ़िल्टर कभी गायब हो; सर्वर का अपना लेखन कनेक्शन तालिका मालिक के रूप में चलता है और इसलिए उसी ऐप-स्तरीय org_id स्कोपिंग के माध्यम से संचालित होता है। टेनेंट जीवनचक्र ऑपरेटर-नियंत्रित है, जबकि सदस्य जो कुछ भी दिन-प्रतिदिन करते हैं वह डैशबोर्ड में स्व-सेवा रहता है। संगठन और उनकी सदस्यता agenteye-orgctl CLI के साथ बनाई और प्रबंधित की जाती है, जो सर्वर छवि के अंदर शिप की जाती है और मौजूदा सर्वर पॉड के अंदर चलती है। टेनेंट निर्माण और विलोपन जानबूझकर डैशबोर्ड और HTTP API से दूर रखे जाते हैं: टेनेंट जीवनचक्र के लिए कोई HTTP API नहीं और कोई डैशबोर्ड बटन नहीं है, इसलिए यह एप्लिकेशन सतह के बजाय क्लस्टर/पॉड शेल एक्सेस के पीछे गेटेड है। एक संगठन के भीतर, सदस्य पूरी तरह से डैशबोर्ड और API में काम करते हैं: वे साइन इन करते हैं, उन संगठनों के बीच स्विच करते हैं जिनसे वे संबंधित हैं, अपनी स्वयं की API कुंजियों का प्रबंधन करते हैं, डैशबोर्ड और सहेजी गई क्वेरीज़ बनाते हैं, और अपने संगठन के लिए सतर्कताओं को कॉन्फ़िगर करते हैं। विभाजन स्पष्ट है: ऑपरेटर CLI के माध्यम से टेनेंट और उनके सदस्यों को प्रावधान और बंद करते हैं; सदस्य एक टेनेंट के अंदर UI के माध्यम से सब कुछ चलाते हैं।

एकल-टेनेंट स्थापन को इसमें से कुछ की भी आवश्यकता नहीं है। एकल-टेनेंट इंस्टॉल किसी ऑपरेटर कार्रवाई के बिना चलता है। सभी डेटा, उपयोगकर्ता, और कुंजियाँ एक निर्मित-में default संगठन में रहती हैं जो स्वचालित रूप से प्रावधान की जाती है। आप केवल इस गाइड की आवश्यकता है जब आप दूसरा संगठन जोड़ने का निर्णय लें।

पूर्वापेक्षाएँ

इससे पहले कि आप अपना दूसरा संगठन बनाएं (निर्मित-में default संगठन को कुछ नहीं चाहिए):

PostgreSQL 15+. org-membership स्कीमा एक स्तंभ-सूची ON DELETE SET NULL विदेशी कुंजी का उपयोग करता है जिसके लिए PostgreSQL 15+ की आवश्यकता होती है। दूसरे संगठन को प्रावधान करने से पहले PostgreSQL को अपग्रेड करें।
एक मजबूत, स्थिर ORG_CH_SECRET. प्रत्येक संगठन की ClickHouse पासवर्ड HMAC(ORG_CH_SECRET, org_id) के रूप में प्राप्त की जाती है, इसलिए सार्वजनिक रूप से-ज्ञात निर्मित-में dev डिफ़ॉल्ट सार्वजनिक रूप से-व्युत्पन्न प्रति-संगठन क्रेडेंशियल्स प्राप्त करेगा। agenteye-orgctl org create जब तक ORG_CH_SECRET अनसेट है या निर्मित-में dev डिफ़ॉल्ट पर छोड़ा गया है तब तक चलाने से इनकार करता है। पहले अपना स्वयं का मूल्य सेट करें (देखें Deployment → environment variables और, Kubernetes पर, §2.6 of the Kubernetes guide)। सभी सर्वर प्रतिकृतियों में इसे समान रखें और इसे आकस्मिक रूप से घुमाएं नहीं; इसे घुमाने से हर संगठन की ClickHouse उपयोगकर्ता अनाथ हो जाती है जब तक अगली स्टार्टअप पुनः प्रावधान न करे।

CLI चलाना

agenteye-orgctl सर्वर के समान छवि में शिप किया जाता है (agenteye-server के साथ-साथ)। आप इसके लिए एक अलग पॉड, Job, या Deployment को नहीं तैनात करते हैं; आप इसे सर्वर पॉड के अंदर exec करते हैं जो पहले से चल रहा है, इसलिए यह समान DATABASE_URL, CLICKHOUSE_URL, और ORG_CH_SECRET को पढ़ता है जो सर्वर उपयोग करता है। Kubernetes:

kubectl -n agenteye exec deploy/server -- agenteye-orgctl <args>

Docker Compose:

docker compose exec server agenteye-orgctl <args>

नीचे दिए गए उदाहरण संक्षिप्तता के लिए नंगे agenteye-orgctl <args> दिखाते हैं; प्रत्येक को आपकी तैनाती से मेल खाने वाली ऊपर की दोनों लाइनों में से किसी एक के साथ उपसर्ग करें।

कमांड संदर्भ

संगठन

कमांड	यह क्या करता है
`org create --slug <slug> --name <name>`	एक नया संगठन बनाएं। जब तक `ORG_CH_SECRET` अनसेट है या निर्मित-में dev डिफ़ॉल्ट पर छोड़ा गया है तब तक चलाने से इनकार करता है (पहले अपना स्वयं सेट करें, पूर्वापेक्षाएँ देखें)। संगठन की केवल-पढ़ने के लिए ClickHouse उपयोगकर्ता + पंक्ति नीति को प्रावधान करता है।
`org list`	सभी संगठनों को सूचीबद्ध करें (slug, name, और जीवनचक्र स्थिति)।
`org rename --slug <slug> --name <new name>`	एक संगठन का प्रदर्शन नाम बदलें। slug (URLs और कुंजियों में उपयोग किया जाता है) अपरिवर्तित है।
`org delete --slug <slug>`	संगठन को soft-delete करें और इसके ClickHouse उपयोगकर्ता को छोड़ दें। डेटा बनाए रखा जाता है। यह एक्सेस को रद्द करता है और प्रति-संगठन ClickHouse क्रेडेंशियल को मुक्त करता है, लेकिन इवेंट्स को मिटाता नहीं है। ऑपरेटर द्वारा प्रतिवर्तनीय; शुद्धि से पहले सुरक्षित पहली कदम।
`org purge --slug <slug>`	अप्रतिवर्तनीय डेटा पोंछ। संगठन पहले से ही `delete`d होना चाहिए। कभी भी निर्मित-में `default` संगठन पर अनुमति नहीं। केवल तब उपयोग करें जब आप निश्चित हों कि टेनेंट का डेटा नष्ट हो जाना चाहिए।

सदस्य

कमांड	यह क्या करता है
`member add --org <slug> --email <email> [--set <permission-set>] [--add perm1,perm2] [--remove perm3] [--protected]`	एक सदस्य को संगठन में जोड़ें। वैकल्पिक रूप से एक निर्मित अनुमति सेट से शुरू करें, फिर व्यक्तिगत अनुमतियों को जोड़ें/हटाएं। `--protected` सदस्य को पिन करता है इसलिए डैशबोर्ड उन्हें हटा या डीमोट नहीं कर सकता (नीचे देखें)। नया सदस्य अपने पहले डैशबोर्ड लॉगिन पर एक OTP प्राप्त करता है।
`member list --org <slug>`	संगठन के सदस्यों को सूचीबद्ध करें। आउटपुट स्तंभ `EMAIL`, `SET` (निर्मित सेट जिससे सदस्य शुरू हुआ, या `-`), `PROT` (क्या सदस्य संरक्षित है), और `PERMISSIONS` (उनकी प्रभावी अनुमतियां) हैं। एक अनुगामी `*` के साथ दिखाया गया ईमेल एक उदाहरण व्यवस्थापक है; उनके पास हर संगठन तक पहुंच है।
`member update --org <slug> --email <email> [--set ...] [--add ...] [--remove ...] [--protected \| --unprotect]`	सदस्य की अनुमतियों और/या संरक्षित ध्वज को बदलें। `--set` एक निर्मित सेट से बदलता है; `--add` / `--remove` व्यक्तिगत अनुमतियों को समायोजित करते हैं; `--protected` / `--unprotect` सुरक्षा को टॉगल करते हैं। केवल `--protected`/`--unprotect` (कोई अनुदान ध्वज नहीं) को पास करने से केवल सुरक्षा बदलती है और मौजूदा अनुमतियां अपरिवर्तित छोड़ी जाती हैं।
`member remove --org <slug> --email <email>`	संगठन से एक सदस्य को हटाएं। यदि सदस्य संरक्षित है तो इनकार करता है; पहले उन्हें `--unprotect` करें। (एक व्यक्ति कई संगठनों का सदस्य हो सकता है; यह केवल नामित संगठन को प्रभावित करता है।)

एक व्यक्ति विभिन्न अनुमतियों के साथ एक से अधिक संगठन का सदस्य हो सकता है, उदाहरण के लिए एक संगठन में व्यवस्थापक और दूसरे में केवल-पढ़ने के लिए। प्रत्येक सदस्यता प्रति संगठन स्वतंत्र रूप से प्रशासित होती है: एक संगठन में किसी व्यक्ति की अनुमतियों को देना या बदलना किसी अन्य में उनकी सदस्यता पर कोई प्रभाव नहीं डालता है।

संरक्षित सदस्य (एक अदुहि-हटाने योग्य संगठन प्रशासक)

सुरक्षा गारंटी देती है कि एक संगठन कभी भी स्वयं को स्व-प्रबंधन से आकस्मिक रूप से बाहर नहीं कर सकता। डिफ़ॉल्ट रूप से एक संगठन के अपने व्यवस्थापक डैशबोर्ड के स्व-सेवा उपयोगकर्ताओं पृष्ठ के माध्यम से एक-दूसरे को जोड़ और हटा सकते हैं, इसलिए वे अंतिम प्रशासक को हटा सकते हैं और संगठन को इसे प्रबंधित करने में सक्षम किसी के बिना छोड़ सकते हैं।

उपयोगकर्ताओं पृष्ठ: प्रति डैशबोर्ड उपयोगकर्ता का एक कार्ड उनके ईमेल, दी गई अनुमतियों, और edit/disable नियंत्रणों के साथ

यह रोकने के लिए, एक सदस्य संरक्षित को चिह्नित करें:

kubectl -n agenteye exec deploy/server -- \
  agenteye-orgctl member add --org acme --email owner@acme.example --set admin --protected

एक संरक्षित सदस्य डैशबोर्ड के माध्यम से नहीं हटाया जा सकता या डीमोट नहीं किया जा सकता; ये कार्रवाइयां एक त्रुटि लौटाती हैं। केवल एक ऑपरेटर उन्हें बदल सकता है, और केवल इस CLI के माध्यम से: पहले member update --org acme --email owner@acme.example --unprotect चलाएं, फिर हटाएं या डीमोट करें। यह गारंटी देता है कि हर संगठन कम से कम एक प्रशासक रखता है जिसे इसके अपने सदस्य बाहर नहीं कर सकते, जबकि टेनेंट नियंत्रण को ऑपरेटर-केवल रखते हैं। सुरक्षा प्रति-संगठन है; किसी को एक संगठन में सुरक्षित करना दूसरे में उनकी सदस्यता पर कोई प्रभाव नहीं डालता है।

निर्मित अनुमति सेट

--set तीन निर्मित सेटों में से एक को स्वीकार करता है, प्रति संगठन लागू:

सेट	इसका उद्देश्य है
`admin`	संगठन के भीतर पूर्ण पहुंच, संगठन की API कुंजियों और उपयोगकर्ताओं का प्रबंधन सहित।
`standard`	दिन-प्रतिदिन का उपयोग: पढ़ें + क्वेरीज़ चलाएं, डैशबोर्ड बनाएं, घटनाओं को स्वीकार करें।
`read-only`	संगठन के डेटा और डैशबोर्ड के लिए केवल-देखें पहुंच।

--set के साथ एक सेट से शुरू करें, फिर --add / --remove का उपयोग करके API Keys में सूचीबद्ध व्यक्तिगत अनुमति टोकन के साथ ठीक-ट्यून करें। अनुमति टोकन स्वयं API कुंजियों के लिए उपयोग किए जाने वाले समान हैं।

कार्य किया गया उदाहरण

एक नया acme टेनेंट प्रावधान करें, इसके पहले व्यवस्थापक को जोड़ें, उन्हें एक कुंजी बनाने दें, फिर संगठन को बंद करें। 1. संगठन बनाएं (ORG_CH_SECRET पहले से ही एक मजबूत, स्थिर मूल्य पर सेट होना चाहिए, अनसेट नहीं या निर्मित-में dev डिफ़ॉल्ट):

kubectl -n agenteye exec deploy/server -- \
  agenteye-orgctl org create --slug acme --name "Acme Corp"

2. पहले सदस्य को एक संगठन व्यवस्थापक के रूप में जोड़ें:

kubectl -n agenteye exec deploy/server -- \
  agenteye-orgctl member add --org acme --email alice@acme.example --set admin

Alice को डैशबोर्ड में पहली बार साइन इन करने पर एक OTP प्राप्त होता है। उसके बाद वह पूरी तरह से अपने संगठन के URL उपसर्ग के तहत UI में काम करती है (उदाहरण के लिए /acme/sessions)। 3. प्रति-संगठन API कुंजी बनाएं (डैशबोर्ड में): ऑपरेटर CLI से प्रति-संगठन डेटा कुंजी नहीं बनाता है। Alice (या keys:create के साथ कोई भी संगठन सदस्य) acme संगठन के लिए डैशबोर्ड के Keys पृष्ठ से कलेक्टर / डैशबोर्ड कुंजियां बनाता है। हर कुंजी जो वह बनाती है वह स्वचालित रूप से उसके संगठन के साथ मुहर की जाती है और केवल acme’s डेटा को पढ़ या लिख सकती है। API Keys देखें। 4. बाद में एक सदस्य को समायोजित करें:

kubectl -n agenteye exec deploy/server -- \
  agenteye-orgctl member update --org acme --email alice@acme.example --add alerts:write

kubectl -n agenteye exec deploy/server -- \
  agenteye-orgctl member list --org acme

5. संगठन को soft-delete करें (एक्सेस को रद्द करता है + इसके ClickHouse उपयोगकर्ता को छोड़ता है; डेटा बनाए रखा जाता है):

kubectl -n agenteye exec deploy/server -- \
  agenteye-orgctl org delete --slug acme

6. संगठन को purge करें (अप्रतिवर्तनीय; केवल soft-delete के बाद; कभी भी default संगठन नहीं):

kubectl -n agenteye exec deploy/server -- \
  agenteye-orgctl org purge --slug acme

Docker Compose पर, प्रत्येक kubectl -n agenteye exec deploy/server -- उपसर्ग को docker compose exec server से बदलें।

जिम्मेदारियों का विभाजन

एक संगठन के सदस्य को दिन-प्रतिदिन जरूरत की सब कुछ डैशबोर्ड और API में स्व-सेवा है, स्वचालित रूप से उनके वर्तमान संगठन के दायरे में:

प्रति-संगठन API कुंजियां संगठन के सदस्यों द्वारा डैशबोर्ड में (या कुंजियों API के माध्यम से keys:create को ले जाने वाली कुंजी के साथ) बनाई और प्रबंधित की जाती हैं। CLI डेटा कुंजी नहीं बनाता है। API Keys देखें।
संगठन स्विचिंग डैशबोर्ड में निर्मित है; सदस्य संगठन स्विचर से उन संगठनों के बीच स्विच करते हैं जिनसे वे संबंधित हैं, और संगठन-स्कोप किए गए पृष्ठ /<org-slug>/… के अंतर्गत रहते हैं।
डैशबोर्ड, सहेजी गई क्वेरीज़, सतर्कताएं, और सभी डेटा उपयोग पूरी तरह से UI और API में होता है, सदस्य के वर्तमान संगठन के दायरे में।

ऑपरेटर, agenteye-orgctl का उपयोग करते हुए, केवल संगठन + सदस्य जीवनचक्र के मालिक है: एक संगठन बनाएं / नाम बदलें / हटाएं / purge करें, और एक सदस्य जोड़ें / सूचीबद्ध करें / अपडेट करें / हटाएं।

यह भी देखें

Deployment: ORG_CH_SECRET और बाकी सर्वर पर्यावरण।
Kubernetes Deployment: §2.6 आपके पहले multi-tenant संगठन से पहले agenteye-org-ch-secret Secret बनाता है।
API Keys: प्रति-संगठन कुंजी मॉडल और --add / --remove द्वारा उपयोग की जाने वाली अनुमति टोकन।
Troubleshooting: multi-tenant provisioning और ClickHouse-isolation समस्याएं।

​पूर्वापेक्षाएँ

​CLI चलाना

​कमांड संदर्भ

​संगठन

​सदस्य

​संरक्षित सदस्य (एक अदुहि-हटाने योग्य संगठन प्रशासक)

​निर्मित अनुमति सेट

​कार्य किया गया उदाहरण

​जिम्मेदारियों का विभाजन

​यह भी देखें