Pitanje:
Jednostavan način algoritamskog prepoznavanja skoka zabilježenih pogrešaka
dbenton
2012-10-25 02:44:26 UTC
view on stackexchange narkive permalink

Trebamo sustav ranog upozoravanja. Imam posla s poslužiteljem za koji se zna da ima problema s performansama pod opterećenjem. Pogreške se bilježe u bazi podataka zajedno s vremenskom oznakom. Postoje neki koraci ručne intervencije koji se mogu poduzeti kako bi se smanjilo opterećenje poslužitelja, ali samo ako je netko svjestan problema ...

S obzirom na niz puta kada su se dogodile pogreške, kako mogu prepoznati početak porasta pogrešaka (u stvarnom vremenu)? Možemo izračunati povremeno ili za svaku pojavu pogreške.

Ne brinu nas povremene pogreške, ali nemamo određeni prag. Mogao bih samo obavijestiti nekoga kad god u pet minuta dobijemo, recimo, tri pogreške, ali siguran sam da postoji bolji način ...

Volio bih biti u mogućnosti prilagoditi osjetljivost algoritam zasnovan na povratnim informacijama sysadmina. Za sada bi željeli da to bude prilično osjetljivo, iako znamo da možemo očekivati ​​neke lažne pozitivne rezultate.

Nisam statističar, što je sigurno da je očito, a provedba toga mora biti relativno jednostavan s našim postojećim alatima: SQL Server i old-school ASP JScript. Ne tražim odgovor u kodu, ali ako zahtijeva dodatni softver, vjerojatno nam neće uspjeti (premda pozdravljam nepraktična, ali idealna rješenja kao komentar, iz vlastite znatiželje).

Čini se da je ovo bilo korisno ljudima, pa ću naslov ostaviti onakvim kakav jest, ali mislim da "spike" obmanjuje.Ono što smo zapravo tražili je točka preokreta ili relativno povećanje.
četiri odgovori:
Rohit Chatterjee
2013-04-21 15:24:30 UTC
view on stackexchange narkive permalink

Prošlo je pet mjeseci otkad ste postavili ovo pitanje i nadamo se da ste nešto smislili. Ovdje ću iznijeti nekoliko različitih prijedloga, nadajući se da ćete im naći neke koristi u drugim scenarijima.

Za vaš slučaj upotrebe mislim da ne morate gledati algoritme za otkrivanje šiljaka .

Dakle, ide ovdje: Počnimo sa slikom pogrešaka koje se javljaju na vremenskoj traci:

Error Graph

Ono što želite je numerički pokazatelj, "mjera" brzine pogrešaka. I ova bi mjera trebala biti podložna graničarenju - vaši sysadmini trebali bi moći postaviti ograničenja koja kontroliraju s kojom se osjetljivošću pogreške pretvaraju u upozorenja.

Mjera 1

Spomenuli ste "šiljke", najlakši način za postizanje šiljaka je crtanje histograma u svakih 20-minutnih intervala:

Error Histogram

Vaši sysadmini postavili bi osjetljivost na temelju visine šipki, tj. najviše pogrešaka podnošljivih u intervalu od 20 minuta.

(U ovom trenutku možda se pitate da li bi to 20- Duljina minutnog prozora ne može se prilagoditi. Može, a duljinu prozora možete zamisliti kao definiranje riječi zajedno u frazi pogreške koje se pojavljuju zajedno .)

Koji je problem s ovom metodom za vaš određeni scenarij? Pa, vaša je varijabla cijeli broj, vjerojatno manja od 3. Ne biste postavili prag na 1, jer to samo znači "svaka pogreška je upozorenje" koja ne zahtijeva algoritam. Dakle, vaši izbori za prag bit će 2 i 3. To vašim sysadminima ne daje puno precizne kontrole.

Mjera 2

Umjesto brojanja pogrešaka u vremenskom prozoru, pratite broj minuta između trenutne i posljednje pogreške. Kad ova vrijednost postane premala, to znači da su vaše pogreške prečeste i da morate upozoriti.

Time Differences

Vaši će sysadmineri vjerojatno postaviti ograničenje na 10 (tj. ako se pogreške događaju manje od 10 minuta, to je problem) ili 20 minuta. Možda 30 minuta za sustav koji nije kritičan za misiju.

Ova mjera pruža veću fleksibilnost. Za razliku od mjere 1, za koju je postojao mali skup vrijednosti s kojima biste mogli raditi, sada imate mjeru koja daje dobrih 20-30 vrijednosti. Stoga će vaši sysadmini imati više prostora za fino podešavanje.

Prijateljski savjet

Postoji još jedan način da pristupite ovom problemu. Umjesto gledanja učestalosti pogrešaka, možda će biti moguće predvidjeti pogreške prije nego što se pojave.

Spomenuli ste da se to ponašanje događalo na jednom poslužitelju za kojeg se zna da ima problema s izvedbom. Možete pratiti određene ključne pokazatelje izvedbe na tom računalu i tražiti da vam kažu kada će se dogoditi pogreška. Konkretno, osvrnuli biste se na upotrebu CPU-a, upotrebu memorije i KPI-jeve koji se odnose na diskovni I / O. Ako vaša upotreba procesora prijeđe 80%, sustav će se usporiti.

