New Relic 無料プラン 設定手順：開始前の確認と方針決定

導入前に把握すべきポイントをまとめます。
無料プランにはデータ取り込み量や保持期間などの制約があります。これらは地域やアカウント種別で変わるため、公式の使用状況画面とドキュメントを必ず確認してください。

開始前の確認事項

導入の判断に影響する要素を簡潔に整理します。

• アカウントの支払い情報や地域による制約を確認すること。サインアップ画面や公式案内を参照してください（https://newrelic.com/signup、https://docs.newrelic.com）。
• 監視対象の優先順位を決めること。まずは重要な1〜2サービスから始めると評価しやすいです。
• データ保持やインジェスト上限の影響を確認すること。ログ・メトリクス・トレースで違いがあるため、Account → Usage（使用状況）やドキュメントを参照してください（https://docs.newrelic.com）。

コスト管理方針（短く）

実運用で初期に決めておくべき方針を示します。

• 重要メトリクスとエラーログを優先的に収集します。
• ログはフォワーダー側でフィルタ・マスク・サンプリングして送信量を削減します。
• 月間使用量が閾値（例: 80%）に達したら通知する運用を作ります。使用量通知の設定方法は公式ドキュメントを参照してください。

New Relic 無料プラン 設定手順：アカウント作成と初期設定

アカウント作成から初回設定までの最短手順と実務上の注意点を示します。
作成後は組織設定、タイムゾーン、初回管理者の権限設計を済ませることを推奨します。

サインアップと確認メール

サインアップとメール確認の基本的な流れを示します。

• サインアップページにアクセスして登録を開始します（https://newrelic.com/signup）。
• 使用するメールは業務用の個人メールを推奨します。共有アドレスは監査や責任範囲の観点から避けてください。
• 確認メールが届かない場合は迷惑メールフォルダやドメインブロック設定を確認してください。

最小初期設定と招待

初回の最小限設定とメンバー招待の設計方針です。

• 組織名とタイムゾーンを設定します。
• 管理者（Org Admin）は最小限に留め、運用担当は標準権限（Standard）、参照者はRead-onlyなどで分けます。
• ユーザー招待は UI の「Users / Team」→「Invite user」から行い、Roles を用途に応じて割り当てます。SSO/SAML を利用する場合は組織の ID 管理方針に沿って設定してください。

New Relic 無料プラン 設定手順：APIキーと安全な運用

キーは監視運用の根幹です。キーの種類と用途を正しく理解し、安全に保管・ローテーションする方法を示します。必ず公式の「API keys」関連ページで権限や使い分けを確認してください（https://docs.newrelic.com）。

キーの種類と用途の区別

主要なキーの種類と、一般的な用途をわかりやすく整理します。

• License Key（ライセンスキー）
• かつて APM や Infrastructure エージェントで用いられてきたキーです。古いエージェントや一部の設定で必要になります。エージェント別ドキュメントでの確認を推奨します（例: Java/Node/Python エージェントのページ）。
• Insert Key（インサートキー）
• Logs や Events、Custom Metrics などのデータインジェストに使います。ログフォワーダーや挿入APIでの認証に利用されます。
• Query / Personal API Key（クエリ/API キー）
• Insights クエリや API 呼び出し、自動化スクリプトでの読み取り・書き込みに使うキーです。ユーザー単位・用途別にスコープを分けて発行できます。
• 備考
• 各キーのスコープや名前はドキュメントで随時更新されます。用途に不明点がある場合は公式の「Types of New Relic API keys」等を参照してください（https://docs.newrelic.com）。

キーの安全な保管・注入・ローテーション

運用で実践すべき具体的なルールと手順を示します。

• 保管場所の推奨
• クラウドのシークレットマネージャ（AWS Secrets Manager、GCP Secret Manager、Azure Key Vault、HashiCorp Vault 等）を優先します。
• Kubernetes では Kubernetes Secret を利用しますが、Git に平文で置かないこと。sealed-secrets や helm-secrets の利用を検討してください。
• キー注入のベストプラクティス（Kubernetes 例）

• シェル履歴に残さないためにファイル経由で secret を作成します。例:

  bash

  推奨: ファイルから作る（シェル履歴に残りにくい）

  printf '%s' "$NEW_RELIC_LICENSE_KEY" > /tmp/newrelic_license.txt
kubectl create secret generic newrelic-license --from-file=licenseKey=/tmp/newrelic_license.txt


• Deployment では envFrom で秘密を注入します。

  yaml
envFrom:
- secretRef:
name: newrelic-license

• Helm を使う場合は、直接コマンドラインにキーを書く（--set global.licenseKey=...）手法は避け、CI のシークレットストアや sealed-secrets 経由で値を注入してください。公式 Helm チャートの使い方はドキュメントを参照してください（https://docs.newrelic.com / helm-charts 関連）。

