SISTEM DE MONITORIZARE ȘI GESTIONARE A SITE-URILOR WEB [308356]

Universitatea Liberă Internațională din Moldova

SISTEM DE MONITORIZARE ȘI GESTIONARE A SITE-URILOR WEB

SYSTEM FOR MANAGEMENT AND MONITORING THE WEB SITES

Student: [anonimizat], TI- X

Conducător:

lector superior X

Chișinău 2020

Ministerul Educației al Republicii Moldova

Universitatea Liberă Internațională din Moldova

Facultatea x

Catedra x

Admis la susținere

Șef de catedră:

_______________________________

„____”_____________ 2020

Sistem de monitorizare și gestionare a site-urilor web

Teză de licență înTehnologii Informaționale

Student:_____________ (I. Panțîr )

Conducător: _( X )

Chișinău, 2020

AICI

Declarația de onestitate a masterand: [anonimizat]: Sistem de monitorizare și gestionare a site-urilor web

Student: [anonimizat], gr. TI- X

1. Actualitatea temei:Tema proiectului de master a fost selectată în conformitate cu cerințele pieței actuale de software. Aplicația a [anonimizat], cît și pentru dispozitive mobile.

2. Caracteristica tezei de master:Teza de master a fost elaborată în conformitate cu normele și standardele în vigoare. Proiectul a [anonimizat] a fost implementată conform tuturor cerințelor stabilite inițial.

3. Analiza prototipului: [anonimizat]. [anonimizat] a sistemului. Interfața grafică are un design plăcut și nu deranjează utilizatorul la folosirea acestuia.

4. Estimarea rezultatelor obținute: Analizând domeniul de aplicabilitate și urmînd indicațiile conducătorului proiectului, a [anonimizat]. Aplicația implementată corespunde normelor generale de realizare a tehnologiilor web și tuturor cerințelor specificate în capitolul de proiectare.

5. Corectitudinea materialului expus: Materialul prezentat a [anonimizat], subcapitole și paragrafe conform standardelor. [anonimizat].

6. Calitatea materialului grafic: [anonimizat], clare și reprezintă elementele de bază ale aplicației. [anonimizat].

7. Valoarea practică a tezei: [anonimizat], pune la dispoziție clienților notificări privind disponibilitatea serviciilor și a resurselor. Este un instrument necesar și accesibil mediului digital.

8. Observații și recomandări: [anonimizat] a satisface un cerc mai mare de utilizatori.

9. Caracteristica student: [anonimizat]: Student: [anonimizat], a respectat cerințele impuse și a manifestat profesionalism în perfectarea și calitatea tezei. [anonimizat] 10 (zece).

Conducătorul tezei de master: l.sup. X ___________

Adnotare

Această lucrare presupune o descriere amplă a aplicației ”monitoring de sistem”. Sarcina principală a aplicației este de a monitoriza serviciile web disponibile în rețeaua globală – internet și informarea clientului prin notificare în cazul în care serviciul cade sau se ridică. Clientul dispune de un panel comod de gestionare a sarcinilor, dar și care îi va permite manipularea de pe dispozitive mobile.

Monitoringul de accesibilitate acoperă un număr mare de protocoale larg răspîndite, dar permite și notificarea prin intermediul diferitor sisteme.

Pe lîngă sistemul de accesibilitate, mai există și sistemul de monitorizare a resurselor serverelor pe sistemul de operare Linux. Un agent instalat pe server îi va permite serverului de monitoringîntr-un interval de timp să depoziteze indicele resurselor principale, iar mai apoi clientul va puteaprelua anumite acțiuni în baza datelor statistice.

Proiectul îl putem defini prin următoarele cuvinte cheie: Monitoring, Website, disponibilitate, resursele serverului, protocoale, notificare, gestionare, statistică.

Abstract

This work represents a huge description of the application :" system monitoring". The main purpose of this application is to monitor the web services available in the global network and to inform the client through notification in case of low or up service.

The client is exposed to a convenient panel of segmentation of duties which will allow him to manipulate with it from any mobile device.

Monitorizing the accessibility covers a range of spread out protocols and it allows as well the notification throughout different systems. Despite the accessibility system, there is the monitoring system of servers resources on the Linux system of operation. An installed agent on the server will dispose the monitoring server with the indice of the main resources in a short time. Then, the client will be able to retake some actions on the basis of some data.

The project might be defined using the following key words: Monitoring, website, accessibility, the resources of the server, protocols, notification, segmentation, statistics.

INTRODUCERE

Astăzi am ajuns la etapa în care fiecare dispozitiv electronic este conectat la internet, astfel încît orice dispozitiv din casă poate fi gestionat de la distanță.

Fiecare dispozitiv setat corect poate să ne ajute semnificativ, și să ne facă viața mai sigură. Pe lîngă faptul că dispozitivul lucrează și își îndeplinește funcția sa, există cazuri în carealți factori crează dificultăți pentru ca acesta să-și execute funcționalitatea sa normală.

Fie că aveți un dispozitiv ce vă anunță prin mesaje sms despre scurgerea de gaze și încercarea de a închide robinetul în caz de scurgere.Însă, închiderea robinetului necesită energie electrică pentru a porni motorașul ce execută efortul de închidere.În caz că nu sunteți în apartament, nu puteți fi siguri că starea senzorului este în regim de verificare a scurgerii de gaz. Pentru aceasta se creeazăservicii de monitoring.Scopul loreste de a monitoriza funcționalitatea senzorilor, serviciilor, în vederea executării lucrului într-o formă stabilă.

În cazul unui accident, cînd nu sunt disponibili acești senzori, clientul va fi alertat ca în cel mai scurt timp să rezolve problema apărută.

Acest lucru este valabil pentru toate domeniile, dar mai ales este răspîndit în domeniul web.

Un factor important în aplicațiile web, pe lîngă calitatea acestuia, este disponibilitatea și mentenanța. Chiar dacă serviciile pentru găzduire web menționează o mentenanță destul de ridicată, ea nu poate asigura o alertare prealabilă a căderii site-ului din cauza lor, ca mai apoi soluționare rapidăsă fieridicarea pe un server străina site-ului personal. Un ajutor în rezolvarea problemei date este utilizarea monitoringului de disponibilitate, cît și de gestionare a resurselor proceselor în interiorul sistemului de operare.

Factorii ce pot duce la deconectarea sistemelorpot fi:

deteriorarea fizică a sistemului de hard;

viruși, atacuri cibernetice;

actualizarea de sistem cu erori neverificate;

resurse limitate ce cauzează căderea anumitor servicii;

eroarea resurselor umane;

căderea rețelei de internet, rețelei electrice.

Monitoringul va înștiința persoana responsabilă de aplicație, iar aceasta va rezolvaproblemacît mai curînd ca mai apoi să fie reinițiatăconexiunea cu lumea externă a aplicației web.

Pe lîngă notificare, mai este posibilitatea de a interacționacu alte sisteme ce va determinaîn mod automat comutarea vizitelor clienților la un alt server de rezervă.

Atunci cînd nivelul de disponibilitate pentru aplicația web ajunge într-o situație critică pentru business, nu este suficientă doar disponibilitatea acestuia.Doar un sistem de monitoring este puțin. Aici deja este necesar de a verifica aplicația web din mai multe puncte geografice, nu mai puțin de o dată pe minut (pentru a detecta la maxim problemele ce vizează legătura geografică)[1]. Drept criterii de verificare putem evedenția următoarele:

problemele cu DNS-serverele (cînd într-un anumit timp aplicația web nu poate fi accesată, pe cînd aplicația este disponibilă);

probleme cu răspunsul îndelungat (în legătură cu reînnoirea fișierilor temporare (cache) sau executarea cererilor complexe la nivel de server);

probleme de conexiune la baza de date;

probleme cu memoria fizică disponibilă;

probleme de conexiune la fișiere statice (legate cu infrastructura acestuia);

probleme la expedierea sau primirea scrisorilor electronice;

și altele.

Sistemele de monitoring nu par prea scumpe, dar au un rol important în mentenanța aplicațiilor web. Pentru o verificare, importanță unui site popular ce este bazat pe comenzi online, se poate calcula calcula printr-o formulă matematică simplă:calcularea profitului zilnic adus de site și prețul sistemului de monitoring în comparație cu prețul pierderii orelor în care site-ul nu este disponibil.

1 ANALIZA SITUAȚIEI ÎN DOMENIUL DE PROIECTARE

1.1 Avantajele sistemului

În orice proiect on-line este foarte importantă colectarea datelor statistice. Monitorizarea site-ului ajută la determinarea disponibilității resurselor. Aceste metode de culegere a informațiilor face mai marcată promovarea pentru dezvoltator.

Prin culegerea informațiilorse analizează creșterea și dezvoltarea website-ului. Controlul accesului și analiza erorilor resursei ceea ce va permite eliminarea problemelor principale și a erorilor de cod. Deci, dezvoltatorul va fi mereu asigurat de disponibilitatea și eficiența proiectului său.

Există mai multe tipuri de monitorizare.Există soluții gratuite simple pentru întreprinderi mici și o mare colecție de statistici pentru resurse mari. Fiecare resursă web are nevoie de un tip de monitorizare și va fi posibilăselectarea tipului potrivit pentru fiecare proiect în parte.

Selectarea unui sistem de monitorizare nu este dificilă, dacă aveți o idee despre parametrii de bază. Astfel, sistemul de monitorizare a site-urilor ar trebui să fie reprezentat, în primul rînd, de date exacte și fiabile, care sunt obținute prin teste repetate din diferite regiuni. De asemenea trebuie să fie configurațiile flexibile, să permită rularea pe mai multe site-uri, să fie permisă setarea propriei perioade de testare și o varietate de tipuri de notificări în caz de eșec a unei oarecare sarcini.

Sistemul de notificare flexibil trebuie să permită primirea mesajelor de alertă într-un mod cît mai eficient pe telefonul mobil sau pe e-mail. De asemenea, dacă este necesar, monitorizarea poate fi dezactivată temporar în timpul lucrărilor de întreținere. Atunci cînd lucrările asupra aplicației web sunt încheiate, monitorizarea trebuie să se inițieze în mod automat[2].

Un avantaj semnificativ este și salvarea tuturor datelor de monitorizare pe o perioadă destul de îndelungată și posibilitatea selectării perioadei într-un format comod ca mai apoi să fie analizate datele.

De asemenea, drept notificare poate servi o aplicație pe altă resursă ce va permite redirecționarea utilizatorilor pe o resursă temporară. În urma acestor acțiuni, pierderea utilizatorilor va fi stopată prin afișarea unor informații ce nu-lvor speria.Totodată se va diminua intenția de a părăsi resursa.

1.2 Necesitatea unui sistem de monitoring

Argumentul că sistemul de monitoring e util doar prin existența sa, e puțin.Acest sistem este o cerință pentru o bază operativă cînd aplicația cade fără avertisment. Un sistem de monitoring trebuie să execute notificareaîn timp foarte scurt după căderea serviciului ce este în verificare.

Un sistem puternic și flexibil de monitoring, pe baza datelor statistice, ne va permite optimizarea rețelelor și a serverelor pentru un folos econom a resurselor în viitor. Ne permite găsirea rapidă a problemelor apărute, ce a cauzat căderea unui oarecare serviciu, precum și realizarea într-un timp scurt a problemei apărute[3].

La crearea și administrarea oarecărui site, trebuie să înțelegem ce sarcini își impune proiectul. Toate proiectele web se deosebescdupă mărime.

Mărimea acestora depinde de mulți factori, precum:

Bugetul. Suma alocată de creatorul site-ului și activitatea sa de promovare.

Mărimea auditoriului. Există resurse extrem de specializate, care sunt create pentru un număr mic de experți sau membri ai unor grupuri.

Nivelul dorit de creștere. Acest indice este prioritar.În general nu există limită pentru popularitatea proiectului web.

Metoda de promovare. Cel mai frecvent utilizat este promovarea în motoarele de căutare, dar unele site-uri preferă să găsească alte surse de vizitatori.

Capacitatea de a crea noi subiecte sau de a extinde subiectele existente. Uneori, creatorul proiectului este supus de a adăuga la site mai multe ramuri tematice, pentru a crea o universalitate mai largă.

Vom încerca să înțelegm toate aceste puncte în detalii. Deci, putem înțelege ce este dimensiunea unui site. Astfel, ajungem mai aproape de subiect și putem deducepentru ce avem nevoie de sistemul de monitoring.

Bugetul

Cel mai important lucru în orice afacere este bugetul. Cînd creați un nou proiect web, totul depinde de suma de bani care vafi investită.

Să încercăm să explicăm un exemplu adeseaîntîlnit – atunci cînd creatorul site-ului duce lipsa financiară și mai mult pune accent pe forțele personale decît pe achiziționarea de servicii.

Un astfel de proiect poate fi numit mic. Pentru promovarea acestuia va lua timp. Totul începe cu crearea unei platforme pentru a delibera viitorul site.

În timpul creării, trebuie foarte bine de testat sistemul cu toate modulele și template-urile necesare, astfel încît să putem elimina imediat bug-urile și deficiențele.

La testare va fi util punctul de vedere al unei alte persoane.Se poate de prezentat site-ul încă închis la nivel de confortabilitate și proiectare acelei persoane. Sistemul de monitoring nu este necesar dacă proiectul încă nu este pornit.Acest intrument este necesar pentru stocarea informațiilor despre stabilitatea resursei.

În timpul creării proiectului și lucrului îndelungat asupra lui, viziunea dezvoltatorului poate fi părtinitoare.În acest caz, el nu poate să observe probleme deschise, care se află la suprafață.

