STEP 24：モニタリングとロギング

ホーム > クラウドデータ基盤 > STEP 24

📊 STEP 24: モニタリングとロギング

システムの健全性を監視！CloudWatch・Cloud Monitoringでアラート設定

📋 このステップで学ぶこと

  • モニタリングとロギングの重要性
  • CloudWatch（AWS）の基礎と活用
  • Cloud Monitoring（GCP）の基礎と活用
  • ログの収集と分析
  • アラート設定とインシデント対応
  • ダッシュボード作成
  • 実践演習：データパイプラインの監視設定

🎯 このステップのゴール

このステップを終えると、システムの健全性を監視し、問題を早期発見できるようになります。CloudWatch/Cloud Monitoringでアラートを設定し、ダッシュボードで可視化する方法を身につけましょう！

🎯 1. なぜモニタリングが必要なのか？

💡 例え話：車のダッシュボード

【モニタリング = 車のダッシュボード】 車を運転するとき、ダッシュボードを見て： 🚗 スピードメーター → 速度が法定速度を超えていないか ⛽ 燃料計 → ガソリンが残っているか 🌡️ 水温計 → エンジンがオーバーヒートしていないか 🔋 バッテリー警告灯 → バッテリーに問題がないか もしダッシュボードがなかったら… ❌ スピード違反で捕まる ❌ ガス欠で立ち往生 ❌ エンジン故障で修理代が高額に 【クラウドも同じ！】 ダッシュボード = CloudWatch / Cloud Monitoring ・CPU使用率 → 処理が重くなっていないか ・メモリ → 足りているか ・エラー率 → 問題が起きていないか ・コスト → 予算を超えていないか 💡 問題が起きる前に気づける！

モニタリングの4つの目的

1️⃣ 早期発見

問題が大きくなる前に発見して対処。ユーザーから報告される前に気づける。

2️⃣ 原因究明

ログを分析して、なぜエラーが起きたか特定。「再発防止」につなげる。

3️⃣ パフォーマンス最適化

遅い処理を発見して改善。ボトルネックを特定できる。

4️⃣ コスト管理

リソース使用量を監視してコスト削減。無駄な支出を防ぐ。

モニタリング vs ロギング

📊 モニタリングとロギングの違い

【モニタリング vs ロギング】 ┌─────────────────────────────────────────────────────────┐ │ モニタリング（Monitoring） │ ├─────────────────────────────────────────────────────────┤ │ 目的: システムの「今」の状態を監視 │ │ データ: メトリクス（数値データ） │ │ 例: CPU使用率 85%、メモリ使用量 4GB │ │ 頻度: リアルタイム（数秒〜数分間隔） │ │ 用途: アラート発報、ダッシュボード表示 │ │ │ │ 例え: 「今、熱があるか？」を体温計で測る │ └─────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────┐ │ ロギング（Logging） │ ├─────────────────────────────────────────────────────────┤ │ 目的: システムの「過去」の動作を記録 │ │ データ: ログ（テキストデータ） │ │ 例: “2024-01-15 10:30:45 ERROR: DBに接続できません” │ │ 頻度: イベント発生時（何か起きたら記録） │ │ 用途: トラブルシューティング、監査 │ │ │ │ 例え: 「何が原因で熱が出たか？」を診察記録で確認 │ └─────────────────────────────────────────────────────────┘ 【両方必要！】 ・モニタリング: 問題が起きていることに「気づく」 ・ロギング: 問題の「原因」を特定する

☁️ 2. AWS CloudWatch入門

CloudWatchの4つの機能

📝 CloudWatchの主要機能

