どのログを取り込んで保存するかを決めたら、ログを整理します。おそらく、依然として数百ギガバイトまたは数十テラバイトのログを取り込むことになります。当初よりはかなり減りましたが、効果的に使用しようとすると、やはり苦労が必要になります。
これを解決するために、これらの残りのログをテーマ別のパーティションにグループ化し、ログを解析して貴重な属性を取り出してタグ付けします。この方法でログを整理すると、次のことが可能になります。
- ログ内の任意の属性をクエリします
- フロントエンド ログとバックエンド ログなど、特定のパーティションを一度に管理
- クエリのロード時間を短縮する
ログを分割する理由
データ パーティションを適切に使用することで、パフォーマンスを大幅に向上できます。 データを個別のパーティションに整理すると、必要なデータだけをクエリできるようになります。 単一のパーティションまたはコンマで区切られたパーティションのリストをクエリできます。 データをパーティション分割する目的は次のとおりです。
- 環境または組織内の静的または頻繁に変更されないカテゴリ (たとえば、ビジネス ユニット、チーム、環境、サービスなど) に合わせてデータ パーティションを作成します。
- パーティションを作成して、最も一般的なクエリに対してスキャンする必要があるイベントの数を最適化します。 確立されたルールはありませんが、一般的に、スキャンされたログイベントは、
common書き込みに対して 5 億以上（特に 10 億以上）になるため、パーティショニングの調整を検討することをお勧めします。
パーティションの名前空間は、その保持期間を決定します。 2つの保持オプションを提供します。
- Standard: New Relic サブスクリプションによって決定されるアカウントのデフォルトの保持期間。 これは、アカウントで利用可能な最大保持期間であり、ほとんどのパーティションに対して選択するネームスペースです。
- Secondary: 30日間保持されます。 セカンダリ ネームスペースのメンバーであるパーティションに送信されたすべてのログは、取り込まれてから 30 日後に定期的に削除されます。
ログを解析する理由
取り込み時にログを解析することは、あなたや組織内の他のユーザーがログ データをより使いやすくするための最良の方法です。たとえば、Grok 解析ルールを使用して、次の 2 つのログを解析前と解析後で比較します。
事前解析:
{ "message": "32 4329 store_Portland"}事後解析:
{ "transaction_total": "32", "purchase_number": "4329", "store_location": "store_Portland",}これにより、ダッシュボードやアラートで transaction_total などの新しく定義された属性を簡単にクエリできるようになります。
ログを整理する
ACME Corp が今後数か月間で約 2 TB のログを取り込むことが分かっているとします。Java アプリとインフラストラクチャ エージェントからのログのパーティションを作成したいと考えています。彼らは、遠い将来に Java ログをクエリする必要があるかもしれないと考え、標準の保存期間を使用することにしました。一方、最近のインフラストラクチャ ログのみが必要なため、それらに対しては二次保持を使用します。
そのためには
UIに移動します
ログを分割する
- 左側のナビゲーションのManage dataからData partitionsをクリックし、次にCreate partition ruleをクリックします。
- パーティション名を、
Log_で始まる英数字の文字列として定義します。この場合、Log_java。 - 任意の説明を追加します。
- パーティションの標準の名前空間保持を選択します。
- ルールの一致基準を設定します。このパーティションに保存するログと一致する有効な NRQL
WHERE句を入力します。この場合、logtype=java。 - 新しいパーティションを保存するには、 Createをクリックします。
これにより、すべての Java ログに対して標準のデータ保持を持つデータ パーティションが作成されます。インフラストラクチャ ログを整理するには、上記と同じ手順に従い、保持をセカンダリに変更し、クエリを logtype=infrastructureに変更するだけです。
ログを解析する
ログが分割されたので、今度はログを解析します。それらを解析すると、ログ内の関連データを抽出して、クエリとアクセスを容易にすることができます。
ログを解析するには:
- ログ UI の左側のナビゲーションのManage Dataから、 Parsingをクリックし、次にCreate parsing ruleをクリックします。
- 新しい解析規則の名前を入力します。
- 解析する既存のフィールドを選択するか (デフォルトは
message)、または新しいフィールド名を入力します。 - 解析するログに一致する有効な NRQL
WHERE句を入力してください。 - 一致するログが存在する場合はそれを選択するか、「ログの貼り付け」タブをクリックしてサンプル ログを貼り付けます。
- 解析ルールを入力し、 Outputセクションの結果を表示してそれが機能していることを確認します。 （下記の例を参照）
- カスタム解析ルールを有効にして保存します。
次の例は、解析ルールを作成する具体的な例を示しています。
ログを解析するための Grok パターンの作成の詳細については、 ブログ投稿を参照してください。
次のステップ
ログの真の価値を明らかにし、ログに関するチームのストレス時間を節約できたことをお祝いします。 システムが成長し、データを取り込むにつれて、解析ルールとパーティションの維持管理を確実に行う必要があります。 New Relic で何ができるかについて詳しく知りたい場合は、次のドキュメントをご覧ください。
- ログ データの解析: Grok を使用したログの解析を詳しく調べ、GraphQL API である NerdGraph を使用してログ解析ルールを作成、クエリ、管理する方法を学びます。
- ログ パターン: ログ パターンは、検索せずにログ データの値を発見する最速の方法です。
- ログの難読化: ログの難読化ルールを使用すると、特定の種類の情報が New Relic に保存されないようにすることができます。
- 長いログ (BLOB) でデータを検索する: 大量のログ データは、問題のトラブルシューティングに役立ちます。しかし、ログ内の属性に数千の文字が含まれている場合はどうなるでしょうか?New Relic はこのデータのうちどれくらいの量を保存できますか?そして、このすべてのデータから有用な情報を見つけるにはどうすればよいでしょうか?