Datadog入門第3部 - インフラストラクチャ監視の実践マスターガイド

Datadogの基本設定を完了したら、次は本格的なインフラストラクチャ監視の実装です。本記事では、Infrastructure Monitoring機能の活用からメトリクス管理、効果的なダッシュボード作成まで、実践的なインフラ監視手法を段階的に解説します。モダンなクラウドネイティブ環境からレガシーシステムまで、あらゆるインフラでDatadogを最大限活用するための包括的ガイドです。

3.1 Infrastructure Monitoring

Infrastructure Monitoringの概要と活用シナリオ

Infrastructure Monitoringとは

Infrastructure Monitoringは、Datadogの中核機能の一つで、物理・仮想・クラウドインフラストラクチャ全体の統合監視を実現します。従来のサイロ化された監視ツールとは異なり、単一プラットフォームで全レイヤーの可視化が可能です。

yaml

# Infrastructure Monitoringの監視対象
物理インフラ:
  - オンプレミスサーバー (Linux/Windows/macOS)
  - ネットワーク機器 (スイッチ、ルーター、ファイアウォール)
  - ストレージシステム (SAN/NAS)

仮想化環境:
  - VMware vSphere
  - Hyper-V
  - KVM/QEMU

コンテナ環境:
  - Docker コンテナ
  - Kubernetes クラスター
  - OpenShift

クラウドサービス:
  - AWS (EC2、ECS、Fargate、Lambda等)
  - Azure (Virtual Machines、AKS、Functions等)
  - GCP (Compute Engine、GKE、Cloud Functions等)

従来監視との比較優位性

機能領域	従来監視ツール	Datadog Infrastructure Monitoring
統合性	ツール毎の分離	統一プラットフォーム
スケーラビリティ	手動スケーリング	自動スケーリング対応
可視化	静的グラフ	動的・インタラクティブ
アラート	閾値ベース	機械学習ベース異常検知
クラウド対応	限定的	ネイティブ統合

ホストマップの活用方法

ホストマップの基本概念

ホストマップ（Host Map）は、インフラストラクチャ全体をヒートマップ形式で可視化する革新的な機能です。数百台から数万台のホストの状態を一目で把握できます。

yaml

# ホストマップの主要機能
可視化要素:
  - 色: メトリクス値を色で表現
  - サイズ: ホストの重要度やリソース使用量
  - グルーピング: タグベースの自動分類
  - フィルタリング: 条件による表示制御

表示可能メトリクス:
  - CPU使用率
  - メモリ使用率
  - ディスクI/O
  - ネットワーク転送量
  - カスタムメトリクス

実践的なホストマップ活用例

1. 大規模クラスター状態の監視

bash

# タグベースのグルーピング設定例
# インフラをサービス・環境・AZ別に可視化

# タグ付け戦略
Group by: service, env, availability_zone

# 表示設定
Color by: system.cpu.user (CPU使用率)
Size by: system.mem.total (メモリ総量)
Filter: env:production AND service:web

2. 異常ホストの即座特定

yaml

# 異常検知のためのホストマップ設定
異常パターン:
  高CPU使用率:
    条件: "CPU > 80%"
    色: 赤色表示
    アクション: "自動調査開始"
  
  メモリリーク疑い:
    条件: "Memory growth > 10%/hour"
    色: オレンジ表示
    アクション: "アラート送信"
  
  ディスク容量不足:
    条件: "Disk usage > 90%"
    色: 紫色表示
    アクション: "緊急通知"

コンテナ監視 (Docker、Kubernetes)

Docker コンテナ監視

Docker環境での包括的監視を実現するDatadogの機能は、従来の静的なホスト監視を超えた動的監視を提供します。

yaml

# Docker Agent設定
version: '3.8'
services:
  datadog-agent:
    image: gcr.io/datadoghq/agent:latest
    environment:
      - DD_API_KEY=${DD_API_KEY}
      - DD_SITE=datadoghq.com
      - DD_CONTAINER_EXCLUDE="name:datadog-agent"
      - DD_DOCKER_LABELS_AS_TAGS='{"environment":"env","version":"version"}'
      - DD_LOGS_ENABLED=true
      - DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL=true
      - DD_PROCESS_AGENT_ENABLED=true
      - DD_APM_ENABLED=true
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /proc/:/host/proc/:ro
      - /opt/datadog-agent/run:/opt/datadog-agent/run:rw
      - /sys/fs/cgroup/:/host/sys/fs/cgroup:ro
    privileged: true