• ローテーション手順（簡潔）
• 新しいキーを発行する（同スコープ）。
• ステージングで新キーを適用し動作確認する。
• 本番で段階的に切り替え、問題なければ旧キーを失効する。
• 禁止事項
• キーをチャットやメールで平文共有しない。
• 公開リポジトリやドキュメントにキーを残さない。

New Relic 無料プラン 設定手順：エージェント導入（APM・インフラ・RUM）

最小構成で「データが届く」ことを素早く確認するための手順と注意点を示します。各言語とプラットフォームの公式エージェントページで最新手順を必ず確認してください（https://docs.newrelic.com）。

Java エージェント導入（短く）

Java エージェントの基本的な導入手順と注意点を示します。

• 概要: newrelic.jar を JVM 起動オプションに渡す方法が一般的です。
• 最短手順: エージェント jar を配置し、JVM に -javaagent:/path/newrelic.jar を追加します。
• キー設定: 環境変数（例: NEW_RELIC_LICENSE_KEY）か newrelic.yml でキーを指定します。キーをコマンドラインに直接書かないでください。
• 公式: Java エージェントの詳細は公式ドキュメントを参照してください（https://docs.newrelic.com/docs/agents/java-agent）。

Node.js エージェント導入（短く）

Node.js アプリへの組み込みの要点です。

• 概要: npm パッケージを導入し、アプリの最上行で require('newrelic') を呼び出します。
• 最短手順: npm install newrelic → newrelic.js にキーを設定（あるいは環境変数）→ アプリの先頭で require して再起動。
• バージョン依存: Node のバージョンやフレームワークによる差異があるため公式ドキュメントで互換性を確認してください（https://docs.newrelic.com/docs/agents/nodejs-agent）。

Python / Go / Ruby / .NET の導入（短く）

各言語の基本パターンと確認ポイントをまとめます。

• Python: pip install newrelic、newrelic-admin generate-config で設定ファイルを生成して実行する手法が簡便です。公式ドキュメントを参照してください（https://docs.newrelic.com/docs/agents/python-agent）。
• Go: ライブラリ組み込み型のためアプリコードに newrelic.NewApplication を追加します。互換性や API の呼び方は公式を確認してください（https://docs.newrelic.com/docs/agents/go-agent）。
• Ruby: gem 'newrelic_rpm' を導入し、newrelic.yml で設定します（https://docs.newrelic.com/docs/agents/ruby-agent）。
• .NET: OS や環境によりインストーラや環境変数で導入します。コンテナ環境と Windows 環境で手順が異なるため公式を参照してください（https://docs.newrelic.com/docs/agents/net-agent）。

Infrastructure Agent と Kubernetes（短く）

ホスト監視とクラスタ環境での導入要点です。

• Linux/Windows: パッケージ（apt/yum/MSI）で導入し /etc/newrelic-infra.yml などでキーを設定します。service を起動してログを確認します。公式は Infrastructure Agent のページを参照してください（https://docs.newrelic.com/docs/infrastructure）。
• Kubernetes: Helm や DaemonSet でデプロイします。キーの扱いは Secret を使い、RBAC を最小権限にしてデプロイしてください。Helm での安全な運用には sealed-secrets やクラウドシークレット統合の使用を推奨します。公式の Kubernetes 統合ドキュメントを参照してください（https://docs.newrelic.com）。

ブラウザ RUM とモバイル SDK（短く）

フロントエンドとモバイルの導入上の注意点です。

• ブラウザ RUM: UI から取得するスニペットを HTML の head に挿入するか、SPA は npm パッケージ経由で組み込みます。必ず PII を収集しないように設定し、必要なら同意取得を行ってください（公式のブラウザドキュメント参照）。
• モバイル: iOS/Android SDK を組み込む際は、ユーザー同意・収集項目の最小化に注意してください。公式のモバイルドキュメントを参照してください。

Distributed Tracing とサンプリング（短く）

トレースの伝播とインジェスト制御の基本です。

• 各エージェントで distributed tracing を有効にします。ヘッダー伝播は W3C tracecontext 等の標準をサポートするよう確認してください。
• サンプリング率を調整して高トラフィック環境のインジェスト量を抑制します。トレースはビジネス重要なトランザクションを優先する設定を検討してください。
• テストはフロントから意図するトランザクションを実行し、UI でトレースがつながるか確認します。

New Relic 無料プラン 設定手順：ログ・ダッシュボード・アラート設計

運用開始直後に作るべきダッシュボードとアラート、ログフォワーディングの実務ポイントをまとめます。ここでの設計はインジェスト量管理とトラブル検知の両立を重視します。

Fluentd/Fluent Bit 経由のログ送信（実務ポイント）

フォワーダー側での整形とフィルタリングが重要です。

• フォワーダーで不要ログを除外・マスクしてから New Relic に送信します。Insert Key を認証に使います。
• フィルタ例: record_transformer で PII をマスク、grep で debug レベルを除外、throttle プラグインで送信量を制御します。
• サンプリング: 特定パスは 100% 送信、その他は低割合で送るなどルールを設けます。大量ログは S3 等にアーカイブして New Relic にはサマリを送る運用を検討してください。公式のログフォワーディングガイドを参照してください（https://docs.newrelic.com/docs/logs）。

