ログ機能のベストプラクティスガイド

New Relicログ機能のベストプラクティスガイドへようこそ。ここでは、ログ機能を最適化し、データ消費を管理する方法に関する詳細な推奨事項をご覧いただけます。

ログの転送

ログ転送ドキュメントを補足するためのログ転送のヒントは次のとおりです。

ログを転送する場合は、New Relic Infrastructureエージェントおよび/またはAPMエージェントを使用することをお勧めします。New Relicエージェントを使用できない場合は、他の対応エージェント（FluentBit、Fluentd、Logstashなど）を使用してください。
以下は、対応ロギングエージェントのGithub設定例です。
- FluentBitの例
- Fluentdの例
- Logstashの例
  重要
  ログが基盤となるホスト/コンテナのディレクトリに保存されていて、ログを収集するためにインフラストラクチャエージェントによってインストルメント化されている場合、インフラストラクチャエージェントとエージェント。重複したログを送信しないようにするには、このガイドの推奨事項を参照してください。
転送対象のすべてのデータにlogtype属性を追加します。属性は、組み込み解析ルールの使用に必要であり、データ型に基づいてカスタム解析ルールの作成にも使用できます。logtype属性は既知の属性と見なされ、ログサマリー情報のクイックスタートダッシュボードで使用されます。
既知のログタイプには、組み込みの解析ルールを使用します。関連するlogtype属性を設定すると、さまざまな既知のログタイプからログが自動的に解析されます。
以下は、Infrastructureエージェントが転送したログにlogtype属性を追加する方法の例です。
```
logs:
- name: mylog
    file: /var/log/mylog.log
    attributes:
      logtype: mylog
```
New Relicインテグレーションを使用して、次のような一般的な他のデータ型のログを転送します。
- コンテナ環境：Kubernetes（K8S）
- クラウドプロバイダーの統合：AWS、Azure、GCP
- ロギングでサポートされているその他のオンホストインテグレーション

データパーティション

ログデータを1日あたり1TB以上消費している場合は、ログの取り込みガバナンス計画を必ず立てる必要があります。これには、機能的およびテーマ別のグループ化を行う方法でデータを分割する計画が含まれます。New Relicのドキュメントでは、パーティションあたり1TB以下をベストプラクティスとして推奨しています。これは、パフォーマンスと使いやすさの両方で役立ちます。1つのアカウントの1つの巨大な「バケット」（つまり、デフォルトのログパーティション）に送信した場合、クエリが遅くなったり、クエリが失敗したりする場合があります（検査カウント（IC）制限に達したため）。

クエリのパフォーマンスを向上させる方法の1つには、検索する時間範囲を制限することです。長期間にわたってログを検索すると、より多くの結果が返され、より多くの時間を要します。可能な限り長い検索（> 1週間）を避け、時間範囲セレクターを使用して検索をより狭め、より具体的な時間枠に絞り込みます。

検索パフォーマンスを向上させるもう1つの方法は、データパーティションを使用することです。データパーティションのベストプラクティスは次のとおりです。

ログのオンボーディングプロセスの早い段階で、パーティションを使用するようにしてください。ユーザーが特定のログを検索して見つけた場所を把握できるように、パーティションを使用する方策を作成します。そうすることで、ログジャーニーの後半でパーティションを実装する場合、アラート、ダッシュボード、保存済みビューを変更する必要がなくなります。
制限を回避してクエリ時間を短縮するには、1日あたりの総取り込み量が1TBを超える場合に、特定のデータ型にデータパーティションルールを作成します。特定の大量のインフラストラクチャログ（KK8Sログ、CDNログ、VPCログ、Syslogログ、Webログなど）は、独自のパーティションに適した候補となる場合があります。
取り込み量が少ない場合でも、データパーティションを使用してデータを論理的に分離したり、個別のデータ型間でクエリのパフォーマンスを改善したりすることもできます。
保持時間を短縮したいデータには、セカンダリデータパーティションのネームスペースを使用します。セカンダリデータパーティションには、デフォルトで30日間の保持期間があります。
ログUIでデータパーティションを検索するには、適切なパーティション（複数可）を選択し、パーティションセレクターを開いて、検索するパーティションを確認する必要があります。NRQLを使用している場合は、FROM句を使用して検索するLogまたはLog_<partion>を指定します。例：
```
FROM Log_<my_partition_name> SELECT * SINCE 1 hour ago
```
または、複数のパーティションのログを検索するには：
```
FROM Log, Log_<my_partition_name> SELECT * SINCE 1 hour ago
```

解析ログ

取り込み時にログを解析することで、ユーザーや組織内の他のユーザーにログデータをより使いやすくする最善策を提供します。属性を解析すると、クエリ時にデータを解析することなく、ログUIとNRQLで簡単に検索できます。また、アラートやダッシュボードでも簡単に使用できます。

ログを解析するには、以下を推奨します。

