http://www.opitz-consulting.com/go/3-6-11 Oracle Enterprise Manager 12c Cloud Control sammelt zahlreiche Daten auf fast allen Ebenen der IT-Infrastruktur. Gerade durch die Engineered Systems wird die Rolle des Cloud Control immer wichtiger. Somit fallen nicht nur Datenbank-Metriken an, sondern auch Middleware- und Infrastruktur-Daten, wie z. B. von Loadbalancern. Oft steht in der Praxis der Einsatz des OEM als Monitoring-Werkzeug im Vordergrund: Die Rohdaten („Current Metrics") der überwachten Ziele werden zeitnah, innerhalb weniger Tage nach Sammlung aggregiert und verlieren durch diese Verdichtung für spätere Datenanalysen an Informationsgehalt. Detaillierte Analysen der Infrastrukturdaten über längere Zeiträume sind deshalb nicht möglich. Andererseits sprechen wirtschaftliche Gründe und die Performance gegen eine langfristige Speicherung von großen Datenmengen in der OEM Repository Datenbank oder in anderen, dedizierten RDBMS. In der Praxis beobachtet man zusätzliche Metrikdaten in der Größenordnung von 50-100 GB/ Monat, was eine Realtime-Auswertung schwer macht. Damit bleiben aufgrund von Budgetrestriktionen Potenziale in den historischen Daten ungenutzt oder die Abfragegeschwindigkeit von Auswertungen geht in den zweistelligen Minutenbereich. Unser Datenbankspezialist Ingo Reisky stellte in einem Vortrag bei der DOAG Konferenz 2014 gemeinsam mit Matthias Fuchs von der Firma ISE Information Systems Engineering vor, wie Metrikdaten von z. B. Oracle Datenbanken und Oracle Fusion Middleware in einem Hadoop Cluster gespeichert und mit Standard-Mitteln aus der Hadoop-Welt analysiert und visualisiert werden können. -- Über uns: Als führender Projektspezialist für ganzheitliche IT-Lösungen tragen wir zur Wertsteigerung der Organisationen unserer Kunden bei und bringen IT und Business in Einklang. Mit OPITZ CONSULTING als zuverlässigem Partner können sich unsere Kunden auf ihr Kerngeschäft konzentrieren und ihre Wettbewerbsvorteile nachhaltig absichern und ausbauen. Über unsere IT-Beratung: http://www.opitz-consulting.com/go/3-8-10 Unser Leistungsangebot: http://www.opitz-consulting.com/go/3-8-874 Karriere bei OPITZ CONSULTING: http://www.opitz-consulting.com/go/3-8-5

1. Oracle® Enterprise Manager 12c:
Historisierung und Analyse von Daten aus OEM
Cloud Control in Hadoop
Ingo Reisky
Senior Consultant
OPITZ CONSULTING Deutschland GmbH
Matthias Fuchs
Solutions Architect
ISE Information Systems Engineering GmbH
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 1
Nürnberg, 19.11.2014

2. Vorstellung OPITZ CONSULTING
Mission
Wir entwickeln gemeinsam mit allen
Branchen Lösungen, die dazu führen, dass
sich diese Organisationen besser entwickeln
als ihr Wettbewerb.
Unsere Dienstleistung erfolgt
partnerschaftlich und ist auf eine langjährige
Zusammenarbeit angelegt.
Leistungsangebot
 Application Lifecycle Management
 IT-Beratung
Business-Lösungen
Managed Services
Training und Coaching
 IT-Trends
Märkte
 Branchenübergreifend
 Über 600 Kunden
29%
Industrie / Versorger /
Telekommunikation
29%
Handel / Logistik /
Dienstleistungen
42%
Öffentliche Auftraggeber / Banken und
Versicherungen / Vereine und Verbände
Eckdaten
Gründung 1990
 400 Mitarbeiter
 9 Standorte
DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop © OPITZ CONSULTING, © OPITZ I.CONSULTING S.E. GmbH 2014 GmbH 2014
Seite 2

