Administration

API कुंजियाँ

API कुंजियाँ नियंत्रित करती हैं कि कौन और क्या आपके Failproof AI Observability सर्वर तक पहुँच सकता है, जिससे एक कलेक्टर कभी भी पढ़ने या व्यवस्थापक शक्तियों को प्राप्त किए बिना ईवेंट भेज सकता है। प्रत्येक कुंजी एक या अधिक अनुमतियाँ रखती है, और प्रत्येक अनुमति विशिष्ट सर्वर रूट को नियंत्रित करती है; आप केवल वह अनुमतियाँ देते हैं जो एक कार्य को चाहिए। अधिकांश परिनियोजन केवल तीन प्रकार की कुंजियाँ बनाते हैं।

3 कुंजियाँ जो अधिकांश परिनियोजन को चाहिए

कुंजी	अनुमतियाँ	इसका उपयोग कौन करता है
कलेक्टर कुंजी	`events:add`	प्रत्येक एजेंट मशीन पर `agenteye-collector`, ईवेंट भेजने के लिए।
डैशबोर्ड पढ़ने की कुंजी	`events:read`, `keys:read`	केवल-पढ़ने वाला ऑपरेटर या एकीकरण जो डेटा को बिना बदले क्वेरी करता है।
बूटस्ट्रैप व्यवस्थापक कुंजी	सभी अनुमतियाँ	ऑपरेटर जो पहली बार उदाहरण को चलाता है (और डैशबोर्ड)। `ADMIN_KEY` पर्यावरण चर से बीजित। बूटस्ट्रैप व्यवस्थापक कुंजी देखें।

यहाँ से शुरुआत करें। पूर्ण अनुमति सूची नीचे केवल तभी देखें जब आपको एक संकीर्ण, कस्टम-स्कोप की गई कुंजी चाहिए। अनुशंसित कुंजी लेआउट और कुंजियाँ बनाना भी देखें।

अनुमतियाँ

सर्वर एक निश्चित अनुमतियों की सूची को लागू करता है; प्रत्येक विशिष्ट HTTP रूट को नियंत्रित करता है। एक व्यवस्थापक कुंजी उन सभी को रखती है; एक स्कोप की गई कुंजी उस सबसेट को रखती है जो आप निर्माण पर देते हैं। अज्ञात अनुमति स्ट्रिंग को अस्वीकार कर दिया जाता है जब एक कुंजी बनाई जाती है।

नोट: दो वैध अनुमतियाँ मानव/डैशबोर्ड-केवल हैं और एक API कुंजी को नहीं दी जा सकतीं: orgs:admin (उदाहरण प्रशासन, जो केवल ऑपरेटर के लिए है) और keys:update। POST /keys या PATCH /keys/:id के लिए एक अनुरोध जो इनमें से किसी एक को देने का प्रयास करता है HTTP 422 से अस्वीकार कर दिया जाता है। keys:update पंक्ति देखें कि क्यों एक वाहक कुंजी कुंजियाँ बना सकती है लेकिन कभी संपादित नहीं कर सकती।

ईवेंट अंतर्ग्रहण और क्वेरी

अनुमति	HTTP रूट	यह क्या अनुमति देता है
`events:add`	`POST /events`	एक कलेक्टर से ईवेंट के बैच को अंतर्ग्रहण करें। एकमात्र अनुमति जो एक कलेक्टर को चाहिए।
`events:read`	`GET /events`, `GET /events/latency_aggregate`, `GET /events/environments`, `GET /events/models`, `GET /sessions/:session_id/export`	ईवेंट को क्वेरी करें, ज्ञात वातावरणों की सूची बनाएँ, डेटा में देखे गए मॉडल पहचानकर्ताओं की सूची बनाएँ (मॉडल दृश्य और मॉडल फ़िल्टर द्वारा उपयोग), अव्यवस्थित समन्वय की गणना करें जो ताप-मानचित्र / प्रतिशतक बैंड को शक्ति देता है, और एक सत्र को JSONL के रूप में निर्यात करें। साझा फ़िल्टर-बार पहलू अंतिम बिंदु `GET /events/environments` और `GET /events/agent_ids` या तो `events:read` या `evaluations:read` के साथ पहुँचने योग्य हैं, इसलिए सत्र पृष्ठ (द्वार `evaluations:read`) समान प्रति-ऑर्ग पहलू का पुन: उपयोग करता है। `GET /events/models` उनमें से एक नहीं है: इसे `events:read` की आवश्यकता है, इसलिए केवल `evaluations:read` रखने वाला एक प्रिंसिपल इससे 403 प्राप्त करता है।

