New Relicログ機能のベストプラクティスガイドへようこそ。ここでは、ログ機能を最適化し、データ消費を管理する方法に関する詳細な推奨事項をご覧いただけます。
ヒント
ログがたくさんありますか? それらを最適化および管理する方法については、チュートリアルをご覧ください。
ログの転送
ログ転送ドキュメントを補足するためのログ転送のヒントは次のとおりです。
ログを転送する場合は、New Relic Infrastructureエージェントおよび/またはAPMエージェントを使用することをお勧めします。New Relicエージェントを使用できない場合は、他の対応エージェント(FluentBit、Fluentd、Logstashなど)を使用してください。
以下は、対応ロギングエージェントのGithub設定例です。
重要
ログが基盤となるホスト/コンテナのディレクトリに保存されていて、ログを収集するためにインフラストラクチャ エージェントによってインストルメント化されている場合、インフラストラクチャ エージェントと エージェント。 重複したログを送信しないようにするには、 このガイドの推奨事項を参照してください。
転送するすべてのデータに
logtype
属性を追加します。この属性は、組み込みの解析ルールを使用するために 必要であり 、データ型に基づいてカスタムの解析ルールを作成するためにも使用できます。logtype
属性は既知の属性と見なされ、クイックスタートで使用されます ログの概要情報。既知のログタイプには、組み込みの解析ルールを使用します。関連する
logtype
属性を設定すると、さまざまな既知のログタイプからログが自動的に解析されます。以下は、Infrastructureエージェントが転送したログに
logtype
属性を追加する方法の例です。logs:- name: mylogfile: /var/log/mylog.logattributes:logtype: mylogNew Relicインテグレーションを使用して、次のような一般的な他のデータ型のログを転送します。
- コンテナ環境:Kubernetes(K8S)
- クラウドプロバイダーの統合:AWS、Azure、GCP
- ロギングでサポートされているその他のオンホストインテグレーション
データパーティション
1 日あたり 1 TB 以上のログ データを消費している場合は、機能的およびテーマ別のグループ化を行う方法でデータを分割する計画など、ログの取り込みガバナンス計画に確実に取り組む必要があります。パーティションごとに 1 TB 以下のベスト プラクティスをお勧めします。これにより、パフォーマンスと使いやすさの両方が実現されます。すべてのログを 1 つのアカウント内の 1 つの巨大な「バケット」 (デフォルトのログ パーティション) に送信した場合、クエリの速度が低下したり、クエリが失敗したりする可能性があります (検査されたカウント制限に達するため)。
クエリのパフォーマンスを向上させる 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関数を使用すると、検索時にデータを解析できます。
- Logs analysis および/または APM logs monitoring quickstart をインストールします ログ データの詳細をすばやく把握できます。 これらのダッシュボードを追加するには 、one.newrelic.com > Add Data > Logging > Dashboardsに移動します。
次は何ですか?
ログ管理の開始を参照してください。