【CloudWatchの4つの柱】 ┌─────────────────────────────────────────────────────────┐ │ 1. CloudWatch Metrics（メトリクス） │ ├─────────────────────────────────────────────────────────┤ │ CPU、メモリ、ディスクなどの数値データを収集 │ │ 例: CPUUtilization = 75% │ └─────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────┐ │ 2. CloudWatch Logs（ログ） │ ├─────────────────────────────────────────────────────────┤ │ アプリケーションのログを収集・分析 │ │ 例: ERROR: Database connection failed │ └─────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────┐ │ 3. CloudWatch Alarms（アラーム） │ ├─────────────────────────────────────────────────────────┤ │ しきい値を超えたら自動で通知 │ │ 例: CPU > 80% が5分続いたらメール送信 │ └─────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────┐ │ 4. CloudWatch Dashboards（ダッシュボード） │ ├─────────────────────────────────────────────────────────┤ │ 複数のメトリクスを1画面にまとめて可視化 │ │ 例: Redshiftの全メトリクスを一覧表示 │ └─────────────────────────────────────────────────────────┘

主要なメトリクス一覧

サービス メトリクス 説明・しきい値の目安
EC2 CPUUtilization CPU使用率（%）。80%超えで要注意
S3 NumberOfObjects バケット内のオブジェクト数
Redshift DatabaseConnections アクティブな接続数。上限に近づいたら要注意
Redshift PercentageDiskSpaceUsed ディスク使用率。80%超えで増設検討
Lambda Invocations 関数の実行回数
Lambda Errors エラー発生回数。0以外は要調査
Glue glue.driver.jvm.heap.usage JVMメモリ使用量。OOMの前兆を検知

CloudWatch Logsの使い方

📝 PythonからCloudWatch Logsに送信

# PythonでCloudWatch Logsに送信 import boto3 import logging from watchtower import CloudWatchLogHandler # pip install watchtower # ロガーを作成 logger = logging.getLogger(__name__) logger.setLevel(logging.INFO) # INFO以上のログを出力 # CloudWatch Logsハンドラーを設定 handler = CloudWatchLogHandler( log_group=’/my-app/production’, # ロググループ名（フォルダのようなもの） stream_name=’app-logs’ # ログストリーム名（ファイルのようなもの） ) logger.addHandler(handler) # ログを出力 logger.info(‘アプリケーションが起動しました’) logger.warning(‘メモリ使用率が高くなっています’) logger.error(‘エラーが発生しました’, exc_info=True) # スタックトレースも出力

📝 コードの各行を解説

【各パラメータの意味】 log_group=’/my-app/production’ ├── ロググループ = フォルダのようなもの ├── アプリケーションごと、環境ごとに分ける └── 例: /my-app/production, /my-app/staging stream_name=’app-logs’ ├── ログストリーム = ファイルのようなもの ├── 同じロググループ内でさらに分類 └── 例: app-logs, error-logs, access-logs logger.setLevel(logging.INFO) ├── このレベル以上のログだけ出力 ├── DEBUG < INFO < WARNING < ERROR < CRITICAL └── 本番環境ではINFO推奨（DEBUGは量が多すぎる） exc_info=True ├── エラー発生時のスタックトレース（呼び出し履歴）を出力 └── 原因究明に必須！

CloudWatch Alarmsの設定手順

📝 アラーム設定のステップバイステップ

  1. AWSコンソール → 「CloudWatch」を開く
  2. 左メニューから「アラーム」→「すべてのアラーム」
  3. 「アラームの作成」ボタンをクリック
  4. 「メトリクスの選択」でサービスを選ぶ
  5. 条件を設定
  6. アクション（通知先）を設定
  7. 名前をつけて作成
【アラーム条件の設定例】 ┌─────────────────────────────────────────────────────────┐ │ メトリクスの選択 │ ├─────────────────────────────────────────────────────────┤ │ 名前空間: AWS/Redshift │ │ メトリクス名: CPUUtilization │ │ ClusterIdentifier: my-redshift-cluster │ └─────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────┐ │ 条件の設定 │ ├─────────────────────────────────────────────────────────┤ │ しきい値の種類: 静的 │ │ 条件: より大きい（>） │ │ 値: 80（%） │ │ │ │ データポイント: 5分間に3回中3回超えたらアラーム │ │ （一時的なスパイクは無視、継続的な高負荷のみ検知） │ └─────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────┐ │ アクションの設定 │ ├─────────────────────────────────────────────────────────┤ │ アラーム状態: アラーム状態 │ │ 通知先: 既存のSNSトピックを選択 │ │ SNSトピック: redshift-alerts │ └─────────────────────────────────────────────────────────┘ 💡 SNSトピックに事前にメールアドレスを登録しておく！

✅ SNS（Simple Notification Service）との連携

  1. SNSトピックを作成：SNSコンソール → 「トピックを作成」
  2. サブスクリプションを追加：メールアドレスを登録
  3. 確認メールを承認：届いたメールの「Confirm subscription」をクリック
  4. CloudWatch AlarmでSNSトピックを選択：アクションに設定

🔵 3. GCP Cloud Monitoring入門

Cloud Monitoringの主要機能

📝 Cloud Monitoringの4つの柱

【Cloud Monitoringの主要機能】 1. Metrics Explorer（メトリクスエクスプローラー） → メトリクスをグラフ化して表示 → CloudWatchのMetricsに相当 2. Cloud Logging（ロギング） → ログを収集・分析 → CloudWatch Logsに相当 3. Alerting（アラート） → しきい値を超えたら通知 → CloudWatch Alarmsに相当 4. Dashboards（ダッシュボード） → 複数のメトリクスを可視化 → CloudWatch Dashboardsに相当 ※ 旧名は「Stackdriver」

主要なメトリクス一覧

サービス メトリクス 説明
Compute Engine cpu/utilization CPU使用率
GCS storage/total_bytes 保存されているデータ量
BigQuery query/count 実行されたクエリ数
BigQuery slots/total_available 利用可能なスロット数
Dataflow job/element_count 処理した要素数
Dataflow job/current_num_vcpus 使用中のvCPU数
Cloud Functions function/execution_count 関数の実行回数

Cloud Loggingの使い方

📝 PythonからCloud Loggingに送信

# PythonでCloud Loggingに送信 # pip install google-cloud-logging from google.cloud import logging as cloud_logging import logging # Cloud Loggingクライアントを作成 client = cloud_logging.Client() # 標準のloggingモジュールと連携 client.setup_logging() # ロガーを取得 logger = logging.getLogger(__name__) logger.setLevel(logging.INFO) # ログを出力（自動的にCloud Loggingに送信される） logger.info(‘アプリケーションが起動しました’) logger.warning(‘メモリ使用率が高くなっています’) logger.error(‘エラーが発生しました’)

📝 コードの各行を解説

【各部分の意味】 from google.cloud import logging as cloud_logging ├── GCPのCloud Loggingライブラリをインポート └── 標準のloggingと名前が被るので、別名をつける client = cloud_logging.Client() ├── Cloud Loggingのクライアントを作成 └── 認証情報は環境変数 GOOGLE_APPLICATION_CREDENTIALS で設定 client.setup_logging() ├── 標準のloggingモジュールと連携 ├── これ以降のlogger.info()などが自動でCloud Loggingに送信される └── とても便利！1行でセットアップ完了 【ログの確認場所】 GCPコンソール → 「ロギング」 → 「ログエクスプローラー」 フィルタ: severity>=INFO でINFO以上のログを表示

アラートポリシーの設定手順

📝 アラート設定のステップバイステップ

  1. GCPコンソール → 「Monitoring」を開く
  2. 左メニューから「アラート」
  3. 「ポリシーを作成」をクリック
  4. 「条件を追加」でメトリクスを選択
  5. しきい値を設定
  6. 通知チャネルを設定
  7. 名前をつけて作成
