Konfigurowanie alertów i powiadomień

Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. info

Warunki alertu określają konkretny kod stanu (np. 404/502/2xx/4xx/5xx), próg opóźnienia i kod błędu, których przekroczenie powoduje wyświetlanie alertów wizualnych w interfejsie i wysyłanie powiadomień różnymi kanałami, takimi jak e-mail, Slack, PagerDuty czy webhooki. Alerty możesz skonfigurować na poziomie środowiska, serwera proxy interfejsu API lub usługi docelowej albo regionu. Gdy alert zostanie aktywowany, otrzymasz powiadomienie za pomocą metody zdefiniowanej podczas dodawania alertów i powiadomień.

Możesz na przykład wywołać alert i wysłać powiadomienie do zespołu ds. operacji, gdy odsetek błędów 5xx przekroczy 23% w ciągu 5 minut w przypadku serwera proxy interfejsu API orders-prod wdrożonego w środowisku produkcyjnym.

Na ilustracji poniżej pokazano, jak alerty wyświetlają się w interfejsie:

Poniżej znajdziesz przykład powiadomienia e-mail, które możesz otrzymać, gdy zostanie wywołany alert.

W treści powiadomienia o alercie kliknij te linki, aby uzyskać więcej informacji:

• Kliknij Wyświetl szczegóły, aby zobaczyć więcej informacji, w tym ustawienia alertów i aktywność w przypadku każdego warunku w ciągu ostatniej godziny.
• Definicja alertu, aby wyświetlić definicję alertu.
• Historia alertów, aby wyświetlić więcej informacji o danym alercie.
• Wyświetl podręcznik, aby zobaczyć zalecane działania (jeśli są dostępne).
• Wyświetl raport API Analytics, aby wyświetlić raport niestandardowy dotyczący warunku alertu.

W sekcjach poniżej znajdziesz opis konfigurowania alertów i powiadomień oraz zarządzania nimi.

Informacje o typach alertów

Pierwsza wersja monitorowania interfejsu API umożliwiała tworzenie reguł opartych na wzorcach, które określały, kiedy należy wywołać alert na podstawie zestawu wstępnie zdefiniowanych warunków. Te typy alertów nazywane są alertami stałymi i były jedynym typem alertów obsługiwanym w pierwszej wersji usługi API Monitoring.

Możesz na przykład wywołać alert stały, gdy:

• [Odsetek błędów 5xx] [jest większy niż] [10%] przez [10 minut] w przypadku [celu mytarget1]
• [count of 2xx errors] [is less than] [50] for [5 minutes] in [region us-east-1]
• [Czas oczekiwania p90] [jest większy niż] [750 ms] przez [10 minut] na [serwerze proxy myproxy1]

Wersja beta raportowania zabezpieczeń z 13 listopada 2019 r. zawiera nowe typy alertów:

• alerty Anomalie (beta). Typ alertu, w którym Edge wykrywa problemy z ruchem i wydajnością, zamiast wymagać od Ciebie ich wcześniejszego określenia. Następnie możesz utworzyć alert dotyczący tych anomalii.
• alerty TLS Expiry (Beta); Typ alertu, który umożliwia wysyłanie powiadomień, gdy certyfikat TLS zbliża się do wygaśnięcia.

Monitorowanie interfejsu API obsługuje teraz wiele typów alertów, dlatego w oknie dialogowym Utwórz alert jest teraz widoczna opcja wyboru typu alertu:

Wyświetlanie ustawień alertów

Aby wyświetlić aktualnie zdefiniowane ustawienia alertów, w interfejsie Edge kliknij Analyze > Alert Rules (Analizuj > Reguły alertów).

Wyświetli się strona Alert, jak pokazano na ilustracji poniżej:

Jak widać na ilustracji, na stronie Alert możesz:

• Wyświetlanie podsumowania aktualnie zdefiniowanych ustawień alertów
• wyświetlać historię alertów, które zostały aktywowane;
• Dodawanie alertów i powiadomień
• Tworzenie raportu niestandardowego na podstawie alertu
• Włączanie i wyłączanie alertu
• Edytowanie alertu
• Usuwanie alertu
• Przeszukaj listę alertów w poszukiwaniu określonego ciągu znaków.

Wyświetlanie historii alertów, które zostały wywołane w organizacji

Aby wyświetlić historię alertów, które zostały wywołane w Twojej organizacji w ciągu ostatnich 24 godzin, w interfejsie Edge kliknij Analyze > Alert Rules (Analizuj > Reguły alertów), a potem kliknij kartę History (Historia).

