Buddhy

Entschuldige die späte Antwort @sts23 Umfangreich wird es auf jeden Fall, jedoch klingt es nach mehr, da ich im Projektantrag noch nicht weiß für welche Lösung wir uns entscheiden, weswegen viele Aspekte so generell formuliert sind. - Ich vermute ehrlich gesagt, das die beiden Favoriten Splunk und ELK stack schon einfachere Möglichkeiten mitbringen sollte das nicht der Fall sein werde ich vermutlich auf Scripte oder regexp zurückgreifen, wobei ich dann nur ein Fallbeispiel nahe legen werde und auf den Gebrauch dieser zur Erstellung von Benachrichtigungen etc. verweisen werde. - Den Punkt hatte ich in 2.2 am Ende kurz aufgegriffen, auch hier liegt die Vollständige Umsetzung im Hintergrund, wobei das von der Zeit abhängig wird. Vermutlich werde ich eine Berechtigungsgruppe für unsere IT in LDAP erstellen und falls es ELK stack wird diesen an unser LDAP anbinden. Mehr oder weniger als proof of concept. Ob LDAP auch bei Spunk eine Möglichkeit ist weiß ich aktuell noch nicht. Hinter "3.3.2.6. Erstellung von Workflows und Prozessen 2h" verbirgt sich die von der Projektdoku unabhängige Dokumentation bzw. How to zum Einbinden von neuen LOG quellen. Somit soll auch der Prozess genormt sein um Zertifikatsansprüchen wie ISAE 3402 Zertifizierung gerecht zu werden. Freundliche Grüße Buddhy

Hängt halt stark von dem gewählten Log Management ab, Splunk in AWS kommt so out of the box. Meines Wissens hat Splunk aber 3 Möglichkeiten die Logs zu sammeln, somit wäre da Schwerpunkt mehr darauf die verschiedenen Varianten zu begutachten. Da wir auch Logs zentralisieren wollen, die Userdaten enthalten, sollen diese z.B, bereits "vorformatiert" werden. Was wiederum stark von dem jeweiligen Agent abhängt. ELK stack ist meiner Meinung nach ein schönes open source Beispiel da immernoch elastic search logstash und kibana unabhängig voneinander via ssh auf der Maschine installiert und konfiguriert werden müssen. In beiden Fällen müssen dann noch Firewallregeln angepasst werden bzw. neu gebaut werden. Ich kann nur schwer einschätzen wie das Thema der Log Formate und verschiedener timestamps mit reinspielt. Sollte man sich für ein Sammeln der Daten via Agent entscheiden muss man zusätzlich überlegen wie man diese auf unsere Server verteilen will. Manuell ist keine Option, vermutlich mit einem neuen Puppet Manifest.

Moin mapr, kannst du etwas genauer werden ?

