Hei kaikille!
Yrityksemme harjoittaa ohjelmistokehitystä ja sitä seuraavaa teknistä tukea. Tekninen tuki ei edellytä vain virheiden korjaamista, vaan myös sovelluksiemme suorituskyvyn seurantaa.
Jos esimerkiksi jokin palveluista on kaatunut, sinun on tallennettava tämä ongelma automaattisesti ja aloitettava sen ratkaiseminen, eikä odota, että tyytymättömät käyttäjät ottavat yhteyttä tekniseen tukeen.
Meillä on pieni yritys, meillä ei ole resursseja tutkia ja ylläpitää mitään monimutkaisia ratkaisuja sovellusten valvontaan, meidän piti löytää yksinkertainen ja tehokas ratkaisu.
Seurantastrategia
Sovelluksen toimivuuden tarkistaminen ei ole helppoa, tämä tehtävä on ei-triviaali, voisi jopa sanoa, että luova. Erityisen vaikeaa on todentaa monimutkainen monilinkkijärjestelmä.
Kuinka voit syödä norsun? Vain osissa! Käytämme tätä lähestymistapaa sovellusten valvontaan.
Valvontastrategiamme ydin:
Jaa sovelluksesi osiin.
Luo ohjaustarkistuksia jokaiselle komponentille.
Komponentti katsotaan toimivaksi, jos kaikki sen ohjaustarkastukset suoritetaan virheettömästi. Sovellusta pidetään terveenä, jos kaikki sen osat ovat toimivia.
Siten mikä tahansa järjestelmä voidaan esittää komponenttipuuna. Monimutkaiset komponentit jaetaan yksinkertaisempiin. Yksinkertaisilla komponenteilla on tarkistukset.
Vertailuarvoja ei ole tarkoitettu toiminnallisen testauksen suorittamiseen, ne eivät ole yksikkötestejä. Valvontatarkastuksilla tulee tarkistaa, miltä komponentti tuntuu kulloinkin, onko kaikki sen toimintaan tarvittavat resurssit ja onko siinä ongelmia.
Ihmeitä ei ole, useimmat tarkastukset on kehitettävä itsenäisesti. Mutta älä pelkää, sillä useimmissa tapauksissa yksi tarkistus vie 5-10 koodiriviä, mutta voit toteuttaa minkä tahansa logiikan ja ymmärrät selvästi, kuinka sekki toimii.
Valvontajärjestelmä
Oletetaan, että jaoimme sovelluksen osiin, keksimme ja toteutimme tarkistuksia jokaiselle komponentille, mutta mitä tehdä näiden tarkistusten tuloksilla? Mistä tiedämme, jos jokin tarkistus epäonnistui?
Tarvitsemme seurantajärjestelmän. Hän suorittaa seuraavat tehtävät:
- Vastaanota testitulokset ja käytä niitä komponenttien tilan määrittämiseen.
Visuaalisesti tämä näyttää komponenttipuun korostamisesta. Toiminnalliset komponentit muuttuvat vihreiksi, ongelmalliset punaisiksi. - Suorita yleiset tarkistukset valmiina.
Valvontajärjestelmä voi suorittaa joitain tarkastuksia itse. Miksi keksiä pyörä uudelleen, käytetään niitä. Voit esimerkiksi tarkistaa, että verkkosivuston sivu on avautumassa tai palvelin pingaa. - Lähetä ilmoitukset ongelmista kiinnostuneille osapuolille.
- Valvontatietojen visualisointi, raporttien, kaavioiden ja tilastojen tuottaminen.
Lyhyt kuvaus ASMO-järjestelmästä
On parasta selittää esimerkillä. Katsotaanpa kuinka ASMO-järjestelmän suorituskyvyn seuranta on järjestetty.
ASMO on automatisoitu meteorologinen tukijärjestelmä. Järjestelmä auttaa tiehuollon asiantuntijoita ymmärtämään, missä ja milloin tie on käsiteltävä jäänestoaineilla. Järjestelmä kerää tietoja tievalvontapisteistä. Tievalvontapiste on tiellä oleva paikka, johon on asennettu laitteita: sääasema, videokamera jne. Vaarallisten tilanteiden ennustamiseksi järjestelmä vastaanottaa sääennusteita ulkoisista lähteistä.
Joten järjestelmän koostumus on melko tyypillinen: verkkosivusto, agentti, laitteet. Aloitetaan seuranta.
Järjestelmän hajottaminen osiin
ASMO-järjestelmässä voidaan erottaa seuraavat komponentit:
1. Henkilökohtainen tili
Tämä on verkkosovellus. Sinun on vähintään tarkistettava, että sovellus on saatavilla Internetissä.
2. Tietokanta
Tietokanta tallentaa raportoinnin kannalta tärkeät tiedot, ja sinun on varmistettava, että tietokannan varmuuskopiot luodaan onnistuneesti.
3. Palvelin
Palvelimella tarkoitamme laitteistoa, jolla sovellukset toimivat. On tarpeen tarkistaa HDD:n, RAM:n, CPU:n tila.
4. Agentti
Tämä on Windows-palvelu, joka suorittaa monia erilaisia tehtäviä aikataulussa. Sinun on vähintään tarkistettava, että palvelu on käynnissä.
5. Agenttitehtävä
Pelkkä tieto, että agentti toimii, ei riitä. Agentti voi työskennellä, mutta ei suorittaa sille määrättyjä tehtäviä. Jaetaan agenttikomponentti tehtäviin ja tarkistetaan, toimiiko jokainen agenttitehtävä onnistuneesti.
6. Tievalvontapisteet (kaikkien MPC:iden kontti)
Tievalvontapisteitä on monia, joten yhdistetään kaikki MPC:t yhteen komponenttiin. Tämä tekee seurantatietojen lukemisesta mukavampaa. Kun tarkastelet "ASMO system" -komponentin tilaa, on heti selvää, missä ongelmat ovat: sovelluksissa, laitteistossa vai maksimiohjausjärjestelmässä.
7. Tievalvontapiste (yksi enimmäisraja)
Pidämme tätä komponenttia huollettavana, jos kaikki tämän MPC:n laitteet ovat huollettavissa.
8. Laite
Tämä on videokamera tai sääasema, joka on asennettu enimmäispitoisuusrajalle. On tarpeen tarkistaa, että laite toimii oikein.
Valvontajärjestelmässä komponenttipuu näyttää tältä:
Verkkosovellusten valvonta
Joten, olemme jakaneet järjestelmän komponentteihin, nyt meidän on tehtävä tarkistukset jokaiselle komponentille.
Verkkosovelluksen valvontaan käytämme seuraavia tarkistuksia:
1. Pääsivun avauksen tarkistaminen
Tämän tarkistuksen suorittaa valvontajärjestelmä. Sen suorittamiseksi ilmoitamme sivun osoitteen, odotetun vastausfragmentin ja pyynnön enimmäissuoritusajan.
2. Verkkotunnuksen maksuajan tarkistaminen
Erittäin tärkeä tarkistus. Kun verkkotunnus jää maksamatta, käyttäjät eivät voi avata sivustoa. Ongelman ratkaiseminen voi kestää useita päiviä, koska... DNS-muutoksia ei oteta käyttöön välittömästi.
3. SSL-varmenteen tarkistaminen
Nykyään lähes kaikki verkkosivustot käyttävät https-protokollaa pääsyyn. Jotta protokolla toimisi oikein, tarvitset voimassa olevan SSL-varmenteen.
Alla on "Henkilökohtainen tili" -komponentti valvontajärjestelmässä:
Kaikki yllä olevat tarkistukset toimivat useimmissa sovelluksissa eivätkä vaadi koodausta. Tämä on erittäin siistiä, koska voit aloittaa minkä tahansa verkkosovelluksen seurannan 5 minuutissa. Alla on lisätarkistuksia, jotka voidaan suorittaa verkkosovellukselle, mutta niiden toteutus on monimutkaisempaa ja sovelluskohtaista, joten emme käsittele niitä tässä artikkelissa.
Mitä muuta voit tarkistaa?
Voit valvoa verkkosovellustasi täydellisemmin suorittamalla seuraavat tarkistukset:
- JavaScript-virheiden määrä jaksoa kohti
- Virheiden määrä verkkosovelluspuolella (taustajärjestelmässä) ajanjaksolla
- Verkkosovellusten epäonnistuneiden vastausten määrä (vastauskoodi 404, 500 jne.)
- Keskimääräinen kyselyn suoritusaika
Windows-palvelun valvonta (agentti)
ASMO-järjestelmässä agentti toimii tehtävien ajoittajana, joka suorittaa ajoitetut tehtävät taustalla.
Jos kaikki agenttitehtävät valmistuvat onnistuneesti, agentti toimii oikein. Osoittautuu, että agentin valvomiseksi sinun on seurattava sen tehtäviä. Siksi jaamme "Agentti"-komponentin tehtäviin. Luomme jokaiselle tehtävälle erillisen komponentin valvontajärjestelmään, jossa "Agentti"-komponentti on "emo".
Jaamme agenttikomponentin lapsikomponentteihin (tehtäviin):
Olemme siis jakaneet monimutkaisen komponentin useisiin yksinkertaisiin. Nyt meidän on tehtävä tarkistuksia jokaiselle yksinkertaiselle komponentille. Huomaa, että pääkomponentilla "Agentti" ei ole tarkistuksia, koska valvontajärjestelmä laskee sen tilan itsenäisesti alikomponenttien tilan perusteella. Toisin sanoen, jos kaikki tehtävät on suoritettu onnistuneesti, agentti toimii onnistuneesti.
ASMO-järjestelmässä on yli sata tehtävää, onko todella tarpeen keksiä jokaiselle tehtävälle ainutlaatuiset tarkistukset? Tietysti ohjaus onnistuu paremmin, jos keksimme ja toteutamme omat erityistarkistukset jokaiselle agenttitehtävälle, mutta useimmissa tapauksissa riittää yleisten tarkistusten käyttö.
ASMO-järjestelmä käyttää vain yleisiä tehtävien tarkistuksia ja tämä riittää valvomaan järjestelmän suorituskykyä.
Tarkistetaan edistymistä
Yksinkertaisin ja tehokkain tarkistus on suorituksen tarkistus. Tarkastus varmistaa, että tehtävä on suoritettu ilman virheitä. Kaikissa tehtävissä on tämä tarkistus.
Tarkista algoritmi
Jokaisen tehtävän suorituksen jälkeen sinun on lähetettävä SUCCESS-tarkistuksen tulos valvontajärjestelmään, jos tehtävän suoritus onnistui, tai VIRHE, jos suoritus päättyi virheellä.
Tämä tarkistus voi havaita seuraavat ongelmat:
- Tehtävä suoritetaan, mutta epäonnistuu virheen vuoksi.
- Tehtävä on pysähtynyt, esimerkiksi se on jäätynyt.
Katsotaanpa, kuinka nämä ongelmat ratkaistaan yksityiskohtaisemmin.
Ongelma 1 – Tehtävä suoritetaan, mutta epäonnistuu virheen vuoksi
Alla on tapaus, jossa tehtävä suoritetaan, mutta epäonnistuu klo 14:00 ja 16:00 välillä.
Kuvassa näkyy, että kun tehtävä epäonnistuu, signaali lähetetään välittömästi valvontajärjestelmään ja vastaavan tarkistuksen tila valvontajärjestelmässä muuttuu hälytykseksi.
Huomaa, että valvontajärjestelmässä komponentin tila riippuu varmennustilasta. Tarkistuksen hälytystila muuttaa kaikki ylemmän tason komponentit hälytykseksi, katso alla oleva kuva.
Ongelma 2 - Tehtävä lopetti suorittamisen (jäätynyt)
Miten valvontajärjestelmä ymmärtää, että tehtävä on jumissa?
Tarkistuksen tuloksella on voimassaoloaika, esimerkiksi 1 tunti. Jos tunti kuluu eikä uutta testitulosta ole, valvontajärjestelmä asettaa testin tilan hälytykseksi.
Yllä olevassa kuvassa valot sammutettiin klo 14. Kello 00:15 valvontajärjestelmä havaitsee, että testitulos (kello 00:14 alkaen) on mätä, koska Relevanssiaika on kulunut umpeen (yksi tunti), mutta uutta tulosta ei ole ja se vaihtaa hälytystilaan.
Klo 16 valot sytytettiin uudelleen, ohjelma suorittaa tehtävän ja lähettää suoritustuloksen valvontajärjestelmään, testitilasta tulee jälleen onnistunut.
Mitä tarkistuksen relevanssiaikaa minun pitäisi käyttää?
Relevanssiajan on oltava suurempi kuin tehtävän suoritusaika. Suosittelen asettamaan relevanssiajan 2-3 kertaa pidemmäksi kuin tehtävän suoritusaika. Tämä on tarpeen, jotta vältytään vääriltä ilmoituksilta, kun esimerkiksi tehtävä kesti tavallista kauemmin tai joku on ladannut ohjelman uudelleen.
Tarkistetaan edistymistä
ASMO-järjestelmässä on "Load Forecast" -tehtävä, joka yrittää ladata uuden ennusteen ulkoisesta lähteestä kerran tunnissa. Tarkkaa aikaa, jolloin uusi ennuste ilmestyy ulkoiseen järjestelmään, ei tiedetä, mutta tiedetään, että tämä tapahtuu 2 kertaa päivässä. Osoittautuu, että jos uutta ennustetta ei ole useaan tuntiin, niin tämä on normaalia, mutta jos uutta ennustetta ei ole yli vuorokaudelle, jokin on mennyt rikki. Esimerkiksi ulkoisen ennustejärjestelmän tietomuoto voi muuttua, minkä vuoksi ASMO ei näe uutta ennustejulkaisua.
Tarkista algoritmi
Tehtävä lähettää SUCCESS-tarkistuksen tuloksen valvontajärjestelmään, kun se onnistuu etenemään (uuden sääennusteen lataaminen). Jos edistystä ei tapahdu tai tapahtuu virhe, valvontajärjestelmään ei lähetetä mitään.
Tarkistuksella on oltava sellainen relevanssiväli, että tänä aikana se saa taatusti uuden edistymisen.
Huomioithan, että saamme tietää ongelmasta viiveellä, koska valvontajärjestelmä odottaa, kunnes viimeisen skannaustuloksen voimassaoloaika umpeutuu. Siksi sekin voimassaoloaikaa ei tarvitse tehdä liian pitkäksi.
Tietokannan seuranta
Hallitaksemme tietokantaa ASMO-järjestelmässä suoritamme seuraavat tarkistukset:
- Varmuuskopion luomista tarkistetaan
- Tarkistetaan vapaata levytilaa
Varmuuskopion luomista tarkistetaan
Useimmissa sovelluksissa on tärkeää, että tietokannan varmuuskopiot ovat ajan tasalla, jotta jos palvelin epäonnistuu, voit ottaa ohjelman käyttöön uudelle palvelimelle.
ASMO luo varmuuskopion kerran viikossa ja lähettää sen tallennustilaan. Kun tämä toimenpide on suoritettu onnistuneesti, onnistumistarkastuksen tulos lähetetään valvontajärjestelmään. Varmennustulos on voimassa 9 päivää. Nuo. Varmuuskopioiden luomisen ohjaamiseen käytetään "edistymisen tarkistus" -mekanismia, josta keskustelimme edellä.
Tarkistetaan vapaata levytilaa
Jos levyllä ei ole tarpeeksi vapaata tilaa, tietokanta ei voi toimia kunnolla, joten on tärkeää hallita vapaan tilan määrää.
On kätevää käyttää mittareita numeeristen parametrien tarkistamiseen.
Mittarit on numeerinen muuttuja, jonka arvo välitetään valvontajärjestelmään. Valvontajärjestelmä tarkistaa kynnysarvot ja laskee metrisen tilan.
Alla on kuva siitä, miltä "tietokanta"-komponentti näyttää valvontajärjestelmässä:
Palvelimen valvonta
Palvelimen valvontaan käytämme seuraavia tarkistuksia ja mittareita:
1. Vapaa levytila
Jos levytila loppuu, sovellus ei voi toimia. Käytämme kahta kynnysarvoa: ensimmäinen taso on VAROITUS, toinen taso on HÄLYTYS.
2. Keskimääräinen RAM-arvo prosentteina tunnissa
Käytämme tuntikeskiarvoa, koska... emme ole kiinnostuneita harvinaisista kilpailuista.
3. Keskimääräinen prosessoriprosentti tunnissa
Käytämme tuntikeskiarvoa, koska... emme ole kiinnostuneita harvinaisista kilpailuista.
4. Ping-tarkistus
Tarkistaa, että palvelin on online-tilassa. Valvontajärjestelmä voi suorittaa tämän tarkistuksen; koodia ei tarvitse kirjoittaa.
Alla on kuva siitä, miltä “Server”-komponentti näyttää valvontajärjestelmässä:
Laitteiden valvonta
Kerron kuinka tiedot saadaan. Jokaiselle tievalvontapisteelle (MPC) on tehtäväsuunnittelijassa tehtävä, esimerkiksi "Tutki MPC M2 km 200". Tehtävä vastaanottaa tietoja kaikista MPC-laitteista 30 minuutin välein.
Yhteyskanavan ongelma
Suurin osa laitteista sijaitsee kaupungin ulkopuolella, tiedonsiirtoon käytetään GSM-verkkoa, joka ei toimi vakaasti (verkko on tai ei ole).
Toistuvien verkkovikojen vuoksi MPC-kyselyn tarkistaminen seurannassa näytti aluksi tältä:
Kävi selväksi, että tämä ei ollut toimiva vaihtoehto, koska ongelmista tuli paljon vääriä ilmoituksia. Sitten päätettiin käyttää jokaiselle laitteelle "edistymisen tarkistusta", ts. Vain onnistumissignaali lähetetään valvontajärjestelmään, kun laite pollataan ilman virhettä. Relevanssiajaksi asetettiin 5 tuntia.
Nyt valvonta lähettää ilmoituksia ongelmista vain silloin, kun laitetta ei voida pollata yli 5 tuntiin. Suurella todennäköisyydellä nämä eivät ole vääriä hälytyksiä, vaan todellisia ongelmia.
Alla on kuva siitä, miltä laitteet näyttävät valvontajärjestelmässä:
Tärkeää!
Kun GSM-verkko lakkaa toimimasta, kaikkia MDC-laitteita ei pollata. Vähentääkseen valvontajärjestelmästä tulevien sähköpostien määrää, suunnittelijamme tilaavat ilmoituksia komponenttiongelmista, joiden tyyppi on "MPC" eikä "Device". Näin voit saada yhden ilmoituksen jokaisesta MPC:stä sen sijaan, että vastaanotat erillisen ilmoituksen jokaisesta laitteesta.
Lopullinen ASMO-valvontajärjestelmä
Laitetaan kaikki yhteen ja katsotaan millainen valvontajärjestelmä meillä on.
Johtopäätös
Tehdään yhteenveto.
Mitä ASMO:n suorituskyvyn seuranta antoi meille?
1. Vianpoistoaika on lyhentynyt
Olemme aiemmin kuulleet käyttäjiltä vioista, mutta kaikki käyttäjät eivät ilmoita vioista. Tapahtui, että saimme tietää järjestelmäkomponentin toimintahäiriöstä viikkoa sen ilmestymisen jälkeen. Nyt valvontajärjestelmä ilmoittaa meille ongelmista heti, kun ongelma havaitaan.
2. Järjestelmän vakaus on parantunut
Koska vikoja alettiin poistaa aikaisemmin, järjestelmä kokonaisuudessaan alkoi toimia paljon vakaammin.
3. Teknisen tuen puheluiden määrän vähentäminen
Monet ongelmat on nyt korjattu ennen kuin käyttäjät edes tietävät niistä. Käyttäjät alkoivat ottaa yhteyttä tekniseen tukeen harvemmin. Kaikella tällä on hyvä vaikutus maineeseemme.
4. Asiakas- ja käyttäjäuskollisuuden lisääminen
Asiakas havaitsi positiivisia muutoksia järjestelmän vakaudessa. Käyttäjät kohtaavat vähemmän ongelmia järjestelmän käytössä.
5. Vähennä teknisen tuen kustannuksia
Olemme lopettaneet manuaalisten tarkastusten suorittamisen. Nyt kaikki tarkastukset on automatisoitu. Aiemmin opimme ongelmista käyttäjiltä; usein oli vaikea ymmärtää, mistä ongelmasta käyttäjä puhui. Nyt suurimman osan ongelmista raportoi valvontajärjestelmä, ilmoitukset sisältävät teknisiä tietoja, joista käy aina selväksi mikä meni pieleen ja missä.
Tärkeää!
Et voi asentaa valvontajärjestelmää samalle palvelimelle, jossa sovelluksesi toimivat. Jos palvelin kaatuu, sovellukset lakkaavat toimimasta eikä kukaan voi ilmoittaa siitä.
Valvontajärjestelmän tulee toimia erillisellä palvelimella toisessa konesalissa.
Jos et halua käyttää dedikoitua palvelinta uudessa palvelinkeskuksessa, voit käyttää pilvivalvontajärjestelmää. Yrityksemme käyttää Zidium-pilvivalvontajärjestelmää, mutta voit käyttää mitä tahansa muuta valvontajärjestelmää. Pilvivalvontajärjestelmän hinta on edullisempi kuin uuden palvelimen vuokraaminen.
Suositukset:
- Pura sovellukset ja järjestelmät komponenttipuun muodossa mahdollisimman yksityiskohtaisesti, jotta on kätevää ymmärtää, missä ja mikä on rikki, ja ohjaus on täydellisempää.
- Testien avulla voit tarkistaa komponentin toimivuuden. On parempi käyttää useita yksinkertaisia tarkastuksia kuin yhtä monimutkaista.
- Määritä metriset kynnykset valvontajärjestelmän puolelle sen sijaan, että kirjoitat niitä koodiin. Tämä säästää sinua joutumasta kääntämään, määrittämään uudelleen tai käynnistämään sovellus uudelleen.
- Käytä mukautettuja tarkistuksia varten marginaalia, jotta vältytään vääriltä ilmoituksilta, koska joidenkin tarkistusten suorittaminen kesti tavallista kauemmin.
- Yritä saada valvontajärjestelmän komponentit muuttumaan punaisiksi vain silloin, kun ongelma on selvä. Jos ne muuttuvat punaisiksi turhaan, lopetat huomioimisen valvontajärjestelmän ilmoituksiin, sen merkitys katoaa.
Jos et vielä käytä valvontajärjestelmää, aloita! Se ei ole niin vaikeaa kuin miltä näyttää. Nauti itse kasvattamastasi vihreästä ainesosapuusta.
Onnea.
Lähde: will.com