Docker固有メトリクス収集

bash

# 重要なDockerメトリクス例
docker.containers.running          # 稼働コンテナ数
docker.containers.stopped          # 停止コンテナ数
docker.cpu.usage                   # CPU使用率
docker.memory.usage                # メモリ使用量
docker.memory.limit                # メモリ制限
docker.io.read_bytes               # ディスク読み取り
docker.io.write_bytes              # ディスク書き込み
docker.net.bytes_rcvd              # ネットワーク受信
docker.net.bytes_sent              # ネットワーク送信

Kubernetes クラスター監視

Kubernetes環境の完全監視には、クラスター全体の健全性、個別ポッドの状態、リソース利用効率の最適化が重要です。

yaml

# Kubernetes Agent DaemonSet設定
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: datadog-agent
  namespace: default
spec:
  selector:
    matchLabels:
      app: datadog-agent
  template:
    metadata:
      labels:
        app: datadog-agent
    spec:
      containers:
      - name: datadog-agent
        image: gcr.io/datadoghq/agent:latest
        env:
        - name: DD_API_KEY
          valueFrom:
            secretKeyRef:
              name: datadog-secret
              key: api-key
        - name: DD_COLLECT_KUBERNETES_EVENTS
          value: "true"
        - name: DD_LEADER_ELECTION
          value: "true"
        - name: DD_KUBERNETES_KUBELET_HOST
          valueFrom:
            fieldRef:
              fieldPath: status.hostIP
        - name: DD_CLUSTER_AGENT_ENABLED
          value: "true"
        volumeMounts:
        - name: dockersocket
          mountPath: /var/run/docker.sock
        - name: procdir
          mountPath: /host/proc
        - name: cgroups
          mountPath: /host/sys/fs/cgroup
      volumes:
      - name: dockersocket
        hostPath:
          path: /var/run/docker.sock
      - name: procdir
        hostPath:
          path: /proc
      - name: cgroups
        hostPath:
          path: /sys/fs/cgroup

Kubernetes固有の監視ポイント

yaml

# クラスターレベル監視
Cluster Health:
  - Node Ready状態
  - Pod成功率
  - Deployment可用性
  - Service正常性

Resource Monitoring:
  - CPU/Memory Requests vs Limits
  - Node容量使用率
  - PersistentVolume状態
  - NetworkPolicy適用状況

Application Level:
  - Pod Restart回数
  - Container起動時間
  - HPA動作状況
  - ImagePull成功率

クラウドインテグレーション (AWS、Azure、GCP)

AWS統合の詳細設定

Amazon Web Servicesとの深い統合により、AWS固有のメトリクスとDatadogの統合監視を実現します。

yaml

# AWS統合設定例
AWS Services Integration:
  Core Compute:
    - EC2: インスタンス監視、Auto Scaling
    - ECS: コンテナサービス監視
    - EKS: Kubernetes on AWS
    - Lambda: サーバーレス監視
    
  Storage & Database:
    - RDS: データベース性能監視
    - DynamoDB: NoSQL監視
    - S3: オブジェクトストレージ監視
    - EBS: ブロックストレージ監視
    
  Networking:
    - VPC: ネットワーク監視
    - CloudFront: CDN監視
    - Route53: DNS監視
    - ELB/ALB: ロードバランサー監視

AWS IAM Role設定例

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "cloudwatch:List*",
        "cloudwatch:Get*",
        "ec2:Describe*",
        "support:*",
        "tag:GetResources",
        "tag:GetTagKeys",
        "tag:GetTagValues"
      ],
      "Resource": "*"
    }
  ]
}

Azure統合の実装

Microsoft Azure環境での統合監視設定により、Azure固有のサービスを包括的に監視します。

bash

# Azure CLI を使用したサービスプリンシパル作成
az ad sp create-for-rbac \
  --role "Monitoring Reader" \
  --scopes /subscriptions/{subscription-id} \
  --name datadog-integration

# 出力例
{
  "appId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
  "displayName": "datadog-integration",
  "name": "http://datadog-integration",
  "password": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
  "tenant": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
}

GCP統合の設定

Google Cloud Platformとの統合により、GCP特有のサービスメトリクスを効率的に収集します。

yaml

# GCP統合で監視可能なサービス
GCP Services:
  Compute:
    - Compute Engine
    - Google Kubernetes Engine (GKE)
    - Cloud Functions
    - App Engine
    
  Storage:
    - Cloud Storage
    - Cloud SQL
    - Bigtable
    - Firestore
    
  Networking:
    - VPC
    - Cloud Load Balancing
    - Cloud CDN
    - Cloud DNS

