ElasticON in de Beurs van Berlage op 22 november 2022

Ingediend door Dirk Hornstra op 06-dec-2022 21:57

Een collega heeft in het verleden een script gemaakt om IIS logs weg te schrijven in een MSSQL-database. Je kunt dan zoeken op tijdstippen, foutmeldingen en hopelijk de oorzaak van bepaalde fouten of andere meldingen terug vinden. Op een later tijdstip konden we Kibana inzetten, daarmee kun je rechtstreeks op de log-bestanden query-en, heb je een goede web-interface, dus dat was een prima vervanger. Nog weer later kwam APM naar voren, een oud-collega had hier goede ervaringen mee, wij zijn er ook naar gaan kijken. Deze producten horen in de "Elastic Stack".

Een tijdje geleden werden we getipt door oud-collega Dirk-Jan de Vries: ElasticON op 22 november in Amsterdam. Omdat ik wel benieuwd was of er zaken/besproken zouden worden waarmee we beter/anders/uitgebreider gebruik kunnen maken van deze tooling (en welke nieuwe tools er zijn) via Tres een kaartje gekocht.

Registratie en het rondlopen bij de sponsors is tussen 8.30 en 9.30 uur, de kickoff is om 9.30 uur. Rond Amsterdam is het altijd druk qua verkeer en ik zag dat bij de locatie waar ik ga parkeren (via de website van QPark, in de parkeergarage aan de Nieuwendijk) in een straat ligt waar druk gegraven en gewerkt wordt.

Dus... om 5.00 uur opstaan, om 6.00 uur in de auto. Door de polder, het rijdt op zich prima door. Sta ik toch weer voor een afgesloten Piet Heijn-tunnel (is die nu nog niet klaar, eind juni stond ik hier ook al), dus via de volgende afslag door de stad, maar om 8.05 uur staat de auto netjes in de parkeergarage! De Nieuwendijk is vlakbij het Damrak door door een paar smalle steegjes sta ik al tegenover de Beurs van Berlage, een kwartier voordat de deuren officieel open gaan. Dus eerst maar even richting Madame Tussaud gelopen. Starbucks is ook nog dicht. Bij het terug lopen bij de Mc Donalds naar binnen, eerst een cappuccino. Rond 9.00 uur bij de Beurs van Berlage naar binnen. Naam invoeren, badge uitprinten, jas ingeleverd bij de garderobe. Bij de grote zaal even bij de stands kijken, rond 9.15 bij de zaal naar binnen. Die is nog leeg, dus mooi op de 4e rij aan het gangpad. En zo kan ik mooi foto's maken van de sheets die getoond worden.

De slides kun je hier online zien: link.

Matthew Day

De eerste spreker is Matthew Day, baas van Elastic uit Engeland. En hij laat zien welke diensten hij overdag gebruikt. En die maken allemaal weer gebruik van Elastic, de BBC, Booking.com, Soundcloud.

Shay Banon en Uri Cohen

Volgende sprekers zijn Shay Banon, de CTO en founder van Elastic en Uri Cohen van Elastic. Elastic bestaat alweer 10 jaar! De Stack zit gekoppeld aan de kernbegrippen "Speed. Scale. Relevance.". Als je zoekt wil je dat je resultaten snel beschikbaar zijn, dat als de data een factor 10 groter wordt de boel kan opschalen zodat de snelheid gewaarborgd blijft. En relevantie: als ik zoek op een wit shirt heb ik niets aan een lijst met spijkerbroeken. Dat is waar Elastic mee gestart is: zoeken.

We zien de onderdelen welke ontstaan zijn, 2012: Elasticsearch, Logstash en Kibana, 2015: Found, Packetbeat, 2016: Prelert, 2017: Opbeat, Swiftype, 2019: Perched, Endgame, 2021: Build.Security, CMD, Optimyze.

En op die tweede slide zie je ook "Search. Observe. Protect." staan. Dus niet alleen meer alleen zoeken. Maar ook monitoren en beschermen. Je kunt Elastic ook in (hun) cloud laten draaien. En je ziet, de zaken die ik benoemd heb om te gebruiken, zijn al zo'n beetje 10 jaar oud. Het wordt dus hoog tijd om daar meer mee te doen en om te kijken wat al die andere overnames/producten te bieden hebben.

