class: center, middle, inverse  --- class: center, middle, inverse # Datawarehousing for Cloud # Computing Metrics --- ## Inhalt * Einleitung * Vorstellung - Aktuelle Situation * Management-Methoden * Vorbereitung * Realisierung * Risiken und unerwartete Probleme * Abschluss --- .left-column[ ## Einleitung ] .right-column[  .footnote[© Hetzner Online GmbH] ] --- .left-column[ ## Einleitung ] .right-column[  .footnote[© Google Inc.] ] --- .left-column[ ## Vorstellung ] .right-column[  .footnote[© Puppet Inc.] ] ??? * Marktführer im Bereich Konfigurationsmanagment Lösung * Kernprodukt ist gleichnahmiges Produkt Puppet * Projekt Betreuer Agile Entwicklung und Testverfahren --- .left-column[ ## Marktlage ] .right-column[  * Telemetry ist ein Teilprojekt von OpenStack * Datenbank MongoDB getestet durch Kyle Kingsbury * Hohe Hardwareanforderung * Benötigt OpenStack Cloud Umgebung .footnote[© Julien Danjou] ] --- .left-column[ ## Management ### Scrum ] .right-column[ * Arbeit in Sprints * Review & Retrospective * Beliebt unter Entwicklern * Sehr starr * Nicht geeignet für asynchrones Arbeiten ] ??? * Scrum am weitesten verbreitet in der Wirtschaft * Anforderungen an Projektmanagementlösungen * Unvorhersehbar * Schnell wechselnde anforderungen * Standups * Darf man nur Scrum nennen wenn man alles genau so macht --- .left-column[ ## Management ### Scrum ### Agil ] .right-column[ * Flexible Kombination aus Scrum und Kanban * Nutzung von einzelnen Elementen * Sprints * R&R * Decommissioning ] ??? * Pool aus Methoden die in Scrum und Kanban genutzt werden * Man nutzt was am besten passt, lässt rest weg * Puppet --- .left-column[ ## Management ### Scrum ### Agil ### Werkzeuge ] .right-column[ * Code Management * Git * GitHub * Continuous Integration: Travis * Continuous Delivery: Jenkins * Projekt Management * Jira * Confluence * Telegram * Tests * Acceptance Tests: Beaker * Unit Tests: RSpec * Integration Tests: Spring ] ??? * SVN bei gruppe im vorjahr * Puppet hat erfahrung mit allem --- .left-column[ ## Vorbereitung ] .right-column[ * Absprache mit Auftraggeber bezüglich des Lösungsbildes * Auswahl von Software zur Realisierung * Aneignen von Git und Methoden * Frühzeitig Meilenstein definieren * Ersten Prototyp abliefern ] ??? * Lösungansätze * Anforderungen an Teilbereichen stellen --- .left-column[ ## Realisierung ] .right-column[  ] ??? * collectd auf hypervisors sammelt metriken * werden an beliebig viele logstash instanzen geschickt * cached eingehende daten, aufbereitung * Postgresql tabelle mit json als bus * Daten von dort per ETL prozess in finale tabellen * API RESTFul schema angelehnt, CRUD support * Alles mit Puppet --- .left-column[ ## Realisierung ### Datenerfassung ] .right-column[  ] ??? * Input Plugin * Pro format ein plugin * Collectd kann ausgetauscht werden * Filter plugin * Serialisierung * XML -> JSON * Einheitliches Datumsformat * Outputplugin * Jedes Backend ansprechbar --- .left-column[ ## Realisierung ### Datenerfassung ### ETL ] .right-column[  ] --- .left-column[ ## Realisierung ### Datenerfassung ### ETL ### Partitioning ] .right-column[  ] --- .left-column[ ## Realisierung ### Datenerfassung ### ETL ### Partitioning ### API ] .right-column[ * Bereistellung von Funktionen * Datenverarbeitung muss nicht in SQL erfolgen * Vorgabe der Daten durch die API * Keine Notwendigkeit für direkte SQL Queries * Zusätzliche Abstraktionsschicht * Zusätzlicher Cache * Datenbankaustausch ist transparent für Grafana * Kleinere Angriffsfläche auf das Interface * HTTP API vs SQL * Einfacher zu testen  ] --- .left-column[ ## Realisierung ### Datenerfassung ### ETL ### Partitioning ### API ### Visualisierung ] .right-column[   ] ??? * Graph besteht aus 2 Vektoren (Knoten und Kante) * Daten werden aus der API erhalten * Threshold / Schwellenwert --- .left-column[ ## Realisierung ### Datenerfassung ### ETL ### Partitioning ### API ### Visualisierung ### Userstorys ] .right-column[ * SSD Userstory * CPU Userstory * Memory Userstory * Zeitdefinierte Analyse Userstory * Webinterface Userstory ] --- .left-column[ ## Realisierung ### Datenerfassung ### ETL ### Partitioning ### API ### Visualisierung ### Userstorys ### Wireframe ] .right-column[  ] --- .left-column[ ## Risiken ] .right-column[ * Risk Register definieren * Präventivmaßnahmen * Post Mortem Maßnahmen ] --- .left-column[ ## Risiken ] .right-column[  ] ??? * Kaputte Spühlmaschine unvorhersehbar * undicht, Auf raviolidosen damit das wasser auslaufen kann * 1 tag arbeit * mehrere tage psychische belastung --- .left-column[ ## Ausblick ] .right-column[ * Alerting * Benachrichtigung bei Schwellenwertüberschreitung * Quality of Service * Bevorzugen bestimmter Datentypen zur Live-Visualisierung * Cache Invalidation * Sicherstellung der kontinuierlichen Datenverarbeitung * Trendgenerierung * Extrapolation vorhandener Daten ] ??? * Cache Invalidation * Schwellenwert beim Cache sobald dieser zu groß wird. * Trendgenerierung * Hochrechnung --- class: middle, center, inverse ## Fazit ### Solide und modulare Architektur ### Flexibler und einfacher als Telemetry ### Persönliche Fortbildung .footnote[© Marcel Reuter, Nikolai Luis, Tim Meusel] ??? * Viele Monate Arbeit, Gute Alternative zu Telemtry aus dem OpenStack Projekt * Realisierung von allen Userstorys, passender Replacemant Algorithmus der API mehr Funktionen als Telemetry * Ist Flexibel, da es auf Linux Hypervisor intgriert werden können * Praktischer Wissenschatz, neue Wissensinhalte u. Arbeitsmethoden * Belastbarkeit jedes einzelnen wurde erforscht.