Hva er forskjellen mellom Watcher og Kibana varsling? En dypere forståelse av varslingsrammeverk i Elastic Stack.

Watcher, et tidligere sentralt verktøy for varsling i Elastic Stack, har blitt mer av en legacy-funksjon etter introduksjonen av Kibana varsling, som nå er det anbefalte og mer fleksible systemet for håndtering av varsler. Watcher ble opprinnelig utviklet for å overvåke spesifikke forhold i dataene dine, kontinuerlig analysere og utløse definerte handlinger når bestemte betingelser ble oppfylt. Dette kunne innebære alt fra å sende e-post til å trigge webhooks eller Slack-varsler, avhengig av hvordan det var konfigurert.

Den største forskjellen mellom Watcher og Kibana varsling ligger i deres integrasjon og fleksibilitet. Kibana varsling er en mer moderne, fullstendig integrert løsning med en rekke fordeler som ikke er tilgjengelige i Watcher, slik som muligheten for å tilpasse varsler i sanntid, handlinger basert på komplekse spørringer, og en bedre brukeropplevelse med visuelle verktøy for å administrere varsler. Mens Watcher fortsatt kan være nyttig i tilfeller hvor det er behov for avansert skreddersydd logikk eller kompleks betingelsesstyring, har Kibana varsling utvilsomt overtatt som det dominerende valget.

I de tilfellene hvor Watcher fremdeles er nyttig, er det ofte relatert til eldre systemer som allerede har blitt konfigurert med Watcher. Overgangen til Kibana varsling kan være ressurskrevende, og i slike tilfeller kan det være bedre å opprettholde Watcher-løsningene. En annen situasjon der Watcher kan være fordelaktig, er når det er behov for avansert tilpassing, som for eksempel når det kreves skripting eller betingede handlinger som er vanskelig å implementere i Kibana varsling.

I den nyere versjonen av Elastic Stack, spesielt 8.x, er det introdusert en rekke nye funksjoner for varsling. Kibana tilbyr nå et sett med API-er for handlinger og koblinger, som gjør det lettere å utvide og tilpasse varselsystemet etter spesifikke behov. Den komplette dokumentasjonen for disse API-ene kan finnes på Elastic sin nettside, og det er mange detaljerte eksempler på hvordan man setter opp og konfigurerer tilkoblinger for varsler.

Å sette opp varsler er avgjørende for proaktiv overvåkning av data, og derfor er det viktig å forstå hvordan man kan følge opp og overvåke varsler etter at de er opprettet. Kibana gir en robust ramme for overvåkning av varsler, der man kan se status på varsler og handlinger knyttet til bestemte regler. For eksempel, i Kibana, kan man bruke "Logs"-fanen for å vise alle aktive logger for reglene som er definert i systemet, og filtrere på spesifikke tidspunkter eller utførelsesstatus for å få innsikt i systemets tilstand.

Når det gjelder å overvåke varsler, er det viktig å forstå hvilke målinger som er mest relevante for å vurdere ytelsen til varslene. En nøkkelindikator som bør overvåkes er gjennomsnittlig kjøretid for reglene, som gir en indikasjon på hvor effektivt systemet kjører. Historikkfunksjonene i Kibana gir en visualisering av ytelsen over tid, og den kan justeres for å vise alt fra de siste 30 kjørene til de siste 120, avhengig av hva som trengs.

Et viktig aspekt ved Kibana varsling er håndteringen av handlinger som er tilknyttet reglene. Handlinger kan være alt fra sending av e-post til eksterne varsler via Slack eller API-er. Her er det viktig å følge med på feilhåndtering, som kan inkludere scenarioer der en feilaktig konfigurasjon fører til at varsler ikke blir sendt eller handlinger ikke blir utført korrekt. Å forstå hvordan du kan håndtere slike feil er essensielt for å sikre påliteligheten til varselsystemet.