Wyświetli się strona Historia alertów.

Kliknij nazwę alertu, aby wyświetlić jego szczegóły w panelu Analiza. Możesz filtrować listę, wyszukując całą nazwę alertu lub jej część.

Dodawanie alertów i powiadomień

Aby dodać alerty i powiadomienia:

1. W interfejsie Edge kliknij Analyze > Alert Rules (Analizuj > Reguły alertów).
2. Kliknij + Alert.
3. Podaj te ogólne informacje o alercie:

   Pole	Opis
   Nazwa alertu	Nazwa alertu. Użyj nazwy, która opisuje wyzwalacz i będzie dla Ciebie zrozumiała. Nazwa nie może mieć więcej niż 128 znaków.
   Typ alertu	Kliknij Stała. Więcej informacji o typach alertów znajdziesz w artykule Typy alertów.
   Opis	Opis alertu.
   Środowisko	Wybierz środowisko z menu.
   Stan	Przełącz, aby włączyć lub wyłączyć alert.

4. Zdefiniuj dane, próg i wymiar pierwszego warunku, który będzie aktywować alert.

   Pole warunku	Opis
   Wskaźnik	Wybierz jeden z tych rodzajów danych: Kod stanu: wybierz kod stanu z listy, np. 401, 404, 2xx, 4xx lub 5xx HTTP. Uwaga: Interfejs API umożliwia ustawienie szerszego zakresu kodów stanu. Za pomocą interfejsu API możesz określić dowolny kod stanu z zakresu 200–299, 400–599 oraz wartości wieloznaczne 2xx, 4xx lub 5xx. Zobacz Tworzenie alertu. W przypadku alertów dotyczących ograniczenia szybkości (kod stanu HTTP 429) ustaw w przypadku danych kod błędu Spike Arrest. Możesz użyć zasady AssignMessage, aby zmienić kod odpowiedzi HTTP, który może być błędem serwera proxy lub błędem docelowym. Usługa API Monitoring ignoruje wszystkie przepisane kody i rejestruje rzeczywiste kody odpowiedzi HTTP. Opóźnienie: wybierz wartość opóźnienia z listy. Są to: p50 (50 centyl), p90 (90 centyl), p95 (95 centyl) lub p99 (99 centyl). Na przykład wybierz p95, aby skonfigurować alert, który będzie wywoływany, gdy czas oczekiwania na odpowiedź dla 95 centyla będzie większy niż próg ustawiony poniżej. Kod błędu: wybierz z listy kategorię, podkategorię i kod błędu. Możesz też wybrać jedną z tych opcji w kategorii lub podkategorii: Wszystkie – łączna suma wszystkich kodów błędów w tej kategorii lub podkategorii musi spełniać kryteria danych. Dowolny – pojedynczy kod błędu w tej kategorii lub podkategorii musi spełniać kryteria rodzaju danych. Więcej informacji znajdziesz w dokumentacji kodów błędów.
   Próg	Skonfiguruj próg dla wybranego wskaźnika: Kod stanu: ustaw próg jako odsetek, liczbę lub transakcje na sekundę (TPS) w czasie. Czas oczekiwania: wybierz próg jako łączny lub docelowy czas oczekiwania (ms) w określonym czasie. W tym przypadku alert jest wywoływany, jeśli określony centyl zaobserwowanego czasu oczekiwania, który jest aktualizowany co minutę, jeśli występuje ruch, przekracza warunek progu w okresie obejmującym określony czas trwania. Oznacza to, że warunek progu nie jest agregowany w całym okresie. Kod błędu: ustaw próg jako odsetek, liczbę lub transakcje na sekundę (TPS) w czasie.
   Wymiar	Kliknij + Dodaj wymiar i określ szczegóły wymiaru, dla którego chcesz uzyskać wyniki, w tym serwer proxy interfejsu API, usługę docelową lub aplikację dewelopera oraz region. Jeśli ustawisz określony wymiar na: Wszystkie – wszystkie elementy w wymiarze muszą spełniać kryteria danych. W przypadku rodzaju danych Czas oczekiwania nie możesz wybrać opcji Wszystkie. Dowolny – dotyczy tylko regionu. Jednostka w wymiarze musi spełniać kryteria danych w dowolnym regionie. Uwaga: w przypadku serwerów proxy interfejsu API lub usług docelowych wybierz kolekcję, aby obsługiwać funkcję Dowolny. Kolekcje – wybierz kolekcję z listy, aby określić zestaw proxy interfejsów API lub usług docelowych. W tym przypadku każde wystąpienie w kolekcji musi spełniać kryteria. Jeśli ustawisz wymiar na Cel, możesz wybrać usługę docelową lub usługę określoną przez zasadę ServiceCallout. Cel zasady ServiceCallout jest wyświetlany jako wartość z prefiksem „sc://”. Na przykład „sc://my.endpoint.net”.

