Forord. Javaprogrammering Database Overvåking / Statistikk JSP / Java web teknologi

Transkript

1

2 Forord Prosessrapport for hovedprosjekt våren 2009 ved Høgskolen i Oslo avdeling for ingeniørutdanning, datalinjen. Gruppen består av tre medlemmer, Younes Hajji, Mo Amini og Diyar Amin. Gruppemedlemmene kjente hverandre fra før og sammarbeidet på tidligere prosjekter. Derfor valgte gruppen å utføre hovedprosjektet sammen. I begynnelsen av oktober 2008 begynte gruppen å planlegge og diskutere hovedprosjektet. Gruppen kom fram til følgende generelle ønsker for prosjektet: Javaprogrammering Database Overvåking / Statistikk JSP / Java web teknologi Disse ønskene ble innfridd i prosjektet for Redpill Linpro AS (heretter referert til som oppdragsgiveren ). 2

3 Innhold Forord...2 Innledning Dagens situasjon Valg av prosjektet Om Oppdragsgiveren Om Munin Bruksområder Munin Plugin Kodebeskrivelse Mål og rammebetingelser Mål Rammebetingelser Planlegging og arbeidsmetode Planlegging Gruppen Startfasen Arbeidsfordeling Rollene Samarbeid Møter Fremdriftsplan Risikoanalyse... 18

4 2.4 Verktøy og programmer Hva måtte gruppen lære Utviklingsprosessen Generelt Problemer underveis Installasjon av JBoss Munin JMX Avslutning Oppsummering Hva kunne vært gjort bedre Framtiden Konklusjon Kildehenvisning

5 1. Innledning 1.1 Dagens situasjon Overvåking av JVM ressurser er interessant og viktig for oppdragsgiveren. Oppdragsgiveren har systemer som overvåker ressursbruk. Slik det fungerer i dag blir dataene hentet ut fra loggfiler. Disse loggfilene blir generert ved at JVM blir startet med verbose prefix. Det er flere ulemper med denne metoden som oppdragsgiveren ønsker å eliminere. Logparsing kan være ressurskrevende når loggfiler blir store. Den største ulempen med loggparsing som oppdragsgiveren har erfart er at formatet endrer seg veldig ofte med versjonsendringer. Dermed knekker også koden og dette medfører mye tid til å oppdatere parsingen for hver versjon. Fordelen med å benytte JMX for å hente ut dataene framfor logparsing: Alle javadistribusjoner fra versjon 1.5 har implementert JMX Effektiv Enkel i bruk Ikke endringer i formatet Kan enkelt implementeres for applikasjoner som har implementert MBeans interfacet Gjenbruk av kode 5

6 1.2 Valg av prosjektet Etter svar på vår første e-post til oppdragsgiveren holdt vi et møte med dem. Muninproblematikken ble presentert og gruppen fikk et overblikk av oppgaven og arbeidet som måtte gjøres. Da gruppen ikke hadde benyttet JMX før dette prosjektet visste vi lite om omfanget og hvor mye vi måtte studere for å oppfylle oppdragsgiverens ønsker. Etter en forstudie av JMX fikk vi et større innblikk i hva teknologien gikk ut på, hvordan den skulle brukes og hva vi var i stand til å utnytte den til. Dette var en milepæl og vi skrev en kravspesifikasjon med alt vi kunne utnytte teknologien til. Prosjektet bygger på god kunnskap om operativsystemer og ressursbruk, særlig minnebruk. Kjennskap til Unix administrasjon og kommandobruk har vært en sentral del av prosjektet. Vi har programmert i Java og Shell og benyttet oss av SQL databaser for testing og validering. Dessuten har vi benyttet JSP for å teste Tomcat ved å lage programmer som benytter og fyller opp minnet. Dette samsvarer med hva vi ønsket oss før vi fikk en oppdragsgiver. På denne måten har vi benyttet kunnskap og teknikker vi har lært i mange fag på studiet. 1.3 Om Oppdragsgiveren Redpill Linpro er Nordens ledende totalleverandør av produkter og tjenester rundt fri programvare, og de har 180 ansatte inkluderer noen av markedets fremste eksperter på sine fagområder. Deres fokus er på leveranse av produkter og tjenester basert på fri programvare. De tilbyr profesjonell rådgivning, utviklingstjenester, kurs, support, applikasjonsforvaltning og drift rundt flere av de verdensledende fri programvare-produktene fra infrastruktur, databaser, middleware, og forretningssystemer til kundetilpassede løsninger basert på åpen kildekodekomponenter. 6

