Bouw aangepaste observatieoplossingen

Cisco Observeerbaarheidsplatform (COP) stelt ontwikkelaars in staat aangepaste observatieoplossingen te bouwen om waardevolle inzichten te verkrijgen in hun technologie- en bedrijfsstack. Terwijl het opslaan en opvragen van metrische, gebeurtenis-, log- en traceergegevens (MELT) een belangrijke platformmogelijkheid is, biedt de Data Retailer (KS) oplossingen de mogelijkheid om domeinspecifieke bedrijfsgegevens te definiëren en te beheren. Dit is een belangrijke issue die gedifferentieerde oplossingen mogelijk maakt. Een oplossing kan bijvoorbeeld gebruik maken van gezondheidsregels en FMM-entiteitsmodellering om netwerkinbraken te detecteren. Met behulp van de Data Retailer zou de oplossing een idea als ‘Onderzoek’ naar het platform kunnen brengen, waardoor gebruikers de volledige levenscyclus van een onderzoek naar netwerkinbraak kunnen creëren en beheren, van creatie tot herstel.

In deze blogpost leren we de basisprincipes van het toevoegen van een kennismodel aan een Cisco Observability Platform (COP)-oplossing, aan de hand van het voorbeeld van een netwerkbeveiligingsonderzoek. In deze blogpost zal veelvuldig gebruik worden gemaakt van de FSOC-opdracht praktijkvoorbeelden te geven. Als u niet bekend bent met FSOC, kunt u het bekijken Leesmij.

Laten we eerst snel de COP-architectuur om te begrijpen waar de Data Retailer in previous. De Data Retailer is het gedistribueerde ‘brein’ van het platform. Het kennisarchief is een geavanceerd JSON-documentarchief dat door de oplossing gedefinieerde typen en kruisobjectreferenties ondersteunt. In het onderstaande diagram wordt de Data Retailer door pijlen ‘verbonden’ weergegeven met andere componenten van het platform. Dit komt omdat alle componenten van het platform hun configuraties opslaan in de kennisopslag. De Data Retailer heeft geen ‘ingebouwde’ typen voor deze componenten. In plaats daarvan gebruikt elke part van het platform een ​​systeemoplossing om kennistypen te definiëren die hun eigen configuraties definiëren. In die zin zijn zelfs interne componenten van het platform oplossingen die afhankelijk zijn van de Data Retailer. Om deze reden is de Data Retailer het meest essentiële onderdeel van het platform waar absoluut niets anders zonder kan.

Om een ​​gedetailleerder begrip van de Data Retailer toe te voegen, kunnen we deze begrijpen als een database met lagen. De SOLUTION-laag wordt globaal gerepliceerd in alle cellen. Dit maakt de SOLUTION-laag geschikt voor relatief kleine stukjes informatie die wereldwijd gedeeld moeten worden. Alle objecten die in een oplossingspakket worden geplaatst, moeten in alle cellen beschikbaar worden gemaakt voor abonnees. Daarom worden ze in de gerepliceerde SOLUTION-laag geplaatst.

Ontvang een stapsgewijze handleiding

Vanaf dit punt zullen we overschakelen naar een hands-on modus en je uitnodigen voor ‘git clone git@github.com:geoffhendrey/cop-examples.git’. Kijk eens naar na het klonen van de repository https://github.com/geoffhendrey/cop-examples/blob/principal/instance/knowledge-store-investigation/README.md die een gedetailleerde stapsgewijze handleiding biedt voor het definiëren van een netwerkinbraaktype in de JSON-opslag en hoe u deze kunt vullen met een reeks standaardwaarden voor een onderzoek. Hieronder ziet u een voorbeeld van een malwareonderzoek dat kan worden opgeslagen in de kennisopslag.

Het cruciale ding om te begrijpen is dat voorafgaand aan de creatie van het ‘onderzoek’ kind, dat wordt onderwezen in de git repo hierboven, het platform geen idea van een onderzoek had. Daarom is kennismodellering een fundamentele mogelijkheid, waardoor oplossingen het platform kunnen uitbreiden. Zoals u kunt zien in het onderstaande voorbeeldonderzoek, kan een oplossing de mogelijkheid bieden om een ​​malware-incident te rapporteren, onderzoeken, herstellen en sluiten.

Als je de git repository hebt gekloond en de README hebt gevolgd, dan ken je de belangrijkste punten uit het ‘onderzoeks’-voorbeeld al:

1. Het kennisarchief is een JSON-documentarchief
2. Een oplossingspakket kan een Kind definiëren, wat lijkt op het toevoegen van een tabel aan een database
3. Een Kind moet een JSON-schema opgeven voor de toegestane inhoud
4. Een Kind moet ook specificeren welke documentvelden op unieke wijze documenten/objecten in de winkel identificeren
5. Een oplossing kan objecten bevatten die van een kind kunnen zijn dat in de oplossing is gedefinieerd, of die door een andere oplossing zijn gedefinieerd
6. Objecten die deel uitmaken van een oplossing worden globaal gerepliceerd in alle cellen in het Cisco Observability Platform.
7. Een oplossing inclusief Varieties en Objecten kan worden gepubliceerd met het fsoc-opdrachtregelhulpprogramma

Bied waarde en context bovenop MELT-gegevens

Met Cisco Observability Platform kunnen oplossingsontwikkelaars krachtige, domeinspecifieke kennismodellen naar het platform brengen. Met kennismodellen kunnen oplossingen waarde en context bieden bovenop MELT-gegevens. Deze mogelijkheid is uniek voor COP. Kijk uit naar toekomstige blogs waarin we zullen onderzoeken hoe we toegang kunnen krijgen tot objecten tijdens runtime, met behulp van fsoc en de onderliggende REST API’s. We zullen ook geavanceerde onderwerpen verkennen, zoals het genereren van kennisobjecten op foundation van workflows die kunnen worden geactiveerd door platformgezondheidsregels, of triggers binnen de data-opnamepijplijn.

Vind gerelateerde bronnen

Leer meer over Cisco Full-Stack-observatie en verken bronnen voor ontwikkelaars voor:

• Infrastructuurmonitoring
• Applicatiebewaking
• Applicatiebeveiliging
• Monitoring van digitale ervaringen

Deel: