New Relicログ転送設定の完全ガイド - 効率的なログ収集の実装

New Relicのログ監視機能を活用するためには、アプリケーションやインフラストラクチャから生成されるログデータを効率的にNew Relicプラットフォームに転送する必要があります。本記事では、様々なログ転送方法の設定手順と、実運用における最適化手法について詳しく解説します。

ログ転送の基本概念

New Relicへのログ転送は、ログデータをソースシステムからNew Relicプラットフォームに送信するプロセスです。このプロセスには、ログの収集、前処理、フォーマット変換、送信という4つの主要なステップが含まれます。

ログ転送の方式

New Relicでは、以下の主要な転送方式を提供しています。

Infrastructure Agentによる直接転送は、最も簡単で効率的な方法です。既にInfrastructure Agentが導入されている環境では、追加のツールを導入することなくログ転送を開始できます。

専用ログシッパーによる転送では、Fluentd、Logstash、Filebeat、fluent-bit、vectorなどの専用ツールを使用します。これらのツールは高度な前処理機能と柔軟な設定オプションを提供します。

APM Agentによる直接転送では、アプリケーションから直接ログをNew Relicに送信できます。アプリケーションログとAPMデータの自動的な関連付けが可能になります。

REST APIによる直接送信では、カスタムアプリケーションやスクリプトから直接New Relic Logs APIにログデータを送信できます。

Infrastructure Agentを使用したログ転送設定

Infrastructure Agentを使用したログ転送は、最も一般的で推奨される方法です。設定ファイルの変更だけで簡単に始められます。

基本設定の実装

Infrastructure Agentの設定ディレクトリ（通常は/etc/newrelic-infra/logging.d/）に、ログ設定ファイルを作成します。

yaml

logs:
  - name: "application-logs"
    file: "/var/log/myapp/*.log"
    attributes:
      service: "myapp"
      environment: "production"
      logtype: "application"

この基本設定では、/var/log/myapp/ディレクトリ内のすべてのログファイルが監視対象となり、各ログエントリにはサービス名、環境、ログタイプの属性が付与されます。

高度な設定オプション

より複雑な要件に対応するため、以下の高度な設定オプションが利用できます。

マルチライン処理では、JavaやPythonのスタックトレースなど、複数行にわたるログエントリを適切に処理できます。

yaml

logs:
  - name: "java-application-logs"
    file: "/var/log/java-app/application.log"
    pattern: "^\\d{4}-\\d{2}-\\d{2}"
    attributes:
      service: "java-backend"
      logtype: "application"

フィルタリング設定により、特定のパターンにマッチするログのみを転送できます。これによりログ量の制御とコスト最適化が可能になります。

yaml

logs:
  - name: "error-logs-only"
    file: "/var/log/app/error.log"
    attributes:
      service: "webapp"
      severity: "error"

Docker環境での設定

コンテナ環境では、ログの収集方法が若干異なります。Docker コンテナのログを収集する場合の設定例を示します。

yaml

logs:
  - name: "docker-containers"
    file: "/var/lib/docker/containers/*/*.log"
    attributes:
      container_type: "docker"
      log_source: "container_stdout"
    pattern: "^{\"log\""

Dockerコンテナのログは通常JSON形式で出力されるため、適切なパターンマッチングが重要です。

ログ属性とメタデータの設定

ログデータの価値を最大化するためには、適切な属性とメタデータの設定が重要です。これらの情報により、ログの検索、フィルタリング、分析が効率化されます。

標準属性の設定

New Relicでは、以下の標準属性の設定を推奨しています。

service属性は、ログを生成するサービスやアプリケーションを識別します。マイクロサービス環境では特に重要な属性です。

environment属性は、開発、ステージング、本番などの環境を区別するために使用します。

version属性は、アプリケーションのバージョンを追跡し、デプロイメントに関連する問題の特定に役立ちます。

hostname属性は、ログを生成したホストを識別し、インフラストラクチャデータとの関連付けを可能にします。

カスタム属性の活用

ビジネス固有の要件に応じて、カスタム属性を定義できます。

yaml

logs:
  - name: "business-critical-logs"
    file: "/var/log/business-app/*.log"
    attributes:
      service: "order-service"
      environment: "production"
      business_unit: "ecommerce"
      criticality: "high"
      team: "backend-team"

これらのカスタム属性により、組織の構造やビジネス要件に応じたログの分類と分析が可能になります。

ログフォーマットと構造化

効果的なログ分析のためには、ログの構造化が重要です。New Relicは、JSON形式のログを自動的に解析し、フィールドとして抽出します。

JSON構造化ログの活用