【アラートポリシーの例】 ┌─────────────────────────────────────────────────────────┐ │ 条件の設定 │ ├─────────────────────────────────────────────────────────┤ │ リソースタイプ: BigQuery Dataset │ │ メトリクス: storage/stored_bytes │ │ フィルタ: dataset_id = “my_dataset” │ │ │ │ 条件: 1TB（1,000,000,000,000 bytes）以上 │ │ 期間: 5分間連続 │ └─────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────┐ │ 通知チャネル │ ├─────────────────────────────────────────────────────────┤ │ ✅ メール: [email protected] │ │ ✅ Slack: #alerts チャネル │ └─────────────────────────────────────────────────────────┘ 💡 BigQueryテーブルが1TBを超えたら、 メールとSlackに通知！

✅ 通知チャネルの設定

  • メール：指定したアドレスに送信
  • Slack：Webhookで連携（Slackアプリの設定が必要）
  • PagerDuty：オンコールツールと連携
  • SMS：携帯電話にテキストメッセージ
  • Pub/Sub：プログラムで受け取って自動処理

🔍 4. ログ分析のベストプラクティス

ログレベルの使い分け

💡 例え話：健康診断の結果

【ログレベル = 健康診断の結果】 DEBUG（デバッグ）= 精密検査の詳細データ ・「血圧: 120/80、心拍: 72、体温: 36.5」 ・開発者しか見ない、量が多い INFO（情報）= 健康診断の結果 ・「特に異常ありません」 ・通常の動作記録 WARNING（警告）= 要経過観察 ・「コレステロールがやや高めです」 ・問題になりそうだが、今は動作している ERROR（エラー）= 要治療 ・「血糖値が基準値を超えています」 ・一部機能に問題あり CRITICAL（致命的）= 緊急入院 ・「心臓に重大な異常が見つかりました」 ・システム全体が危険な状態
レベル 用途 例
DEBUG 開発時のデバッグ情報 「変数x=123」「関数Aを呼び出し」
INFO 通常の動作情報 「処理開始」「100件処理完了」
WARNING 警告（動作は継続） 「再試行します」「非推奨の機能を使用」
ERROR エラー（一部機能が失敗） 「ファイル読み込み失敗」「API呼び出し失敗」
CRITICAL 致命的エラー（システム停止） 「DB接続不可」「メモリ不足」

💡 本番環境のログレベル設定

  • 開発環境：DEBUG（すべて出力）
  • 本番環境：INFO以上（DEBUGは出力しない）
  • 理由：DEBUGログは量が多すぎて、コストが高くなる＆重要なログが埋もれる

構造化ログ（JSON形式）

❌ NG例：プレーンテキスト

2024-01-15 10:30:45 INFO User [email protected] logged in from 192.168.1.1 問題点： ・フィールドを抽出するのが面倒 ・「[email protected] のログを検索」が難しい ・集計や分析がしづらい

✅ OK例：JSON形式（構造化ログ）

{ “timestamp”: “2024-01-15T10:30:45Z”, “level”: “INFO”, “message”: “User logged in”, “user_email”: “[email protected]“, “ip_address”: “192.168.1.1”, “event_type”: “login” } メリット： ・フィールドごとに検索できる ・「[email protected]」で簡単にフィルタ ・集計クエリ: 「event_type=login を時間ごとにカウント」

📝 Pythonで構造化ログを出力

import logging import json from datetime import datetime class JsonFormatter(logging.Formatter): def format(self, record): log_data = { ‘timestamp’: datetime.utcnow().isoformat() + ‘Z’, ‘level’: record.levelname, ‘message’: record.getMessage(), ‘logger’: record.name } # extraの属性を追加 if hasattr(record, ‘user_email’): log_data[‘user_email’] = record.user_email if hasattr(record, ‘event_type’): log_data[‘event_type’] = record.event_type return json.dumps(log_data) # 使い方 logger = logging.getLogger(__name__) handler = logging.StreamHandler() handler.setFormatter(JsonFormatter()) logger.addHandler(handler) logger.info(‘User logged in’, extra={ ‘user_email’: ‘[email protected]‘, ‘event_type’: ‘login’ })