ネットワーク監視の基礎

Network Performance Monitoring (NPM)

Datadog NPMは、アプリケーション層からネットワーク層まで、エンドツーエンドの通信フローを可視化します。

yaml

# NPM設定例
NPM Configuration:
  収集データ:
    - フローデータ: 送信元/送信先IP、ポート情報
    - レイテンシ: RTT (Round Trip Time)
    - スループット: 帯域使用率
    - パケットロス: 損失率とパターン
  
  可視化機能:
    - Network Map: トポロジカル表示
    - Flow Analysis: 通信パターン分析
    - Dependency Tracking: サービス依存関係
    - Performance Bottleneck: ボトルネック特定

ネットワークアラート設定例

bash

# 高レイテンシアラート
Alert Name: "High Network Latency"
Condition: avg(last_5m):avg:network.tcp.rtt{*} > 200
Message: |
  Network latency is high (>200ms)
  
  Current RTT: {{value}}ms
  
  Investigation steps:
  1. Check network topology in NPM
  2. Verify bandwidth utilization
  3. Examine packet loss patterns
  
  Runbook: https://company.com/runbooks/network-latency

プロセス監視とサービス発見

Process Monitoring

プロセスレベルの詳細監視により、システムの内部動作を深く理解できます。

yaml

# Process Agent設定
datadog.yaml configuration:
process_config:
  enabled: "true"
  scrub_args: true
  custom_sensitive_words: 
    - "password"
    - "token"
    - "key"
  blacklist_patterns:
    - ".*ssh.*"
    - ".*vpn.*"

重要プロセスメトリクス

bash

# プロセス監視の主要メトリクス
process.cpu_percent              # CPU使用率
process.memory.rss               # Resident Set Size
process.memory.vms               # Virtual Memory Size
process.open_file_descriptors    # ファイルディスクリプタ数
process.threads                  # スレッド数
process.context_switches         # コンテキストスイッチ数
process.load.1                   # 1分平均ロードアベレージ
process.load.5                   # 5分平均ロードアベレージ
process.load.15                  # 15分平均ロードアベレージ

Service Discovery

自動サービス発見により、動的環境でのサービス把握を自動化します。

yaml

# サービス発見設定
Service Discovery:
  対象環境:
    - Kubernetes Services
    - Docker Containers
    - AWS ECS Tasks
    - Consul Services
    
  発見情報:
    - Service名と版数
    - エンドポイントURL
    - 依存関係マッピング
    - 稼働インスタンス数
  
  自動タグ付け:
    - service:web-frontend
    - version:v1.2.3
    - env:production
    - team:platform

3.2 メトリクス管理

メトリクスの種類と特徴

Datadogメトリクスの分類体系

Datadogでは、4つの主要メトリクスタイプでシステムの状態を包括的に表現します。

yaml

# メトリクスタイプの詳細分類
COUNT (カウント):
  説明: "イベントの総発生回数"
  用途: "API呼び出し数、エラー発生回数"
  集約方法: "合計値 (SUM)"
  例: "web.requests.total, error.count"
  
RATE (レート):
  説明: "単位時間あたりの発生頻度"
  用途: "秒間リクエスト数、分間エラー率"
  集約方法: "平均値 (AVG)"
  例: "web.requests.rate, error.rate"
  
GAUGE (ゲージ):
  説明: "特定時点での値"
  用途: "CPU使用率、メモリ使用量"
  集約方法: "最新値または平均値"
  例: "system.cpu.usage, system.memory.used"
  
HISTOGRAM (ヒストグラム):
  説明: "値の分布統計"
  用途: "レスポンス時間分布、サイズ分布"
  集約方法: "パーセンタイル (p50, p90, p99)"
  例: "request.duration, file.size"

メトリクス精度とサンプリング戦略

yaml

# メトリクス精度設定
Resolution Settings:
  High Resolution (1秒):
    - リアルタイム監視が必要
    - 一時的な異常検知
    - コスト: 高
    
  Standard Resolution (10-60秒):
    - 通常の性能監視
    - トレンド分析
    - コスト: 中
    
  Low Resolution (5-15分):
    - 長期トレンド監視
    - レポート作成
    - コスト: 低

Sampling Strategy:
  Critical Metrics: 100% sampling
  Standard Metrics: 10% sampling
  Debug Metrics: 1% sampling