Eksempelet med å sette opp en e-posttilkobling som med vilje er feilkonstruksjon, viser hvordan man kan teste feil i systemet og hvordan Kibana gir muligheten til å overvåke disse feilene på en effektiv måte. Når en feil skjer i et varselsystem, som en ugyldig e-postserverkonfigurasjon, kan dette lett oppdages via Kibanas grensesnitt, og detaljer om feilen kan undersøkes for å finne årsaken til at varslet ikke ble sendt.

I praksis er det viktig å ha et godt forståelsesgrunnlag for hvordan systemet reagerer på ulike betingelser og hvilke skritt som kan tas for å rette feil før de påvirker den daglige driften. Å bygge et robust varselsystem i Kibana handler ikke bare om å sette opp regler, men også om å ha full kontroll over hvordan de utføres, overvåkes og feilsøkes.

Hvordan forbedre feilsøking og varsling gjennom logganalyse og regelkonfigurasjon

Når man arbeider med regelkonfigurasjon i Kibana, er et kritisk skritt å oppdatere og verifisere at reglene for varsler fungerer korrekt i henhold til de angitte frekvensinnstillingene. Etter at en endring i regelkonfigurasjonen er gjort, som for eksempel å knytte handlinger til spesifikke feiltilkoblinger, er det viktig å lagre disse endringene og deretter manuelt kjøre regelen. Dette kan gjøres gjennom Kibanas brukergrensesnitt ved å bruke menyen som vises øverst til høyre, hvor man kan velge å «kjøre regelen» umiddelbart. Etter utførelsen er det lurt å navigere til "Historikk"-fanen, hvor alle feilmeldinger som har oppstått under den nylige kjøringen, blir logget.

En god forståelse av loggføringssystemet gjør det mulig å identifisere feil og finne årsaken til at en handling mislykkes. Det er her Kibanas loggfunksjonalitet spiller en viktig rolle, spesielt i produksjonsmiljøer med høy belastning, hvor rask feilsøking kan være en utfordring. Når en feil oppstår i en handling, kan du åpne feilmeldingen for å se detaljene, som inkluderer både selve feilen og den underliggende årsaken til at handlingen ikke ble utført som forventet. Dette gjør det lettere å forstå hva som gikk galt og rette opp i det.

Videre er logganalyse et kraftig verktøy for å identifisere trender og endringer i loggdata, og spesielt logghastighetsanalyse kan gi innsikt i hvorfor loggaktivitetene har økt eller minsket. Denne funksjonen er en del av den mer omfattende AIOps (Artificial Intelligence for IT Operations)-kapabiliteten i Elastic Stack, som benytter maskinlæring for å gjøre IT-operasjoner mer proaktive. Ved å analysere loggfrekvenser og identifisere statistisk signifikante avvik, kan systemet raskt peke på mulige årsaker til nedgang i aktivitet, som for eksempel at trafikkmønstre endrer seg i løpet av natten.

Logghastighetsanalyse innebærer at man kan filtrere og analysere loggdata for å finne spesifikke hendelser som kan indikere problemer, for eksempel "trafikkbelastning" eller "tung trafikk". Ved å bruke Kibanas histogramverktøy, kan man plassere avviksvinduet på områder med lav aktivitet og baselinjen før dette, for å utføre en analyse av hva som forårsaket nedgangen i loggaktiviteten. Denne analysen gir detaljerte tabeller som viser hvilke feltverdier som har størst påvirkning på loggdataene, og gjør det lettere å identifisere rotårsaken til problemet.

En viktig fordel ved logghastighetsanalyse er at den gir en omfattende oversikt over loggdataene, og hjelper til med å oppdage trender og mønstre som ellers kunne gått ubemerket hen. Denne funksjonen benytter avanserte statistiske metoder for å analysere logghastigheter og gir dermed innsikt i potensielle problemer før de eskalerer til større feil.

Det er viktig å merke seg at både de tekniske verktøyene og metodene for logganalyse ikke bare hjelper med å diagnostisere og løse problemer, men også med å forebygge dem. Ved å forstå og bruke de rette verktøyene for overvåking og analyse, kan man skape et mer robust og pålitelig IT-miljø, der eventuelle problemer blir identifisert tidlig og håndtert effektivt.

