Konfigurowanie alertów i powiadomień

Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje

Warunki alertów definiują określony kod stanu (np. 404/502/2xx/4xx/5xx), czas oczekiwania oraz progi kodów błędów, które po przekroczeniu limitu powodują wyświetlanie alertów wizualnych w interfejsie i wysyłanie powiadomień za pomocą różnych kanałów, takich jak e-mail, Slack, Pagerduty lub webhooki. Alerty możesz skonfigurować na poziomie środowiska, serwera proxy interfejsu API, usługi docelowej lub regionu. Po uruchomieniu alertu otrzymasz powiadomienie zgodnie z metodą określoną podczas dodawania alertów i powiadomień.

Możesz na przykład aktywować alert i wysłać powiadomienie do zespołu operacyjnego, gdy odsetek błędów 5xx przekroczy 23% przez okres 5 minut dla serwera proxy interfejsu order-prod API wdrożonego w środowisku produkcyjnym.

Ten rysunek przedstawia sposób wyświetlania alertów w interfejsie:

Poniżej znajdziesz przykład e-maila z powiadomieniem, który możesz otrzymać po uruchomieniu alertu.

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

• Wyświetl szczegóły, aby zobaczyć więcej informacji, w tym ustawienia alertów i aktywność związaną z poszczególnymi warunkami w ciągu ostatniej godziny.
• Definicja alertu, aby wyświetlić definicję alertu.
• Historia alertów – aby wyświetlić więcej informacji o konkretnym alercie.
• Wyświetl scenariusz, aby zobaczyć zalecane działania (jeśli są dostępne).
• Wyświetl raport interfejsu API Analytics, aby wyświetlić raport niestandardowy dotyczący warunku alertu.

W kolejnych sekcjach opisano, jak skonfigurować alerty i powiadomienia oraz nimi zarządzać.

Typy alertów

Pierwsza wersja monitorowania interfejsów API pozwala tworzyć reguły oparte na wzorcach, które określają, kiedy alert ma być wywoływany na podstawie zbioru wstępnie zdefiniowanych warunków. Te typy alertów są nazywane alertami poprawionymi i były jedynym rodzajem alertów obsługiwanych w pierwszej wersji usługi API Monitoring.

Możesz na przykład wysłać alert naprawiony, gdy:

• [współczynnik błędów 5xx] [wynosi więcej niż] [10%] w przypadku [10 minut] z [cel_mojego_celu1]
• [liczba błędów 2xx] [jest mniejsza niż] [50] w przypadku [5 minut] w [region us-east-1]
• [czas oczekiwania p90] [większy niż] [750 ms] przez [10 minut] w [proxy myproxy1]

Wersja beta raportowania zabezpieczeń 19.11.13 zawiera nowe typy alertów:

• Alerty dotyczące całkowitego ruchu (beta). Typ alertu, który pozwala generować alert, gdy w danym okresie natężenie ruchu zmieni się o określoną wartość procentową.
• Alerty dotyczące anomalii (beta). Typ alertu, w którym Edge wykrywa problemy z ruchem i wydajnością, a nie trzeba ich wstępnie określać. Możesz potem zgłosić alert o tych anomaliach.
• Alerty o wygaśnięciu TLS (beta). Typ alertu, który umożliwia wysyłanie powiadomień, gdy certyfikat TLS dobiega końca.

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

Wyświetl ustawienia alertów

Aby wyświetlić obecnie zdefiniowane ustawienia alertów, kliknij Analiza > Reguły alertów w interfejsie Edge.

Zostanie wyświetlona strona Alert, tak jak pokazano na tej ilustracji:

Jak zaznaczyliśmy na ilustracji, na stronie Alert możesz:

• Wyświetl podsumowanie ustawień alertów, które są obecnie zdefiniowane
• wyświetlać historię alertów,
• Dodawanie alertów i powiadomień
• Tworzenie raportu niestandardowego na podstawie alertu
• Włączanie i wyłączanie alertu
• Edytowanie alertu
• Usuwanie alertu
• Wyszukiwanie na liście alertów dotyczących konkretnego ciągu

Wyświetlanie historii alertów, które zostały aktywowane dla Twojej organizacji

Aby wyświetlić historię alertów, które zostały aktywowane dla Twojej organizacji w ciągu ostatnich 24 godzin, kliknij Analizuj > Reguły alertów w interfejsie użytkownika Edge i kliknij kartę Historia.

Wyświetli się strona Historia alertów.

Kliknij nazwę alertu, aby wyświetlić jego szczegóły w panelu Zbadaj. Listę możesz filtrować, wyszukując całość lub część nazwy alertu.

Dodawanie alertów i powiadomień

Aby dodać alerty i powiadomienia:

1. Kliknij Analiza > Reguły alertów w interfejsie Edge.
2. Kliknij +Alert.
3. Wpisz te ogólne informacje o alercie:

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

4. Określ dane, próg i wymiar pierwszego warunku, który będzie wyzwalał alert.

   Pole warunku	Opis
   Dane	Wybierz jeden z tych danych: Kod stanu: wybierz z listy kod stanu, np. 401, 404, 2xx, 4xx lub 5xx HTTP. Uwaga: Interfejs API umożliwia ustawienie szerszego zakresu kodów stanu. Za pomocą interfejsu API podaj dowolny kod stanu z zakresu 200–299, 400–599 oraz wartości symboli wieloznacznych 2xx, 4xx lub 5xx. Zobacz Tworzenie alertu. W przypadku alertów o ograniczaniu liczby żądań (kod stanu HTTP 429) ustaw wartość na Kod błędu Arrest Speke. Do przepisania kodu odpowiedzi HTTP z błędu serwera proxy lub z błędu docelowego możesz użyć zasady AssignMessage. API Monitoring ignoruje wszystkie przepisane kody i rejestruje rzeczywiste kody odpowiedzi HTTP. Czas oczekiwania: wybierz z listy wartość czasu oczekiwania. W szczególności: p50 (50. percentyl), p90 (90. percentyl), p95 (95. percentyl) lub p99 (99 centyl). Możesz na przykład wybrać kod p95, aby skonfigurować alert, który będzie wyzwalany, gdy czas oczekiwania na odpowiedź 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 liczba wszystkich kodów błędów w tej kategorii/podkategorii musi spełniać kryteria danych. Dowolna – kod pojedynczego błędu w tej kategorii/podkategorii musi spełniać kryteria danych. Więcej informacji znajdziesz w informacjach o kodach błędów. Łączny ruch (beta): wybierz zwiększenie lub zmniejszenie ruchu. Więcej informacji znajdziesz w artykule Alerty o natężeniu ruchu (beta).
   Próg	Skonfiguruj próg dla wybranego wskaźnika: Kod stanu: ustaw próg w postaci stopy procentowej, liczby transakcji lub liczby transakcji na sekundę (TPS). Czas oczekiwania: wybierz próg jako łączny lub docelowy czas oczekiwania (ms) w czasie. W takim przypadku alert jest wywoływany, gdy określony centyl zaobserwowanego czasu oczekiwania (który jest aktualizowany co minutę w przypadku natężenia ruchu), przekracza warunek progowy dotyczący przedziału czasu obejmującego określony czas. Oznacza to, że warunek progowy nie jest agregowany w całym okresie. Kod błędu: ustaw próg jako stopę procentową, liczbę lub liczbę transakcji na sekundę (TPS).
   Wymiar	Kliknij + Dodaj wymiar i określ szczegóły wymiaru, dla których mają zostać zwrócone wyniki, w tym serwer proxy interfejsu API, usługa docelowa, aplikacja dewelopera i region. Jeśli ustawisz konkretny wymiar na: Wszystkie – wszystkie elementy w wymiarze muszą spełniać kryteria danych. Nie możesz wybrać opcji Wszystkie dla danych typu Czas oczekiwania. Dowolny – dotyczy tylko regionu. Encja w wymiarze musi spełniać kryteria danych dla dowolnego regionu. Uwaga: w przypadku serwerów proxy interfejsu API lub usług docelowych wybierz kolekcję, która obsługuje dowolne funkcje. Kolekcje – wybierz z listy kolekcję, aby określić zestaw serwerów proxy interfejsu API lub usług docelowych. W takim przypadku każdy element w kolekcji musi spełniać kryteria. Jeśli ustawisz wymiar na Cel, możesz wybrać usługę docelową lub usługę określoną przez zasady dotyczące wywołań ServiceCallout. Cel zasady ServiceCallout jest wyświetlany jako wartość poprzedzona ciągiem „sc://”. Na przykład „sc://my.endpoint.net”.

