Michael JohnsonAWS tillkännagav CloudWatch Omni den 22 september 2026 och listade det som allmänt tillgängligt den 23 september. Datumen beskriver två olika händelser: tillkännagivandet och starten för allmän tillgänglighet. Omni samlar observerbarhet för applikationer och AI-agenter i en och samma upplevelse, med ett fristående webbgränssnitt och IDE-tillägg samt CloudWatch-integration. aws.amazon.com
Den kombinationen åtgärdar en blind fläck i produktionsmiljöer: en agents begäran kan slutföras utan ett konventionellt tjänstefel och ändå ge ett dåligt svar eller välja fel verktyg. AWS framhåller att team kan granska agentspår och utvärderingar tillsammans med applikationstelemetri. Den praktiska frågan är om signalerna blir användbara i en gemensam arbetsyta – och vilken data, åtkomst och vilka kostnader som följer med att dirigera dem dit.
Produkten omfattar mer än agentspår
Omni är ett tillägg till CloudWatch, inte en ersättning för det. AWS uppger att befintliga CloudWatch-larm, instrumentpaneler, API:er och konsolflöden fortsätter att fungera. Telemetri som redan skickas till CloudWatch kan visas i Omni utan omkonfigurering; andra instrumenterade arbetslaster kan skicka data via OpenTelemetry Protocol (OTLP). AWS beskriver också tjänsteupptäckt och beroendekartläggning, med arbetsytor som kan samla telemetri från flera konton och regioner när de konfigureras för det ändamålet. docs.aws.amazon.com
Upplevelsen är inte begränsad till AWS Management Console. AWS erbjuder ett fristående webbgränssnitt med enkel inloggning samt IDE-tillägg för VS Code, Cursor och Kiro. Versionsinformationen från den 23 september anger att tjänsten är allmänt tillgänglig i US East (N. Virginia), US West (Oregon) och Europe (Ireland). Team bör kontrollera det regionala stödet innan de bygger in Omni i en produktionslösning.
För agenter beskriver AWS spårutforskning, utvärdering och experimentering med ramverk som OpenAI Agents SDK, LangGraph, CrewAI, Vercel AI SDK och Strands. Vid applikationsundersökningar kan användare ställa frågor på naturligt språk eller utforska telemetrin direkt; AWS uppger att de AI-assisterade undersökningsfunktionerna drivs av DevOps Agent. I lanseringsinlägget om applikationer uppger AWS också att DevOps Agent är aktiverat som standard i varje Omni-undersökningssession, vilket administratörer bör känna till när de bedömer arbetsflödet.
Därför kan det spela roll att samla signalerna
Konventionell övervakning kan visa om en tjänst svarar, hur lång tid det tar och om den returnerar fel. Den visar kanske inte att en agent missförstod en begäran, valde ett olämpligt verktyg eller gav ett felaktigt svar. Om ett utvärderingsresultat granskas tillsammans med spåret och applikationssignalerna kan teamet kanske spåra ett kvalitetsproblem bakåt genom agentens körning.
Det är en tänkbar operativ fördel, inte ett bevisat resultat. AWS lanseringsmaterial beskriver det kombinerade arbetsflödet, men visar inte att det löser incidenter snabbare än befintliga verktyg. Team behöver testa om Omnis utvärderingar och undersökningar hjälper i deras egna arbetslaster.
OpenTelemetry kan göra det enklare att skicka telemetri från befintlig instrumentering, men ett gemensamt protokoll gör inte observerbarhetsplattformar utbytbara. OTLP-specifikationen definierar hur telemetri överförs; team behöver fortfarande kontrollera vilka signaler, frågor och plattformsspecifika funktioner deras arbetsflöden är beroende av.
Centralisering kräver konfiguration
Omni kan samla data från flera konton och regioner, men team bör inte utgå från att aktivering av gränssnittet automatiskt samlar telemetri från alla konton. AWS installationsdokumentation beskriver hur domäner och arbetsytor skapas och hur telemetri från flera konton sedan konfigureras för att föras in i en arbetsyta. Befintliga CloudWatch-data kan visas utan ny instrumentering, men organisationen måste fortfarande konfigurera avsedd åtkomst och dataflöde. docs.aws.amazon.com
Den skillnaden spelar roll både för driftsättning och kostnader. AWS prissida skiljer mellan avgifter för inläsning, lagring och analys av telemetri. Den beskriver även avgifter för ytterligare centraliserade kopior, medan den första centraliserade kopian är kostnadsfri enligt den angivna prissättningen. Frågekostnader beror på mängden genomsökt data och tillämpliga inkluderade mängder; agentutvärderingar faktureras enligt priserna för Amazon Bedrock AgentCore Evaluations. En användbar kostnadsuppskattning behöver därför ta hänsyn till volym, lagringstid, frågemönster, kopior och utvärderingsfrekvens – inte bara antalet agenter.
Granska spårinnehåll och åtkomst
Agentspår kan innehålla promptar, svar, hämtade dokument och personuppgifter. AWS uppger att Omni inte automatiskt upptäcker eller maskerar personligt identifierbar information. I sina riktlinjer för känsliga data rekommenderar AWS att man väljer var filtreringen ska ske; maskering vid insamling är det alternativ som hindrar känsligt innehåll från att lämna applikationen.
AWS uppger också att Omni inte använder kundinnehåll för att träna grundmodeller eller förbättra Omni i sig. Det innebär inte att innehållet aldrig behandlas någon annanstans: vissa funktioner skickar data till tjänster som Bedrock eller AgentCore, och AWS dokumenterar inferens över regioner för AI-funktioner. Data lagras fortfarande i arbetsytans region, men AI-begäranden kan behandlas på andra platser inom samma geografiska område. Team bör granska AWS policy för dataanvändning och informationen om inferens över regioner, särskilt om deras policyer begränsar var spårinnehåll får behandlas.
Åtkomstkontroller kräver samma granskning som telemetripipelinen. AWS uppger att medlemmar i en arbetsyta som standard kan läsa all dess telemetri; databegränsningar kan avgränsa vilka logg- och spårrader en medlem ser. Begränsningarna döljer dock inte fält i en rad och ersätter därför inte maskering av innehåll som användare aldrig ska få se. docs.aws.amazon.com
Utvärdera Omni stegvis
För team som redan använder CloudWatch kan ett avgränsat test visa om Omnis gemensamma vy för applikationer och agenter hjälper med ett verkligt arbetsflöde. Innan produktionsspår skickas dit bör team identifiera vilka signaler som behövs, konfigurera filtrering, fastställa åtkomst till konton och regioner samt uppskatta kostnader för inläsning, lagring, analys och utvärdering. Jämför sedan de genererade undersökningarna och utvärderingsresultaten med nuvarande incidentrutiner.
För organisationer som använder andra observerbarhetsplattformar är lanseringen en anledning att utvärdera arbetsflödet – inte i sig ett skäl att migrera. Omni för kvalitetsindikatorer för agenter närmare applikationsdriften, men värdet beror på hur användbara undersökningarna är, hur väl kontrollerna passar och vad dataflödet kostar.
