API कुंजियाँ

AgentEye सर्वर तक पहुँच को नियंत्रित करने के लिए बारीक-दानेदार API कुंजियों का उपयोग करता है। प्रत्येक कुंजी एक या अधिक अनुमतियों के साथ आती है जो यह निर्धारित करती है कि यह क्या कर सकती है।

अनुमतियाँ

सर्वर अनुमतियों का एक निश्चित कैटलॉग लागू करता है; प्रत्येक विशेष 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/models` या तो `events:read` या `evaluations:read` के साथ पहुंचने योग्य हैं, इसलिए सत्र पृष्ठ (गेटेड `evaluations:read`) समान प्रति-org पहलू का पुनः उपयोग करता है।

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

अनुमति	HTTP मार्ग	यह क्या अनुमति देता है
`evaluations:read`	`GET /sessions`, `GET /evaluations`, `GET /evaluations/aggregate`, `GET /evaluations/environments`, `GET /evaluation-jobs`	सत्रों को सूचीबद्ध करें, मूल्यांकन परिणामों को पढ़ें, डैशबोर्ड द्वारा उपयोग की जाने वाली रोल-अप eval स्वास्थ्य, और मूल्यांकन-कार्य कार्यकर्ता कतार स्थिति।
`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`	सहेजी गई क्वेरीज़ को सूचीबद्ध करें, एक को लोड करें, और संगीतकार को लक्ष्य करने वाली केवल-पढ़ने के लिए ClickHouse स्कीमा का निरीक्षण करें।
`queries:write`	`POST /queries`, `PUT /queries/:id`	सहेजी गई क्वेरीज़ बनाएं और संपादित करें। SQL को अभी भी `queries:run` कॉल के रूप में एक ही केवल-पढ़ने के लिए भूमिका और `sql_guard` जाँचों के माध्यम से भेजा जाता है।
`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`	ऑडिट्स बनाएं, संपादित करें, हटाएं, और चलाएं; निष्कर्षों को ट्रिएज करें (स्वीकार करें / शांत करें / खारिज करें / हल करें / फिर से खोलें / असाइन करें)।

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

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

प्राप्तकर्ता-पिकर समापन बिंदु 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 (सूची, users:read द्वारा गेटेड) और POST /permission-sets / PUT /permission-sets/:name / DELETE /permission-sets/:name (एक कस्टम सेट बनाएं, संपादित करें, हटाएं, settings:write द्वारा गेटेड) पर API के माध्यम से प्रबंधित होते हैं। एक बिल्ट-इन सेट को हटाना या संपादित करना अस्वीकार कर दिया जाता है। सेट सदस्यता दो अन्य विशेषताओं को समर्थन देती है:

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

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

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

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

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

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

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

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

कलेक्टर कुंजी (केवल इंजेस्ट)

curl -s -X POST http://your-server:8080/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:8080/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:8080/keys \
  -H "Authorization: Bearer $ADMIN_KEY"

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

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

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

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

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

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

curl -s -X POST http://your-server:8080/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 के रूप में प्रस्तुत करता है); कोई मैनुअल कुंजी-टकसाली कदम नहीं है और कोई व्यवस्थापक कुंजी शामिल नहीं है। इसकी अनुमतियाँ स्रोत कोड में निर्धारित हैं ताकि स्कोप को गलत विन्यास द्वारा चौड़ा न किया जा सके: ईवेंट्स / मूल्यांकन / डैशबोर्ड में पढ़ें, साथ ही dashboards-write और queries-read / write / run क्वेरी लेखन प्रवाह के लिए। सभी SQL अभी भी एक उपयोगकर्ता-लिखित क्वेरी के समान केवल-पढ़ने के लिए भूमिका और sql_guard जाँचों के माध्यम से जाता है, इसलिए यह लेखन सतह को चौड़ा करता है, डेटा सतह को नहीं; विनाशकारी कार्यों (queries:delete, dashboards:delete) जानबूझकर सहायक कुंजी से दूर रहते हैं। admin कुंजी की तरह, यह संरक्षित है: इसे कुंजी API के माध्यम से अक्षम या पुनः उत्पन्न नहीं किया जा सकता है, केवल AGENT_API_KEY को बदलकर और पुनः आरंभ करके घुमाया जा सकता है। डैशबोर्ड उपयोगकर्ताओं को अतिरिक्त रूप से सहायक को देखने और उपयोग करने के लिए agent:use अनुमति की आवश्यकता है। यदि आप स्व-उपकरण सक्षम करते हैं, तो सहायक को एक अलग events:add-केवल कुंजी दें।

​अनुमतियाँ

​ईवेंट्स इंजेस्ट और क्वेरी

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

​डैशबोर्ड

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

​AI सहायक

​API कुंजियाँ

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

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

​अलर्ट्स और घटनाएं

​ऑडिट्स

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

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

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

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

​कलेक्टर कुंजी (केवल इंजेस्ट)

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

​कुंजियों को सूचीबद्ध करना

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

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

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

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

अनुमतियाँ

ईवेंट्स इंजेस्ट और क्वेरी

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

डैशबोर्ड

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

AI सहायक

API कुंजियाँ

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

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

अलर्ट्स और घटनाएं

ऑडिट्स

अनुमति सेट्स

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

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

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

कलेक्टर कुंजी (केवल इंजेस्ट)

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

कुंजियों को सूचीबद्ध करना

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

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

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

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