New Relic株式会社のQiita Organizationでは、
新機能を含む活用方法を公開していますので、ぜひフォローをお願いします。

はじめに

New Relicのログ管理機能を使っていますか？New Relicに関わらずログ解析を日々ガリガリ行っているなら、良い意味で楽しませんか？いや、ガリガリと毎日解析する位スキルが高いのだから、New Relicを使って効率を上げてもらって、新たな解析方法を検討したり、見つけた課題に対応する時間を増やすお手伝いができれば幸いです。

ログ管理機能ってどんなものあるんだっけ？

機能の詳細はいいので、とりあえず試してみたいという人はこちらから手を動かしてみるセクションにジャンプしてください。

New Relicが提供するログ管理機能は非常に多岐に渡るのですが、ログを自由に解析するという観点だと、New RelicポータルのLogsというメニューに主要な機能が集約されています。

Logsメニューにアクセスすると…New Relicポータルに集められたログが以下のように一元化されて表示されます。

大事なログ専用のメニューは以下のように色々な機能をもっています。

簡単に機能を紹介すると...

All logs(参考情報): 最も基本となるログを解析するためのメニューです。自由にログのフィルタ条件を設定したりログラインの詳細を確認したりすることができます。他のメニューにもありますが、設定したフィルタ条件を保存して再利用したり、グラフ化(可視化)することで他の方との皆生期結果を共有したり、同じような解析を毎回行わないようにすることができます。
Attributes(参考情報): 参照しているログに含まれるカラムの情報を活用して、UIベースでフィルタ条件を設定することがでできます。フィルタ条件の記載方法を把握しておかなくても直感的なフィルタ条件の作成が可能ですので、最初にこのメニューを試してみると利用が捗るかもしれませんね。
Patterns(参考情報): 参照している大量のログが同じ形式となっているものを自動で仕分けし、その結果を確認することができます。例えば、IDは異なっているけれど、同じ処理をした際に発生するログがどれだけあるのか？や、ログラインに含まれている時間情報は異なっているが、同じ情報を含むログはどれだけ発生したか？などを参照することができます。わざわざ集計や皆生期のためのパターンマッチングを作成しなければならないケースが減りそうですよね。
Drop filters(参考情報): 送信しているログラインの特定のカラムが特定の値を持っている場合に、そのログラインを廃棄する、あるいは、任意のカラムだけを廃棄するといったことが可能です。この機能を使う場合は、まずはログの転送元であるシステムのログレベルが適切になっているのか？他のログの送信制御ができないかを検討し(そもそものログを転送することで発生してるシステムの負荷やネットワークコストを減らしてから)、最後の砦として使ってもあるのが良さそうです。ここで必要以上に設定を行ってしまうと、いざという時に必要なログが無いということが発生するので、利用には最新の注意を払ってください。
Parsing(参考情報): 個人的にはこの機能によく救われています。1ラインのテキストで書かれたログを指定したルールに従ってJSON形式に変換して、ログデータとして保存します。JSON形式にしておくことで、上記で紹介した様々な機能をフル活用することが可能です。個人的には、アクセスログを解析することが多い(多かった)のですが、awkやsedを使って解析してという毎度毎度の苦行から解放されて、参照したいカラムを指定するだけで解析ができるようになります。
Data partitions(参考情報): 大量のログが一元化されるのは良いのですが・・・一緒にする必要がないログってありますよね。そういった場合には、パーティション(ログの格納領域)を分けることが可能です。わけることでできることが変わるのではないのですが、New Relicが保持しているデータに対して自由にクエリをかけることができる機能(通称: NRQL)を用いる際に、クエリ先のテーブルをわけることができます。例えば、Log_AAAとLog_BBBみたいにFROM句で指定するテーブル名が変わるイメージです。
Obfuscation(参考情報): とても見慣れない単語ですね。辞書を引くと難読化という意味だそうです。特定のカラムの内容をハッシュにかけて読めない形にしたり、マスクをかけて内容を参照できないようにすることができます。New Relicの仕様としては、個人に紐づくような情報は収集することはないのですが、もしシステムが生成するログにそのような情報が含まれている場合には、まずはそのような情報をログ経由で送信しないようにすることを検討いただき、その上で、上記のDrop filters機能や難読化を適用することを検討されると良いかと思います。
Lookup tables(参考情報): 参照用のテーブルを読み込ませることが可能です。例えば、ログラインの中で、特定の状態のものをテキストではなく数値で表現しているものがあると思いますが、その数値を任意の文字列に置き換える情報を事前に設定しておくことができます。よりわかりやすい例としては、httpのステータスコード(200はOKとか)があるかと思います。この機能を通して、解析した結果をよりわかりやすく周りの方と共有することが捗りそうですね。

実際にやってみよう

下準備 - 任意のカラムを追加してみる

一番最初にLogsのUI(Logs -> All logs)にアクセスした際は、表示されるログの内容は時間情報(timestamp属性)とログ内容(message属性)の2つだけのカラムとなっているのではないでしょうか？

任意のカラムは、ログ一覧を表示しているエリアの上部にあるAdd columnメニューから行います。メニューをクリックするとプルダウンが表示れるので、サーバ名やホスト名が格納されているhostnameを検索し、検索結果をクリックします。

ログの内容によって属性名が変わってきます。参照対象のログを1つクリックしてみることで、より詳細情報が表示されるので、参照しながらどのようなカラムを追加すればいいかを検討してください。

