B-3 ログと徹底的に向き合うデータドリブンなサービス運用

デブサミでメモしたことをつらつら書いていきます。

持って帰って欲しいこと
　ログをデータドリブン開発の一部として利用できる仕組み

ログ出力の基本

ログの出力形式
　・タイムスタンプ
　　ログの出力時刻
　・出力元の情報
　　ホスト名、プロセスID、スレッドID等
　・ログレベル
　　INFO、WARN、ERROR等
　・トレース識別情報
　　サービスを跨いでリスクエストを追跡するための情報
　・処理結果
　　所要時間、ステータスコード
　・詳細情報
　　バックトレース等

ログ例
　スタックトレース（バックトレース）は出していい

ログの出力先
　・CloudWatch Logs（クラウドのログ基盤）
　　コンテナの出力するログ
　・S3（オブジェクトストレージ）
　　VPC Flow Log、ALBのログ等、AWS内部で自動的に取得するもの
　・BigQuery（データウェアハウス）
　　リクエストログの一部は、CloudWatch LogsではなくBigQueryに連携
　　Google AnalyticsのログもBigQueryに連携
　・Sentry/Datadog（イベントトラッキングサービス）
　　アプリケーションのエラー情報
　　リクエストログの一部

ログの出力タイミング
　・エラーが発生した場合
　　アプリケーションエラー
　　不具合の可能性もあるので早急に対応が必要
　・エラーではないが、特定の条件に合致した場合
　　入力のValidationエラー、ログイン認証の失敗、サービス規約上の上限や制限超過等
　　アプリケーション的には想定通りの挙動だが、ユーザー側はうまく利用できていない状況の記録
　　発生頻度が多いようであれば、何かしら改善の余地がある可能性がある
　・常時
　　リクエストログ、監査ログ等
　　長時間かかる処理の進捗状況

うるるでの仕組み

サービスの状態とは
　・リクエスト数
　　そのサービスがどれくらい呼ばれているか
　　DatadogやBigQueryに格納したログの集計で把握
　・レスポンス
　　遅延がないかDatadogで把握
　　500エラーが多発していないかALBのメトリクスで把握
　・システムリソース
　　CPUやメモリ等が過負荷になっていないか
　　CloudWatch、Datadogで把握

エラーの種類
　・アプリの不具合（バグ）
　　アプリからのログと通知（イレギュラーな事象）
　　主にSentryで検知
　・プラットフォームの不具合（サーバーダウン等）
　　死活監視、AWSからの通知
　　アプリからのログと通知（DB接続エラー等）
　・過負荷によるスローダウン
　　Datadogのアラート

エラーの見やすさ
　・量を絞る
　　一目で確認できる量には限界がある
　　Sentryで通知頻度を制御
　・フォーマットを工夫する
　　必要な情報だけに整理する
　　Web画面で整理された情報を確認（Sentry/Datadog）

セキュリティ関連のログ
　・外部からの攻撃や侵入の記録
　　GuardDuty
　　WAFのログ
　　VPCフローログ
　・監査ログ
　　データベースへログを記録
　・システム変更
　　CloudTrail
　　AWSConfig

利用情報
　・ユーザーの操作情報
　　アクセス情報
　　UA
　　リファラー
　　ユーザーを特定できる情報（IDなど）