Hvordan bruke en trent modell til inferens i Elastic Stack

På "Konfigurer prosessor"-siden kan du sette opp innstillinger for inferens-konfigurasjonen. Som regel kan du la disse være på sine standardinnstillinger. Under konfigurasjonen vil du legge merke til en seksjon for felt. Dette er viktig å konfigurere dersom de innkommende dokumentene ikke inneholder de input-feltene modellen forventer. Når dette er på plass, kan du fortsette til neste steg.

På "Test"-siden (som er valgfri) får du en god mulighet til å teste pipelinen. Denne er forhåndsutfylt med et eksempel-dokument, og ved å klikke på "Simuler pipeline" kan du sjekke resultatet. Hvis alt ser riktig ut, kan du gå videre.

På "Opprett"-siden kan du gjennomgå pipelinen din før du lager den. Hvis du ønsker, kan du kopiere og lagre konfigurasjonen for gjenbruk, for eksempel via et API-kall i Dev Tools. Når alt er som det skal være, kan du fullføre opprettelsen ved å klikke på "Opprett pipeline".

Når pipelinen er opprettet, er modellen din nå vellykket distribuert og klar til å brukes i inferens-pipelinen. Det betyr at du kan begynne å bruke modellen på nye data for å gjøre prediksjoner basert på det modellen har lært. For å gjøre det lettere å bruke modellen, har vi laget en Streamlit-basert Python-applikasjon, som er tilgjengelig i vårt GitHub-repository. Denne applikasjonen gir en grafisk grensesnitt der brukeren kan interagere med den distribuerte modellen. Ved å laste ned appen og installere nødvendige avhengigheter, kan du begynne å gjøre prediksjoner.

Når det gjelder hvordan inferens fungerer i Elastic Stack 8, blir dette teknisk sett utført ved å distribuere en trent modell til en ML-node. Under distribusjonsfasen definerer du en ingest-pipeline som skal brukes til inferens. Modellen, som er trent på historiske data, er lagret i Elasticsearch. Når nye data kommer inn, sendes de til inferens-prosessoren eller API-en, som anvender modellen på dataene for å gjøre prediksjoner eller klassifikasjoner.

Prosessen er dypt integrert med Elasticsearch sin databehandlings- og lagringsevne, noe som gjør inferensoperasjoner både effektive og skalerbare.

Det er viktig å merke seg at selv om vi har fokusert på distribuerte modeller som er trent i Elasticsearch, kan du også importere tredjepartsmodeller til Elastic Stack. Dette kan gjøres ved hjelp av Eland, en Python-klient som gjør det mulig å bruke modeller trent med biblioteker som scikit-learn, XGBoost og LightGBM. Du kan også distribuere tredjeparts NLP-modeller ved hjelp av Eland-klienten, og dette vil bli dekket i den neste delen.

Når det gjelder distribusjon av tredjeparts NLP-modeller, kan vi importere NLP-modeller som er trent på plattformer som Hugging Face, og teste dem i Elastic Stack ved hjelp av Kibana sin dedikerte UI for trente modeller.

For å importere tredjeparts NLP-modeller, må du først sørge for at Python 3.11 eller nyere er installert på systemet ditt, samt at du har et Elastic 8.x-distribusjon i gang. For enkel pakkehåndtering, anbefales det å bruke pip. Det er også nødvendig å ha Cloud ID, samt brukernavn og passord for grunnleggende autentisering mot din Elastic Cloud-distribusjon.

For eksempel kan vi importere modeller for Named Entity Recognition (NER) og tekstklassifisering. Etter at du har installert Eland Python-klienten, kan du begynne å importere modeller fra Hugging Face ved å bruke kommandoer i terminalen. Dette kan gjøres for flere NLP-oppgaver som tekstklassifisering eller NER-modeller. Den første modellen vi importerer er for NER, og den andre modellen er spesifikt laget for å forutsi filmgenrer. Når modellene er importert, kan de testes og brukes i en pipeline for inferens.