選択後、下の画像の様に追加したカラムが右に追加されます。カラム名部分をドラッグ＆ドロップすることで、表示順を変更することができるので、timesamp属性のカラムとmessage属性のカラムの間に動かしてみてください。

以下の様に表示が変わります。

日頃の使い慣れたカラムや順番があると思います。まずは、使い慣れた表示形式になるようにカラムの追加や順番の変更を行ってみてください。
カラムの変更については、ブラウザ上のキャッシュに記録が残るので、ブラウザを閉じても、次回以降も再利用が可能です。

実際にログにフィルタをかけてみよう

先のセクションで様々な機能の頭出しをさせて頂きましたが、最もベーシックなフィルタを手動で設定する方法を試してみます。
想定:

hostname属性の値がhost-proxy-west-2となっている
message属性の値にerrorという文字列を含んでいる

最初にフィルタにどの様な記載をしてしまえばいいかを言ってしまうと、以下の通りです。

hostname: "host-proxy-west-2" AND message: "*error*"

Logs UIも以下の様に時系列での発生するや該当ログを確認することが可能です。

では、最初からやってみましょう。
Logs -> All logsにアクセスし、空となっているフィールドにhostnameと入力して下さい。カラムを追加した時と同じ様に、入力した文字列に併せて候補となる属性名が表示されます。もし入力が完了していない場合には直接カラム名をクリックして下さい。

カラム名を選択することで、属性名と値の関係(イコール、含む、始まり、終わり、またはそれら否定形)を指定する記載方法も併せて表示されます。

属性の値はhost-proxy-west-2のものを指定したいので、equals attribute:"value"となっている項目を選択します。ログに含まれる実データから、指定したい値の一覧が表示されるので、そちらから選択するか、あるいは、直接指定したい値を入力します。

以下のようになります。ここでキーボードのENTERを入力するか、右側のQuery logsボタンをクリックすることで、ログもフィルタがかかります。

更にもう一つのフィルタ条件(message属性の値にerrorという文字列を含んでいる)を設定するために、1つ目の条件に加えてANDと追記します。

フィルタ条件を複数設定する場合に、ANDやORを利用することができます。

同様に、message属性を指定し、特定の文字列を含むための条件を指定するためにcontains attribute:"value"となっている項目を選択します。

選択後、含んでいる文字列や値を入力(今回の例だと、error文字列を含む)することで、フィルタの設定は完了します。以下がその例となります。

お手元で、いつも設定しているロジックを設定してみましょう。

今回はあまりの情報の多さから新たなログの解析機能を全て紹介することはできませんでしたが、続々と便利機能をリリースしています。ご興味のある方は、是非、New Relicのブログを定期的にチェックして、最新アップデート情報を確認して下さい。

例えば、New Relic アップデート(2024年5月)
やNew Relic アップデート一覧
に関連する最新情報をポストしているので、思わぬ便利機能に出会えるかもしれません。

さいごに

同じフィルタ設定をいつもやっていると感じたら？

『あれ？いつもおなじことやっていない？』と感じたら・・・きっと、それはとても良い気づきを得たのかもしれません。エンジニアの本能が、新しいことをやってみたいと感じている時なのかもしれませんね。

そんな時は、最初に・・・、

もし、同じような作業をいつも行っていると感じた場合には、フィルタした結果を常に可視化したり(下部のNRQLボタンより実施)、設定内容をViewという形で保存(Saved viewsより実施)し任意のViewを再利用することで、いつも同じ作業を行わない工夫をしてみましょう。

次に・・・、いつもログを解析して得ようとしているデータの目的を考え直してみましょう。例えば、時間あたりのログの数を計算しているようであれば、その解析の目的はシステムやサービスにかかっている負荷のピーク時間帯を把握したいという背景があるかもしれませんね。その場合には、New Relicであれば、サーバのキャパシティ状態を収集するInfrastructureのデータを活用したり、APMを用いたアプリケーションのリクエスト処理数を見てあげることでログだけに頼った解析をしなくても良くなることが期待できます。

今回のポストではInfrastructureやAPMの詳細は割愛しますが、New Relicが提供する様々なエージェントや機能を活用することで、ログを頑張って解析するという機会は減らしつつ、本当に得たいデータを収集することが容易に行えるようになります。その結果、取得したデータから目的としている気づき(原因箇所だったり、改善のための適切な優先度づけなど)を得たり、ログ自身は事実を確認するための最終確認の情報として用いるという使い分けができるようになります。

ん？要するに？

ログの解析って、面白いけど、みなさんがログ解析をしているのって、そこがゴールじゃないですよね？なので、まずは色々なデータを集めて、様々な観点で現状を把握することができたら、本当にやりたいことを実現することができそうですよね。そのデータから得た気づきを本当に事実なのか・・・という最終確認としてログを活用できれば、日々のログと睨めっこしながら『何が起きているんだろう？』という不安な時間を減らしつつ、エンジニアとしてワクワクする時間がふえそうじゃないですか？

もし少しでも『そうだよな。ログ以外にも他の方法で必要なデータを収集する方法はないかな？』と思ったら、是非是非、New Relicを用いることを検討して下さい。無料で試せるので、ご興味があれば下のリンクを確認してみてください。

無料のアカウントで試してみよう！

New Relic フリープランで始めるオブザーバビリティ！