アプリケーションでJSON形式のログを出力することで、New Relicでの分析能力が大幅に向上します。

json

{
  "timestamp": "2025-07-27T10:00:00Z",
  "level": "ERROR",
  "message": "Database connection failed",
  "service": "user-service",
  "request_id": "req_12345",
  "user_id": "user_67890",
  "error_code": "DB_CONNECTION_ERROR",
  "duration_ms": 5000
}

この構造化されたログデータにより、エラーレート、レスポンス時間、ユーザー別の分析など、高度な分析が可能になります。

非構造化ログの構造化

既存の非構造化ログについても、Infrastructure Agentの解析機能を使用して構造化できます。

yaml

logs:
  - name: "apache-access-logs"
    file: "/var/log/apache2/access.log"
    attributes:
      service: "web-server"
      logtype: "access"
    parsing:
      built_in: "apache_access"

パフォーマンス最適化

大量のログデータを扱う環境では、パフォーマンス最適化が重要です。以下の手法により、システムへの影響を最小限に抑えながら効率的なログ転送を実現できます。

バッファリングと圧縮

Infrastructure Agentは、ログデータのバッファリングと圧縮を自動的に行います。これらの機能により、ネットワーク使用量とシステム負荷を削減できます。

yaml

logging:
  buffer_size: 10000
  compression: true
  flush_interval: 5s

サンプリングとフィルタリング

高頻度で生成されるログについては、サンプリングやフィルタリングを適用することで、ログ量を制御できます。

yaml

logs:
  - name: "high-volume-logs"
    file: "/var/log/high-traffic-app/*.log"
    sampling_rate: 0.1  # 10%のサンプリング
    attributes:
      service: "high-traffic-service"

リソース制限の設定

Infrastructure Agentのリソース使用量を制限することで、本番システムへの影響を最小限に抑えられます。

yaml

agent:
  max_memory_mb: 500
  max_cpu_percent: 5

セキュリティとコンプライアンス

ログデータには機密情報が含まれる可能性があるため、適切なセキュリティ対策が必要です。

強化されたデータ暗号化設定

New Relicへのログ転送は、デフォルトでTLS暗号化されています。さらに、送信前のデータ暗号化も設定できます。

yaml

# Infrastructure Agent の強化されたセキュリティ設定
agent:
  # TLS設定の強化
  ca_bundle_file: "/etc/ssl/certs/ca-certificates.crt"
  ssl_min_version: "TLSv1.2"
  ssl_max_version: "TLSv1.3"
  ssl_ciphers: "TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256"
  ssl_verify_hostname: true
  
  # 接続セキュリティ
  proxy_validate_certificates: true
  network_interface_filters:
    enable_loopback: false
  
  # 認証強化
  license_key_obfuscated: true
  
logging:
  # ログ転送のセキュリティ設定
  ssl_verification_mode: "full"
  headers:
    User-Agent: "NewRelic-InfraAgent/1.52.0"
  
  # 送信レート制限
  rate_limit_per_second: 1000
  max_concurrent_requests: 10

機密データのマスキング

個人情報やAPI キーなどの機密データは、転送前にマスキングまたは除外することが重要です。

yaml

logs:
  - name: "application-logs"
    file: "/var/log/app/*.log"
    attributes:
      service: "secure-app"
    obfuscation:
      - field: "password"
        replacement: "***"
      - field: "credit_card"
        replacement: "****-****-****-****"

アクセス制御

ログデータへのアクセスは、適切な権限管理により制御する必要があります。New Relicでは、ロールベースのアクセス制御（RBAC）を提供しています。

トラブルシューティング

ログ転送の設定で問題が発生した場合の一般的なトラブルシューティング手法について説明します。

接続問題の診断

Infrastructure Agentのログを確認することで、New Relicとの接続状況を診断できます。

bash

# Infrastructure Agentのログ確認
tail -f /var/log/newrelic-infra/newrelic-infra.log

# ログ転送の状態確認
grep "logs" /var/log/newrelic-infra/newrelic-infra.log

パフォーマンス問題の特定

システムリソースの使用状況を監視することで、ログ転送によるパフォーマンス影響を評価できます。

設定の検証

Infrastructure Agentには、設定ファイルの検証機能が含まれています。

bash

# 設定ファイルの検証
newrelic-infra -config-check

コスト最適化戦略

大規模環境でのログ転送コストを効率的に制御するための戦略について説明します。

ログ量削減のサンプリング戦略

yaml