7 I tillegg er Redpill Linpro involvert i en rekke åpen kildekodeprosjekter for å sikre markedet fleksible og profesjonelle produkter og tjenester basert på åpne standarder. Mange virksomheters IT-behov kan i dag dekkes av velprøvde, fleksible og kostnadseffektive løsninger basert på fri programvare. Redpill Linpros solide erfaring med og spisskompetanse på fri programvare sikrer nordiske virksomheter en pålitelig partner. Redpill Linpro har kunder i alle nordiske land og kontor i Stockholm, Oslo, København, Helsinki, Karlstad, Gøteborg og Stavanger. 1.4 Om Munin Munin er et rammeverk utviklet av Redpill Linpro for å produsere grafer på en systematisk og enkel måte i et Unix miljø. Munin benytter RRD Tool for å generere det grafiske og er skrevet I Perl. Munin vil per dags dato plotte grafer hvert 5te minutt. Noe som kan være et problem dersom man har topper som varer i en kort periode som man vil vite om. En liten forbedring på situasjonen er at man kan få munin til å hente ut data hvert minutt og deretter plotte snittet for disse 5 tallene hvert 5te minutt. Dette vil fortsatt være et problem for korte topper men er en forbedring. 1.5 Bruksområder I stor grad har Munin blitt benyttet til å overvåke ressurser I Unix miljø som CPU, Minne, Harddisk, Temperatur og mye annet. Det er derimot ingen begrensninger for hva man kan plotte så lenge man tilfredsstiller kravene for en Munin plugin. 1.6 Munin Plugin For å lage en enkel graf med Munin kreves det en viss minimal standard i scriptet. Det kan bli skrevet i Java, perl, c, eller rett og slett hvilket som helst språk som kan generere utskrift og 7

8 bli kjørt i et Unix miljø. Vi har valgt å skrive pluginene i Shell script som starter Java programmene som benytter JMX. Figur 1, Viser en Munin graf mens kode 1 viser en minimal konfigurasjon for et Munin script market med blå farge. Figur 1 8

9 /etc/munin/plugins/daemonthreadcount import java.lang.management.managementfactory; import java.lang.management.threadmxbean; import javax.management.mbeanserverconnection; import javax.management.remote.jmxconnector; import javax.management.remote.jmxconnectorfactory; import javax.management.remote.jmxserviceurl; public class DaemonThreadCount { public static void main(string args[]) { if (args.length == 1) { if (args[0].equals("config")) { System.out.println( "graph_title DaemonThreadCount\n" + "graph_vlabel DaemonThreadCount\n" + "graph_info Returns the current number of live daemon threads.\n" + "graph_category Tomcat\n" + "DaemonThreadCount.label DaemonThreadCount\n"); } } else { try { JMXServiceURL u = new JMXServiceURL("service:jmx:rmi:///jndi/rmi://" + " " + ":" "/jmxrmi"); JMXConnector c = JMXConnectorFactory.connect(u); MBeanServerConnection connection = c.getmbeanserverconnection(); ThreadMXBean threadmxbean = ManagementFactory.newPlatformMXBeanProxy(connection, ManagementFactory.THREAD_MXBEAN_NAME, ThreadMXBean.class); System.out.println("DaemonThreadCount.value " + threadmxbean.getdaemonthreadcount()); } catch (Exception e) { System.out.print(e); } } } } Kode 1.1 DaemonThreadCount.java kompileres og classfilen legges i /etc/munin/java/ 9