3. Wie OPITZ CONSULTING Big Data versteht
 Wir helfen Kunden,
 die Möglichkeiten von Big Data zu verstehen
 Business Cases in ihrem Unternehmen zu erkennen und ganzheitlich unter
Berücksichtigung bestehender Architekturen zu bewerten
 Projekte zielorientiert aufzusetzen und erfolgreich durchzuführen
 Business Cases anhand von Proof of Concepts zu verifizieren.
 Big Data ist bei OPITZ CONSULTING eines der TOP 3
Zukunftsthemen!
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 3
Big Data = Alter Hut
• IT-Durchdringung der
Geschäftswelt steigt seit
Beginn
• Mooresche Gesetz gilt
immer noch
OPITZ CONSULTING1990
• Database-focused
Company
• große Datenmengen &
komplexe
Anforderungen
OPITZ CONSULTINGt+25
• Individuallösungen,
wenn Standard nicht
ausreicht
• Kontinuierliche Adaption
neuer IT-Trends
Big Data = Chance
• Prozess- und
Interessenstransparenz
dank MachineData
• Wettbewerbsvorteile
dank Kombination
(Mobile+ Big Data +
Cloud + Analytics) 25

4. Enable
eXtreme
Performance.
www.ise-informatik.de
ISE Information Systems Engineering
Copyright (C) ISE GmbH - All Rights Reserved 4
 Gegründet 1991
 Mitarbeiteranzahl: 50
 Hauptsitz in Gräfenberg, Niederlassungen in München und Nürnberg
 Schwerpunkte:
 Oracle Engineered Systems (Exadata / Exalogic / Exalytics)
 Data Warehousing & Business Intelligence
 Oracle DB – Migrationen, Optimierungen, Hochverfügbarkeit
 Managed Service für Datenbanken, BI und Middlewareapplikationen
 Oracle Partner Engineered Systems Award 2013

5. Enable
eXtreme
Performance.
www.ise-informatik.de
ISE Oracle Technology Center
Erstes und einziges Exastack Technology Center in
Deutschland in Nürnberg
Copyright (C) ISE GmbH - All Rights Reserved 5

6. © OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 6
Agenda
1. Big Data aus dem Enterprise Manager?
2. Lösungsansätze im OEM
3. Lösungsansätze in Apache Hadoop
4. Praktischer Lösungsvorschlag
5. Zusammenfassung & Ausblick

7. 1 Big Data aus dem Enterprise Manager?
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 7

8. Das Innovationspotential von Big Data
Mehr speichern
• Rohdaten müssen nicht
mehr gelöscht werden
• Längere Historien
Complex Event
Recognition
• Mehr beobachten
• Schneller erkennen
• Informationsvorsprung
nutzen
Prädikative Analytik
• Prognosen
• Simulationen
Produktverbesserung Betrugserkennung
Erkennung von Attacken
Marktmonitoring für Verkaufschancen
Absatzprognose
Mitarbeitergewinnung
Personalisierte Produktempfehlung Kündigerfrüherkennung
Umsichtige Steuerung Finanzielle Risikoabschätzung
Vorausschauende Instandhaltung
Chancen steigern Risiken minimieren
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 8

9. Der OEM als willkommener Datenstaubsauger
 Oracle Enterprise Manager 12c (OEM) sammelt zahlreiche
Kennzahlen (Metriken) auf fast allen Ebenen der IT-Infrastruktur
 OEM unterstützt zahlreiche unterschiedliche Zieltypen:
 OS-Metriken (Windows, Linux, Unix, …)
 Oracle DB-Ziele: DB, GI, RAC, DG, …
 Oracle FMW-Ziele: WLS Cluster, OSB, SOA, WCP, WCC, OAM, OVD, …
 Non-Oracle DB und MW (z.B. MYSQL DB und Tomcat AS)
 Weitere Zieltypen (z.B. HW-LB via snmp)
 … bis hin zu Oracle Engineered Systems (z.B. Exadata)
 Standardmetriken unterschiedlich je Zieltyp, erweiterbar mit
