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

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

ヒント

ログがたくさんありますか? それらを最適化および管理する方法については、チュートリアルをご覧ください。

ログの転送

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

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

データパーティション

毎日大量のログデータを消費している、または消費する予定がある場合は、機能別およびテーマ別にグループ化してデータを分割する計画を含め、ログの取り込みガバナンス計画を必ず作成する必要があります。データパーティションを適切に使用することで、パフォーマンスを大幅に向上できます。すべてのログを 1 つのアカウント内の 1 つの巨大な「バケット」 (デフォルトのログパーティション) に送信すると、各書き込みの結果を返すためにアカウント内のすべてのログをスキャンする必要があるため、書き込みが遅くなったり、書き込みに失敗したりする可能性があります。詳細については、「NRQL クエリレート制限」を参照してください。

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

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

ログのオンボーディングプロセスの早い段階で、パーティションを使用するようにしてください。ユーザーが特定のログを検索して見つけた場所を把握できるように、パーティションを使用する方策を作成します。そうすることで、ログジャーニーの後半でパーティションを実装する場合、アラート、ダッシュボード、保存済みビューを変更する必要がなくなります。
環境または組織内の静的または頻繁に変更されないカテゴリ (たとえば、ビジネスユニット、チーム、環境、サービスなど) に合わせてデータパーティションを作成します。
パーティションを作成して、最も一般的なクエリに対してスキャンする必要があるイベントの数を最適化します。取り込み量が多い場合、短い時間枠内に多くのイベントが発生するため、長期間にわたる検索には時間がかかり、タイムアウトになる可能性があります。厳格なルールはありませんが、一般的に「スキャンされた」ログイベントは 5 億 (特に 10 億) を超えます。一般的なクエリの場合は、パーティション分割の調整を検討してください。
取り込み量が少ない場合でも、データパーティションを使用してデータを論理的に分離したり、個別のデータ型間でクエリのパフォーマンスを改善したりすることもできます。
Logs 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
```

解析ログ

ログを取り込み時に解析することは、ログデータを自分や組織内の他のユーザーがより使いやすくするための最善の方法です。属性を解析すると、クエリ時にデータを解析しなくても、 Logs UI と NRQL で簡単に検索できるようになります。これにより、やダッシュボードでも簡単に使用できるようになります。

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

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

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

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

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

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

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

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

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

New Relicログのサイジング

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

ログの検索

一般的なログ検索の場合は、UI でSaved viewsを作成して使用します。データの検索を作成し、 + Add Columnをクリックして UI テーブルに追加の属性を追加します。次に、列を移動して希望の順序で表示し、プライベートまたはパブリックの権限を持つ保存済みビューとして保存します。保存したビューを公開するように構成すると、自分や他のユーザーが関連するすべての属性データを表示しながら一般的な検索を簡単に実行できるようになります。これは、Apache、nginx などのサードパーティアプリケーションでは良い方法であり、ユーザーは検索せずにそれらのログを簡単に確認できます。
を使用して検索を実行するには、書き込みビルダーをNRQL 使用し、その高度な機能を利用します。複数のアカウントからログをクエリし、対応するアカウント ID で識別するには、NRQL クエリのSELECTステートメントにaccountId() as accountId含めます。
を作成するか、利用可能なクイックスタートを使用して、ログに関する一般的な質問に答えたり、時系列グラフでログデータを経時的に確認したりできます。複数のパネルを備えたダッシュボードを作成し、ログデータをさまざまな方法で細分化します。
capture()やaparse()などの高度なNRQL関数を使用すると、検索時にデータを解析できます。
Logs analysisおよび/またはAPM logs monitoring quickstartダッシュボードをインストールして、ログデータへのインサイトを迅速に増やします。これらのダッシュボードを追加するには、 one.newrelic.com > Integrations & Agents > Logging > Dashboardsに移動します。

次は何ですか？

の使用開始を参照してください。

この機械翻訳は、参考として提供されています。