Am 4. Oktober ist die Automic V12 erschienen und hat einige Neuerungen mit sich gebracht. Ich habe kurz nach der Veröffentlichung schon einen kleinen Überblick darüber gegeben. In diesem Artikel stelle ich Ihnen mein liebstes neues Feature der V12 im Detail vor: Die Automic Analytics.
Inzwischen konnte ich die Analytics ausführlich selbst testen, habe mir aber noch einen Insider als Unterstützung geholt: Tobias Stanzel ist Software Product Designer bei Automic und war für die Entwicklung der Automic Analytics verantwortlich.
Tobias arbeitet seit 15 Jahren in der Softwareentwicklung und ist seit 4 Jahren bei Automic. Seine Freizeit verbringt er am liebsten mit seinen drei Kindern und in der Natur. Ansonsten arbeitet er natürlich fleißig daran, unsere Lieblingsautomatisierungsplattform immer besser zu machen. Sein Motto dabei: „Finde heraus, was die Kunden brauchen – und baue das passende Produkt dafür.“
Es war mir ein großes Vergnügen mit ihm über die Automic Analytics zu plaudern und Antworten auf einige der Fragen zu bekommen, die mir – und vielleicht auch Ihnen – unter den Nägeln brennen.
Vielen Dank an dieser Stelle noch einmal an Tobias für ein tolles Gespräch und jede Menge nützliche und spannende Hintergrundinformationen.
Die Architektur der Automic V12 Analytics
In der Dokumentation zur V12 gibt es die folgende Grafik zur Architektur der V12 Analytics (rote Kommentare von mir). Dabei fällt insbesondere ein Faktor auf: Der Analytics Datastore ist eine PostgreSQL Datenbank.
Ich habe Tobias bei unserem Treffen die naheliegende Frage gestellt: Warum PostgreSQL – und warum ausschließlich PostgreSQL?
„Wir wollten eine Lösung anbieten, die auf ein Datenbank-System optimiert ist. Das reduziert dieKomplexität und ermöglicht uns, die Funktionalität der Datenbank voll auszureizen, weil wir nicht aus Kompatibilitätsgründen auf den kleinsten gemeinsamen Nenner eingeschränkt sind.
Außerdem wollen wir den ‘Datastore’ direkt mit ausliefern, daher musste es eine OpenSource Datenbank sein.
Dass es schließlich PostgreSQL wurde, war eine rein technische Entscheidung.
Automic wird Sie bei der Einrichtung und Konfiguration des Datastores natürlich unterstützen. PostgreSQL wird schließlich als Teil des Produkts ausgeliefert.
Die Analytics Datenbank ist als lokaler Datastore konzipiert, es ist standardmäßig kein Zugriff von außen möglich. Wir liefern Tools zum Datenmanagement in Form eines Action-Packs mit. So kann man Analytics auch ohne Kenntnisse von PostgreSQL administrieren.”
Setup und Installation der V12 Analytics
Es gib eine detaillierte Installationsanleitung im AE Administration Guide.
Ich habe noch ein paar zusätzliche Hinweise für Sie:
- Beim Setup des Analytics Datastores wir ein API-Key ausgegeben. Den müssen Sie später in die Konfigurationsdatei des AWI-Plugins einfügen. Falls Sie den Key verlieren, finden Sie ihn in der Analytics Datenbank in „key“, der einzigen Spalte der Tabelle api_key.
- Der Analytics Datastore (die PostgreSQL Installation) erlaubt standardmäßig nur lokale Verbindungen. Das ist kein Problem, solange das Analytics Backend am selben Server läuft wie die Datenbank. Alle, die das Backend nicht am selben Server betreiben wollen, erfahren in der Installationsanleitung unter „Test the Connection to the Datastore“, wie man das ändern kann.
- Analytics unterstützt derzeit nur AE-Datenbanken unter Oracle und MS SQL Server als Datenquellen, DB2 wird aktuell (noch?) nicht unterstützt.
- Ich rate dazu, nicht nur das Backend, sondern auch den Datastore zum Automic Service-Manager hinzuzufügen. Der Screenshot zeigt ein Beispiel-Setup für den Analytics Datastore im Service-Manager.
- Das Analytics Backend kann auch SSL verwenden, lesen Sie dazu den Abschnitt Securing the Backend Administration Guide.
- Passwörter in der Konfigurationsdatei application.properties können (und sollten) genauso verschlüsselt werden, wie in der Datei ucsrv.ini der Automation Engine.
- Wenn Sie den API-Key im Analytics AWI-Plugin (in der Konfigurationsdatei plugin.properties) eintragen oder ändern, nachdem Sie das Plugin installiert haben, dann müssen Sie den AWI-Tomcat neu starten, damit die Konfigurationsänderung greift.
Wie kommen die Daten von der AE in die Analytics?
Tobias hat mir erklärt, wie die Daten in den Analytics Datastore kommen. Das Analytics Backend zieht die Daten aus der AE und (optional) ARA Datenbank. Dafür stehen zwei unterschiedliche Modes zur Verfügung: Normal Sampling Mode and Large Sampling Mode.
Im Normal Sampling Mode werden standardmäßig alle fünf Minuten die Daten aller Tasks aus der AE in die Analytics DB übertragen, die in den letzten 6 Minuten (= 5 Minuten + 60 Sekunden) fertig geworden sind. Diese Zeitabschnitte können mit zwei Parametern geändert werden:
- collector.normal_sampling_period.minutes – verändert den Abstand zwischen den Samplings und den Zeitraum der geholten Daten. Default-Wert: 5 Minuten.
- collector.safety_margin.seconds – verändert den zusätzlichen Zeitraum, für den Daten gezogen werden. Default-Wert: 60 Sekunden.
Als Suchkriterium in der AE Datenbank wird AH_Timestamp4 benutzt.
Der Large Sampling Mode kommt immer dann zum Einsatz, wenn der letzte Datensatz älter als die normal_sampling_period ist. Das Large Sampling blickt soweit in die Vergangenheit, wie der jüngste, vorhandene Datensatz in der Analytics DB alt ist. Es holt alle Daten die seither angefallen sind. Die Daten werden in Paketen von höchstens 50.000 Records in die Analytics DB übernommen.
Wenn der jüngste vorhanden Datensatz in Analytics älter als 1 Tag ist, dann werden die Daten tageweise abgeholt, jedoch auch immer nur in Paketen von maximal 50.000 Records.
Das Large Sampling geht maximal 32 Tage in die Vergangenheit. Ältere Daten werden nicht gesammelt.
Natürlich können Sie auch in diesem Modus alle wichtigen Parameter anpassen:
- collector.large_sampling_period.days
Default-Wert: 1 Tag - collector.initial_collect_before_now.days
Default-Wert: 32 Tage - collector.chunk_size.rows
Default-Wert: 50.000 Zeilen
Im Analytics Backend können Sie über die Konfigurationsdatei übrigens auch Chart Caching aktivieren. Standardmäßig werden Charts jedes Mal neu berechnet und mit den neuesten Daten dargestellt. Bei sehr großen Datenmengen kann das zu merkbaren Ladezeiten führen.
Aktiviert man das Caching, bekommt man zwar nicht immer sofort die aktuellsten Daten dargestellt, dafür gibt es keine Verzögerung bei der Darstellung der Diagramme, während man in ihnen navigiert.
Welche Daten werden aus der AE in die Analytics übertragen?
Bisher werden in Analytics nur drei Datenquellen der AE modelliert: Jobs, Workflows und Service Fulfillments. Dafür werden zwei Tabellen der AE in die Analytics übernommen:
- AH – die Header-Tabelle der Statistiksätze
- LASLM – Die Monitoring-Tabelle für Service Fulfillments (für den neuen Objekttyp SLO)
Wie im folgenden Screenshot verdeutlicht, werden die Daten zunächst 1:1 in Staging Tabellen kopiert. Danach werden sie angereichert und normalisiert für die modellierten Tabellen AH_Cleaned und LASLM_Cleaned. Diese dienen dann als Basis für die Analytics.
Die Daten aus der Tabelle LASLM werden einfach komplett in LASLM_Cleaned übernommen und stehen dann für die Analytics zur Verfügung.
Bei der Tabelle AH ist die Sache ein wenig komplizierter: Die Tabelle AH in der Analytics DB enthält noch alle Felder der Tabelle AH der AE. Die Tabelle AH_Cleaned enthält aber nur noch 18 der 129 Spalten von AH – dafür 2 zusätzliche Spalten aus AH_Enricher.
AH_Cleaned enthält übrigens nicht nur Statistikdaten von Jobs und Workflows, sondern von fast allen Objekttypen. Bisher sind allerdings nur die beiden Objekttypen Job und Workflow für Analytics modelliert. Daher können nur diese beiden verwendet werden.
Es stehen insgesamt 20 Felder zur Analyse von Jobs und Workflows zur Verfügung, nämlich:
Mein Meinung: Ein begeisterndes Minimum Viable Product
In meinem ersten Blogpost zur V12 habe ich die Automic Analytics als ein „Minimum Viable Product“ bezeichnet, mich gleichzeitig aber auch als absoluter Fan davon geoutet.
Das klingt für Sie nach einem Widerspruch? Das ist es aber keinesfalls:
Sowohl die Architektur als auch die Art der Implementierung von Analytics begeistern mich total. Sie bilden eine tolle Basis für die Analytics, um in Zukunft nach und nach mehr Daten aufzunehmen und für die Analyse bereitzustellen.
Bisher können Sie aber nur Service Fulfillments und 20 Attribute der Statistiksätze von JOBS und Workflows in den Analytics nutzen. Das meine ich, wenn ich von einem Minimum Viable Product spreche. Ich bin mir aber sicher, dass sich das schnell ändert. In der AE steht schließlich ein riesiger Datenschatz zur Analyse bereit.
Die nächsten Schritte mit den Automic Analytics
Ich habe Tobias Stanzel gefragt, wie es mit den Analytics weitergehen wird und eine vielversprechende Antwort erhalten:
„Wir haben noch große Pläne mit den Analytics. Derzeit arbeiten wir am Bereich Datenmodellierung, um noch weitere Objekttypen zu unterstützen. Außerdem werden wir immer mehr Attribute von der AE in die Analytics übernehmen – zum Beispiel AV Daten, um Objektvariablen und die Werte von PromptSets abbilden zu können.
Auch die Actions sollen noch erweitert werden, dazu kann ich aber noch nichts Genaueres verraten.
Für mich persönlich ist auch die Integration ins AWI noch ein wichtiger Ansatzpunkt für Verbesserungen. Es wäre doch toll, aus Analytics-Widgets direkt zu anderen Perspektiven im AWI verlinken zu können.
Ich kann auf jeden Fall versprechen: Im Bereich ‚Daten‘ wird sich bei Automic noch viel tun!“
Das klingt doch großartig, finden Sie nicht auch? Ich bin vor allem gespannt, was die mysteriöse Ankündigung im letzten Satz zu bedeuten hat…
Wie sieht es bei Ihnen aus? Haben Sie schon mit den Analytics experimentiert? Haben Sie Wünsche oder Anregungen für die Zukunft? Schreiben Sie mir einen Kommentar, ich werde alles Feedback an Automic weiterleiten.