Գործակալի դիտարկելիություն. ինչ գրանցել, հետագծել և պահել production-ում

Յուրաքանչյուր production AI գործակալի run-ի համար գրանցեք կառուցվածքային իրադարձություններ. request id, tool name, args (redacted), results status, approvals, model ids, latency և cost։ Հում prompt-ները և ամբողջական completion-ները պահեք միայն հստակ retention rules-ի տակ։ Եթե այդ իրադարձություններից չեք կարող վերակառուցել միջադեպը, դուք չեք հասնում production AI գործակալի ճարտարապետության շեմին։

Այս էջը production logging քաղաքականություն է, ոչ թե հարթակների գնումների ցուցակ։ Օգտագործեք այն LangSmith, Phoenix, Datadog կամ plain OpenTelemetry միացնելուց առաջ, որպեսզի իրադարձությունները գոյություն ունենան նույնիսկ եթե sink-ը փոխվի։

Ինչ է գործակալի դիտարկելիությունը (և ինչ չէ)

AI գործակալի դիտարկելիությունը end-to-end վարքի մոնիտորինգի պրակտիկա է, ներառյալ LLM կանչերը և tool փոխազդեցությունները, որպեսզի կարողանաք բացատրել, թե ինչ է արել գործակալը և ինչու է run-ը ձախողվել կամ շեղվել (drift)։ Այդ սահմանումը համընկնում է արդյունաբերական նյութերի ձևակերպման հետ. end-to-end agentic journey-ներ, ոչ միայն դասական infra չափորոշիչներ (IBM on AI agent observability)։

Այն ավելի լայն է, քան դասական APM-ը։ APM-ն ասում է, որ ծառայությունը up էր, request-ը դանդաղ էր, կամ dependency-ն ժամանակը սպառեց (timeout)։ Գործակալի run-երը նաև ճյուղավորվում են, ցիկլ են անում, կանչում են 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։

Եզրակացություն. եթե ձեր telemetry-ն ավարտվում է «մոդելը կանչվեց, 200 OK»-ով, դուք գործակալը չեք դիտարկում։

Նվազագույն կենսունակ trace

Production run-ը պետք է կախված լինի մեկ correlation identity-ից յուրաքանչյուր քայլում։

Նվազագույն viable trace բովանդակություն.

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)։ Այդ ձևը կարող եք նախ իրականացնել կառուցվածքային մատյաններով։ Tracer-ի brand-ը երկրորդական է։

Հիպոթետիկ օրինակ (չվերակառուցելի). support-ը էսկալացնում է վատ refund։ Մատյաններում կա «tool succeeded» և model id, բայց չկա run_id, չկան tool args և չկա gate record։ Չեք կարող ապացուցել, թե ինչ է հաստատվել և ինչ է գրվել։ Այդ run-ը չի անցնում վերակառուցելիության շեմը, նույնիսկ եթե uptime-ը նորմալ էր երևում։

Եզրակացություն. correlation + trigger + tools + gates + side effects-ը run-ի նվազագույն պատմությունն է։

Նվազագույն event schema

Նախ թողարկեք փոքր, կայուն field հավաքածու, հետո հետապնդեք dashboard-ներ։

Նվազագույն structured fields, որոնք պետք է արտադրել յուրաքանչյուր production գործակալի 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-ը լիարժեք իրադարձություններ են, ոչ ծանոթագրություններ։ 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, ամբողջական card numbers (PAN) և ավելորդ PII, մինչև մատյանները լքեն ձեր control plane-ը։ Դա ներառում է SaaS observability արտադրանքները, vendor agent tracers, shared Slack dumps և ticket attachments։

Հստակ որոշեք, թե ինչ կարող է դուրս գալ VPC-ի կամ account սահմանից.

OpenTelemetry GenAI պրակտիկան default-ով անջատում է 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, ոչ full 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 հավաքածուի, հետո vanity token charts-ի.

• Success rate - run-ի business success, ոչ միայն HTTP 200։
• Exceptions / tool error rate - ըստ tool-ի և error class-ի։
• Human overrides - rate և reason codes. spikes-ը հաճախ նշանակում են semantic failure կամ weak 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 platforms-ը սովորաբար ցույց են տալիս 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-ը կանաչ են։ Հարակից failure patterns-ի համար տեսեք production գործակալի ձախողման ռեժիմներ։

Եզրակացություն. չափեք ավարտված աշխատանքի որակը և միջամտության բեռը, ոչ միայն tokens։

OpenTelemetry կամուրջ (ընտրովի, նախ structure)

OpenTelemetry-ի GenAI աշխատանքը նպատակ ունի ստանդարտացնել, թե ինչպես են ձևավորվում agent և model telemetry-ն, որպեսզի թիմերը ավելի քիչ կախված լինեն մեկ framework-ի private format-ից (OTel on AI agent observability. կենդանի conventions semantic-conventions-genai repository-ում)։

Երբ OTel-ը համապատասխանում է ձեր stack-ին, մտավոր համապատասխանեցրեք նվազագույն schema-ն GenAI-style operations-ի վրա, օրինակ 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-ը պարտադիր չէ սկսելու համար։ Կառուցվածքային իրադարձությունները կայուն id-ներով արդեն ավելի լավ են, քան դատարկ backlog-ը «tracing կավելացնենք հետո»։ Structure-ն ավելի կարևոր է, քան tracer-ի brand-ը։ 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 ուղի, օգտագործեք ինչպես գնահատել AI գործակալները go-live-ից առաջ որպես հարևան թեմա, ոչ որպես runtime events-ի փոխարինող։

Եզրակացություն. OTel-ը օգտակար բառապաշարային կամուրջ է. պահանջը ձեր նվազագույն schema-ն է։

Sampling և storage զգուշություն

Ագրեսիվ sampling-ը կարող է ջնջել հենց այն rare run-երը, որոնք պետք են միջադեպից հետո։ Agent traces-ը high-cardinality են և հաճախ wide. ամեն ինչը coarse metrics-ի մեջ գլորելը կորցնում է tool args, gate outcomes և side-effect summaries։

Նախընտրեք.

• Միշտ պահել structured metadata յուրաքանչյուր production run-ի համար, որը կարող է փոխել state։
• Ժամանակային սահմանափակում դրեք heavy content-ի վրա (prompts, մեծ tool bodies), ոչ թե պատահականորեն բաց թողեք critical runs։
• Առանձնացրեք «full fidelity mutable paths-ի համար» և «lighter telemetry read-only assistants-ի համար», եթե cost-ը ստիպում է split։

Մի ընկալեք vendor-ի storage-size կամ query-speed պնդումները որպես ունիվերսալ փաստեր ձեր workload-ի համար։ Չափեք ձեր սեփական volume-ը schema-ն կայունանալուց հետո։

Եզրակացություն. նմուշառեք vanity-ն, ոչ audit trail-ը side-effecting tools-ի համար։

Ինչպես է Northstar-ն տեղավորվում

Northstar-ն ներառում է logging սպասումներ production pilots-ում, ներառյալ correlation, tool-call կառուցվածք, approvals, redaction և retention policy scale-out-ից առաջ։ Դա գործակալներ թողարկելու մաս է engineering և operations կարգապահությամբ, ոչ dashboard, որը կպցվում է առաջին միջադեպից հետո։

Եթե ուզում եք logging և approval gates, նախագծված pilot-ի մեջ, ոչ կպցված առաջին միջադեպից հետո, սկսեք լուծումներից։ Եթե դեռ սահմանում եք, թե ինչ է նշանակում «production» գործակալների համար, սկսեք ինչ է production AI գործակալը։