Hvordan oppdage avvik og bygge regresjonsmodeller i Kibana

For å validere at datatransformasjonen har blitt korrekt opprettet, følg disse trinnene:

1. I Kibana, naviger til Stack Management | Kibana | Data Views, og klikk på Opprett data view. Opprett et nytt data view ved å bruke mønsteret for indeksen rennes-traffic-dataframe-analysis, som vist i figur 8.4.

2. Gå deretter til Analytics | Discover og velg det nylig opprettede data view. Bekreft at det er fylt med resultater fra datatransformasjonen, som vist i figur 8.5.

Når datatransformasjonen er vellykket satt opp og data view er opprettet for målindeksen, kan vi gå videre til hoveddelen av prosessen. Hvordan gjøre det?

De neste trinnene viser hvordan man setter opp en data frame analytics-jobb i Kibana for å identifisere uvanlige data i datasettet vårt. Vi vil bruke det transformerede data view fra Rennes trafikkdata og anvende maskinlæringsteknikker for å oppdage avvik:

1. I Kibana, gå til Machine Learning | Data Frame Analytics | Jobs.

2. Klikk på Opprett data frame analytics jobb og velg det transformerede data view, rennes-traffic-dataframe-analysis, som kilde til data view.

3. Sett Jobbtype til avviksdeteksjon og fortsett med følgende trinn:
   A. I konfigurasjonsseksjonen beholder du standardverdiene og klikker på Fortsett.
   B. I seksjonen for tilleggsmuligheter, øk minnegrensen for modellen til 50 MB og behold de andre standardverdiene. Klikk deretter på Fortsett.
   C. Bla ned til Jobbdetaljer-seksjonen, sett Jobb_ID til rennes-traffic-dataframe-outlier, og klikk på Fortsett.
   D. I valideringsseksjonen klikker du på Fortsett.
   E. Klikk på Opprett-knappen for å opprette jobben. På dette tidspunktet bør du se bekreftelser på jobben som er opprettet og startet, som vist i figur 8.6.
   F. Klikk på Data Frame Analytics, og du vil se oversikten over maskinlæringsjobben og fremdriften til jobben.

Når statusen til jobben endres til stoppet (det skal ta bare noen sekunder), kan du klikke på visningsikonet for å se resultatene, som vist i figur 8.7.

Nå kan du begynne å utforske resultatene fra avviksdeteksjonsjobben. I scatterplot-matrisepanelet, under alternativet "Fields", velg max_speed.max og traveltime.duration.avg og sett utvalgsstørrelsen til 10 000, som vist i figur 8.8. Dette vil avsløre forholdet mellom disse to aggregatene i to dimensjoner, og markere avvik med større og distinkte prikker.

Score for avviket (ml.outlier_score) varierer fra 0 til 1. Jo høyere verdien er, desto mer sannsynlig er det at enheten er et avvik. Videre får hvert dokument annotasjoner i form av påvirkningsverdier for funksjoner, som er tildelt individuelle felt. Disse verdiene summeres til 1, og signaliserer den relative betydningen av hvert felt i klassifiseringen av enheten som enten et avvik eller ikke. Et eksempel på dette er mørk skyggelegging på feltet, som indikerer at traveltime.duration.avg var den mest innflytelsesrike faktoren for å identifisere avviket.

Avviksdeteksjon fokuserer på å identifisere atypiske datapunkter i et datasett. Unormaliteten til et datapunkt bestemmes av nærheten til andre punkter og tettheten av nærliggende klynger. Normale punkter har vanligvis mange naboer, mens avvik er plassert lenger fra disse klyngene. Metoden for å beregne denne unormaliteten er basert på avstand, ved bruk av K-nærmeste nabo-algoritmer. Resultatet uttrykkes som en avvikscore – jo høyere avvikscore, desto mer atypisk anses punktet å være. Mens man peker ut avvik, hjelper Elasticsearch også med å tolke årsakene bak hvorfor et datapunkt er et avvik ved å fremheve det mest innflytelsesrike feltet som bidrar til unormaliteten.