10 1.7 Kodebeskrivelse Linjer og 29 (merket med blå bakgrunn) i kode 1.1 er obligatoriske deler av en Munin plugin. Uten disse utskriftene ville ikke Munin pluginen vært gyldig og derfor ikke fungert. Munin trenger disse feltene for å vite overskriftnavnet til grafen, navn på akser, hvilken kategori pluginen vil falle i og til slutt navn og verdi til variable. Resterende kode henter ut variable verdier. I dette prosjektets tilfelle vil det være JMX kode som setter opp en tilkobling til gjeldende IP-adresse og port som aktuell MBean server lytter på. 1.8 Mål og rammebetingelser Mål Prosjektet har som formål å løse svakheten som Munin har for Java. Oppdragsgiveren, som står bak Munin rammeverket fikk ideen om å overvåke aktiviteter og ressurser for en JVM, for å ha oversikt over minnebruk og kunne lettere lokalisere feil på serveren. Dette kan også benyttes som et verktøy i utviklingssammenheng. Scenario 1: Bedrift X utvikler en applikasjon Y versjon 1.0 skrevet i Java. Fra begynnelsen blir et MBean server interface implementert i applikasjonen og ressurser blir overvåket med JMX pluginer. Etter en periode med videreutvikling av applikasjon Y blir versjon 1.1 sluppet. Utviklere i bedrift X ser øyeblikkelig en stor økning i minnebruk for applikasjon Y. Utviklerne går raskt i gang med å finne ut av hva som kan forårsake dette. Utfall 1: Utviklere i bedrift X finner en ofte brukt løkke som ikke er optimal. De optimaliserer koden og minnebruken går ned. 10

11 Utfall 2: Utviklere i bedrift X finner ingen feil eller uoptimal kode. De forventer at minnebruken skal øke da de har lagt til funksjonalitet som er minneintensiv i applikasjon Y. Konklusjon: Produktet vi har utviklet vil overvåke ressursbruken til en ønsket JVM instans. De er ikke nødvendigvis laget for å vise om instansen kjører optimalt. Derimot er det veldig nyttig for oppdragsgiver å overvåke trender i ressursbruken slik at oppdragsgiver kan fastsette en normal og deretter finne avvik i driften Rammebetingelser Rammebetingelsene for dette prosjektet har vært kort og presist. Vi skulle ikke benytte oss av loggfiler for å lage våre grafer da det har hatt problemer med formatendringer. 11

12 2. Planlegging og arbeidsmetode 1.1 Planlegging Dette kapitelet beskriver både gruppen, samarbeidet og arbeidsmetodene gruppemedlemmene brukte under utviklingsprosessen Gruppen Navn Younes Hajji Mo Amini Diyar Amin Rolle Leder Web ansvarlig & tillitsmann Sekretær Startfasen Etter mange e-poster til forskjellige bedrifter kom gruppen i kontakt med oppdragsgiveren som ville gi gruppen et interessant prosjekt å jobbe med. Ved første møte med oppdragsgiveren kom det frem at gruppen ønsket å jobbe med Java teknologi, gjerne statistikk med Munin. Tilstede på møtet var gruppemedlemmene og Per Buer som er leder for infrastruktur og drift. Gruppen kom raskt til enighet med oppdragsgiveren om å jobbe med overvåking av Java ressurser i Munin. Problemstillingen er at Munin har en softspot for Java, og det er meget interessant for oppdragsgiveren å overvåke de innebygde ressursene. Men det har vist seg å være ustabilt å hente denne informasjonen via Munin med proprietære metoder. Derfor ønsker oppdragsgiveren plugin for Apache Tomcat og Jbosss for overvåkning. Hensikten med prosjektet er å gjøre det enklere for oppdragsgiveren og andre som benytter seg av Munin å overvåke ressursene til en JMV instans. 12

