Konfigurowanie alertów i powiadomień

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

Warunki alertów definiują konkretny kod stanu (np. 404/502/2xx/4xx/5xx), czasu oczekiwania oraz kodów błędów, które po przekroczeniu 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 wywołaniu alertu otrzymasz powiadomienie zgodnie z metodą określoną podczas dodawania alertów i powiadomień.

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

Poniższy rysunek przedstawia sposób wyświetlania alertów w interfejsie:

Poniżej znajduje się przykład powiadomienia e-mail, które 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 – zawiera więcej informacji o konkretnym alercie.
• Wyświetl scenariusz, aby zobaczyć zalecane działania (jeśli zostały podane).
• Wyświetl raport interfejsu API Analytics, aby wyświetlić raport niestandardowy dotyczący warunku alertu.

W sekcjach poniżej opisano, jak konfigurować alerty i powiadomienia oraz nimi zarządzać.

Typy alertów

We wstępnej wersji usługi API Monitoring można tworzyć reguły oparte na wzorcach, które określają, kiedy ma być wywoływany alert na podstawie zestawu wstępnie zdefiniowanych warunków. Te typy alertów są nazywane alertami stałymi i były jedynym rodzajem alertów obsługiwanym we wstępnej wersji usługi API Monitoring.

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

• [współczynnik błędów 5xx] [wynosi więcej niż] [10%] w przypadku [10 minut] z [cel moja_cel1]
• [liczba błędów 2xx] [wynosi mniej niż] [50] przez [5 minut] w [region us-east-1]
• [czas oczekiwania p90] [wynosi więcej niż] [750 ms] przez [10 minut] na serwerze [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 umożliwia zgłaszanie alertu, gdy natężenie ruchu zmienia się o określoną wartość procentową w wybranym przedziale czasu.
• alerty o anomalii (beta), Typ alertu, w przypadku którego Edge wykrywa problemy związane z ruchem i wydajnością, bez konieczności ich samodzielnego określania. Możesz następnie 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 zbliża się do wygaśnięcia.

Ponieważ API Monitoring obsługuje teraz wiele typów alertów, w oknie Utwórz alert pojawi się teraz 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ów zgodnie z tą ilustracją:

Jak zaznaczyliśmy na ilustracji, strona Alert umożliwia:

• Wyświetl podsumowanie ustawień alertów, które są obecnie zdefiniowane
• wyświetlić historię alertów, które zostały wygenerowane;
• 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 określonego 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 w Twojej organizacji w ciągu ostatnich 24 godzin, kliknij Analiza > 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 sprawdzania. Listę można filtrować, wyszukując całość lub część nazwy alertu.

Dodawanie alertów i powiadomień

Aby dodać alerty i powiadomienia:

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

   Pole	Opis
   Nazwa alertu	Nazwa alertu. Użyj nazwy, która opisuje regułę i będzie przydatna dla Ciebie. Długość nazwy 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. Użyj interfejsu API, aby podać dowolny kod stanu z przedziału 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 Spike Arrest. Za pomocą zasady AssignMessage możesz przepisać kod odpowiedzi HTTP z powodu błędu serwera proxy lub błędu docelowego. API Monitoring ignoruje wszystkie przepisane kody i rejestruje rzeczywiste kody odpowiedzi HTTP. Czas oczekiwania: wybierz wartość czasu oczekiwania z listy. W szczególności: p50 (50 centyl), p90 (90 centyl), p95 (95 centyl) lub p99 (99 centyl). Wybierz na przykład P95, aby skonfigurować alert, który jest wyzwalany, gdy czas oczekiwania na odpowiedź 95 centyla przekracza próg ustawiony poniżej. Kod błędu: wybierz z listy kategorię, podkategorię i kod błędu. Możesz też wybrać jedną z następujących opcji w kategorii lub podkategorii: Wszystkie – łączna liczba wszystkich kodów błędów w tej kategorii lub podkategorii musi spełniać kryteria danych. Dowolny – 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ększanie lub zmniejszanie 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 jako stopę procentową, liczbę lub liczbę transakcji na sekundę (TPS) w czasie. 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 wystąpienia ruchu, przekracza warunek progowy dla 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 w postaci stawki procentowej, liczby lub transakcji na sekundę (TPS) w czasie.
   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ługę docelową, aplikację dewelopera i region. Jeśli ustawisz konkretny wymiar na: Wszystko – wszystkie elementy w wymiarze muszą spełniać kryteria danych. Nie można wybrać opcji Wszystkie dla danych typu Czas oczekiwania. Dowolna – 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 dowolną funkcję. Kolekcje – wybierz kolekcję z listy, 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ą w zasadach dotyczących 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 stanu z ostatniej godziny.
   Odsetek błędów na wykresie jest wyświetlany 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 kilka warunków, alert zostanie wywołany po spełnieniu wszystkich tych warunków.

7. Kliknij Utwórz raporty Analytics na podstawie warunków alertu, jeśli chcesz utworzyć raport niestandardowy na podstawie skonfigurowanych przez Ciebie 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żyć, i określ miejsce docelowe: Email, 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 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 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 kolejne powiadomienia.

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

    Pole	Opis
    Poradnik	(Opcjonalnie) Pole tekstowe z krótkim opisem zalecanych działań w przypadku uruchamiania uruchamianych alertów. Możesz też podać link do wewnętrznej strony wiki lub społeczności, na której znajdziesz sprawdzone metody. Informacje z tego pola zostaną dołączone do powiadomienia. Długość zawartości 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 pojedynczy ciąg znaków ze szczegółami, a thresholdViolationsFormatted – obiekt opisujący alert. Zwykle używasz właściwości thresholdViolationsFormatted, ponieważ jest ona łatwiejsza do dekodowania.

Powyższy przykład przedstawia zawartość tych właściwości dla alertu stałego, gdy skonfigurujesz wskaźnik alertu tak, aby uruchamiał 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 anomalii) oraz jego konfiguracji. Jeśli np. utworzysz naprawiony 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 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 z wstępnie wypełnionymi odpowiednimi polami. Domyślna nazwa raportu niestandardowego to: API Monitoring Generated alertName

