Dokumentasjonsstøttesystemet i banken vår er i stadig utvikling og skalering, og kravene til hastighet og feiltoleranse bare øker. På et tidspunkt ble det for risikabelt å opprettholde et LMS uten effektiv sentralisert overvåking. For å sikre forretningsprosesser hos VTB og forenkle arbeidet til administratorer, implementerte vi en løsning basert på en stabel med åpne teknologier. Med dens hjelp kan vi reagere proaktivt på hendelser og forhindre potensielle problemer. Under snittet er en historie om vår erfaring med å bruke gratis programvare for å overvåke store forretningssystemer.
Hvorfor overvåke dokumenthåndteringssystemet ditt?
Siden 2005 har dokumentasjonsstøtte hos VTB Bank blitt "administrert" av CompanyMedia-systemet. LMS sysselsetter over 60 tusen brukere som lager mer enn en million nye dokumenter hver måned. Serverne våre må fungere 24 timer i døgnet: tilnærmet ethvert øyeblikk er det 2500–3000 personer i systemet, som er tilkoblet over hele landet, fra Petropavlovsk-Kamchatsky til Kaliningrad. Hvert sekund av LMS-drift betyr 10–15 endringer.
For å sikre at systemet nøyaktig oppfyller de tildelte oppgavene, har vi distribuert en feiltolerant infrastruktur som bruker proxy-servere, forespørselsbalansering, informasjonsbeskyttelse, fulltekstsøk, integrasjonsruter og sikkerhetskopiering. Å støtte og administrere et prosjekt av denne skalaen krever enorme ressurser. Administratorer overvåker grunnleggende informasjon om serverdrift, RAM-belastning, CPU-tid, I/O-undersystem og så videre døgnet rundt. Men i tillegg til dette trengs mer subtile analyser:
- beregne tiden brukt på å utføre forretningsscenarier;
- overvåke dynamikken i systemytelsen og belastningen på den;
- søke etter avvik i systemkomponenter fra godkjente ikke-funksjonelle krav.
11 år etter innføringen av LMS har spørsmålet om proaktiv respons på ulike typer feil blitt spesielt akutt. Bankens ledelse innså at det å jobbe uten skjermer og en systemlivskonsoll lekte med ilden: den minste feil i et forretningssystem på dette nivået kan resultere i millioner i tap.
I 2016 begynte vi å introdusere verktøy for raskt å identifisere problemer i funksjonen til LMS, inkludert overvåking av parametere av interesse for oss i sanntid. Tidligere ble det anvendte overvåkingssystemet distribuert og testet innenfor rammen av InterTrust-selskapets infrastruktur.
Hvordan alt begynte
I dag hjelper det sentraliserte applikasjonsovervåkingssystemet til VTB LMS, basert på programvareprodukter med åpen kildekode, med å forhindre de fleste feil knyttet til dokumentflyt, raskt og nøyaktig klassifisere problemer og reagere raskt på eventuelle hendelser. Den inkluderer to delsystemer:
- for overvåking av IT-infrastrukturen til systemtjenester;
- å overvåke forekomsten av feil i driften av LMS.
Det hele startet med en enkelt gratis overvåkingsapp. Etter å ha gått gjennom flere alternativer bestemte vi oss for Zabbix – gratis programvare som opprinnelig ble skrevet for banktjenester og utstyr. Dette PHP nettbaserte systemet, som kan lagre data i MySQL, PostgreSQL, SQLite eller Oracle Database, passet perfekt for våre behov.
Zabbix kjører sine agenter på hver server og samler informasjon om målinger av interesse i sanntid i en enkelt database. Ved å bruke applikasjonen er det praktisk å samle inn data om belastningen på prosessorer og RAM, om bruken av nettverket og andre komponenter, sjekke tilgjengeligheten og responsen til standardtjenester (SMTP eller HTTP), kjøre eksterne programmer og støtte overvåking via SNMP.
Etter å ha distribuert Zabbix, konfigurerte vi standard maskinvareberegninger, og først var dette nok. Men VTB SDO utvikler seg og vokser stadig: i 2016 økte antallet servere merkbart, migrasjonsprosesser dukket opp, Bank of Moscow, VTB Capital og VTB24 ble med i systemet. Det er ikke lenger nok standardverdier, og vi lærte Zabbix å spore informasjon om tilstedeværelsen av køer på hvert av volumene som er koblet til serveren (ut av esken reflekterer Zabbix bare den generelle diskkøen), samt tiden det tar for å fullføre en bestemt prosedyre.
I tillegg utstyrte vi systemet med flere utløsere - betingelser der et varsel sendes til administratoren (en melding i Telegram, en SMS til et telefonnummer eller en e-post). Utløsere kan konfigureres for ethvert sett med parametere. Du kan for eksempel spesifisere en viss prosentandel ledig diskplass, og systemet vil varsle administratoren når den angitte terskelen er nådd, eller informere deg om en bakgrunnsprosedyre kjører lenger enn vanlig.
Java-tilkobling og datavisualisering
Vi utvidet utvalget av analyserte data betydelig, men snart var dette ikke nok for effektiv overvåking. Ved å utnytte det faktum at CompanyMedias LMS er en Java-applikasjon, koblet vi til Java Virtual Machine via JMX-grensesnittet og var i stand til å ta Java-målinger direkte. Og ikke bare standard parametere for Java vital aktivitet, som GC arbeidsintensitet eller Heap forbruk, men også spesifikke tester knyttet direkte til den kjørbare applikasjonskoden.
I 2017, omtrent et år etter implementeringen av overvåkingssystemet, ble det klart at for å kunne jobbe normalt med den kolossale mengden data som ble samlet inn i Zabbix, var det ikke nok visualisering – komplekse skjermer. Den beste løsningen på dette problemet var igjen gratis programvare – Grafana, et praktisk dashbord for beregninger som lar deg samle alle data på én skjerm.
Grafana-grensesnittet er interaktivt, og minner om et OLAP-system. Delsystemet viser dataene mottatt av Zabbix på en enkelt skjerm, og presenterer informasjonen i form av grafer og diagrammer som er enkle å analysere. Administratoren kan enkelt tilpasse skivene han trenger.
Overvåking og forebyggende eliminering av feil i LMS-systemet
ELK programvareplattform med åpen kildekode hjelper deg med å filtrere og analysere informasjonen som mottas under overvåking. Dette opensource-produktet består av tre kraftige verktøy for å samle inn, lagre og analysere data: Elasticsearch, Logstash og Kibana. Implementeringen av dette undersystemet gjør det spesielt mulig å se i sanntid hvor mange feil som oppsto i systemet, på hvilke servere og om disse feilene gjentas.
Nå kan administratoren oppdage et problem på et tidlig stadium, selv før brukeren støter på det. Slik proaktiv overvåking lar deg forhindre systemfeil ved å eliminere feil i tide. I tillegg kan vi forstå hvordan systemets oppførsel har endret seg etter oppdateringen, samt oppdage nye problemer hvis de dukker opp.
Virksomhetsovervåking
I tillegg til de grunnleggende funksjonene for overvåking av ressursforbruk, har systemet muligheten til å analysere og kontrollere forretningsdrift.
Overvåking av den samlede gjennomføringstiden for forretningsdrift lar deg identifisere nye faktorer og forstå hvilken innvirkning de har på driften av systemet.
Overvåking av utførelsestiden for forespørsler for hver forretningstjeneste gjør det mulig å oppdage operasjoner som avviker fra normen.
Skjermbildet ovenfor er et eksempel på overvåking av en bakgrunnsoppgave når det gjelder dens avvik fra normen.
Listen over kontrollerte oppgaver når det gjelder deres aktivitet på en spesifikk server lar deg identifisere feil – inkludert duplisering av oppgavekjøring – på tvers av alle servere.
Trender i utførelsestiden for bakgrunnsprosedyrer overvåkes også.
Systemet vokser, utvikler seg og hjelper til med å takle problemer
Med implementeringen av det beskrevne systemet har overvåking av driften av LMS-servere blitt betydelig forenklet. Ikke desto mindre oppstår det fra tid til annen ulike typer konflikter som påvirker hastigheten på dokumentflyten og forårsaker klager fra brukerne. Så vi innså at det var nødvendig å kontrollere oppførselen til selve applikasjonen, og ikke bare serverne.
For å løse dette problemet ble en balanser koblet til overvåkingssystemet via API, som fungerer med en klynge av applikasjonsservere. Takket være dette kan administratoren se hvor lang tid det tar serveren å svare på hver brukerforespørsel.
Data om serverresponstider ble tilgjengelig for analyse, noe som gjorde det mulig å koble nedbremsingen av LMS med prosessene som skjer på serveren. Spesielt dukket det opp en interessant situasjon: serveren kjører sakte, selv om den for øyeblikket ikke er lastet. Ved å analysere anomalien oppdaget vi avvik i driften av Garbage Collector Java. Til slutt viste det seg at det var feil drift av denne tjenesten som førte til denne situasjonen. Ved å ta kontroll over Garbage Collector Java, eliminerte vi problemet fullstendig.
Slik hjelper fri programvare dokumenthåndteringssystemet i banknæringen med å utvikle og vokse. Vi har kun berørt hovedproblemene knyttet til VTB SDO-overvåkingssystemet. Hvis du er interessert i detaljer, spør i kommentarene, vi vil gjerne dele vår erfaring med deg.
Kilde: www.habr.com