13 I startfasen slet gruppen med å få tildelt en veileder. Vi var den siste gruppen som fikk tildelt dette og gruppen mener de kom 1 til 2 uker for sent i gang på grunn av dette. Gruppen leverte prosjektskisse og forprosjekt uten å ha en veileder. Dette hadde sine konsekvenser for utviklingsprosessen, men gruppen klarte å dra seg inn etter hvert. Den 2.feb.2009 fikk gruppen tildelt Hårek Haugerud som veileder. De tok raskt et møte med Hårek for å forklare hvor langt gruppen hadde kommet og hva gruppemedlemmene jobbet med Arbeidsfordeling Da ingen i gruppen hadde jobbet med JMX tidligere var det spennende for alle å studere teknologien og lære seg denne. Derfor gikk det mye tid i begynnelsen på å komme over terskelen med å benytte JMX. Arbeidsfordelingen var derfor lik de første ukene. Dette hadde sine fordeler og ulemper. Det kostet gruppen mye tid i begynnelsen da alle jobbet med det samme og ingenting annet ble gjort. Derimot sparte vi inn tid etter hvert når vi begynte med implementeringen av pluginene og skrive Java koden som skulle brukes. I løpet av denne senere perioden ble det skrevet mye kode på kort tid. Etter en måned hadde gruppen god oversikt over hvor mye arbeid som var forventet og hva prosjektet spesifikt gikk ut på. Derfor ble arbeidet fordelt slik at gruppemedlemmene hadde hvert sitt ansvarsområde som de var mest interessert å jobbe med Rollene Younes Hajji ble valgt til leder. Hans hovedoppgave var å holde møter og føre inn møtereferater i websidene sammen med Diyar. Han hadde også hovedansvaret for produktrapporten. Mo Amini var web ansvarlig, han satt opp og administrerte wikisidene og tok bakup jevnlig. Han hadde hovedansvaret for installering og drift av nødvendige programmer på den virtuelle maskinen og hans server hjemme som inneholder wikisidene og andre dokumenter. Dessuten var Mo talsmannen i gruppen, det var han som kommuniserte med veilederen, oppdragsgiveren og gruppen. Han hadde også som oppgave å hjelpe Diyar med prosessrapport og Younes med produktrapport når han hadde tid til det. I tillegg fikk han ansvaret for testrapporten samt mye av programmeringen. 13

14 Diyar Amin tildelt sekretærjobben. Han skrev inn møtereferatene sammen med Younes. Han hadde hovedansvaret for SQL database testingen under prosjektet. Han jobbet også med JMX programmeringen. Han hadde hovedansvaret for prosessrapporten. Til slutt fikk Diyar rollen å hjelpe Mo med testrapporten Samarbeid Samarbeidet i gruppen Gruppen jobbet sammen som regel i grupperom eller andre steder. Det har vært åpne diskusjoner om hvordan de skal løse forskjellige aspekter av prosjektet. Spørsmål og ideer har kommet løpende og blitt diskutert i gruppen. Når en person har sittet fast på et problem har de andre i gruppen sett på problemet og kommet med forslag til løsning. Da alt har vært lastet opp på serveren og på wikisidene har det vært enkelt å se på hva andre har gjort. Og det har vært enkelt å laste ned andres kode for å se nærmere på et problem. Store deler av kodingen har vært lik og derfor har løsninger på andres problemet kommet fort når en person har funnet en løsning Samarbeid med oppdragsgiver I startfasen hadde gruppen kontakt med en person fra oppdragsgiveren, Per Buer, som ga gruppen en introduksjon om Redpill Linpro AS og generelt om Munin. Deretter ble Nikolai Langfeldt gruppens kontaktperson da han er ansvarlig for Munin. Nikolai var veldig hjelpsom og gruppen fikk alltid hjelp når det var nødvendig. Selv på helligdager og søndager var det enkelt å komme i kontakt med Nikolai per e-post Samarbeid med Veileder Helt fra startfasen viste Hårek Haugerud sin interesse for prosjektet gruppen hadde. Han mente at det var en interessant oppgave, og det var ikke langt fra hans fagfelt. Gruppemedlemmene hadde et godt samarbeid med Hårek og de fikk hjelp med spørsmål de stilte. 14

15 2.1.6 Møter Møter i gruppen I startfasen hadde gruppen 2-3 møter i uken hvor spørsmål ble tatt opp og diskutert. Gruppen diskuterte også hva hadde de gjort og hva burde de gjøre til neste gang. Årsaken til dette var at vi var i en studiefase hvor vi hele tiden måtte oppdatere hverandre på hva vi hadde lært og også lære det til hverandre. Det var stor usikkerhet i begynnelsen og det var viktig å holde møter ofte slik at gruppemedlemmene kunne få god oversikt over arbeidet. Møtene ble holdt i 4e etasje på Pilestredet 35. Noen ganger var det trangt om plassen og gruppen fant ikke et ledig grupperom. I disse tilfellene ble salen i samme etasje benyttet Møter med veileder Ved første møte med veileder ble det fastsatt at gruppen skulle ha en fast dag i uken hvor de oppdaterte veilederen. Dette ble satt til å være på tirsdager klokken 11:00. Ved disse møtene diskuterte gruppen hva de hadde gjort den siste uken og fikk tilbakemeldinger fra Hårek om hva som var bra, hva som kunne vært bedre og hva gruppen måttte fokusere å jobbe mest med. Disse møtene ble holdt på kontoret til Hårek Møter med oppdragsgiver Gruppen har vært i møte med bedriften flere ganger og Nikolai har vært kontaktpersonen som gruppen har møtt. Møtene ble holdt ved lokalene til oppdragsgiveren på Storo. Disse møtene varte i 1 time og mye ble tatt opp og mange nye ideer kom frem. Oppdragsiveren var fornøyd med resultatene ved disse møtene men det var alltid rom for forbedringer. Det var meget viktig for gruppen å bli oppdatert på oppdragsgiverens ønsker underveis. Gruppen hadde en veldig konkret kravspesifikasjon fra begynnelsen av prosjektet men etter disse møtene ble den mer detaljert og finpusset. 15