Når en modell er trent og evaluert, kan den implementeres for prediksjon. I dette tilfellet, med regresjonsmodellen, er målet å forutsi den gjennomsnittlige reisetiden basert på faktorer som plassering, ukedag og tidspunkt på dagen. Dette er et klassisk eksempel på hvordan regresjon kan hjelpe til med å forstå og forutsi atferd i komplekse datasett.

Endtext

Hvordan fungerer OpenTelemetry-integrasjonen i Elastic Observability, og hvordan overvåke Kubernetes med Elastic Agent?

Selv om OpenTelemetry-agenter kan sende data direkte til Elastic Stack, anbefales det i produksjonsmiljøer å benytte Collector for å sikre bedre ytelse og skalerbarhet. Elastic tilbyr også en OpenTelemetry-bridge som oversetter API-kall fra OpenTelemetry til Elastic APM API-kall, og dette finnes per i dag for Java, .NET, Node.js og Python. Denne broen gjør det mulig å gjenbruke eksisterende instrumentering, noe som forenkler integrasjon av flere teknologier i samme overvåkingsplattform.

Når det gjelder Kubernetes-miljøer, er det avgjørende å overvåke ikke bare applikasjonsnivået, men også infrastrukturen som applikasjonene kjører på. Elastic Agent med Kubernetes-integrasjon gjør det mulig å samle inn både loggfiler fra containere og infrastrukturmetrikker. Ved å installere Elastic Agent i Kubernetes-klyngen, kan man sende denne informasjonen til Elastic Stack og bruke ferdigkonfigurerte dashboards for å få innsikt i både applikasjonsytelse og klyngehelse.

Installasjonsprosessen starter med opprettelse av en agentpolicy i Kibana under Fleet, hvor man velger Kubernetes som plattform og laster ned manifestfilen som deployeres i klyngen med kubectl. For at Kubernetes-integrasjonen skal fungere optimalt, må kube-state-metrics være installert. Denne tjenesten kommuniserer med Kubernetes API-serveren for å generere metrikker som Elastic sin integrasjon benytter for å fylle dashboards med informasjon om klyngens tilstand, som noder, pods, og andre objekter.

Etter at Elastic Agent er på plass og kube-state-metrics kjører, legges Kubernetes-integrasjonen til i agentpolicyen. Når data strømmer inn, blir de synlige i dashboards i Kibana, hvor man kan overvåke ressursbruk som CPU, minne og nettverk på tvers av pods, samt få en helhetlig oversikt over klyngens tilstand.

Det er viktig å forstå at effektiv overvåking i komplekse distribuerte systemer som Kubernetes krever en helhetlig tilnærming der både applikasjonsnivå og infrastrukturnivå må dekkes. OpenTelemetry gir en fleksibel og standardisert måte å samle inn telemetridata på, mens Elastic Stack tilbyr kraftige verktøy for lagring, visualisering og analyse. Bruken av Collector sikrer at datainnsamlingen er robust og effektiv, noe som er spesielt kritisk i produksjonsmiljøer med høy trafikk og mange komponenter.

Ytterligere forståelse av samspillet mellom de ulike komponentene i OpenTelemetry-økosystemet og Elastic Observability er sentralt for å kunne optimalisere konfigurasjonen og oppnå best mulig innsikt. For eksempel, vurdering av nettverksbelastning, datakonsistens, og hvordan data aggregeres og rutes, har stor betydning for kvaliteten på overvåkingen. Videre er det nødvendig å ta hensyn til sikkerhetsaspekter ved overføring av telemetridata, spesielt i produksjonsmiljøer med sensitive opplysninger. Bruk av autorisasjonsnøkler og sikre endepunkter er derfor avgjørende.

Hvordan administrere tilgangskontroll i Elastic Stack: En guide til brukerroller og sikkerhet

I Elastic Stack er tilgangskontroll en grunnleggende komponent for å sikre at dataene er beskyttet og tilgjengelige på en ansvarlig måte. Brukerroller og autentisering spiller en avgjørende rolle i å regulere tilgangen til systemet og opprettholde datasikkerhet. I denne delen av boken tar vi for oss hvordan man administrerer tilgangskontroll i Elastic Stack, med fokus på innebygde og egendefinerte roller, og hvordan man sikrer tilgang til Kibana og andre verktøy uten å gå på akkord med sikkerheten.

