For å registrere et snapshot-repositorium i Elasticsearch og legge til generell innholdsinndata, er det flere viktige trinn som må følges. Først og fremst krever prosessen at man etablerer en forbindelse med en skybasert lagringsløsning som AWS S3, og deretter konfigurerer og registrerer repositoriet i Kibana.

Når du legger til et S3-repositorium, er den første nødvendige oppgaven å bruke et eksisterende eller nylig opprettet S3-bøtte som lagringsplass for snapshot-dataene. Dette gjøres ved å navigere til Kibana, gå til Stack Management og deretter Snapshot & Restore. Derfra kan du registrere et nytt repositorium og velge AWS S3 som typen for repositoriet. Et viktig punkt her er at du må bruke nøyaktig den samme S3-bøttenavnet som du opprettet på AWS, for eksempel "elasticsearch-s3-bucket-repository". I tillegg kreves det at du angir klienten som er konfigurert med de nødvendige tilgangs- og hemmelighetsnøklene (som du finner i keystore-konfigurasjonen), noe som er kritisk for at repositoriet skal fungere som forventet.

Når repositoriet er registrert, kan du verifisere tilkoblingen til S3-bøtten ved å sjekke statusen for repositoriet i Kibana. Det er viktig å sørge for at bøtten er tilgjengelig som et snapshot-repositorium, og at det er konfigurert korrekt. Som alternativ kan dette også gjøres via Elasticsearch API, hvilket gir mer fleksibilitet for automatisering av prosessen.

Selv om denne oppskriften fokuserer på bruk av AWS S3 som repositorium, finnes det flere andre lagringsalternativer tilgjengelig, inkludert Azure, Google Cloud Storage og delte filsystemer. Elastic-dokumentasjonen gir grundig veiledning om hvordan du kan registrere repositorier på disse plattformene, og spesielt når du bruker ECK (Elastic Cloud on Kubernetes), kreves det at du følger spesifikke instruksjoner som er tilgjengelige i Elastic Cloud-dokumentasjonen.

Når du har registrert repositoriet, kan du begynne å konfigurere snapshot- og restore-prosesser, som vil bli behandlet i detalj i kapittel 12 av boken. Å ha et fungerende snapshot-repositorium gir en solid base for håndtering av data over tid og for å sikre at viktige data kan gjenopprettes ved behov.

Når du har satt opp repositoriet, kan du begynne å jobbe med datainnhenting. Dette innebærer å legge til generell innholdsinndata som kan komme fra forskjellige kilder som API-er, HTML-sider, PDF-dokumenter eller relasjonsdatabaser. Denne prosessen er delt inn i flere viktige operasjoner som inkluderer indeksering, sletting og oppdatering av data i Elasticsearch.

Elasticsearch tilbyr et bredt spekter av verktøy for datainnhenting gjennom språkspesifikke klienter, som for eksempel Python-klienten. Disse klientene gjør det mulig å sende HTTP-forespørsler til Elasticsearch, som deretter prosesserer forespørslene og gir tilbakemeldinger til klientapplikasjonen. I denne sammenhengen er det viktig å ha et korrekt oppsett for å sende data til Elasticsearch, som for eksempel en Python-applikasjon som bruker Elasticsearch-biblioteket og .env-filer for å lagre nødvendige autentiseringsinformasjon. Dette er et av de første trinnene for å kunne indeksere data i Elasticsearch på en effektiv måte.

Etter at forbindelsen er etablert, kan man begynne å sende data til Elasticsearch. For eksempel kan du bruke et datasett fra Wikipedia Movie Plots, som inneholder metadata om filmer og er tilgjengelig på Kaggle. Dette datasettet kan brukes som et eksempel på generell innholdsinndata som skal indekseres i Elasticsearch. For å legge til et dokument, må man bygge opp et JSON-dokument som representerer dataene, som i tilfellet med filmene kan inkludere informasjon som tittel, regissør, rollebesetning og utgivelsesår.

Når dataene er lagt til, kan du begynne å utføre operasjoner som oppdatering og sletting av eksisterende indekser. Elasticsearch gir også muligheten til å bruke analyzere for å analysere og indeksere tekstdata på en optimal måte, samt definere index mapping og bruke dynamiske maler i dokumentindekseringen.

