Kokia jūsų patirtis ieškant klaidų mikroservisų architektūroje ir kokius įgūdžius naudojate tam?

Mikroservisų architektūros gedimų paieškai naudoju keletą metodų ir įrankių:

• Centralizuotas žurnalų kaupimas: Žurnalų surinkimas iš visų paslaugų vienoje sistemoje (pvz., Elasticsearch, Fluentd, Kibana - EFK rinkinys arba Grafana Loki). Tai leidžia greitai koreliuoti įvykius tarp paslaugų.
• Išplėstinė sekimo sistema: Užklausos gyvavimo ciklo sekimas per skirtingas paslaugas (pvz., Jaeger, Zipkin). Padeda nustatyti vietas, kuriose įvyksta trikdžiai ir klaidos.
• Stebėjimo ir įspėjimo sistemos: Veiklos metrikų nustatymas (CPU, RAM, tinklo aktyvumas, užklausų skaičius, delsimas) kiekvienai paslaugai ir bendros infrastruktūros (Prometheus, Grafana, Zabbix). Įspėjimai apie anomalijas.
• Profilavimas: Išteklių ir kodo vykdymo laiko analizė atskiruose paslaugose, siekiant nustatyti "sunkias" operacijas.
• Postmortem kultūra: Incidentų analizė siekiant nustatyti pagrindines priežastis ir užkirsti kelią jų pasikartojimui.

Pagrindiniai įgūdžiai:

• Tinklo protokolų (TCP/IP, HTTP) supratimas.
• Darbas su žurnalų, stebėjimo ir sekimo įrankiais.
• Scripting kalbų (Bash, Python) žinojimas automatizacijai.
• Mikroservisų veikimo principų, konteinerizacijos (Docker) ir orkestracijos (Kubernetes) supratimas.
• Kodo skaitymo ir analizės įgūdžiai, įskaitant potencialių problemų asinchroniniuose sąveikose nustatymą.
• Sisteminis mąstymas ir problemų dekonstravimas.

Pavyzdys užklausos sekimo naudojant curl ir derinimo antraštes:

# Užklausos siuntimas su sekimo antrašte (pvz., X-Request-Id)
curl -H "X-Request-Id: $(uuidgen)" http://my-service/api/v1/data

Logų analizės pavyzdys su grep:

# Klaidos paieška nurodytu laiko tarpu centralizuotame žurnale
grep "ERROR" /var/log/services/* | grep "2023-10-27T10"