Application Response Measurement API

Die Application Response Measurement API (ARM API) wurde ursprünglich (Version 1.0) im Jahre 1996 in einer gemeinsamen Initiative der Firmen Hewlett Packard und Tivoli entwickelt. Die Nachfolgeversionen 2.0 und 3.0 wurden von der ARM Working Group (ARM WG) der Computer Measurement Group (CMG) CMG Computer Measurement Group   entwickelt. Die ARM WG der CMG ist ein Zusammenschluß von 17 Firmen unter der Leitung von Hewlett-Packard und Tivoli. 1998 wurde die Version 2.0 der ARM API von der Open Group  im Rahmen der IT Dialtone Initiative als technischer Standard [#!c807!#] übernommen. Aktuell ist Version 3.0 der ARM API verfügbar, die allerdings zum heutigen Zeitpunkt noch nicht als offizieller Standard übernommen wurde. Aus diesem Grund wird im folgenden zunächst die Version 2.0 vorgestellt und im Anschluß daran ein Überblick über die wesentlichen Erweiterungen der Version 3.0 gegeben. Die Arbeiten zur ARM API der ARM WG und die Arbeiten der DAP/Metrics WG der DMTF (siehe Abschnitt ) ergänzen sich und werden gemeinsam vorangetrieben [#!john:99!#].

Die ARM API erlaubt die transaktionsbasierte Überwachung des Antwortzeitverhalten s verteilter Anwendungen auch in heterogenen Umgebungen. Um dieses Ziel zu erreichen wurde eine sehr einfache API definiert. Vor Beginn und nach Ende jeder (vom Anwendungsentwickler festzulegenden) zu überwachenden Transaktion müssen Aufrufe der entsprechenden Funktionen der API in den Source Code der Anwendung eingefügt werden. Die Implementierung der Funktionen der API erfolgt in sogenannten Measurement Agents, die zur zu überwachenden Anwendung gebunden werden. Diese bestimmen und speichern den Zeitpunkt der Aufrufe und gestatten so die Berechnung der Antwortzeiten einzelner Transaktionen.

 

Abbildung:  ARM API: Architektur

13#13

Abbildung  stellt die resultierende Architektur dar: Eine - möglicherweise verteilt realisierte - Anwendung wird instrumentiert, vor Beginn und nach Ende jeder Transaktion eine Funktion der ARM API aufzurufen [#!hare00!#]. Ein auf dem jeweiligen System vorhandener Measurement Agent wird dynamisch zur Anwendung gebunden und wird somit im selben Prozeß wie die zu überwachende Anwendung ausgeführt. Er nimmt die Aufrufe entgegen, bestimmt die aktuelle Systemzeit und leitet die Information an beliebige Managementanwendungen weiter. Die Schnittstelle zwischen Managementanwendung und Measurement Agent ist hierbei allerdings nicht vorgegeben, sondern bleibt der Implementierung des Managementsystems überlassen. Aus Gründen der Performanz des resultierenden Systems wird allerdings vorgeschlagen, daß der Measurement Agent nur teilweise innerhalb des Prozesses der zu überwachenden Anwendung abläuft und der Hauptteil des Agenten (z.B. die Kommunikation mit der eigentlichen Managementanwendung) außerhalb der Anwendung stattfindet [#!john97!#]. Damit instrumentierte Anwendungen auch dann lauffähig sind, wenn kein Measurement Agent auf dem System vorhanden ist, kann die sogenannte Null Library zur Anwendung gebunden werden. Diese implementiert die ARM API, verfügt aber über keinerlei Funktionalität, sondern kehrt unmittelbar zur aufrufenden Anwendung zurück.

In Version 2.0 der ARM API sind die folgenden sechs Funktionen definiert:

• arm_init
  Wird während der Initialisierung der zu überwachenden Anwendung (bzw. einer Instanz einer Anwendung) aufgerufen und dient dazu, die Anwendung eindeutig zu benennen und den aktuellen Benutzer zu identifizieren. Diese Funktion liefert einen eindeutigen Identifikator für die Instanz der Anwendung.
• arm_getid
  Dient dazu, die unterschiedlichen Klassen von Transaktionen, die innerhalb der Anwendung auftreten können, zu definieren und einen eindeutigen Identifikator für jede Transaktionsklasse zu generieren. Für jede Klasse läßt sich optional angeben, welche zusätzlichen Informationen in den nachfolgenden Aufrufen zu liefern sind.
• arm_start
  Dieser Aufruf wird in den Code der Anwendung eingefügt, unmittelbar bevor eine zu überwachende Transaktion beginnt. Die Klasse der Transaktion wird über den mittels arm_getid ermittelten Identifikator übergeben. Als Rückgabewert wird ein eindeutiger Identifikator der Transaktionsinstanz zurückgegeben. Weitere Daten, die den aktuellen Status der Anwendung beschreiben, können - wie mittels arm_getid beschrieben - als Parameter mit übergeben werden.
• arm_stop
  Ebenso, wie zum Start einer Transaktion die Funktion arm_start aufgerufen wird, wird zu deren Ende die Funktion arm_stop aufgerufen. Wiederum können zusätzliche Informationen, insbesondere über den Erfolg oder Mißerfolg der Transaktion übergeben werden. Die Identifikation der Instanz der Transaktion erfolgt über den vom arm_start Aufruf zurückgelieferten Identifikator.
• arm_update
  Dieser Aufruf kann beliebig oft zwischen arm_start und arm_stop Aufrufen verwendet werden, um zusätzliche Informationen zu übermitteln oder z.B. im Falle sehr lang dauernder Transaktionen zwischenzeitlich einen Status zu übergeben und mitzuteilen, daß die Transaktion weiterhin korrekt ausgeführt wird.
• arm_end
  Wenn die zu überwachende Anwendung beendet wird, kann dies dem Measurement Agent mit Hilfe von arm_end übermittelt werden, der daraufhin die belegten Ressourcen freigeben kann.

Seit Einführung von Version 2.0 gestattet die ARM API die Korrelation von Subtransaktionen zu übergeordneten Transaktionen. Dies kann über mehrere Systeme verteilt geschehen. Hierzu werden sogenannte Korrelatoren (correlators) eingesetzt. Beim Aufruf von arm_start kann die Anwendung vom Measurement Agent einen Korrelator anfordern, der bei nachfolgenden Aufrufen von arm_start wieder übergeben werden kann. Diese nachfolgenden Aufrufe werden dann vom Measurement Agent als Beginn von Subtransaktionen der ursprünglichen Transaktion betrachtet. Der Korrelator muß hierzu natürlich innerhalb der zu überwachenden Anwendung (z.B. als zusätzlicher Aufrufparameter) propagiert werden. Eine detailliertere Betrachtung der Korrelation von Subtransaktionen bei Verwendung der ARM API findet sich in Abschnitt .

Wie bereits erwähnt, ist mittlerweile Version 3.0 der ARM API bei der CMG verfügbar [#!john:99!#][#!smea99!#], allerdings noch nicht offiziell von der Open Group  standardisiert worden. Die wesentlichen Erweiterungen sind die Unterstützung von Java sowie die Möglichkeit, komplette Transaktionen an den Measurement Agent zu übermitteln. Die bisherigen Versionen der ARM API beschränkten sich auf die Programmiersprache C, gingen aber davon aus, daß C-Bibliotheken aus nahezu jeder anderen Programmiersprache aufrufbar sind. Aus Java heraus besteht diese Möglichkeit mit Hilfe des Java Native Interface (JNI). Da dies aber umständlich ist und Probleme bzgl. der Performanz bereitet und Java heutzutage immer weitere Verbreitung findet, wurde eine Java-Bibliothek definiert, die direkt in Java-Programme eingebunden und aus diesen heraus aufgerufen werden kann. Aufgrund der Objektorientiertheit von Java wurden einige Anpassungen erforderlich, die aber keine wesentlichen konzeptionellen Unterschiede darstellen. Wie schon erwähnt, ist darüber hinaus ein Aufruf eingeführt worden, der es Anwendungen gestattet, komplette Transaktionen an den Measurement Agent zu übermitteln. Dies wurde im Hinblick auf Anwendungen gemacht, die bereits über - nicht ARM-konforme - Instrumentierung verfügen und somit mit geringem Aufwand in die ARM-basierte Überwachung integriert werden können.

Trotz vieler Unzulänglichkeiten ist die ARM API die derzeit am weitesten verbreitete Methode für die generische Instrumentierung von Anwendungen zur Transaktionsüberwachung. Mehrere Hersteller von Managementsystemen (z.B. Hewlett Packard, Tivoli) bieten Measurement Agents an, die eine Überwachung von instrumentierten Anwendungen erlauben. Die ARM API stellt somit einen wichtigen ersten Schritt für die generische Managementinstrumentierung  verteilter Anwendungen dar. Aus diesen Gründen wurde sie im Rahmen der Studien zur vorliegenden Arbeit einer eingehenden Untersuchung unterzogen [#!hare99!#][#!fisc01!#][#!alde00!#][#!hojn99!#].

Dabei zeigte sich, daß zum heutigen Zeitpunkt keine instrumentierten Anwendungen verfügbar sind. Dies liegt insbesondere daran, daß trotz der sehr einfach gehaltenen Struktur der ARM API die Instrumentierung von Anwendungen erheblichen Aufwand verursacht. Insbesondere die nachträgliche Instrumentierung von Anwendungen ist - selbst wenn Zugang zum Source Code der Anwendung existiert - nur mit großer Mühe möglich. Auch bereitet die Korrelation von Subtransaktionen zu übergeordneten Transaktionen erhebliche Probleme. Dies liegt daran, daß der vom Measurement Agent gelieferte Korrelator innerhalb der zu überwachenden Anwendung propagiert werden muß, so daß er beim Start von Subtransaktionen übergeben werden kann. Dies bedeutet, daß z.B. bei nachträglicher Instrumentierung einer Anwendung die Aufrufparameter einzelner Funktionen der Anwendung verändert werden müssen, um die Propagierung der Korrelatoren zu ermöglichen. Dies macht sich insbesondere im Fall über mehrere Systeme verteilter Anwendungen negativ bemerkbar. Ein detaillierter Vergleich der ARM API mit der im folgenden Kapitel vorgeschlagenen Lösung findet sich in Abschnitt