16 2.2 Fremdriftsplan I begynnelsen skrev gruppen en fremdriftsplan som dekket de store og viktige delene av prosjektet. Gruppen visste at de måtte gjøre denne fremdriftsplanen mer detaljert etter hvert som de fikk et bedre bilde av hva som var forventet av dem. Den største usikkerheten var at de visste ikke hvor lang tid de måtte sette av for forstudien av JMX. Gruppen skrev derfor en mye mer detaljert fremdriftsplan når de var over denne fasen. Figur 2 viser det første utkastet av fremdriftsplan mens figur 3 var den endelige versjonen av fremdriftsplan. Figur 2 16

17 Figur 3 17

18 2.3 Risikoanalyse I et prosjekt som dette burde gruppen ha en utvei for eventuelle problemer og hindringer de møter på veien som kan forsinke arbeidet. Hensikten med denne analysen er å illustrere risikoen for slike problemer og demonstrere en løsning og utvei for å slippe ekstra arbeid og stress mot innleveringsfrist. Problemer med planlegging og planoppfølging: Uten å planlegge, har ikke gruppen oversikt når de ulike delene av prosjektet skal gjøres ferdig, noe som er viktig siden vi har en frist for å levere prosjektet. Planleggingen må skje så tidlig så mulig, slik at gruppen vet når oppgaver skal gjøres for å unngå belastning og stress når innleveringsfrist nærmer seg. Problemer med programmeringen: Programmering er en viktig del av prosjektet. Å kombinere forskjellig teknologi er noe nytt for gruppen og det er mulig at det forårsaker forsinkelser. I tilfelle noe går galt eller gruppen ikke finner ut hvordan en del oppgave skal programmeres bør de konsultere veileder eller oppdragsgiver i tillegg til selvstudie. Problemer med dokumenteringen: Dokumentasjonen er en viktig del av prosjektet, den burde være detaljert og dekke krav til malen som ligger på nettsiden til hovedprosjektet hos Høgskolen i Oslo. Dokumenteringen burde gruppen begynne med tidlig. Det er lett å glemme hva man ha gjort og når man har gjort det. Derfor skal gruppen sørge for å dokumentere hver gang de har gjort noe. Fravær, sykdom og andre fag i studiet: Sykdom og fravær på grunn av personlige årsaker kan skje når som helst uten forvarsel, derfor skal man jobbe hjemmefra om man har mulighet, de andre i gruppen skal kompensere for hverandre dersom mulig. Alle i gruppen har en del andre fag å jobbe med, gruppen skal prøve å organisere tiden så godt som mulig. 18

19 Kommunikasjon og organisering innad i gruppen: Bra kommunikasjon i gruppen er viktig for prosjektets suksess. For å holde kontakt i gruppen burde gruppemedlemmene helst gå i samme klasse for å kunne lettere treffe hverandre. Kommunikasjon med oppdragsgiveren: Prosjektet er avhengig av at gruppen holder kontakt med oppdragsgiver, derfor er det viktig å møte de ofte og oppdatere kravspesifikasjonen dersom den endres. 2.4 Verktøy og programmer Verktøy og programmer som ble brukt under utviklingen av prosjektet var: Eclipse for programmering i Java Netbeans for programmering i Java Putty.exe både for å logge inn i serveren og for å lage database tabellene med MYSQL klienten. Microsoft Office for skriving av dokumentasjon. Open Office for skriving av dokumentasjon. En server for å laste opp filene og bruke som testing av prosjektet. En annen server som ligger hos Mo for å ha hjemmesiden på. Som kommunikasjonsverktøy brukte gruppemedlemmene, mobil, e-post, MSN og wikisidene. Omondo et program for design av UML diagrammer Argouml et program for design av UML diagrammer. 19

