Michael JohnsonAWS kunngjorde CloudWatch Omni 22. september 2026 og oppførte tjenesten som generelt tilgjengelig 23. september. Datoene viser til to ulike hendelser: kunngjøringen og starten på generell tilgjengelighet. Omni samler observerbarhet for applikasjoner og KI-agenter i én opplevelse, med et frittstående webgrensesnitt og IDE-utvidelser i tillegg til CloudWatch-integrasjon, slik AWS beskriver i kunngjøringen.
Denne kombinasjonen tar tak i en blindflekk i produksjon: En forespørsel fra en agent kan fullføres uten en konvensjonell tjenestefeil, men likevel gi et dårlig svar eller velge feil verktøy. AWS mener at team kan undersøke agent-spor og evalueringer sammen med applikasjonstelemetri. Det praktiske spørsmålet er om signalene blir nyttige i et felles arbeidsområde – og hvilke data, tilganger og kostnader som følger med når de rutes dit.
Produktet omfatter mer enn agent-spor
Omni er en utvidelse av CloudWatch, ikke en erstatning for tjenesten. AWS sier at eksisterende CloudWatch-alarmer, dashbord, API-er og konsollarbeidsflyter fortsatt fungerer. Telemetri som allerede sendes til CloudWatch, kan vises i Omni uten ny konfigurering. Andre instrumenterte arbeidsbelastninger kan sende data gjennom OpenTelemetry Protocol (OTLP). AWS beskriver også tjenesteoppdagelse og avhengighetskartlegging, med områder som kan samle telemetri på tvers av kontoer og regioner når dette konfigureres slik. AWS-dokumentasjonen for CloudWatch Omni beskriver disse funksjonene.
Opplevelsen er ikke begrenset til AWS Management Console. AWS tilbyr et frittstående webgrensesnitt med enkel pålogging, samt IDE-utvidelser for VS Code, Cursor og Kiro. Lanseringsnotatet fra 23. september oppgir at tjenesten er generelt tilgjengelig i US East (N. Virginia), US West (Oregon) og Europa (Irland). Team bør undersøke regional støtte før de bygger Omni inn i en produksjonsløsning.
For agenter beskriver AWS sporutforsking, evaluering og eksperimentering med rammeverk som OpenAI Agents SDK, LangGraph, CrewAI, Vercel AI SDK og Strands. I applikasjonsundersøkelser kan brukerne stille spørsmål på naturlig språk eller utforske telemetrien direkte. AWS opplyser at funksjonene for KI-assistert undersøkelse drives av DevOps Agent. I innlegget om lanseringen for applikasjoner står det også at DevOps Agent er aktivert som standard i hver Omni-undersøkelsesøkt – en oppførsel administratorer bør kjenne til når de vurderer arbeidsflyten.
Derfor kan det være nyttig å samle signalene
Konvensjonell overvåking kan vise at en tjeneste svarer, hvor lang tid det tar, og om den returnerer feil. Den viser ikke nødvendigvis at en agent misforsto en forespørsel, valgte et uegnet verktøy eller ga et feil svar. Ved å se et evalueringsresultat sammen med sporet og applikasjonssignalene kan et team kanskje spore et kvalitetsproblem tilbake gjennom agentens kjøring.
Dette er en sannsynlig driftsfordel, ikke et dokumentert resultatmål. AWS’ lanseringsmateriell beskriver den kombinerte arbeidsflyten, men viser ikke at den løser hendelser raskere enn eksisterende verktøy. Team må teste om Omnis evalueringer og undersøkelser hjelper med deres egne arbeidsbelastninger.
OpenTelemetry kan gjøre det enklere å sende telemetri fra eksisterende instrumentering, men en felles protokoll gjør ikke plattformer for observerbarhet utbyttbare. OTLP-spesifikasjonen definerer hvordan telemetri overføres. Team må fortsatt undersøke hvilke signaler, spørringer og plattformspesifikke funksjoner arbeidsflytene deres er avhengige av.
Sentralisering krever konfigurering
Omni kan samle data på tvers av kontoer og regioner, men team bør ikke anta at det å aktivere grensesnittet automatisk samler telemetrien fra alle kontoer. AWS’ oppsettdokumentasjon beskriver hvordan man oppretter domener og områder, og deretter konfigurerer hvordan telemetri fra flere kontoer samles i et område. Eksisterende CloudWatch-data kan vises uten ny instrumentering, men organisasjonen må fortsatt sette opp ønsket tilgang og dataflyt. AWS’ veiledning for oppsett beskriver denne prosessen.
Dette skillet er viktig både for utrulling og kostnader. AWS’ prisside for Omni skiller mellom kostnader for inntak av telemetri, lagring og analyse. Den beskriver også kostnader for ekstra sentraliserte kopier, mens den første sentraliserte kopien er gratis i henhold til den oppgitte prisingen. Spørringskostnadene avhenger av mengden skannede data og inkluderte kvoter; agentevalueringer faktureres etter prisene for Amazon Bedrock AgentCore Evaluations. Et nyttig kostnadsoverslag må derfor ta hensyn til datamengde, oppbevaringstid, spørringsmønstre, kopier og evalueringsfrekvens – ikke bare antall agenter.
Innhold i spor og tilgang må gjennomgås
Agent-spor kan inneholde spørsmål, svar, hentede dokumenter og personopplysninger. AWS sier at Omni ikke automatisk oppdager eller sladder personlig identifiserbar informasjon. I veiledningen om sensitive data anbefaler AWS å velge hvor filtreringen skal skje. Sladding ved registrering er alternativet som hindrer at sensitivt innhold forlater applikasjonen.
AWS sier også at Omni ikke bruker kundens innhold til å trene grunnmodeller eller forbedre Omni. Det betyr ikke at innholdet ikke behandles andre steder: Noen funksjoner sender data til tjenester som Bedrock eller AgentCore, og AWS dokumenterer inferens på tvers av regioner for KI-funksjoner. Data lagres fortsatt i regionen til området, men KI-forespørsler kan behandles andre steder innenfor samme geografiske område. Team bør gjennomgå AWS’ retningslinjer for databruk og detaljene om inferens på tvers av regioner, særlig hvis retningslinjene deres begrenser hvor sporinnhold kan behandles.
Tilgangskontroller fortjener samme grundige vurdering som telemetripipelinen. AWS sier at medlemmer av et område som standard kan lese all telemetrien der. Dataomfang kan begrense hvilke rader med logger og spor et medlem ser. Omfangene skjuler imidlertid ikke felter i en rad, så de erstatter ikke sladding av innhold som brukerne aldri skal se. AWS’ veiledning om å begrense medlemstilgang beskriver kontrollene.
Slik kan Omni evalueres på en kontrollert måte
For team som allerede bruker CloudWatch, kan en avgrenset test vise om Omnis felles visning av applikasjoner og agenter hjelper med en reell arbeidsflyt. Før dere sender produksjonsspor, bør dere identifisere hvilke signaler som trengs, konfigurere filtrering, fastsette tilgang på konto- og regionnivå og anslå kostnader for inntak, lagring, analyse og evaluering. Sammenlign deretter undersøkelsene og evalueringsresultatene med dagens rutiner for hendelseshåndtering.
For organisasjoner som bruker andre plattformer for observerbarhet, er lanseringen en grunn til å vurdere arbeidsflyten – ikke i seg selv en grunn til å migrere. Omni bringer signaler om agentkvalitet nærmere applikasjonsdriften, men verdien avhenger av hvor nyttige undersøkelsene er, hvor godt kontrollene passer, og hva dataflyten koster.