Metric Extensions oder eigenen Agent Plug-ins
 Zusätzlich On-Demand-Funktionen (z.B. Logfile-Viewing)
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 9

10. Beteiligte Systemkomponenten im OEM 12c R4
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 10

11. Rolle des OEM in der Praxis
 Oft steht in der Praxis der Einsatz als Monitoring-Werkzeug
im Vordergrund:
 Hauptfunktion Überwachung/Alarmierung im Fokus
 Nebenfunktionen Kapazitätsplanung, Reporting, … nicht im Fokus
 Alte Metrikdaten werden oft zeitnah aggregiert und später
ganz gelöscht, da sie für Überwachung und Alarmierung
nicht mehr relevant sind
 Frische Incidents und Problems, also junge Metriken, am interessantesten
 1-2 Wochen alte Metriken nur noch für z.B. Ursachenforschung gebraucht
 Danach Schnee von gestern
 Damit stehen die Metrikdaten aber nicht in Rohform und
nicht dauerhaft für eigene Auswertungen zur Verfügung 
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 11

12. Der Lebenszyklus der OEM Metrikdaten
 Vier zentrale DB-Views im OEM Repository (SYSMAN):
 MGMT$METRIC_CURRENT: jüngster Metrikwert
 MGMT$METRIC_DETAILS: gesammelte Rohdaten
 MGMT$METRIC_HOURLY: Stundenwerte
 MGMT$METRIC_DAILY: Tageswerte
 Reduktion des Datenvolumens durch Aggregation:
 Standardwerte Aufbewahrungszeit: Rohdaten für 7 Tage; Stunden-Daten für
31 Tage; Tages-Daten für 1 Jahr (keine Monats-/Jahres-Daten)
 Konfigurierbar (MOS Doc ID 1405036.1 => Änderung Partitionierung)
 Kompromiss zwischen Datenwachstum im Repo und
Aufbewahrungszeit (retention times)
 Rohdaten (höchster Detaillierungsgrad) sind also in der
Standardkonfiguration schon nach einer Woche weg!
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 12

13. OEM Reporting-Werkzeuge & Datenmodell
 Oracle Information Publisher (IP):
 Integriert in OEM 11g und 12c, bewährte Reports
 Produkt schon länger abgekündigt, keine langfristige Lösung
 Oracle Business Intelligence Publisher (BIP):
 In OEM 12c integriert, für Reports mit begrenzter Komplexität gut geeignet
 Komplexe Abfragen mit dem BIP auf das OEM Repo dauern zu lange für
interaktives Online-Reporting und können hohe DB Last verursachen
 Bugs: Seit OEM 12c R4 nun BIP 11.1.1.7 möglich plus Bundle Patches
 SQL Zugriff auf Repository, SQL Developer: MGMT$ Views
 Grundsätzlich gelten für diese die Einschränkungen des
OEM Datenmodells:
 Aufbewahrungsfristen der Metrikdaten (Purging Policies)
 Auf effektives Schreiben der vom OMS empf. Agent-Uploads hin optimiert
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 13

14. Alternativen zu den OEM Reporting-Werkzeugen?
 Aufbewahrungsfristen der Metrikdaten im OEM Repository
könnten erhöht werden, aber:
 Performance des OEM muss gewährleistet bleiben und hohe
Kosten der Datenhaltung stehen dem entgegen…
 Kostenargument gilt auch bei Transfer der Metrikdaten in dediziertes, hoch-performantes
DWH/RDBMS
 Datenmengen können ziemlich groß werden… (in der Praxis zusätzliche
Metrik-Rohdaten in Größenordnung 50-100 GB/Monat gesehen)
 Lösungsvorschlag: Verwendung von Commodity Hardware
und Open Source Software: Apache Hadoop 
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 14

15. 2 Lösungsansätze im OEM
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 15

16. Ansatzpunkte im OEM im Überblick
An welchen Stellen im OEM System können Metrikdaten
abgegriffen werden?
Zentrale Ansatzpunkte:
 Direkte Datenübernahme aus der OEM Repository DB
 SQL Zugriff, DB Link, Export, …
 Verwendung von OEM Data Exchange Connectors
 Spezieller Typ von Konnektor für Datenaustausch, JMS-basiert