20 2.5 Hva måtte gruppen lære For å komme i gang med prosjektet måtte gruppen har visse forkunnskaper. Hovedsaklig måtte de konsentrere seg på å lære seg JMX rammeverket og hvordan de skulle bruke det og hva det var i stand til å gjøre for dem. Deretter måtte de lære seg å benytte denne informasjonen i sammenheng med Munin. Gruppen har hatt erfaring med Munin fra faget Unix og operativsystemer, men på et veldig lavt nivå. For dette prosjektet måtte gruppen lære seg mer om hvordan Munin fungerer slik at dataene kunne bli presentert på en tolkelig måte. For eksempel kan en Munin plugin bli konfigurert til å vise grafer på ulike måter. Herunder fargevalg, måten den fyller fargene og informasjonstagger. I tillegg måtte pluginene konsolideres med Java programmene og data måtte sendes mellom Munin-noden, Munin pluginen, Java klassene for tilkobling av JMX og Java klassene for henting av dataene. Gruppen måtte også lære å installere, konfigurere og administrere programmer som var nødvendige for systemet det kjøres på. Vi ble gitt en ukonfigurert basisinstallasjon av Debian Linux. På denne laben måtte vi installere Munin-main, Munin-node, editeringsprogrammer, Java SDK, Tomcat m.m. Her gikk det mye tid og søking for konfigurering. Gruppen forsøkte å installere JBoss, noe som viste seg å være en vanskelig oppgave da pakkehåndteringsprogrammet (apt-get) i Debian ikke hadde JBoss pakken. Gruppen måtte studere manualene for å starte MBean serveren for Tomcat5.5, noe som krevde manuell konfigurering av oppstartsfilen til Tomcat (/etc/init.d/tomcat5.5). 20

21 3. Utviklingsprosessen 3.1 Generelt Da gruppen begynte å planlegge prosjektet i startfasen skjønte de fort at store deler av prosjektet kom til å gå ut på å skrive små kodesamlinger og teste dem med enten Munin eller JMX og deretter koble de sammen for å generere grafer. Dette resulterte i at de ikke kunne benytte tradisjonelle utviklingsmetoder som fossefall eller RUP. Da de ikke visste mye om JMX før de begynte var det også umulig for dem å skrive en helt ferdig kravspesifikasjon da de ikke visste eksakt hva den var i stand til å gjøre. Oppdragsgiver var også usikker på hvor mye data det var mulig å hente ut via JMX kontra loggfiler. Det mest naturlige for gruppen var derfor å benytte en kombinasjon av tradisjonelle metoder sammen med XP modellen. Gruppen hadde en deadline og dermed måtte de allikevel planlegge de forskjellige fasene for å rekke å komme gjennom alt. Koding og testing var viktige deler under utviklingen av systemet. Årsaken til at gruppen kodet og testet hver enkelt plugin på denne måten var fordi Munin oppdaterer grafer hvert 5te minutt og det ville kostet gruppen mer tid å vente på at Munin skulle fylle ut grafene. Dermed startet gruppen deres Javaprogrammer i en løkke som skrev til en SQL database hvert 5te sekund. Dette ga mye raskere verifikasjon på at pluginen fungerte og vi kunne raskt se endringer i verdiene når vi belastet programmet. Figur 4 på andre side viser hvordan livssyklusen til utviklingen har vært og hvor viktig testing har vært under utviklingsprosessen. 21

22 Figur 4 22