カスタムメトリクスの作成

DogStatsD を使用したメトリクス送信

DogStatsDは、アプリケーションから直接カスタムメトリクスを送信するための高性能プロトコルです。

python

# Python でのカスタムメトリクス送信例
from datadog import DogStatsdClient

# DogStatsD クライアント初期化
statsd = DogStatsdClient(
    host='localhost',
    port=8125,
    namespace='myapp',
    constant_tags=['env:production', 'service:user-api']
)

# 各種メトリクスタイプの送信
class UserAPIMetrics:
    def __init__(self, statsd_client):
        self.statsd = statsd_client
    
    def record_login_attempt(self, user_type, success):
        # COUNT: ログイン試行回数
        self.statsd.increment(
            'login.attempts',
            tags=[f'user_type:{user_type}', f'success:{success}']
        )
    
    def record_response_time(self, endpoint, duration):
        # HISTOGRAM: API応答時間
        self.statsd.histogram(
            'api.response_time',
            duration,
            tags=[f'endpoint:{endpoint}']
        )
    
    def update_active_users(self, count):
        # GAUGE: アクティブユーザー数
        self.statsd.gauge('users.active', count)
    
    def record_database_query_rate(self):
        # RATE: データベースクエリレート
        self.statsd.increment('database.queries.rate')

# 使用例
metrics = UserAPIMetrics(statsd)
metrics.record_login_attempt('premium', True)
metrics.record_response_time('/api/users', 0.150)
metrics.update_active_users(1250)

アプリケーション埋め込みメトリクス

java

// Java アプリケーションでのメトリクス実装
import com.timgroup.statsd.StatsDClient;
import com.timgroup.statsd.NonBlockingStatsDClient;

public class ECommerceMetrics {
    private final StatsDClient statsd;
    
    public ECommerceMetrics() {
        this.statsd = new NonBlockingStatsDClient(
            "ecommerce",
            "datadog-agent",
            8125,
            new String[]{"service:checkout", "env:production"}
        );
    }
    
    public void recordPurchase(double amount, String category) {
        // ビジネスメトリクス: 購入金額
        statsd.histogram("purchase.amount", amount, 
            "category:" + category);
        
        // ビジネスメトリクス: 購入回数
        statsd.increment("purchase.count", 
            "category:" + category);
    }
    
    public void recordInventoryLevel(String productId, int stock) {
        // 在庫レベル監視
        statsd.gauge("inventory.level", stock, 
            "product:" + productId);
        
        // 在庫切れアラート
        if (stock == 0) {
            statsd.increment("inventory.stockout", 
                "product:" + productId);
        }
    }
    
    public void recordUserEngagement(String action, String userId) {
        // ユーザーエンゲージメント
        statsd.increment("user.engagement", 
            "action:" + action, "user_segment:premium");
    }
}

メトリクス集約とタグ戦略

戦略的タグ設計

効果的なタグ戦略は、メトリクスの価値を最大化し、分析効率を向上させます。

yaml

# 推奨タグ階層設計
Primary Tags (必須):
  - env: [production, staging, development]
  - service: [user-api, order-service, payment-gateway]
  - version: [v1.2.3, v1.2.4]
  
Secondary Tags (分析用):
  - team: [platform, mobile, data]
  - datacenter: [us-east-1, eu-west-1, ap-northeast-1]
  - instance_type: [t3.medium, m5.large, c5.xlarge]
  
Business Tags (ビジネス分析):
  - customer_tier: [free, premium, enterprise]
  - feature_flag: [new-checkout, old-checkout]
  - experiment: [test-a, test-b, control]

# タグのベストプラクティス
Best Practices:
  命名規則:
    - 小文字使用: "env:production" (not "Env:Production")
    - ケバブケース: "instance-type:t3-medium"
    - 意味のある名前: "payment-method:credit-card"
  
  カーディナリティ制御:
    - 高カーディナリティ回避: user_id, session_id等は除外
    - 適切な粒度: 必要最小限のタグセット
    - 動的値の制限: 無制限に増加する値は避ける

集約ルールの設計

yaml

# メトリクス集約戦略
Aggregation Rules:
  Space Aggregation (空間集約):
    Method: "タグによるグループ化"
    例: "avg by service"
    用途: "サービス別平均応答時間"
  
  Time Aggregation (時間集約):
    Method: "時間窓での統計計算"
    例: "5分間の平均値"
    用途: "短期変動の平滑化"
  
  Advanced Aggregation:
    Rollup: "カスタム時間窓集約"
    Arithmetic: "メトリクス間演算"
    Functions: "rate(), diff(), derivative()"