5. Kliknij Pokaż dane dotyczące warunku, aby wyświetlić najnowsze dane dotyczące warunku z ostatniej godziny.
   Odsetek błędów na wykresie wyświetla się na czerwono, gdy przekracza próg warunku alertu.
   

   Aby ukryć dane, kliknij Ukryj dane warunku.

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

   Uwaga: jeśli określisz wiele warunków, alert zostanie aktywowany po spełnieniu wszystkich ich warunków.

7. Kliknij Utwórz raporty analityczne dotyczące interfejsu API na podstawie warunków alertu, jeśli chcesz utworzyć raport niestandardowy na podstawie skonfigurowanych warunków alertu. Jeśli nie jesteś administratorem organizacji, ta opcja jest nieaktywna.

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

   Uwaga: po zapisaniu alertu możesz zmodyfikować raport niestandardowy zgodnie z opisem w sekcji Zarządzanie raportami niestandardowymi.

8. Kliknij + Powiadomienie, aby dodać powiadomienie o alercie.

   Szczegóły powiadomienia	Opis
   Kanał	Wybierz kanał powiadomień, którego chcesz używać, i podaj miejsce docelowe: Email, Slack, PagerDuty lub Webhook.
   Miejsce docelowe	Określ miejsce docelowe na podstawie wybranego typu kanału: E-mail – adres e-mail, taki jak joe@company.com Slack – adres URL kanału Slacka, 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 sekcji Format obiektu webhooka. Przekaż dane logowania w adresie URL webhooka. Na przykład: https://apigee.com/test-webhook?auth_token=1234_abcd. Możesz podać adres URL punktu końcowego, który może przeanalizować obiekt webhooka, aby go zmodyfikować lub przetworzyć. Możesz na przykład podać adres URL interfejsu API, takiego jak Edge API, lub dowolnego innego punktu końcowego, który może przetworzyć obiekt. Uwaga: dla każdego powiadomienia możesz określić tylko jedno miejsce docelowe. Aby określić kilka miejsc docelowych dla tego samego typu kanału, dodaj więcej powiadomień.

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

    Field	Opis
    Poradnik	(Opcjonalnie) Pole tekstowe zawierające krótki opis zalecanych działań związanych z rozwiązywaniem alertów po ich uruchomieniu. Możesz też podać link do wewnętrznej strony wiki lub strony społeczności, na której znajdziesz sprawdzone metody. Informacje z tego pola zostaną umieszczone w powiadomieniu. Zawartość tego pola nie może przekraczać 1500 znaków.
    Ograniczaj	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 jeden ciąg znaków ze szczegółami, a thresholdViolationsFormatted zawiera obiekt opisujący alert. Zwykle używasz właściwości thresholdViolationsFormatted, ponieważ jest ona prostsza do dekodowania.

Powyższy przykład przedstawia zawartość tych właściwości w przypadku alertu stałego, gdy konfigurujesz dane alertu tak, aby uruchamiały się na podstawie kodu stanu HTTP 2xx, co wskazuje właściwość statusCode.

Zawartość tych właściwości zależy od typu alertu (np. naprawiony lub anomalia) oraz jego konkretnej konfiguracji. Jeśli np. utworzysz stały alert na podstawie kodu błędu, właściwość thresholdViolationsFormatted będzie zawierać właściwość faultCode, a nie statusCode.

W tabeli poniżej znajdziesz wszystkie możliwe właściwości właściwości thresholdViolationsFormatted w 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 Tworzenie raportów analitycznych na podstawie warunków alertu zgodnie z opisem w artykule Dodawanie alertów i powiadomień.

   Gdy zapiszesz alert, w interfejsie wyświetli się ten komunikat:

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

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

2. Wprowadź zmiany w raporcie niestandardowym 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. Kliknij Analiza > Reguły alertów w interfejsie Edge.
2. Kliknij kartę Ustawienia.
3. W kolumnie Raporty kliknij raport niestandardowy powiązany z alertem, którym chcesz zarządzać.

   Strona raportu niestandardowego pojawi się w nowej karcie. Jeśli kolumna Raporty jest pusta, oznacza to, że raport niestandardowy nie został jeszcze utworzony. W razie potrzeby możesz zmodyfikować alert, aby dodać raport niestandardowy.