🚨 5. アラート設定のベストプラクティス

アラート疲れを防ぐ

💡 例え話：オオカミ少年

【アラート疲れ = オオカミ少年】 毎日「オオカミが来た！」と叫ぶ少年… 🐺 1日目: みんな駆けつける → オオカミいない 🐺 2日目: 「また？」と思いつつ確認 → オオカミいない 🐺 3日目: 無視する → オオカミいない 🐺 4日目: 完全に無視 → 本当にオオカミが来た！ 【アラートも同じ】 毎日100件のアラートが来ると… ❌ 全部確認しきれない ❌ 重要なアラートを見逃す ❌ そのうちアラートを無視するようになる 【解決策】 ✅ 本当に重要なときだけアラートを出す ✅ 優先度をつけて、通知方法を変える ✅ 一時的なスパイクは無視する設定に

⚠️ よくある失敗例

  • アラートが多すぎる：1日に100件のアラートが来て、全部無視される
  • 誤検知が多い：ほとんどが誤報で、本当の問題を見逃す
  • しきい値が厳しすぎる：一時的なスパイクでアラートが連発

✅ アラート設計の3原則

  1. Actionable（対応可能）：アラートを受け取ったら、何かアクションを取れる
  2. Meaningful（意味がある）：本当に問題があるときだけアラート
  3. Prioritized（優先順位付け）：重要度に応じて通知方法を変える

アラートの優先度設定

優先度 条件 通知方法・対応時間
P1（緊急） システム全体が停止
データ損失のリスク		 電話 + SMS + Slack
即座に対応（24時間対応）
P2（重要） 一部機能が停止
パフォーマンス劣化		 Slack + メール
30分以内に対応
P3（通常） 軽微な問題
影響は限定的		 メール
翌営業日に対応
P4（情報） 念のための通知
対応不要		 ダッシュボードのみ
通知なし

📝 良いアラート条件 vs 悪いアラート条件

【良いアラート条件】✅ ✅ Redshift CPU使用率が90%を「10分間連続」で超えた → 一時的なスパイクは無視、継続的な高負荷のみ検知 ✅ DataflowジョブがERROR状態で終了した → 明確な失敗のみアラート、成功は通知不要 ✅ BigQueryのクエリコストが1日$100を超えた → 予算超過の早期発見 ✅ エラー率が全体の5%を超えた → 1件のエラーでは通知しない、割合で判断 【悪いアラート条件】❌ ❌ CPU使用率が50%を超えた → 50%は正常範囲、頻繁すぎる ❌ エラーログが1件でも出た → 軽微なエラーまで通知、ノイズが多い ❌ レスポンスタイムが100msを超えた → 厳しすぎる、一時的な遅延は許容すべき ❌ ディスク使用率が10%を超えた → 低すぎる、意味のないアラート

🛠️ 6. 実践演習：データパイプラインの監視設定

シナリオ

日次でGCS → Dataflow → BigQueryのパイプラインを実行しています。監視とアラートを設定します。

📋 監視する項目

  1. Dataflowジョブの実行状態（成功/失敗）
  2. Dataflowの処理時間（通常より遅くないか）
  3. BigQueryへのデータロード件数
  4. エラーログの発生

STEP 1: Dataflowジョブの監視（ログ出力）