# 実践的な集約クエリ例
Query Examples:
  # サービス別エラー率
  "sum:error.count{service:*}.as_rate() / sum:request.count{service:*}.as_rate()"
  
  # リージョン別レイテンシ分布
  "avg:request.duration{*} by {region}"
  
  # 前週同時刻との比較
  "avg:cpu.usage{*}, avg:cpu.usage{*}.timeshift(604800)"

メトリクス保持期間と課金への影響

保持期間ポリシー

Datadogのメトリクス保持期間は、データの価値と運用コストのバランスを考慮して設計します。

yaml

# Datadog標準保持期間
Retention Periods:
  High Resolution (1秒間隔):
    保持期間: "30分"
    用途: "リアルタイム監視、障害対応"
    コスト影響: "最高"
  
  Standard Resolution (1分間隔):
    保持期間: "15ヶ月"
    用途: "通常監視、分析"
    コスト影響: "標準"
  
  Downsampled Resolution:
    1時間間隔: "15ヶ月"
    1日間隔: "無制限"
    用途: "長期トレンド、年次レポート"
    コスト影響: "最低"

# カスタム保持期間設定
Custom Retention:
  Critical Business Metrics:
    期間: "24ヶ月"
    解像度: "1分"
    理由: "コンプライアンス要件"
  
  Debug Metrics:
    期間: "7日"
    解像度: "1分"
    理由: "短期トラブルシューティング用"
  
  Historical Analytics:
    期間: "無制限"
    解像度: "1日"
    理由: "長期ビジネス分析"

コスト最適化戦略

yaml

# メトリクスコスト最適化
Cost Optimization:
  メトリクス量削減:
    不要メトリクス除外:
      - テスト環境の詳細メトリクス
      - 廃止サービスのメトリクス
      - 重複メトリクス
    
    サンプリング率調整:
      - 本番環境: 100%
      - ステージング: 50%
      - 開発環境: 10%
  
  タグ最適化:
    高カーディナリティタグ削除:
      - user_id, session_id
      - timestamp, random_id
      - full_url_path
    
    必要最小限タグセット:
      - 分析に必要なタグのみ保持
      - ビジネス価値の高いタグ優先
      - 定期的なタグ監査実施

# 月次コスト見積もり例
Cost Estimation:
  前提条件:
    - ホスト数: 100台
    - カスタムメトリクス: 500個
    - 月間データポイント: 1000万個
  
  計算:
    Infrastructure Monitoring: "$15 × 100 = $1,500"
    カスタムメトリクス: "$0.05 × 500 = $25"
    合計月額: "$1,525"

メトリクス検索とフィルタリング

高度な検索クエリ

効率的なメトリクス検索により、大量のデータから必要な情報を素早く抽出できます。

bash

# 基本検索パターン
# サービス別CPU使用率
system.cpu.user{service:web-frontend}

# 複数条件でのフィルタリング
system.memory.used{env:production AND service:database}

# 正規表現を使用した検索
nginx.requests{endpoint:/api/v[0-9]+/users}

# 除外条件を含む検索
docker.containers.running{* AND !service:test*}

# 時間範囲を指定した検索
avg:request.duration{*}[5m ago:now]

動的フィルタリング

yaml

# Template Variables活用
Dashboard Template Variables:
  $service:
    Type: "Tag Values"
    Tag: "service"
    Default: "*"
    Multi-select: "enabled"
  
  $env:
    Type: "Tag Values"
    Tag: "env"
    Default: "production"
    Multi-select: "disabled"
  
  $region:
    Type: "Tag Values"
    Tag: "region"
    Default: "us-east-1"
    Multi-select: "enabled"

# クエリでのテンプレート変数使用
Query: "avg:system.cpu.user{service:$service,env:$env,region:$region}"

3.3 ダッシュボード作成

ダッシュボードの設計原則

効果的ダッシュボード設計の法則

優れたダッシュボードは、情報の階層化と視覚的な明確さにより、迅速な意思決定を支援します。

yaml

