sobota, 30 listopada 2024

CloudWatch Insights - most used HTTP endpoints


Having a standard PHP Symfony Framework log structure like one below you can measure whole application HTTP traffic using CloudWatch Insights.  

{
   "message":"Matched route \"some_endpoint_name\",
   "context":{
      "route":"some_endpoint_name",
      "request_uri":"http://some.domain.com/some/endpoint/91b5602d-f098-471a-aa05-92937fea3636/name",
      "method":"POST"
   },
   "level":200,
   "level_name":"INFO",
   "channel":"request",
   "datetime":"2024-11-30T10:26:08.594527+00:00",
}

As you can see context.request_uri  key it's hard to aggregate since each request for the same endpoint will differ due to passed in URI params like UUID of the resource. To avoid mentioned problem we should use rather a context.route value which is declared in Symfony Controller class as one of the value Action Attribute.  

Here is example of the CloudWatch Insights query which show in descending order all of the most used POST/PATCH/PUT/DELETE (these are changing state of the system) endpoints in your application: 

fields @timestamp, @message, @logStream, @log
| filter channel = "request" and context.method != "GET" 
| stats count(*) as endpointsCallsCount by context.route, context.method
| sort endpointsCallsCount desc


The standard output of the query, it's descending order easily shows the most used endpoints in your application

You can also see results as chart so you can compare all endpoints share in total HTTP traffic volume  

For monitor all GET endpoints worth to filter non functional endpoints call that only checks an availability of the system:

fields @timestamp, @message, @logStream, @log
| filter channel = "request" and context.method = "GET" and context.route not in ["health_check","ping"]
| stats count(*) as endpointsCallsCount by context.route, context.method
| sort endpointsCallsCount desc

pi膮tek, 8 listopada 2024

Observability

Tradycyjne metody monitoringu przesta艂y by膰 wystarczaj膮ce w dobie z艂o偶onych system贸w - wymagane jest bardziej wnikliwe zrozumienie system贸w oraz przy艣pieszanie rozwi膮zywania incydent贸w.

Sama implementacja system贸w obserwowalnych i ich utrzymanie rodzi nowe problemy. Zewn臋trzne systemy s艂u偶膮 do obserwowania aplikacji; kwestionowanie w celu poznania wewn臋trznej pracy systemu i stanu systemu.

Je偶eli mamy mo偶liwo艣膰 pozyskania informacji na temat stanu aplikacji w ka偶dym jej aspekcie nawet z kt贸rymi byli艣my nie zaznajomieni jeszcze jaki艣 czas temu, kt贸rych nie przewidzieli艣my - a przysz艂y nam one dopiero teraz i mamy mo偶liwo艣膰 zweryfikowania tych偶e danych. Oznacza to, 偶e wska藕nik Observability systemu jest wysoki.

Stale musimy usprawnia膰 proces zwi臋kszania wska藕nika Observability; dzi臋ki wysokiemu Observability mo偶emy wypatrywa膰 niecodziennych/podejrzanych wzorc贸w i zachowa艅; pozwala na analiz臋 interakcji u偶ytkownika z systemem; dzi臋ki Observability mamy wgl膮d w dynamik臋 komunikacji mi臋dzy mikro serwisami/kontenerami; taka analiza powinna by膰 standardowym elementem pracy programist贸w (development life-cycle). Observability daje mo偶liwo艣膰 wgl膮du w zachowanie systemu, dzi臋ki tym informacj膮 deweloperzy mog膮 poprawia膰 niezawodno艣膰/wydajno艣膰 systemu; analiza log贸w, metryk, trace’贸w pozwala na zidentyfikowanie bottleneck’贸w wydajno艣ciowych;

Kluczowe koncepty:

  • Root cause analysis
  • Highly observable system (has intricate details/critical insights)
  • Realtime monitoring/alerting
  • resource utilization
  • error rates
  • Synthetic Journeys
  • performance metrics
  • deviations from normal patterns
  • APM (Application Performance Monitoring)
  • application dependencies,
  • Distributed tracing - z艂o偶one systemy gdzie pojedynczy request oddzia艂uje na wiele mikro serwis贸w w r贸偶nych data centers - taki trace ma sw贸j ID
  • Telemetry Instrumentations (Open Telemetry Standard) event wysy艂any do central location (tracking user journey; troubleshooting errors)
  • Site Reliability Engineering (SRE)
  • feature flagging
  • incident analysis
  • blue-green deployment
  • chaos engineering; “pytania kt贸re zostan膮 postawione bez wcze艣niejszej wiedzy”
  • alert ➡️ warto艣膰 progowa predefiniowanej metryki zosta艂a przekroczona; remediations (艣rodki zaradcze)
  • podej艣cie reaktywne: zidentyfikowanie i rozwi膮zanie problemu po tym jak wyst膮pi
  • podej艣cie proaktywne
Observability pomaga zrozumie膰 wewn臋trzne zachowanie systemu co mo偶e wy艂oni膰 potencjalne problemy kt贸re b臋d膮 mie膰 miejsce w przysz艂o艣ci.

Alert musi mie膰 dane dot. powodu jego wyst膮pienia (moje do艣wiadczenie: miejsce wyst膮pienia, dane kontekstowe - zasobu kt贸rego dotyczy).

Tradycyjny monitoring i dashboardy polegaj膮 na wiedzy Seniora (dependency on human expertise) - czyli metodologia (tradycyjny monitoring) polegaj膮ca na objawach ani偶eli na actual Root Cause - to nie mo偶e by膰 d艂u偶ej stosowane gdy z艂o偶ono艣膰 i skala jest du偶a; “Information to debug issues in details”, “ask open questions”, “trace the system to find real cause of problems (deeply hidden)”; organizacja nie polega na wiedzy eksperta i na subiektywnym zgadywaniu, a prowadzi do bardziej obiektywnej analizy; Z艂o偶one interakcje mi臋dzy systemami rozproszonymi; metrics, events, logs, traces, telemetry data - unforeseen issues. Szybkie rozwi膮zanie problemu to ograniczenie down-time; identify & solve potential issue before they affect users - w przeciwie艅stwie do reagowania na problem; Problemy z Observability: przechowywanie tych danych, przesy艂anie tych danych po sieci; zmiana sposobu my艣lenia z re na pro; observability kosztuje; security & privacy; 



殴r贸d艂o