# Cloud Loggingでジョブの状態をログ出力 import logging from datetime import datetime logger = logging.getLogger(__name__) def dataflow_pipeline(): job_name = ‘daily_etl’ start_time = datetime.now() try: # ジョブ開始をログ出力 logger.info(‘Dataflowジョブを開始します’, extra={ ‘job_name’: job_name, ‘status’: ‘STARTED’, ‘timestamp’: start_time.isoformat() }) # Dataflowパイプライン実行 result = pipeline.run() result.wait_until_finish() # 成功をログ出力 end_time = datetime.now() duration = (end_time – start_time).total_seconds() logger.info(‘Dataflowジョブが成功しました’, extra={ ‘job_name’: job_name, ‘status’: ‘SUCCESS’, ‘duration_seconds’: duration, ‘timestamp’: end_time.isoformat() }) except Exception as e: # 失敗をログ出力 logger.error(‘Dataflowジョブが失敗しました’, extra={ ‘job_name’: job_name, ‘status’: ‘FAILED’, ‘error_message’: str(e), ‘timestamp’: datetime.now().isoformat() }) raise

STEP 2: アラートポリシーの作成

🚨 アラート1: ジョブ失敗の検知（P1）

条件: ・リソースタイプ: Dataflow Job ・メトリクス: job/is_failed ・条件: TRUE（失敗した） 通知: ・Slackチャネル #alerts（即座に通知） ・メール: [email protected] ・PagerDuty: オンコール担当者 優先度: P1（緊急）- 即座に対応

⏱️ アラート2: 処理時間の異常（P2）

条件: ・リソースタイプ: Dataflow Job ・メトリクス: job/elapsed_time ・条件: 2時間以上（通常は1時間以内） 通知: ・Slack + メール 優先度: P2（重要）- 30分以内に確認 💡 処理時間が通常の2倍を超えたら、 何か問題が起きている可能性が高い

📊 アラート3: データロード件数の異常（P2）

条件: ・BigQueryテーブルの行数が前日比で50%以上減少 ・または、0件のデータロード 通知: ・メール 優先度: P2（重要） 💡 データが欠損している可能性を検知

STEP 3: ダッシュボードの作成

【監視ダッシュボードの構成】 ┌────────────────────────────────────────────────────┐ │ 📊 日次ETLパイプライン監視ダッシュボード │ ├────────────────────────────────────────────────────┤ │ │ │ ジョブ実行状態（今日） │ │ [成功: ●緑 5件] [失敗: ✕赤 0件] [実行中: ▶青 1件] │ │ │ ├────────────────────────────────────────────────────┤ │ 処理時間の推移（過去7日） │ データロード件数 │ │ [折れ線グラフ] │ [棒グラフ] │ │ ↗ 平均: 45分 │ 📈 今日: 125,000件 │ │ 📍 最大: 1時間20分 │ 📈 昨日: 123,500件 │ ├────────────────────────────────────────────────────┤ │ エラーログ（直近24時間） │ リソース使用率 │ │ [ログクエリ結果] │ [折れ線グラフ] │ │ ERROR: 0件 │ CPU: 45% │ │ WARNING: 3件 │ メモリ: 60% │ └────────────────────────────────────────────────────┘

STEP 4: インシデント対応手順の文書化

📝 インシデント対応フロー

  1. アラート受信：Slackまたはメールで通知を確認
  2. 状況確認：ダッシュボードで現在の状態を確認
  3. ログ調査：Cloud Loggingでエラーの詳細を確認
  4. 原因特定：エラーメッセージから原因を推測
  5. 対応：手動での再実行、コード修正など
  6. 事後報告：インシデントレポートを作成

📝 7. STEP 24 のまとめ

✅ このステップで学んだこと

  • モニタリングはシステムの健全性を保つために必須
  • CloudWatch（AWS）：メトリクス、ログ、アラーム、ダッシュボード
  • Cloud Monitoring（GCP）：メトリクスエクスプローラー、ロギング、アラート
  • 構造化ログ：JSON形式で出力して分析しやすく
  • アラート設計：優先度をつけて、アラート疲れを防ぐ
  • ダッシュボード：複数のメトリクスを可視化して一目で状況把握

💡 次のステップへ

モニタリングは「問題が起きてから慌てて設定する」ものではありません。
システム構築時から、最初から監視を組み込むことが重要です。