# ダッシュボード設計の5つの原則
Design Principles:
  1. Purpose-Driven (目的主導):
    - 明確な対象ユーザー定義
    - 特定の問題解決にフォーカス
    - アクション可能な情報提供
  
  2. Information Hierarchy (情報階層):
    - 最重要情報を上部配置
    - 詳細情報は下部に配置
    - 関連情報をグループ化
  
  3. Visual Clarity (視覚的明確さ):
    - 適切な色使い
    - 読みやすいフォント
    - 十分な余白確保
  
  4. Responsive Design (レスポンシブ設計):
    - モバイル対応
    - 画面サイズ適応
    - 情報密度の最適化
  
  5. Actionable Insights (アクション可能な洞察):
    - 閾値の明確化
    - トレンド表示
    - 比較情報提供

ダッシュボードタイプ別設計指針

yaml

# 用途別ダッシュボード設計
Dashboard Types:
  Executive Dashboard (経営層向け):
    更新頻度: "日次/週次"
    表示期間: "30日/90日"
    重要指標:
      - 全体サービス可用性
      - ビジネスKPI
      - 重大インシデント数
      - コスト効率
    
    視覚化:
      - 大きな数値表示
      - 傾向を示すシンプルなグラフ
      - ステータスインジケーター
      - 前期比較

  Operations Dashboard (運用チーム向け):
    更新頻度: "リアルタイム"
    表示期間: "1時間/24時間"
    重要指標:
      - システム健全性
      - アラート状況
      - リソース使用率
      - サービス依存関係
    
    視覚化:
      - ヒートマップ
      - 時系列グラフ
      - トポロジマップ
      - アラートリスト

  Development Dashboard (開発チーム向け):
    更新頻度: "リアルタイム/分次"
    表示期間: "1時間/7日"
    重要指標:
      - アプリケーション性能
      - エラー率
      - デプロイメント状況
      - 機能使用状況
    
    視覚化:
      - 詳細時系列グラフ
      - エラー詳細テーブル
      - パフォーマンス分布
      - A/Bテスト結果

ウィジェットの種類と使い分け

主要ウィジェット詳細ガイド

Datadogでは、20種類以上の専用ウィジェットで多様なデータ可視化ニーズに対応します。

yaml

# 数値表示ウィジェット
Value Widgets:
  Query Value:
    用途: "単一メトリクスの現在値表示"
    最適ケース: "アクティブユーザー数、エラー率"
    設定: "大きなフォント、色による閾値表示"
    
  Table:
    用途: "複数メトリクスの詳細比較"
    最適ケース: "サービス別性能比較、エラー詳細"
    設定: "ソート可能、条件付きフォーマット"
    
  List:
    用途: "上位/下位N項目の表示"
    最適ケース: "最も使用率の高いホスト"
    設定: "自動ソート、制限数設定"

# グラフ表示ウィジェット
Graph Widgets:
  Timeseries:
    用途: "時間経過による変化表示"
    最適ケース: "CPU使用率、応答時間トレンド"
    設定: "複数メトリクス重ね合わせ、Y軸スケール"
    
  Heatmap:
    用途: "2次元データの密度表示"
    最適ケース: "応答時間分布、アクセスパターン"
    設定: "色スケール、時間粒度"
    
  Distribution:
    用途: "値の分布状況表示"
    最適ケース: "レイテンシ分布、ファイルサイズ分布"
    設定: "パーセンタイル表示、区間設定"

実践的ウィジェット設定例

yaml

# SREダッシュボード向けウィジェット構成
SRE Dashboard Widgets:
  Service Level Indicators:
    Widget: "Query Value"
    メトリクス: "sum:request.success{*} / sum:request.total{*} * 100"
    表示: "99.95%"
    閾値:
      - Green: "> 99.9%"
      - Yellow: "99.0% - 99.9%"
      - Red: "< 99.0%"
    
  Error Rate Trend:
    Widget: "Timeseries"
    メトリクス: 
      - "rate(error.count{*})"
      - "rate(request.count{*})"
    表示期間: "24時間"
    Y軸: "ログスケール"
    
  Response Time Distribution:
    Widget: "Heatmap"
    メトリクス: "request.duration{*}"
    集約: "パーセンタイル(p50, p90, p99)"
    時間粒度: "5分"
    
  Top Errors:
    Widget: "Table"
    メトリクス: "sum:error.count{*} by {error_type}"
    ソート: "降順"
    表示数: "上位10件"
    リンク: "ログ詳細画面へ"

テンプレート変数の活用

動的ダッシュボードの実装

テンプレート変数により、一つのダッシュボードで複数の視点からの分析が可能になります。

yaml