logs:
  # 環境別サンプリング設定
  - name: "production-debug-logs"
    file: "/var/log/app/debug.log"
    sampling_rate: 0.05  # 本番環境のDEBUGログを95%削減
    attributes:
      service: "webapp"
      environment: "production"
      log_level: "debug"
      retention_policy: "short"
  
  # 高頻度ログのサンプリング
  - name: "health-check-logs"
    file: "/var/log/nginx/access.log"
    pattern: "GET /health"
    sampling_rate: 0.1  # ヘルスチェックログを90%削減
    attributes:
      service: "nginx"
      logtype: "health-check"
  
  # 重要度別設定
  - name: "error-logs"
    file: "/var/log/app/error.log"
    sampling_rate: 1.0  # エラーログは100%送信
    attributes:
      service: "webapp"
      log_level: "error"
      retention_policy: "long"
      data_retention_days: 90

保存期間の最適化手法

yaml

logs:
  # 開発環境の短期保存
  - name: "development-logs"
    file: "/var/log/dev-app/*.log"
    attributes:
      environment: "development"
      data_retention_days: 7
      retention_policy: "short"
  
  # セキュリティログの長期保存
  - name: "security-audit-logs"
    file: "/var/log/audit/audit.log"
    attributes:
      category: "security"
      data_retention_days: 365
      retention_policy: "compliance"
      archive_required: true
  
  # 一般的なアプリケーションログ
  - name: "application-logs"
    file: "/var/log/app/*.log"
    attributes:
      service: "webapp"
      data_retention_days: 30
      retention_policy: "standard"

効率的なバッファリング設定

yaml

logging:
  # コスト効率を考慮したバッファ設定
  buffer_size: 20000  # より大きなバッファサイズ
  compression: true
  flush_interval: 60s  # 送信間隔を延長
  
  # バッチ送信最適化
  batch_size: 2000
  max_batch_size: 5000
  
  # ネットワーク効率化
  keep_alive: true
  connection_pool_size: 5
  request_timeout: 120s

agent:
  # リソース使用量制限
  max_memory_mb: 300
  max_cpu_percent: 3
  
  # ディスク使用量制御
  max_buffer_size_disk: "500MB"
  buffer_cleanup_interval: "24h"

運用監視の拡充

ログ転送エージェントのヘルスチェック

yaml

# Infrastructure Agent監視設定
logs:
  - name: "agent-health-monitoring"
    file: "/var/log/newrelic-infra/newrelic-infra.log"
    attributes:
      service: "infrastructure-agent"
      monitoring: true
    
    # ヘルスチェック条件
    parsing:
      rules:
        - pattern: "ERROR"
          action: "alert"
          severity: "high"
        - pattern: "connection.*failed"
          action: "alert"
          severity: "critical"
        - pattern: "memory.*exceeded"
          action: "alert"
          severity: "warning"

# カスタムヘルスチェックスクリプト
custom_commands:
  - name: "agent_health_check"
    command: |
      #!/bin/bash
      # Infrastructure Agentの健全性チェック
      AGENT_PID=$(pgrep newrelic-infra)
      MEMORY_USAGE=$(ps -p $AGENT_PID -o %mem --no-headers 2>/dev/null | tr -d ' ')
      CPU_USAGE=$(ps -p $AGENT_PID -o %cpu --no-headers 2>/dev/null | tr -d ' ')
      
      # メモリ使用量チェック（5%超過でアラート）
      if (( $(echo "$MEMORY_USAGE > 5.0" | bc -l) )); then
        echo '{"alert_type": "high_memory_usage", "memory_usage": "'$MEMORY_USAGE'", "severity": "warning"}'
      fi
      
      # CPU使用量チェック（10%超過でアラート）
      if (( $(echo "$CPU_USAGE > 10.0" | bc -l) )); then
        echo '{"alert_type": "high_cpu_usage", "cpu_usage": "'$CPU_USAGE'", "severity": "warning"}'
      fi
      
      # プロセス存在チェック
      if [ -z "$AGENT_PID" ]; then
        echo '{"alert_type": "agent_not_running", "severity": "critical"}'
      fi
    interval: 300s
    attributes:
      service: "infrastructure-agent-monitoring"

パフォーマンスメトリクスの監視設定

yaml

logs:
  # ログ転送統計の監視
  - name: "log-forwarding-stats"
    source: "agent_metrics"
    attributes:
      service: "log-forwarding-metrics"
    
    # カスタムメトリクス収集
    metrics:
      - name: "logs_sent_per_minute"
        type: "counter"
      - name: "bytes_sent_per_minute" 
        type: "counter"
      - name: "connection_errors"
        type: "counter"
      - name: "buffer_utilization"
        type: "gauge"