次のSTEP 25では、Infrastructure as Code（IaC）を学びます。
Terraformでインフラをコード化しましょう！

📝 練習問題

問題 1 基礎

モニタリングとロギングの違いを説明してください。

【解答】
  • モニタリング：システムの現在の状態を数値データ（メトリクス）で監視。例：CPU使用率、メモリ使用量。リアルタイムでアラートを発報
  • ロギング：システムの過去の動作をテキストデータ（ログ）で記録。例：エラーメッセージ、アクセスログ。トラブルシューティングや監査に使用
問題 2 基礎

ログレベルを低い順に並べてください：ERROR、DEBUG、INFO、CRITICAL、WARNING

【解答】

低い順（詳細度が高い順）：
DEBUG → INFO → WARNING → ERROR → CRITICAL

問題 3 応用

「アラート疲れ」を防ぐための3つの対策を挙げてください。

【解答例】
  1. しきい値を適切に設定：一時的なスパイクでアラートが出ないように、継続時間も考慮
  2. 優先度をつける：緊急度に応じて通知方法を変える（P1は電話、P3はメールのみなど）
  3. 誤検知を減らす：本当に問題があるときだけアラートが出るように条件を調整
問題 4 発展

データパイプラインで監視すべき項目を5つ挙げ、それぞれアラート条件を設定してください。

【解答例】
  1. ジョブの実行状態：失敗したら即座にアラート（P1）
  2. 処理時間：通常の2倍以上かかったらアラート（P2）
  3. データロード件数：前日比で50%以上減少したらアラート（P2）
  4. エラー率：全体の5%以上でエラーが発生したらアラート（P1）
  5. リソース使用率：CPU/メモリが90%を10分間超えたらアラート（P2）

❓ よくある質問

Q1: CloudWatchとCloud Monitoring、どちらが優れていますか？
どちらも優れたサービスです。使っているクラウド（AWS or GCP）に合わせて選ぶのが自然です。機能的にはほぼ同等で、どちらもメトリクス監視、ログ収集、アラート、ダッシュボードをサポートしています。
Q2: ログはどれくらいの期間保存すべきですか？
用途によります。アプリケーションログは30〜90日、セキュリティログは1年〜7年が一般的です。古いログはS3 Glacier/GCS Archiveに移行してコスト削減しましょう。コンプライアンス要件（GDPR、SOC2など）がある場合は、それに従ってください。
Q3: アラートの通知先は、どう設定すればいいですか？
優先度に応じて使い分けましょう。緊急（P1）は電話やSMS、重要（P2）はSlack、通常（P3）はメールなど。また、オンコールローテーションを組んで、担当者に確実に届くようにすることも重要です。
Q4: ダッシュボードは誰が見るべきですか？
チーム全員が見られるようにしましょう。エンジニアだけでなく、マネージャーやビジネス側の人も、システムの状態を把握できると良いです。ただし、技術的な詳細はエンジニア向け、ビジネスKPIは経営層向けなど、対象者に応じて複数のダッシュボードを作ることをおすすめします。
Q5: モニタリングツールは、CloudWatch/Cloud Monitoring以外にもありますか？
はい、サードパーティ製のツールも多数あります。例：
・Datadog：マルチクラウド対応、高機能
・New Relic：APM（アプリケーション性能監視）が強い
・Grafana + Prometheus：オープンソース、カスタマイズ性が高い
これらは有料ですが、より高度な機能を提供します。
Q6: 構造化ログ（JSON形式）は本当に必要ですか？
規模が大きくなるほど必要です。小規模なプロジェクトでは、プレーンテキストでも問題ありませんが、ログ量が増えると検索や集計が困難になります。最初から構造化ログを採用しておくと、後で分析がしやすくなります。
📝

学習メモ

クラウドデータ基盤（AWS・GCP） - Step 24

💾 自動保存 · 0文字
📋 過去のメモ一覧 ▼
ホーム
クラウドデータ基盤（AWS・GCP）