Hvordan bygge avanserte søkeapplikasjoner ved hjelp av hybrid søk og boosting

Hybrid søk er en kraftig teknikk som kombinerer ulike søkemetoder, som leksikalsk søk og k-NN (k nærmeste naboer)-søk, for å gi mer presise og relevante søkeresultater. Denne teknikken er spesielt nyttig når man trenger å integrere ulike typer data og søkemetoder i én enkelt applikasjon, slik som tekst- og vektorbaserte søk. En viktig utfordring ved å bruke hybrid søk er å finne riktig balanse mellom de ulike søkesystemene, spesielt når man benytter seg av teknikker som boosting og RRF (Reciprocal Rank Fusion).

Boosting er en metode der man tilordner vekter til forskjellige deler av et søkespørsmål for å prioritere visse resultater over andre. Når du bruker boosting i kombinasjon med leksikalsk søk (som bruker BM25-algoritmen) og vektorsøk (som bruker k-NN), justeres poengsummene før de slås sammen for hvert dokument. For eksempel, i vår applikasjon kan poengsummene fra BM25 og k-NN justeres med boost-faktorer som gjør at de søkeresultatene som kommer fra én metode får høyere prioritet enn de fra en annen. Dette krever at man forstår forskjellene i poengsumene mellom de ulike metodene og finner den riktige balansen for å unngå at én metode dominerer resultatene på en uønsket måte.

En annen teknikk for å håndtere kombinasjonen av resultater fra forskjellige søkemetoder er RRF, som benytter rangeringen av dokumentene fremfor de rå poengsummene. Dette er en fordel ettersom poengsummene kan variere betydelig mellom leksikalsk søk og k-NN søk. I stedet for å stole på de absolutte poengene, bruker RRF rangeringen til å kombinere søkemetodene på en mer rettferdig måte. Ved å bruke parametrene window_size og rank_constant kan du finjustere hvordan de ulike rangene slås sammen.

For å implementere hybrid søk med RRF i Elasticsearch, kan man begynne med å kjøre både leksikalsk søk og vektorsøk separat for å få rangeringen av dokumentene fra begge systemene. Deretter kan du bruke RRF-formelen, som er 1/(rank_constant + rank), for å kombinere rangeringen av dokumentene. En lavere verdi for rank_constant gir større vekt til høyere rangerte dokumenter, noe som kan være nyttig i situasjoner der du ønsker å prioritere nøyaktige treff i søket. Når du har kombinert rangeringen, kan du bruke den samlede rangeringen til å generere en mer balansert liste over søkeresultater.

Videre kan du også bruke sparsomme vektorer i hybrid søk, i tillegg til de tettere vektorene som vi har sett på i oppskriften vår. Denne tilnærmingen kan være nyttig når dataene er veldig tette eller sparsomme, avhengig av hvordan vektorene er representert.

For å oppsummere, gir hybrid søk deg muligheten til å utnytte både leksikalsk søk og k-NN søk i én søkefunksjon, og gir deg dermed muligheten til å lage mer avanserte søkeapplikasjoner. Imidlertid er det viktig å forstå hvordan man balanserer resultatene fra de ulike metodene ved hjelp av teknikker som boosting og RRF. Det krever både eksperimentering med parametere og en god forståelse av hvordan poengsummer og rangeringer fungerer i Elasticsearch.

En viktig faktor som kan påvirke resultatene i hybrid søk er hvordan parametrene window_size og rank_constant blir justert. Disse påvirker hvordan rangeringen kombineres og kan ha en betydelig effekt på søkets relevans og ytelse. Det er også viktig å merke seg at Elasticsearch støtter flere k-NN søk innen én søkespørring, noe som kan være spesielt nyttig i applikasjoner som håndterer forskjellige datatyper.

Hvordan gi spesifikke privilegier og administrere tilgangskontroll i Kibana og Elasticsearch