# システムリソース監視
custom_commands:
  - name: "system_performance_check"
    command: |
      #!/bin/bash
      # システムパフォーマンス監視
      LOAD_AVG=$(uptime | awk -F'load average:' '{print $2}' | awk '{print $1}' | tr -d ',')
      DISK_USAGE=$(df /var/log | tail -1 | awk '{print $5}' | tr -d '%')
      LOG_FILES_COUNT=$(find /var/log -name "*.log" | wc -l)
      
      # Load average監視（2.0超過でアラート）
      if (( $(echo "$LOAD_AVG > 2.0" | bc -l) )); then
        echo '{"performance_alert": "high_load_average", "load_average": "'$LOAD_AVG'", "severity": "warning"}'
      fi
      
      # ディスク使用量監視（80%超過でアラート）
      if [ "$DISK_USAGE" -gt 80 ]; then
        echo '{"performance_alert": "high_disk_usage", "disk_usage": "'$DISK_USAGE'%", "severity": "warning"}'
      fi
      
      # ログファイル数監視
      if [ "$LOG_FILES_COUNT" -gt 1000 ]; then
        echo '{"performance_alert": "too_many_log_files", "log_files_count": "'$LOG_FILES_COUNT'", "severity": "info"}'
      fi
      
      echo '{"load_average": "'$LOAD_AVG'", "disk_usage": "'$DISK_USAGE'%", "log_files_count": "'$LOG_FILES_COUNT'", "service": "system-performance"}'
    interval: 300s
    attributes:
      service: "system-performance-monitoring"

まとめ

New Relicへのログ転送設定は、Infrastructure Agentを使用することで比較的簡単に実装できます。適切な属性設定、構造化ログの活用、パフォーマンス最適化により、効果的なログ監視環境を構築できます。

コスト最適化戦略として、サンプリング設定、保存期間の最適化、効率的なバッファリングにより、大規模環境でも経済的なログ管理が可能です。運用監視の拡充により、Infrastructure Agentの健全性とパフォーマンスを継続的に監視し、安定した運用を実現できます。

セキュリティとコンプライアンス要件を考慮し、機密データの適切な処理とアクセス制御を実装することで、安全で信頼性の高いログ管理システムを実現できます。

次のステップとして、Fluentdを使用したより高度なログ統合設定について学んでいきましょう。Fluentdの柔軟な設定オプションと豊富なプラグインエコシステムを活用した実装手法を詳しく解説していきます。

New Relicログ転送設定の完全ガイド - 効率的なログ収集の実装 ​

ログ転送の基本概念 ​

ログ転送の方式 ​

Infrastructure Agentを使用したログ転送設定 ​

基本設定の実装 ​

高度な設定オプション ​

Docker環境での設定 ​

ログ属性とメタデータの設定 ​

標準属性の設定 ​

カスタム属性の活用 ​

ログフォーマットと構造化 ​

JSON構造化ログの活用 ​

非構造化ログの構造化 ​

パフォーマンス最適化 ​

バッファリングと圧縮 ​

サンプリングとフィルタリング ​

リソース制限の設定 ​

セキュリティとコンプライアンス ​

強化されたデータ暗号化設定 ​

機密データのマスキング ​

アクセス制御 ​

トラブルシューティング ​

接続問題の診断 ​

パフォーマンス問題の特定 ​

設定の検証 ​

コスト最適化戦略 ​

ログ量削減のサンプリング戦略 ​

保存期間の最適化手法 ​

効率的なバッファリング設定 ​

運用監視の拡充 ​

ログ転送エージェントのヘルスチェック ​

パフォーマンスメトリクスの監視設定 ​

まとめ ​

New Relicログ転送設定の完全ガイド - 効率的なログ収集の実装

ログ転送の基本概念

ログ転送の方式

Infrastructure Agentを使用したログ転送設定

基本設定の実装

高度な設定オプション

Docker環境での設定

ログ属性とメタデータの設定

標準属性の設定

カスタム属性の活用

ログフォーマットと構造化

JSON構造化ログの活用

非構造化ログの構造化

パフォーマンス最適化

バッファリングと圧縮

サンプリングとフィルタリング

リソース制限の設定

セキュリティとコンプライアンス

強化されたデータ暗号化設定

機密データのマスキング

アクセス制御

トラブルシューティング

接続問題の診断

パフォーマンス問題の特定

設定の検証

コスト最適化戦略

ログ量削減のサンプリング戦略

保存期間の最適化手法

効率的なバッファリング設定

運用監視の拡充

ログ転送エージェントのヘルスチェック

パフォーマンスメトリクスの監視設定

まとめ