For å opprettholde en sikker operasjon i Elastic Stack er det viktig å bruke tilgangskontrollsystemer som forhindrer uautorisert tilgang og samtidig gir brukerne nødvendige privilegier for å utføre sine oppgaver. I de tidligere kapitlene har vi utforsket flere brukstilfeller for Elastic Stack, fra datainnsamling til overvåkning og analyse. Imidlertid har vi hittil antatt en enkel konfigurasjon med administratortilgang. I virkelige scenarioer, hvor flere personer kan jobbe med systemet, er det viktig å implementere et mer strengt sikkerhetssystem som gjør at vi kan dele ressursene uten å risikere utilsiktede endringer.

En effektiv måte å kontrollere tilgang på er gjennom bruk av roller i Elastic Stack, som gir ulike nivåer av tilgang til ressurser og funksjoner. Ved hjelp av innebygde roller kan du enkelt regulere hvem som kan se og gjøre hva i systemet. Disse rollene er forhåndsdefinerte sett med tillatelser som styrer hva brukere kan gjøre med indekser, administrere klyngedrift og bruke funksjonene i Kibana. For eksempel kan du opprette en bruker med en "viewer"-rolle, som gir tilgang til visning av data og dashbord uten å gi tillatelse til å redigere eller slette noe. Dette gjør det lettere å sikre at folk kan se informasjon uten risikoen for utilsiktede endringer.

Etter at brukeren er opprettet, kan du logge ut og bruke de nøyaktige innloggingsinformasjonene for å logge på som den nye brukeren. Som en bruker med "viewer"-rollen vil du se færre alternativer i Kibana, og du vil ikke ha tilgang til funksjoner som kan endre systemet. Dette demonstrerer hvordan innebygde roller kan hjelpe til med å beskytte integriteten til Elastic Stack-innstillingene samtidig som det gir nødvendig tilgang til data.

Men hva skjer når standardroller ikke er tilstrekkelige? I slike tilfeller kan du lage egendefinerte roller, som gir deg mer fleksibilitet til å tilpasse tilgangen etter spesifikke behov. Egendefinerte roller gjør det mulig å justere tillatelsene mer presist og sørge for at brukerne kun har tilgang til de funksjonene og dataene de trenger.

For eksempel kan en systemadministrator ha full tilgang til alle systemer og konfigurasjoner, mens en utvikler kun trenger tilgang til de relevante indekser og dashbordene for sine prosjekter. En finansanalytiker kan trenge tilgang til spesifikke rapporter og analyser, men bør ikke kunne endre systeminnstillinger. Ved å definere egendefinerte roller kan du skreddersy tilgangen til akkurat det som er nødvendig, noe som øker både sikkerheten og produktiviteten i organisasjonen.

En annen viktig funksjon i Elastic Stack er bruken av API-nøkler, som kan brukes til å gi spesifik tilgang til bestemte ressurser. API-nøkler er spesielt nyttige når du trenger automatiserte prosesser som tilgang til data gjennom programvare eller skript. Ved å bruke API-nøkler kan du definere nøyaktige tillatelser på programmatisk nivå, noe som gir mer kontroll over tilgang uten å måtte stole på manuell rolleadministrasjon.

For mer kompleks tilgangsstyring, kan du også implementere Single Sign-On (SSO), som gjør det lettere for brukerne å få tilgang til systemet gjennom en enkelt autentisering. Dette er spesielt nyttig i større organisasjoner der mange applikasjoner brukes, og SSO forenkler både administrasjonen og brukeropplevelsen. For å konfigurere SSO, kan du følge de nødvendige trinnene som er beskrevet i dokumentasjonen, og dette kan bidra til å strømlinjeforme sikkerheten ytterligere.

Det er viktig å merke seg at tilgangskontroll i Elastic Stack ikke bare handler om å hindre uautorisert tilgang. Det er like viktig å tillate den rette tilgangen på en kontrollert måte. Jo mer du tilpasser tilgangsrettighetene til behovene i organisasjonen din, jo mer effektivt kan du håndtere både sikkerheten og arbeidsflyten. Riktig konfigurasjon av tilgangskontroll bidrar til en balansert sikkerhet der både dataene og brukernes produktivitet ivaretas.

Endtext