Skip to content

Subscribe errors to the monitoring/alerter#94

Merged
lsipii merged 13 commits intomainfrom
feat/error-alerting
Oct 25, 2023
Merged

Subscribe errors to the monitoring/alerter#94
lsipii merged 13 commits intomainfrom
feat/error-alerting

Conversation

@lsipii
Copy link
Copy Markdown
Contributor

@lsipii lsipii commented Oct 18, 2023

  • sends alerts to the monitoring when:
    • the http response code is above 404, that primarily includes:
      • server errors
      • validation errors
    • lambda function timeouts
  • drop the lambda function timeout from 30s to 15s:
    • should the users-api response time be above 15 seconds, an error it be considered as should
  • adds exception type and message to the request log (payload that's send to the alerter)
  • simplifies the logging configurations regarding live environments
  • relates to Cloudwatch logs alerts monitoring#28

@lsipii lsipii marked this pull request as ready for review October 20, 2023 08:09
@lsipii lsipii requested a review from LauriGofore October 20, 2023 08:09
_ = new LogSubscriptionFilter(stackSetup.CreateResourceName("StatusCodeAlert"), new LogSubscriptionFilterArgs
{
LogGroup = LogGroup.Name,
FilterPattern = "{ $.StatusCode > 404 }", // Users API should not encounter errors with status code > 404, for example validation errors not expected
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Eikö tässä toimis yhtälailla "ERROR" patterni? jos 404 ei ole huolenaihe eikä niitä oletettavasti tule kuitenkaan (toki sekin catchattais, jos jostain aivan mysteerisyystä semmottinen ilmestyis - olisi varmaan hyvä saada tietää että nyt on jotain pahasti vinossa 😅)

Copy link
Copy Markdown
Contributor Author

@lsipii lsipii Oct 23, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Patterni riippuupi ihan että mitenkä appis logittelee. "Error"-avainsanaa ei taida users-api normaalisti nyt tuotella, paitsi näyttäisi sattuvan yksi mätsi, eli jos ErrorHandlerMiddleware vastaanottaa virheen jolle ei käsittelyä niin siitä logittuu sen trace josta tulee luokan nimestä mätsi, sama virhe kyllä taas osuu tuohon statuskoodifiltteriin > 404. Sit taas nykyisellä logituksella validaatiovirhe 422 ei tuota "error"-avainsanaa ja aattelin että tässä tarkoituksessa se voisi olla alertin arvoinen tieto jos dataspacen kautta tulee invalidia sisältöä.

Ehkäpä toi voisi olla parempi että käyttää sitä error-avainsanaa sit kuitenkin ja muuttaa niissä virheissä joista haluaa aiheutuvan alertin logitusta site että se myös värähtää, pitää vain sit otaa noi statuskoodi-katselmoinnit pois kun siitä taitaa tulla silloin tuplana ne alertit kun ne on eri logiriveillä ne mätsit.

Copy link
Copy Markdown
Contributor

@LauriGofore LauriGofore Oct 24, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah aivan. Mulla oli tässä väärinymmärrys, kun ajattelin että cloudwatch logs itsessään jotenkin kategorioisi noita logeja (tyyliin jos tullut error catchistä -> ERROR -tason logi jne.) Ikään kuin oma kerros tuossa, mutta tosiaan tämähän onkin aivan lähteestä riippuvainen, että missä muodossa tulee. (ERROR, INFO yms. näitä nyt nähnyt paljon alerts systeemin debuggailuissa, lienee sit vaan aspnet/.net skeemaa(?)/omaa muotoa noissa logituksissa). Ja laiteittiinhan tuo "ERROR" lisänä myös sinne af-appiksen puolelle eli joo kylkyl!

@lsipii lsipii merged commit 8b24818 into main Oct 25, 2023
@lsipii lsipii deleted the feat/error-alerting branch October 25, 2023 09:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants