NRQLアラートコンディションで設定可能なクエリーの文字数には制限があります。例えばLogデータに対して、アラートコンディションを作成し、ブラックリスト方式で無視する文字列を徐々に追加されるような運用をされている場合、こちらの制限に達してしまい以下のようなエラーが表示される可能性がございます。
<condition name> has failed to save
An unexpected error occurred: DaqsValidationError.NrqlQueryTooLong: NRQL query too long
Logの監視自体は多くの場合、いわゆるアラート疲れを容易に引き起こすため、代わりにEventやMetricを使ってユーザ体験の悪化にに対してアラートを設定していただいた方が良いかと思われますが、そういったことが難しい場合に、代替案としてご利用できる方法をいくつか紹介します。
1. クエリーの最適化で対応する
こちら、難易度が多少高いですが、クエリーの条件に記載する文字列が似通っている場合、正規表現にて記載することで文字数を削減していただける可能性があります。RLIKEの演算子を使うと正規表現が利用できます。
2. ログパーシングの利用
ログパーシングは、ログから値を抽出して任意の属性に保存していただけます。具体的な実現方法はいくつかありますが、例えば、除外されたいエラーメッセーが「除外メッセージ」という文字列を含むようなLogの場合、Filter logs based on NRQLの欄にmessage LIKE '%除外メッセージ%'を設定していただき、Parsing ruleの欄に%{GREEDYDATA:ignoreAlert}を設定していただくことで、除外メッセージを含むログのignoreAlertという属性にmessageの内容がそのまま複製されます。
除外メッセージを含まない場合は、こちらのルールは適用されないので、アラートコンディションにて、「AND ignoreAlert IS NULL」という条件を追加するのみで、対象のLogをアラート対象から除外していただくことができます。
3. Drop filter ruleを使う
アラートから除外するLog自体が保存する必要がない場合、Drop filter ruleをご利用いただけます。こちらで対象のLogを破棄していただくことで、Logに保存されないので、自然にアラート対象から除外していただけます。
4. Log出力側で修正する
ログの転送方法や利用しているLoggerに大きく依存しているため、具体的な例はございませんが、送信元を修正していただき対象のLogに任意の属性をつけることで、除外していただくこともできるかと思われます。
また、Log出力時のLogレベルやメッセージ内容を変更して、アラートの条件に該当しないLogの内容に変更していただくという方法もあります。
まとめ
ブラックリスト方式を選択されている場合で、コード修正を行う予定がない場合、基本的には、除外対象が増えることがあっても、減ることはめったに無いかと思います。その場合、いつかは上限に達してしまいます。短期的に上記にて回避できる可能性はありますが、長期的にソフトウェアを修正して、ブラックリストを減らしていくということもご検討いただければ幸いでございます。
本ブログに掲載されている見解は著者に所属するものであり、必ずしも New Relic 株式会社の公式見解であるわけではありません。また、本ブログには、外部サイトにアクセスするリンクが含まれる場合があります。それらリンク先の内容について、New Relic がいかなる保証も提供することはありません。
