აგენტის დაკვირვებადობა: რა უნდა დალოგოთ, ტრასიროთ და შეინახოთ production-ში

ყოველი production AI აგენტის გაშვებისთვის დაალოგეთ სტრუქტურირებული events: request id, tool name, args (redacted), results status, approvals, model ids, latency და cost. ნედლი prompt-ები და სრული completion-ები შეინახეთ მხოლოდ ცალსახა retention rules-ის ქვეშ. თუ ამ events-ით ინციდენტის აღდგენა არ შეგიძლიათ, თქვენ არ აკმაყოფილებთ production AI აგენტის არქიტექტურის ზღვარს.

ეს გვერდი არის production logging-ის პოლიტიკა და არა პლატფორმების შესყიდვის სია. გამოიყენეთ ის LangSmith-ის, Phoenix-ის, Datadog-ის ან plain OpenTelemetry-ის მიერთებამდე, რომ events არსებობდეს sink-ის შეცვლის შემთხვევაშიც.

რა არის აგენტის დაკვირვებადობა (და რა არ არის)

AI აგენტის დაკვირვებადობა არის end-to-end აგენტის ქცევის მონიტორინგის პრაქტიკა, LLM გამოძახებებისა და tool ურთიერთქმედებების ჩათვლით, რათა ახსნათ, რა გააკეთა აგენტმა და რატომ ჩავარდა ან drift-ში წავიდა run. ეს განმარტება ემთხვევა იმას, როგორ ჩარჩოავენ თემას ინდუსტრიული მასალები: end-to-end agentic journeys და არა მხოლოდ კლასიკური infra მეტრიკები (IBM on AI agent observability).

ეს უფრო ფართოა, ვიდრე კლასიკური APM. APM გეუბნებათ, რომ სერვისი იყო up, request იყო ნელი, ან dependency timeout-ზე გავიდა. აგენტის გაშვებები კიდევ იტოტება, იციკლება, იძახებს tools-ს და ცვლის რეალურ სისტემებს.

ეს უფრო ფართოა, ვიდრე მხოლოდ LLM დაკვირვებადობა. LLM observability ფოკუსირებულია ერთ model call-ზე: prompt, completion, tokens, latency, cost. აგენტის დაკვირვებადობა ფარავს control loop-ს ამ გამოძახებების გარშემო: plan, tool I/O, gate გადაწყვეტილებები, retries და საბოლოო side effects (ClickHouse on agent vs LLM observability).

სემანტიკური ჩავარდნა არის failure mode, რომელსაც ოპერატორები გამოტოვებენ HTTP-only dashboard-ებით. ჰიპოთეტური მაგალითი: order-status აგენტი აბრუნებს HTTP 200-ს, ყოველი tool აცხადებს ok-ს, და კლიენტი მაინც იღებს არასწორ refund თანხას, რადგან downstream-ში არასწორი order id გადავიდა. პროტოკოლური წარმატება დამალა business failure. გჭირდებათ journey + tool I/O + decisions + side effects და არა მხოლოდ model tokens.

დასკვნა: თუ ტელემეტრია მთავრდება ფრაზაზე „მოდელი გამოიძახეს, 200 OK“, თქვენ აგენტს არ აკვირდებით.

მინიმალური სიცოცხლისუნარიანი ტრასა

Production run უნდა ეყრდნობოდეს ერთ correlation identity-ს ყოველ ნაბიჯზე.

ტრასის მინიმალური შიგთავსი:

1. Correlation / run identity - request_id და run_id, საერთო ყოველი span-ის ან event-ისთვის.
2. Trigger - ვინ ან რამ დაიწყო run (user, webhook, cron, სხვა სისტემა) და business intent, როცა ცნობილია.
3. Tools attempted - სახელი, redacted args, status, latency და error class ჩავარდნისას.
4. Gate decisions - approve, deny, escalate ან auto-allow, იმით, ვინც გადაწყვიტა.
5. Final side effects - რა რეალურად შეიცვალა (ticket updated, email sent, row written) ან ცალსახა „no mutation“ შედეგი.

ოფციონალური multi-step ფორმა ერთი request-ისთვის:

run (correlation id)
├── plan / model step
├── execute_tool (lookup)
├── gate (human or policy)
├── execute_tool (mutation)
└── final response + side_effect_summary

ხეში ყველა span იზიარებს ერთსა და იმავე request_id / run_id-ს.

OpenTelemetry GenAI walkthrough-ებში ხშირად ჩანს მსგავსი ხე: root agent invoke child chat და tool span-ებით (OTel GenAI observability). ამ ფორმის განხორციელება პირველ რიგში structured logs-ით შეგიძლიათ. Tracer-ის ბრენდი მეორეხარისხოვანია.

ჰიპოთეტური მაგალითი (არაღდგენადი): support აესკალირებს ცუდ refund-ს. ლოგებში ჩანს „tool succeeded“ და model id, მაგრამ არ არის run_id, არ არის tool args და არ არის gate record. ვერ დაამტკიცებთ, რა იყო approved და რა ჩაიწერა. ასეთი run ვერ გადის აღდგენადობის ზღვარს, მაშინაც კი, თუ uptime ნორმალურად გამოიყურებოდა.