Tien jaar "antwoorden vinden", dus waar is een Über taxi die ik kan gebruiken, welk restaurant kan ik boeken, welke films zijn voor mij interessant (Netflix).

We zien ook de aantallen, code staat op Github: https://github.com/elastic

  • Downloads: meer dan 3.6 biljoen.
  • Github Stars: meer dan 103.000.
  • Pull Requests: meer dan 183.000.
  • Commits: meer dan 148.000.
  • Unieke auteurs: meer dan 3.500.

Bepaalde zaken zijn volgens mij betaald (je moet ergens je geld mee verdienen), maar met de basis kun je al heel veel.
De grote problemen worden benoemd als "Data problemen": IT observability, cyber security, enterprise search.

We zien hoe er allemaal data "input" is. De websites, de apps, de logs, de metrics, content. Dit moet allemaal verwerkt/opgeslagen worden: ingestion.Vervolgens wordt het opgeslagen, doorzocht en geanalyseerd. Op basis daarvan kan de visualisatie en mogelijkheid om daarin te zoeken aangeboden worden.

De component Elastic Observability.
Één Unified Agent die alle data kan stroomlijnen voor "ingestion". Native ondersteuning voor OpenTelemetry (die tool is genoemd bij Technation en heeft mijn interesse). 7.0 - 7.17 (huidige versie lijkt mij).
Vervolg is dat er met AIOps-drive incident management op ingespeeld wordt. Root cause analyse automatiseren. CI/CD observability die geintegreerd is. 8.0 - 8.5 (komende versie(s)?).
Laatste deel is Continuous Profiling, Cloud Synthetics en AI Ops, dit (nog) toekomstmuziek.

Volgende blok is Elastic Security. Dit blok it boven de visualize en explore. Vier blokken: Continuous Monitoring, Automated Threat Protection, Investigation and Incident Response en Threat Hunting. Hier boven zit SIEM / Security Analytics. Waarboven Endpoint en Cloud zit.

Items zijn unify SIEM, endpoint security en XDR. Het uitschakelen van "blind spots", het automatiseren van detecties, het stroomlijnen van onderzoeken en oplossing en tevens het voorkomen van ransomware en malware. 7.0 - 7.17 (huidig).

Volgende slide toont Thwart threats op enterprise schaal. De zichtbaarheid laten toenemen, analyse-workflows optimaliseren, beveiligen van cloudworkloads en cloud security policies en het stoppen van geavanceerde aanvallen op het endpoint. 8.0 - 8.5

Toekomst van Elastic Security is Native Response Actions, Threat Inteligence Management, CWP en CSPM en Entity Analytics.

Volgende blok is Elastic Enterprise Search. We zien App Search en Workspace Search, daarboven Embedded Search, Customer Support en Marketplace Search.

Hiermee moet het makkelijk worden om in real-time overal alles te kunnen zoeken. Pre-built tooling, zoektijd verminderen, zoekresultaten optimaliseren. 7.0 - 7.17

Om betere resultaten te leveren gaan we naar Vector Search. Snellere en relevantere zoekresultaten. Uitbreiden van zoeken naar afbeeldingen, audio en meer. Op basis van semantische betekening de ranking van je resultaat bepalen. Query ongestructureerd in en natuurlijke taal. 8.0 - 8.5

Toekomst van Elastic Enterprise Search. We zien Become the best unified platform for developing search apps in the cloud, Enable sophisticated use-cases based on emerging technologies at production scale, Capture behavioral analytical data that drive modern search applications.

Dan het blok Elastic Stack. Het uitbouwen van het beste data analytics platform, kosten besparen op data-opslag, versnellen van "time to value" en het stroomlijnen van data analyse. 7.0 - 7.17

Ik mis hier volgens mij de 8.0-8.5 versie in dit verhaal, bij de toekomst staat Time-series database, Elasticsearch Language (ESQL) en Stateless Architecture.

Er komt dus een eigen SQL-taal voor het zoeken met Elastic.