Este necesar să nu fie încărcat site-ul cu multă funcționalitate.Pentru un blog nu este nevoie de forum, iar pentru un magazin on-line, pentru început, nu trebuie aplicații flash complexe pentru întreținerea sistemului.

Utilizatorilor le place simplitatea, iar motoarelor de căutare – viteza de încărcare. Prioritar ar fi designul și disponibilitatea informației. Funcționalități suplimentare pot fi adăugate atunci cînd acestea vor fi necesare.

Într-un astfel de proiect mic, sistemul de monitoring nu are un rol important, dar va fi mai bine dacă se va lua în seamă accesibilitatea acestuia.

Pentru un așa proiect tînăr nu este nevoie de a comanda pachete la cele mai scumpe tarifecare vorverifica sistemulla fiecare cîteva secunde. Este suficient dea vizita de cîteva ori pe zi pentru verificarea funcționalității acestuia.

Dacă serios se va ocupa depromovarea proiectului, ar fi posibil de utilizat și gratis sisteme de monitoring. Serviciul va verifica proiectul după o limită de opțiuni ce potfi destule pentru început.

În sistemul de monitoring minimalist se includ:

disponibilitatea paginei;

afișarea corectă și disponibilitatea erorilor;

numărul de vizite.

Acest pachet se poate de executat o dată pe zi. Programul va scana toate punctele și veți primi un raport detaliatpe poșta electronică sau pe un oarecare internet-mesenger.

Veți fi imediat înștiințat de starea resurseidacă este în lucru sau dacă a fost găsită vreo eroare. După primireaalertei, vă veți putea ocupa de rezolvarea acestuia. În așa mod, dvs veți fi sigur că monitoringul de disponibilitate a fost efectutat cu succes și funcționează stabil.

Numărul de vizitatori este mai curîndun bonus frumos pentru analiză. Această cifră nu este obligatorie, dar multordezvoltatori începători le este plăcută această opțiune, de aceea și figureazăîn listă.

Mărimea auditoriului

Unul și același subiect, în general, nu poate fi interesant pentru absolut toate persoanele. Prin urmare, resursele online încearcă să ia numai unul sau cel mult cîteva tematici profunde.

Cu cît mai mult efort va fi concentrat la promovarea resursei de către un nucleu semantic, cu atît mai multe rezultate vaaduce această optimizare. Nucleul semantic, în cuvinte simple, este o scurtă formulare tematică în format de cerere de căutare.

Nucleul semantic este disponibil atît pentru site, cît și pentru un bloc tematic a articolului. Ca exemplu, utilizînd cuvintele de căutare “urși albi”, în nucleul semantic este posibil de introdus “urs” și “alb”.

Numărul cheilor tematice de intrare poate varia de la zeci la sute. Totul depinde de cantitatea de concurență și popularitatea acestuia.

În această situație, o monitorizare unică a site-urilor concurenților va fi utilă pentru a cunoaște popularitatea resurselor lor.

Dacă doriți cu adevărat să aduceți site-ul în partea de sus a tuturor cererilor de căutare după cuvintele “urs alb”, se va face simplu, deoarece acest subiect nu este comercial și nu poartă scopul de a vinde sau de a cumpăra.

Dar dacă doriți să promovați cheile “vînzarea apartamentelor”, atunci dificultatea va fi mare, deoarece tema dată este destul de aglomerată de concurenți. Este important să înțelegem ce public dorim.

Bazîndu-ne pe exemplul de mai sus, putem spune că prima variantă va fi destinată unui public restrîns, dar nu aveți nevoie de mult efort pentru a promova. Cea de-adoua variantă implică un număr mare de vizite și reclamă.

În al doilea caz, pentru a ridica site-ul pe anumite chei de căutare, va fi dificil, deoarece în afară de cîștigurile online în formă de publicitate și de vînzare a link-urilor, se poate presupune că resursa face activități în afara Internetului.

Deci, site-uri similare din această nișă vor investi mult mai mulți bani și va fi nevoie dedepuneri mari de efort pentru promovare.

Sistemulde monitoring are aceeași poziție de prioritate ca și în exemplulprecedent. Dar să încercăm să ne imaginăm un proiect mare și vom analiza problemele pe care aceste și le propune pentru a le rezolva. Vom lua ca exemplu un proiect popular de vînzări a apartamentelor.

Acestafuncționează pe principiul unui site plătit pentru anunțuri. El lucrează prioritar cu agențiile mari, verificarea integrității și fiabilitatea lor. Ca răspuns, oferindu-le lor clienți și vizualizarea anunțurilor lor.

Numărul zilnic de vizitatori unici pe această resursă este de aproximativ 30-40 de mii. Această resursă este destul de mare, astfel un sistem de monitoring de tip gratis nu ar face față acesteia.

Analiza complexă de date care are nevoie de această resursă:

se calculează greutatea de pagini și de rating CY și PR;

numărul de pagini care sunt deja indexate;

determinarea poziției unui site după interogări principale;

numărul de vizite;

verificarea disponibilității;

analiza fișierilor de loguri;

verificarea erorilor, analiza paginilor și eșecurilor.

Dacă există o problemă pe site, aceasta trebuie să fie rezolvată cît mai curînd. Pentru un astfel de proiect, o oră de nefuncționare este foarte scumpă. Timp de o oră, ratele de respingere vor fi mari. Acest lucru este foarte important, motoarele de căutare iau în seamă acești indicatori pentru a le clasa în top.

Rata de respingere – numărul de utilizatori care părăsesc pagina îndată ce o descarcă. Acesta este un alt instrument în analiza paginilor la roboții motoarelor de căutare. Pentru a evita pierderea de poziții, trebuie de monitorizat în mod regulat accesul la site.

Ea devine în mod automat un program care poate fi descărcat și personalizat de tine sau puteți comanda serviciul de la companiile respective. Într-un astfel de proiect mare ar fi ideal pentru a monitoriza disponibilitatea dată la fiecare 10 secunde.

Există mai multe standarte de periodicitate:

o dată pe zi;

2 ori pe zi;

o dată pe oră;

la fiecare 10 minute;

verificarea la fiecare 10 secunde.

Cu cît mai mareeste publicul site-ului și numărul utilizatorilor online, cu atît mai destrebuie efectuate verificări de disponibilitate. În cazul în careresursa nu va fi disponibilă pe parcursul unei ore, pierderele vor fi de cîteva mii de vizitatori.Aceasta este o rată foarte mare de respingere, iar riscul de a pierde pozițiile sunt foarte mari. Pentru a verifica site-ul, ar fi bine de monitorizat și pozițiile în motoarele de căutare, astfel să fie posibil de vizualizat schimbările la rezultate. Aceasta va arăta rapid modificările după lucrările de optimizare.

Nivelul dorit de creștere

De regulă, majoritatea resurselor nu au un limităde dezvoltare, lucrează dupăprincipiul “cu cît mai mult, cu atît mai bine”. Este vorba de public și numărul de vizitatori. Aceste site-uri, în general, sunt îndreptate sub un anumit tip de venituri asociate cu publicitatea sau vînzări de link-uri.

Dar, există și alte tipuri de proiecte în internet. Uneori, dezvoltatorii se bazează la un anumit public, care este foarte limitat. În acest caz, metoda de promovare poate fi foarte diferităde cea tradițională.

Metoda “Tradițională” este numită promovarea în motoarele de căutare. Pînă în prezent, popularitatea lor rezidă în faptul că peste 90% de vizitatori au parvenit datorită motoarelor de căutare. Pentru majoritatea proiectelor, această metodă este cea mai potrivită.

În această secțiune vom încerca să ne ocupăm de situația în care toate standardele nu sunt adecvate. Fie, de exemplu, site-ul companiei, care vinde echipamente de prelucrare a lemnului industrial.

Care este publicul site-ului în cazul în care este limitată de țările din CSI. Pe de o parte, numărul de membri interesate din țările vorbitoare de limba rusă va fi minime, dar suficiente pentru companie.

Dacă vom lua exemplul precedent, în care site-ul avea zilnic aproximativ 30-40 mii de vizitatori, pentru a atinge acest lucru, în acest exemplu nu va funcționa în nici un fel.

Prin urmare, nu este necesar de stabilit niște obiective ireale.Mult mai bine ar fi de evaluat gradul așteptatde popularitate a site-ului.

Promovarea pentru site-ul dat va fi mai mult concentrat pe publicitate și recunoașterea numelui firmei. Suntde evedențiat și motoarele de căutare.Companiile de toate dimensiunile oricum folosesc motoarele de căutare.

Concurența la cererea de acest tip pot fi foarte diferită, totul depinde de faptul pe care țară sau regiune optați mai mult și cît e de mare concurența la acest produs sau serviciu.

Înainte de a începe campania de promovare a site-ului, ar trebui să fie creat un raport de analiză a pozițiilor site-urilor concurenților săi, pentru a înțelege în mod clar cu cine veți concura mai mult. Pe baza acestor factori, în continuare se va desfășura procesul de promovare. Cel mai bine este să începeți cu motoarele de căutare.

Putem combina mai multe elemente obligatorii de promovare. De exemplu, cumpararea link-urilor pe site-uri cu tematica asemănătoare, pe care ar putea fi un potențial client.

Prin această metodă puteți nu doar să măriți indicele de performanță CY și PR, dar și de a face publicitate resurselor personale.

Pentru așa tipuri de proiecte, un punct important este stabilitatea lucrului resursei, deoarece calitatea site-ului este fața companiei în ochii potențialilor clienți.

Pentru un astfel de site este adecvată lista de monitorizare din secțiunea precedentă, cu toate acestea, un număr mai puțin important este numărul de vizualizări a site-ului.

În orice caz, pentru companiesunt importante comenzile. De multe ori în astfel de chestiuni se bazează mai mult pe numărul de apeluri sau e-mail-uri decît pe numărul de utilizatori unici.

Capacitatea de a crea noi sau extinde subiecte existente

Să detaliezămun caz, cînd propunerea serviciului sau a produsului este ceva revoluționar și nou. Ca exemplu, un site, care este destinat pentru vînzarea dispozitivelor “D”.

De această invenție încă nu cunoaște nimeni, dar va fi interesant pentru aproape toată lumea, acest dispozitiv este universal. Promovarea resurseicu cuvintele cheie “cumpăr dispozitivul “D”” nu are sens.Oamenii pur și simplu nu știu ce reprezintă dispozitivul ”D”

În astfel de situații, se crează un bloc sau o resursă, iar pe aceasta se crează o secțiune separată cu o descriere și cu alte materiale explicative despre acest dispozitiv “D”. Ca exemplu: dispozitivul ”D” este proiectat pentru economisirea energiei electrice.

Prin gîndire logică simplă, putem spune că acest dispozitiv va fi deosebit de interesant pentru cei care sunt interesați să economisească energia electrică sau se ocupă cu instalarea energiei electrice.

Se crează un nucleu semantic pe economiile de energie și tot în legătură cu aceasta pînă la instalarea de rețele electrice.

Creăm un conținut unic pe interogările de căutare populare în acest domeniu și în fiecare text se înscrie un link-cheie la pagina cu descrierea dispozitivului ”D”.

Prin urmare, vom promova un nou dispozitiv, în plus oferind utilizatorilor informații necesare de interes și informații cu privire la dispozitivul nostru. A fost rezolvată problema cu lipsa de popularitate a interogării de căutare, alipind aceasta la un miez semantic des folosit.

Este foarte important să știm cum variazăprogresul la promovarea produsului dat și devine el popular sau nu. Pentru aceasta se va folosi sistemul de monitoring a site-ului.

Principalele date din acest proiect vorfi următoarele:

monitorizarea poziției site-ului;

monitorizarea numărului de pagini indexate;

monitorizarea de rating CY și PR;

monitorizarea numărului de vizite unice pentru fiecare secțiune;

monitorizarea disponibilătății site-ului.

Pe lîngă faptul că vom verifica site-ul de erori și disponibilitatea acestuia, este foarte important de a aduna informații despre cît de des este căutat și cît de bine s-a progresat în domeniul promovării.

Obiectivul principal este promovarea proiectului.Pentru aceasta dezvoltăm o temă similară pe portal pentru a obține treceri și vizite. Această metodă este deseori folosită pentru a face publicitate produselor noi.

Sistemul de monitoring deține un rol important, arătînd eficacitatea acțiunilor de promovare.

2 ASPECTE TEORETICE ȘI METODOLOGICE ÎN DOMENIUL DE PROIECTARE

Pentru a pătrunde în esența proiectului”sistem de monitoring”, este necesar de a cunoaște noțiunile de bază ce vor fi folosite în acest raport.

Proiectul este destinat pentru verificarea diferitor servicii ce utilizează protocoale la accesibilitate. Întrucît fiecare protocol diferă multde celelalte, trebuie să le trecem în revistă pe fiecare în parte.

2.1 Protocoale de rețea

Protocolul HTTP

Hypertext Transfer Protocol (HTTP) este metoda ceamai des utilizată pentru accesarea informațiilor în Internet care sunt păstrate pe servere World Wide Web (WWW). Protocolul HTTP este un protocol de tip text, fiind protocolul "implicit" al WWW. Adică, dacă un URL nu conține partea de protocol, aceasta se consideră ca fiind http. HTTP presupune că pe calculatorul de destinație se rulează un program care înțelege protocolul. Fișierul trimis la destinație poate fi un document HTML (abreviație de la HyperText Markup Language), un fișier grafic, de sunet, animație sau video, de asemenea un program executabil pe server-ul respectiv sau un editor de text. Laclasificarea după modelul de referință OSI, protocolul HTTP este un protocol de tipaplicație. Realizarea și evoluția sa este coordonată de către World Wide Web Consortium (W3C).