# 包括的テンプレート変数設定
Template Variables Configuration:
  環境選択:
    Variable Name: "$env"
    Type: "Tag Values"
    Tag Key: "env"
    Default Value: "production"
    Multi-select: false
    Include All: false
    
  サービス選択:
    Variable Name: "$service"
    Type: "Tag Values"
    Tag Key: "service"
    Query Filter: "env:$env"
    Default Value: "*"
    Multi-select: true
    Include All: true
    
  時間範囲:
    Variable Name: "$timeframe"
    Type: "Custom"
    Options:
      - "1h": "過去1時間"
      - "24h": "過去24時間"
      - "7d": "過去7日"
      - "30d": "過去30日"
    Default Value: "24h"
    
  リージョン:
    Variable Name: "$region"
    Type: "Tag Values"
    Tag Key: "region"
    Query Filter: "env:$env AND service:$service"
    Default Value: "*"
    Multi-select: true
    Include All: true

高度なテンプレート変数活用

bash

# 連動するテンプレート変数の実装
# メインクエリでのテンプレート変数使用
avg:system.cpu.user{env:$env,service:$service,region:$region}

# 条件付きフィルタリング
avg:request.duration{env:$env,$service,$region} by {endpoint}

# 動的タイトル生成
Title: "CPU使用率 - $env環境 $serviceサービス"

# 複数値対応
avg:memory.usage{service:$service.in($service_list)}

チーム共有とアクセス制御

組織レベルでのダッシュボード管理

エンタープライズ環境では、適切なアクセス制御と共有戦略が重要です。

yaml

# アクセス制御階層
Access Control Hierarchy:
  Organization Level:
    - 管理者: 全ダッシュボード管理権限
    - メンバー: 閲覧および作成権限
    - 読み取り専用: 閲覧のみ
    
  Team Level:
    - チームオーナー: チーム内ダッシュボード管理
    - チームメンバー: チーム内ダッシュボード編集
    - 外部コラボレーター: 特定ダッシュボード閲覧
    
  Dashboard Level:
    - 作成者: 完全な編集権限
    - 編集者: 内容編集権限
    - 閲覧者: 表示のみ権限

# 実践的共有設定
Sharing Configuration:
  社内共有:
    Public Link: "認証なしアクセス"
    Organization内: "組織メンバーのみ"
    Team限定: "特定チームのみ"
    
  外部共有:
    読み取り専用リンク: "時間制限付き"
    PDFエクスポート: "定期自動送信"
    Slack統合: "アラート時自動投稿"

モバイル対応ダッシュボード

レスポンシブ設計の実装

モバイルデバイス対応により、場所を選ばない監視体制を構築できます。

yaml

# モバイル最適化設計
Mobile Optimization:
  レイアウト調整:
    - 縦並び配置優先
    - タッチ操作対応
    - 拡大縮小可能
    
  情報密度:
    - 重要指標に絞り込み
    - 大きなフォント使用
    - 簡潔なラベル
    
  操作性:
    - スワイプナビゲーション
    - 簡易フィルタリング
    - クイックアクション

# モバイル専用ダッシュボード例
Mobile Dashboard Structure:
  Header Section:
    - サービス状態概要
    - 重要アラート数
    - 現在時刻とタイムゾーン
    
  Key Metrics Section:
    - 可用性 (大きな%表示)
    - エラー率 (色付きインジケーター)
    - 応答時間 (トレンド付き)
    
  Quick Actions Section:
    - インシデント作成
    - オンコール確認
    - 詳細ダッシュボードリンク

# Datadog Mobileアプリ活用
Mobile App Features:
  プッシュ通知:
    - 重要アラート即座通知
    - インシデント更新通知
    - SLA違反警告
    
  オフライン機能:
    - 最新データキャッシュ
    - 基本操作継続可能
    - 同期自動復旧
    
  統合機能:
    - PagerDuty連携
    - Slack通知
    - カレンダー統合

まとめ

第3部では、DatadogのInfrastructure Monitoring、メトリクス管理、ダッシュボード作成の実践的活用方法を詳しく解説しました。

主要ポイントの再確認

yaml

Infrastructure Monitoring:
  ✅ ホストマップによる全体俯瞰
  ✅ コンテナ・K8s環境の深い監視
  ✅ マルチクラウド統合監視
  ✅ ネットワーク・プロセス監視

メトリクス管理:
  ✅ 4つのメトリクスタイプ活用
  ✅ カスタムメトリクス戦略的設計
  ✅ タグベース効率的分析
  ✅ コスト最適化手法

ダッシュボード作成:
  ✅ 目的別設計原則
  ✅ 20種類以上ウィジェット活用
  ✅ テンプレート変数による動的化
  ✅ モバイル対応レスポンシブ設計