დასკვნა: correlation + trigger + tools + gates + side effects არის run-ის მინიმალური ისტორია.

მინიმალური event schema

ჯერ გაუშვით პატარა, სტაბილური ველების ნაკრები, შემდეგ დაედევნეთ dashboard-ებს.

მინიმალური structured fields, რომლებიც უნდა გაიგზავნოს ყოველი production agent run-ისთვის.

მხოლოდ ილუსტრაციული schema (არ არის client log):

{
  "request_id": "req_01J...",
  "run_id": "run_01J...",
  "agent_id": "support-refund-v3",
  "tool_name": "lookup_order",
  "args_redacted": { "order_id": "ORD-4417" },
  "result_status": "ok",
  "approval_id": null,
  "human_override": false,
  "model_id": "example-model",
  "latency_ms": 312,
  "cost_units": 0.002,
  "side_effect_summary": "none"
}

ადამიანის approvals და overrides არის სრულფასოვანი events და არა სქოლიოები. IBM-სტილის event სიები human handoff-ს განიხილავს სიგნალად, რომელიც უნდა დაიჭიროთ failed tool calls-თან და LLM calls-თან ერთად (IBM event types). Gate დიზაინის კონტექსტისთვის იხილეთ human-in-the-loop AI აგენტები ახსნილია. Tool საზღვრების დისციპლინისთვის იხილეთ უსაფრთხო tool calling ბიზნეს აგენტებისთვის.

დასკვნა: განსაზღვრეთ schema ერთხელ; შემდეგ მიუსადაგეთ ნებისმიერ sink-ს, რომელსაც გამოიყენებთ.

Redaction და third-party გაგზავნა

ამოიღეთ secrets, API tokens, session cookies, ბარათის სრული ნომრები (PAN) და ზედმეტი PII მანამ, სანამ ლოგები დატოვებენ თქვენს control plane-ს. ეს ეხება SaaS observability პროდუქტებს, vendor agent tracers-ს, shared Slack dumps-ს და ticket attachments-ს.

ცალსახად გადაწყვიტეთ, რა შეიძლება გავიდეს VPC-ის ან account-ის საზღვარზე:

OpenTelemetry GenAI პრაქტიკა ნაგულისხმევად თიშავს content capture-ს prompts-ის, completions-ის და tool bodies-ისთვის, რადგან ეს content მგრძნობიარეა; full capture არის opt-in (OTel content capture default). გაასწორეთ product settings ამ პოზასთან, მაშინაც კი, თუ ჯერ OTel-ზე არ ხართ.

დაკავშირებული privacy მასალა ამ საიტზე: PII და GDPR logging AI აგენტებისთვის.

დასკვნა: third-party sinks პირველ რიგში იღებენ metadata-ს და redacted structure-ს და არა სრულ conversation dumps-ს.

Retention მატრიცა

მეტი logging ეხმარება debug-ს და შეიძლება გაზარდოს შესაბამისობის (compliance) ტვირთი. განსაზღვრეთ retention ცალსახად მონაცემთა კლასის მიხედვით და არა „შეინახე ყველაფერი forever“ ან „დაასემპლე ყველაფერი ნულამდე“.

Retention პოზა მონაცემთა კლასის მიხედვით: debug window, audit window და never-store.

ეს არის ზოგადი ოპერატორის სახელმძღვანელო და არა კონკრეტული იურისდიქციის სამართლებრივი მოთხოვნა. რეგულირებად ინდუსტრიებს სჭირდებათ counsel და საკუთარი policy owners. ინჟინერული წესი მაინც რჩება: raw prompts და completions რჩება explicit retention-ის ქვეშ და არა „დაალოგე ყველაფერი, რადგან storage იაფია“.

დასკვნა: debug window, audit window და never-store არის სამი განსხვავებული გადაწყვეტილება.

მეტრიკები, რომლებიც მნიშვნელოვანია production-ში

ჯერ თვალყური ადევნეთ პატარა ops ნაკრებს, ზედაპირულ token charts-ამდე:

• Success rate - run-ის business success და არა მხოლოდ HTTP 200.
• Exceptions / tool error rate - tool-ის და error class-ის მიხედვით.
• Human overrides - rate და reason codes; spikes ხშირად ნიშნავს semantic failure-ს ან სუსტ gates-ს.
• p95 latency - per run და per critical tool.
• Cost per successful completion - dollars ან token-derived units გაყოფილი successes-ზე და არა ყოველ partial attempt-ზე.

Token usage არის cost driver და capacity signal. თავისთავად ეს არ არის quality score. Vendor პლატფორმები ჩვეულებრივ აჩვენებენ token usage-ს, latency percentiles-ს, errors-ს და cost-ს agent traces-ისთვის (LangSmith observability; მსგავსი თემები ჩანს OSS და APM stack-ებში, მაგალითად Arize Phoenix). მიიღეთ ისინი როგორც სასარგებლო inputs; Northstar-ის production ზღვარი რჩება success, overrides და reconstructability-ზე.