4. Wprowadź zmiany w raporcie niestandardowym 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. Kliknij Analiza > Reguły alertów w interfejsie Edge.
2. W kolumnie Stan kliknij przełącznik obok alertu, który chcesz włączyć lub wyłączyć.
   

Edycja alertu

Aby edytować alert:

1. Kliknij Analiza > Reguły alertów w interfejsie Edge.
2. Kliknij nazwę alertu, który chcesz edytować.
3. Zmodyfikuj alert.
4. Kliknij Zapisz.

Usuwanie alertu

Aby usunąć alert:

1. Kliknij Analiza > Reguły alertów w interfejsie Edge.
2. Najedź kursorem na alert, który chcesz usunąć, i kliknij w menu działań.

Sugerowane alerty

Apigee zaleca skonfigurowanie poniższych alertów, aby otrzymywać powiadomienia o typowych problemach. Niektóre z tych alertów są związane z implementacją interfejsów API i są przydatne tylko w określonych sytuacjach. Na przykład kilka widocznych poniżej alertów dotyczy tylko zasad dotyczących ServiceCallout lub zasad dotyczących języka JavaScript.

Konfigurowanie alertu z kodem stanu 5xx dla serwera proxy interfejsu API

Poniżej znajdziesz przykład konfigurowania alertu za pomocą interfejsu użytkownika, który jest wyzwalany, gdy liczba transakcji na sekundę (TPS) o kodach stanu 5xx dla serwera proxy interfejsu Hotel API przekracza 100 przez 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 z kodem stanu 5xx dla serwera proxy przy użyciu interfejsu API.

Konfigurowanie alertu o czasie oczekiwania P95 dla serwera proxy interfejsu API

Poniżej znajdziesz przykład konfigurowania alertu za pomocą interfejsu użytkownika, który jest wyzwalany, gdy łączny czas oczekiwania na odpowiedź 95 centyla wynosi ponad 100 ms przez 5 minut dla serwera proxy interfejsu Hotel API 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 czasie oczekiwania P95 dla serwera 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 konfigurowania alertu za pomocą interfejsu użytkownika, który jest aktywowany, gdy odsetek kodów stanu 404 dla wszystkich serwerów proxy interfejsu API przekracza 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 (Nie znaleziono aplikacji) dla wszystkich serwerów proxy interfejsu API korzystających z interfejsu API.

Konfigurowanie alertu dotyczącego liczby serwerów proxy interfejsu API dla interfejsów API

Poniżej znajdziesz przykład konfigurowania alertu za pomocą interfejsu użytkownika, który jest wyzwalany, gdy liczba kodów 5xx dla interfejsów API przekracza 200 przez 5 minut w dowolnym regionie. W tym przykładzie interfejsy API są przechwytywane w kolekcji krytyczne serwery proxy interfejsu 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 dotyczącego liczby serwerów proxy interfejsu API przy użyciu interfejsu API.

Skonfiguruj alert dotyczący odsetka błędów dla usług docelowych

Poniżej znajdziesz przykład konfigurowania alertu za pomocą interfejsu użytkownika, który jest wyzwalany, gdy stawka kodu 500 dla usług docelowych przekracza 10% przez 1 godzinę w dowolnym regionie. W tym przykładzie usługi docelowe są rejestrowane w kolekcji Cele krytyczne. 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 dotyczącego odsetka błędów w usługach docelowych korzystających z interfejsu API.

Skonfiguruj alert dotyczący liczby błędów dla zasady dotyczącej objaśnienia usługi

Poniżej znajdziesz przykład konfigurowania alertu za pomocą interfejsu uruchamianego, gdy stawka 500 kodów w usłudze określonej przez zasady ServiceCallout przekracza 10% przez 1 godzinę 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 dotyczącego odsetka błędów w zasadach dotyczących objaśnienia usługi przy użyciu interfejsu API.

Skonfiguruj alert dotyczący kodu błędu zasad

Poniżej znajdziesz przykład konfigurowania alertu za pomocą interfejsu użytkownika, który jest uruchamiany, gdy liczba kodów błędów JWT AlgorithmMismatch dla zasady weryfikacji JWT przekracza 5 przez 10 minut w przypadku wszystkich 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 dotyczącego kodu błędu dotyczącego kodu błędu zasad za pomocą interfejsu API.