(Znam da ste rekli da ne želite instalirati nikakav softver i istina je da biste to mogli učiniti pomoću PerfMona. Ali postoje besplatni alati koji će to učiniti umjesto vas, poput Nagios i Zenoss.)

A za ljude koji su ovdje došli nadajući se da će pronaći nešto o otkrivanju šiljaka u vremenskoj seriji:

Otkrivanje šiljaka u vremenskoj seriji

Najjednostavnija stvar koju biste trebali započeti je izračunavanje pokretnog prosjeka vaših ulaznih vrijednosti. Ako je vaša serija $ x_1, x_2, ... $, tada biste izračunali pokretni prosjek nakon svakog promatranja kao:

$ M_k = (1 - \ alpha) M_ {k-1} + \ alpha x_k $

gdje bi $ \ alpha $ odredio kolika težina daje najnoviju vrijednost $ x_k $.

Ako se vaša nova vrijednost previše udaljila od pokretnog prosjeka, na primjer

$ \ frac {x_k - M_k} {M_k} > 20 \% $

tada podižete upozorenje.

Pomični prosjeci ugodni su za rad s podacima u stvarnom vremenu. Ali pretpostavimo da već imate hrpu podataka u tablici i samo želite pokrenuti SQL upite protiv nje kako biste pronašli skokove.

Predložio bih:

  1. Izračunajte srednja vrijednost vaših vremenskih serija
  2. Izračunajte standardnu ​​devijaciju $ \ sigma $
  3. Izolirajte one vrijednosti koje su više od $ 2 \ sigma $ iznad prosjeka (možda ćete trebati prilagoditi taj faktor "2")

Još zabavnih stvari o vremenskim serijama

  • Mnoge stvarne vremenske serije pokazuju ciklično ponašanje. Postoji model koji se zove ARIMA koji vam pomaže izvući ove cikluse iz vaših vremenskih serija.

  • Pomični prosjeci koji uzimaju u obzir ciklično ponašanje: Holt i Winters

  • Hvala na temeljitom i edukativnom odgovoru. Završili smo s pisanjem pohranjene procedure za bilježenje svake pogreške u bazu podataka i vraćanje broja pogrešaka u posljednjih X (riješili smo 5) minuta. Ako je taj broj premašio naš prag, Y, poslala se e-poruka s upozorenjem. Prag smo podesili eksperimentiranjem dok nismo bili zadovoljni. Ako bih to učinio, uključio bih vaš prijedlog brojanja vremena između pogrešaka radi veće granulacije.
    Odgovor u Kući slavnih, * pljesak *.Pridružio se ovoj zajednici samo da bi je podržao.
    Tumbledown
    2012-10-25 13:05:22 UTC
    view on stackexchange narkive permalink

    +1 za statističku kontrolu procesa, ovdje su neke korisne informacije o otkrivanju koraka.

    Za SPC nije preteško napisati implementaciju niti zapadne Električna pravila ili Nelsonova pravila.

    Jednostavno napravite USP u SQL poslužitelju koji će se iteratizirati kroz skup podataka i pingati svaku točku prema pravilima koristeći susjedne točke . Možda zbrojite broj pogrešaka po satu (ovisno o vašim potrebama).


    Ova vrsta odnosi se na pitanje koje sam neko vrijeme objavio na Stack Overflowu (upravo sam napisao brzi odgovor ako je pomaže): Grafikoni statističke kontrole procesa u SQL Server 2008 R2

    damienh
    2012-10-25 03:51:14 UTC
    view on stackexchange narkive permalink

    Potraga za algoritmima mrežne detekcije bila bi početak.

    Više informacija smješteno na stackoverflow: Najveća dekcija izmjerenog signala

    Implementaciju pythona rutine naivnog otkrivanja vrhova pronaći ćete na github

    Tražio sam _online algoritme za otkrivanje_ i uglavnom nalazio akademske članke koji su mi preko glave. Oni mogu zadržati odgovor, ali nemojte proći moj osobni "jednostavni" test. Ispravite me ako griješim, ali mislim da ne tražim algoritam za otkrivanje vrha. Jednom kada pogreške dosegnu vrhunac, čini se da sam po definiciji propustio priliku popraviti najgore pitanje. Ispričavam se ako je moja upotreba "spike" zbunjivala. Pretpostavljam da trebam predvidjeti daljnji porast pogrešaka ili prepoznati veliki korak gore.
    Stephan Kolassa
    2012-10-25 04:11:59 UTC
    view on stackexchange narkive permalink

    Možda biste željeli pogledati statističku kontrolu procesa. Ili praćenje vremenskih serija. U tom smjeru ima puno posla, a optimalni odgovor vjerojatno uvelike ovisi o tome što točno radite (trebate li filtrirati godišnje ili tjedne sezonske opterećenja prije otkrivanja anomalija itd.).



    Ova pitanja su automatski prevedena s engleskog jezika.Izvorni sadržaj dostupan je na stackexchange-u, što zahvaljujemo na cc by-sa 3.0 licenci pod kojom se distribuira.
    Loading...