For å sikre at bare autoriserte brukere har tilgang til bestemte data og funksjoner i Elasticsearch og Kibana, er det nødvendig å bruke en kombinasjon av tilgangsroller og privilegier. Dette inkluderer både generell tilgang til kluster- og indekser, samt mer granulær kontroll over hvilke data spesifikke brukere kan se eller manipulere. Denne typen tilgangskontroll er avgjørende for å opprettholde både sikkerhet og samsvar med databehandlingsretningslinjer.

Indeksprivilegier bestemmer hvilke handlinger en bruker kan utføre på Elasticsearch-indekser, for eksempel å lese eller skrive data, administrere indeksinnstillinger eller utføre indeksspesifikke handlinger.

Kibana space-privilegier bestemmer hvilke Kibana-spaces en bruker kan få tilgang til og hvilke handlinger de kan utføre innenfor disse rommene. Dette kan innebære å lage og administrere dashboards, visualiseringer, eller bruke utviklerverktøy.

Feature-privilegier gir tilgang til spesifikke funksjoner i Kibana, for eksempel visualiseringer og dashboards. Det er også viktig å forstå at brukertildeling kobler en eller flere roller til en bruker, og disse rollene bestemmer brukerens tilgangsnivå til ulike data og funksjoner.

RBAC (Role-Based Access Control) er et kraftig verktøy for å sikre at brukere kun får tilgang til dataene og funksjonene som er nødvendige for deres roller, noe som reduserer risikoen for uautorisert tilgang og feilaktig databehandling.

Det finnes også tilfeller der brukeren ikke trenger tilgang til Kibana, for eksempel når Elasticsearch brukes som datalager for tredjepartsapplikasjoner eller søkeapplikasjoner. I slike tilfeller kan du opprette Elasticsearch-roller uten å legge til Kibana-privilegier. Disse rollene kan opprettes via Kibana UI eller via et dedikert API for Elasticsearch rolleadministrasjon.

For mer detaljerte beskrivelser av de ulike privilegiene som kan tildeles roller, kan brukere konsultere Elastic sine offisielle dokumentasjoner for både klusterprivilegier og indeksprivilegier.

Field-level security tillater administratorer å spesifisere hvilke felt i et dokument som skal være synlige for brukere med en bestemt rolle. Dette kan være nyttig for å hindre at sensitiv informasjon, som for eksempel brukernes personlige identifikasjon eller finansiell informasjon, blir eksponert. Ved å sette opp feltbegrensninger kan administratorer kontrollere hvilke felt som skal vises i søk, visualiseringer eller i Kibana Discover.

På den andre siden gir document-level security tilgang til å restriksjonere spesifikke dokumenter innenfor en indeks. Dette kan være spesielt nyttig når det er behov for å gi brukere tilgang til bare deler av datamengden basert på spesifikke kriterier, som for eksempel tilgang til Kubernetes-logger i et observability-miljø. Ved å bruke dokumentnivåspørsmål kan administratorer finjustere tilgangen til dokumenter basert på innholdet i disse dokumentene.

Når du tildeler privilegier for field-level security, kan du spesifisere hvilke felt brukeren skal få tilgang til, og hvilke felt de ikke skal kunne se. For eksempel kan du gi en bruker tilgang til et dokument, men skjule visse følsomme felt som "insee" i indeksen. Dette kan gjøre at enkelte sensitive opplysninger forblir skjult for brukere som ikke har nødvendig tilgang.

I praksis kan dette oppnås gjennom Kibanas grensesnitt under "Stack Management | Security | Roles", hvor du kan oppdatere roller med spesifikke privilegier for felt og dokumenter. Etter at oppdateringene er gjort, kan brukerne logge inn og verifisere at tilgangen er korrekt satt opp, for eksempel ved å prøve å se på spesifikke dokumenter eller logger i Kibana Discover eller Observability-verktøyet.

I tillegg til at man setter opp tilpassede roller og privilegier, er det viktig å ha en regelmessig gjennomgang av tilgangsinnstillinger for å sikre at de fortsatt samsvarer med organisatoriske behov og sikkerhetskrav. Dette gjelder både for brukere som har fått tilgang til systemene, og for roller som kan ha fått unødvendig bred tilgang over tid.