Dezentrale Ansatzpunkte:
 OEM Management Agents auf den Zielsystemen
 Verwendung von OEM Metric Extensions (früher: „User-Defined Metrics“)
 Verwendung von Custom Agent Plug-ins (Hardcore)
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 16

17. Ansatzpunkte für den Datentransfer im OEM 12c
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 17

18. Direkte Datenübernahme aus OEM Repository DB
 Haupt-Views können ausgelesen werden: MGMT$...
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 18

19. Direkte Datenübernahme aus OEM Repository DB
 DDL von View MGMT$METRIC_HOURLY (Beispiel):
Leider kein Primary Key…
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 19

20. Verwendung von Data Exchange Connectors
 Data Exchange-Konnektoren sind eine Funktionalität im
OEM 12c, um externe Systeme per Java Messaging Service
(JMS) anzubinden, eingehend oder ausgehende Nachrichten
 Es gibt Werkzeuge im Hadoop-Ökosystem, die eingehende
JMS-Nachrichten aufnehmen können (z.B. Apache Flume)
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 20

21. Verwendung von Metric Extensions (ME)
 ME werden zentral im OMS gepflegt, dezentral auf die
Agenten deployed und können dort beliebige Skripte
ausführen => möglicher Weg, Hadoop direkt anzusprechen?
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 21

22. Verwendung von Custom Agent Plug-ins
 Falls die Möglichkeiten von Metric Extensions den
Anforderungen nicht genügen, können via Oracle
Extensibility Development Kit (EDK) eigene Agent Plug-ins
entwickelt werden.
 Sind Java-basiert => Möglichkeit, den Hadoop Cluster direkt
per Webservice Call anzusprechen?
 Näheres siehe „Cloud Control Extensibility Programmer's
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 22
Guide “.
 Analog zu Metric Extensions sind auch hier ggf. Netzwerk-
/Firewall-Freischaltungen für die Kommunikation Host
Target – Hadoop erforderlich.

23. 3 Lösungsansätze in Hadoop
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 23

24. Bestandteile von Apache Hadoop
 Hadoop Common:
enthält von den Komponenten gemeinsam genutzte Utilities
 Hadoop HDFS (“Hadoop Distributed File System”):
ein verteiltes, hochverfügbares Datei-System, welches auf
Schreibzugriff und große Dateien hin optimiert ist
 Hadoop YARN (“Yet Another Resource Negotiator”):
Ressourcen-Manager
 Hadoop MapReduce (MR):
der ursprüngliche Map-and-Reduce Algorithmus
Zweck: Parallele Ausführung von Java-Programmen auf
großen Filesystem-Daten, die verteilt über Daten-Knoten mit
rel. kostengünstiger Hardware „von der Stange“ erfolgt
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 24

25. Wo ist die Brücke zwischen den Welten?
Problem: Strukturierte
Daten aus RDBMS lassen
sich nicht einfach mit
unstrukturierten Daten in
HDFS kombinieren…
Lösung: Apache Squoop
SQL-nach-Hadoop (ETL), leichter
Import aus RDBMS nach Hadoop,
erzeugt MapReduce Code,
Integration mit Apache Hive
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 25

26. Übersicht Hadoop Ökosystem
 Die vier Kernkomponenten werden durch einen bunten
Blumenstrauß an Bearbeitungswerkzeugen ergänzt!
Processing Layer
Stinger
Resource Management YARN + MapReduce
Storage Layer
Filesystem (HDFS)
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 26

27. Hadoop Processing Layer und Daten-Basis
 Basis kann jegliche Art von unstrukturierten Daten sein,
Nutzung ist abhängig von der Processing Layer Erweiterung
 Bilder
 Logfiles
 Filme
 Dokumente
 Die Analyse der Daten erfolgt über YARN Ressourcen-
Management verteilt im Cluster
 Die Geschwindigkeit ist somit nur noch von der Anzahl der
