Két perc alatt jutott el a tünettől az okig a SingleStore új ügynöke

Természetes nyelven lehet kérdezni a rendszer állapotáról

Az Observability Agent a SingleStore munkaterületének állapotáról fogad kérdéseket közérthető nyelven, a válaszokat pedig a felhasználó saját megfigyelési adataira alapozza. Meg lehet kérdezni például, hogyan alakult a CPU-, memória- és lemezhasználat egy fürtön az elmúlt órában, volt-e kiugró csomópont, mely lekérdezések használták a legtöbb erőforrást, illetve milyen gyakran hibáztak.

Az ügynök egy lassuló adatfeldolgozási folyamatnál is megvizsgálhatja az állapotot, a közelmúltbeli változásokat, az átviteli teljesítményt, az erőforrás-használatot és a hibákat. Azt is ellenőrzi, hogy egy fürtesemény vagy más művelet időben egybeesett-e a lassulással. A SingleStore szerint az ügynök megmutatja, milyen bizonyítékok alapján jutott a következtetésre, így a válasz ellenőrizhető marad.

Diagnosztizál, de nem módosítja a rendszert

Az Observability Agent nem hajt végre műveleteket a felhasználó helyett. Nem változtatja meg az adatokat, nem módosítja a konfigurációt, nem méretezi át az infrastruktúrát, és nem állít le munkaterhelést. Azt magyarázza el, mi történik, valamint javaslatot ad arra, mit érdemes megvizsgálni, a döntés azonban a felhasználónál marad.

A hozzáféréseket a Helios szerepköralapú hozzáférés-vezérlése korlátozza. Minden kérés ugyanazokat a jogosultságokat használja, mint a felhasználó, ezért az ügynök csak az elérhető munkaterületeket vizsgálhatja, és csak az olvasásra jogosult adatokat láthatja. A vizsgálat egy hibásnak tűnő grafikonról is elindítható, ilyenkor az ügynök átveszi a megnyitott fürtöt és időablakot.

Egy memóriahiba mögött a sikertelen lekérdezések álltak

A SingleStore egy éles ügyfélesetet is bemutatott. Egy munkaterület délelőtt memóriahibákat kezdett jelezni, miközben a hibaüzenet csak azt mutatta, hogy a csomópont elérte a maximális memóriaértéket. A kezdeti értékelés szerint a memória a lekérdezések végrehajtásában gyűlt, ezért a szokásos javaslat a terhelés csökkentése vagy a munkaterület bővítése volt.

Az ügynök először kizárta, hogy a táblák memóriaigénye növekedett volna. Ez nagyjából 7,7 GB-on maradt, miközben a lekérdezések végrehajtási memóriája egyetlen ötperces időszakban körülbelül 2,4 GB-ról több mint 70 GB-ra ugrott. Ezután memóriahasználat szerint rangsorolta a munkaterheléseket, nem pedig a futási idő alapján.

A legnagyobb terhelést két, ugyanahhoz a jelentéshez kapcsolódó lekérdezésváltozat okozta. A forrásban szereplő adatok szerint ezek az esetek 80, illetve 84 százalékában hibáztak. Az ügynök ebből arra következtetett, hogy az ismételt próbálkozások újra és újra memóriát foglalnak, így maguk is fenntartják a memóriahiányos állapotot. Egy másik lekérdezés több mint 40 GB adatot írt ki lemezre, ami további nyomást jelentett.

A SingleStore szerint két perc alatt elkészült a használható elemzés

A vállalat beszámolója szerint az ügynök körülbelül két perc alatt jutott el a beillesztett hibaüzenettől a rangsorolt, intézkedést segítő megállapításokig. A javaslat ezúttal konkrétabb volt: meg kellett keresni a SelectReport_A változatokat előállító Looker-jelentést, majd korlátozni annak terhelését. A méretezés továbbra is lehetséges opció maradt, de önmagában a SingleStore szerint csak több teret adhatott volna az újrapróbálkozásoknak.

A megoldás a vállalat szerint azért működhet gyorsan, mert a SingleStore már tárolja az ilyen vizsgálatokhoz szükséges fürtállapot-, munkaterhelési és adatfolyam-aktivitási jeleket. Az ügynök egymás után teszi fel a következő kérdéseket, például először azt vizsgálja, nő-e a tábla memóriahasználata, majd azt, melyik munkaterhelés fogyasztja a memóriát, végül pedig azt, milyen gyakran hibázik a kiemelt terhelés. A felhasználók így ellenőrizhető magyarázatot és konkrétan vizsgálható következő lépést kapnak.