5. Kliknij Pokaż dane dotyczące stanu, aby wyświetlić najnowsze dane dotyczące stanu z ostatniej godziny.
   Gdy współczynnik błędów na wykresie przekroczy próg warunku alertu, wyświetli się na czerwono.
   

   Aby ukryć dane, kliknij Ukryj dane o stanie.

6. Aby dodać kolejne warunki, kliknij + Dodaj warunek i powtórz kroki 4 i 5.

   Uwaga: jeśli określisz kilka warunków, alert zostanie wyzwolony, gdy wszystkie zostaną spełnione.

7. Jeśli chcesz utworzyć raport niestandardowy na podstawie skonfigurowanych warunków alertu, kliknij Utwórz raport analityczny interfejsu API na podstawie warunków alertu. Ta opcja jest wyszarzona, jeśli nie jesteś administratorem organizacji.

   Więcej informacji znajdziesz w artykule Tworzenie raportu niestandardowego na podstawie alertu.

   Uwaga: po zapisaniu alertu możesz zmodyfikować raport niestandardowy, jak opisano w artykule Zarządzanie raportami niestandardowymi.

8. Aby dodać powiadomienie o alercie, kliknij + Powiadomienie.

   Szczegóły powiadomienia	Opis
   Kanał	Wybierz kanał powiadomień, którego chcesz używać, i określ miejsce docelowe: e-mail, Slack, PagerDuty lub webhook.
   Miejsce docelowe	Określ miejsce docelowe na podstawie wybranego typu kanału: E-mail – adres e-mail, np. joe@company.com Slack – adres URL kanału na Slacku, np. https://hooks.slack.com/services/T00000000/B00000000/XXXXX PagerDuty – kod PagerDuty, np. abcd1234efgh56789 Webhook – adres URL webhooka, np. https://apigee.com/test-webhook. Opis obiektu wysyłanego na adres URL znajdziesz w artykule Format obiektu webhooka. Przekaż wszelkie informacje o danych logowania w adresie URL webhooka. Na przykład: https://apigee.com/test-webhook?auth_token=1234_abcd. Możesz określić adres URL punktu końcowego, który może analizować obiekt webhooka w celu jego zmodyfikowania lub przetworzenia. Możesz na przykład określić adres URL interfejsu API, np. interfejsu Edge API, lub dowolnego innego punktu końcowego, który może przetwarzać obiekt. Uwaga: w przypadku każdego powiadomienia możesz określić tylko jedno miejsce docelowe. Aby określić wiele miejsc docelowych dla tego samego typu kanału, dodaj dodatkowe powiadomienia.

9. Aby dodać kolejne powiadomienia, powtórz krok 8.
10. Jeśli dodasz powiadomienie, ustaw te pola:

    Pole	Opis
    Scenariusz	(Opcjonalnie) Pole tekstowe w formie swobodnej wypowiedzi, w którym możesz podać krótki opis zalecanych działań, które należy podjąć, gdy alerty zostaną wywołane. Możesz też podać link do wewnętrznej wiki lub strony społeczności, na której znajdziesz sprawdzone metody. Informacje w tym polu zostaną dołączone do powiadomienia. Tekst w tym polu nie może przekraczać 1500 znaków.
    Ograniczenie	Częstotliwość wysyłania powiadomień. Wybierz wartość z listy. Prawidłowe wartości to: 15 minut, 30 minut i 1 godzina.

11. Kliknij Zapisz.

Format obiektu webhooka

{
  "alertInstanceId": "event-id",
  "alertName": "name",
  "org": "org-name",
  "description": "alert-description",
  "alertId": "alert-id",
  "alertTime": "alert-timestamp",
  "thresholdViolations":{"Count0": "Duration=threshold-duration Region=region Status Code=2xx Proxy=proxy Violation=violation-description"
  },
  "thresholdViolationsFormatted": [
    {
      "metric": "count",
      "duration": "threshold-duration",
      "proxy": "proxy",
      "region": "region",
      "statusCode": "2xx",
      "violation": "violation-description"
    }
  ],
  "playbook": "playbook-link"
}