Datenverarbeitungsknoten und dem Storagesystem
abhängig
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 27

28. 4 Praktischer Lösungsvorschlag
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 28

29. Gewählter Architekturansatz
 SQL-Import von OEM Metrikdaten
 Datei-Import aus Filesystemen (Logfiles von OEM-Zielen)
 Auswertung mit ausgewählten Werkzeugen
Analytic
output
HDFS
Weblogs
CC
RDBMS
Flume
Elasticsearch
YARN/MR
SQOOP
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 29

30. Verwendete Werkzeuge
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 30
 Sqoop
SQL to Hadoop – Integration in Hadoop um Daten als
relationalen DBs in HDFS zu laden
 Flume
Tool zum einsammeln von Logs
verteilt, hochverfügbar
 Elasticsearch
Server für Enterprise-Suche
(mandantenfähig, volltextfähig),
basierend auf JSON-Dokumenten

31. Sqoop Daten-Import
 Abfrage der Metadaten in der Oracle DB zur Partitionierung
der MapReduce Jobs
 Übergabe der Jobs an YARN
 Start der Jobs
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 31

32. Sqoop Workflow
Sqoop DB Load
Store Data in HDFS
Load Data into HIVE
Analytic Queries mit
Impala oder Big Data SQL
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 32

33. Ergebnis: Sqoop Job erfolgreich
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 33

34. Ergebnis: Dateien im Sqoop Ausgabe-Verzeichnis
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 34

35. Ergebnis: Externe Tabelle in Hive anlegen
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 35

36. Ergebnis: Tabelle in Hue
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 36

37. Ergebnis: Beispieldaten in Hue
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 37

38. Nächste Schritte
 Automatisierung mit Oozie:
Workflow anlegen, um die zuvor gezeigten manuellen
Schritte zu automatisieren
 Auswertung der Daten in Hive mit Standard-BI-Tools
 Echtzeit-Abfragen über z.B. Cloudera Impala
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 38

39. Flume Integration
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 39
Weblogs
Flume
Weblogs
Flume HDFS
Elastic Search
Kopieren der
Logs,
komprimieren
Weitere
Auswertung mit
z.B. PIG
Speichern der
Logdaten als
Jason, Real Time
Index,
Auswertung mit
Kibana

40. Konfiguration Flume-Agent für Log-Kopie
<…>
source_agent.sources = wls_server</pre>
source_agent.sources.wls_server.type = spooldir
source_agent.sources.wls_server.channels = memoryChannel
source_agent.sources.wls_server.fileHeader = true
source_agent.sources.wls_server.deletePolicy = immediate
source_agent.sources.wls_server.spoolDir =
/.../user_projects/domains/base_domain/logrotate
#source_agent.sources.wls_server.ignorePattern =
soa_server1.log
<…>
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 40

41. Log Files in Hue
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 41

42. Inhalt der Logs
 Weiterverarbeitung mit z.B. R oder PIG
 Und laden in Elasticsearch
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 42

43. Flume nach Elasticsearch
 Weitere Konfiguration Flume-Agent
<…>
e_agent.sources.tail.type = exec
e_agent.sources.tail.command = tail -f --retry /u01/12.1/oracle/middleware/
user_projects/domains/base_domain/servers/soa_server1/logs/soa_server1-diagnostic.log
e_agent.sources.tail.interceptors=i1 i2 i3
e_agent.sources.tail.interceptors.i1.type=regex_extractor
e_agent.sources.tail.interceptors.i1.regex = [(.*)] [(.*)] [(.*)] [(.*)] [(.*)]
[(.*)] [(.*)] [(.*)] [(.*)] (.*)
e_agent.sources.tail.interceptors.i1.serializers = s1 s2 s3 s4 s5 s6 s7 s8
e_agent.sources.tail.interceptors.i1.serializers.s1.name = date
e_agent.sources.tail.interceptors.i1.serializers.s2.name = mangedserver
e_agent.sources.tail.interceptors.i1.serializers.s3.name = type
e_agent.sources.tail.interceptors.i1.serializers.s4.name = addon
e_agent.sources.tail.interceptors.i1.serializers.s5.name = ComponentID
e_agent.sources.tail.interceptors.i1.serializers.s6.name = tid
e_agent.sources.tail.interceptors.i1.serializers.s7.name = userID
e_agent.sources.tail.interceptors.i1.serializers.s8.name = ecid
<…>
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 43