取り込み時にログを解析してattributes（またはフィールド）を作成します。これは、ダッシュボードやアラートを検索または作成する際に使用できます。データまたは数値の文字列が属性になります。
取り込み時にログに追加したlogtype属性と他のNRQLWHERE句を使用して、解析するデータに一致させます。ログをできるだけ正確にフィルターする特定の一致ルールを記述します。例：
```
WHERE logtype='mylog' AND message LIKE '%error%'
```
可能な限り、組み込みの解析ルールと関連するlogtype属性を使用してください。組み込みのルールがデータに対して機能しない場合は、別のlogtype属性名（つまり、apache_logsとapache、iis_w3c_customとiis_w3c）を使用してから、組み込みルールの修正バージョンを使用してUIで新しい解析ルールを作成し、ログデータ形式で機能するようにします。
当社の解析UIを使用して、Grokルールをテストし検証します。Paste logオプションを使用すると、永続的な解析ルールを作成し保存する前に、ログメッセージのいずれかに貼り付けて Grok式をテストできます。
外部FluentBit設定を使用すると、複数行のログを解析したり、New Relicに取り込む前に、より広範な解析を事前に実行したりできます。当社のInfrastructureエージェントによる複数業の解析の詳細と設定については、このブログ記事を参照してください。
フィルターされたログに一致するように最適化されたGrokパターンを作成し、属性を抽出します。GREEDYDATAのような高価なGrokパターンを過剰に使用しないでください。準最適な解析ルールの特定についてサポートが必要な場合は、New Relicのアカウント担当者にお問い合わせください。

Grokに関するベストプラクティス

Grok 型を使用して、抽出する属性値の型を指定します。省略した場合、値は文字列として抽出されます。これらの属性で NRQL 関数 (つまり、 monthOf() 、 max() 、 avg() 、 > 、 <など) を使用できるようにする場合、これは特に数値の場合に重要です。
解析UIを使用して、Grokパターンをテストします。解析UIにサンプルログを貼り付けて、GrokまたはRegexパターンを検証し、想定どおりに属性を抽出しているかどうかを確認できます。
行頭を示すために構文解析ロジック（つまり、^）にアンカーを追加するか、行末に$を追加します。
パターンの前後に()?を使用して、オプションのフィールドを識別します。
'%{GREEDYDATA}のような高価なGrokパターンを過剰に使用しないようにしてください。属性を抽出するときは、常に有効なGrokパターンとGrokタイプを使用してください。

ドロップフィルタールール

取り込み時にログをドロップする

ドロップフィルタルールを作成して、役に立たないログ、またはダッシュボード、アラート、トラブルシューティングのユースケースの要件に不要なログを削除します。

取り込み時にログから属性をドロップする

ログから未使用の属性をドロップするドロップルールを作成します。
解析後にmessage属性を削除します。メッセージ属性を解析してデータから新しい属性を作成する場合は、メッセージフィールドを削除します。
例：AWSインフラストラクチャからデータを転送している場合、ドロップルールを作成して不要なデータの肥大化を引き起こす可能性のあるAWS属性をドロップできます。

New Relicログのサイジング

ストレージの請求方法は、一部の競合他社とは異なる場合があります。ログデータの測定方法は、使用量の計算で定義されている他のタイプのデータの測定方法と請求方法と同様です。
クラウドインテグレーション（AWS、Azure、GCP）がインストールされている場合、すべてのログレコードにクラウドメタデータが追加され、全体的な取込み請求に加算されます。ただし、このデータは、取り込みを削減するためにドロップできます。
ログデータのオーバーヘッドの主な要因を、影響の大きい順に以下に示します。
- クラウドインテグレーション
- JSON形式
- ログパターン (ログUI でパターンを無効/有効にできます。)

ログの検索

一般的なログ検索では、UIで保存済みビューを作成して使用します。データの検索を作成し、列を追加をクリックして、追加の属性をUIテーブルに追加します。次に、列を移動して目的の順序で表示し、プライベートまたはパブリックのアクセス許可を持つ保存済みビューとして保存できます。保存したビューを公開するように設定して、関連するすべての属性データを表示して、ユーザーが一般的な検索を簡単に実行できるようにします。これは、ApacheやNginxなどのサードパーティ製アプリケーションの場合に最適な方法で、ユーザーは検索せずにこれらのログを簡単に確認できます。
クエリビルダーを使用して、NRQLで検索を実行します。クエリビルダーを使用すると、NRQLで使用可能な高度な機能をすべて使用できます。
ダッシュボードを作成するか、使用可能なクイックスタートのダッシュボードを使用して、ログに関する一般的な質問に回答し、時系列グラフでログデータを経時的に確認します。複数のパネルを備えたダッシュボードを作成すると、さまざまな方法でログデータを細かく分析できます。
capture()やaparse()などの高度なNRQL関数を使用すると、検索時にデータを解析できます。
ログ分析および/またはAPMログ監視クイックスタートダッシュボードをインストールして、ログデータに関するインサイトを迅速に取得できます。これらのダッシュボードを追加するには、one.newrelic.com > Add Data > Logging > Dashboardsに移動します。

次は何ですか？

ログ管理の開始を参照してください。

この機械翻訳は参考用に提供されます。