23 3.2 Problemer underveis Dette kapittelet vil omhandle problemer gruppen har møtt på under installasjon av applikasjoner og programmering av Java koden Installasjon av JBoss Gruppen trengte en server for å kunne teste det de har programmert på. Gruppen ble tildelt en enkel installasjon av Debian Linux. Installasjon av Tomcat gikk bra under Debian men gruppen hadde problemer med å installere JBoss. Vi gikk gjennom flere dokumentasjoner og prøvde flere metoder for å installere JBoss men det var uten hjelp. Da gruppen hadde brukt lang tid uten hell valgte vi å gå videre uten JBoss etter å ha diskutert det med oppdragsgiveren. Årsaken til det var at gruppens plugin endrer seg ikke når applikasjonen som skal overvåkes endres. Det er kun en linje i Munin-node.config som endres. Derfor valgte gruppen med samtykke fra oppdragsgiver å konsentrere seg om å lage flest mulig plugin med JMX. Dette viste seg å være et lurt valg da de klarte å utvikle alle grafer som er mulig via JMX. En som skal overvåke JBoss kan nå enkelt starte JBoss med suffix om å starte sin Mbean server og velge en port den skal lytte til. Deretter er det kun nødvendig å endre på to linjer i plugin-conf.d Munin Munin oppdaterer som kjent grafene hvert 5te minutt. I løpet av programmeringen av Munin pluginene har gruppen møtt på et irritasjonsmoment. Dersom man fyller inn noe feil i plugin konfigurasjonen, for eksempel ved at graf informasjonen er feil er det en tidskrevende prosess å rette dette. Først må Java filen rettes, deretter må class filen flyttes til riktig mappe. Deretter må Munin-node restartes. Og for at endringen skal vises i gjeldene Munin-graf vil det ta to 23

24 Munin oppdateringer før endringen er synlig. Dette betyr to 5 minutters venteperioder etter at feilen er rettet. Til sammen vil en liten endring i en graf ta 15 minutter. Slike små endringer har det vært mange av og det har gått mange timer på finpussing. I utgangspunktet har det ikke vært et problem men et irritasjonsmoment som ikke kunne vært gjort annerledes JMX Gruppen har hatt flere problemer med JMX. Den største og den som tok mest av vår tid var hvordan vi skulle bruke JMX riktig. Først hadde gruppen tolket JavaDoc feil slik at vi fikk data fra feil Java instans. Det er to måter å hente ut data for det gjeldende MXBean interfacet. Direkte Dette gjøres ved at det blir opprettet et MXBean objekt ved å kalle ManagementFactory klassen. Dette vil medføre at det blir hentet ut data for Java instansen koden ligger i. Indirekte Dette gjøres ved at man lager et MXBean objekt ved å kalle ManagementFactory.newPlatformMXBeanProxy. På denne måten velger man IP adresse og port for å sette opp en tilkobling til ønsket Java instans som har implementert Mbeans interfacet og lytter til ønsket port. Slik gruppen hadde tolket dokumentasjonen var at dataene de hentet ut var for JVM i sin helhet. Gruppen trodde dermed at når de hentet ut dataene ved den direkte måten at de hentet ut data for alle Java instanser akkumulert. Men dette var ikke tilfelle, noe de raskt kunne bekrefte ved at de belastet Debian installasjonen med en Java applikasjon som inneholdt en tung løkke. Gruppen kunne se at prosessor og minnebruk generelt for maskinen endret seg betraktelig, men gruppens grafer for JVM ikke hadde endringer. Det er ikke mulig å hente ut akkumulert data for Java, det er kun mulig å hente ut informasjon per instans. I våres tilfelle hentet vi ut data for vår Munin plugin i stedet for Tomcat instansen. Da munin pluginet ikke påvirkes av andre JVM instanser. 24

25 4. Avslutning 4.1 Oppsummering Gruppemedlemmene var veldige fornøyde med valg av JVM resources som oppgave for hovedprosjektet og valg av Redpill Linpro AS som oppdragssiver. Gruppemedlemmene har lært mye om å benytte teknologi fra flere fagområder og konsolidere det for å utvikle og teste et system, og ikke minst dokumentere det slik at andre kan dra nytte av produktet. Gruppen håper og regner med at produktet som består av en samling plugin vil bli benyttet av profesjonelle aktører innenfor drift og overvåking av IT-systemer som benytter Java. Gruppen har allerede fortalt om prosjektet til bedrifter som benytter Munin for overvåking og de har vært meget interessert i å ta i bruk og teste produktet når det blir tilgjengelig ved neste Munin versjon. Gruppemedlemmene har fått verdifull erfaring med å programmere med nye rammeverk og lært å benytte javadoc på en effektiv måte. Dokumentasjonen i JMX rammeverket har vært sentral for å gjennomføre prosjektet. Derfor vet gruppen at dokumentasjon er en viktig del av prosjektet og mye tid har blitt brukt på nettopp det. Underveis møtte gruppen på små og store problemer som forårsaket at vi ikke holdt fremdriftsplanen så godt som vi ønsket. Dette regnet gruppen med da vi begynte fordi vi ikke er profesjonelle og vi hadde ikke nok kunnskaper i startfasen. Derimot klarte gruppen å jobbe seg inn etter hvert som vi hadde studert emnet og fremdriften ble mer og mer som forventet. Det var i perioder nedturer som forårsaket stress, men gruppen var målrettet og samarbeidet var godt. Gruppen oppmuntret hverandre når noen hadde problemer og dersom vi hadde jobbet mange timer i strekk tok vi oss pauser hvor vi diskuterte andre emner enn prosjektet. Gruppen mener slike avkoblinger var nødvendige og hjalp oss å få opp motet. Under siste fasen som var testing av sluttproduktet, måtte vi friske opp våre JSP kunnskaper. Dette var en morsom del av prosjektet da den største og tyngste delen var over og gruppen 25