44. Flume-Meldungen in Kibana
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 44

45. Kibana Analytics
 Visual Analytics
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 45
in Kibana
 Beispiel
Fehlerklassen

46. 5 Zusammenfassung und Ausblick
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 46

47. Zusammenfassung
 Oracle Enterprise Manager 12c sammelt bereits im Standard
eine große Vielfalt von Metriken für heterogene Arten von
Zielen (DB, Middleware, Apps, Engineered Systems, …)
 Datenmodell des OEM ist historisch auf Monitoring &
Alarmierung ausgerichtet, Repository hat Einschränkungen
bzgl. Online-Auswertungen / Information Discovery
 Durch den Transfer der Metrik-Daten in einen Hadoop
Cluster können diese Einschränkungen umgangen werden:
Rohdaten speicherbar, eigene Datenmodelle verwendbar
 Sind die Metrikdaten in Hadoop verfügbar, bieten sich dort
alle bekannten Möglichkeiten der Werkzeuge des Hadoop-Ökosystems:
Schema-on-Read, Suche, Visualisierung,…
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 47

48. © OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 48
Ausblick
 Rolle des OEM wird durch Engineered Systems wichtiger,
zukünftig noch höheres Volumen und Vielfalt der
Metrikdaten zu erwarten. Mehr Mehrwert!
 Oracle trägt dem Rechnung: „Oracle Analytics Cloud “
kürzlich angekündigt. Big data as a service – BDaaS 
 https://www.oracle.com/corporate/pressrelease/analytics-cloud-092914.html
 „Leveraging Oracle Big Data SQL, Hadoop, and Oracle Database as a
Service together”
 Partnerschaft zwischen Oracle und Cloudera, einer der
führenden Hadoop-Distributionen:
 Cloudera in Oracle Big Data Appliance enthalten (Engineered System)
 “Oracle Big Data Lite Virtual Machine” ausprobieren, VBox VM enthält in
aktueller Version 4.0.1 u.a. Cloudera CDH 5.1.2 – viel Spass beim Testen!

49. Oracle Unified Query
 Oracle Integration Hadoop
 Abfrage der Daten über SQL
 Die Daten können in Hadoop
oder einer Oracle DB liegen
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 49

50. Oracle Hadoop Integration
 Oracle Hadoop Erweiterung
 Query Offloading to Hadoop
SparkSQL Hive Impala
Hive Metastore
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 50
Oracle Big
Data SQL
…
Table Definitions:
movieapp_log_json
Tweets
avro_log
Metastore maps DDL to Java access classes

51. Ansprechpartner bei OPITZ CONSULTING
Ingo Reisky
Senior Consultant, Infrastructure Consulting
OPITZ CONSULTING Deutschland GmbH
ingo.reisky@opitz-consulting.com
Telefon +49 89 680 098 -1489
Mobil +49 172 204 8789
youtube.com/opitzconsulting
@OC_WIRE
slideshare.net/opitzconsulting
xing.com/net/opitzconsulting
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 51

52. Ansprechpartner bei ISE
Matthias Fuchs
Solutions Architect
ISE Information Systems Engineering GmbH
matthias.fuchs@ise-informatik.de
Telefon +49 9192 9929 505
Mobil +49 172 8288 751
Blog - http://hias222.wordpress.com
LinkedIn - https://www.linkedin.com/pub/matthias-fuchs/2/6a6/620
Xing - https://www.xing.com/profile/Matthias_Fuchs17
Twitter - https://twitter.com/Hias222
© OPITZ CONSULTING, I.DOAG 2014: Analyse und Historisierung von OEM Metrikdaten in Hadoop S.E. GmbH 2014 Seite 52