ダッシュボード作成と NRQL の実務例

最初に作るべきウィジェットと NRQL のサンプルを示します。

• 優先ウィジェット例: p95 応答時間、エラーレート、スループット、ホストの CPU/メモリ、ログレート（1h）など。
• NRQL 例（p95 応答時間）:

SELECT percentile(duration, 95) FROM Transaction WHERE appName = 'prod-api' SINCE 5 minutes AGO

• NRQL 例（エラーレート）:

SELECT percentage(count(*), WHERE error IS true) FROM Transaction WHERE appName = 'prod-api' SINCE 5 minutes AGO

• NRQL 例（ログレート）:

SELECT count(*) FROM Log WHERE appName = 'prod-api' SINCE 1 hour AGO

• 補足: クエリやダッシュボードはチームで使い回せるテンプレとして保存し、定期的に見直します。

アラート設計と通知チャネル

実務でのポリシー分けと通知設計の要点です。

• ポリシーは環境別（prod/staging/dev）と目的別（SLA監視、コスト監視、インフラ健全性）に分けます。
• 閾値運用: まず Warning を出してから Critical を自動ページングにするなど段階的に通知します。
• 通知チャネル: Slack、メール、PagerDuty などを登録し、必ずテスト通知を行います。
• インジェスト超過対策: 使用量が逼迫する前に通知を受け取るアラートや、サンプリング自動調整の仕組みを作っておきます。使用量関連の設定は公式の Usage ドキュメントを参照してください。

New Relic 無料プラン 設定手順：運用・超過対策・トラブルシュート

運用フェーズで継続的に抑えるべきポイントと、トラブル時の優先的な確認項目を示します。日次・週次の運用ルーチンを決めておくことが重要です。

使用量管理と削減策

使用量を抑えるための実務的な手段を集約します。

• 毎日・週次で使用量ダッシュボードを確認し、急増時は原因を追います。
• ログ: フォワーダーで不要ログを除外・マスクし、重要なエラーログのみをフルで送信します。アーカイブは S3 等へ。
• トレース: サンプリング率を下げ、トレース対象を絞ります。
• メトリクス: 高頻度のカスタムメトリクスは集約して送るか、送信頻度を下げます。

日次・週次・月次の運用チェックリスト

導入直後から月次までに実行する具体的なタスクを示します。

• 初日: 1 サービスに APM を導入し、データ受信を確認します。重要アラートを一つ設定します。
• 初週: ダッシュボード整備、メンバー招待と権限確認を行います。ログフィルタ方針を決定します。
• 初月: 使用量レビューを実施し、必要なサンプリング・フィルタを適用します。ランブックとキー回転計画を整備します。

よくあるトラブルシュート（データが届かない場合）

優先的に確認すべきチェック項目を示します。

• エージェントが起動しているかを確認します（systemctl status、プロセスの有無）。
• エージェントログに認証エラーやパーミッションエラーが出ていないかを確認します。
• 使用しているキーの種類と値が正しいかを再確認します。Insert Key と License Key の使い分けミスに注意してください。
• ネットワーク: outbound TLS/443 が許可されているか、プロキシ設定が正しいかを確認します。
• 時刻同期（NTP）にずれがないかを確認します。
• エージェントバージョンの互換性を確認します。古いエージェントは動作しない場合があります。
• UI 側のフィルタやタイムレンジを見直してデータが非表示になっていないか確認します。
• フォワーダー側のサンプリングやフィルタが誤って大量除外していないか確認します。

New Relic 無料プラン 設定手順：要点まとめと次の一手

導入と初期運用で押さえるべき要点を短く整理します。実行前に必ず公式ドキュメントで最新情報を確認してください。

• まずは 1〜2 サービスを対象に最小構成でデータ受信を確認する。
• キーは用途別に使い分け、クラウドシークレットや Kubernetes Secret、sealed-secrets 等で安全に保管する。
• ログはフォワーダー側でフィルタ・マスク・サンプリングして送る。長期保存は外部ストレージを使う。
• ダッシュボードとアラートを早期に整備し、使用量閾値の通知を設定する。
• トラブル時はエージェント稼働、キー、ネットワーク、時刻同期、エージェントバージョンを優先確認する。

参考リンク（公式優先）

• New Relic ドキュメント（トップ）: https://docs.newrelic.com
• サインアップ: https://newrelic.com/signup
• API キーと認証に関する説明: https://docs.newrelic.com （ドキュメント内の「API keys」や「Authentication」ページを参照してください）
• エージェント一覧（Java/Node/Python/Go/Ruby/.NET）: https://docs.newrelic.com/docs/agents
• Infrastructure / Kubernetes / Logs / Alerts の詳細: https://docs.newrelic.com

補足: 公式ドキュメントを一次情報として優先してください。非公式記事は実践例として参考にする場合のみ扱ってください。