次のステップ

Infrastructure Monitoringの基盤構築完了後は、第4部：アプリケーション監視編にて、APM（Application Performance Monitoring）とRUM（Real User Monitoring）の実装に進みます。これにより、インフラからアプリケーション、そしてエンドユーザーまでのエンドツーエンド可視化が実現されます。

組織のオブザーバビリティ成熟度向上に向けて、段階的かつ戦略的にDatadogを活用していきましょう。

Datadog入門 第3部 - インフラストラクチャ監視の実践マスターガイド ​

3.1 Infrastructure Monitoring ​

Infrastructure Monitoringの概要と活用シナリオ ​

Infrastructure Monitoringとは ​

従来監視との比較優位性 ​

ホストマップの活用方法 ​

ホストマップの基本概念 ​

実践的なホストマップ活用例 ​

コンテナ監視 (Docker、Kubernetes) ​

Docker コンテナ監視 ​

Kubernetes クラスター監視 ​

クラウドインテグレーション (AWS、Azure、GCP) ​

AWS統合の詳細設定 ​

Azure統合の実装 ​

GCP統合の設定 ​

ネットワーク監視の基礎 ​

Network Performance Monitoring (NPM) ​

プロセス監視とサービス発見 ​

Process Monitoring ​

Service Discovery ​

3.2 メトリクス管理 ​

メトリクスの種類と特徴 ​

Datadogメトリクスの分類体系 ​

メトリクス精度とサンプリング戦略 ​

カスタムメトリクスの作成 ​

DogStatsD を使用したメトリクス送信 ​

アプリケーション埋め込みメトリクス ​

メトリクス集約とタグ戦略 ​

戦略的タグ設計 ​

集約ルールの設計 ​

メトリクス保持期間と課金への影響 ​

保持期間ポリシー ​

コスト最適化戦略 ​

メトリクス検索とフィルタリング ​

高度な検索クエリ ​

動的フィルタリング ​

3.3 ダッシュボード作成 ​

ダッシュボードの設計原則 ​

効果的ダッシュボード設計の法則 ​

ダッシュボードタイプ別設計指針 ​

ウィジェットの種類と使い分け ​

主要ウィジェット詳細ガイド ​

実践的ウィジェット設定例 ​

テンプレート変数の活用 ​

動的ダッシュボードの実装 ​

高度なテンプレート変数活用 ​

チーム共有とアクセス制御 ​

組織レベルでのダッシュボード管理 ​

モバイル対応ダッシュボード ​

レスポンシブ設計の実装 ​

まとめ ​

主要ポイントの再確認 ​

次のステップ ​

Datadog入門第3部 - インフラストラクチャ監視の実践マスターガイド

3.1 Infrastructure Monitoring

Infrastructure Monitoringの概要と活用シナリオ

Infrastructure Monitoringとは

従来監視との比較優位性

ホストマップの活用方法

ホストマップの基本概念

実践的なホストマップ活用例

コンテナ監視 (Docker、Kubernetes)

Docker コンテナ監視

Kubernetes クラスター監視

クラウドインテグレーション (AWS、Azure、GCP)

AWS統合の詳細設定

Azure統合の実装

GCP統合の設定

ネットワーク監視の基礎

Network Performance Monitoring (NPM)

プロセス監視とサービス発見

Process Monitoring

Service Discovery

3.2 メトリクス管理

メトリクスの種類と特徴

Datadogメトリクスの分類体系

メトリクス精度とサンプリング戦略

カスタムメトリクスの作成

DogStatsD を使用したメトリクス送信

アプリケーション埋め込みメトリクス

メトリクス集約とタグ戦略

戦略的タグ設計

集約ルールの設計

メトリクス保持期間と課金への影響

保持期間ポリシー

コスト最適化戦略

メトリクス検索とフィルタリング

高度な検索クエリ

動的フィルタリング

3.3 ダッシュボード作成

ダッシュボードの設計原則

効果的ダッシュボード設計の法則

ダッシュボードタイプ別設計指針

ウィジェットの種類と使い分け

主要ウィジェット詳細ガイド

実践的ウィジェット設定例

テンプレート変数の活用

動的ダッシュボードの実装

高度なテンプレート変数活用

チーム共有とアクセス制御

組織レベルでのダッシュボード管理

モバイル対応ダッシュボード

レスポンシブ設計の実装

まとめ

主要ポイントの再確認

次のステップ