CloudWatchログを最適化：collectdの不要なログ出力を減らす方法
閲覧いただきありがとうございます！"さいとう"と申します。わたしは異業種・未経験からIT業界に転職し、現在インフラエンジニアとしてクラウド環境の設計や構築・運用の支援を行っています。
Linux OSにCloudWatchエージェントをインストールすると、モニタリングツールとして“collectd"をインストールすることが多いですよね。
collectdはシステムのパフォーマンスデータを収集し、それをCloudWatchに送信する役割を果たします。しかし、後日サーバーのログを確認しようとCloudWatchログをチェックした際に、「secondary info Available write targets: [none]」というメッセージが大量に出力されている状況に直面しました。
このようなメッセージが大量に出力されると、ログが膨大になり、必要な情報が埋もれてしまうことがあります。また、不要なログの記録がシステムのパフォーマンスやリソースにも悪影響を及ぼす可能性があるため、対策が必要です。これに気づいてから、collectdの設定を見直し、ログの出力内容を最適化する必要性を感じました。
この記事では、collectdの設定を変更し、不要なログの出力を減らす方法を具体的に紹介します。設定の調整を通じて、システムのログを適切に管理し、効率的なモニタリングを行えるようにするための手順を詳しく解説します。
この設定変更により、必要なログに集中できる環境を整え、ログ管理の効率を大幅に向上させることができるでしょう。
syslogへのcollectd大量ログが発生
■現状
CloudWatchロググループを覗いてみると、
2023-01-23T14:29:40.439+09:00 Jan 23 14:29:40 secondary info Available write targets: [none]
2023-01-23T14:29:40.439+09:00 Jan 23 14:29:40 secondary info Available write targets: [none]
2023-01-23T14:29:40.439+09:00 Jan 23 14:29:40 secondary info Available write targets: [none]
2023-01-23T14:29:40.439+09:00 Jan 23 14:29:40 secondary info Available write targets: [none]
2023-01-23T14:29:40.439+09:00 Jan 23 14:29:40 secondary info Available write targets: [none]
2023-01-23T14:29:40.439+09:00 Jan 23 14:29:40 secondary info Available write targets: [none]
2023-01-23T14:29:40.439+09:00 Jan 23 14:29:40 secondary info Available write targets: [none]
2023-01-23T14:29:40.439+09:00 Jan 23 14:29:40 secondary info Available write targets: [none]
2023-01-23T14:29:40.439+09:00 Jan 23 14:29:40 secondary info Available write targets: [none]
2023-01-23T14:29:40.439+09:00 Jan 23 14:29:40 secondary info Available write targets: [none]
2023-01-23T14:29:40.439+09:00 Jan 23 14:29:40 secondary info Available write targets: [none]
2023-01-23T14:29:40.439+09:00 Jan 23 14:29:40 secondary info Available write targets: [none]
2023-01-23T14:29:40.439+09:00 Jan 23 14:29:40 secondary info Available write targets: [none]
2023-01-23T14:29:40.439+09:00 Jan 23 14:29:40 secondary info Available write targets: [none]
2023-01-23T14:29:40.439+09:00 Jan 23 14:29:40 secondary info Available write targets: [none]
2023-01-23T14:29:40.439+09:00 Jan 23 14:29:40 secondary info Available write targets: [none]
2023-01-23T14:29:40.439+09:00 Jan 23 14:29:40 secondary info Available write targets: [none]
2023-01-23T14:29:40.439+09:00 Jan 23 14:29:40 secondary info Available write targets: [none]
2023-01-23T14:29:45.371+09:00 Jan 23 14:29:40 secondary info Available write targets: [none]
2023-01-23T14:29:50.468+09:00 Jan 23 14:29:50 secondary info Available write targets: [none]
2023-01-23T14:29:50.468+09:00 Jan 23 14:29:50 secondary info Available write targets: [none]
2023-01-23T14:29:50.468+09:00 Jan 23 14:29:50 secondary info Available write targets: [none]
2023-01-23T14:29:50.468+09:00 Jan 23 14:29:50 secondary info Available write targets: [none]
2023-01-23T14:29:50.468+09:00 Jan 23 14:29:50 secondary info Available write targets: [none]
2023-01-23T14:29:50.468+09:00 Jan 23 14:29:50 secondary info Available write targets: [none]
2023-01-23T14:29:50.468+09:00 Jan 23 14:29:50 secondary info Available write targets: [none]
2023-01-23T14:29:50.468+09:00 Jan 23 14:29:50 secondary info Available write targets: [none]
2023-01-23T14:29:50.468+09:00 Jan 23 14:29:50 secondary info Available write targets: [none]
2023-01-23T14:29:50.468+09:00 Jan 23 14:29:50 secondary info Available write targets: [none]
2023-01-23T14:29:50.468+09:00 Jan 23 14:29:50 secondary info Available write targets: [none]
2023-01-23T14:29:50.468+09:00 Jan 23 14:29:50 secondary info Available write targets: [none]
2023-01-23T14:29:50.468+09:00 Jan 23 14:29:50 secondary info Available write targets: [none]
2023-01-23T14:29:50.468+09:00 Jan 23 14:29:50 secondary info Available write targets: [none]
2023-01-23T14:29:50.468+09:00 Jan 23 14:29:50 secondary info Available write targets: [none]
2023-01-23T14:29:50.468+09:00 Jan 23 14:29:50 secondary info Available write targets: [none]
2023-01-23T14:29:50.468+09:00 Jan 23 14:29:50 secondary info Available write targets: [none]
2023-01-23T14:29:50.468+09:00 Jan 23 14:29:50 secondary info Available write targets: [none]
2023-01-23T14:29:50.468+09:00 Jan 23 14:29:50 secondary info Available write targets: [none]
2023-01-23T14:29:50.468+09:00 Jan 23 14:29:50 secondary info Available write targets: [none]
2023-01-23T14:29:50.468+09:00 Jan 23 14:29:50 secondary info Available write targets: [none]
2023-01-23T14:29:50.468+09:00 Jan 23 14:29:50 secondary info Available write targets: [none]
2023-01-23T14:29:50.468+09:00 Jan 23 14:29:50 secondary info Available write targets: [none]
2023-01-23T14:29:50.468+09:00 Jan 23 14:29:50 secondary info Available write targets: [none]
2023-01-23T14:29:50.468+09:00 Jan 23 14:29:50 secondary info Available write targets: [none]※このログは一部です。
CloudWatchログは収集や保存に料金が発生しますので、なんとかしたいですよね。
詳しく見てみると、collectdが出力しているログだとわかりました。
■対処法
collectdに関する設定は[/etc/collectd.conf]で指定されています。今回の大量ログはsyslogへの出力ログレベルがinfoなので出ていたようなので、ログレベルをnoticeに変更します。要件がinfo以上の場合はやめましょう。
ちなみに、ログレベルは以下の通りです。
| ログのレベル | 説明 |
|---|---|
| debug | デバッグ |
| info | 情報 |
| notice | 通知 |
| warning | 警告 |
| err | エラー発生 |
| crit | 致命的な問題 |
| alert | 早急に修正すべき問題 |
| emerg | システム不能の非常事態 |
[/etc/collectd.conf]の変更イメージは以下です。
#<Plugin syslog>
# LogLevel info
#</Plugin>
↓
<Plugin syslog>
LogLevel notice
</Plugin>
まず“collectd.conf”の中身を確認します。
less /etc/collectd.conf
ファイルのボリュームが大きいので、検索します。
/#<Plugin syslog>vi
以下のように変更しましょう。
#<Plugin syslog>
# LogLevel info
#</Plugin>
↓変更
<Plugin syslog>
LogLevel notice
</Plugin>
保存して終了しましょう。
:wq
編集しましたら、サービスを再起動しましょう。
systemctl restart collectd
systemctl status collectd
以上です。
まとめ
CloudWatchログを使ってログ収集を行うことは、サーバーやアプリケーションのモニタリングにおいて非常に重要なプロセスです。
しかし、今回のケースを通じて、ログの収集はあくまでスタート地点であり、適切に管理・最適化することが非常に重要であることを改めて認識しました。ログが過剰に出力されたり、不要なメッセージが大量に含まれていると、必要な情報が見つけにくくなるだけでなく、システムパフォーマンスやリソースの無駄遣いにもつながる可能性があります。
適切なログ管理を行うためには、collectdのようなログ収集エージェントの設定を見直し、必要な情報だけを効率的に収集することが大切です。ログの出力内容を調整することで、情報のノイズを減らし、モニタリングの精度や有用性を高めることができます。
今後は、ただログを収集するだけでなく、どのようなログが実際に重要で、どの情報が運用に役立つのかを見極めて、さらにログ管理に向き合っていきたいと思います。これにより、システムの状態を的確に把握し、迅速な問題解決や運用効率の向上を目指していきます。ログ管理の重要性を理解しつつ、継続的に最適化を進めることが、インフラ運用における成功の鍵となるでしょう。
参考リンク：AWS公式ドキュメント