En viktig del av datainnhentingen er å forstå hvordan man kan lage et godt indeksskjema. Dynamiske maler og indeksskjemaer er essensielle for å organisere og strukturere dataene på en måte som gir best mulig ytelse under søk. Elasticsearch tillater at indeksskjemaer og maler konfigureres dynamisk, noe som gjør det enklere å håndtere varierende datatyper og strukturer.

Når du begynner å arbeide med bulkindeksering, kan du bruke Bulk API-et til å indeksere flere dokumenter samtidig. Dette gir bedre ytelse når du jobber med store datamengder, og kan være avgjørende når du bygger større applikasjoner som krever effektiv databehandling.

Det er viktig å merke seg at datainnhenting i Elasticsearch ikke bare handler om å sende data til en database. Det innebærer også å forstå de underliggende prosessene og hvordan Elasticsearch håndterer og indekserer dataene. Ved å bruke riktige verktøy og tilnærminger kan man sikre at dataene lagres effektivt, og at de er klare for spørringer og analyser når det er nødvendig.

Hvordan bruke Beats for å samle data fra kilder som ikke støttes av Elastic Agent

I de tidligere oppskriftene i dette kapitlet har vi lært hvordan vi kan bruke Elastic Agent og dets integrasjoner for å hente tidsstemplet data. Men det kan oppstå tilfeller hvor det ikke finnes noen tilgjengelig Elastic Agent-integrasjon for kilden vår. I slike tilfeller kan Beats være et nyttig alternativ. Beats er et sett med lettvektsdataleverandører som effektivt kan samle inn og sende data til Elasticsearch for analyse og visualisering.

Beats er en samling av små og spesialiserte verktøy, kalt "shippers", som er designet for å håndtere ulike datatyper og sende dem til Elasticsearch eller Logstash. Et av de mest brukte Beats-verktøyene er Metricbeat, som samler system- og applikasjonsmetrikker og sender dem til Elasticsearch for videre analyse. I denne oppskriften vil vi se på hvordan Metricbeat kan brukes til å hente Apache Tomcat-metrikker og sende dem til Elasticsearch, med Kibana for visualisering.

Forberedelser før datainnsamling

Før vi begynner å hente data, er det viktig at vi har en kjørende Apache Tomcat-instans som støtter versjon 9.x. For å hente metrikker, bruker vi Jolokia, som gjør at Tomcat kan eksponere JMX-metrikker. Både Apache Tomcat og Jolokia må være installert på systemet.

Tomcat kan settes opp på ulike måter, men i denne oppskriften bruker vi Google Cloud Platform (GCP) Marketplace-løsningen for å sette opp en Ubuntu VM med en forhåndskonfigurert Apache Tomcat 9-instans. Hvis du bruker en annen skytjeneste eller en selvadministrert løsning, kan du følge den offisielle Tomcat-setup-guiden.

Installasjon av Apache Tomcat og Jolokia

For å sette opp Apache Tomcat 9 på GCP, kan du bruke følgende lenke til GCP Marketplace: [Tomcat på GCP](https://console.cloud.google.com/ marketplace/browse). Hvis du har en selvadministrert løsning, finner du den offisielle installasjonsveiledningen her: Apache Tomcat Setup Guide.

Jolokia er en åpen kildekode Java-bibliotek og agent som forenkler administrasjonen og overvåkingen av Java-applikasjoner. Den gir et HTTP-grensesnitt for å samhandle med JMX MBeans, som er nødvendige for å hente metrikker fra Tomcat. For å bruke Metricbeat til å hente Tomcat-metrikker, må Jolokia installeres i Tomcat-applikasjonen. Du finner mer informasjon om installasjon og konfigurasjon på Jolokia hjemmeside.

Konfigurering av Metricbeat

For å begynne å samle data med Metricbeat, må du først installere Metricbeat på systemet ditt. I vårt eksempel installerer vi Metricbeat 8.12.2 på Ubuntu ved hjelp av følgende kommandoer:

bash
$ curl -L -O https://artifacts.elastic.co/downloads/beats/metricbeat/metricbeat-8.12.2-amd64.deb
$ sudo dpkg -i metricbeat-8.12.2-amd64.deb

Når Metricbeat er installert, må vi konfigurere det til å koble til vår Elastic Cloud-installasjon. Åpne konfigurasjonsfilen for Metricbeat, som ligger på /etc/metricbeat/metricbeat.yml, og legg inn nødvendige detaljer for cloud.id og cloud.auth.

Deretter aktiverer vi Tomcat-modulen for Metricbeat:

bash
$ sudo metricbeat modules enable tomcat

Konfigurasjonsfilen for Tomcat-modulen ligger i /etc/metricbeat/modules.d/tomcat.yml. I vårt tilfelle trenger vi ikke å gjøre noen endringer i denne filen, da standardinnstillingene fungerer godt for de fleste brukstilfeller.

Nå skal vi konfigurere Jolokia-modulen i Metricbeat for å hente JMX-metrikker. For å gjøre dette, aktiver Jolokia-modulen:

bash
$ sudo metricbeat modules enable jolokia

Konfigurasjonsfilen for Jolokia-modulen er plassert i /etc/metricbeat/modules.d/jolokia.yml. En viktig del av konfigurasjonen er jmx.mapping, hvor vi mapper JMX MBean-attributter til Elastic Common Schema (ECS) attributter. Dette gir oss en standardisert måte å representere loggdata og hendelser på i Elastic Stack.

Eksempel på JMX-mapping

Her er et utdrag av hvordan JMX-mapping kan se ut i Jolokia-modulen:

yaml
- module: jolokia metricsets: ["jmx"] period: 10s hosts: ["localhost"] namespace: "metrics" path: "/jolokia/?ignoreErrors=true&canonicalNaming=false" jmx.mappings: - mbean: 'java.lang:type=Memory' attributes: - attr: HeapMemoryUsage field: memory.heap_usage - attr: NonHeapMemoryUsage field: memory.non_heap_usage

Når konfigurasjonen er ferdig, kan du starte Metricbeat for å begynne å hente Tomcat-metrikker og sende dem til Elasticsearch:

bash
$ sudo metricbeat setup -e
$ sudo service metricbeat start

Visualisering av metrikker i Kibana

Når Metricbeat begynner å sende data, kan du gå til Kibana for å visualisere metrikker. Naviger til "Analytics" -> "Dashboards" i Kibana og søk etter "tomcat". Du vil da finne "Metricbeat Tomcat Overview"-dashbordet, hvor du kan se detaljerte metrikker om Tomcat, som minnebruk, tråder, og globale forespørsler.

I tillegg kan du bruke Kibanas Observability-funksjoner til å overvåke systemhelse og infrastruktur. Gå til "Observability" -> "Infrastructure" -> "Hosts" for å inspisere systemmetrikkene på VM-en.

Hvordan det fungerer

Beats var historisk sett det foretrukne verktøyet for å hente tidsstemplet data fra forskjellige kilder. Selv om Elastic Agent nå er det foretrukne valget for å hente slike data, er Beats fortsatt et nyttig alternativ når det ikke finnes noen Elastic Agent-integrasjon for en spesifikk datakilde. I eksempelet vårt har vi brukt Metricbeat til å hente Tomcat-metrikker ved hjelp av Jolokia-modulen, som gir oss et standardisert format for dataene før de sendes til Elasticsearch.

Metricbeat bruker Elastic Common Schema (ECS), som er et standardisert skjema for strukturert loggføring og hendelsesdata i Elastic Stack. Denne standardiseringen gjør det enklere å analysere, sammenligne og visualisere dataene på tvers av forskjellige systemer og applikasjoner.

Hvordan detektere endringspunkter i tidsserieanalyse og anvende det på trafikdata

Endringspunktsdeteksjon er en kraftig metode for å analysere tidserie-data ved å identifisere øyeblikk der det skjer signifikante endringer i dataene. Det kan være enten en plutselig økning eller reduksjon i en måling, eller en endring i den overordnede trenden. Denne metoden gir innsikt i når og hvor endringer skjer, og kan brukes på tvers av ulike områder som finans, cybersikkerhet, industri og transport for å muliggjøre proaktive tiltak og forbedre den generelle dataanalysen. I denne artikkelen skal vi utforske hvordan endringspunktsdeteksjon kan brukes på trafikdata fra Rennes, og hvordan vi kan identifisere mønstre og korrelasjoner i dataene som kan bidra til å forstå og håndtere trafikkforhold mer effektivt.

Når vi analyserer trafikdata, kan vi begynne med å identifisere endringspunktene for gjennomsnittlig kjørehastighet på ulike steder i Rennes. Ved å bruke Kibana, kan vi sette opp en enkel endringsdeteksjon der vi justerer tidsspennet til de siste 24 timene og velger nødvendige innstillinger for aggregasjon og måleparametre. Dette gir oss en visualisering av endringspunktene som enten representerer en nedgang (dip) eller en økning (spike) i gjennomsnittlig kjørehastighet, samt et geografisk skille basert på forskjellige steder i byen.

Når vi har identifisert endringspunktene for én måling, kan vi utforske hvordan disse endringene samvarierer med andre faktorer, for eksempel kjøretidens varighet. Ved å legge til en ny aggregasjon for reisetid kan vi sammenligne de to målingene side om side, noe som gir oss en mer kontekstuelt rik forståelse av hvordan endringspunktene i kjørehastighet påvirker kjøretiden på forskjellige steder. Dette gir verdifull innsikt for trafikkplanleggere og beslutningstakere som ønsker å forstå dynamikken i bytrafikken.

Den praktiske bruken av endringspunktsdeteksjon går utover bare å identifisere trafikkendringer. Den kan også brukes til å analysere mer subtile mønstre i dataene som kan indikere viktige hendelser. For eksempel kan det hjelpe til å identifisere plutselige økninger i trafikkvolum som kan være forårsaket av uventede hendelser eller ulykker. Endringspunktsdeteksjon kan også brukes til å forstå mer langsomme trender, som for eksempel sesongmessige endringer i trafikken, og dermed gi en bedre basis for fremtidige trafikksikkerhetstiltak.

En annen viktig bruksområde for endringspunktsdeteksjon er i cybersikkerhet. I stedet for å stole på statiske terskler, som en unormalt høy mengde innloggingsforsøk, kan endringspunktsdeteksjon bidra til å identifisere subtile eller langsomt utviklende trusler som kan indikere et cyberangrep. For eksempel, en plutselig økning i nettverkstrafikk kan være et tegn på et distribuert tjenestenektangrep (DDoS), og ved å bruke endringsdeteksjon kan vi raskt identifisere når angrepet begynner, slik at tiltak kan iverksettes tidlig.

På samme måte kan endringspunktsdeteksjon oppdage endringer i forespørselsmønstre, for eksempel en plutselig økning i POST-forespørsler, som kan indikere et angrep som utnytter et sikkerhetshull i systemet. En annen interessant mulighet er å analysere endringer i trafikkens geografiske kilde, som kan signalisere at en angrepsgruppe prøver å få tilgang til systemet fra et nytt område. Dette kan være særlig nyttig i større nettverksinfrastrukturer der spredte angrep kan være vanskelige å oppdage.

Ved å anvende endringspunktsdeteksjon i praksis, kan organisasjoner bli mer proaktive i å identifisere trusler før de utvikler seg til fullskala-angrep. Dette gir en mer dynamisk og responsiv tilnærming til nettverksovervåkning, og hjelper til med å beskytte digital infrastruktur mer effektivt.

Det er også viktig å merke seg at endringspunktsdeteksjon ikke er begrenset til bare trafikkdata eller cybersikkerhet. Det kan også benyttes i en rekke andre sammenhenger, som for eksempel overvåking av produksjonsprosesser, hvor det kan bidra til å identifisere feil eller ineffektiviteter som kan oppstå plutselig i produksjonslinjen. Endringspunktene kan gi tidlige varsler om feil, og dermed gi muligheter for å iverksette korrigerende tiltak før problemene eskalerer.

En videre anvendelse er å bruke endringsdeteksjon for å forbedre den generelle kvalitetskontrollen og forvaltningen av data i ulike domener. Når endringspunktene er identifisert, kan de analyseres i detalj for å finne årsakene til endringene, og dette kan hjelpe organisasjoner til å ta mer informerte beslutninger. I tillegg kan det hjelpe til å minimere risikoen for at viktig informasjon overses, ettersom endringsdeteksjon fungerer som et ekstra verktøy for å fremheve avvik fra forventede mønstre.

Endringspunktsdeteksjon gir også muligheten til å bruke maskinlæring for å automatisk lære og forstå de typiske atferdsmønstrene i tidserie-dataene, noe som ytterligere forbedrer evnen til å identifisere anomalier og mønstre som ikke nødvendigvis er åpenbare for manuell analyse. Denne teknologien er et viktig skritt mot mer sofistikert dataanalyse og kan være svært nyttig i en tid der datamengder vokser eksponentielt.

Endtext

Hvordan implementere semantisk søk med spredte vektorer

Når man jobber med semantisk søk og generative AI, er det viktig å forstå forskjellen på de ulike tilnærmingene og teknologiene som er i bruk. Tidligere har vi brukt tette vektorer (dense vectors), men med fremveksten av modeller som ELSER, som benytter seg av spredte vektorer, har vi fått tilgang til mer effektive metoder for tekstutvidelse og forbedret søk.

I det nye skriptet som benyttes for ELSER-integrasjon, er en av hovedforskjellene hvordan inndata behandles. I stedet for å bruke den tradisjonelle tilnærmingen med feltkartlegging (field_map) og mål-felt (target_field) for å generere tette vektorinnkapslinger, benyttes det her et nytt felt, input_output, for å knytte inngangs- og utgangsfelt sammen. Det betyr at når en inndata er behandlet med ELSER-modellen, blir det generert token-verdier som knyttes til de relevante feltene i datasettet.

Det er viktig å merke seg at dette endrer hvordan dataene struktureres. I stedet for de tidligere tette vektorene, benytter man nå en ny type vektor, kalt sparse_vector, som er mer effektiv i lagring og behandling, spesielt når man jobber med store datasett.

Når dataene er prosessert og lagret, kan vi begynne å bruke dem for semantisk søk. Et vanlig steg her er å bruke Kibana for å se hvordan de spredte vektorene er lagret i Elasticsearch-databasen. For å gjøre dette, kan vi opprette et nytt data view i Kibana og deretter inspisere hvordan vektorene ser ut i systemet.

En viktig funksjon når man jobber med spredte vektorer er å bruke den spesifikke søkespørringen text_expansion, som er utviklet for å jobbe med slike vektorfelt. Denne spørringen tar inn tekst, som i vårt tilfelle en beskrivelse fra filmens plot, og utfører en tekstutvidelse ved å bruke den underliggende ELSER-modellen. Dette gjør at man kan finne relaterte resultater til søket, selv om de ikke nødvendigvis er direkte matchende ord, men heller semantisk relaterte konsepter.

Etter at søkespørringen er kjørt, kan vi begynne å bruke de spredte vektorene til å generere resultater for applikasjoner som krever semantisk søk, for eksempel en filmsøker. Ved å bruke det tilpassede søkeskjemaet som tar hensyn til spredte vektorer, kan vi få tilbake relevante resultater for brukere som søker på komplekse konsepter som er beskrevet i filmskript.

Hvordan fungerer dette teknologisk sett? ELSER benytter en nevralt nettverksbasert modell som anvender spredt hentingsteknikk for å støtte semantisk søk. Dette er basert på en teknikk kalt "term expansion". Begrepet innebærer at modellen utvider søket ved å bruke relaterte termer som er lært gjennom store treningsdatasett. Dette er en parallell til hvordan BM25-algoritmen opererer i tradisjonelt leksikalsk søk, men her er det fokus på semantisk relasjon mellom ordene, snarere enn deres bokstavelige forekomster.

Modellen identifiserer begreper som ofte opptrer sammen i tekst, og bruker denne kunnskapen til å returnere token/vekttilordninger som er semantisk knyttet til det opprinnelige søket. Når ELSER er i drift, vil den bruke dette til å rangere dokumentene på en måte som fremhever de mest relevante resultatene, basert på semantisk likhet.

Som et resultat av denne prosessen, ved å bruke spredte vektorer og term expansion, kan vi oppnå semantisk søk med høy nøyaktighet uten å måtte endre eller spesifisere omfanget av vårt datasett. Dette er spesielt nyttig i tilfeller der man har store mengder tekstdata som kan inneholde en rekke forskjellige, men relaterte konsepter. Den største fordelen med denne metoden er at den kan brukes på eksisterende datasett med minimal konfigurasjon og uten behov for dyptgående domene-spesifikke justeringer.

I tillegg er det verdt å merke seg at bruk av spredte vektorer reduserer behovet for lagringsressurser sammenlignet med tette vektorer, ettersom de fleste elementene i en spredt vektor er nullverdier. Dette gjør modellen mer skalerbar og raskere å behandle, særlig når man håndterer store datasett.

Med den nye søkefunksjonen som utnytter spredte vektorer, kan vi oppnå resultater som er praktisk talt identiske med de som oppnås ved hjelp av tette vektorer, men med bedre ytelse og mer effektive ressurser. Dette er en viktig utvikling for semantisk søk, og spesielt når man ønsker å bygge søkeapplikasjoner som kan håndtere komplekse forespørsler i stor skala.