Overrides დაკავშირებულია semantic failure-თან. თუ ადამიანები მუდმივად ცვლიან აგენტის outcome-ს, სისტემა ჩავარდნილია, მაშინაც კი, როცა traces მწვანედ გამოიყურება. მიმდებარე ჩავარდნის პატერნები: production აგენტის ჩავარდნის რეჟიმები.

დასკვნა: გაზომეთ დასრულებული სამუშაოს ხარისხი და ჩარევის დატვირთვა და არა მხოლოდ tokens.

OpenTelemetry ხიდი (ოფციონალური, ჯერ structure)

OpenTelemetry-ის GenAI სამუშაო მიზნად ისახავს აგენტისა და მოდელის telemetry-ის ფორმის სტანდარტიზაციას, რათა გუნდები ნაკლებად იყვნენ მიბმული ერთი framework-ის private format-ზე (OTel on AI agent observability; ცოცხალი conventions რეპოზიტორიაში semantic-conventions-genai).

როცა OTel ერგება თქვენს stack-ს, გონებრივად მიუსადაგეთ minimum schema GenAI-style ოპერაციებს, როგორიცაა root agent invoke და child tool execution (მაგალითად invoke_agent და execute_tool მიმდინარე GenAI walkthrough-ებში) (OTel GenAI observability). Attribute სახელები და stability დონეები ვითარდება. არ ჩააფიქსიროთ ყოველი attribute string runbooks-ში conventions repo-ის ხელახალი შემოწმების გარეშე implementation-ის მომენტში.

Content capture prompts-ისა და tool bodies-ისთვის უნდა დარჩეს default-off / opt-in, OTel-ის sensitive-data guidance-ის შესაბამისად, რომელიც ზემოთაა ციტირებული.

OpenTelemetry-ის დასაწყებად არ გჭირდებათ. Structured events სტაბილური ids-ით უკვე უკეთესია ცარიელ backlog-ზე „tracing-ს მოგვიანებით დავამატებთ“. Structure უფრო მნიშვნელოვანია, ვიდრე tracer-ის ბრენდი. OSS და commercial tools (Phoenix, LangSmith, MLflow-style stacks, cloud APM) შეიძლება იჯდეს სუფთა event model-ზე; არცერთი მათგანი არ ცვლის პოლიტიკას იმისა, რასაც აგენერირებთ და ინახავთ.

Hyperscaler best-practice სიები ხშირად continuous evaluation-სა და production monitoring-ს ერთმანეთის გვერდით აყენებს (Azure agent observability practices). Evals არის ცალკე design ამოცანა. ეს გვერდი რჩება logs-ზე, traces-ზე, redaction-სა და retention-ზე. თუ მოგვიანებით გჭირდებათ go-live evaluation path, გამოიყენეთ როგორ შევაფასოთ AI აგენტები go-live-მდე როგორც მეზობელი თემა და არა runtime events-ის შემცვლელი.

დასკვნა: OTel არის სასარგებლო ტერმინოლოგიური ხიდი; requirement არის თქვენი minimum schema.

Sampling და storage სიფრთხილე

აგრესიულმა sampling-მა შეიძლება წაშალოს სწორედ ის rare runs, რომლებიც ინციდენტის შემდეგ გჭირდებათ. Agent traces არის high-cardinality და ხშირად wide; ყველაფრის coarse metrics-ში ჩაკეცვა კარგავს tool args-ს, gate outcomes-ს და side-effect summaries-ს.

უპირატესობა მიანიჭეთ:

• ყოველთვის შეინახოთ structured metadata ყოველი production run-ისთვის, რომელსაც შეუძლია state-ის მუტაცია.
• Time-box heavy content (prompts, large tool bodies) და არა შემთხვევით გადაყაროთ კრიტიკული runs.
• გაყავით „full fidelity mutable paths-ისთვის“ და „lighter telemetry read-only assistants-ისთვის“, თუ cost აიძულებს split-ს.

არ მიიღოთ vendor-ის storage-size ან query-speed claims როგორც უნივერსალური ფაქტები თქვენი workload-ისთვის. გაზომეთ საკუთარი volume schema-ს სტაბილიზაციის შემდეგ.

დასკვნა: დაასემპლეთ ზედაპირული მეტრიკები და არა audit trail side-effecting tools-ისთვის.

როგორ ჯდება Northstar

Northstar production pilots-ში ჩადებს logging expectations-ს, მათ შორის correlation-ს, tool-call structure-ს, approvals-ს, redaction-სა და retention policy-ს scale-out-მდე. ეს არის აგენტების მიწოდების ნაწილი engineering და operations დისციპლინით და არა dashboard, რომელიც პირველი ინციდენტის შემდეგ მიეკრობა.

თუ გინდათ logging და approval gates pilot-ში ჩაშენებული და არა პირველი ინციდენტის შემდეგ მიბმული, დაიწყეთ გადაწყვეტებიდან. თუ ჯერ განსაზღვრავთ, რას ნიშნავს „production“ აგენტებისთვის, დაიწყეთ რა არის production AI აგენტი.