We zien nog even waar je in de cloud je Elastic kunt laten draaien: overal dus. Via AWS, GCP en de Azure marketplace.

Search. Solve. Succeed.

Stefan de Moerloose

Na dit toekomstbeeld komt de volgende spreker, Stefan de Moerloose van Swift. Swift is een grote partij die voor het betalingsverkeer verantwoordelijk is. Stefan laat ons de grote getallen zien, 4 biljoen accounts, 44.8 miljoen dagelijkse financiële transacties, levert ondersteuning aan 235 partijen, SLA (beschikbaarheid) zit op 99.999%.

Voor rapportages, monitoring en andere zaken werden allemaal losse zaken gebouwd door de afbeeldingen, maar die konden dan weer niet door andere afdelingen gebruikt worden. Het beeld van Stefan is redelijk somber, alles werkt als silo's en niet als 1 team, de bouwers droppen het bij de mensen die de boel deployen en vervolgens: succes service!

Er moet dus een centrale applicatie komen om te zorgen dat er een standaard komt. Keuze is gevallen op het Instrumentation Framework. We zien ook hoe er voorbereid wordt op de toekomst. Want onder het Swift Platform hangen losse zaken als Validation, Trackers, Fraud Control, Sanctions Screening, Partner Modules.

In dit verhaal heb ik niet zoveel "Elastic" voorbij horen komen, hier had misschien nog wat meer over verteld kunnen worden.

David Ponessa en Gabriel Vignolo

David Ponessa en Gabriel Vignolo komen op het podium. Ze zijn van booking.com. In de begintijd hadden ze zelf hun eigen servers in beheer. En dat waren er 1.900! Naast het feit dat dit een heel groot aantal is en je daarvan kunt schrikken was het ook nog zo dat "maar" 2 man het onderhoud hiervoor uitvoerden. En ook waren ze willekeurig ingericht/opgezet, dus nog eens extra arbeidsintensief. Het bedrijf wat iedereen een mooie vakantie wil laten kopen, kan eigenlijk de eigen medewerkers niet met vakantie laten gaan omdat ze eigenlijk niet gemist kunnen worden bij het onderhoud. Toen kwam corona ook nog om de hoek en stortte alle verkopen in, er moest wat gebeuren.

Daarom is alles naar de cloud verhuisd (in 3 maand tijd). Nu de zaken in de cloud draaien gelden de volgende cijfers:

  • 400 nodes met 18 deployments
  • meer dan 150 users, verdeeld over meer dan 12 teams
  • 1 Pb aan data opgeslagen, elke dag komt er 100 Tb bij op basis van meer dan 100 datastromen
  • en aan onderhoud is nu een halve dag per week voldoende


Wat heeft het nog meer opgeleverd?

  • De backlog "dit moet nog eens gebeuren" is met 89% teruggebracht.
  • Een lagere MTTR door de recente data die je beschikbaar hebt (MTTR = mean time to remediate).
  • Minder "false negatives" door "silent source detection"
  • En security die om kan gaan met hoge volumes aan verbruik/data.


Security was niet de eerste insteek om Elastic te gebruiken, dat kwam door cross cluster search, dus zowel "on premise" als in Google Cloud kunnen zoeken.

Omdat de presentaties iets langer geduurd hebben een korte chat en daarna tijd voor een koffie-break.
We lopen allemaal weer terug naar de grote zaal waar je wat kunt drinken, er liggen koekjes, het is allemaal prima geregeld.  Ook nu loop ik weer wat eerder terug naar de zaal en heb weer een plaats aan het gangpad, mooi vooraan. Tijd voor de volgende spreker!

Jim Stolze

Spreker is Jim Stolze. Nou ja, eigenlijk de show-master, want we loggen allemaal in op Kahoot en beantwoorden daar vragen. Vragen over Elastic, de founders, kunstmatige intelligentie, welke besturingssysteem het minst last heeft van virussen (nog steeds de mac). Er zijn wat bezoekers van het bedrijf Humanz en die gebruiken die naam in hun nickname. Elke promotie is meegenomen natuurlijk :) Winnaar is Jonas, hij mag een NFT op zijn naam schrijven. Na wat vragen wordt iets ingevoerd met een hond, darth vader en nog wat zaken en zo levert Midjourney (gaat via Discord) ons een Golden Retriever met een soort Darth Vader hoofd, de nieuwe NFT.

