Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
![PayPalがGraphQLを採用し、開発者の生産性向上を実現](https://cdn-ak-scissors.b.st-hatena.com/image/square/05a86ec395cdfc4a5740ffd2c73fa56f98ee3fe1/height=288;version=1;width=512/https%3A%2F%2Fcdn.infoq.com%2Fstatics_s2_20240425073945%2Fstyles%2Fstatic%2Fimages%2Flogo%2Flogo-big.jpg)
Lambdaを実装しているとき、ふと「ログのレベルって決めてたっけ?」となりました。 個人の基準はあってもチームとしては曖昧だったので(開発者のさじ加減)、チームで話し合って明文化してみました。 前提 対象はLambdaのログです ERRORレベルのログがあるとき、Slackに通知する仕組みがあります この通知を元に開発者が確認を行い、必要に応じて対処します AWSの環境は3つです development staging production ログを残す理由 Lambdaの処理で何かあったことを認識するため 何らかの対応(暫定・恒久)を行うとき、参考情報とするため CloudWatch AlarmでLambdaのエラー監視をすればLambdaの実行が失敗したことは分かりますが、適切なログが無ければ、「何をしようとして失敗したのか?」「その時のパラメータは何か?」などが分かりません。 また、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く