HTTP oferă o tehnică de comunicare prin care paginile web se pot transmite de la un computer aflat la distanță spre propriul computer. Dacă se apelează un link sau o adresă web, cum ar fi http://www.example.com, atunci se cere calculatorului un host pentru a afișa o pagină web (index.html sau altele). În prima fază numele (adresa) www.example.com este convertit de protocolul DNS (în continuare va fi descris protocolul dat) într-o adresă IP. Urmează transferul prin protocolul TCP pe portul standard 80 al serverului HTTP, ca răspuns la cererea HTTP-GET. Informații suplimentare ca de ex. indicații pentru browser, limba dorită ș.a. se pot adăuga în header-ul (antetul) pachetului HTTP. În urma cererii HTTP-GET urmează din partea serverului răspunsul cu datele cerute, ca de ex.: pagini în (X)HTML, cu fișiere atașate ca imagini, fișiere de stil (CSS), script-uri (Javascript), dar pot fi și pagini generate dinamic (SSI, JSP, PHP și ASP.NET). Dacă dintr-un anumit motiv informațiile nu pot fi transmise, atunci serverul trimite înapoi un mesaj de eroare. Modul exact de desfășurare a acestei acțiuni (cerere și răspuns) este stabilit în specificațiile HTTP.

Protocolul FTP

Protocolul pentru transfer de fișiere (sau FTP, din engl. File Transfer Protocol) este un protocol (set de reguli) utilizat pentru accesul la fișiere aflate pe servere din rețele de calculatoare particulare sau din Internet. FTP este utilizat începînd de prin anul 1985, fiind foarte răspândit și actualmente. Numeroase servere de FTP din toată lumea permit conectare la ele de oriunde prin intermediulInternetului, iar fișierele plasate pe ele pot fi apoi transferate (încărcate sau descărcate). Web-ulnu aduce aici mari schimbări, ajută doar ca obținerea fișierelor să se realizeze mai ușor, având o interfață mai prietenoasă decât aplicațiile (programele) de FTP. Este posibilă accesarea unui fișier local prin adresa sa URL, ca și la o pagină de Web, fie utilizând protocolul "file" (fișier), fie utilizând calea și numele fișierului. Această abordare este similară utilizării protocolului FTP, dar nu necesită existența unui server. Desigur funcționează numai pentru fișiere locale.

Protocolul IMAP

Protocolul de Acces la Mesaje Internet (în engleză Internet Message Access Protocol, abreviat IMAP – denumit și Interactive Mail Access Protocol) permite accesul la mesaje din mapede e-mail de pe un server. Spre deosebire de POP3, care este proiectat pentru a transfera și a șterge e-mail-urile de pe server, scopul IMAP este de a le stoca pe toate pe server, pentru a putea fi oricând accesate din orice loc.

Internet Message Access Protocol (denumit uzual IMAP) este un protocol de nivel aplicație ce permite unui client accesul la e-mail pe un server de mail. Versiunea curentă, IMAP versiunea 4, revizia 1 (IMAP4rev1) este definită de RFC 3501. Un server IMAP poate asculta pe portul de contact 143. IMAP peste SSL (IMAPS) are asociat portul de contact 993.

Protocolul POP3

POP3 sau Protocolul Post Office – Versiunea 3 este, alături de IMAP, unul din protocoalele utilizate de un calculator gazdă pentru recepționarea poștei electronice (e-mail).

Cu siguranță, tipurile nodurilor mai mici în Internet deseori nu sunt practice să întrețină un sistem de transport al mesajului (MTS). De exemplu, o stație de lucru poate să nu dispună de suficiente resurse (spațiu pe disc) cu scopul de a permite un server SMTP RFC 821 și asociază un sistem local de trimitere mail pentru a fi ținut rezident și să ruleze continuu. Similar, poate deveni costisitor (sau imposibil) să menții un computer interconectat la un IP-style rețea pentru un interval mai mare de timp (nodul duce lipsă de resursa cunoscută ca “conectivitate”). În ciuda acestora, deseori este foarte util să deservești poșta acestor noduri mai mici și deseori sprijină un utilizator agent (UA) să ajute la gestionareapoștei electronice. Pentru a rezolva această problemă, un nod care întreține o entitate MTS oferă un serviciu maildrop pentru aceste noduri înzestrate mai puțin. POP3 a intenționat să permită unei stații de lucru acces dinamic la maildrop de pe un server gazdă într-un mod util. De obicei, aceasta înseamnă că protocolul POP3 este utilizat pentru a permite unei stații de lucru să primească poșta pe care serverul o stochează. POP3 nu a intenționat să furnizeze operații extinse de manipulare a poștei de pe server. În mod normal poșta este descărcată de pe server și apoi ștearsă. Un protocol mai avansat (și mai complex), IMAP4, a fost discutat în RFC 1730. În continuare, termenul “client gazdă” (client host) se referă la o gazdă ce utilizează serviciul POP3, iar termenul “server gazdă” (server host) se referă la o gazdă care oferă serviciul POP3.

Protocolul SMTP

Simple Mail Transfer Protocol (prescurtat, SMTP; în traducere aproximativă Protocolul simplu de transfer al corespondenței) este un protocol simplu, folosit pentru transmiterea mesajelor în format electronic pe Internet. SMTP folosește portul de aplicație 25 TCP și determină adresa unui server SMTP pe baza înregistrării MX (Mail eXchange, „schimb de corespodență”) din configurația serverului DNS.

Protocolul SMTP specifică modul în care mesajele de poștă electronică sunt transferate între procese SMTP aflate pe sisteme diferite. Procesul SMTP care are de transmis un mesaj este numit client SMTP iar procesul SMTP care primește mesajul este serverul SMTP. Protocolul nu se referă la modul în care mesajul ce trebuie transmis este trecut de la utilizator către clientul SMTP, sau cum mesajul recepționat de serverul SMTP este livrat utilizatorului destinatar și nici cum este memorat mesajul sau de câte ori clientul SMTP încearcă să transmită mesajul.

Protocolul ICMP

Internet Control Message Protocol (abreviat ICMP) este un protocol din suita TCP/IP care folosește la semnalizarea și diagnosticarea problemelor din rețea. Protocolul este definit in RFC792. Mesajele ICMP sunt încapsulate în interiorul pachetelor IP. Versiunea ICMP ptr IPv4 este adesea cunoscuta ca ICMPv4; in schimb IPv6 dispune de un protocol similar cunoscut sub abrevierea ICMPv6.

Probabil cele mai utilizate programe care se bazează pe ICMP sunt ”ping” și ”traceroute”.

”Ping” trimite mesaje ICMP de tip echo request ("cerere de ecou") către calculatorul țintă și așteaptă de la acesta mesaje ICMP de tip echo reply ("răspuns de tip ecou"). Dacă acestea nu sunt primite, se poate presupune că ceva este în neregulă cu conexiunea dintre cele două calculatoare.

Toate pachetele IP au în antet un câmp special numit TTL (Time To Live). Acest câmp este decrementat de fiecare dată când trece printr-un ruter. Pentru a evita buclele de routare, în momentul în care câmpul TTL ajunge la zero pachetul nu este trimis mai departe. În această situație, router-ul care a decrementat câmpul TTL la zero trimite către calculatorul-origine al pachetului (adresa acestuia se află tot în prologul IP) un mesaj ICMP de tip ”time exceeded”. Programul ”traceroute” profită de acest mecanism și trimite către calculatorul țintă, pachete UDP cu valori ale câmpului TTL din ce în ce mai mari, cu scopul de a obține mesaje ”time exceeded” de la toate routerele aflate pe traseu.

Baza de date MySQL

MySQL este un sistem de gestiune a bazelor de date relaționale, produs de compania suedeză MySQL AB și distribuit sub Licența Publică Generală GNU. Este cel mai popular SGBD open-source la ora actuală, fiind o componentă cheie a stivei LAMP (Linux, Apache, MySQL, PHP).

Deși este folosit foarte des împreună cu limbajul de programare PHP, cu MySQL se pot construi aplicații în orice limbaj major. Există multe scheme API disponibile pentru MySQL ce permit scrierea aplicațiilor în numeroase limbaje de programare pentru accesarea bazelor de date MySQL, cum are fi: C, C++, C#, Java, Perl, PHP, Python, FreeBasic, etc., fiecare dintre acestea folosind un tip specific API. O interfață de tip ODBC denumită MyODBC permite altor limbaje de programare ce folosesc această interfață, să interacționeze cu bazele de date MySQL cum ar fi ASP sau Visual Basic. În sprijinul acestor limbaje de programare, unele companii produc componente de tip COM/COM+ sau .NET (pentru Windows) prin intermediul cărora respectivele limbaje să poată folosi acest SGBD mult mai ușor decât prin intermediul sistemului ODBC. Aceste componente pot fi gratuite (ca de exemplu MyVBQL) sau comerciale.

Pentru a administra bazele de date MySQL se poate folosi modul linie de comandă sau, prin descărcare de pe internet, o interfață grafică: MySQL Administrator și MySQL Query Browser. Un alt instrument de management al acestor baze de date este aplicația gratuită, scrisă în PHP, phpMyAdmin.

MySQL poate fi rulat pe multe dintre platformele software existente: AIX, FreeBSD, GNU/Linux, Mac OS X, NetBSD, Solaris, SunOS, Windows 9x/NT/2000/XP/Vista.

DNS Server

Un sistem de nume de domeniu (abreviat DNS, în engleză Domain Name System) este un sistem distribuit de păstrare și interogare a unor date arbitrare într-o structură ierarhică. Cea mai cunoscută aplicație a DNS este gestionarea domeniilor în Internet.

Caracteristicile sistemului de nume (DNS) sunt:

folosește o structură ierarhizată;

deleagă autoritatea pentru nume;

baza de date cu numele și adresele IP este distribuită.

Fiecare implementare TCP/IP conține o rutină software (name resolver) specializată în interogarea serverului de nume (DNS) în vederea obținerii translatării nume/adresă IP sau invers.

Tipic, procesul de rezoluție a numelor se desfășoară astfel:

Name resolverprimește de la o aplicație client TCP/IP un nume; acesta formulează o interogare primului server de nume din lista serverelor;

Serverul de nume DNS determină daca este mandatat (autorizat) pentru domeniul respectiv (dacă există configurată o zonă DNS care conține numele respectiv);

Dacă este autorizat, transmite răspunsul clientului;

Dacă nu, transmite o interogare altui server de nume pentru un răspuns autorizat; obține răspunsul autorizat și transmite clientului un răspuns neautorizat; totodată stochează răspunsul local pentru a răspunde la alte cereri pentru același nume.

Resolverul de nume transmite răspunsul aplicației utilizator și îl păstrează într-un cache pentru o anumită perioadă;

Dacă name resolverul nu primește un răspuns într-un anumit timp, transmite cererea următorului server de nume din listă. Când lista este epuizată, va genera o eroare.

Disponibilitatea link-urilor conform regulilor SEO

Optimizare pentru motoare de căutare sau Search Engine Optimization (SEO), este un proces de perfecționare (favorizare) a vizibilității site-urilor web sau paginilor web în cadrul ordonării rezultatelor căutării în lista făcută de motorul de căutare. SEO este o subcategorie a marketing-ului online SEM, practică apărută în anul 1990, odată cu apariția primelor site-uri pe Internet, și care reprezintă totalitatea tehnicilor prin care un site web este adus la o formă în care este propulsat mai sus în lista de rezultate date de un motor de căutare pentru diverse cuvinte-cheie. Cu timpul, optimizarea unei pagini web a unui site a devenit un serviciu oferit de unele companii și/sau corporații.

Datorită acestei metode, serviciul ne va permite:

să verificăm dacă un anumit link este disponibil pe anumite pagini;

să fie verificat dacă pagina nu este închisă pentru motoarele de căutare (noindex, nofollow, robots.txt, ș.a.);

primirea notificărilor cînd este nevoie de prelungit;

păstrarea informației de prețul link-ului;

vizualizarea statisticii de schimbări a PR (Google) și CY (Yandex) pentru site-urile unde sunt amplasate link-urile.

2.2 Tipuri de notificări

Pentru serviciile de verificare este neapărat și serviciul de notificări.

Notificarea pe client prin metoda disponibilă lui îi face un comfort la utilizarea acestui serviciu. Un punct forte la selectarea sistemului de monitoring pentru resursa personală este tipurile de notificări. De aceea sunt servicii ce oferă notificări tot mai des și utilizînd diferite web mesengere ca: skype, viber, whatsapp, ICQ, telegram, jabber.

Omul în mare parte mai mult preferă ca obiectele din jur să fie compatibile după confortul lui, dar nu invers. De aceea, dacă în sistemul dat nu va fi un tip de notificare ce nu îi va fi confortabil unui anumit utilizator, pe acești utilizatori ca clienți pe viitor deja nu le vom putea număra.

Acest capitol de notificări este ușor extensibil din cauza că scopul oarecărui tip de notificare este să fie anunțat clientul despre căderea sau ridicarea resursei personale.

Tipuri posibile de notificări pe lîngă mesengere sunt:

E-Mail;

SMS;

Apel telefonic;

Push service;

RSS;

accesarea unui link anterior predefinit prin protocolul HTTP;

apelarea unei comenzi pe serverul îndepărtat prin SSH.

Principalul scop a sistemului de monitoring, este ca notificarea să fie cît mai rapidă, este un factor la fel de prioritar la alegerea sistemului de monitoring.

3 REZULTATE PRACTICE ȘI METODOLOGICE ÎN DOMENIUL DE PROIECTARE

3.1 Proiectarea sistemului

3.1.1 Specificarea cerințelor

Pentru specificarea cerințelor vor fi aplicatediagramele cazurilor de utilizare, care reprezintă funcționalitățile sistemului în întregime sau specifică funcționalitățile detaliate pentru un anumit modul al unui sistem. Diagrama cazurilor de utilizare, din figura 3.1, reprezintă, în mod general, funcționalitățileaplicației. Aplicația este construită pe platformă web, framework-ul Laravel, în limbajul PHP cu conexiune la baza de date MySQL. Utilizatorul are posibilitate în aplicația dată să folosească următoarele funcții:

monitorizarea protocolului HTTP(s);

monitorizarea protocolului FTP;

monitorizarea protocolului MySQL;

monitorizarea protocolului POP3;

monitorizarea protocolului SMTP;

monitorizarea protocolului IMAP;

monitorizarea protocolului DNS;

monitorizarea protocolului IMCP (Ping);

moitorizarea prezenței link-ului pe un site oarecare;

monitorizarea expirării domenului;

monitorizarea resurselor serverului pe Linux;

setarea metodelor de alertare sms, email, wget;

sistemul de parteneriat;

crearea sistemului personal utilizînd accesul API.

Figura 3.1 – Diagrama cazurilor de utilizare afișînd posibilitățile clientului

Pentru implementarea acestor cerințe, a fost creat sistemuldestul de avansat pentru o simplă lărgire orizontală a serverelor odată cu creșterea numărului clienților și a cererilor de monitorizare.

Clientului îi este disponibilă utilizarea într-un mod foarte simplu, dar în același timp și foarte flexibil.

3.1.2 Structura aplicației

Aplicația va fi creată prin interacțiunea diferitor noduri cu executarea fiecărui nod a sarcinilor personale. Utilizatorul în primul rînd va avea contact cu site-ul principal, unde va putea efectua înregistrarea și, respectiv, introducerea datelor pentru monitorizarea resurselor personale.

Structura aplicației este prezentată în figura3.2, prin următoarele elemente:

website-ul, baza de date și sistemul de notificări – acest nod răspunde de interacțiunea cu utilizatorul, sistemulde billing și sistemulde notificări prin sms, email și cerere HTTP GET;

serverul task manager– acest nod răspunde degestionarea sarcinilor de către serverele de execuție;

servere de execuție 1 .. n –execută sarcina expediată de către serverul task manager.

Figura 3.2 – Structura aplicației

WebSite, baza de date și sistemulde notificări

Acest nod are dreptscop interacțiunea cu utilizatorul. Aici sunt incluse sistemulde notificări, sistemulbilling și gestionarea sarcinilor din contul personal.

În cazul în care se creează un cont în sistem, iar apoi se gestioneazăbalanța cu o sumă suficientăde a manipula cu sarcinile date, clientul va putea adăuga o sarcină pentrua monitoriza resursa sa la disponibilitate.

La setarea sarcinii de monitorizare, pentru fiecare, individual se va seta metoda de notificare.

Tot în panelul personal va putea vizualiza toată istoria de verificări a resurseipersonale indiferent dacă a fost efectuatăde serverele de execuție. Interacțiunea între site-ul principal, serverul task manager și serverele de execuție sunt transparente pentru client.

Sistemulde notificări este modular,ceea ce ne permite de a introduce o metodă nouă de alerteindiferent de idiologia sa.

Tot în nodul dat interacțiunea utilizatorului cu sistemulpoate fi la nivel de API. Aceasta ne permite de a crea aplicații folosind API a serviciului dat fără teamacă vor fi adăugate funcționalități noi sau schimbări de design în caz că a fost creat vreun parser. Aplicația va lucra în continuare chiardacă serviciul ce oferă API va suferi schimbări în design.

Baza de date este setată folosind instrumentul de replicare, împărțită ca MASTER + SLAVE. Unde MASTER va primi toate cererile de modificări, pe cînd SLAVE va fi utilizat doar pentru cereri de SELECT. Aceasta va permite evitarea problemelor de blocare a tabelelor și rezultatele vor fi returnate cu mult mai rapid din cauza că nu vor fi ocupate cu procesul de modificări. Pe parcurs, va fi posibilă mărirea numărului de baze de date, odată cu creșterea numărului de cereri față de baza de date.

Serverul Task Manager

Nodul dat răspunde de repartizareasarcinilor către serverele de execuție și website. Acest nod este un nod ce permite interacțiunea execuției cu vizualizarea rezultatului.

La adăugarea, ștergerea sau modificarea unei sarcini din partea utilizatorului sau balanța contului,se va micșora pînă la insuficiența achitării execuției sarcinilor.Modificarea sarcinii se expediază direct spre acest server pentru a fi executată modificarea, care mai apoi se schimbăși în baza de date.

Pe lîngă sarcina nodului dat de a comunica cu serverele de execuție, el mai are și funcția de a selecta cărui server să-i fie expediată o sarcină nouă în funcțiede gradul de încărcare a acestuia. Gradul de încărcare este calculat înbaza sarcinilor încărcate pe minut. Pe lîngă aceasta, se ia în considerație că majoritatea sarcinilor sunt comandate pentru verificare nu în fiecare minut, ci odată la 5, 10 sau 15 minute,un rol deosebit la alegerea lui avîndu-l factorul economic. Pentru aceasta, fie că este prezent la noi doar un server de execuție, pentru a balansa sarcina dată pe acest server noi nu îi vom atribui mai multe sarciniîn același minut, ci pe parcursul unei ore vom repartizasarcina în așa mod ca să fie balansatăefectiv la maxim.

Fie 2 sarcini cu repetări de odată peminut, 2 sarcini – odată în 5 minute, 2 sarcini odată în 10 – minute și 2 sarcini cu repetarea odată în 15 minute. Vom evalua rezultatele fără balansare și cu balansare prezentate în tabelele 3.1 și 3.2 respectiv.

Tabelul 3.1–Fără balansarea sarcinilor

Tabelul 3.2 – Cu balansarea sarcinilor

În tabele vedem o balansare la nivel de server de sarcini, în așa mod căpătăm o economie și o balansare reciprocă pe parcursul unei ore.

Gradul de încărcare a unui server se va calcula datorită număruluide sarcini pe minut încărcate pe un oarecare server prin sumarea repetărilor tuturor sarcinilor timp de 24 de ore împărțind la 1440 (minute în 24 de ore).

Pentru exemplul expus de mai sus cu 8 sarcini va fi calculat în forma dată:

Sarcini executate pe oră = (60 repetări/oră + 12 repetări/oră + 6 repetări/oră + 4 repetări/oră) * 2 sarcini = 164, respectiv 164 sarcini executate * 24 ore = 3936 sarcini executate timp de 24 ore, unde în urma raportului de 3936 / 1440 vom primi rezultatul de 2,73 sarcini pe minut. Rezultatul dat vanumi gradul de încărcare.

Numărul sarcinilor admisepe minut este configurabil pentru fiecare server de execuție aparte în funcțiede resursele acestuia și mărimea canalului de rețea în internet. Pentru configurările minime vom considera că se execută5 cereri paralele timp de o secundă, respectiv timp de 60 secunde, aproximativ vom avea posibilitatea de a încărca pentru un server cu resursele minime de300 de sarcini. Numărul cererilor paralele pot fi majorate pentru fiecare server aparte. Trebuie de ținut cont că sunt sarcini care se vor executa cu mult mai rapid față de alte cereri. Spreexemplu o sarcină HTTP față de HTTPS diferă după execuția acestuia, într-un timp de 2 ori mai rapid.

Pe baza indicatorului gradului de încărcare putem selecta cărui server să-iexpediem o sarcină nouă. Acest indicator este calculat pentru fiecare server individual de fiecare dată de cîte ori suferă modificări una din sarcinile acestui server, inclusiv adăugarea sau ștergerea unei sarcini.

Pentru detectarea minutului de cînd ar trebui să pornească execuția sarcinii cu periodicitatea stabilită de client,ca scop de balansare a serverului vom recurge la un algoritm expus mai jos prin pseudocod.

În urma execuției funcției prezentate de mai sus, vom primi minutul pentru a fi înregistrată sarcina dată pe serverul actual.

Minutul dat va fi expediat spre serverul de execuție, timpul căreia mai apoi va fi salvat local pentru a conlucra autonom fără serverul task manager. Rolul serverului task manager este de a împărți și a gestiona sarcinile de pe toate serverele de execuție.

Serverul de execuție

Acest nod este un punte important la realizarea sarcinilor, el preia sarcinile de la serverul Task Manager și le execută.Pri urmare, rezultatul este expediat către Task Manager. Numărul acestor servere poate fi variat și în regiuni geografice diferite.

Sarcinile sunt expediate sub niște opțiuni ca: ID-ul sarcinii, repetarea, minutul de la care ar trebui să înceapă execuția sarcinii, tipul sarcinii (http, ping, smtp), adresa spre server pentru a executa sarcina, repetarea sarcinii în cazul rezultatelor negative.

Interacțiunea dintreserverul de Task Manager și serverul de execuție este destul de importantă, și indiferent de rezultatul execuției sarcinii, rezultatul este expediat obligatoriu spre serverul de Task Manager. În caz dacă interconexiunea între Task Manager și Serverul de execuție se pierde, Task Managerul încearcă să împartă sarcinile serverului pierdut unui alt server pentru a nu pierde sarcinile în vederea execuției acestora, iar în același timp, serverul de execuție ce a pierdut conexiunea se oprește dinexecutareasarcinilor. Stoparea execuției sarcinilor serverului pierdut permite de a nu depăși numărul de cereri planificate spre serverul ce este sub monitorizare.

Atunci cînd serverul Task Manager împărțește sarcinile altor servere, în baza locală el își bifează acesteaca fiind temporare și în caz că își revine serverul anterior pierdut, serverul Task Manager returnează starea sarcinilor eliminînd sarcinile anterior expediate altor servere.

Sarcinile acestui server sunt păstrate într-o bază locală amplasată pe același server.

3.1.3 Interacțiunea între componentele aplicației

Mai jos prezentăm interacțiunea semnalelor dintreservere. Considerăm că balanța contului clientului este suficient încărcată pentru a executa sarcinile de mai jos.

În figura 3.3 este prezentată schema bloc pentru adăugarea unei sarcini noi. După cum se poate observa, la adăugarea unei sarcini pe site, cererea va pleca spre Serverul Task Manager. În funcție de opțiunile setate de client și în urma optimizării de a selecta cel mai liber server după resurse, va expedia sarcina spre serverul selectat. Serverul în răspuns va da starea execuției sarcinii, care mai apoi spre site-ul principal va expedia ID la nivel de task manager și starea execuției sarcinii expediate anterior.

Figura 3.3 – Schema bloc pentru adăugarea sarcinii noi

Următoarele scheme bloc din figurile 3.4, 3.5, și 3.6 reprezintăexecuția unei sarcini complete prin toate nodurile sistemului. Sunt evidențiate atît rezultatele pozitive, cît și cele eșuate.

La nivel de server de execuție, rulează mereu mai multe demone ce manipulează cu sarcinile ce trebuie să fie executate și cu sarcinele în stare de execuție. Ajungînd la timpul necesar pentru a executa o sarcină, el preia din baza locală sarcina ce este în așteptare de execuție și crează un proces nou cu execuția acestei sarcini. Indiferent de rezultatul sarcinii, fie el pozitiv sau negativ, acesta este expediat spre serverul task manager cum se poate observa în figura 3.4.

În caz de eșec, după cum se vede în schema bloc, rezultatul este expediat spre serverul task manager, dar și îl pune într-o stare de așteptare de a repeta sarcina dată conform opțiunilor anterior introduse de către client. În opțiuni, pe lîngă periodicitatea executării sarcinii, mai este și periodicitatea în caz de eșec.

Fie ca exemplu o sarcină setată cu periodicitatea de odată în 15 minute, cu opțiunea de periodicitate odată în minut în caz de eșec și în momentul de verificare va suferi un eșec, atunci,sarcina actuală va fi amortizată și expusă următorei execuții peste un minut conform opțiunilor setate de către client. În așa caz, spre serverul task manager vor fi expediate și rezultate a sarcinilor neplanificate în caz de eroare. La un nivel mai sus aceasta va fi luat în considerație ca să fie alertat clientul în continuare.

Figura 3.4 – Execuția sarcinii la nivel de server de execuție

Primind rezultatul de la sarcinile de execuție la serverul task manager ca în figura 3.5, acest semnal doar va retransmite mesajul spre serverul principal de date statistice. În cazul respectiv el reprezintă doar o componentă de tranziție. Serverul Task Manager va lucra cu baza de date MASTER pentru modificarea datelor.

Figura 3.5 – Execuția sarcinii la nivel de Server Task Manager

Mai apoi, de la serverul task manager, rezultatul sarcinii este expediat spre serverul principal cu date. Aici el este prelucrat în continuare în funcție de opțiuni. Dacă rezultatul sarcinii este negativ, conform schemei din figura 3.6 se va prelua valoarea opțiunii “Notificaredupă X erori” introdusă de către client pentru sarcina actuală.Totodată va fi luat numărul de rezultate negative consecutiv executate anterior inclusiv rezultatul actual. Numărul rezultatelor negative anterior executate se va compara cu opțiunea setată de client.În cazul în care numărul de rezultate va depăși valoarea setată de client, se va apela modulul de notificare unde mai apoi se aplică notificarea în funcție de opțiunile setate de către client pentru sarcina dată.