Midjourney kwam ook bij één van de vragen naar voren, deze kan dus met AI kunstwerken opleveren. Maar is het dan "echt" kunst, of niet? Lees hier meer: link, daar kun je ook het werk zien. Ik vind het er prachtig uit zien!

 

Hierna is het tijd voor de lunch. Dan komen er veel mensen weer in de zaal, maar het personeel krijgt het voor elkaar. Licht verteerbare hapjes, ook hier weer prima geregeld.

Steve Dodson

Na de lunch spreekt Steve Dodson van Elastic over Vector Search.
Hij benoemt nog even de punten die ook vanmorgen vroeg al voorbij gekomen waren:

  • Semantisch: "snap" de bedoeling van de vraag, niet alleen de losse woorden
  • Input flexibiliteit: ook kunnen zoeken met een afbeelding of met geluid als query
  • Context en domain specifiek
  • Precieze en hoge signalen


Vector Search gaat verder dan het matchen van tekst. We zien het voorbeeld van de vraag "How fast should my internet be?"
Semantische Search bouw je met behulp van ElasticSearch ml (machine learning).

Steve laat nog de verschillen zien bij het "normaal" zoeken op tekst, waarbij gezocht wordt op "how to setup elasticsearch ml", Elastic zelf geeft je daar artikelen in de lijst waar je niet echt veel mee kunt.
De Google zoekactie geeft wel een goede lijst en het eerste resultaat is ook wel waar je op door wilt klikken: dat is 'm!

Ook zien we de zoekresultaten van een online kledingshop. Er is gezocht op "blue t-shirt with stripes". Er is een jurkje foutief "T-shirt blue" genoemd.

Vector Similarity 101.
Vector Similarity is het converteren van data in een vector representatie waar afstanden gelijkheid representeren.
We zien een voorbeeld van een 1-dimensionale vector.
Het zijn 2 elanden, het ene is "realistisch", de andere een "cartoon".
We zien vervolgens een 2-dimensionale vector waar naast die scheiding ook nog een scheiding tussen "mammal (zoogdier)" en "bird (vogel)" aangebracht is.

Queries (dus de zoekacties) worden ook omgezet naar vectoren. Zo kan de "nearest neighbour" gevonden worden.

Hierna volgt een uitleg van hoe je dat met Elastic kunt doen.

  • Je hebt een Use Case nodig (waar ga ik het voor gebruiken).
  • Vervolgens een Elastic Cloud account.
  • Daarna een Machine learning ("embedding") model
  • En als laatste een search-powered applicatie.


Het opzetten van het learning model, in het schema zien we het gebruik van PyTorch en Eland.
Er wordt nog verwezen naar dit: BERT-MiniLM-L6. Ook wordt huggingfaces nog genoemd: link.
Er wordt nog wel gezegd dat hybride scores je vaak het beste resultaat geven, dus zoeken op tekst en de vector score, die combi levert vaak het beste resultaat.

We krijgen nog een overzicht van klantprojecten die vector search gebruiken:
* zoeken op vergelijkbare producten: "verkoop je zwarte v-nek t-shirts die hier op lijken" en daar een afbeelding bij koppelen.
* beantwoorden technische vragen: "wat zijn de stappen om probleem X op te lossen"
* medische kennis uitvragen: "wordt lithium gebruikt om migraine te bestrijden"
* reageren op klant-ervaringen: als een klant niet goed behandeld wordt (niet goede antwoorden op vragen, langdurige correspondentie), identificeer die interacties voordat ze escaleren

De laatste slide roept op om te starten: Elastic Cloud, Enterprise Search kun je op Elastic Cloud voor 14 dagen gratis uitproberen.
Filmpje Quick Start: Get started with free training to help you succeed.
En wat je zo kunt nalezen: from the blog: how to deploy NLP: Text Embeddings en Vector Search en Elastic Docs: lees de uitgebreide handleidingen voor vector search en machine learning (en how-to materiaal).

