A New Relic az OpenTelemetryhez igazítja AI-megfigyelési platformját

Egy nézetbe kerülhetnek a különböző telemetriai adatok

A generatív AI-architektúrákat használó vállalatok egyre gyakrabban támaszkodnak az OpenTelemetryre, a New Relic szerint azonban az eltérő adatstruktúrák miatt láthatósági rések alakulhatnak ki. Ilyenkor az egyes alkalmazások és a nyelvi modellek tokenhasználata kimaradhat a központi követésből, miközben az OpenTelemetry nyomkövetési adatai nem kapcsolódnak a biztonsági ellenőrzési folyamatokhoz.

A vállalat AI Observability for OpenTelemetry megoldása ezt egy Normalize on Read nevű architektúrával kezeli. A telemetriai adatokat natívan, standard Span-táblákban tárolja, majd a lekérdezés pillanatában igazítja a felhasznált sémához. A New Relic állítása szerint így nincs szükség az adatok többszörözésére, az adatfelvétel közbeni átalakításra vagy a fejlesztői kód átírására.

A kezelőfelület lekérdezési motorja futásidőben felismeri a telemetria forrását, és ehhez igazítja az NRQL-sablonokat. A cég szerint ezzel ugyanaz a láthatóság érhető el az OpenTelemetry használata mellett, miközben elkerülhetők az adatkettőzésből és a háttérfeldolgozásból fakadó többletköltségek.

A tokenköltségek és a modellek teljesítménye is összevethető

Az AI Observability for OpenTelemetry fiókszintű Model Inventory nézeteket kínál, amelyekben a nyílt forrású és a natív APM-ügynököktől érkező adatok együtt jelennek meg. A platform vezetői egy helyen követhetik a teljes tokenfelhasználást, a kérések késleltetését és a hibaarányokat.

A Model Comparison felület oszloponként változtatható lekérdezési felbontást használ. Ez lehetővé teszi, hogy a fejlesztők egymás mellett hasonlítsanak össze egy saját APM-ügynökkel műszerezett régebbi szolgáltatást és egy OpenTelemetryt használó modern mikroszolgáltatást. A New Relic szerint a költség-, késleltetési és minőségi adatok együttes megjelenítése segíthet a költséghatékonyabb nyelvimodell-konfiguráció kiválasztásában.

A vállalat ezt pénzügyi irányítási funkcióként írja le. A központi nézetekkel a platformcsapatok követhetik a több mikroszolgáltatáson átívelő tokenfelhasználást, és alapvonalriasztásokat állíthatnak be a kiugró fogyasztás felismerésére.

Automatikus felderítés a rejtett AI-szolgáltatások ellen

A New Relic szerint a fejlesztőcsapatok gyakran építenek nyílt forrású LLM-könyvtárakra anélkül, hogy erről értesítenék a platform- vagy biztonsági vezetőket. Ez úgynevezett Shadow AI-hoz vezethet, amikor a mikroszolgáltatások működnek ugyan, de nem szerepelnek a központi leltárban, és nincs hozzájuk rendelve költség- vagy biztonsági felügyelet.

Az új megoldás TraceProcessor-kiterjesztése valós időben vizsgálja a beérkező OpenTelemetry-nyomkövetési adatokat. A gen_ai. kezdetű szemantikai attribútumok felismerésekor kinyeri az entitás GUID-ját, majd automatikusan az aiEnabledApp:true címkét publikálja az Entity Platformban.

Így az OpenTelemetryvel műszerezett AI-könyvtárat használó mikroszolgáltatás automatikusan bekerülhet az AI Monitoring felületére. A New Relic szerint a platformcsapatok és az SRE-k naprakész leltárt kaphatnak a nyílt forrású AI-telepítésekről, valamint szűrhetik és költségszegmensekbe rendezhetik ezeket.

A biztonsági ellenőrzések az OpenTelemetry-adatokhoz is elérhetők

A New Relic az OpenTelemetry nyomkövetési adatait közvetlenül a saját értékelési folyamatába irányítja. A cég szerint ez lehetővé teszi, hogy a nyílt forrású AI-alkalmazások élő forgalmán automatikus személyesadat-maszkolást, valós idejű promptinjekció-védelmet és toxicitásvizsgálatot végezzenek.

A megoldás az OpenTelemetry GenAI szemantikai konvencióira támaszkodik. Egyetlen span a felhasználói promptot és a nyelvi modell válaszát is tartalmazhatja, ezért a New Relic szerint nincs szükség Redis-alapú gyorsítótárazásra vagy munkamenetek utólagos összeállítására. A vállalat ezt állapotmentes feldolgozásként írja le.

A bejelentés alapján a fejlesztők tovább használhatják az általuk választott nyílt forrású könyvtárakat és a standard OpenTelemetry-műszerezést. A New Relic szerint ehhez nem kell egyedi kódot újraírni, illetve a láthatóság eléréséhez nem szükséges gyártóspecifikus SDK-ra váltani. A platform így a fejlesztési, üzemeltetési és biztonsági csapatok közös AI-felügyeletét célozza.