Właściwości thresholdViolations i thresholdViolationsFormatted zawierają szczegółowe informacje o alercie. Właściwość thresholdViolations zawiera pojedynczy ciąg znaków ze szczegółowymi informacjami, a thresholdViolationsFormatted zawiera obiekt opisujący alert. Zwykle używasz usługi thresholdViolationsFormatted, ponieważ jest ona łatwiejsza do dekodowania.

Powyższy przykład pokazuje zawartość tych właściwości w przypadku stałego alertu, gdy skonfigurujesz go tak, aby był wywoływany na podstawie kodu stanu HTTP 2xx, co jest wskazane przez właściwość statusCode.

Zawartość tych właściwości zależy od typu alertu, np. stałego lub dotyczącego anomalii, oraz od konkretnej konfiguracji alertu. Jeśli na przykład utworzysz stały alert na podstawie kodu błędu, właściwość thresholdViolationsFormatted będzie zawierać właściwość faultCode zamiast właściwości statusCode.

W tabeli poniżej znajdziesz wszystkie możliwe właściwości thresholdViolationsFormattedw przypadku różnych typów alertów:

metric, proxy, target, developerApp,
region, statusCode, faultCodeCategory, faultCodeSubCategory,
faultCode, percentile, comparisonType, thresholdValue,
triggerValue, duration, violation

metric, proxy, target, developerApp,
region, comparisonType, thresholdValue, triggerValue,
duration, violation

metric, proxy, target, region,
statusCode, faultCode, percentile, sensitivity,
violation

envName, certificateName, thresholdValue, violation

Tworzenie raportu niestandardowego na podstawie alertu

Aby utworzyć raport niestandardowy na podstawie alertu:

1. Podczas tworzenia alertu kliknij Utwórz raporty analityczne interfejsu API na podstawie warunków alertu, jak opisano w artykule Dodawanie alertów i powiadomień.

   Po zapisaniu alertu w interfejsie pojawi się ten komunikat:

   Alert alertName saved successfully. To customize the report generated, click here.

   Kliknij wiadomość, aby otworzyć raport w nowej karcie z wstępnie wypełnionymi odpowiednimi polami. Domyślna nazwa raportu niestandardowego to:API Monitoring Generated alertName

2. Edytuj raport niestandardowy i kliknij Zapisz.
3. Kliknij nazwę raportu na liście i wygeneruj raport niestandardowy.

Aby zarządzać raportem niestandardowym utworzonym na podstawie warunków alertu:

1. W interfejsie Edge kliknij Analyze > Alert Rules (Analizuj > Reguły alertów).
2. Kliknij kartę Ustawienia.
3. W kolumnie Raporty kliknij raport niestandardowy powiązany z alertem, którym chcesz zarządzać.

   Strona raportu niestandardowego wyświetli się w nowej karcie. Jeśli kolumna Raporty jest pusta, oznacza to, że nie utworzono jeszcze raportu niestandardowego. W razie potrzeby możesz edytować alert, aby dodać raport niestandardowy.

4. Edytuj raport niestandardowy i kliknij Zapisz.
5. Kliknij nazwę raportu na liście i wygeneruj raport niestandardowy.

Włączanie i wyłączanie alertu

Aby włączyć lub wyłączyć alert:

1. W interfejsie Edge kliknij Analyze > Alert Rules (Analizuj > Reguły alertów).
2. Kliknij przełącznik w kolumnie Stan obok alertu, który chcesz włączyć lub wyłączyć.
   

Edycja alertu

Aby edytować alert:

1. W interfejsie Edge kliknij Analyze > Alert Rules (Analizuj > Reguły alertów).
2. Kliknij nazwę alertu, który chcesz edytować.
3. W razie potrzeby zmień alert.
4. Kliknij Zapisz.

Usuwanie alertu

Aby usunąć alert:

1. W interfejsie Edge kliknij Analyze > Alert Rules (Analizuj > Reguły alertów).
2. Umieść kursor nad alertem, który chcesz usunąć, i w menu czynności kliknij .

Sugerowane alerty

Apigee zaleca skonfigurowanie tych alertów, aby otrzymywać powiadomienia o typach problemów. Niektóre z tych alertów dotyczą konkretnych wdrożeń interfejsów API i są przydatne tylko w określonych sytuacjach. Na przykład kilka alertów pokazanych poniżej ma zastosowanie tylko wtedy, gdy używasz zasady ServiceCallout lub zasady JavaCallout.

Konfigurowanie alertu o kodzie stanu 5xx dla proxy interfejsu API