Marvin Ngoma

De volgende sessie is van Marvin Ngoma van Elastic. Hij gaat het over snelheid hebben en hoe we die met Elastic kunnen boosten.
Het eerste deel gaat vooral over security.
Elastic heeft 700 ingebouwde MITRE-mapped preventions, detection en response rules, ondersteund door 60+ machine learning modelen en threat research.

Ik meende dat die ook in Github staan en je die dan ook zelf zou kunnen gebruiken in je eigen oplossingen.

Er wordt flink geinvesteerd in cloud security, security orchestration automation en response (SOAR) en threat intelligence (TI).

In de volgende slide zien we wat de trends zijn en wat de uitdagingen zijn.
Zo heb je dat iedereen naar cloud gaat: toename aan foutieve configuratie, kwetsbaarheden en bedreigingen
Doordat zaken zo groot worden een "visibility gap": welke eigendommen heb ik, hoe moet ik weten wat ik moet beschermen?
De traditionele endpoint security wordt uitgebreid naar cloud security: combineer al die platformen zodat je "ergens" centraal alarmeringen, triage (beoordelen of zaken wel of niet mogen) en respons-acties uitgevoerd kunnen worden.

We zien de mean time to respond (MTTR), was dit: alert komt binnen, analist bepaalt of het een terechte melding is: case aanmaken en escalatie, team ontwikkelt een fix en rolt dit uit. Dit kon uren/dagen duren.
Na automatisering kun je zorgen dat het eerste deel binnen minuten uitgevoerd kan worden (zet bijvoorbeeld bepaalde zaken alvast dicht ter bescherming).

Elastic Search automatiseert uitvoerbare threat intelligence. We zien een aantal onderdelen:
1: Influence and Inform
2: Investigate and Understand
3: Aggregate, analyze and synthesize
4: Share and Consume
5: Identity and Analyze

De laatste slide verwijst naar de "SIEM Buyer's Guide" op elastic.co/security

Oren Loulay, Pedro Esteves en Delphin Barankanira

Vervolgens komen 3 mannen van Google op het podium. Google heeft een partnership met Elastic, ik vond het een promo-praatje. Maar goed.
De Develops Cheat Sheet die ik ook gedeeld heb, die kun je vinden op https://googlecloudcheatsheet.withgoogle.com/, op Github staat de PNG versie hiervan: link en directe link.

Door op Google Cloud Marketplace te zoeken naar "elastic" heb je het product al gauw gevonden.

We zien een overzicht met de Open Source producten (Hadoop, Apache Base, Cockroach, Tensorflow, Beam) en de Google producten: BigQuery, Pub/Sub, DataFlow, Bigtable, Spanner, Vertex AI.

Hierna nog een use case, een klant die een luxe en beauty merk beheert. Ze willen hun producten online aanbieden, maar hebben geen idee wat andere partijen doen. Dus een simpele crawler die "even andere sites" checkt, dat wordt 'm niet.
Implementatie is gedaan met verschillende crawl-acties die zaken in Kubernetes toevoegt, daar zit het uitfilteren van attributen, worden zaken gematcht.

Tweede use case is een telecomprovider die in real-time wil zien welke films/video's door klanten bekeken worden en deze adviezen geven "bekijk ook deze serie". Huidige situatie is dat pas na een aantal dagen dat advies gegeven kan worden.
Hier is een implementatie met Kafka gedaan, zaken in Kibana, Elasticsearch. En ook zien we hier Jenkins terug voor releases, Bitbucket voor  versiebeheer.

 

Hierna hebben we weer een half uurtje pauze in de Grote Zaal. Fijn, want je begint toch bijna een houten kont te krijgen van het zitten. Een flesje cola, nog even een rondje maken en vervolgens terug naar de zaal voor de laatste sessies.

David Brimley and Henning Anderson

David Brimley en Henning Anderson van Elastic bespreken hoe er gewerkt wordt om Elasticsearch "Serveless" te maken. Zoals veel producten gebouwd worden "als cloud applicaties", zo moet Elasticsearch dat ook gaan doen. De heren zijn fan van David Bowie, want hij wordt gebruikt om de verschillende onderdelen te splitsen.

