Gast Geschrieben 3. März 2014 Teilen Geschrieben 3. März 2014 Hallo, mein Projektantrag wurde abgelenht, es hieß die Projektbeschreibung sei unklar. Deshalb bin ich bestrebt dies verständlich zu erklären. Aktuell sieht meine Projektbeschreibung so aus, was meint ihr? IST-Analyse Wir betreuen bereits seit mehreren Jahren das lokale Netzwerk eines Kunden welcher über diverse Standorte in Deutschland, den Niederlanden und Belgien verfügt. Aktuell wird das Monitoring über eine Lösung mit Realtech The Guard realisiert bei dem die Switches, Router und Firewalls per SNMP abgefragt werden. Das Monitoringkonzept besteht aus 2 Systemen, zwischen denen eine periodische Synchronisation stattfindet. Die Alarmierungen sind standortspezifisch, bei einem Ausfall Ausfall von Komponenten wird ein entsprechendes Ticket per E- Mail Schnittstelle generiert, zu den normnalen Betriebszeiten findet eine Alarmeirung asn den 2nd level Support statt, anderenfalls wird die Bereitschaft informiert. SOLL Zustand Aufbau einer neuen Monitoringlösung zur ausschließlichen Statusabfrage der Netzwerkkomponenten auf Erreichbarkeit mit ICMP für alle Komponenten ohne jegliche Ticketgenerierung mit Nagios. Abbildung der Funktionsweise des aktuellen Systems betreffend der Alarmierungen, hinzufügen von Host Abhängigkeiten um unnötige Alarmierungen zu vermeiden. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Klotzkopp Geschrieben 3. März 2014 Teilen Geschrieben 3. März 2014 IST-AnalyseDa fehlt mir irgendwie die Erwähnung der Motivation für das Projekt. Was ist an dem aktuellen Zustand unbefriedigend? Warum wird da ein Projekt erwogen? Ist es unzuverlässig? Wartungsaufwändig? Zu teuer? SOLL Zustand Aufbau einer neuen Monitoringlösung...Ein Aufbau von irgendetwas ist kein Zustand. Du baust diese neue Monitoringlösung auf, um den SOLL-Zustand zu erreichen. Im SOLL-Zustand sollen die Unzulänglichkeiten, die bei der IST-Analyse gefunden wurden, behoben worden sein. Auch hier fehlt mir das "warum". Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Gast Geschrieben 3. März 2014 Teilen Geschrieben 3. März 2014 Danke dir, Motivation sind hauptsähclich die Anforderungen des Kunden die sich verändert haben. Das habe ich in meinem vorherigen erstmal so allein stehen lassen ohne weiter darauf einzugehn, vielleicht auchnoch näher darauf eingehen? Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Gast Geschrieben 3. März 2014 Teilen Geschrieben 3. März 2014 Aktuell sieht meine Projektdefinition so aus: IST-Analyse Wir betreuen bereits seit mehreren Jahren das lokale Netzwerk eines Kunden welcher über diverse Standorte in Deutschland, den Niederlanden und Belgien verfügt. Aktuell wird das Monitoring über eine Lösung mit Realtech The Guard realisiert bei dem die Switches, Router und Firewalls per SNMP abgefragt werden. Das Monitoringkonzept besteht aus 2 Systemen, zwischen denen eine periodische Synchronisation stattfindet. Die entsprechende Konfiguration der Alarmierung ist nicht für eine Gruppe möglich ,stattdessen muss die Alarmierung für jede zu überwachende Komponente konfiguriert werden, ist daher wartungsaufwendig. Die Alarmierungen sind standortspezifisch, bei einem Ausfall Ausfall von ein oder mehreren Komponenten wird ein entsprechendes Ticket per E-Mail Schnittstelle generiert, selbst wenn es sich um denselben Standort handelt und die Ursache die gleiche ist wird für jedes ausgefallene Gerät ein Ticket generiert, es entsteht zu hoher Aufwand bei der anschließenden Abarbeitung. Das gleiche gilt für das Postfach in das die Notifications für einen Ausfall landen, daher keine Übersichtlichkeit mehr gegeben und Filterung sehr schwierig. Zu den normalen Betriebszeiten findet eine Alarmierung an den 2nd Level Support statt, anderenfalls wird die Bereitschaft informiert. SOLL Zustand Aufgrund von geänderten Kundenanforderungen das für das Monitoring Statusabfragen der Netzwerkkomponenten auf Erreichbarkeit mit ICMP für alle Komponenten ausreichend sind. Zudem findet eine Vereinheitlichung der Alarmierungen in Gruppen statt. Eine Ticketgenerierung soll das neue Moniotringsystem welches mit Nagios realisiert wird, nicht bieten. Die Motivation liegt darin begründet ein erweiterbares, effektives, performantes und leicht anpassbares Monitoringsystem zu gewährleisten das den tagtäglichen Ansprüchen gerecht wird. Insbesondere die Skalierung spielt eine wichtige Rolle. Desweiteren Evaluierung der Hardwareanforderungen für die Realiserung und Wahl von geigneter Hardware. Abbildung sowohl der Kundenanforderungen als auch der internen betreffend der Alarmierungen und Steigerung der Effektivität bei auftreten von Störungen durch die Konfiguration von Host Abhängigkeiten und Nutzung von Templates zur einfachen Erweiterung von Gruppen, Hosts und Services. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.