SigNoz ਦੇ Managed Cloud Platform (MCP) 'ਤੇ ਚੱਲ ਰਹੇ ਦੋ ਆਟੋਨੋਮਸ (autonomous) AI SRE agents ਮੂਲ-ਕਾਰਨ (root-cause) ਦੀ ਪਛਾਣ ਕਰਦੇ ਹਨ, Slack 'ਤੇ ਇੱਕ ਸਾਰ (summary) ਪੋਸਟ ਕਰਦੇ ਹਨ, ਅਤੇ ਪੂਰੀ ਜਾਂਚ 4 ਸੈਕਿੰਡ ਤੋਂ ਵੀ ਘੱਟ ਸਮੇਂ ਵਿੱਚ ਪੂਰੀ ਕਰ ਲੈਂਦੇ ਹਨ, ਜਿਸਦੀ ਲਾਗਤ ਪ੍ਰਤੀ ਘਟਨਾ ਸਿਰਫ਼ $0.0013 ਆਉਂਦੀ ਹੈ। ਇਸਦਾ ਨਤੀਜਾ ਰਿਐਕਟਿਵ (reactive) ਚੈਟਬੋਟ ਕੁਐਰੀਆਂ ਤੋਂ ਇੱਕ ਸੈਲਫ-ਡਰਾਈਵਿੰਗ (self-driving) ਅਬਜ਼ਰਵੇਬਿਲਟੀ (observability) ਵਰਕਫੋਰਸ ਵੱਲ ਤਬਦੀਲੀ ਹੈ, ਜੋ ਫਾਲਤੂ ਮੈਟ੍ਰਿਕਸ (metrics) ਨੂੰ ਸਾਹਮਣੇ ਲਿਆਉਂਦੇ ਹੋਏ ਜਾਂਚ ਦੇ ਖਰਚੇ ਨੂੰ ਬਹੁਤ ਘਟਾ ਦਿੰਦੀ ਹੈ।
ਇਹ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ
ਰਵਾਇਤੀ AI-observability ਡੈਮੋਜ਼ ਵਿੱਚ ਅਜੇ ਵੀ ਟ੍ਰੇਸ (traces) ਜਾਂ ਲੌਗਸ (logs) ਬਾਰੇ ਸਵਾਲ ਟਾਈਪ ਕਰਨ ਲਈ ਇੱਕ ਇਨਸਾਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਨਵਾਂ ਤਰੀਕਾ ਇਸ ਕਦਮ ਨੂੰ ਖਤਮ ਕਰ ਦਿੰਦਾ ਹੈ: ਜਦੋਂ ਕੋਈ ਅਲਰਟ (alert) ਆਉਂਦਾ ਹੈ, ਤਾਂ ਸਿਸਟਮ ਆਪਣੇ ਆਪ ਇੱਕ ਪ੍ਰਮਾਣਿਤ SRE ਪਲੇਅਬੁੱਕ (playbook) ਚਲਾਉਂਦਾ ਹੈ ਅਤੇ ਜਵਾਬ ਦੇ ਦਿੰਦਾ ਹੈ।
ਉਹ ਹੈਕਾਥਨ ਜਿਸ ਨੇ ਇਹ agents ਪੈਦਾ ਕੀਤੇ
ਇਹ agents WeMakeDevs × Agents of SigNoz ਹੈਕਾਥਨ ਤੋਂ MIB (Men in Backend) ਪ੍ਰੋਜੈਕਟ ਦੇ ਨਾਮ ਹੇਠ ਉਭਰੇ ਹਨ। ਇੱਕ ਗੱਲਬਾਤ ਕਰਨ ਵਾਲੇ ਚੈਟਬੋਟ ਦੀ ਬਜਾਏ, ਟੀਮ ਨੇ ਦੋ agents ਦੀ ਇੱਕ “autonomous observability workforce” ਬਣਾਈ:
- Agent J – The Incident Responder – ਅਲਰਟਸ 'ਤੇ ਨਜ਼ਰ ਰੱਖਦਾ ਹੈ, ਫਿਰ ਪੰਜ-ਪੜਾਵੀ ਪਲੇਅਬੁੱਕ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ: ਅਲਰਟ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨਾ, ਦੋਸ਼ੀ ਟ੍ਰੇਸ (offending traces) ਲੱਭਣਾ, ਸਬੰਧਤ ਲੌਗਸ ਦੀ ਡੂੰਘਾਈ ਨਾਲ ਜਾਂਚ ਕਰਨਾ, ਡੈਲਟਾ (delta) ਦੀ ਗਣਨਾ ਕਰਨਾ, ਅਤੇ Slack 'ਤੇ root-cause ਕਾਰਡ ਪੋਸਟ ਕਰਨਾ। ਇਹ ਪ੍ਰਕਿਰਿਆ ਔਸਤਨ 3.7 ਸੈਕਿੰਡ ਲੈਂਦੀ ਹੈ।
- Agent K – The Auditor – ਮੈਟ੍ਰਿਕ ਵਰਤੋਂ ਦੇ ਨਿਰਧਾਰਤ ਆਡਿਟ (audits) ਚਲਾਉਂਦਾ ਹੈ, ਉਹਨਾਂ ਮੈਟ੍ਰਿਕਸ ਨੂੰ ਫਲੈਗ ਕਰਦਾ ਹੈ ਜੋ ਖਰਚਾ ਤਾਂ ਕਰਦੇ ਹਨ ਪਰਨਾਂ ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਹੁੰਦੀ, ਅਤੇ ਇਨਸਾਨ ਦੀ ਮਨਜ਼ੂਰੀ ਲਈ ਡੈਸ਼ਬੋਰਡ ਤਬਦੀਲੀਆਂ ਦਾ ਖਰੜਾ ਤਿਆਰ ਕਰਦਾ ਹੈ।
ਹੈਕਾਥਨ ਦੌਰਾਨ, Agent K ਨੇ ਦੱਸਿਆ ਕਿ ਸਭ ਤੋਂ ਉੱਪਰਲੇ 38% ਮੈਟ੍ਰਿਕਸ ਕਦੇ ਪੜ੍ਹੇ ਹੀ ਨਹੀਂ ਗਏ ਸਨ, ਜਿਸ ਨਾਲ observability stack ਵਿੱਚ ਲੁਕੀ ਹੋਈ ਬਰਬਾਦੀ ਦਾ ਪਤਾ ਲੱਗਿਆ।
ਸਿਸਟਮ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ
ਡਿਟਰਮਨਿਸਟਿਕ (Deterministic) ਪਲੇਅਬੁੱਕਸ, ਨਾ ਕਿ ਖੁੱਲ੍ਹੇ-ਅੰਨ੍ਹੇ ਲੂਪਸ
Agents ਖੁੱਲ੍ਹੇ-ਅੰਨ੍ਹੇ “agentic” ਤਰਕ ਦੀ ਬਜਾਏ ਨਿਸ਼ਚਿਤ, ਡਿਟਰਮਨਿਸਟਿਕ ਪਲੇਅਬੁੱਕਸ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਨ। ਹਰ ਰਨ ਇੱਕ ਜਾਣੇ-ਪਛਾਣੇ SRE ਵਰਕਫਲੋ—confirm, trace, log, delta—ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ, ਜੋ ਇੱਕ ਨਿਰੰਤਰ ਆਉਟਪੁੱਟ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ ਅਤੇ ਅਨਿਸ਼ਚਿਤ LLM ਟੈਕਸਟ ਤੋਂ ਬਚਦਾ ਹੈ।
ਅਬਜ਼ਰਵੇਬਿਲਟੀ ਦੀਆਂ ਤਿੰਨ ਪਰਤਾਂ
- Application layer – ਮਾਨੀਟਰਡ ਐਪ ਟ੍ਰੇਸ, ਲੌਗਸ ਅਤੇ ਮੈਟ੍ਰਿਕਸ ਨੂੰ SigNoz 'ਤੇ ਸਟ੍ਰੀਮ ਕਰਦੀ ਹੈ।
- Agent layer – ਹਰ agent ਆਪਣੇ GenAI-ਜਨਰੇਟਡ ਸੈਮੈਂਟਿਕ ਸਪੈਨਸ (semantic spans) ਵਾਪਸ SigNoz ਨੂੰ ਭੇਜਦਾ ਹੈ, ਜਿਸ ਨਾਲ agents ਖੁਦ ਵੀ ਅਬਜ਼ਰਵੇਬਲ (observable) ਬਣ ਜਾਂਦੇ ਹਨ।
- MCP telemetry layer – MCP ਸਰਵਰ ਟੂਲ-ਕਾਲ ਟੈਲੀਮੈਟਰੀ (tool-call telemetry) ਨੂੰ ਰਿਕਾਰਡ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਇੱਕ ਫੀਡਬੈਕ ਲੂਪ ਪੂਰਾ ਹੁੰਦਾ ਹੈ ਜਿੱਥੇ SigNoz ਉਹਨਾਂ agents 'ਤੇ ਨਜ਼ਰ ਰੱਖਦਾ ਹੈ ਜੋ SigNoz 'ਤੇ ਨਜ਼ਰ ਰੱਖਦੇ ਹਨ।
ਪ੍ਰੀ-ਅਲਰਟ ਇਨਸਾਈਟ ਲਈ ਪ੍ਰੈਡਿਕਟਿਵ ਇੰਜਣ
ਇੱਕ ਬੈਕਗ੍ਰਾਊਂਡ ਪ੍ਰਕਿਰਿਆ ਹਰ 25 ਸੈਕਿੰਡ ਵਿੱਚ ਟ੍ਰੈਂਡਸ (trends) ਦਾ ਸਕੋਰ ਕਰਦੀ ਹੈ। ਜਦੋਂ ਲੇਟੈਂਸੀ (latency) ਜਾਂ ਗਲਤੀਆਂ ਦੀ ਦਰ (error rates) ਵਧਦੀ ਹੈ, ਤਾਂ ਇੰਜਣ ਅਲਰਟ ਥ੍ਰੈਸ਼ਹੋਲਡ (alert threshold) ਤੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਘਟਨਾ ਦੀ ਭਵਿੱਖਬਾਣੀ ਕਰ ਦਿੰਦਾ ਹੈ, ਜਿਸ ਨਾਲ agents ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਜਾਣਕਾਰੀ ਮਿਲ ਜਾਂਦੀ ਹੈ।
ਮਹੱਤਵਪੂਰਨ ਨਤੀਜੇ
| ਮੈਟ੍ਰਿਕ (Metric) | ਨਤੀਜਾ |
|---|---|
| ਪ੍ਰਤੀ ਰਨ ਜਾਂਚ ਦੀ ਲਾਗਤ | $0.0013 |
| ਪੂਰੇ root-cause ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ ਸਮਾਂ | < 4 ਸੈਕਿੰਡ |
| ਪਛਾਣੇ ਗਏ ਅਣਵਰਤੇ ਉੱਪਰਲੇ ਮੈਟ੍ਰਿਕਸ | 38 % |
ਮੈਦਾਨ ਵਿੱਚ ਸਿੱਖੇ ਗਏ ਸਬਕ
- GenAI spans ਲਈ ਮੈਨੂਅਲ ਇੰਸਟ੍ਰੂਮੈਂਟੇਸ਼ਨ – AI ਦੇ ਸੈਮੈਂਟਿਕ ਆਉਟਪੁੱਟ ਨੂੰ ਕੈਪਚਰ ਕਰਨ ਲਈ ਸਪਸ਼ਟ ਇੰਸਟ੍ਰੂਮੈਂਟੇਸ਼ਨ ਜੋੜਨਾ ਡੇਟਾ ਨੂੰ ਸਹੀ ਅਤੇ ਸਰਚ ਕਰਨ ਯੋਗ ਰੱਖਦਾ ਹੈ।
- “Thinking” ਮੋਡਸ ਨੂੰ ਬੰਦ ਕਰੋ – ਉਹ LLMs ਜੋ ਗੱਲਬਾਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਨ, ਅਕਸਰ JSON ਨੂੰ ਅਧੂਰਾ (truncate) ਕਰ ਦਿੰਦੇ ਹਨ। ਉਹਨਾਂ ਮੋਡਸ ਨੂੰ ਡਿਸੇਬਲ ਕਰਨ ਨਾਲ ਸੰਖੇਪ ਅਤੇ ਮਸ਼ੀਨ-ਪੜ੍ਹਨਯੋਗ ਆਉਟਪੁੱਟ ਮਿਲਦੀ ਹੈ।
- RFC 6902 ਨਾਲ ਪੈਚ ਲਗਾਓ – Foundry ਪਲੇਟਫਾਰਮ 'ਤੇ JSON-Patch (RFC 6902) ਲਾਗੂ ਕਰਨ ਨਾਲ ਟੀਮ ਨੂੰ ਪੂਰੀ ਸਰਵਿਸ ਨੂੰ ਮੁੜ-ਤਿਆਰ (redeploy) ਕੀਤੇ ਬਿਨਾਂ ਕੰਟੇਨਰ ਹੈਲਥ-ਚੈੱਕ ਅਤੇ ਲੇਟੈਂਸੀ ਪੈਰਾਮੀਟਰਾਂ ਨੂੰ ਠੀਕ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਮਿਲੀ।
ਕਿਸ ਨੂੰ ਫਾਇਦਾ ਹੋਵੇਗਾ, ਅਤੇ ਕੌਣ ਸ਼ੱਕੀ ਹੋ ਸਕਦਾ ਹੈ
ਉਹ ਉਦਯੋਗ (Enterprises) ਜੋ ਪਹਿਲਾਂ ਹੀ observability ਪਲੇਟਫਾਰਮਾਂ ਲਈ ਭੁਗਤਾਨ ਕਰਦੇ ਹਨ, ਉਹ ਤੁਰੰਤ ਬਚਤ ਦੇਖ ਸਕਦੇ ਹਨ: ਵਿਸ਼ਲੇਸ਼ਕਾਂ (analysts) ਦੇ ਸਮੇਂ ਵਿੱਚ ਕਮੀ ਅਤੇ ਫਾਲਤੂ ਮੈਟ੍ਰਿਕ ਇਕੱਠਾ ਕਰਨ ਦੀ ਸਮੱਸਿਆ ਦਾ ਖਾਤਮਾ।
ਅੱਗੇ ਕੀ ਦੇਖਣਾ ਹੈ
MIB ਲਈ ਓਪਨ-ਸੋਰਸ ਕੋਡ GitHub 'ਤੇ ਉਪਲਬਧ ਹੈ, ਅਤੇ ਇੱਕ ਡੈਮੋ ਵੀਡੀਓ ਪੂਰੀ ਘਟਨਾ ਦੇ ਰਨ (incident run) ਬਾਰੇ ਦੱਸਦੀ ਹੈ।
ਸਿੱਟਾ
SigNoz ਦੇ MCP ਵਿੱਚ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਦੋ ਵਿਸ਼ੇਸ਼ AI agents ਨੂੰ ਸ਼ਾਮਲ ਕਰਨਾ ਇਹ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਆਟੋਨੋਮਸ root-cause ਵਿਸ਼ਲੇਸ਼ਣ ਬਹੁਤ ਤੇਜ਼ ਅਤੇ ਬਹੁਤ ਸਸਤਾ ਹੋ ਸਕਦਾ ਹੈ। ਇਹ ਤਰੀਕਾ observability ਨੂੰ ਇੱਕ ਪੈਸਿਵ (passive) ਰਿਪੋਰਟਿੰਗ ਟੂਲ ਤੋਂ ਇੱਕ ਸਰਗਰਮ ਭਾਗੀਦਾਰ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ ਜੋ ਘਟਨਾ ਵਾਪਰਦੇ ਹੀ ਕਾਰਵਾਈ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਸਮਾਂ, ਪੈਸਾ ਅਤੇ ਘਟਨਾ ਤੋਂ ਬਾਅਦ ਲੌਗਸ ਦੀ ਜਾਂਚ ਕਰਨ ਦੀ ਮਨੁੱਖੀ ਨਿਰਾਸ਼ਾ ਤੋਂ ਬਚਾਅ ਹੁੰਦਾ ਹੈ।