1. はじめに

システム監視において、ログは詳細な分析情報を提供し、メトリクスはシステムパフォーマンスの合理的なビューを提供します。このガイドでは、軽量なオープンソースのセットアップを使用して、生のログを使用可能なメトリクスに変換する方法を説明します。また、Telegrafエージェントを使用して、ログを簡単に視覚化してアラートを生成できるGraphiteメトリクスに変換します。これは、システム管理者、DevOps初心者、または革新的な監視パイプラインをゼロから構築することに関心のある方に最適です。このチュートリアルを開始するためにMetricFireのHosted Graphiteアカウントをまだお持ちでない場合は、こちらから14日間の無料トライアルにサインアップしてください。

この例では、Grok検索パターンを使用してsyslogメッセージをプルし、Telegraf入力プラグインを使用してデータソースに転送します。

Grokパターンの設定が面倒な場合は、「ログからメトリクスへ」シリーズのパート1をご覧ください。Loki、Telegraf、および簡単なPythonスクリプトを使用して、同様のsyslogメッセージをGraphiteメトリクスに変換する方法について詳しく説明しています。

主なポイント：

可観測性の強化：ログをメトリクスに変換することで、システムパフォーマンスを簡潔に把握でき、監視とアラート通知が容易になります。
カスタマイズ可能な解析：Grokパターンにより、ログから関連データをカスタマイズして抽出できるため、特定の監視ニーズに合わせたメトリクスの適用が可能になります。
スケーラブルなソリューション：TelegrafとGraphiteを活用することで、大規模なログ管理スタックに代わる軽量でスケーラブルなソリューションを提供できます。
応答性の向上：ログから得られるメトリクスにより、異常の迅速な検出と効率的なトラブルシューティングが可能になります。
費用対効果の高い監視：オープンソースツールを活用することで、高価な独自ソリューションの必要性が軽減され、あらゆる規模の組織で利用できるようになります。

2. 重要なシステムログを特定

Linuxシステムは、ほぼすべてのアクティビティをsyslog（通常/var/log/syslogまたは/var/log/messagesにある集中ログファイル）に書き込みます。syslogには、システムサービス、cronジョブ、認証試行、ネットワークの問題、パッケージ更新などのイベントが含まれます。syslogは人間が判読できるトラブルシューティング用に設計されていますが、多くのエントリは一貫したパターンに従っているため、メトリクスの抽出に適しています。これらの構造化されたログをメトリクスに変換することで、生のログをインデックス化して保存することなく、システムの動作を経時的に追跡できます。

一般的なsyslogメッセージ

CRONジョブ実行：
- 例：CRON[12345]: (root) CMD (/usr/local/bin/backup.sh)
- 用途：ジョブの実行頻度をカウントし、障害やスケジュール未達を特定します。
サービス開始/停止イベント（systemd）：
- 例：systemd[1]: nginxを停止しました
- 用途：サービスの安定性と稼働時間を監視し、予期しない再起動を警告します。
カーネル警告またはネットワークエラー:
- 例: kernel: TCP: too many retransmissions
- 使用法: ネットワークの不安定性、ディスクエラー、ハードウェアの問題など、システムレベルの問題を検出します。

この例では、CRON がスケジュールされたタスクを実行する頻度をカウントし、内部自動化ツール (Puppet) が設定を適用するのにかかる時間を測定します。/var/log/syslog 内の行にマッチさせるために必要な Grok パターンを定義するために使用する syslog メッセージは以下のとおりです。

May  9 19:47:01 <host-name> CRON[843454]: (root) CMD (/usr/local/bin/health_check 2>&1|/usr/local/bin/send_to_cronspam)

May  9 19:44:17 <host-name> puppet-agent[839530]: Applied catalog in 30.74 seconds

3. カスタムGrokを定義

Grokは、非構造化ログ行から構造化フィールドを抽出するパターンマッチング構文です。再利用可能な正規表現パターンと名前付きキャプチャグループを連結することで機能します。Telegrafでは、grok_patternsを使用することで、特定のログ形式にマッチさせ、ユーザー名、期間、コマンド、エラーコードなどの重要な値を抽出し、時系列メトリクスに変換できます。2つのSyslogメッセージをGrokパターンに変換する方法を詳しく説明します。

Cronジョブ実行パターン
Syslogの例：

May  9 19:47:01 <host-name> CRON[843454]: (root) CMD (/usr/local/bin/health_check 2>&1|/usr/local/bin/send_to_cronspam)

Grok 一致パターン:

"%{SYSLOGTIMESTAMP:timestamp} %{HOSTNAME:host} %{WORD:program}(?:\\[%{NUMBER:pid:int}\\])?: %{GREEDYDATA:message}"

この柔軟なキャッチオールパターンは、幅広い標準Syslogメッセージに一致します。各Grokコンポーネントは、既知のログ構造に一致し、それを名前付きフィールドに割り当てます。

%{SYSLOGTIMESTAMP:timestamp} => Matches May 9 19:47:01
%{HOSTNAME:host} => Matches
%{WORD:program} => Matches CRON
%{NUMBER:pid:int} => Extracts the numeric process ID (843454)
%{GREEDYDATA:message} => Captures the entire command being executed

この行はcatch-allによって解析され、最終的に count = 1という増分メトリックを送信します。これにより、スケジュールされたタスクの実行頻度を追跡できます。

Puppet エージェントの期間パターン

Syslogの例:

May  9 19:44:17 <host-name> puppet-agent[839530]: Applied catalog in 30.74 seconds

特定の Grok パターン:

