tokyo.serverlessconf.io他のセッションtech.guitarrapc.comtech.guitarrapc.comtech.guitarrapc.comtech.guitarrapc.com引用は私のコメントです。監視これらは不要だけど、サービスは正しく動いているのか、コンポーネントが動いているのかを確認していくのが重要になる。サービス監視サービスが正しく提供されているか判断する指標コンポーネント監視コンポーネントが動いているのかレイヤがインフラ生からサービスの要素に変わっているので、そうなりますね。提供AWS/GCPで提供される視覚表示は、折れ線グラフになっており指標とあってないこともおおい。大型モニタに表示して席から見てる。クォーターリミットサービスパフォーマンス所要時間が重要。IODatadogのしきい値、色変化で見てる。Logsすべてのアカウント、プロジェクトのエログを集約フィルタリングも爆速たとえば、マイクロサービスを絞り込んだり、ファンクションで絞り込んだり、ステータスコードで絞り込んだり、レコードを選ぶと詳細が見られる。ここで、リクエストの内容やレスポンスの内容を埋め込んでいる。ダッシュボードのメトリックからログに飛ぶことが可能。ノードを選択するとより細かい利用が見られる。何がいいかというと、プラットフォーマーが提供しうるサービスとは異なり、クラウドをまたげる。(が、サービスマップはサーバーレスからは利用できない、エージェントインストールが必要)Q&Aインシデントがあったときに連動方法は?異常はダッシュボードで確認。ここからDynamoDB用など詳細のダッシュボードでわかるようになっている。あとは、じょじょに上がっているのであればキャパシティ問題。スパイクなら、異常が発生しているのかの確認。スパイクを起こしているテーブルから、そのテーブルを使っている関数をたどる。通知でハンドルしている。日常的に改善が必要と認識。人間が対処するしかないという認識。以外に、タイムボードでメモを残している。(フルマネージドなので、クラウド障害じゃないと障害にナリにくいのでノウハウが溜まりにくい)ちょっとインシデント管理厳しいですよねぇ。流して、自動的にesaにpostあたりがいいかなぁ。Issueもインシデント管理にそこまで強くいないしなぁ。