autonomic computing - diagnosis - pinpoint summary

Autonomic ComputingSeminar (SS 2010)

Diagnosis

Über: Pinpoint: Problem Determination in Large, Dynamic Internet Services (Chen, Mike et al.)

Oliver Stadie

7. Juni 2010

Autonomic Computing - Über: Pinpoint 2

Gliederung● Problem & Ziel● Idee● Umsetzung● Bewertung● Einschränkungen & Ansätze


Problem & Ziel (1)● Problem: Riesige Systeme

● Ständige Änderung● Ständiges Wachstum● Fehler treten auf● Interagierende, verteilte Komponenten● Client Requests durchlaufen verschiedene

Komponenten● Ziel: Fehlerquellen finden ohne konkretes System

zu kennen oder anzupassen


Problem & Ziel (2)● Fehlerhafter

Request:● Problem:

Fehlerquelle könnte in Komponente K21, K22, K32 oder K33 liegen

● Ziel: Fehlerquelle idenzifizieren

K11 K21 K31

K12 K22 K32

K13 K23 K33

System


Idee (1)● Viele Requests: ● Einige Komponenten haben

öfter Fehler als andere● K22: 3 von 3 (100%)● K21: 1 von 2 (50%)● K12: 0 von 2 (0%)

● Zusammenspiel mehrerer Komponenten● K32+K33: 1 von 2 (50%)

● Sensitivität einstellbar

K11 K21 K31

K12 K22 K32

K13 K23 K33


Idee (2)

1.Client Request Traces

2.Failure Detection (extern & intern)

3.Data Clustering Analysis


Idee (3)● Client Request Traces

● Middleware instrumentieren → welche Komponenten für jeden Request benutzt?

● Failure Detection● Interne Failure Detection● Externe Failure Detection

● Data Clustering Analysis● Daten über benutzte Komponenten + Failure Daten →

fehlerhafte Komponenten & Interaktionen


Idee (4) - Client Request Tracing

K2 Pinpoint K3

<R1, ...><R2, ...><R2, K2>

<R1, ...><R2, ...><R2, K2><R2, K3>

R2PinpointR

Middleware Framework

Trace Log vorher

Trace Log nachher

PP


Idee (5) - Client Request Tracing● Aufzeichnen aller Komponenten die jeder Request benutzt

● Alternativ: Aufzeichnen aller Maschinen (grob) oder Dateien (fein)

● Weist ankommenden Requests ID zu● Instrumentierung der Middleware

● Vergleichbar: umschreiben der verwendeten Bibliotheken (z. B. Mathe-Bibliothek)

● Komponenten bleiben unberührt● Abhängig vom benutzen Framework


Idee (6) – Failure Detection● Unabhängig von Client Request Tracing● Aufzeichnen ob ein Request fehlerhaft ist

oder nicht● Interne Failures:

● Werden maskiert bevor sie User erreichen● Middleware wird instrumentiert

● External Failures● z.B. Maschinen-Crash, veraltete Links


Idee (9) – Failure Detection● Erfolgreicher Request

K2 PinpointK3

<R1, ...><R2, ...>

R3PPR


Fault Log vorher

Trace Log nachher

<R1, ...><R2, ...><R3, Success>


Idee (7) – Failure Detection● Beispiel interner maskierter Fehler:


R3

Idee (10) – Failure Detection● Interner Fehler ohne PP:

K3 K4


K1 K2

Km<<maskierend>>


R3

Idee (11) – Failure Detection● Interner Fehler mit PP:

K3 K4


K1 K2

Km<<maskierend>>

Trace Log nacher

<R1, ...><R2, ...><R3, Fail>

PP


Idee (8) – Failure Detection● Beispiel Externe Fehler:

● Error 404, Server-Timeouts, etc.● Url: http://www.google.de/ungueltigeUrl

http://www.google.de/ungueltigeUrl


R

Idee (12) – Failure Detection● Externer Fehler ohne PP:

K3 K4

K1 K2


Server

Response mit Fehler


R

Idee (13) – Failure Detection● Externer Fehler mit PP:

K3 K4

K1 K2


Server

Response mit Fehler

PP

Trace Log nacher

<R1, ...><R2, ...><R3, Fail>


Idee (14) – Data Analysis● Zusammenführen des Trace Logs und Failure

Logs. Bsp:

● Berechnen wie oft Komponenten (oder Kombinationen) an Fehlern beteiligt sind

● Im Paper nicht näher erklärt


Umsetzung (1)● Prototyp auf J2EE Middleware implementiert

● Client Request Tracing● Interne Fault Detection● (Fault Injektion)

● Network Sniffer● Externe Failure Detection, durch TCP- und HTTP-Check

der Responses● Analyzer

● Benutzt nicht näher erläuterte Algorithmen


Bewertung (1)● Experimenteller Aufbau:

● e-commerce service: J2EE PetStore demonstration application

● Fehler ins System injiziert– 4 Typen von Fehlern– Fehler Injektion getrennt von Fault Detector

● 133 Tests: Einzel-Komponenten-Fehler & Fehler durch Interaktion

● Client Emulator: generiert Requests


Bewertung (2)

Anteilgefundener fehlerhafter Paare

perfekt


Bewertung (3)● Vergleich mit 2 anderen einfachen Analyse-

Verfahren● Dedection & dependency checking● Pinpoint hat deutlich bessere Ergebnisse

● Performance Verlust durch Pinpoint:● Unter 10%● Analyse kann offline gemacht werden● Tracefiles: 2,5kB pro Request (100 Byte wenn

komprimiert)


Einschränkungen und → Ansätze● Komponenten die immer zusammenarbeiten nicht

unterscheidbar → synthetische Requests● Request-übergreifende Fehler nicht identifizierbar → Traces

auf „shared state“ (Datenbanken) ausweiten● „krankhafte Eingaben“ (z.B. fehlerhafte Cookies / defekter

Browser) nicht von Systemfehlern unterscheidbar → Die Requests selbst aufzeichnen

● „fail-stutter“ fault (Performance-Verlust durch maskierte Fehler) → Timing Informationen nutzen


Quellen● Pinpoint: Problem Determination in Large,

Dynamic Internet Services (Chen, Mike et al.)


Diskussion, Fragen, Kommentare

autonomic computing - diagnosis - pinpoint summary

Technology