Indiferent de rezultat, sunt înregistrate toate în baza de date, ca mai apoi să fie analizate de către client.

Figura 3.6 – Analiza rezultatului primit la nivel de website

Dacă vom reprezenta prin diagrama de activități interacțiunea dată, noi o putem evidenția în figura 3.7.Drept componente vom enumera următoarele elemente: Baza de date, Sistemul de notificări, Sistemul Task Manager și serverul de execuție.

Figura 3.7 – Diagrama de activități ce arată interacțiunea între componente pentru execuția sarcinii

3.2 Tehnologii utilizate

Pentru căpătarea celor mai rapide și eficiente rezultate, în proiect sunt utilizate cele mai performante tehnologii. Pentru fiecare nod, sunt utilizate tehnologii diferite.

Acest serviciu, anterior menționat, este format din 3 părți principale:

WebSite-ul;

Serverul Task Manager;

Serverele de execuție.

Pentru WebSite, tehnologiile utilizate sunt: PHP, MySQL, Apache (ca server HTTP). WebSite-ul este creat pe framework-ul Laravel 5.1.

Serverul Task Manager este cel mai apelat nod atît din partea website-ului, cît și din parteaserverelor de execuție, luînd în considerație că serverele de execuție pot fi în număr de peste 100. Deci aici am utilizat Baza de date NoSQL Tarantool cu procedurile scrise în Lua și în legătură cu serverele exterioare folosind protocolul HTTP cu aplicația NGINX cu datele serializate în JSON.

Serverele de execuție utilizează tehnologiile: PHP, NGINX (ca server HTTP), baza de date MySQL.

Pe lîngă serviciul de monitoring aldisponibilității, este și serviciul de monitoring alresurselor. El constă în preluarea datelor resurselor de la serverele monitorizate și expedierea lor spre serverul de API a serviciului dat. Pentru a expedia datele, pe serverul monitorizat se instalează și se rulează scriptul scris pe PERL.

3.3 Implementarea execuției sarcinilor

Execuția sarcinilor va fi descrisă în secțiunile de mai jos la nivel doar de server de execuție. Se vorprezenta metodele și implementarea fiecărui protocol înparte.

La setarea sarcinii la nivel de site, clientului îi sunt disponibile următoarele opțiuni:

denumirea punctului de control;

periodicitatea verificării;

periodicitatea verificării în timpul erorii;

momentul expedierii alertării despre serviciul căzut;

expedierea alertării despre serviciul ridicat;

metoda de alertare;

timpul maxim de așteptare;

algoritmul de control;

starea acestui punct de control.

Însă, la serverul de execuție ajung doar date ca: periodicitatea verificării, periodicitatea în timpul erorii și timpul maxim de așteptare. Opțiunile celelalte sunt folosite de către website și de către serverul Task Manager.

Fiecărui tip de control îi sunt oferite un număr diferit de opțiuni.Desprefiecare tip vom discuta în continuare.

Verificarea serviciului protocolului HTTP(s)

Acest tip verifică disponibilitatea aplicației prin protocolul HTTP. Verificarea este posibilă folosind metodele GET, POST, HEAD atît pentru conexiune nesecurizată, cît și pentru cea securizată. Metoda dată este utilizată pentru site-uri web disponibile pe port-ul standart pentru HTTP 80.

Pentru această opțiune sunt disponibile următoarele setări adiționale:

adresa web sau IP;

să urmeze verificarea dacă sunt redirecționări;

user agent;

verificarea content-ului (după text sau expresii regulate);

notificarea la ridicarea serviciului.

Pentru acest protocol este disponibilă și versiunea securizată. În cazul dat cererea nu va fi expediată spre port-ul 80, ci pe 443, în caz dacă nu este selectat un alt port diferit de cel standard.

Verificarea protocolului dat în funcție de opțiuni se verifică utilizînd funcțiile din biblioteca “curl”. Acest cod poate fi vizualizat îndată mai jos.

Verificarea serviciului protocolului FTP

Acest protocol este utilizat pentru accesul la fișierele aflate pe server cît și manipularea acestora.

Metoda dată este utilizată pentru verificarea accesării la site prin protocolul FTP. Port-ul standard utilizat pentru FTP este 21. La verificare acestui serviciu, clientul trebuie să introducă datele de access la server, datele contului pentru autentificare și regimul FTP (activ sau pasiv).

Pentru transferul de fișiere, mai este standardizat și regimul anonim fără utilizarea autorizării. Pentru aceasta, este nevoie de a bifa opțiunea stabilită ce va indica FTP-ul anonim.

Prin monitorizarea acestui serviciu, vă va permite înștiințarea și rezolvarea problemei prealabile apărute de căderea serviciului dat. Acest serviciu este utilizat adesea de către dezvoltatori în timpul transformării, analizei logurilor de pe server sau în timpul încărcării unor documente pe server. Paralel pe un server poate fi creat un număr nelimitat de conturi FTP în care, pentru fiecare cont FTP, vom putea atribui un domen diferit. Domenele de pe serverul dat pot fi considerate că aparțin diferitor stăpîni.Astfel, utilizînd acest protocol, se conectează paralel diferiți utilizatori. Căderea acestui serviciu va aduce nemulțumirea clienților.

Verificarea protocolului dat în funcție de opțiuni se se realizează datorită funcției de mai jos.

Verificarea serviciului protocolului SMTP

Protocolul SMTP este destinat serviciilor poștei electronice. Prin acest protocol sunt expediate mesajele electronice.

În majoritatea cazurilor, oricare proiect mare are o poștă electronică destinată expedierii datelor de înregistrare, instrucțiunii de resetare a parolei sau altor informații ce contribuie la gestionarea contului personal. Pentru acestea se utilizează poșta electronică cel mai des întîlnită -no-reply@example.com(doar cu scop de expediere). În cazul expedierii mesajelor, în majoritatea cazurilor este utilizat protocolul SMTP.

Deci, căderea acestui serviciu va face imposibilă utilizarea expedierii mesajelor, fapt ce va provoca o funcționare proastă a site-ului personal.

Verificarea protocolului dat în funcție de opțiuni se realizează datoritălibrăriei “PHPMailer”.

Verificarea serviciului protocolului POP3 și IMAP

Ca în protocolul precedent, POP3 și IMAP sunt protocale de nivel aplicație pentru Email,destinate recepționării și expedierii mesajelor electronice pe serverul poștal.

Protocolul POP3 este utilizat doar pentru încărcarea mesajelor noi de pe serverul poștal. El permite clientului poștei electronice să se conecteze doar în perioada în care este nevoie de a descărca scrisorile. Nu se permite conexiunea în paralel a mai multor clienți poștali la aceeași poștă.

La utilizarea protocolului IMAP, conexiunea nu se întrerupe pînă cînd când nu se stabilește legătura dintre poșta electronică și clientul poștal. Scrisoarea încărcată pe server se descarcă doar după cererea clientului poștal. Este permis accesul concomitent a mai multor clienți poștali pe aceeași poștă electronică și fiecare poate vedea schimbările executate de alți clienți, precum și statutul fiecărui mesaj (citit, răspunsul expediat, șters).

Verificarea protocolului dat în funcție de opțiuni se realizează datoritălibrăriei “PHPMailer”.

Verificarea serviciului protocolului ICMP (PING)

Este un protocol din suita TCP/IP care folosește la semnalizarea și diagnosticarea problemelor din rețea. Mesajele ICMP sunt încapsulate în interiorul pachetelor IP. Una din programele bazate pe ICMP este PING. Aceasta verifică printr-o „cerere de ecou” așteptînd un “răspuns ecou”.

O deprindere importantă la majoritatea dezvoltatorilor este utilizarea acestui instrument. În cazul în care dispare conexiunea la internet, primul lucru care trebuie să-l facem este să verificăm conexiunea dînd un ping la un server foarte popular, cunoscut.

Cu ajutorul acestui instrument putem vizualiza timpul de răspuns din partea serverului. În majoritatea cazurilor, acest protocol poate fi blocat de către server. În așa caz, cererile expediate spre server vor eșua, iar serviciile precum HTTP vor fi disponibile.

Verificarea protocolului dat în funcție de opțiuni se realizează datorită funcției de mai jos.

Verificarea conexiunii cu MySQL