"%{SYSLOGTIMESTAMP:timestamp} %{HOSTNAME:host} puppet-agent\\[%{NUMBER:pid:int}\\]: Applied catalog in %{NUMBER:duration:float} seconds"

このより具体的なGrokルールは、Puppetカタログアプリケーションログのみに一致し、実行時間を数値フィールドとして取得します。Grokパターンもトップダウンで評価されるため、より具体的なパターンは最後に配置されます。これは、包括的なパターンによって上書きされるのを防ぐためです。

duration => Parsed as a floating-point number (30.74)

このフィールドはTelegrafで実行時間メトリックとなり、グラフ化することでPuppet実行パフォーマンスの経時的なモニタリングが可能です。

4. ログを処理するようにTelegrafを構成

OS 上で Telegraf のインスタンスがまだ実行されていない場合は、便利な HG-CLI ツールをインストールして、Telegraf をすぐに起動して実行してください。

curl -s "https://www.hostedgraphite.com/scripts/hg-cli/installer/" | sudo sh

ツールをインストールしたら、TUIモード（hg-cli tui）で実行し、HG APIキーを入力して、プロンプトに従ってTelegrafエージェントをインストールします。

次に、Telegraf設定ファイル（/etc/telegraf/telegraf.conf）を開き、以下のコードを追加します。

[[inputs.tail]]
  name_override = "syslog-to-telegraf"
  files = ["/var/log/syslog"]
  from_beginning = true
  watch_method = "inotify"
  path_tag = ""
  data_format = "grok"
  grok_patterns = [
    "%{SYSLOGTIMESTAMP:timestamp} %{HOSTNAME:host} %{WORD:program}(?:\\[%{NUMBER:pid:int}\\])?: %{GREEDYDATA:message}",
    "%{SYSLOGTIMESTAMP:timestamp} %{HOSTNAME:host} puppet-agent\\[%{NUMBER:pid:int}\\]: Applied catalog in %{NUMBER:duration:float} seconds"
  ]
  fieldexclude = ["remainder", "timestamp", "pid"]

[[processors.starlark]]
  namepass = ["syslog-to-telegraf"]
  source = '''
def apply(metric):
    metric.fields["count"] = 1
    return metric
'''

## Optional:
## Uncomment these outputs to print metrics to stdout for debugging and Graphite format preview

#[[outputs.file]]
#  files = ["stdout"]

#[[outputs.file]]
#  data_format = "graphite"
#  templates = [
#    "host.measurement.field"
#  ]
#  files = ["stdout"]

ここでは多くの処理が行われています。これらのプラグインがログ行を時系列メトリクスに変換する仕組みを詳しく説明しましょう。

[[inputs.tail]]

機能：

このプラグインは、syslog ファイル (/var/log/syslog) をリアルタイムで監視し、新しい行が書き込まれるとそれを読み取ります。これは、システムアクティビティのライブフィードのようなものです。

主な設定：

initial_read_offset = 'beginning'：初回実行時はファイルの先頭から開始します（テストに適しています）。
data_format = "grok": 各行は、上記で定義した Grok パターンを使用して解析されます。
name_override = "syslog-to-telegraf": すべてのメトリクスは、この名前をプレフィックスとして使用します。

ここでの Grok の使用方法：

最初のパターンは包括的なものです。プログラム名や完全なメッセージなど、ほとんどの syslog 行から共通するフィールドを取得します。
2 番目のパターンはより具体的で、Puppet ログを対象とし、カタログの適用にかかった時間 (期間) を抽出します。これはメトリック追跡用に float として保存されます。

[[processors.starlark]]

機能:

Telegraf が処理するすべてのログイベントに count = 1 フィールドを追加します。

必要な理由:

Graphite は数値フィールドのみを保存するため、count を追加することで、一致したログ行をメトリックとして扱い、その発生頻度をグラフ化できます。

Telegrafを実行

ファイルを保存し、Telegraf サービスを再起動すると、Tail Input プラグインが syslog ファイルを読み取り、一致するパターンを抽出し、それらをメトリックとして Hosted Graphite アカウントに転送します。

telegraf --config /etc/telegraf/telegraf.conf

注) HG-CLIツールを使用してTelegrafをインストールした場合、Telegrafのoutputs.graphiteプラグインはすでに設定されているはずです。MetricFireアカウントをまだお持ちでない場合は、別のTelegraf出力を設定して、メトリックを別のデータソースに転送できます。

5. Grafanaでメトリクスを可視化

TelegrafがOS上で実行されると、メトリクスはHosted Graphiteアカウントに転送され、メトリクス検索UI（プレフィックスは*.syslog-to-telegraf.*）で確認できます。

これらのメトリクスを使用してHosted Grafanaで可視化を行う方法については、ダッシュボードのドキュメントをご覧ください。以下は、2つのsyslog行をメトリクスとしてログに記録した例です。

6. まとめ

重要なログメッセージをメトリクスに変換することで、システム内で何が起こっているかを時間の経過とともに追跡するためのシンプルかつ強力な方法が得られます。ログを1行ずつ調べる代わりに、グラフをざっと見るだけで、CRONジョブの実行、サービスの再起動、Puppetによる設定の適用など、何かがどのくらいの頻度で発生しているかを確認できます。これは、ログインデックスパイプラインを完全に構築することなく、履歴コンテキストを取得し、異常なパターンを早期に発見し、システムの動作を監視するための軽量な方法です。

さらに詳しく知りたいですか？今すぐお問い合わせください。モニタリングをお楽しみに！

目次