Contents
最短で始める 3 ステップ（クイックスタート）
ここでは最短で「サインアップ→エージェント導入→データ到達確認」を終えるための簡潔な手順を示します。
各ステップには直後の簡易検証ポイントを添えています。
- サインアップとキー取得
- 手順: New Relic のサインアップ画面にアクセスしてアカウントを作成し、管理画面で必要なキー（Insertキー / Personal API Key / ライセンスキー）を発行します。公式サインアップ（日本）: https://newrelic.com/jp/sign-up-japan
-
検証: 管理画面にログインできること、Keys（またはAPI keys）画面でキーが発行できることを確認します。
-
代表ホストへ Infrastructure エージェントを導入（Linux の例）
- 手順: 下記の概念例でエージェントを導入し、設定ファイルにライセンスキーを反映してサービスを起動します。詳細は公式ドキュメントを参照してください（概念例・実行前に公式を確認）。
|
1 2 3 4 5 6 7 8 |
# 概念例（実行前に公式ドキュメントで配布手順を確認してください） sudo apt-get update sudo apt-get install -y newrelic-infra sudo tee /etc/newrelic-infra.yml > /dev/null <<EOF license_key: YOUR_LICENSE_KEY EOF sudo systemctl restart newrelic-infra |
- 参照（公式）: Infrastructure エージェント導入ガイド https://docs.newrelic.com/docs/infrastructure/install-infrastructure-agent
-
検証: New Relic の Hosts/Infrastructure にホストが数分以内に表示されることを確認します。
-
代表アプリに APM を組み込み（例: Node.js）
- 手順: アプリに newrelic パッケージを追加し、アプリ起動時にキーとアプリ名を指定します（概念例）。詳細は各言語の公式手順を参照してください。
|
1 2 3 4 5 |
# 概念例（Node.js） npm install newrelic --save # アプリの先頭で require('newrelic') を読み込む NEW_RELIC_LICENSE_KEY="YOUR_KEY" NEW_RELIC_APP_NAME="MyApp" node app.js |
- 参照（公式）: Node.js エージェント https://docs.newrelic.com/docs/apm/agents/nodejs-agent/getting-started
- 検証: New Relic の APM → Services にアプリ名が表示され、トランザクションが数分以内に計測されることを確認します。
導入目安時間と事前準備
導入にかかる時間は環境やネットワークで変わります。ここでは一般的な目安と、短時間で検証を進めるための準備項目を示します。
準備が整っていると初期評価を迅速に終えられます。
導入目安時間
導入の標準的な目安を示します。環境により大きく変動します。
- サインアップ・初期確認：5〜15分
- APM（言語1つ導入・確認）：10〜30分
- Infrastructure エージェント導入：5〜20分
- Logs（Fluent Bit 等経由）：10〜40分
- Browser RUM 導入：5〜15分
- ダッシュボード／アラート初期設定：15〜60分
事前準備チェックリスト
導入前に揃えるとスムーズな項目です。必須権限やネットワーク設定を確認してください。
- 個別の一意なメールアドレスと管理者権限（キー発行、設定変更ができるアカウント）
- 対象ホストへソフトウェアをインストールできる root/sudo 権限
- 監視対象の技術情報（言語、OS、コンテナ/Kubernetes の有無）
- New Relic へアウトバウンド HTTPS（通常 443）が許可されていること。プロキシ経由の場合はエージェントのプロキシ設定を用意すること
- テスト用のカナリア対象（1台のホスト／1サービス）を決めること
- データ量の方針（ログのフィルタリング、トレースのサンプリング）をざっくり決めておくこと
アカウント作成・リージョン選択とキー管理
アカウント作成時のリージョン選択やキーの種類は運用に影響します。ここではサインアップの流れとキー運用の実務ポイントを整理します。
キーごとの用途を明確に分け、シークレット管理やローテーション方針を決めておくことが重要です。
サインアップ〜初回設定の流れ
サインアップ後に行う基本的な流れです。UI 表示や選択肢は変更される可能性があります。
- サインアップページ（日本）でメールアドレスを入力して登録します。公式サインアップ（日本）: https://newrelic.com/jp/sign-up-japan
- 認証メールのリンクでアカウントを有効化し、組織名等を入力します。オンボーディング画面でサンプルアプリやエージェントの案内が出ます。
- リージョン選択がある場合はレイテンシや法規制を考慮して選んでください。保存先リージョンの変更が制約されることがあります。詳細は公式ドキュメントで確認してください。
キーの種類と用途
以下は概念的な整理です。UIでの表記や権限は変更される場合があります。必ず管理画面で名称と用途を確認してください。
| キー名 | 主な用途 | 備考（公式ドキュメント） |
|---|---|---|
| Insertキー（Insert API Key） | ログやイベントの送信（Ingest API） | ログ送信やイベント送信に使用。エンドポイントはリージョンにより異なるため公式のログ送信ドキュメントを参照してください。 https://docs.newrelic.com/docs/logs |
| Personal API Key（個人用APIキー） | 管理API操作やスクリプト実行 | ダッシュボードや管理APIをスクリプトから操作する際に使用。権限範囲を確認してください。 https://docs.newrelic.com/docs/apis |
| ライセンスキー | 一部エージェントの認証 | 旧来のエージェントや一部のエージェントで使用されることがあります。導入時は該当エージェントの手順を確認。 https://docs.newrelic.com/docs/infrastructure |
（注）上記は概念説明です。キー名や用途の表記は UI により変わる場合があります。管理画面の Keys（API keys）ページで権限と用途を必ず確認してください。
キーの安全な管理方法
キーは機密情報です。平文でのリポジトリ管理やログ出力は避けてください。以下は実務的な代替例です。
- シークレットマネージャ（HashiCorp Vault、AWS Secrets Manager、Google Secret Manager 等）を利用する。
- CI/CD の場合はパイプラインのシークレット機能を使用し、ビルド成果物に直書きしない。
- Kubernetes の場合は Secret で格納し、Pod への環境変数注入は最小限にする。概念例:
|
1 2 3 4 |
# 概念例（Kubernetes Secret を作成） kubectl create secret generic newrelic-keys \ --from-literal=NEW_RELIC_INSERT_KEY='REPLACE_WITH_INSERT_KEY' |
- サーバ上の systemd ユニットで環境変数を設定する場合は、ファイルのパーミッション管理を徹底する。概念例:
|
1 2 3 4 |
# 概念例（/etc/systemd/system/myapp.service の EnvironmentFile を使う） EnvironmentFile=/etc/default/myapp # /etc/default/myapp のパーミッションは 600 に設定 |
- キーのローテーション手順と失効時の対応フロー（キー無効化→再発行→再設定）を文書化する。
（注）上記は運用例です。実施前に組織のセキュリティポリシーに従ってください。
主要エージェント導入（APM / Infrastructure / Logs / Browser）
主要な収集エージェントは APM、Infrastructure、Logs、Browser の4領域です。ここでは各領域の最小導入例と検証項目を示します。
コマンド例は概念例として示します。実行前に該当エージェントの公式手順を必ず参照してください。
APM（Java / Node.js / Python / Ruby）
APM は言語ごとに導入手順が異なります。ここでは最小構成の概念例を示します。各言語の詳細は公式ドキュメントを参照してください。
- Java（概念例）
- 導入: newrelic Java エージェント jar をアプリサーバに配置し、起動オプションで -javaagent を指定します。設定は newrelic.yml または環境変数で行います（概念例）。
- 検証: New Relic UI の Services にアプリが表示されること。
-
参照（公式）: Java エージェント https://docs.newrelic.com/docs/apm/agents/java-agent
-
Node.js（概念例）
- 導入: npm パッケージ newrelic をインストールし、アプリ起動前に require('newrelic') を読み込みます。環境変数または newrelic.js で設定します。
- 検証: Services にアプリが表示され、トランザクションが計測されること。
-
参照（公式）: Node.js エージェント https://docs.newrelic.com/docs/apm/agents/nodejs-agent/getting-started
-
Python（概念例）
- 導入: pip install newrelic でライブラリを追加し、newrelic-admin generate-config で設定を作成してから newrelic-admin run-program でアプリを起動します。
- 検証: Services にアプリが表示されること。
-
参照（公式）: Python エージェント https://docs.newrelic.com/docs/apm/agents/python-agent
-
Ruby（概念例）
- 導入: gem newrelic_rpm を導入し、newrelic.yml を配置してアプリを再起動します。
- 検証: Services にアプリが表示されること。
- 参照（公式）: Ruby エージェント https://docs.newrelic.com/docs/apm/agents/ruby-agent
（注）言語別の細かな設定や互換性はエージェントごとに異なります。該当ドキュメントを確認してください。
Infrastructure（Linux / Windows / Kubernetes）
Infrastructure エージェントはホスト単位でメトリクスを収集します。OS ごとに導入手順が異なります。
- Linux（概念例）
- 概念的な手順を示します。配布リポジトリやパッケージ名はディストリビューションと New Relic の配布方式で異なります。
|
1 2 3 4 5 |
# 概念例（実行前に公式を確認） sudo apt-get update sudo apt-get install -y newrelic-infra # /etc/newrelic-infra.yml に license_key を設定して再起動 |
- 参照（公式）: Infrastructure エージェントのインストール https://docs.newrelic.com/docs/infrastructure/install-infrastructure-agent
-
検証: Hosts/Infrastructure にホストが表示され、CPU/メモリ等のメトリクスが数分で反映されること。
-
Windows（概念）
- 概要: MSI をダウンロードして管理者権限でインストール。サービス管理はサービスコンソールや PowerShell で実施。
-
参照（公式）: Windows 向け手順は上記公式ページ参照。
-
Kubernetes（概念）
- 概要: Helm チャートや DaemonSet でエージェントを展開します。クラスタ用の追加設定（Kubernetes integration）があります。
- 参照（公式）: Kubernetes 用導入ガイド https://docs.newrelic.com/docs/integrations/kubernetes-integration
Logs と Browser（RUM）
ログは量が増えやすいため、フィルタリングとサンプリング設計が重要です。Browser（RUM）はユーザ側のパフォーマンス観測に使います。
- Fluent Bit（概念例: HTTP 出力）
- 概念: Fluent Bit の HTTP 出力で New Relic のログ API に送信する構成例です。ヘッダ名やエンドポイントはリージョンや API 仕様で変わるため公式ドキュメントを参照してください（概念例）。
|
1 2 3 4 5 6 7 8 9 10 |
# 概念例（Fluent Bit） [OUTPUT] Name http Match * Host <NEWRELIC_LOG_INGEST_HOST> Port 443 URI /log/v1 Header Api-Key: <INSERT_KEY> Format json |
- 参照（公式）: Fluent Bit 向けの送信ガイド https://docs.newrelic.com/docs/logs/forward-logs/fluent-bit
-
検証: Log Explorer にログが数分で到達し、期待する属性（service 等）が付与されていること。
-
Browser（RUM）導入（概略）
- 自動挿入: APM 設定で自動挿入が使える場合があります。
- 手動挿入: New Relic UI で取得したスニペットを HTML の head に貼り付けます。SPA は別途設定を要します。
- 参照（公式）: Browser RUM https://docs.newrelic.com/docs/browser
（注）ログ送信時の HTTP ヘッダ名（Api-Key / X-Insert-Key 等）やエンドポイントは仕様変更やリージョン差があり得ます。必ず該当 API ドキュメントの「Log ingest endpoints」を確認してください。
可視化・アラート設定と導入後の動作確認
データ到達確認後は可視化と通知設定を行い、ベースラインを測定して閾値を決めます。ここでは代表的な NRQL クエリ例と初期の動作確認手順を示します。
アラートは短期のフラッピング対策として評価ウィンドウや発火条件の設定が重要です。
NRQL クエリ例とダッシュボード作成
基本的な NRQL クエリ例を示します。ダッシュボードのウィジェットに貼り付けて可視化します。
- 平均応答時間（タイムシリーズ）
|
1 2 |
SELECT average(duration) FROM Transaction WHERE appName = 'MyApp' TIMESERIES |
- スループット（リクエスト数）
|
1 2 |
SELECT count(*) FROM Transaction WHERE appName = 'MyApp' TIMESERIES |
- エラーレート（%）
|
1 2 |
SELECT percentage(count(*), WHERE error IS true) FROM Transaction WHERE appName = 'MyApp' |
- ログ件数の推移
|
1 2 |
SELECT count(*) FROM Log WHERE service = 'my-service' TIMESERIES |
期待結果: クエリ実行で数値が返り、ウィジェットにグラフが表示されることを確認します。
アラートポリシー・通知チャネル設定
アラートはポリシー→条件→通知チャネルの順で作成します。通知チャネルは Slack、PagerDuty、メール等と連携できます。
- 例: p95 応答時間が 1 秒を超えた場合に通知する設定
- 条件種別: APM / NRQL（p95 latency）
- 評価期間の設定: 5 分間の評価ウィンドウ内で継続的に閾値を超える場合に発火など、フラッピング対策を入れること
Slack 連携は Incoming Webhook を作成して New Relic の通知チャネルに登録します。重要な障害はオンコールツールへも連携してください。
導入後の動作確認手順
導入直後に実施する基本チェックをまとめます。短時間で到達確認を行うことを優先してください。
- APM：Services にサービス名が表示され、トランザクションが記録されているか。
- Infrastructure：Hosts に対象ホストが表示され、CPU/メモリ等のメトリクスが反映されているか。
- Logs：Log Explorer で期待するログが検索でき、属性が付与されているか。
- Browser：ページロードやセッションが記録されているか。
- 簡易負荷/イベント生成：curl やブラウザ操作を数回行い、NRQL または UI でイベントが反映されるか確認する。
簡易コマンド（概念例）:
|
1 2 3 4 5 6 |
# エージェントのサービス確認（概念例） systemctl status newrelic-infra # エージェントログ確認（概念例） tail -n 200 /var/log/newrelic-infra/newrelic-infra.log |
運用移行判断基準・コスト管理とトラブルシューティング
本番運用に移行する際は、コストと保持要件を定量的に評価して判断します。ここでは移行判断の指標例とトラブルシューティングの優先チェック項目を示します。
プランや無料枠の具体値は変わり得るため、請求/使用量ページで必ず確認してください。
定量的な移行判断基準（例）
以下は検討のための一例です。自社の要件に合わせて閾値を調整してください。
- 月間ログ送信量の閾値例：100 GB／月を超える場合は有料プランの検討を推奨（目安）。
- 保持期間要件：ログやトレースの保持が 30〜90 日を超える場合は有料オプションが必要になる可能性あり。
- 管理面：監視対象サービスが多数（例: 50 サービス以上）になり、アラート管理やダッシュボード運用が肥大化するなら運用体制の見直しを検討。
- SLO 要件：SLO を厳密に運用する場合はトレースサンプリングやメトリクス粒度の要件を満たすプランを選定。
（注）上記の閾値は例です。正確な無料枠やプラン内容は公式の請求／使用状況ページで確認してください。
トラブルシューティングの優先チェック項目
発生しやすい問題と初動の確認ポイントをまとめます。
- データ未着／遅延
- エージェントが稼働しているか（systemctl やプロセス）を確認する。
- エージェントログを確認してエラーや接続失敗を探す。
- 使用中のキーの種類が適切か（Insertキー と Personal API Key の用途混同がないか）を確認する。
-
ネットワーク経路やプロキシ設定、ファイアウォールのブロックを確認する。
-
認証エラー
-
キーの権限とスコープを管理画面で確認する。必要に応じてキーを再発行する。
-
エージェント非稼働／クラッシュ
- サービスの再起動、ログ取得、Kubernetes 環境では Pod のログを確認する（kubectl logs
-n ）。
代表的な診断コマンド（概念例）:
|
1 2 3 4 5 6 7 8 9 |
# サービス状態の確認（概念例） systemctl status newrelic-infra # ログ確認（概念例） tail -f /var/log/newrelic-infra/newrelic-infra.log # Kubernetes（概念例） kubectl logs <pod> -n <namespace> |
コスト抑制策と運用ベストプラクティス
運用コストを抑えるための実務的な方法です。
- ログのフィルタリングとサンプリングを導入し、重要なログのみ長期保存する。
- トレースのサンプリング率を調整して遅いトランザクションを優先する。
- メトリクス収集の頻度を見直し、必要な粒度だけを送る。
- タグや属性は必要最小限にしてデータ量を削減する。
- 構成はコード化（Ansible/Terraform/Helm）して再現性を確保する。
- キー管理、RBAC、エージェントの定期更新を運用ルールに組み込む。
公式ドキュメント（主要リンク）
以下は導入で参照しやすい公式ドキュメントの代表リンクです。各手順の詳細や最新のエンドポイント情報はこれらを参照してください。
- New Relic Docs（総合）: https://docs.newrelic.com
- サインアップ（日本）: https://newrelic.com/jp/sign-up-japan
- Infrastructure エージェント: https://docs.newrelic.com/docs/infrastructure/install-infrastructure-agent
- APM エージェント（言語別のトップ）: https://docs.newrelic.com/docs/apm/agents
- Logs（Ingest API / Fluent Bit）: https://docs.newrelic.com/docs/logs
- Browser RUM: https://docs.newrelic.com/docs/browser
参考（非公式）: 実務的な導入例やハウツー（外部）: https://app-tatsujin.com/new-relic-free-plan-quick-setup/
（注）非公式情報は参考として扱い、最終的な操作は公式ドキュメントや管理画面の表記を優先してください。
まとめ（要点）
- 最短手順は「サインアップ→代表ホストへ Infrastructure 導入→代表アプリへ APM 導入」の3ステップで、各ステップで UI 上の到達確認を行います。
- キーは用途ごとに使い分け（Insertキー: ログ/イベント、Personal API Key: 管理API、ライセンスキー: 一部エージェント）し、シークレットマネージャ等で安全に保管します。
- ログ量と保持期間を定量的に評価し、閾値を超える場合は有料プラン検討やサンプリング設計でコスト制御を行います。
- 導入後は NRQL ダッシュボードとアラートでベースラインを測定し、運用ルール（キー管理・エージェント更新・ローテーション）を整備してください。