SaltAndTilt
-
Gesamte Inhalte
7 -
Benutzer seit
-
Letzter Besuch
Inhaltstyp
Profile
Forum
Downloads
Kalender
Blogs
Shop
Beiträge von SaltAndTilt
-
-
Hallo zusammen,
nach Rücksprache mit meinem Fachbetreuer haben wir uns auf folgendes Thema geeinigt und mein ursprüngliches Thema verworfen.
Vielen Dank schonmal im Voraus für alle Tipps und Korrekturvorschläge:
Projektantrag
1.Projektbezeichnung
1.1.Kurzform der Aufgabenstellung
Evaluierung und Konfiguration einer Lösung für ein Verfahrensmonitoring
1.2.Projektziele
Aufbau eines Monitoringservices für die Fachverfahren vom dem Fachbereich [XXX], Entscheidung für eine Monitoringlösung, Darstellung der Zusammenhänge der entsprechenden Dienste und Geräte für den Service
1.3.Projektauftrag
Evaluierung der Anforderungen des Kunden an das Monitoring, mit anschließendem Aufbau und Konfiguration
2.Projektbeschreibung
2.1.Ausgangssituation
Der Fachbereich [XXX] stellt für eine [XXX] verschiedene Fachverfahren bereit. Hierfür betreibt der Bereich mehrere Server mit entsprechenden Softwarelösungen.
Aktuell werden diese Server nicht gesondert gemonitored, weshalb auf etwaige Störungen nicht schnell genug reagiert werden kann und SLAs nicht eingehalten werden können
2.2.Projektziel
Ziel des Projektes ist es, die Fachverfahren vom Fachbereich [XXX]als funktionales Konstrukt zu monitoren und darzustellen.
Der Fachbereich erhält die Möglichkeit, seine Verfahren zu monitoren und darzustellen und ist dadurch in der Lage, etwaige Störungen beim Kunden gezielt zu beheben und damit ihre SLAs einzuhalten.
Hierzu muss eine Auswahl bezüglich des Monitoring-Tools getroffen werden, sowie eine Darstellung von verschiedenen Verfahren in dem gewählten Tool.
Zudem soll ein Dasboard erstellt werden, welches dem Fachbereich eine Übersicht über die jeweiligen Services und deren Status gibt.
2.3.Einschränkungen
2.4. Rahmenbedingungen
Das [XXX] ist [XXX]Dienstleister [XXX] und stellt für die [XXX] verschiedene Dienstleistungen und Services bereit.
Meine Projektarbeit findet im Fachbereich Monitoring statt. Der Bereich stellt für andere Bereiche verschiedene Monitoringlösungen bereit und unterstützt beim Betrieb dieser Lösungen.
Der Kunde ist der Fachbereich [XXX] der verschiedene Verfahren für die [XXX] bereitstellt.
3.Projektphasen mit Zeitplan inkl Teilaufgaben
1.Planung(12h)
1.1. Absprache mit [XXX] zu Zielvorstellung und Aufbau der Services 2h
1.2. Ist-Analyse 1h
1.3. Erstellung des Soll-Zustandes 2h
1.4. Vergleich möglicher Monitoringlösungen 2h
1.5. Kosten/Nutzenanalyse 2h
1.6. Planung der gewählten Monitoringlösung 3h
2.Projektdurchführung(15h)
2.1. Einrichtung und Konfiguration der Monitoring-Software 6h
2.2. Einbindung der zu monitorenden Systeme 3h
2.3. Darstellung des Verfahrens im System 4h
2.4. Verfahren als Dashboard für [XXX] 2h
3.Projektabnahme(3h)
3.1. Funktionstest, Fehlerüberprüfung und Behebung 2h
3.2. Abnahme durch [XXX] 1h
4.Dokumentation(5h)
-
vor 17 Stunden schrieb pr0gg3r:
Ich glaube, du bist da etwas zu optimistisch. Kubernetes ist nicht in zwei Stunden installiert (wenn wir von einem richtigen Kubernetes und keinem Minikube ausgehen). Wie viele Nodes hast du denn geplant?
Ich kenne check_mk nicht, aber wenns um Monitoring und Kubernetes geht, hört man öfter Log DNA, Elk Stack, Prmetheus, etc.
Die ursprüngliche Planung war mit ~3 Pi's (1 Master, 2 Nodes), ich habe auch gerade nochmal die inoffizielle Bestätigung, dass ordentliche Hardware nicht möglich sein wird. Wenn so Rasberry Lösungen Punktabzug bedeuten, würde ich mir ein anderes Thema suchen.
vor 19 Stunden schrieb Listener:Custom-Metriken lese ich da jetzt nicht raus. Das alleine wäre in jedem Cluster, den ich bisher aufgesetzt habe, ein KO-Kriterium, da alleine Velero-Metriken überwacht werden müsssen. etcd, kubedns/coredns auch. Ist für mich keine gute Lösung, so ganz kurz und knapp
Ich meine, ich kann im Ergebnis doch darauf kommen, dass unsere aktuelle Software für das Monitoring von Kubernetes nicht ausreicht und quasi einen Rat für die Zukunft abgeben oder? -
CheckMK über Kubernetes, kann jetzt natürlich nicht einschätzen inwieweit das nur Marketingblabla ist, aber angeblich können sie Containermonitoring.
Aber dann quasi den Fokus auf die mögliche Umsetzung des Monitorings der Kubernetes und den Cluster "Zusammenbau" eher nebenbei, alles klar.
Auf jedenfall schonmal vielen Dank für die Hilfe. -
Der Ausbildungsbetrieb ist Teil des öD, faktisch wird das hier im Haus also auf CheckMK hinauslaufen, aber wenn es sinnvoll/gut ist, würde ich natürlich den Fokus auf den Vergleich CheckMK/Prometheus legen.
Das Pi's nicht best practice sind, ist mir schon klar.
Wenn es nicht das Pi Cluster wird, wäre der Arbeitsschritt leider nur durch ein "Linuxserver bei einem anderen Fachbereich beantragen" zu ersetzen, wird dass dann nicht schon problematisch mit der fachlichen Tiefe? Zumal das dann u.U. daran auch scheitern könnte, da die Wartezeit gegebenfalls einige Monate sein kann. Oder wäre das ein Punkt den die IHK bereits ankreidet?
-
vor einer Stunde schrieb Listener:
Mal eine fachliche Frage: Sollen nur folgende Monitoring-Lösungen zum Monitoren eines Kubernetes-Clusters evaluiert werden?
Wäre tatsächlich eine Frage des Zeitaufwandes. Faktisch sind das die einzigen Produkte die wir einsetzen (können), aber ich ziehe in Betracht, bei der Evaluation den Vergleich zwischen CheckMK, Prometeus und Grafana zu ziehen, je nachdem wie es sich dann letztendlich zeitlich gestaltet.
Bei der Hardwareauswahl dachte ich an den Vergleich Raspberry Pi vs Standardinfrastruktur im Haus, um dann bei den Kosten wahrscheinlich auf den Pi Cluster zu kommen. -
Hallo zusammen, ich habe von meinem Fachbetreuer dieses Projektthema vorgeschlagen bekommen.
Ich habe auf der Basis erstmal einen ersten Entwurf eines Projektantrags gefertigt, bin mir aber sehr unsicher ob das Thema als FiSi-Thema taugt/ausreicht.
Durch meinen Fachbereich bin ich leider etwas eingeschränkt in der möglichen Auswahl an Projekten.
Bin daher schonmal für jedes Feedback spannend inkl. Verbesserungsvorschlägen.
______________________________________________
1.Projektthema
Planung und Aufbau einer Kubernetes-Testumgebung für den Fachbereich Monitoring
1.1.Ausgangssituation
Mehrere Fachbereiche wünschen sich, einige ihrer Systeme und Dienste in einer Kubernetes-Umgebung umzusetzen. Aktuell erfolgen sämtliche Dienste entweder in Citrix oder VMware.
Aktuell hat das Monitoring dementsprechend auch nur der Überwachung dieser Systeme zu tun, da nur Systeme im Livebetrieb gemonitored werden.
1.2.Zielsetzung
Ziel des Projektes ist es, dem Fachbereich Monitoring ein Kubernetes-Cluster zur Verfügung zu stellen, damit dieser die vorhandene Monitoringsoftware auf das Überwachen von Diensten in einer Kubernetes-Umgebung umzustellen und etwaige benötigte Änderungen durchzuführen.
Zudem muss überprüft werden, welche der vorhandenen Monitoringlösungen sich zur Überwachung von Kubernetes am besten eignet.
So soll sichergestellt werden, das bei der Einführung in anderen Bereichen das Monitoring garantiert funktioniert, so dass etwaige Ausfälle oder Störungen nicht unbemerkt bleiben.
1.3.Konsequenzen bei Nichtverwirklichung
Bei einer Nichtverwirklichung des Projektes kann der Fachbereich Monitoring sich erst mit Kubernetes-Monitoring auseinandersetzen, wenn dieses im Livebetrieb genutzt wird, was je nach Komplexität zu längeren Zeitfenstern führen kann, in denen die betroffenen Dienste nicht gemonitored werden können, was es den für die Dienste zuständigen Fachbereichen erschwert, etwaige Störungen schnell zu erkennen und zu beheben.
2.Projektumfeld
Das XXX ist ein Großunternehmen und der IT-Dienstleister des XXX und ist damit verantwortlich für den Betrieb der kompletten IT des XXX, u.a. Dienste, Server, Datenbanken etc.
Meine Projektarbeit findet im XXX in der Abteilung Monitoring statt.
Die Abteilung Monitoring stellt die Monitoring Infrastruktur (CheckMK, SCOM, ZIS) und erstellt individuelle Monitore, beteiligt sich bei komplexeren Problemen an der Lösung und stellt den anderen Fachbereichen individuelle Monitoringansichten zur Verfügung.
3.Phasen mit Zeitplanung
1.Definitionsphase (4 Stunden)
1.1 Analyse der IST-Situation (1 Stunde)
1.2 Definition des SOLL-Zustandes (1 Stunde)
1.3 Erstellung eines Pflichtenhefts (2 Stunden)
2.Planungsphase (6 Stunden)
2.1 Recherche zur Hardwareumsetzung (1 Stunde)
2.2 Wirtschaftlichkeitsbetrachtung der Hardwareoptionen (2 Stunden)
2.3 Recherche zu möglicher Software für Testläufe (1 Stunde)
2.4 Erstellung des Projektablaufplans (2 Stunden)
3.Durchführungsphase (13 Stunden)
3.1 Aufbau der Hardwareumgebung (3 Stunden)
3.2 Installation und Konfiguration des Betriebssystemes (1 Stunde)
3.3 Installation und Konfiguration von Kubernetes (2 Stunden)
3.3 Installation der verschiedenen Monitoringagents (2 Stunden)
3.4 Eingliederung in die Monitoring-Umgebung (1 Stunde)
3.5 Testlauf (4 Stunden)
4.Abschlussphase (8 Stunden)
4.1 SOLL-IST-Vergleich (1 Stunde)
4.2 Vergleich der verschiedenen Agents (2 Stunden)
4.2 Empfehlung einer Monitoringlösung für Kubernetes-Umgebungen (2 Stunden)
4.3 Guidelines zum Monitoring von Kubernetes (2 Stunden)
4.4 Projektübergabe (1 Stunde)
5.Dokumentation (4 Stunden)
5.1 Erstellen einer Projektdokumentation (4 Stunden)
Projektantrag: Evaluation und Konfiguration eines Verfahrensmonitorings
in Abschlussprojekte
Geschrieben
Nein, wir haben im Haus eigentlich nur 2. Dashboard-Lösungen, entweder die in Check_MK inkludierte oder ZIS.
So oder so sind da eigentlich vorallem Schwellwertfestlegungen und Zusammenhänge zu definieren, der Programmieranteil ist bei nahezu 0.