सत्र और मूल्यांकन

अनुमति	HTTP रूट	यह क्या अनुमति देता है
`evaluations:read`	`GET /sessions`, `GET /evaluations`, `GET /evaluations/aggregate`, `GET /evaluations/environments`, `GET /evaluation-jobs`	सत्रों की सूची बनाएँ, मूल्यांकन परिणाम पढ़ें, डैशबोर्ड द्वारा उपयोग की जाने वाली रोल-अप मूल्यांकन स्वास्थ्य, और मूल्यांकन-कार्य कार्यकर्ता कतार स्थिति।
`evaluations:trigger`	`POST /sessions/:session_id/re-evaluate`	एक समाप्त सत्र के लिए पुन: मूल्यांकन को मैन्युअल रूप से कतार में डालें।

डैशबोर्ड

अनुमति	HTTP रूट	यह क्या अनुमति देता है
`dashboards:read`	`GET /dashboards`, `GET /dashboards/:id`, `GET /dashboards/:id/tiles`	डैशबोर्ड की सूची बनाएँ, एक को लोड करें, और इसकी टाइलें पढ़ें।
`dashboards:write`	`POST /dashboards`, `PUT /dashboards/:id`, `POST /dashboards/:id/tiles`, `PUT /dashboards/:id/tiles/:tile_id`, `DELETE /dashboards/:id/tiles/:tile_id`, `PUT /dashboards/:id/tiles/layout`	डैशबोर्ड बनाएँ और संपादित करें, टाइलें जोड़ें / संपादित करें / हटाएँ, और टाइल ग्रिड को पुन: क्रमबद्ध करें।
`dashboards:delete`	`DELETE /dashboards/:id`	एक संपूर्ण डैशबोर्ड हटाएँ (टाइल-स्तर का विलोपन `dashboards:write` के तहत रहता है)।

सहेजी गई क्वेरीज़ (SQL संगीतकार)

अनुमति	HTTP रूट	यह क्या अनुमति देता है
`queries:read`	`GET /queries`, `GET /queries/:id`, `GET /queries/schema`	सहेजी गई क्वेरीज़ की सूची बनाएँ, एक को लोड करें, और संगीतकार लक्ष्य के केवल-पढ़ने वाले स्कीमा का निरीक्षण करें।
`queries:write`	`POST /queries`, `PUT /queries/:id`	सहेजी गई क्वेरीज़ बनाएँ और संपादित करें। SQL अभी भी `queries:run` कॉल के समान केवल-पढ़ने वाली भूमिका के माध्यम से दिया जाता है और संरक्षित SQL जांच द्वारा संरक्षित है।
`queries:delete`	`DELETE /queries/:id`	एक सहेजी गई क्वेरी हटाएँ।
`queries:run`	`POST /queries/run`	संगीतकार द्वारा उपयोग की जाने वाली केवल-पढ़ने वाली भूमिका के विरुद्ध सहेजी गई या तदर्थ SQL को निष्पादित करें।

AI सहायक

अनुमति	HTTP रूट	यह क्या अनुमति देता है
`agent:use`	`GET /agent/conversations`, `POST /agent/conversations`, `GET /agent/conversations/:id`, `PATCH /agent/conversations/:id`, `DELETE /agent/conversations/:id`, `PUT /agent/conversations/:id/messages`	AI सहायक से बात करें और अपनी स्वयं की (निजी) बातचीत का प्रबंधन करें। सहायक डॉक देखने के लिए उपयोगकर्ता पर आवश्यक; सहायक की अपनी कुंजी `dashboard-assistant` है और अलग से बीजित है (नीचे देखें)।

API कुंजियाँ

अनुमति	HTTP रूट	यह क्या अनुमति देता है
`keys:create`	`POST /keys`	एक नई स्कोप की गई API कुंजी बनाएँ। मौजूदा कुंजी की अनुमतियों को संपादित करने के लिए नहीं देता है (वह `keys:update` है)।
`keys:read`	`GET /keys`	मौजूदा कुंजियों की सूची बनाएँ। गोपनीयताएँ कभी भी इस अंतिम बिंदु द्वारा नहीं दी जाती हैं।
`keys:update`	`PATCH /keys/:id`	मौजूदा कुंजी की अनुमतियों को संपादित करें। एक मानव/डैशबोर्ड-केवल अनुमति; इसे एक API कुंजी को असाइन नहीं किया जा सकता (एक वाहक कुंजी कुंजियाँ बना सकती है लेकिन उन्हें कभी संपादित नहीं कर सकती)।
`keys:disable`	`POST /keys/:id/disable`	एक कुंजी को रद्द करें। संरक्षित कुंजियाँ (`admin`, `dashboard-assistant`) को अक्षम नहीं किया जा सकता; env var + पुनः आरंभ के माध्यम से उन्हें घुमाएँ।
`keys:regenerate`	`POST /keys/:id/regenerate`	एक कुंजी की गोपनीयता को घुमाएँ। संरक्षित कुंजियों को इस रूट के माध्यम से पुन: निर्मित नहीं किया जा सकता।

डैशबोर्ड उपयोगकर्ता

अनुमति	HTTP रूट	यह क्या अनुमति देता है
`users:create`	`POST /users`, `GET /users/defaults`	एक नए डैशबोर्ड उपयोगकर्ता को आमंत्रित करें (एक ईमेल + एकबारगी पासकोड (OTP) लॉगिन जारी करता है) और डैशबोर्ड-कॉन्फ़िगर की गई डिफ़ॉल्ट अनुमति सेट पढ़ें जो आमंत्रण फॉर्म को बीजित करने के लिए उपयोग किया जाता है।
`users:read`	`GET /users`, `GET /users/:id`	उपयोगकर्ताओं की सूची बनाएँ और एक एकल उपयोगकर्ता रिकॉर्ड लोड करें।
`users:update`	`PUT /users/:id`	एक उपयोगकर्ता की अनुमतियों को संपादित करें। अपडेट प्रभावित उपयोगकर्ता को अनुमति-परिवर्तन ईमेल भेजते हैं और उनके अगले अनुरोध पर प्रभावी होते हैं; कोई पुन: लॉगिन आवश्यक नहीं।
`users:delete`	`DELETE /users/:id`, `POST /users/:id/enable`	एक उपयोगकर्ता को अक्षम करें (उनके सत्र को तुरंत रद्द करता है) और पहले से अक्षम उपयोगकर्ता को पुन: सक्षम करें।

ये अनुमतियाँ डैशबोर्ड के उपयोगकर्ता पृष्ठ को समर्थन देती हैं, जहाँ प्रत्येक सदस्य के दिए गए दायरे चिप्स के रूप में दिखाए जाते हैं:

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

परिचालन सेटिंग्स

अनुमति	HTTP रूट	यह क्या अनुमति देता है
`settings:read`	`GET /settings`, `GET /settings/schema`, `GET /settings/model-context-windows`, `GET /settings/model-context-windows/resolve`	डैशबोर्ड-प्रबंधित परिचालन सेटिंग्स और उनके मेटाडेटा को देखें; प्रति-मॉडल संदर्भ-विंडो ओवरराइड की सूची बनाएँ; और एक मॉडल के लिए प्रभावी विंडो को हल करें।
`settings:write`	`PUT /settings/:key`, `PUT /settings/model-context-windows`, `DELETE /settings/model-context-windows`	परिचालन सेटिंग्स को संपादित करें और प्रति-मॉडल संदर्भ-विंडो ओवरराइड को जोड़ें, बदलें, या हटाएँ। परिवर्तन सर्वर को पुनः आरंभ किए बिना नई ईवेंट को प्रभावित करते हैं।

अलर्ट और घटनाएँ

अनुमति	HTTP रूट	यह क्या अनुमति देता है
`alerts:read`	`GET /alerts`, `GET /alerts/:id`	कॉन्फ़िगर किए गए अलर्ट परिभाषाओं को देखें।
`alerts:write`	`POST /alerts`, `PUT /alerts/:id`, `DELETE /alerts/:id`, `POST /alerts/:id/test`	अलर्ट परिभाषाओं को बनाएँ, संपादित करें, हटाएँ, और परीक्षण-फायर करें।
`incidents:read`	`GET /alerts/incidents`, `GET /alerts/incidents/:iid`, `GET /alerts/incidents/:iid/comments`, `GET /alerts/incidents/:iid/subscribers`	घटनाओं और उनके ट्रिएज ट्रेल को देखें।
`incidents:write`	`POST /alerts/:id/incidents`	एक मौजूदा अलर्ट के विरुद्ध मैन्युअल रूप से एक घटना खोलें।
`incidents:ack`	`POST /alerts/incidents/:iid/ack`, `POST /alerts/incidents/:iid/assign`, `POST /alerts/incidents/:iid/resolve`, `POST /alerts/incidents/:iid/comments`, `POST /alerts/incidents/:iid/subscribe`, `POST /alerts/incidents/:iid/unsubscribe`	घटनाओं को स्वीकार करें, असाइन करें, हल करें, और उन पर टिप्पणी करें।