26 kunne teste og validere produktet. Dessuten var det morsomt å la datamaskinen jobbe for oss til en forandring. Grafene endret seg som forventet og prosjektet var en suksess. 4.2 Hva kunne vært gjort bedre Gruppen slet med å installere JBoss på serveren og det gikk mye tid på dette. Til slutt valgte vi i samarbeid med oppdragsgiver å droppe denne delen av kravspesifikasjonen. Vi mener at vi kunne unngått dette ved å ikke jobbe med JBoss fra begynnelsen av. Da vi skjønte at metodene vi bruker og produktet vi lager kan implementeres enkelt til andre applikasjoner visste vi at vi hadde sløst bort verdifull tid. For prosjektet sin del var det tilstrekkelig å teste produktet med Tomcat da samme vil gjelde for andre applikasjoner. Det er opp til sluttbrukeren å implementere produktet for ønsket applikasjon, om det skulle være Tomcat, JBoss, WebSphere, Oracle Application Server 10g eller en annen properitær applikasjon. 4.3 Framtiden Gruppen har i dette prosjektet produsert grafer for alle variable som kan hentes ut via en MBean server og presenteres i en graf. Gruppen mener at disse er veldig detaljerte. Det er mer enn 30 grafer hvor hver har opp til flere variable. Det er ikke sikkert at alle grafer er like interessante for alle. Derimot har gruppen blitt så interessert i arbeidet at vi vil følge med på teknologien i fremtiden og implementere flere grafer på hobbybasis dersom det blir flere MBean tilgjengelig. Oppdragsgiveren mener at prosjektet er ganske interessant og vil se nærmere på hva som kan forbedres og videreutvikles. Gruppemedlemmene fikk ikke lov til å teste prosjektet på oppdragsgiveren sin produksjon servere, dette skyldes sikkerheten. Men prosjektleder Nikolai Langfeldt mener at mange vil benytte produktet. 26

27 4.4 Konklusjon Vi er fornøyde med metodene vi benyttet for å utvikle produktet. Prosessmetodene som har vært benyttet har hjulpet oss gjennom hele prosjektet. Vi mener at det var riktig for oss å benytte en blanding av tradisjonelle utviklingsmetoder og XP metoden. Årsaken til det var at vi fikk jobbet mest med å utvikle produktet istedenfor å benytte en prosessmodell som er avansert og beregnet for større prosjekter med flere prosjektdeltagere og over lenger tid. Gruppen kom gjennom de forskjellige fasene med mindre avvik slik vi hadde planlagt. Gjennom hele prosjektet har vi fått benyttet mange deler av vår dataingeniør utdanning. Det har vært spennende å sette sammen alle de forskjellige prosessene, metodene, programmeringsteknikkene og ikke minst lære noe nytt. Det har vært meget lærerikt og gruppemedlemmene er glade for å ha kommet gjennom dette og blitt litt klokere. Vi kommer til å ta til oss kunnskapen og erfaringen videre i arbeidslivet. 27

28 5. Kildehenvisning Dette er den offisielle siden til Redpill linpro. JMX Tomcat hjemmeside JBoss hjemmeside Jconsole Jboss on Debian Wiki for Debian Algouml Eclipse Netbeans Munin Omando 28