Ćwiczenie — definiowanie stanu kondycji, metryk i progów
W tym ćwiczeniu kontynuujemy utworzoną wcześniej strukturę modelu kondycji. Twoim zadaniem jest określenie ilościowych stanów kondycji poszczególnych składników dla przykładowej aplikacji.
W strukturze modelu kondycji zacznij od oceny warstw zaczynających się od góry przy użyciu przepływów użytkownika i przejdź do niższych warstw.
Stan kondycji przepływu użytkownika
Do tej pory zidentyfikowaliśmy dwa przepływy użytkowników: Wyświetlanie listy elementów wykazu i Dodawanie komentarza. Aby określić stany kondycji dla każdego przepływu, zadaj pytania, takie jak:
- Kiedy przepływ użytkownika jest uznawany za w dobrej kondycji?
- Czy może działać w stanie obniżonej wydajności?
Na podstawie wymagań implementacji i funkcjonalności zidentyfikuj składniki aplikacji, które uczestniczą w przepływie użytkownika. Składniki są opisane w sekcji Przykładowe składniki architektury.
| Przepływ użytkownika | Składniki |
|---|---|
| Wyświetlanie listy elementów wykazu | Wewnętrzna aplikacja internetowa frontonu, interfejs API wykazu |
| Dodaj komentarz | Wewnętrzna aplikacja internetowa frontonu, interfejs API wykazu, procesor w tle |
Jeśli którykolwiek z tych składników stanie się w złej kondycji, oczekuje się, że przepływ użytkownika stanie się w złej kondycji.
Uwaga
Niektóre aplikacje mogą działać w specjalnym trybie obniżonej wydajności . Jeśli na przykład firma Contoso Shoes implementuje buforowanie przeglądarki lokalnej, pracownicy korzystający z aplikacji internetowej mogą tworzyć komentarze, ale nie można wysyłać komentarzy, a widok klienta nie zostanie zaktualizowany, dopóki interfejs API wykazu nie stanie się w dobrej kondycji, co przeglądarka może stale sprawdzać.
Stan kondycji składnika aplikacji
Określanie metryk, które przyczyniają się do stanu kondycji składnika. W tym kroku musisz znać funkcjonalność składnika. Zadaj pytania, takie jak:
- Jaki czas przetwarzania interfejsu API jest akceptowalny, aby zachować dobre środowisko użytkownika?
- Czy występują jakieś oczekiwane błędy? Jaka jest "normalna" szybkość błędów?
- Jaki jest "normalny" czas przetwarzania? Co to znaczy, jeśli czas przetwarzania jest wyższy niż zwykle?
- Co się stanie z operacjami zapisu, jeśli usługa Azure Cosmos DB nie jest osiągalna?
Te pytania powinny prowadzić do konkretnych i mierzalnych progów kluczowych metryk. Możesz na przykład rozważyć te wartości progowe dla składnika interfejsu API wykazu.
| Metryki i próg | Kondycja |
|---|---|
| Czas < odpowiedzi 150 ms Liczba nieudanych żądań < 10 | Dobra kondycja |
| Czas < odpowiedzi 300 ms Liczba nieudanych żądań < 50 | Obniżona wydajność |
| Czas > odpowiedzi 300 ms Liczba nieudanych żądań > 50 | Nieprawidłowy |
Wartości można uzyskać z rozwiązania do monitorowania aplikacji, takiego jak Application Insights.
Stan kondycji zasobu platformy Azure
Stany kondycji usługi platformy Azure są oparte na określonych zasobach. Na przykład usługa Azure Cosmos DB raportuje wykorzystanie jednostek transakcji bazy danych (DTU), a usługi aplikacja systemu Azure zawierają informacje o wykorzystaniu procesora CPU.
Aby uzyskać informacje o metrykach według typu zasobu, zobacz Obsługiwane metryki w usłudze Azure Monitor.
Stany kondycji i progi
Po ocenie wszystkich warstw aplikacji powinna zostać wyświetlona lista składników i ich definicji stanu kondycji, które wyglądają podobnie do tego przykładu.
| Składnik | Wskaźnik/metryka | Dobra kondycja | Obniżona wydajność | Nieprawidłowy |
|---|---|---|---|---|
| Wyświetlanie listy elementów wykazu — przepływ użytkownika | Podstawowy stan kondycji | Fronton w dobrej kondycji i interfejs API wykazu w dobrej kondycji | ||
| Dodawanie przepływu użytkownika komentarza | Podstawowy stan kondycji | Fronton w dobrej kondycji, interfejs API wykazu w dobrej kondycji i procesor w tle | ||
| Aplikacja internetowa frontonu | Liczba odpowiedzi HTTP innych niż 20x/min | 0 | 1-10 | > 10 |
| Interfejs API wykazu | Liczba wyjątków na sekundę | < 10 | 10-50 | > 10 |
| Średni czas przetwarzania (ms) | < 150 | 150-500 | > 500 | |
| Procesor w tle | Średni czas w kolejce (ms) | < 200 | 200-1,000 | > 1,000 |
| Średni czas przetwarzania (ms) | < 100 | 100-200 | > 200 | |
| Liczba niepowodzeń | < 3 | 3-10 | > 10 | |
| Azure Cosmos DB | Wykorzystanie jednostek DTU | < 70% | 70%-90% | > 90% |
| Azure Key Vault | Liczba niepowodzeń | < 3 | 3-10 | > 10 |
| Azure Event Hubs | Przetwarzanie długości listy prac (komunikaty wychodzące/przychodzące) | < 3 | 3-20 | > 20 |
| Azure Blob Storage | Średnie opóźnienie (ms) | < 100 | 100-200 | > 200 |
W tym przykładzie tolerancja błędów dla aplikacji internetowej frontonu i interfejsu API wykazu jest inna. Ta różnica odnosi się do wiedzy technicznej aplikacji. Wszystkie błędy frontonu powinny być obsługiwane po stronie klienta, więc istnieje próg zerowy. Jednak w warstwie interfejsu API 10 wyjątków może uwzględniać błędy spowodowane przez użytkownika. Na przykład błędy, takie jak 404 — Nie znaleziono , nie muszą wskazywać problemu z kondycją.