Moin, hier einmal die erste Version meines Projektantrags, ich freue mich über Feedback und Anregungen. Danke schon mal im voraus. Projektantrag Fachinformatiker Fachrichtung Systemintegration Antrag für die betriebliche Projektarbeit Antrag: Antrag vom: Projektbezeichnung Kurzform der Aufgabenstellung Ist-Analyse Zielsetzung entwickeln / Soll-Konzept Was soll am Ende des Projektes erreicht sein ? Welche Anforderungen müssen erfüllt sein ? Welche Einschränkungen müsse berücksichtigt werden ? Projektstrukturplan entwickeln Was ist zur Erfüllung der Zielsetzung erforderlich Hauptaufgaben auflisten Projektphasen mit der Zeitplanung in Stunden Projektbezeichnung ( Auftrag / Teilauftrag ): Evaluierung und Implementierung eines zentralisierten Log Managements. 1.1. Kurzform der Aufgabenstellung Im Interesse der Banana GmbH, soll zeitnahe ein zentralisiertes Log Management eingeführt werden, dass den aktuellen und zukünftigen Ansprüchen des Unternehmens entspricht. Unter anderem soll es die Möglichkeit geben Analysen und granulierte Fehlermeldungen sowohl von System- als auch Applikationslogs erstellen zu können. Gewünscht ist zudem, dass ab einem bisher nicht definierten Zeitpunkt Analysen über Ressourcennutzung und Userverhalten, sowohl von System- als auch Applikationslogs durchgeführt werden können. Erstellung von internen policies und workflows, um das Einbinden von Logs in Zukunft zu vereinheitlichen und um zukünftigen Zertifikats Ansprüchen gerecht zu werden. 1.2. IST-Analyse Aktuell wird in der Banana GmbH ein zentralisiertes Graylog Setup eingesetzt, in diesem werden jedoch nur die Logs unserer Onlineshops gesammelt. Andere Logdateien werden dezentral auf den einzelnen Hosts/Geräten gespeichert. Beispiele hierfür sind unter anderem Apache, Wildfly, Jenkins sowie Audit-, Kernel- und XenServer-Logs. In dem jetzigen Zustand ist das Analysieren und Auswerten von Logs nur sehr bedingt möglich, wodurch Fehlersuche sowie das Sammeln von Prozessdaten nur wenig Früchte trägt. 2. Soll-Konzept / Zielsetzung entwickeln 2.1. Was soll am Ende des Projektes erreicht sein ? Die auf dem Markt gängigen Log Management Tools sollen betrachtet und evaluiert ""werden"", daraufhin sollen die Ergebnisse der Evaluation mit den jeweiligen Ansprüchen und Systemvorgaben an das Tool abgeglichen ""werden"". Abhängig von dem jeweiligen Leistungsumfang der verschiedenen Angebote ist einzuschätzen wie sich Lizenzkosten und Arbeitsstunden auf die Gesamtkosten der Projektumsetzung auswirken, hierbei sind auch laufende Kosten sowie zukünftiger Arbeitsaufwand mit zu berücksichtigen. Abhängig davon ob es sich um eine “on premise” Lösung oder um eine in der Cloud gehostete Variante handelt, sind Datenschutzrichtlinien zu beachten. In Anbetracht dieser Aspekte soll ein neues Log Management in der Firma implementiert werden, vorerst als proof of concept. Im zweiten Schritt, soll dadurch das aktuell genutzte Graylog Setup abgelöst werden. 2.2. Welche Anforderungen müssen erfüllt sein ? Das zentralisierte Log Management soll einfach zu administrieren sein, damit es im Unternehmens Alltag ohne viel Aufwand zum Nachvollziehn von Fehlerursachen als auch zum Erstellen von Analysen, Prognosen und Alerts genutzt werden kann. Damit ein zentralisiertes Setup zu Stande kommt benötigen wir einen Service der sich um das sammeln und weiterleiten der Logs kümmert, einen Service der die Logs aggregiert und einen Service der die Logs auswertet, je nach Menge der Logs sollte man sich schon bei der Planung Gedanken über die größe der jeweiligen Host Systeme machen, in unserem Fall bekommt sowohl der Service zum Aggregieren als auch der Service zum Analysieren ein eigenes Host System, sodass diese falls notwendig unabhängig voneinander skaliert oder migriert werden können. Der hauptsächliche Interaktionspunkt im Alltag ist das jeweilige Webinterface, ob Splunk, ELK Stack oder Graylog die aktuellen Versionen dieser Tools bieten alle eine ausgebaute Weboberfläche, ob diese unseren Anforderungen entsprechen muss an einem späteren Zeitpunkt evaluiert werden. Zusätzlich ist es von hoher Wichtigkeit dass, das Einbinden und Hinzufügen von neuen Logs einfach und ohne Komplikationen möglich ist. Zum Sammeln und Weiterleiten der Logs werden in der Regel Agents auf den Client Systemen installiert, je nach Software kann dann entschieden werden in welchem Umfang Logs gesammelt werden oder ob diese z.B. bereits vorsortiert werden sollen. Ein Beispiel für einen solchen Agent wäre "filebeat" welcher im ELK Stack oder auch bei Graylog Setups zum Einsatz kommt. Um das Einbinden von zusätzlichen Logs weiterhin zu vereinfachen sollen Workflows, Prozesse und Namensschemata definiert werden. Damit in Zukunft auch andere Abteilungen ausschließlich Zugriff auf die für sie relevanten Logs und Analysen bekommen können, werden Berechtigungsgruppen benötigt diese werden entweder innerhalb des Services oder über LDAP definiert. 2.3. Welche Einschränkungen müssen berücksichtigt werden ? Auf Grund von bestehenden Kundenverträgen, sollte man sich bevorzugt mit dem Hosting bei XXX auseinandersetzen. Ein Hosting in AWS ist in der Theorie zwar möglich, könnte aber mit Vertragsänderungen und somit Mehrkosten verbunden sein. Als Betriebssystem soll CentOS 6.9 herhalten, da aktuell alle Linux Server im Unternehmen auf diesem Betriebssystem laufen. In Anbetracht der Kosten sollen sowohl Enterprise Lösungen wie Splunk oder Logz.io aber auch open source Produkte wie ELK stack evaluiert werden, hierbei sind sowohl einmalige als auch fortlaufende Lizenzkosten sowie Arbeitsstunden und vermeintlicher Support zu berücksichtigen. Auf Grund der verschiedenen und dezentralen Logs müssen Punkte wie einheitliche Formate und Timestamps berücksichtigt werden. 3.1 - 3.3. Projektstrukturplan entwickeln 3.1. Was ist zur Erfüllung der Zielsetzung erforderlich Zur Erfüllung sind drei Centos 6.9 Maschinen notwendig, auf einer Maschine wird die Software zum aggregieren der Daten installiert auf einer weiteren Maschine wird die Software zur Auswertung der Daten installiert. Bei der dritten Maschine handelt es sich um einen bereits bestehenden Applikations-Server, auf dem ein Agent zum Sammeln und Weiterleiten der Logs installiert wird. Dieser Server wird im Rahmen des Projektes als Test-Ressource genutzt, um verschiedene Logs zu generieren. Idealerweise sollte ein Laptop mit einem Unix basierten Betriebssystem bereitgestellt werden, da dieser zum installieren, konfigurieren und testen des jeweiligen Log Management Tools und des darunter liegenden Systems, benötigt wird. 3.2. Hauptaufgaben auflisten Vorbereitung und Planung Durchführung / Realisierung des Projektes Testphase / Qualitätssicherung Projektabschluss und Übergab 3.3. Projektphasen mit Zeitplanung in Stunden 35h 3.3.1. Vorbereitung / Planung 8h 3.3.1.1. Auftragsbestimmung 1h 3.3.1.2. IST-Analyse 1h 3.3.1.3. SOLL-Konzept 1h 3.3.1.4. Projektplanung 1h 3.3.1.5. Erstellung einer Übersicht der zu loggenden Systeme 1h und Prozesse 3.3.1.6. Produkte evaluieren 3h 3.3.2. Durchführung / Realisierung des Projekts 14h 3.3.2.1. Auswahl der benötigten Hard- und Software 1h 3.3.2.2. Installation und Konfiguration des Betriebssystems 1h 3.3.2.3. Installation und Konfiguration des Log Management 7h 3.3.2.4. Ausrollen der Agents manuell und oder via Puppet 1h 3.3.2.5. Konfiguration Weboberfläche / Analysene etc. 2h 3.3.2.6. Erstellung von Workflows und Prozessen 2h 3.3.3. Testphase / Qualitätssicherung 6h 3.3.3.1. Funktionstest der verschiedenen Services 1h 3.3.3.2. Funktionstest mit verschiedenen Logs 1h 3.3.3.3. Abgleich zwischen Log Files und Webinterface Analyse 1h 3.3.3.4. Fehleranalyse und Fehlerbehebung 3h 3.3.4. Projektabschluss und Übergabe 7h 3.3.4.1 Projektdokumentation 6h 3.3.4.2 Übergabe an Auftraggeber 1h