ऑडिट

अनुमति	HTTP रूट	यह क्या अनुमति देता है
`audits:read`	`GET /audits`, `GET /audits/:id`, `GET /audits/:id/runs`, `GET /audits/findings`, `GET /audits/findings/:fid`	ऑडिट परिभाषाओं, चलाने का इतिहास, और निष्कर्ष देखें।
`audits:write`	`POST /audits`, `PUT /audits/:id`, `DELETE /audits/:id`, `POST /audits/:id/run`, `POST /audits/findings/:fid/status`	ऑडिट बनाएँ, संपादित करें, हटाएँ, और चलाएँ; निष्कर्षों को ट्रिएज करें (स्वीकार करें / म्यूट करें / खारिज करें / हल करें / फिर से खोलें / असाइन करें)।

नोट: एक कुंजी को ऑडिट सतह देने के लिए, इसे audits:* को स्पष्ट रूप से दें। अपग्रेड और बैकवर्ड-संगतता नोट्स देखें कि जब ऑडिट आया तो मौजूदा अनुदानकर्ताओं को कैसे माइग्रेट किया गया।

प्राप्तकर्ता-पिकर अंतिम बिंदु GET /alerts/recipients (जो सदस्य ईमेल सूचीबद्ध करता है एक अलर्ट संपादक को सूचित कर सकता है) या तो alerts:read या alerts:write के धारक द्वारा पहुँचने योग्य है, इसलिए अलर्ट संपादक बिना users:read को दिए गए पिकर को पॉप्युलेट कर सकते हैं।

एक डैशबोर्ड दर्शक को दोनों dashboards:read (सहेजे गए दृश्यों को लोड करने के लिए) और evaluations:read (स्वास्थ्य मेट्रिक्स मूल्यांकन डेटा से गणना की जाती हैं) की आवश्यकता होती है। डैशबोर्ड बनाने या संपादित करने देने के लिए dashboards:write दें, और उन्हें हटाने के लिए dashboards:delete दें।

/health और /auth/* (OTP अनुरोध, OTP सत्यापन, सत्र जांच, लॉगआउट) डिज़ाइन द्वारा प्रमाणीकृत नहीं हैं; वे लॉगिन प्रवाह और जीविता जांच हैं। GET /access-granters एक वैध कुंजी की आवश्यकता है लेकिन कोई विशिष्ट अनुमति नहीं, इसलिए कोई भी लॉगिन उपयोगकर्ता देख सकता है कि किन व्यवस्थापकों से संपर्क करना है।

अनुमति सेट

अनुमति सेट आपको प्रत्येक बार व्यक्तिगत टोकन को चुनने के बजाय एक नामित भूमिका को लागू करने देते हैं। प्रत्येक नए डैशबोर्ड उपयोगकर्ता या API कुंजी के लिए एक दर्जन अनुमतियों को एक-एक करके चुनने के बजाय, आप एक सेट चुनते हैं, और हर कोई इसे असाइन किया गया एक सुसंगत, समीक्षक अनुदान रखता है। एक कस्टम सेट को संपादित करने से पहले से ही इसे असाइन किए गए हर उपयोगकर्ता को नई अनुदान को पुन: लागू किया जाता है, इसलिए एक भूमिका परिवर्तन एक संपादन है बजाय हर सदस्य के माध्यम से एक स्वीप। हर संगठन को तीन अंतर्निहित सेट के साथ बीजित किया जाता है:

सेट	अनुमतियाँ	के लिए इरादा
`read-only`	`events:read`, `keys:read`, `users:read`, `evaluations:read`, `dashboards:read`, `queries:read`, `settings:read`, `alerts:read`, `audits:read`, `incidents:read`	हर परिचालन सतह में केवल-दृश्य पहुँच।
`standard`	`read-only` में सब कुछ, प्लस `evaluations:trigger`, `queries:run`, `incidents:ack`, `agent:use`	केवल-पढ़ें प्लस रोज़मर्रा के ऑन-कॉलर कार्य: क्वेरीज़ चलाएँ, सत्रों को पुन: मूल्यांकन करें, घटनाओं को स्वीकार करें, और AI सहायक का उपयोग करें।
`admin`	हर असाइन करने योग्य अनुमति	ऑर्ग का पूर्ण नियंत्रण।

तीन अंतर्निहित सेट अपरिवर्तनीय हैं; उनके नाम हमेशा समान बात का मतलब रखते हैं, इसलिए read-only, standard, और admin नीति और ऑनबोर्डिंग में संदर्भित करना सुरक्षित है। एक ऑपरेटर आपके संगठन के लिए विशिष्ट भूमिकाओं को मॉडल करने के लिए अतिरिक्त कस्टम सेट बना सकता है (उदाहरण के लिए, एक “डैशबोर्ड लेखक” भूमिका या एक “कलेक्टर-केवल” भूमिका)। सेट डैशबोर्ड में सतह पर आते हैं और GET /permission-sets पर API के माध्यम से प्रबंधित होते हैं (सूची, users:read द्वारा द्वारपाल) और POST /permission-sets / PUT /permission-sets/:name / DELETE /permission-sets/:name (कस्टम सेट बनाएँ, संपादित करें, हटाएँ, settings:write द्वारा द्वारपाल)। अंतर्निहित सेट को हटाना या संपादित करना अस्वीकार कर दिया जाता है। सेट सदस्यता दो अन्य सुविधाओं को समर्थन देता है:

DEFAULT_USER_PERMISSIONS (जब एक व्यवस्थापक + नया उपयोगकर्ता खोलता है तो पूर्व-चयनित अनुदान) डिफ़ॉल्ट standard सेट के लिए।
--set फ़्लैग agenteye-orgctl पर (ऑपरेटर सदस्य प्रबंधन) एक सदस्य को एक नामित सेट से शुरू करता है, जिसे आप फिर --add / --remove के साथ ठीक-ट्यून करते हैं।

नोट: जब एक सेट एक अनुमति को शामिल करता है जो कुंजी-असाइन करने योग्य नहीं है (उदाहरण के लिए keys:update रखने वाला कस्टम सेट), उस सेट से एक कुंजी को बीजित करने से गैर-असाइन करने योग्य टोकन को छोड़ दिया जाता है; सर्वर अन्यथा HTTP 422 से कुंजी को अस्वीकार कर देगा। डैशबोर्ड उपयोगकर्ता उस प्रतिबंध के अधीन नहीं हैं।

बूटस्ट्रैप व्यवस्थापक कुंजी

व्यवस्थापक कुंजी एकल मूल क्रेडेंशियल है जो एक ऑपरेटर को कुछ भी नहीं से एक्सेस को लाया जा सकता है: इसके साथ आप हर अन्य स्कोप की गई कुंजी को टकसाली कर सकते हैं, पहले डैशबोर्ड उपयोगकर्ताओं को आमंत्रित कर सकते हैं, और किसी भी अन्य कुंजी अस्तित्व से पहले उदाहरण को कॉन्फ़िगर कर सकते हैं। यह एकमात्र कुंजी है जो आप कुंजी API के माध्यम से नहीं बनाते हैं; इसे पर्यावरण से प्रदान किया जाता है इसलिए सर्वर पहले बूट पर पहुँचने योग्य है। सर्वर पर ADMIN_KEY पर्यावरण चर सेट करें। हर स्टार्टअप पर सर्वर इस मान को एक व्यवस्थापक कुंजी के रूप में सभी अनुमतियों के साथ अपसर्ट करता है। घुमाने के लिए: ADMIN_KEY को एक नई गोपनीयता में बदलें और सर्वर को पुनः आरंभ करें।

संगठन स्कोपिंग

संगठन स्वयं ऑपरेटर द्वारा बैंड से बाहर बनाए और प्रबंधित किए जाते हैं, इस कुंजी API के माध्यम से नहीं। ऑर्ग और सदस्य जीवनचक्र (एक ऑर्ग बनाएँ / नाम दें / हटाएँ / शुद्ध करें; एक सदस्य जोड़ें / अपडेट करें / हटाएँ) agenteye-orgctl CLI के साथ किया जाता है; इसके लिए कोई HTTP API या डैशबोर्ड बटन नहीं है। क्या अपरिवर्तित है: प्रति-ऑर्ग API कुंजियाँ अभी भी डैशबोर्ड में टकसाली होती हैं (या इस कुंजी API के माध्यम से) ऑर्ग सदस्यों द्वारा। एक मल्टी-ऑर्ग परिनियोजन में, हर कुंजी एक ऑर्ग सदस्य बनाता है (इस कुंजी API या डैशबोर्ड कुंजियाँ पृष्ठ के माध्यम से) एक संगठन के अंतर्गत आता है और केवल कभी भी उस ऑर्ग के डेटा को पढ़ या लिख सकता है; ऑर्ग निर्माण पर कुंजी पर स्टैम्प किया जाता है और हर अनुरोध पर लागू किया जाता है। दो बूटस्ट्रैप कुंजियाँ एकमात्र अपवाद हैं: admin कुंजी (ADMIN_KEY से बीजित) और dashboard-assistant कुंजी (AGENT_API_KEY से बीजित) उदाहरण-स्कोप किए गए हैं (वे कोई ऑर्ग नहीं रखते हैं)। डैशबोर्ड admin कुंजी के साथ प्रमाणीकरण करता है इसलिए यह हस्ताक्षरित सदस्यों की ओर से प्रति-ऑर्ग अनुरोधों को प्रॉक्सी कर सकता है। एकल-किरायेदार परिनियोजन को इसके बारे में सोचना पड़ता है नहीं; सभी कुंजियाँ अंतर्निहित default ऑर्ग के अंतर्गत आती हैं।

कुंजियाँ बनाना

व्यवस्थापक कुंजी (या keys:create अनुमति रखने वाली किसी भी कुंजी) का उपयोग करके अतिरिक्त स्कोप की गई कुंजियाँ बनाएँ।

कलेक्टर कुंजी (केवल अंतर्ग्रहण)

curl -s -X POST http://your-server/keys \
  -H "Authorization: Bearer $ADMIN_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "prod-collector",
    "key": "your-collector-secret",
    "permissions": ["events:add"]
  }'

डैशबोर्ड कुंजी (केवल पढ़ें)

curl -s -X POST http://your-server/keys \
  -H "Authorization: Bearer $ADMIN_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "dashboard",
    "key": "your-dashboard-secret",
    "permissions": ["events:read", "keys:read"]
  }'

जब आप HTTP API पर एक कुंजी बनाते हैं, तो आप स्वयं key मान प्रदान करते हैं; एक मजबूत गोपनीयता चुनें और इसे सुरक्षित रूप से स्टोर करें। (डैशबोर्ड दूसरे तरीके से काम करता है: यह आपके लिए एक मजबूत गोपनीयता उत्पन्न करता है और निर्माण पर इसे एक बार दिखाता है; डैशबोर्ड में कुंजी प्रबंधन देखें।) प्रतिक्रिया की पुष्टि करती है कि कुंजी बनाई गई थी:

{
  "id": "550e8400-e29b-41d4-a716-446655440000",
  "name": "prod-collector",
  "permissions": ["events:add"],
  "created_at": "2026-04-01T12:00:00Z"
}

कुंजियों की सूची बनाना

curl -s http://your-server/keys \
  -H "Authorization: Bearer $ADMIN_KEY"

कुंजी गोपनीयताएँ सूची प्रतिक्रिया में नहीं लौटाई जाती हैं, केवल IDs, नाम, और अनुमतियाँ।

एक कुंजी को अक्षम करना

अक्षम करना कुंजी रिकॉर्ड को हटाए बिना तुरंत एक्सेस को रद्द करता है।

curl -s -X POST http://your-server/keys/<id>/disable \
  -H "Authorization: Bearer $ADMIN_KEY"

एक कुंजी को पुन: उत्पन्न करना

एक मौजूदा कुंजी के लिए एक नई गोपनीयता उत्पन्न करता है। पुरानी गोपनीयता तुरंत अमान्य कर दी जाती है।

curl -s -X POST http://your-server/keys/<id>/regenerate \
  -H "Authorization: Bearer $ADMIN_KEY"

प्रतिक्रिया में नई सादा पाठ गोपनीयता शामिल है, केवल एक बार दिखाई दी।

डैशबोर्ड में कुंजी प्रबंधन

डैशबोर्ड में कुंजियाँ पृष्ठ उपरोक्त सभी कार्यों के लिए एक UI प्रदान करता है। सूची को देखने के लिए आपको keys:read अनुमति के साथ एक कुंजी चाहिए, और क्रमशः निर्माण / संपादन / अक्षम / पुन: उत्पन्न कार्यों के लिए keys:create / keys:update / keys:disable / keys:regenerate। एक कुंजी की अनुमतियों को संपादित करना (keys:update) एक बनाने (keys:create) से अलग है, इसलिए आप एक ऑपरेटर को कुंजियों को टकसाली करने की क्षमता दे सकते हैं बिना मौजूदा कुंजियों को पुन: स्कोप करने की क्षमता के, या इसके विपरीत। व्यवस्थापक कुंजी इन सभी को कवर करती है। जब आप डैशबोर्ड से एक कुंजी बनाते हैं तो आप गोपनीयता की आपूर्ति नहीं करते हैं; डैशबोर्ड आपके लिए एक मजबूत गोपनीयता उत्पन्न करता है और इसे एक बार निर्माण पर प्रदर्शित करता है। इसे तुरंत कॉपी करें और सुरक्षित रूप से स्टोर करें; यह कभी फिर से दिखाया नहीं जाता है, एक पुन: उत्पन्न के समान ही। आप अभी भी कुंजी की अनुमतियों को सीधे चुन सकते हैं, या एक अनुमति सेट से उन्हें बीजित कर सकते हैं (नीचे देखें)।

API कुंजियाँ पृष्ठ: प्रत्येक कुंजी के लिए एक कार्ड इसके नाम, दी गई अनुमतियों, और निर्माण समय के साथ, पुन: उत्पन्न और अक्षम कार्य; admin जैसी संरक्षित कुंजियाँ चिह्नित हैं

अनुशंसित कुंजी लेआउट

कुंजी	अनुमतियाँ	का उपयोग कौन करता है
`admin` (`ADMIN_KEY` env var के माध्यम से बूटस्ट्रैप)	सभी	Ops/सेटअप, और डैशबोर्ड (`ADMIN_KEY` के साथ प्रमाणीकरण, अनुमति जांच के साथ उपयोगकर्ता अनुरोधों को प्रॉक्सी)
प्रति-होस्ट कलेक्टर कुंजी	`events:add`	प्रत्येक एजेंट मशीन पर कलेक्टर
`dashboard-assistant` (`AGENT_API_KEY` env var के माध्यम से बूटस्ट्रैप)	`events:read`, `evaluations:read`, `dashboards:read`, `dashboards:write`, `queries:read`, `queries:write`, `queries:run`	AI सहायक, स्वचालित रूप से बीजित, संरक्षित; API के माध्यम से संपादित नहीं किया जा सकता
सहायक टेलीमेट्री कुंजी (वैकल्पिक)	`events:add`	AI सहायक आत्म-प्रवृत्तिकरण, यदि सक्षम है

नोट: सहायक की कुंजी स्वचालित रूप से बीजित की जाती है सर्वर द्वारा AGENT_API_KEY env var से (वही गोपनीयता जो एजेंट AGENTEYE_API_KEY के रूप में प्रस्तुत करता है); कोई मैन्युअल कुंजी-मिंटिंग चरण नहीं है और कोई व्यवस्थापक कुंजी शामिल नहीं है। इसकी अनुमतियाँ स्रोत कोड में तय की जाती हैं इसलिए स्कोप को गलतफहमी से व्यापक नहीं किया जा सकता: ईवेंट / मूल्यांकन / डैशबोर्ड में पढ़ें, प्लस डैशबोर्ड-लेखन और क्वेरीज-पढ़ें / लिखें / चलाएँ AI से क्वेरी लिखने के लिए कहने के लिए। सभी SQL अभी भी उसी केवल-पढ़ने वाली भूमिका और संरक्षित SQL पथ के माध्यम से जाता है एक उपयोगकर्ता-लिखी गई क्वेरी के रूप में, इसलिए यह लेखन सतह को व्यापक करता है, डेटा सतह नहीं; विनाशकारी कार्य (queries:delete, dashboards:delete) जानबूझकर सहायक कुंजी से दूर रहते हैं। admin कुंजी की तरह, यह संरक्षित है: इसे कुंजी API के माध्यम से अक्षम या पुन: उत्पन्न नहीं किया जा सकता, केवल AGENT_API_KEY को बदलकर और पुनः आरंभ करके घुमाया जा सकता है। डैशबोर्ड उपयोगकर्ता अतिरिक्त रूप से सहायक को देखने और उपयोग करने के लिए agent:use अनुमति की आवश्यकता होती है। यदि आप आत्म-प्रवृत्तिकरण सक्षम करते हैं, तो सहायक को एक अलग events:add-केवल कुंजी दें।

अपग्रेड और बैकवर्ड-संगतता नोट्स

आपको इन्हीं की आवश्यकता है यदि आप एक मौजूदा उदाहरण को अपग्रेड कर रहे हैं; नई परिनियोजन इन्हें छोड़ सकती है।

जब ऑडिट आया, मौजूदा अनुदानकर्ताओं को अलर्ट के समान भूमिका आकार के साथ व्यापक किया गया: हर उपयोगकर्ता और alerts:read रखने वाली अनुमति सेट audits:read प्राप्त की, और alerts:write के हर धारक को audits:write मिला। मौजूदा API कुंजियों को नहीं व्यापक किया गया। यदि इसे ऑडिट सतह चाहिए तो एक कुंजी को स्पष्ट रूप से audits:* दें।

विरासत alerts:ack टोकन के भंडारीकृत अनुदान incidents:ack के रूप में पार्स किए जाते हैं इसलिए ऑन-कॉलर पुनः कीइंग के बिना एक्सेस को बनाए रखते हैं। टोकन अब डैशबोर्ड के उपयोगकर्ता संपादक से असाइन करने योग्य नहीं है; मैट्रिक्स incidents:ack की पेशकश करता है।

अगले कदम

Python SDK: कैसे आपका एजेंट कोड प्रमाणीकृत होता है जब ईवेंट भेज रहा हो।
सुरक्षा: साइन-इन, एक्सेस नियंत्रण, और प्रति-संगठन डेटा अलगाव कैसे काम करता है।

Overview

Features

SDK and CLI

Administration

API कुंजियाँ

3 कुंजियाँ जो अधिकांश परिनियोजन को चाहिए

अनुमतियाँ

ईवेंट अंतर्ग्रहण और क्वेरी

सत्र और मूल्यांकन

डैशबोर्ड

सहेजी गई क्वेरीज़ (SQL संगीतकार)

AI सहायक

API कुंजियाँ

डैशबोर्ड उपयोगकर्ता

परिचालन सेटिंग्स

अलर्ट और घटनाएँ

ऑडिट

अनुमति सेट

बूटस्ट्रैप व्यवस्थापक कुंजी

संगठन स्कोपिंग

कुंजियाँ बनाना

कलेक्टर कुंजी (केवल अंतर्ग्रहण)

डैशबोर्ड कुंजी (केवल पढ़ें)

कुंजियों की सूची बनाना

एक कुंजी को अक्षम करना

एक कुंजी को पुन: उत्पन्न करना

डैशबोर्ड में कुंजी प्रबंधन

अनुशंसित कुंजी लेआउट

अपग्रेड और बैकवर्ड-संगतता नोट्स

अगले कदम

​3 कुंजियाँ जो अधिकांश परिनियोजन को चाहिए

​अनुमतियाँ

​ईवेंट अंतर्ग्रहण और क्वेरी

​सत्र और मूल्यांकन

​डैशबोर्ड

​सहेजी गई क्वेरीज़ (SQL संगीतकार)

​AI सहायक

​API कुंजियाँ

​डैशबोर्ड उपयोगकर्ता

​परिचालन सेटिंग्स

​अलर्ट और घटनाएँ

​ऑडिट

​अनुमति सेट

​बूटस्ट्रैप व्यवस्थापक कुंजी

​संगठन स्कोपिंग

​कुंजियाँ बनाना

​कलेक्टर कुंजी (केवल अंतर्ग्रहण)

​डैशबोर्ड कुंजी (केवल पढ़ें)

​कुंजियों की सूची बनाना

​एक कुंजी को अक्षम करना

​एक कुंजी को पुन: उत्पन्न करना

​डैशबोर्ड में कुंजी प्रबंधन

​अनुशंसित कुंजी लेआउट

​अपग्रेड और बैकवर्ड-संगतता नोट्स

​अगले कदम

3 कुंजियाँ जो अधिकांश परिनियोजन को चाहिए

अनुमतियाँ

ईवेंट अंतर्ग्रहण और क्वेरी

सत्र और मूल्यांकन

डैशबोर्ड

सहेजी गई क्वेरीज़ (SQL संगीतकार)

AI सहायक

API कुंजियाँ

डैशबोर्ड उपयोगकर्ता

परिचालन सेटिंग्स

अलर्ट और घटनाएँ

ऑडिट

अनुमति सेट

बूटस्ट्रैप व्यवस्थापक कुंजी

संगठन स्कोपिंग

कुंजियाँ बनाना

कलेक्टर कुंजी (केवल अंतर्ग्रहण)

डैशबोर्ड कुंजी (केवल पढ़ें)

कुंजियों की सूची बनाना

एक कुंजी को अक्षम करना

एक कुंजी को पुन: उत्पन्न करना

डैशबोर्ड में कुंजी प्रबंधन

अनुशंसित कुंजी लेआउट

अपग्रेड और बैकवर्ड-संगतता नोट्स

अगले कदम