Verificarea conexiunii cu baza de date MySQL se realizează prin 2 metode (folosind autorizarea directă la portul 3306 sau prin aplicația disponibilă pe portul 80.

A doua metodă este mai eficientă din punct de vedere al securității, pe cînd prima metodă permite utilizarea portului 3306 pentru exterior ce poate fi ținta unui atac de tip brute-force. Se recomandă ca port-ul 3306 să fie închis pentru exterior.

Verificarea protocolului dat în funcție de opțiuni se realizează datorită funcției de mai jos.

Verificarea timpului expirării domen-ului

Acest serviciu se utilizează pentru a primi o notificare în prealabilînainte de expirarea unui anumit domen. Acest serviciu este benefic pentru utilizatorii ce au multe domene de la înregistratori de domene diferite, unde se întîlnesc sisteme ce nu avertizează din timp expirarea domen-ului.

Verificarea expirării domenului se va face prin instrumentele de WHOIS. Acest serviciu permite informații ca datele stăpînului acestuia, datele registratorului, data creării, prelungirii și expirării acestuia, precum și datele spre serverul de nume (DNS).

Pentru acesta, vom crea un parser ce ne va permite extragerea informațiilor datelor despre domen utilizînd serviciul https://who.is/.

Codul pentru extragerea informațiilor de pe acest serviciu va fi următor:

În urma execuției verificării domenului mail.ru vom primi următorul rezultat:

În baza funcției de mai sus, vom pune în monitoring data expirării domen-ului. La prima adăugare în monitoring, va fi parsat informația despre domen. Luînd în vedere perioadele de notificare pentru expirarea domen-ului, vom face o economie de cereri după scenariul descris mai jos.

Fie perioadele de notificări:

30 zile pînă la expirare;

15 zile pînă la expirare;

10 zile pînă la expirare;

5, 4, 3, 2, 1 zile pînă la expirare.

Specific acestui tip de control este faptul că nu este necesar de a monitoriza zilnic data expirării. Ne vom referi la prima încărcare a verificării și înscrierii în baza de date – data expirării. Prin intermediul datei introduse în bază, vom calcula cîte zile au rămas până la expirare și în timpul cela se va face update la data expirării.

Fie domenul expus de mai sus – mail.ru. Potrivit rezultatelor vedem că data expirării va fi în 2016.11.01, dar acum fie că e 22.01.2016. Deci în baza de date înregistrăm data expirării de 2016.11.01. Ajungînd pe data 2016.10.01, se va face update la data expirării și dacă după update se va constata că data expirării este egală din una din perioadele de mai sus, atunci se va produce notificare conform zilelor rămase. Astfel, noi nu executăm zilnic cereri adiționale de prisos, ci verificăm domenul doar în timpul apropiat, cînd vine data expirării, dacă nu a fost întîmplător deja prelungită.

Verificarea PR / CY Yandex

Acest serviciu este util pentru SEO specialiști laanaliza hiperlegăturilor din Internet. În așa mod acestuia îi va fi disponibilă o pagină ce va putea urmări istoria schimbărilor și crearea unor reguli ce va conduce la alertarea în cazul în care se produc schimbări.

Verificarea indicilor va fi din baza adreselor web ce utilizează instrumentele, barele de la Yandex și Google.

În așa mod pentru CY Yandex vom putea prelua datele de pe adresa:http://bar-navig.yandex.ru/u?ver=2&url=http://DOMAIN&show=1

Pentru datele PR Google putem prelua de pe serviciul: http://www.instantpagerankchecker.com/.

Deci, cunoscîndunde se află informația, vom crea 2 funcții pe PHP pentru a extragerea acesteia.

Verificarea link-urilor disponibile pe site (SEO)

Pentru promovarea unui site prin motoarele de căutare, se cunosc promovări bazate pe link-uri aflate pe altă resursă informatică cu aceeași tematică, dar cu mult mai populată.

De aceea, pentru a mări popularitatea site-ului personal, se recurge la metode de procurare a link-urilor de pe resursele ce oferă astfel de servicii.

În vederea siguranței din partea prestatorului de spațiu pentru link, sistemul de monitoring poate oferi un serviciu de verificare a existenței link-ului pentru o anumită perioadă.

Serviciile oferite de monitoring sunt afișate în secțiunea“Disponibilitatea link-urilor conform regulilor SEO” a capitolului 2.1. Aici link-ului pe lîngă disponibilitate, i se va verificași permisiunea de acces din partea motoarelor de căutare. Dacă motorul de căutare nu va avea acces la pagina dată și link-ul necesar, prestatorul nu își va îndeplini în totalitate serviciile oferite.

3.4 Implementarea notificărilor

La implementare, sunt descrise doar metodele utilizate în proiectul final. Acestea sunt:

mesaje E-Mail;

mesaje SMS;

cereri HTTP GET.

Deoarece acest punct, este foarte important în funcționalitatea sistemului, căderea lor va neglija informarea a zeci de mii de clienți, ceea ce poate provoca pierderea unui număr mare de clienți, iar mai apoi o atitudine mai puțin așteptată față de serviciul dat.

Pentru a micșora probabilitatea căderii a unor servicii, noi vom dubla sau chiar tripla căile de notificări pentru fiecare tip de notificare în parte.

Nu ne putem limita doar la un tip de notificare și la o adresă de destinație pentru producerea alertei. Notificările pot veni chiar și în felul următor: 2 email-uri, 3 sms și 5 cereri HTTP GET. Sporirea metodelor de notificări prezintă o probabilitate mai mare că clientul sau administratorul de sistem va fi anunțat în vederea rezolvării problemei.

La nivel de cod, apelarea modulelor de notificare se execută conform șablonului de proiectare „Facade”. Ea poate fi reprezentată prin diagrama de clase în figura 3.8.

Figura 3.8 – Diagrama de clase ce alertează clientul despre starea sarcinii

Notificări utilizînd mesaje E-Mail

Pentru notificare, se va utiliza cel puțin 3 servere pentru expedierea poștei electronice. În cazul în care un server din cele expuse nu își poate executa funcția de a expedia mesajul, sarcina trece la alt server. Ca soluție de rezervă, se va trece la serviciul de expediere a mesajelor prin intermediul www.mandrill.com. În vederea expedierii cu succes a mesajelor e-mail (fără ca acestea să cadă în SPAM), pentru toate serverele, inclusiv pentru serviciul www.mandrill.com, va fi necesar de a introduce notițe TXT în serverul de nume pentru domeniul respectiv, ca permisiune de expediere a mesajelor de pe anumite IP-uri.

Expedierea mesajelor se expediază conform unei liste datorită principiului FIFO. Pe lîngă funcția serverelor de rezervă anterior discutată, ele vor ajuta la execuția sarcinilor de notificare în caz dacă sunt prea multe în listă.

Notificări utilizînd mesaje SMS

Metoda respectivă permite notificarea fără a utiliza internetul, altfel spus – prin metoda mesajelor scrise pe telefonul mobil.

La execuția acestui modul, se va interacționa cu serviciile: www.clickatell.com, www.smsc.ru și www.sms.ru. Lista serviciilor sunt sortate după încrederea și fiabilitatea ce o prezintă. Cel mai sigur și stabil proiect este considerat Clickatell.

De aceea notificarea mai întâi de toate va fi expediată spre clickatell.com. În cazul pierderii conexiunii cu acest serviciu, insuficienței banilor pe contul personal,blocării contului sau în cazul altor probleme apărute la interacțiunea cu acest serviciu, sarcina de notificare va fi transmisăaltuiserviciu. Aceleași condiții se vor verifica și pentru cel din urmă serviciu apelat, iar în caz de eșec, va fi trecută la alt serviciu.

Spre deosebire de metoda de notificare prin utilizării mesajelor email, metoda notificării prin mesaje sms se bazează doar pe servicii terțe. Aceste servicii au în interiorul lor același principiu alsemnalelor FIFO. De aceea, noi o expediem sarcinile în formă de listă spre serviciu fără a aștepta execuția lor, mai apoi doar verificăm starea lor după un timp anumit.

Stării expedierii mesajelor pot fi verificate prin 2 metode:

cu ajutorul cererii din partea serverului nostru spre serviciu utilizînd interfața API;

prin răspuns din partea serviciului spre serverul nostru, după execuția sarcinii.

În cazul nostru, noi utilizăm ambele metode de a verifica starea acestora. Mesajele la care nu a venit încă răspuns prin apel de la serviciu, se verifică repetat după un interval de timp cu cerere din partea noastră prin interfața API la serviciu.

Notificări utilizînd apeluriHTTP GET

Această metodă permite automatizarea aplicației din partea dezvoltatorului aplicației ce este sub monitorizare. În cazul eșecului stării serviciului, se expediază o cerere prin protocolul HTTP GET spre adresa indicată de către client.

La nivel de client, acest serviciu face posibilă realizarea unor comutări pe site. Fie ca exemplu serviciul ce verifică www.example.com.Notificarea se va produce prin metoda HTTP GET la o adresă www.notify-example.com ce se află pe alt server inclusiv alt DNS server. La nivel de server pe adresa www.notify-example.com va fi posibilă comutarea site-ul www.example.com pe altă adresă IP la nivel de DNS pentru a nupierde clienții noi ai site-ului.Există următoarele posibilități de implementare a aplicației de tip server pe serverul ce va primi notifări prin metoda HTTP GET:

modificarea adresei IP pentru notițele A pe serverul DNS;

modificarea adreselor ”name server” pentru domen;

notificarea clienților ce au fost online în momentul căderii site-ului, iar atunci cînd se va restabili – să primească notificați prin e-mail depre restabilirea site-ului;

dezvoltarea metodei personale de notificare în cazullipsei sistemului de monitoring.

Ca și în cazurile precedente, aici se vor folosi servere de rezervă pentru execuția notificărilor. Pentru execuției notificărilor, sarcinile sunt efectuate în paralel.

Dacă apare problema că serverele sunt prea încărcate, rezolvarea acesteia ar fi utilizarea serverelor de execuție pentru notificări.Pentru economia resurselor serverelor, putem să nu folosim serverele de notificări, ci doar serverele de monitoring. Pentru utilizarea serverelor de monitoring, vom fi nevoiți să adăugăm această funcționalitate la nivel de server de execuție pentru a expedia anumite date despre sarcină spre adresa de notificare.

Dacă vom afișa cu ajutorul unei diagrame cazurile de utilizarea serviciuluide notificare, introducînd și căile de rezerve, atunci ea poate fi reprezentată prin figura 3.9.

Figura 3.9 – Diagrama cazurilor de utilizare a serviciului de notificare pentru client

3.5 Agentul de verificarea resurselor serverului

3.5.1 Informații generale

Pentru monitorizarea resurselor interne a unui oarecare server, va fi nevoie de un agent instalat pe server ce va prelua datele interne și le va redirecționa spre interfața API a sistemului de monitoring. Agentul este creat pe limbajul Perl 5, care este destinat sistemelor de operare Linux.

Aplicația este pornită cu ajutorul cron-ului la fiecare 5 minute, unde va prelua datele informaționale referitor la RAM, CPU, NETWORK, HDD.Astfel, se va crea un masiv de date și se va expedia spre interfața API a serviciului de monitoring.

Datele sunt extrase din baza aplicațiilor populare pe Linux.Datele apelate din ”console” se vor parsa cu ajutorul limbajului ”Perl” care, mai apoi, strînse într-un fișier în format plain,vorfi expediate spre interfața API a serviciului de monitoring.

Pentru rularea script-ului de monitorizare, este necesar de a instala pe server compilatorul Perl. Limbajul a fost selectat deoarece majoritatea distributivelor Linux au instalat predefinit compilatorul Perl.

Pe lîngă instalarea compilatorului dat, mai este nevoie și de disponibilitatea modul-ului ”curl”. Acest modul permite comunicarea prin protocolul HTTP la nivel de TCP/IP.

La nivel local de resursă a clientului, fișierele cu date statistice ce nu au fost expediate cu success spre serverul de monitoring, vor fi reexpediate spre monitoring la prima conexiune cu succes. Astfel nu vom pierde datele statistice, chiar dacă nu va exista conexiunea cu serverul de monitoring.

Codul sursă a agentului este prezentat în anexa A.

3.5.2 Interconexiunea agentului cu serverul API

La interacțiunea cu serverul API, datele sunt transmiseprintr-un interval de timp constant prin expedierea datelor strînse de script spre server în format plain.

La instalarea agentului pe server, se va executa următoarea comandă ce va permite descărcarea script-ului local pe server:

Folosind parametrul „key” expediat în adresă, se va genera valoarea codului în script cu codul specific utilizatorului. În așa mod, în funcțiede valoarea “key”, conexiunea cu API face posibilă salvarea datelor utilizatorului cărui îi este specific acest cod.

La expedierea datelor statisticespre serverul API, în paralel se expediază codul dat generat anterior în script. În așa mod se face interconexiunea între server și serviciul de monitoring.

Pentru fiecare server în parte, se va genera o valoare „key” individuală. Acest cod poate fi vizualizat în panoul de control a sistemului de monitoring. El este prevăzut la adăugarea unei noi resurse pentru monitorizare, cît și la vizualizarea informației despre un oarecare server.

La nivel de server, codul dat este generat aleatoriu, utilizînd hash-ul md5 cu valoarea de la 8 la 15 caractere, îndeplinind condiția de unicitate.

Pe lîngă faptul de expedierea datelor spre sistemul de monitoring, sunt cazuri de eșuare a comunicării dintre servere. Problemele pot fi următoarele:

indisponibilitatea servereului de monitoring;

pierderea conexiunii cu lumea exterioară la nivel de server;

căderea serviciului de HTTP sau bază de date la monitoring;

modificarea sau ștergerea codului “key” la nivel de monitoring.

Să exemplificăm un caz de eroare a ștergerii unui proiect din partea utilizatorului. Fie proiectul de monitorizare a resursei RESOURCE_1. Pe resursa dată, agentul este instalat deja de 6 luni. Din greșeală, clientul a șters proiectul din vizualizare din sistemul de monitoring. Apoi, încearcă să își adauge proiectul înapoi creînd un proiect nou, dar aici deja îi va apărea un cod “key” generat nou. În timpul acesta, cît proiectul a fost șters, datele se stochează local pe serverul ce se monitorizează.

Pentru a rezolva problema și a stoca în continuare datele, clientul trebuie să acceseze serverul personal, iar în variabila specifică pentru cod din script-ul ”sysping.pl” să fie modificat ca valoarea nouă. După ce va fi indicată valoarea, timp de 5 minute se va reconecta cu serverul de monitoring și va expedia toate datele inclusiv cele ce nu au fost expediate spre server.

3.5.3 Extragerea informațiilor de pe server

În continuare, se va analiza rînduri din sursa cod ce are ca scop parsarea informațiilor de pe sursa monitorizată.

Mai întîi de toate, la primul apel al script-ului, se verifică existența mapei/sysping în directoriul /var/log, în caz că lipsește, acesta se crează. Aceste operațiuni sunt executate conform următorului cod:

Pe lîngă aceasta, în mapa /var/log/sysping se va crea mapele ”/all” și ”/errors”.

/all – se va include toate datele statistice ce se monitorizează;

/errors – se vor include toate log-urile ce nu au fost expediate spre serverul de monitoring;

În baza fișierelor ce se află în ”/errors”se potreexpedia datele ce au fost expediate anterior cu eroare.

Apoi, se va parsa informațiile resursei date(tipurile acestora sunt explicate în continuare). Și spre final, fișierul este salvat în mapa ”/var/log/sysping” ca fișier temporar. În funcție de cum a fost expediatfișierulspre monitoring – cu succes sau eronat, se va salva în mapa respectivă.

Extragerea informației RAM

Parsarea informației memoriei este extrasă din sistemul virtuală de fișiere /proc. Prin intermediul acestuia avem acces direct la structurile de date ale procesorului. Prin intermediul informației ”/proc/meminfo” vom primi informația în formatul dat:

Utilizînd funcția ”memory()” din script-ul agentului, vom parsa valoriile informațiile prezentate în tabelul 3.3.

Tabelul 3.3 – Valorile informațiilor ”/proc/meminfo”

Extragerea informației HDD

La extragerea informațiilor memoriilor discurilor conectate la sistem se va parsa datele din comanda apelată în ”console”:

Parametrul ”-m” exprimă unitatea de măsură utilizată în cazul în care valorile sunt exprimate în unitățile MB. În urma execuției acestui cod, se va returna rezultatul următor:

Astfel, ne rămîne doar să le grupăm în fișier folosind funcția ”disks()”, în urma căruia vom obține lista de valori prezentate mai jos:

Extragerea infomației CPU

Ca și în cazul parsării informației memoriei operative cu sistemul virtual de fișiere ”/proc”, vom extrage informațiile din ”/proc/stat”.

Un rezultat similar arată în felul următor:

În așa mod, din acest rezultat noi putem extrage informația despre numărul de procesoare a servererului dat, încărcarea fiecărui proces în parte și alte date. Noi ne vom axa doar pe încărcarea fiecărui procesor cît și pe încărcarea globală. În așa mod, vom folosi doar datele ce încep din linia nouă cu indicile “cpu”.Datele returnate în tabelul de mai sus reprezintă timpul necesar folosit pentru executarea anumitor sarcini. Aceste date sunt (time units) caracterizate ca USER_HZ – sutimi de secundă.

Valoarea fiecărei coloane va fi:

user: procesele obișnuite, care rulează în user mode;

nice: procese din nice în user mode;

system: procese în kernel mode;

idle: timpul în repaus;

iowait: așteptarea operațiunilor I/O;

irq: prelucrarea întreruperilor;

softirq: prelucrarea softirq;

steal: timpul executat pentru alte sisteme de operare utilizate prin virtualizare;

guest: prelucrarea proceselor “oaspeți”(virtuali).

Sumînd aceste date, noi vom primi timpul total utilizat de către procesor, inclusiv timpul în repaus.

Pentru parsarea informațiilor necesare vom folosi funcția din script cpu_load(). Rezultatul acestuia va returna, pentru fiecare procesor în parte, raportul dintre timpul utilizat al procesorului și timpul utilizat total inclusiv cel de repaus.

În urma execuției acestei funcții vom obține rezultatul următor:

Extragerea informației desprerețea

Extragerea informațiilor despre tipuri de interfețe conectate la server este posibilă prin apelarea comenzii:

În urma execuției acestei comenzi vom primi răspunsul:

Pe lîngă acestea, mai sunt posibile interfețe ca: bound, bridge, tun, tap, ppp ș.a. Apoi, după ce am primit lista de interfețe disponibile, vom putea extrage informațiile pentru fiecare interfață în parte. Pentru aceasta se vizualizează valoarea fișierului conform tabelului 3.4.

Tabelul 3.4 – Valorile informațiilor /proc/meminfo

Continuarea tabelului 3.4

La nivel de script, returnarea informației despre rețea se va face utilizînd funcția ”network_config()”.

3.6 Descrierea aplicației

3.6.1 Informații generale

Aplicația este elaborată pentru confortul clientului, în așa mod, datele sunt foarte ușor manipulate. Designul este adaptabil și pentru versiunea mobil.

Pînă a ajunge în contul personal, utilizatorilor le sunt disponibile mai multe informații pe site. Dintre care:

informații despre proiect;

tarifele și serviciile oferite;

noutățile;

ajutor informațional;

și contactele cu administratorul.

În continuare, pentru un contact mai simplu și mai rapid cu clientul, pentru a-i crea o viziune mai mare despre proiect, se apelează la un cont demo ce îi va permite o autorizare rapidă sub un cont demo cu date deja completate.

Inregistrarea utilizatorului pe server se face prin introducerea datelor de acces,care include numele de utilizator (care poate fi si un email) si parola.. În cel mai scurt timp, clientul deja este înregistrat și își poate gestiona contul personal.

La prima autorizare în cont, clientul este redirecționat spre contul personal. Aici sunt afișate datele principale referitor la balanța contului (aproximativ pînă pe ce dată îi ajunge această balanță luînd în vedere numărul de sarcini, opțiunile acestuia, și ultimele notificări. Pagina dată este prezentată în anexa B.1.

3.6.2 Vizualizarea informațiilor

După cum am menționat anterior, în proiect este disponibilă monitorizarea resurselor și de accesibilitate. În așa mod, monitorizarea resurselor permite vizualizarea informațiilor despre un oarecare server, aflat la distanță, fiind chiar amplasate în rețea locală ce nu poate fi accesată din exterior dar cu condiția că are access la rețeaua internet. Pe serverele monitorizate se instalează un agent,iar pe parcursul funcționării serverului, scriptul expediază datele spre monitoring o dată la 5 minute în regim repetat. Vizualizarea paginii cu lista resurselor serverelor este prezentată în anexa B.2.

Pe lîngă monitoringul de resurse, mai este și monitoringul de accesibilitate. Aici sunt prezentate diferite protocoale de verificare. Cum apare în proiect putem vedea în anexa B.3.

Pentru adăugarea unei sarcini noi, clientul are posibilitatea de a seta unele opțiuni. Fiecărui protocol în parte, îi sunt caracteristice diferite opțiuni. Setarea protocolului HTTP HEAD este prezentată în anexa B.4. Aici, sunt aplicate efecte JavaScript pentru o comunicare eficientă cu clientul.

Aplicația este disponibilă online pe adresa www.sysping.ru din 18.01.2016 pînă pe 08.12.2016, iar la expirarea termenului, va fi disponibilă pe adresa www.sysping.web-faq.com.

3.7 Rezultate financiare

La implementarea acestui proiect, cheltuielele cresc odată cu necesitatea acestuia. Fiecărui client și cerinței expuse de acest client, îi este rezervat un fir de execuție de minim un server de execuție.

Mai întîi de toate vom calcula resursele minime achitate de server indiferent dacă sunt clienți sau nu, cheltuielele pot fi văzute în tabelul 3.5. Pe parcurs, resursele acestor servere vor avea nevoie de optimizări, dar pentru început, aceste resurse sunt de ajuns pentru acumularea clienților.

Tabelul 3.5– Cheltuilele pentru întreținerea proiectului

Prețul include traficul nelimitat pentru fiecare server în parte. În continuare vom calcula prețul cheltuit pentru o sarcină la nivel de server de execuție cu un rezultat ideal.

Anterior, în capitolul 3.1.2 s-amenționat despre limita de sarcini posibile în execuție pe server cu configurațiile minime pe minut.Valoarea acestuia era de 300 de sarcini. În așa mod, un server pe Linux cu caracteristicile de 512 MB RAM, 1 CPU cu virtualizarea KVM îl vom putea procura în mediu cu 4 $ pe lună. Deci, pentru a afla costul unei sarcini executate odată în minut, vom calcula în modul respectiv:

Prețul serverului / sarcini limită = 4 $ / 300 = 0,1(3) $ pe lună,

respectiv, pentru o sarcină setată cu periodicitatea de verificare odată pe minut, va costa 3,08 * 10-6 $. Acest preț este doar pentru răscumpărarea cheltuielilor doar a servererului de execuție.

În continuare analizăm prețurile concurenților pentru a crea un preț real disponibil clienților, inclusiv pentru a avea clientului propunînd un preț mai mic. În tabelul 3.6 este prezentată o compararea prețurilordintre clienții existenți pentru o cerere achitată de HTTP GET setată cu o perioadă de 1 pe minut. Lista de concurenți este aranjată crescător conform prețurilor.

Tabelul 3.6 – Prețurile concurenților

Din punct de vedere financiar, cel mai econom este proiectul ”syslab.ru”, dar adăugînd și funcționalitățile, tipurile de verificări, selectarea locațiilor și tipuri de notificări, luînd în considerație și prețul, atunci cîștigător devine proiectul ”Monitis.com”.

Deci, vom crea aproximativ același preț de 0.000018 $ pentru o verificare. Pentru acest preț, un server cu caracteristici minime poate executa maxim 300 de sarcini paralele..Numărulsarcinilor ce vor răscumpăra cheltuielile îl vom calcula prin formula următoare:

Marja de sarcini pentru profit = Cheltuielile lunare / Prețul lunar pentru sarcină = 37.16 $ / 0.80 $ = 47

Deci, dacă vom amplasa un preț minim, ce va depăși prețul cel puțin a10 concurenți, pentruîntoarcerea cheltuielilor mai am nevoie de minim de 47 de sarcini ca acestea cu o periodicitate de odată pe minut. Acest număr indică marja între profit și pierderi.

CONCLUZII

Orice sistem informațional sau aplicație are scopul să automatizeze anumite procese, să permită utilizatorilor de a obține anumite servicii într-un mod mult mai simplu și mai comod. Crearea unei aplicații începe de la proiectarea acesteia. Proiectarea sistemelor software include mai multe etape: de la specificarea cerințelor de sistem, specificarea detaliilor interfețelor, a drepturilor de acces a utilizatorilor pînă la structura claselor și obiectelor care urmează să fie implementate în cod. Un factor important la proiectarea aplicațiilor este specificare interacțiunilor dintre obiecte, a fluxurilor de date, a fluxurilor de mesaje, ordonate sau nu cronologic, care se transmit între entitățile aplicației pentru a realiza un anumit scop sau a oferi un serviciu specificat în cerințe de către utilizator.

Etapa de realizare a sistemului include descrierea etapelor realizării, tehnologiile aplicate și descrierea codului sursă. Etapa următoare descrie funcționalitățile aplicației încele mai mici detalii.Aceasta este ca un tipde documentare în vedereautilizării aplicației respective.

Realizarea documentației este importantă nu doar în procesul creării pentru a asigura comunicarea între programatori, ci și pentru întreținerea ulterioară a aplicației, în special în cazurile în care aceasta se va realiza de alte persoane decît cele care au realizat sistemul.

La realizarea serviciului de monitoring, capătă o importanță enormă conectarea pentru stăpînii website-urilor personale. Ea va oferi o stabilitate și încredere în serviciul personal care lucrează sigur și cu succes, ceea ce va provoca vînzări și comenzi active conform planului.

Un factor important la rezolvarea erorilor apărute pe site, este execuția acestuia cît mai curînd. Faptul acesta va permite unui sistem de monitoring să trimită notificări clientuluiimediat cum apar erori pe server. În cel mai scurt timp, clientul va începe lucrul asupra restabilirii proiectului.

La aplicarea sarcinilor pentru verificarea serviciului web, nu este suficientă verificarea doar a unui singur protocol. Pe lîngă HTTP este nevoie de a verifica și serviciul DNS, conexiunea la baza de date și, dacă persistă sistem de tickete cu poșta electronică pe server, va fi nevoie și de verificarea protocoalelor POP3 și SMTP. Toate protocoalele enumerate anterior contribuie la funcționarea în ansamblu a serviciului web, de aceea, va fi necesară verificarea tuturor protocoalelor.În așa mod, lipsa notificărilor din partea sistemului de monitoring vă va asigura că toate serviciile funcționează bine. Dacă se va prezenta vreun clientpe website, lucrul acestuia va fi executat conform funcționalității normale a serviciului web.

La nivel intern, interacțiunea între execuția sarcinilor și afișarea informațiilor se va face cu ajutorul serverului principal de sarcini, care are drept scop împărțirea sarcinilor în mod balansat între servere și în timp pe server, primirea rezultatelor și expedierea acestora spre baza de date centralizată. În așa mod, serverul principal va executa un număr mare de cereri.Pentru aceasta a fost aplicată tehnologia NOSQL care permite execuția sarcinii sigure indiferent de rezultat, într-un timp cît mai scurt.

Funcționalitatea și aducerea unui rezultat conforum unui ”business plan”, se datorează în totalitate sarcinilor executate de fiecare parte a acestei structuri. Deci, dacă o parte din structura site-ului clientului nu va funcționa conform așteptărilor acestora din cauză căderii unui component, va provoca rezultate negative pentru întregul proiect. De aceea, punctul de monitoring este o parte importantă în crearea unui serviciu indiferent din ce domeniu este acesta.

BIBLIOGRAFIE

Николай Мациевский , Методы мониторинга веб-сайтов и сервисов.[15.01.2016] Online: http://habrahabr.ru/post/138989/

Noah Lehmann-Haupt , Zen and the Art of System Monitoring.[15.01.2016] Online:https://www.scalyr.com/community/guides/zen-and-the-art-of-system-monitoring

Система мониторинга сайта. [15.01.2016] Online: http://livesurf.ru/monitoring-sajta/

Effective Monitoring and Alerting, O'Reilly Media. Noiembrie 2012.

System and Network Monitoring, ediția II, Nagios. 2008.

Evi Nemeth et al, UNIX System Administration Handbook, Ediția 3, Prentice Hall, 2001.

Mike Loukides and Gian-Paolo D.Musumeci, System Performance Tuning, Ediția 2, O’ Reilly, 2003.

Aellen Frish, Essential System Administration, Ediția 3, O’Reilly, 2002.

Mark Burgess, Principles of System and Network Administration, Wiley, 2000.

Anexa A Codul sursă a agentului

#!/usr/bin/perl

$str_all="";

# Verificarea folderului de loguri

$var_log_path='/var/log/sysping';

if ( -e $var_log_path."/log" ) {

} else {

system('mkdir -p '.$var_log_path.'/log');

}

if ( -e $var_log_path."/log/all" ) {

} else {

system('mkdir -p '.$var_log_path.'/log/getdate');

}

if ( -e $var_log_path."/log/errors" ) {

} else {

system('mkdir -p '.$var_log_path.'/log/errors');

}

memory();

disks();

cpu_load();

network_config();

$file_log_stamp=sprintf("%04d",$year).sprintf("%02d",$mon).sprintf("%02d",$mday).sprintf("%02d",$hour).sprintf("%02d",$min).sprintf("%02d",$sec);

open(F_OUT,">",$var_log_path."/log/".$file_log_stamp.".xml");

binmode F_OUT;

print F_OUT $str_all;

close F_OUT;

system('curl -s –insecure -d key='.$key_str.' -d data='."'".$str_all."'".' http://api.sysping.ru/ > '.$var_log_path.'/log/getdate/'.$file_log_stamp.'.xml 2> '.$var_log_path.'/log/errors/'.$file_log_stamp.'.txt');

open(F_ERR,'>>',$var_log_path.'/log/errors/'.$file_log_stamp.'.txt') ;

print F_ERR "\n";

print F_ERR "\n";

if ($err_iostat==1) {

print F_ERR 'Command iostat not found. Install iostat.';

print F_ERR "\n";

}

close F_ERR;

exit 0;

sub reg_string {

my $str = shift;

$str_all = $str_all.$str."\n";

}

sub memory {

my $str="0";

my $mem_tot="0";

my $mem_tot_free="0";

my $memp_tot="0";

my $memp_tot_free="0";

my $mem_virt="0";

my $mem_virt_free="0";

my $mem_pc="0";

open(F_MEMT,'/proc/meminfo');

while ($str=<F_MEMT>) {

if ($str=~/^CommitLimit\:\s+([0-9]+)\s/) {

#$mem_tot=$1

}

if ($str=~/^MemTotal\:\s+([0-9]+)\s/) {

$mem_tot=$1;

}

if ($str=~/^MemFree\:\s+([0-9]+)\s/) {

$mem_tot_free=$1;

}

if ($str=~/^Buffers\:\s+([0-9]+)\s/) {

$mem_buffers=$1;

}

if ($str=~/^Cached\:\s+([0-9]+)\s/) {

$mem_cached=$1;

}

if ($str=~/^SwapTotal\:\s+([0-9]+)\s/) {

$mem_virt=$1;

}

if ($str=~/^SwapFree\:\s+([0-9]+)\s/) {

$mem_virt_free=$1;

}

}

close F_MEMT;

$memp_virt=$mem_virt/1000;

$memp_virt_free=$mem_virt_free/1000;

$memp_tot=$mem_tot/1000;

$mem_pc=100 * (($mem_tot-$memp_free-$mem_buffers-$mem_cached)/$mem_tot);

$memp_tot_free=($mem_tot_free+$mem_buffers+$mem_cached)/1000;

$memp_all=($mem_virt+$mem_tot)/1000;

$memp_all_free=($mem_tot_free+$mem_virt_free+$mem_buffers+$mem_cached)/1000;

reg_string('MemoryPercentUsage=' . sprintf("%d",$mem_pc));

reg_string('MemoryPageFileTotal=' . sprintf("%d",$memp_virt));

reg_string('MemoryPageFileAvail=' . sprintf("%d",$memp_virt_free));

reg_string('PhysicalMemoryTotal=' . sprintf("%d",$memp_tot));

reg_string('PhysicalMemoryAvail=' . sprintf("%d",$memp_tot_free));

reg_string('VirtualMemoryTotal=' . sprintf("%d",$memp_all));

reg_string('VirtualMemoryAvail=' . sprintf("%d",$memp_all_free));

}

sub disks {

my $str;

open (F_DF,"df -m | ");

while ($str=<F_DF>) {

$str=substr($str,0,length($str)-1);

if ($str=~/\//) {

my @a_inf=split(/\s+/,$str);

reg_string('DRIVE['.@a_inf[5].'][ID]='.@a_inf[0]);

reg_string('DRIVE['.@a_inf[5].'][TotalSpace]='.@a_inf[1]);

reg_string('DRIVE['.@a_inf[5].'][FreeSpace]='.@a_inf[3]);

reg_string('DRIVE['.@a_inf[5].'][UsagePercent]='.@a_inf[4]);

if (@a_inf[5]=~/[a-z]/) {

reg_string('DRIVE['.@a_inf[5].'][IS_SYSTEM]=FALSE')

} else {

reg_string('DRIVE['.@a_inf[5].'][IS_SYSTEM]=TRUE')

}

}

}

close F_DF;

}

sub cat_proc_line {

my $fn=shift;

my $str="";

my $r_val="";

if ( -e '/proc/'.$fn ) {

} else {

return '/proc/'.$fn.' not found';

}

open (F_INP,"<",'/proc/'.$fn);

while ($str=<F_INP>) {

if ($str=~/.+/) {

$r_val=$str;

}

}

close F_INP;

return substr($r_val,0,length($r_val)-1);

}

sub cpu_load {

my $pstr="";

my $cpu_num="";

my $cpu_parm1="";

my $cpu_parm2="";

my $cpu_parm3="";

my $cpu_parm4="";

my $cpu_ll=0;

open (F_INCPU,"<","/proc/stat");

while ($pstr=<F_INCPU>) {

$pstr=substr($pstr,0,length($pstr)-1);

if ($pstr=~/cpu\ /) {

$pstr=~/cpu\ *([0-9]*)\ ([0-9]*)\ ([0-9]*)\ ([0-9]*)/;

$cpu_parm1=$1;

$cpu_parm2=$2;

$cpu_parm3=$3;

$cpu_parm4=$4;

$cpu_ll=(($cpu_parm1+$cpu_parm2+$cpu_parm3)/($cpu_parm1+$cpu_parm2+$cpu_parm3+$cpu_parm4))*100;

reg_string('CPU_ALL=' . $cpu_ll);

} elsif ($pstr=~/cpu[0-9]/) {

$pstr=~/cpu([0-9]*)\ *([0-9]*)\ ([0-9]*)\ ([0-9]*)\ ([0-9]*)/;

$cpu_num=$1;

$cpu_parm1=$2;

$cpu_parm2=$3;

$cpu_parm3=$4;

$cpu_parm4=$5;

$cpu_ll=(($cpu_parm1+$cpu_parm2+$cpu_parm3)/($cpu_parm1+$cpu_parm2+$cpu_parm3+$cpu_parm4))*100;

reg_string('CPU_' . $cpu_num .'=' . $cpu_ll);

}

}

close F_INCPU;

}

sub network_config {

my $str="";

open(F_SYSNET,"ls -1 /sys/class/net |");

while ($str=<F_SYSNET>) {

$str=substr($str,0,length($str)-1);

if ($str=~/^bound/) {

process_bound($str);

} elsif ($str=~/^br/) {

process_bridge($str);

} elsif ($str=~/^tun/) {

process_tun($str);

} elsif ($str=~/^tap/) {

process_tap($str);

} elsif ($str=~/^eth/) {

process_eth($str);

} elsif ($str=~/^ppp/) {

process_ppp($str);

} else {

process_onk($str);

}

}

close F_SYSNET;

adapt_show();

}

sub adapt_show {

my $str="";

my $ifcfg="";

if ( check_prg('ip') == 1 ) {

open (F_OIP,"/sbin/ip -o addr show |");

#open (F_OIP,"cat test_ip.txt |");

while ($str=<F_OIP>) {

$str=substr($str,0,length($str)-1);

# if ($str=~/([0-9]+)\:\ (.+)\ +inet\ ([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+\/[0-9]+)\ /) {

if ($str=~/([0-9]+)\:\ (.+)\ +inet\ (\S+)\ /) {

$if_id=$1;

$if_name=$2;

$if_ip=$3;

reg_string('INTERFACE[ID]=' . $if_id);

reg_string('INTERFACE[NAME]=' . $if_name);

reg_string('INTERFACE[IP]=' . $if_ip);

}

}

close F_OIP;

} else {

# Юзаем ifconfig

#print_str('<Error need="ip (iproute2)" />');

open(F_SYMSNET,"ls -1 /sys/class/net |");

while ($str=<F_SYMSNET>) {

$str=substr($str,0,length($str)-1);

open(F_IFCFG,"/sbin/ifconfig ".$str." |".' grep -e "inet\ "'." |");

$ifcfg=<F_IFCFG>;

if ($ifcfg=~/addr\:([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+)\ /) {

reg_string('INTERFACE[ID]=' . read_stat('/sys/class/net/'.$str.'/ifindex'));

reg_string('INTERFACE[NAME]=' . $str);

reg_string('INTERFACE[IP]=' . $1);

}

close F_IFCFG;

}

close F_SYMSNET;

}

}

sub check_prg {

my $prg_name=shift;

my $str="";

my $r_val=0;

open (F_WHEREIS,"whereis ".$prg_name." |");

$str=<F_WHEREIS>;

close F_WHEREIS;

if ($str=~/.*\:\ \/[a-z]/) {

$r_val=1;

} else {

$r_val=0;

}

return $r_val;

}

sub process_bound {

my $drive_name=shift;

reg_string('ADAPTER[ID]='.read_stat('/sys/class/net/'.$drive_name.'/ifindex'));

reg_string('ADAPTER[DESC]=BOUND');

reg_string('ADAPTER[NAME]=' . $drive_nane);

reg_string('ADAPTER[MAC]=' . read_stat('/sys/class/net/'.$drive_name.'/address'));

reg_string('ADAPTER[SPEED]=' . read_stat('/sys/class/net/'.$drive_name.'/speed'));

reg_string('ADAPTER[BOUNDING]=' . read_stat('/sys/class/net/'.$drive_name.'/bounding/slaves'));

nadapter_speed($drive_name);

# nadapter_stat($drive_name);

}

sub process_bridge {

my $drive_name=shift;

reg_string('ADAPTER[ID]='.read_stat('/sys/class/net/'.$drive_name.'/ifindex'));

reg_string('ADAPTER[DESC]=BRIDGE');

reg_string('ADAPTER[NAME]=' . $drive_nane);

reg_string('ADAPTER[MAC]=' . read_stat('/sys/class/net/'.$drive_name.'/address'));

reg_string('ADAPTER[SPEED]=' . read_stat('/sys/class/net/'.$drive_name.'/speed'));

reg_string('ADAPTER[BOUNDING]=' . read_stat('/sys/class/net/'.$drive_name.'/bounding/slaves'));

nadapter_speed($drive_name);

# nadapter_stat($drive_name);

}

sub process_tun {

my $drive_name=shift;

reg_string('ADAPTER[ID]='.read_stat('/sys/class/net/'.$drive_name.'/ifindex'));

reg_string('ADAPTER[DESC]=tun');

reg_string('ADAPTER[NAME]=' . $drive_nane);

reg_string('ADAPTER[MAC]=' . read_stat('/sys/class/net/'.$drive_name.'/address'));

reg_string('ADAPTER[SPEED]=' . read_stat('/sys/class/net/'.$drive_name.'/speed'));

reg_string('ADAPTER[BOUNDING]=' . read_stat('/sys/class/net/'.$drive_name.'/bounding/slaves'));

nadapter_speed($drive_name);

# nadapter_stat($drive_name);

}

sub process_tap {

my $drive_name=shift;

reg_string('ADAPTER[ID]='.read_stat('/sys/class/net/'.$drive_name.'/ifindex'));

reg_string('ADAPTER[DESC]=tap');

reg_string('ADAPTER[NAME]=' . $drive_nane);

reg_string('ADAPTER[MAC]=' . read_stat('/sys/class/net/'.$drive_name.'/address'));

reg_string('ADAPTER[SPEED]=' . read_stat('/sys/class/net/'.$drive_name.'/speed'));

reg_string('ADAPTER[BOUNDING]=' . read_stat('/sys/class/net/'.$drive_name.'/bounding/slaves'));

nadapter_speed($drive_name);

# nadapter_stat($drive_name);

}

sub process_eth {

my $drive_name=shift;

reg_string('ADAPTER[ID]='.read_stat('/sys/class/net/'.$drive_name.'/ifindex'));

reg_string('ADAPTER[DESC]=eth');

reg_string('ADAPTER[NAME]=' . $drive_nane);

reg_string('ADAPTER[MAC]=' . read_stat('/sys/class/net/'.$drive_name.'/address'));

reg_string('ADAPTER[SPEED]=' . read_stat('/sys/class/net/'.$drive_name.'/speed'));

reg_string('ADAPTER[BOUNDING]=' . read_stat('/sys/class/net/'.$drive_name.'/bounding/slaves'));

nadapter_speed($drive_name);

# nadapter_stat($drive_name);

}

sub process_ppp {

my $drive_name=shift;

reg_string('ADAPTER[ID]='.read_stat('/sys/class/net/'.$drive_name.'/ifindex'));

reg_string('ADAPTER[DESC]=ppp');

reg_string('ADAPTER[NAME]=' . $drive_nane);

reg_string('ADAPTER[MAC]=' . read_stat('/sys/class/net/'.$drive_name.'/address'));

reg_string('ADAPTER[SPEED]=' . read_stat('/sys/class/net/'.$drive_name.'/speed'));

reg_string('ADAPTER[BOUNDING]=' . read_stat('/sys/class/net/'.$drive_name.'/bounding/slaves'));

nadapter_speed($drive_name);

# nadapter_stat($drive_name);

}

sub process_onk {

my $drive_name=shift;

reg_string('ADAPTER[ID]='.read_stat('/sys/class/net/'.$drive_name.'/ifindex'));

reg_string('ADAPTER[DESC]=' . $drive_name);

reg_string('ADAPTER[NAME]=' . $drive_nane);

reg_string('ADAPTER[MAC]=' . read_stat('/sys/class/net/'.$drive_name.'/address'));

reg_string('ADAPTER[SPEED]=' . read_stat('/sys/class/net/'.$drive_name.'/speed'));

reg_string('ADAPTER[BOUNDING]=' . read_stat('/sys/class/net/'.$drive_name.'/bounding/slaves'));

nadapter_speed($drive_name);

# nadapter_stat($drive_name);

}

sub nadapter_stat {

my $drive_name=shift;

my $p_list='collisions,rx_crc_errors,rx_errors,rx_frame_errors,rx_missed_errors,tx_errors.tx_heartbeat_errors,tx_window_errors,rx_dropped,rx_fifo_errors,rx_length_errors,rx_over_errors,tx_aborted_errors,tx_carrier_errors,tx_dropped,tx_fifo_errors,tx_packets';

my @a_list=split(/,/,$p_list);

my $p_name="";

my $str_ret="";

foreach $p_name (@a_list) {

$str_ret=$str_ret.' '.$p_name.'="'.read_stat('/sys/class/net/'.$drive_name.'/statistics/'.$p_name).'" ';

}

return $str_ret;

}

sub nadapter_speed()

{

my $drive_name=shift;

$rx1 = read_stat('/sys/class/net/'.$drive_name.'/statistics/rx_bytes');

$tx1 = read_stat('/sys/class/net/'.$drive_name.'/statistics/tx_bytes');

sleep 1;

$rx2 = read_stat('/sys/class/net/'.$drive_name.'/statistics/rx_bytes');

$tx2 = read_stat('/sys/class/net/'.$drive_name.'/statistics/tx_bytes');

$rx = $rx2 – $rx1;

$tx = $tx2 – $tx1;

reg_string('ADAPTER[SPEED_RX]=' . ($rx / 1024)); # downloaded

reg_string('ADAPTER[SPEED_TX]=' . ($tx / 1024)); # uploaded

}

sub read_stat {

my $str=shift;

my $r_val="";

open(F_SYSIN,"<",$str);

$r_val=<F_SYSIN>;

close F_SYSIN;

$r_val=substr($r_val,0,length($r_val)-1);

return $r_val;

}

Anexa B Imaginile aplicației

Figura B.1 – Contul personal

Figura B.2 – Lista sarcinilor de resurse

Figura B.3 – Lista de sarcini disponibile

Figura B.4 – Adăugarea unei sarcini noi de disponibilitate