Elasticsearch heeft verschillende scenario's aan data:

  • Gigabytes, productcatalogus, inventaris van een hotel.
  • Terabytes, click-streams.
  • Petabytes, logs, metrieken, "observability".
  • Exabytes, MRI scans, security events.


Wat hebben we nodig?

  • Een modern platform met bijna real-time inzicht.
  • Voor elke grootte (dus van Gigabytes tot Exabytes).
  • Simpel in gebruik, geen administratie/configuratie.
  • Niet te duur: alleen betalen wat je gebruikt.


Om boel te schalen wordt er gebruik gemaakt van "Sharding". Indexen worden verdeeld, daar worden replica's van gemaakt. Elke shard wordt ondersteund door een Lucene index.

Uitdagingen hierbij zijn:

  • (Compute + Storage) * #indexen * #shards = kostenplaatje
  • Oude data kost hetzelfde als nieuwe data.
  • Oude data heeft dezelfde performance als nieuwe data.
  • Infrastructuur wordt ingericht op piekbelasting.


Andere aanpak is Data Tiering met ILM policies.

  • Je hebt een Hot, Cold en Frozen omgeving (tier), de object store bevat snapshots.
  • Alle data is beschikbaar.
  • Je kunt "tiers" automatisch instellen (na 7 dagen naar Cold, na 30 dagen naar Frozen).
  • Elke tier heeft een eigen profiel qua kosten en performance.


Voordelen:

  • snapshots kunnen doorzocht worden
  • data opgeslagen door oude versies van Elasticsearchkan nog steeds doorzocht worden


Ook daar zijn nog wel nadelen aan te wijzen, complex om kosten en performance te begrijpen, veel verplaatsen van data tussen de tiers en daar zit dan ook weer een vertraging tussen.


Het volgende scherm toont "stateless". Hierbij zijn de indexen gesplitst naar een Index Processor en een Search Processor (dat is dus losgekoppeld), die dan ook hun eigen cache hebben.

Dit is dus het pad waar Elastic naar onderweg is. Zaken zijn volledig beheerbaar, compute en storage zijn elastisch, geen problemen met versies, autoschalen (ook naar 0), autohealing.


Israel Ogbole

Israel Ogbole van Elastic spreekt over profiling. Universal Profiling is nog in de beta-fase.
We zien het schema waarbij Israel spreekt over de dood van de wet van Moore: nieuwe hardware betaalt zich eigenlijk niet meer uit (die server van vorig jaar is ook prima), inefficiente code zorgt dat je extra kosten maakt en code die niet liniair schaalt zorgt dat ook de kosten op die wijze stijgen.

Je moet je code dus eigenlijk continu "profilen". Wat doet je code, wat zijn de geheugen-/disk-intensieve processen en hoe kunnen we dat verbeteren?

Universal Profiling draait zowel op x86 als op 64-bit systemen. En ook op ARM. De overhead is extreem laag: ongeveer 250 MB aan RAM, 1% van de CPU.

Met eBPF kun je dit toevoegen zonder code te wijzigen, geen app restart nodig.
C/C++, Rust en Go, PHP, Python, Java, Ruby, Perl en NodeJS zijn inzichtelijk.
En per regel kun je de kosten inzichtelijk krijgen. Hoewel ik CO2 belasting een beetje belachelijk vind, je code beter maken is natuurlijk altijd +1.

We zien een voorbeeld van een stukje Python-script, waarbij het opvragen van een globale omgevingsvariabele binnen een loop zit. Elke keer dat opvragen, dat is intensief. Door dit buiten de loop te zetten is het een stuk beter. Je kunt het zowel weergeven binnen een tabel (met omschrijving, percentage belasting), maar ook als een soort diagram.

De afsluiter is: als je 20% bespaart op 800 servers en die gebruiken 300 watt per stuk, dan is die ene code-aanpassing de oorzaak dat er 160 ton aan CO2 bepaard wordt. Ja, zo kun je het ook bekijken.