2. Odpowiednio 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 > 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 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. Odpowiednio 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 > Reguły alertów.
2. Kliknij przełącznik w kolumnie Stan powiązany z alertem, który chcesz włączyć lub wyłączyć.
   

Edycja alertu

Aby edytować alert:

1. W interfejsie Edge kliknij Analyze > Reguły alertów.
2. Kliknij nazwę alertu, który chcesz edytować.
3. W razie potrzeby zmodyfikuj alert.
4. Kliknij Zapisz.

Usuwanie alertu

Aby usunąć alert:

1. W interfejsie Edge kliknij Analyze > Reguły alertów.
2. Najedź kursorem na alert, który chcesz usunąć, i kliknij w menu czynności.

Sugerowane alerty

Apigee sugeruje skonfigurowanie poniższych alertów, aby otrzymywać powiadomienia o typowych problemach. Niektóre z nich dotyczą implementacji interfejsów API i przydają się tylko w określonych sytuacjach. Kilka poniższych alertów dotyczy na przykład zasad dotyczących ServiceCallout lub zasad dotyczących Javy w języku Java.

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 wywoływany, gdy liczba transakcji na sekundę (TPS) kodów 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 dotyczącego czasu oczekiwania P95 dla serwera proxy interfejsu API

Poniżej znajdziesz przykład konfigurowania alertu za pomocą interfejsu użytkownika wywoływanego, gdy łączny czas oczekiwania na odpowiedź 95 centyla przekracza 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 używaniu interfejsu API znajdziesz w artykule Konfigurowanie alertu P95 dla serwera proxy interfejsu API przy użyciu interfejsu API

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

Poniżej znajdziesz przykład konfigurowania za pomocą interfejsu użytkownika alertu uruchamianego, 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 przy użyciu 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 wywoływany, gdy liczba kodów 5xx dla interfejsów API przez 5 minut w dowolnym regionie przekroczy 200 przez 5 minut. W tym przykładzie interfejsy API są przechwytywane w kolekcji krytycznych serwerów 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 na temat konfigurowania alertu dotyczącego liczby serwerów proxy interfejsu API przy użyciu interfejsu API.

Konfigurowanie alertu dotyczącego odsetka błędów dla usług docelowych

Poniżej znajdziesz przykład konfigurowania za pomocą interfejsu użytkownika alertu uruchamianego, gdy współczynnik kodów 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 na temat konfigurowania alertu dotyczącego odsetka błędów w usługach docelowych za pomocą interfejsu API.

Konfigurowanie alertu dotyczącego odsetka błędów na potrzeby zasady ServiceCallout

Poniżej znajdziesz przykład konfigurowania alertu za pomocą interfejsu, który jest wywoływany, gdy współczynnik kodu 500 dla usługi określonej przez zasadę 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śnień usługi przy użyciu interfejsu API.

Skonfiguruj alert dotyczący kodu błędu zasady

Poniżej znajdziesz przykład konfigurowania alertu za pomocą interfejsu użytkownika, który jest wywoływany, gdy liczba kodów błędów JWT AlgorithmMismatch w zasadzie VerifyJWT jest większa niż 5 przez 10 minut przez wszystkie interfejsy API. Aby dowiedzieć się więcej, zobacz:

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

Informacje o korzystaniu z interfejsu API znajdziesz w artykule na temat konfigurowania alertu dotyczącego kodu błędu zasad przy użyciu interfejsu API.