A SingleStore új ügynöke percek alatt keresi meg a hibák okát

Természetes nyelvű vizsgálat a SingleStore adataival

A SingleStore szeptember 28-i bejelentése szerint az Observability Agent segítségével a felhasználók hétköznapi nyelven kérdezhetnek a SingleStore-munkaterületek állapotáról. Meg lehet kérdezni például, hogyan alakult egy fürt CPU-, memória- és lemezhasználata az elmúlt órában, van-e kiugró csomópont, mely lekérdezések használták a legtöbb erőforrást, vagy miért lassult le egy adatfolyam két megadott időpont között.

Az ügynök a vállalat leírása szerint több megfigyelési jelet kapcsol össze. Átnézi a releváns adatokat, egyik jelről a következőre követi a bizonyítékokat, és akkor áll meg, amikor szerinte egyértelművé válik az ok. A válaszhoz bemutatja az elemzés menetét és a kapcsolódó adatokat is, így az eredmény ellenőrizhető marad.

Ha a felhasználó egy hibásnak tűnő diagramról indítja a vizsgálatot, az ügynök átveszi a megnyitott fürtöt és időablakot, majd ezek alapján folytatja a keresést.

Az ügynök diagnosztizál, de nem hajt végre műveleteket

Az Observability Agent feladata a diagnózis. Nem módosít adatokat, nem változtat konfigurációt, nem méretezi át az infrastruktúrát, és nem állít le munkaterhelést. Elmagyarázza, mi történik, valamint javaslatot ad a következő lépésekre, a döntést azonban a felhasználónál hagyja.

A hozzáférésekre is a SingleStore Helios szerepköralapú hozzáférés-vezérlése vonatkozik. Minden kérés ugyanazokkal a jogosultságokkal fut, mint amelyeket a felhasználó egyébként is birtokol. Az ügynök így csak az elérhető munkaterületeket vizsgálhatja, és csak az olvasásra jogosult adatokat láthatja.

Egy memóriahiba mögött több újrapróbálkozó lekérdezés állt

A SingleStore egy éles ügyfélincidensen keresztül mutatta be a működést. Egy termelési munkaterület délelőtt memóriahibákat kezdett jelezni, miközben a hibaüzenet főként csak azt közölte, hogy egy csomóponton elérte a beállított memóriahatárt.

Az első vizsgálat alapján a memória a lekérdezések végrehajtásánál fogyott, nem a táblák tárolásánál. Ez a szokásos javaslathoz vezetett: csökkenteni kell a terhelést, vagy fel kell méretezni a munkaterületet. A csapat azonban azt akarta tudni, pontosan melyik munkaterhelés okozza a problémát.

Az ügynök megállapította, hogy a táblamemória nagyjából változatlanul, körülbelül 7,7 GB-on maradt, miközben a lekérdezési memória egyetlen ötperces időszakban körülbelül 2,4 GB-ról több mint 70 GB-ra ugrott. Ezután nem a leghosszabb ideig futó lekérdezéseket, hanem a memóriahasználat alapján rangsorolt munkaterheléseket vizsgálta.

A két legnagyobb terhelést két, ugyanahhoz a jelentéshez kapcsolódó lekérdezésváltozat adta. Ezek a futásaik 80, illetve 84 százalékában hibáztak. A SingleStore értelmezése szerint az újrapróbálkozások minden ciklusban újra memóriát foglaltak, így maguk a lekérdezések tartották fenn a memóriahiányt. Egy további lekérdezés több mint 40 GB adatot írt lemezre, ami újabb nyomást jelentett.

A vállalat szerint két perc alatt elkészült a rangsorolt magyarázat

A SingleStore szerint az ügynök körülbelül két perc alatt jutott el a bemásolt hibaüzenettől a beavatkozást igénylő munkaterhelések rangsoráig. A konkrét javaslat az volt, hogy keressék meg a jelentést előállító Looker-munkafolyamatot, és korlátozzák azt. A felméretezés továbbra is lehetőség maradt, de az elemzés alapján önmagában csak több teret adhatott volna az újrapróbálkozási ciklusnak.

A SingleStore szerint az ügynök a Helioshoz kapcsolódó fürtegészségügyi, munkaterhelési és adatfolyam-aktivitási adatokat használja. Az elemzés azért lehet gyors, mert a következő kérdés mindig az előző válasz alapján születik meg. A bemutatott esetben az ügynök először kizárta a táblamemória növekedését, majd memóriahasználat szerint rangsorolt, végül a legfontosabb munkaterhelések hibaarányát vizsgálta.