Mange sliter med Elasticsearch. Men hva skjer når du vil bruke den til å lagre logger "i et spesielt stort volum"? Og er det også smertefritt å oppleve svikt i noen av flere datasentre? Hva slags arkitektur bør du lage, og hvilke fallgruver vil du snuble over?
Vi i Odnoklassniki bestemte oss for å bruke elasticsearch for å løse problemet med loggadministrasjon, og nå deler vi vår erfaring med Habr: både om arkitektur og om fallgruver.
Jeg er Pyotr Zaitsev, jeg jobber som systemadministrator hos Odnoklassniki. Før det var jeg også admin, jobbet med Manticore Search, Sphinx search, Elasticsearch. Kanskje, hvis et nytt ...søk dukker opp, vil jeg sannsynligvis også jobbe med det. Jeg deltar også i en rekke åpen kildekode-prosjekter på frivillig basis.
Da jeg kom til Odnoklassniki, sa jeg hensynsløst på intervjuet at jeg kunne jobbe med Elasticsearch. Etter at jeg fikk taket på det og gjennomført noen enkle oppgaver, fikk jeg den store oppgaven med å reformere loggstyringssystemet som eksisterte på den tiden.
Krav
Systemkravene ble formulert som følger:
- Graylog skulle brukes som frontend. Fordi selskapet allerede hadde erfaring med å bruke dette produktet, visste programmerere og testere det, det var kjent og praktisk for dem.
- Datavolum: i gjennomsnitt 50-80 tusen meldinger per sekund, men hvis noe går i stykker, er ikke trafikken begrenset av noe, det kan være 2-3 millioner linjer per sekund
- Etter å ha diskutert med kundene kravene til hastigheten på å behandle søkespørsmål, innså vi at det typiske mønsteret for å bruke et slikt system er dette: folk leter etter logger for søknaden deres de siste to dagene og ønsker ikke å vente mer enn en andre for resultatet av en formulert spørring.
- Administratorene insisterte på at systemet skulle være enkelt skalerbart om nødvendig, uten at de måtte gå dypt inn i hvordan det fungerer.
- Slik at den eneste vedlikeholdsoppgaven som disse systemene krever med jevne mellomrom, er å endre noe maskinvare.
- I tillegg har Odnoklassniki en utmerket teknisk tradisjon: enhver tjeneste vi lanserer må overleve en datasenterfeil (plutselig, uplanlagt og absolutt når som helst).
Det siste kravet i gjennomføringen av dette prosjektet kostet oss mest, som jeg vil snakke om mer detaljert.
onsdag
Vi jobber i fire datasentre, mens Elasticsearch-datanoder kun kan lokaliseres i tre (av en rekke ikke-tekniske årsaker).
Disse fire datasentrene inneholder omtrent 18 tusen forskjellige loggkilder - maskinvare, containere, virtuelle maskiner.
Viktig funksjon: klyngen starter i containere ikke på fysiske maskiner, men på . Beholdere er garantert 2 kjerner, tilsvarende 2.0Ghz v4, med mulighet for resirkulering av de resterende kjernene hvis de er inaktive.
Med andre ord:
Topologi
Jeg så først den generelle formen for løsningen som følger:
- 3-4 VIP-er står bak A-recorden til Graylog-domenet, dette er adressen loggene sendes til.
- hver VIP er en LVS-balanserer.
- Etter det går loggene til Graylog-batteriet, noen av dataene er i GELF-format, noen i syslog-format.
- Så blir alt dette skrevet i store partier til et batteri av Elasticsearch-koordinatorer.
- Og de sender på sin side skrive- og leseforespørsler til de relevante datanodene.
terminologi
Kanskje ikke alle forstår terminologien i detalj, så jeg vil dvele litt ved den.
Elasticsearch har flere typer noder - master, koordinator, datanode. Det er to andre typer for forskjellige loggtransformasjoner og kommunikasjon mellom forskjellige klynger, men vi brukte bare de som er oppført.
Master
Den pinger alle noder som er tilstede i klyngen, opprettholder et oppdatert klyngekart og distribuerer det mellom noder, behandler hendelseslogikk og utfører ulike typer klyngeomfattende husholdning.
Koordinator
Utfører én enkelt oppgave: godtar lese- eller skriveforespørsler fra klienter og ruter denne trafikken. I tilfelle det er en skriveforespørsel, vil den mest sannsynlig spørre master hvilken shard av den relevante indeksen den skal legge den inn i, og vil omdirigere forespørselen videre.
Data node
Lagrer data, utfører søk som kommer utenfra og utfører operasjoner på shards plassert på den.
grålogg
Dette er noe som en fusjon av Kibana med Logstash i en ELK-stabel. Graylog kombinerer både et brukergrensesnitt og en loggbehandlingspipeline. Under panseret driver Graylog Kafka og Zookeeper, som gir tilkobling til Graylog som en klynge. Graylog kan cache logger (Kafka) i tilfelle Elasticsearch er utilgjengelig og gjenta mislykkede lese- og skriveforespørsler, gruppere og merke logger i henhold til spesifiserte regler. Som Logstash har Graylog funksjonalitet for å endre rader før de skrives til Elasticsearch.
I tillegg har Graylog en innebygd tjenesteoppdagelse som gjør det mulig, basert på én tilgjengelig Elasticsearch-node, å hente hele klyngekartet og filtrere det etter en spesifikk tag, som gjør det mulig å rette forespørsler til spesifikke containere.
Visuelt ser det omtrent slik ut:
Dette er et skjermbilde fra en bestemt instans. Her bygger vi et histogram basert på søket og viser relevante rader.
Indekser
Tilbake til systemarkitekturen vil jeg dvele mer detaljert ved hvordan vi bygget indeksmodellen slik at det hele fungerte riktig.
I diagrammet ovenfor er dette det laveste nivået: Elasticsearch-datanoder.
En indeks er en stor virtuell enhet som består av Elasticsearch-skår. I seg selv er hvert av skårene ikke noe mer enn en Lucene-indeks. Og hver Lucene-indeks består på sin side av ett eller flere segmenter.
Under utformingen fant vi ut at for å oppfylle kravet til lesehastighet på en stor mengde data, måtte vi "spre" disse dataene jevnt på tvers av datanoder.
Dette resulterte i at antall shards per indeks (med replikaer) bør være strengt lik antallet datanoder. For det første, for å sikre en replikasjonsfaktor lik to (det vil si at vi kan miste halvparten av klyngen). Og for det andre for å behandle lese- og skriveforespørsler på minst halvparten av klyngen.
Vi bestemte først lagringstiden til 30 dager.
Fordelingen av skår kan representeres grafisk som følger:
Hele det mørkegrå rektangelet er en indeks. Den venstre røde firkanten i den er den primære shard, den første i indeksen. Og den blå firkanten er en kopiskår. De er plassert i forskjellige datasentre.
Når vi legger til et annet shard, går det til det tredje datasenteret. Og til slutt får vi denne strukturen, som gjør det mulig å miste DC uten å miste datakonsistensen:
Rotasjon av indekser, dvs. ved å opprette en ny indeks og slette den eldste, gjorde vi den lik 48 timer (i henhold til mønsteret for indeksbruk: de siste 48 timene søkes oftest).
Dette indeksrotasjonsintervallet skyldes følgende årsaker:
Når en søkeforespørsel kommer til en spesifikk dataknute, er det, fra et ytelsessynspunkt, mer lønnsomt når en shard spørres, hvis størrelsen er sammenlignbar med størrelsen på nodens hofte. Dette lar deg holde den "varme" delen av indeksen i en haug og raskt få tilgang til den. Når det er mange "varme deler", reduseres hastigheten på indekssøk.
Når en node begynner å utføre et søk på ett shard, allokerer den et antall tråder som tilsvarer antallet hyperthreading-kjerner i den fysiske maskinen. Hvis et søk påvirker et stort antall shards, vil antallet tråder vokse proporsjonalt. Dette har en negativ innvirkning på søkehastigheten og påvirker indekseringen av nye data negativt.
For å gi den nødvendige søkeforsinkelsen bestemte vi oss for å bruke en SSD. For raskt å behandle forespørsler, måtte maskinene som var vert for disse beholderne ha minst 56 kjerner. Tallet 56 ble valgt som en betinget tilstrekkelig verdi som bestemmer antall tråder som Elasticsearch vil generere under drift. I Elasitcsearch avhenger mange trådpoolparametere direkte av antall tilgjengelige kjerner, som igjen direkte påvirker det nødvendige antallet noder i klyngen i henhold til prinsippet "færre kjerner - flere noder".
Som et resultat fant vi ut at en shard i gjennomsnitt veier omtrent 20 gigabyte, og det er 1 shards per indeks. Følgelig, hvis vi roterer dem en gang hver 360. time, har vi 48 av dem. Hver indeks inneholder data for 15 dager.
Dataskriving og lesekretser
La oss finne ut hvordan data registreres i dette systemet.
La oss si at det kommer en forespørsel fra Graylog til koordinatoren. For eksempel ønsker vi å indeksere 2-3 tusen rader.
Koordinatoren, etter å ha mottatt en forespørsel fra Graylog, stiller spørsmål til masteren: "I indekseringsforespørselen spesifiserte vi spesifikt en indeks, men i hvilken shard den skulle skrives var ikke spesifisert."
Masteren svarer: "Skriv denne informasjonen til shard nummer 71," hvoretter den sendes direkte til den relevante datanoden, hvor primær shard nummer 71 er plassert.
Deretter blir transaksjonsloggen replikert til en replika-shard, som er plassert i et annet datasenter.
En søkeforespørsel kommer fra Graylog til koordinatoren. Koordinatoren omdirigerer den i henhold til indeksen, mens Elasticsearch fordeler forespørsler mellom primær-shard og replika-shard ved hjelp av round-robin-prinsippet.
De 180 nodene reagerer ujevnt, og mens de svarer, samler koordinatoren informasjon som allerede er "spyttet ut" av raskere datanoder. Etter dette, når enten all informasjon har kommet, eller forespørselen har nådd en timeout, gir den alt direkte til klienten.
Hele dette systemet behandler i gjennomsnitt søkespørsmål de siste 48 timene i 300-400 ms, unntatt de søkene med et ledende jokertegn.
Blomster med Elasticsearch: Java-oppsett
For å få det til å fungere slik vi opprinnelig ønsket, brukte vi veldig lang tid på å feilsøke en rekke ting i klyngen.
Den første delen av problemene som ble oppdaget var relatert til måten Java er forhåndskonfigurert som standard i Elasticsearch.
Problem en
Vi har observert et svært stort antall rapporter om at på Lucene-nivå, når bakgrunnsjobber kjører, mislykkes Lucene-segmentsammenslåinger med en feil. Samtidig var det tydelig i loggene at dette var en OutOfMemoryError-feil. Vi så fra telemetri at hoften var fri, og det var ikke klart hvorfor denne operasjonen mislyktes.
Det viste seg at Lucene-indekssammenslåinger forekommer utenfor hoften. Og containere er ganske strengt begrenset når det gjelder forbrukte ressurser. Bare heap kunne passe inn i disse ressursene (heap.size-verdien var omtrent lik RAM), og noen off-heap-operasjoner krasjet med en minneallokeringsfeil hvis de av en eller annen grunn ikke passet inn i ~500 MB som gjensto før grensen.
Løsningen var ganske triviell: mengden RAM tilgjengelig for beholderen ble økt, hvoretter vi glemte at vi til og med hadde slike problemer.
Problem to
4-5 dager etter lanseringen av klyngen la vi merke til at datanoder begynte å falle ut av klyngen med jevne mellomrom og gå inn i den etter 10-20 sekunder.
Da vi begynte å finne ut av det, viste det seg at dette off-heap-minnet i Elasticsearch ikke er kontrollert på noen måte. Da vi ga mer minne til beholderen, var vi i stand til å fylle de direkte bufferpoolene med forskjellig informasjon, og den ble slettet først etter at den eksplisitte GC ble lansert fra Elasticsearch.
I noen tilfeller tok denne operasjonen ganske lang tid, og i løpet av denne tiden klarte klyngen å markere denne noden som allerede avsluttet. Dette problemet er godt beskrevet .
Løsningen var som følger: vi begrenset Javas mulighet til å bruke mesteparten av minnet utenfor haugen for disse operasjonene. Vi begrenset den til 16 gigabyte (-XX:MaxDirectMemorySize=16g), for å sikre at eksplisitt GC ble kalt mye oftere og behandlet mye raskere, og dermed ikke lenger destabilisere klyngen.
Oppgave tre
Hvis du tror at problemene med "noder som forlater klyngen på det mest uventede øyeblikket" er over, tar du feil.
Da vi konfigurerte arbeidet med indekser, valgte vi mmapfs til på ferske skår med stor segmentering. Dette var litt av en feil, for når du bruker mmapfs, blir filen kartlagt til RAM, og så jobber vi med den kartlagte filen. På grunn av dette viser det seg at når GC prøver å stoppe tråder i applikasjonen, går vi til sikkerhetspunktet i veldig lang tid, og på vei til det slutter applikasjonen å svare på mesterens forespørsler om hvorvidt den er i live . Følgelig mener master at noden ikke lenger er tilstede i klyngen. Etter dette, etter 5-10 sekunder, fungerer søppelsamleren, noden kommer til live, kommer inn i klyngen igjen og begynner å initialisere skår. Det hele føltes veldig som "produksjonen vi fortjente" og var ikke egnet for noe seriøst.
For å bli kvitt denne oppførselen, byttet vi først til standard niofs, og så, da vi migrerte fra den femte versjonen av Elastic til den sjette, prøvde vi hybridfs, der dette problemet ikke ble gjengitt. Du kan lese mer om lagringstyper .
Oppgave fire
Så var det et annet veldig interessant problem som vi behandlet for rekordtid. Vi fanget den i 2-3 måneder fordi mønsteret var helt uforståelig.
Noen ganger dro koordinatorene våre til Full GC, vanligvis en gang etter lunsj, og kom aldri tilbake derfra. Samtidig, når du logger GC-forsinkelsen, så det slik ut: alt går bra, vel, vel, og så går alt plutselig veldig dårlig.
Først trodde vi at vi hadde en ond bruker som lanserte en slags forespørsel som slo koordinatoren ut av arbeidsmodus. Vi logget forespørsler i veldig lang tid, og prøvde å finne ut hva som skjedde.
Som et resultat viste det seg at i det øyeblikket en bruker sender en stor forespørsel, og den kommer til en spesifikk Elasticsearch-koordinator, svarer noen noder lenger enn andre.
Og mens koordinatoren venter på svar fra alle nodene, akkumulerer han resultatene sendt fra nodene som allerede har svart. For GC betyr dette at haugbruksmønstrene våre endres veldig raskt. Og GC som vi brukte kunne ikke takle denne oppgaven.
Den eneste løsningen vi fant for å endre oppførselen til klyngen i denne situasjonen er migrering til JDK13 og bruk av Shenandoah søppelsamleren. Dette løste problemet, koordinatorene våre sluttet å falle.
Det var her problemene med Java sluttet og båndbreddeproblemene begynte.
"Bær" med Elasticsearch: gjennomstrømning
Problemer med gjennomstrømming gjør at klyngen vår fungerer stabilt, men ved topper i antall indekserte dokumenter og under manøvrer er ytelsen utilstrekkelig.
Det første symptomet som oppstod: under noen "eksplosjoner" i produksjonen, når et veldig stort antall logger plutselig genereres, begynner indekseringsfeilen es_rejected_execution å blinke ofte i Graylog.
Dette skyldtes det faktum at thread_pool.write.queue på én datanode, inntil det øyeblikket Elasticsearch er i stand til å behandle indekseringsforespørselen og laste opp informasjonen til sharden på disken, er i stand til å cache bare 200 forespørsler som standard. Og i Svært lite er sagt om denne parameteren. Bare det maksimale antallet tråder og standardstørrelsen er angitt.
Selvfølgelig gikk vi for å vri denne verdien og fant ut følgende: spesifikt, i oppsettet vårt, er opptil 300 forespørsler bufret ganske bra, og en høyere verdi er full av det faktum at vi igjen flyr inn i Full GC.
I tillegg, siden dette er grupper med meldinger som kommer innen én forespørsel, var det nødvendig å justere Graylog slik at den ikke skriver ofte og i små grupper, men i store grupper eller en gang hvert 3. sekund hvis batchen fortsatt ikke er komplett. I dette tilfellet viser det seg at informasjonen som vi skriver i Elasticsearch blir tilgjengelig ikke på to sekunder, men på fem (noe som passer oss ganske bra), men antallet rerays som må gjøres for å presse gjennom en stor bunken med informasjon reduseres.
Dette er spesielt viktig i de øyeblikkene når noe har krasjet et sted og rapporterer rasende om det, for ikke å få en fullstendig spammet Elastic, og etter en tid - Graylog-noder som er ubrukelige på grunn av tilstoppede buffere.
I tillegg, da vi hadde de samme eksplosjonene i produksjon, mottok vi klager fra programmerere og testere: i det øyeblikket de virkelig trengte disse loggene, fikk de dem veldig sakte.
De begynte å finne ut av det. På den ene siden var det klart at både søk og indekseringsspørringer i hovedsak ble behandlet på de samme fysiske maskinene, og på en eller annen måte ville det være visse nedtrekk.
Men dette kan delvis omgås på grunn av det faktum at i den sjette versjonen av Elasticsearch dukket det opp en algoritme som lar deg distribuere spørringer mellom relevante datanoder som ikke er i henhold til det tilfeldige round-robin-prinsippet (beholderen som gjør indeksering og holder primær- shard kan være veldig opptatt, det vil ikke være mulig å svare raskt), men å videresende denne forespørselen til en mindre lastet beholder med en replika-shard, som vil svare mye raskere. Med andre ord, vi kom frem til use_adaptive_replica_selection: true.
Lesebildet begynner å se slik ut:
Overgangen til denne algoritmen gjorde det mulig å forbedre spørretiden betydelig i de øyeblikkene vi hadde en stor flyt av logger å skrive.
Til slutt var hovedproblemet den smertefrie fjerningen av datasenteret.
Det vi ønsket fra klyngen umiddelbart etter å ha mistet forbindelsen med en DC:
- Hvis vi har en gjeldende master i det mislykkede datasenteret, vil den bli valgt på nytt og flyttet som en rolle til en annen node i en annen DC.
- Masteren vil raskt fjerne alle utilgjengelige noder fra klyngen.
- Basert på de gjenværende vil han forstå: i det tapte datasenteret hadde vi slike og slike primære shards, han vil raskt fremme komplementære replikashards i de gjenværende datasentrene, og vi vil fortsette å indeksere dataene.
- Som et resultat av dette vil klyngens skrive- og lesegjennomstrømning gradvis degraderes, men generelt vil alt fungere, om enn sakte, men stabilt.
Som det viste seg, ønsket vi noe slikt:
Og vi fikk følgende:
Hvordan skjedde dette?
Da datasenteret falt, ble masteren vår flaskehalsen.
Hvorfor?
Faktum er at masteren har en TaskBatcher, som er ansvarlig for å distribuere visse oppgaver og hendelser i klyngen. Enhver nodeutgang, enhver promotering av et shard fra replika til primært, enhver oppgave for å lage et shard et sted - alt dette går først til TaskBatcher, hvor det behandles sekvensielt og i én tråd.
På tidspunktet for tilbaketrekkingen av ett datasenter, viste det seg at alle datanoder i de overlevende datasentrene anså det som sin plikt å informere masteren "vi har mistet slike og slike shards og slike og slike datanoder."
Samtidig sendte de overlevende datanodene all denne informasjonen til den nåværende masteren og prøvde å vente på bekreftelse på at han godtok den. De ventet ikke på dette, siden mesteren fikk oppgaver raskere enn han kunne svare på. Nodene avbrøt gjentatte forespørsler, og mesteren prøvde på dette tidspunktet ikke engang å svare på dem, men var fullstendig oppslukt av oppgaven med å sortere forespørsler etter prioritet.
I terminalform viste det seg at datanodene spammet masteren til det punktet at den gikk inn i full GC. Etter det flyttet mesterrollen vår til en neste node, absolutt det samme skjedde med den, og som et resultat kollapset klyngen fullstendig.
Vi tok målinger, og før versjon 6.4.0, hvor dette ble fikset, var det nok for oss å sende ut kun 10 datanoder av 360 samtidig for å stenge klyngen fullstendig.
Det så omtrent slik ut:
Etter versjon 6.4.0, hvor denne forferdelige feilen ble fikset, sluttet datanoder å drepe masteren. Men det gjorde ham ikke "smartere". Nemlig: når vi sender ut 2, 3 eller 10 (hvilket som helst annet enn én) datanoder, mottar masteren en første melding som sier at node A har forlatt, og prøver å fortelle node B, node C om dette, node D.
Og for øyeblikket kan dette bare håndteres ved å sette en timeout for forsøk på å fortelle noen om noe, lik ca 20-30 sekunder, og dermed kontrollere hastigheten på datasenteret som beveger seg ut av klyngen.
I prinsippet passer dette inn i kravene som i utgangspunktet ble presentert til sluttproduktet som en del av prosjektet, men fra et «ren vitenskap»-synspunkt er dette en feil. Som forresten ble løst av utviklerne i versjon 7.2.
Dessuten, når en bestemt dataknute gikk ut, viste det seg at det var viktigere å spre informasjon om dens utgang enn å fortelle hele klyngen at det var slike og slike primære shards på den (for å fremme en replika-shard i en annen data senter i primærskolen, og det kunne skrives informasjon på dem).
Derfor, når alt allerede har stilnet, blir ikke de utgitte datanodene umiddelbart merket som foreldede. Følgelig er vi tvunget til å vente til alle pingene har gått ut til de utgitte datanodene, og først etter det begynner klyngen vår å fortelle oss at der, der og der må vi fortsette å registrere informasjon. Du kan lese mer om dette .
Som et resultat av dette tar operasjonen med å trekke ut et datasenter i dag oss rundt 5 minutter i rushtiden. For en så stor og klønete koloss er dette et ganske bra resultat.
Som et resultat kom vi til følgende avgjørelse:
- Vi har 360 datanoder med 700 gigabyte disker.
- 60 koordinatorer for å dirigere trafikk gjennom de samme datanodene.
- 40 mastere som vi har lagt igjen som en slags arv siden versjoner før 6.4.0 - for å overleve tilbaketrekkingen av datasenteret var vi mentalt forberedt på å miste flere maskiner for å være garantert å ha et kvorum av mastere selv i det verste scenarioet
- Ethvert forsøk på å kombinere roller på en container ble møtt med det faktum at før eller siden ville noden bryte under belastning.
- Hele klyngen bruker en heap.size på 31 gigabyte: alle forsøk på å redusere størrelsen resulterte i enten å drepe noen noder på tunge søk med det ledende jokertegnet eller få kretsbryteren i selve Elasticsearch.
- I tillegg, for å sikre søkeytelse, prøvde vi å holde antallet objekter i klyngen så lite som mulig, for å behandle så få hendelser som mulig i flaskehalsen som vi fikk i masteren.
Til slutt om overvåking
For å sikre at alt dette fungerer etter hensikten, overvåker vi følgende:
- Hver datanode rapporterer til skyen vår at den eksisterer, og det er slike og slike skår på den. Når vi slukker noe et sted, rapporterer klyngen etter 2-3 sekunder at i senter A har vi slukket nodene 2, 3 og 4 - dette betyr at i andre datasentre kan vi under ingen omstendigheter slukke de nodene der det bare er ett skår. venstre.
- Når vi kjenner til arten av mesterens oppførsel, ser vi veldig nøye på antall ventende oppgaver. Fordi selv en fast oppgave, hvis den ikke går ut i tide, teoretisk i en eller annen nødsituasjon kan bli årsaken til at for eksempel promotering av en replika shard i primæren ikke fungerer, og det er grunnen til at indeksering vil slutte å fungere.
- Vi ser også veldig nøye på søppeloppsamlerforsinkelser, fordi vi allerede har hatt store problemer med dette under optimalisering.
- Avviser per tråd for å forstå på forhånd hvor flaskehalsen er.
- Vel, standardverdier som heap, RAM og I/O.
Når du bygger overvåking, må du ta hensyn til funksjonene til Thread Pool i Elasticsearch. beskriver konfigurasjonsalternativer og standardverdier for søk og indeksering, men er helt stille om thread_pool.management. Disse trådene behandler spesielt spørringer som _cat/shards og andre lignende, som er praktiske å bruke når man skriver overvåking. Jo større klyngen er, desto flere slike forespørsler utføres per tidsenhet, og den nevnte thread_pool.management er ikke bare ikke presentert i den offisielle dokumentasjonen, men er også begrenset som standard til 5 tråder, som meget raskt fjernes, etter hvilken overvåking slutter å fungere som den skal.
Hva jeg vil si avslutningsvis: vi klarte det! Vi var i stand til å gi våre programmerere og utviklere et verktøy som i nesten enhver situasjon raskt og pålitelig kan gi informasjon om hva som skjer i produksjonen.
Ja, det viste seg å være ganske komplisert, men likevel klarte vi å tilpasse våre ønsker til eksisterende produkter, som vi ikke trengte å lappe og omskrive for oss selv.
Kilde: www.habr.com