Poniżej znajdziesz przykład konfiguracji alertu w interfejsie, który będzie się włączać, gdy transakcje na sekundę (TPS) kodów stanu 5xx w przypadku serwera proxy interfejsu API hoteli przekroczą 100 w ciągu 10 minut w dowolnym regionie. Więcej informacji znajdziesz w artykule Dodawanie alertów i powiadomień.

Informacje o korzystaniu z interfejsu API znajdziesz w artykule Konfigurowanie alertu o kodzie stanu 5xx dla serwera proxy za pomocą interfejsu API.

Konfigurowanie alertu o czasie oczekiwania (95 centyl) dla proxy interfejsu API

Poniżej znajdziesz przykład konfiguracji alertu w interfejsie, który jest wywoływany, gdy całkowity czas oczekiwania na odpowiedź dla 95 centyla jest większy niż 100 ms przez 5 minut w przypadku serwera proxy interfejsu API hoteli w dowolnym regionie. Więcej informacji znajdziesz w artykule Dodawanie alertów i powiadomień.

Informacje o korzystaniu z interfejsu API znajdziesz w artykule Konfigurowanie alertu o opóźnieniu P95 dla proxy interfejsu API za pomocą interfejsu API.

Skonfiguruj alert 404 (nie znaleziono aplikacji) dla wszystkich serwerów proxy interfejsu API

Poniżej znajdziesz przykład konfiguracji alertu w interfejsie, który jest wywoływany, gdy odsetek kodów stanu 404 dla wszystkich serwerów proxy interfejsu API przekroczy 5% przez 5 minut w dowolnym regionie. Więcej informacji znajdziesz w artykule Dodawanie alertów i powiadomień.

Informacje o korzystaniu z interfejsu API znajdziesz w artykule Konfigurowanie alertu 404 (Application Not Found) dla wszystkich proxy interfejsów API za pomocą interfejsu API.

Konfigurowanie alertu dotyczącego liczby proxy interfejsu API

Poniżej znajdziesz przykład konfiguracji alertu w interfejsie, który będzie się włączać, gdy liczba kodów 5xx w przypadku interfejsów API przekroczy 200 w ciągu 5 minut w dowolnym regionie. W tym przykładzie interfejsy API są rejestrowane w kolekcji Krytyczne proxy interfejsów API. Aby dowiedzieć się więcej, zobacz:

• Dodawanie alertów i powiadomień
• Zarządzanie kolekcjami

Informacje o korzystaniu z interfejsu API znajdziesz w artykule Konfigurowanie alertu o liczbie proxy interfejsu API w przypadku interfejsów API za pomocą interfejsu API.

Konfigurowanie alertu o odsetku błędów w przypadku usług docelowych

Poniżej znajdziesz przykład konfiguracji alertu w interfejsie, który będzie wywoływany, gdy odsetek kodów 500 w przypadku usług docelowych przekroczy 10% w ciągu 1 godziny w dowolnym regionie. W tym przykładzie usługi docelowe są rejestrowane w kolekcji Krytyczne środowiska docelowe. Aby dowiedzieć się więcej, zobacz:

• Dodawanie alertów i powiadomień
• Zarządzanie kolekcjami

Więcej informacji o korzystaniu z interfejsu API znajdziesz w artykule Konfigurowanie alertu o odsetku błędów w przypadku usług docelowych za pomocą interfejsu API.

Konfigurowanie alertu o współczynniku błędów w przypadku zasady ServiceCallout

Poniżej znajdziesz przykład konfiguracji alertu w interfejsie, który jest wywoływany, gdy odsetek kodów 500 w usłudze określonej przez zasadę ServiceCallout przekroczy 10% w ciągu 1 godziny w dowolnym regionie. Aby dowiedzieć się więcej, zobacz:

• Dodawanie alertów i powiadomień

Informacje o korzystaniu z interfejsu API znajdziesz w artykule Konfigurowanie alertu o odsetku błędów w przypadku zasady wywołania usługi za pomocą interfejsu API.

Konfigurowanie alertu o kodzie błędu zasady

Poniżej znajdziesz przykład konfiguracji alertu w interfejsie, który jest wywoływany, gdy liczba kodów błędów JWT AlgorithmMismatch w przypadku zasad VerifyJWT przekracza 5 w ciągu 10 minut dla wszystkich interfejsów API. Aby dowiedzieć się więcej, zobacz:

• Dodawanie alertów i powiadomień
• Zarządzanie kolekcjami

Więcej informacji o korzystaniu z interfejsu API znajdziesz w artykule Konfigurowanie alertu o kodzie błędu zasad za pomocą interfejsu API.