現在位置: ホーム / Red Hat Ch. / Red Hat Blog / ABRTで障害時の情報収集とレポートを自動化しよう

ABRTで障害時の情報収集とレポートを自動化しよう

Red Hat Enteprise Linux 6から、ABRT(Automatic Bug Reporting Tool)が同梱されています。RHELを運用していて、ABRTからのレポートメール「[abrt] full crash report」を受信したことがある方もいるかと思います。今回はRHEL7でのABRTについて見てみましょう。

レッドハットの森若です。Red Hat Enteprise Linux 6から、ABRT(Automatic Bug Reporting Tool)が同梱されています。RHELを運用していて、ABRTからのレポートメール「[abrt] full crash report」を受信したことがある方もいるかと思います。今回はRHEL7でのABRTについて見てみましょう。

ABRTとは何か?

RHELに含まれるソフトウェアに何かしらの問題があり、クラッシュしたとしましょう。
レッドハットのサポートへ相談をするときに何をするでしょうか? 問題の再現と情報収集ですね。

問題の解析をする際には、問題発生時にそのソフトウェアが何をしようとしていたか、どのような環境で動作していたか、前後のログはどうであったか、コマンドラインはどうなっていたか、ファイルやメモリをどう使用していたかなどの多数の情報が必要になります。再現して収集するのではなく、これらの情報を最初から収集することができれば、問題解析の初動が非常に早くできます。

ABRTは、ユーザがアプリケーションのクラッシュを発見し、報告する時に必要になる作業を自動化するための仕組みです。ABRTは各種の問題を検出するabrtdと、検出した問題に関連した情報を収集し報告するためのプログラム群でできています。

ABRTのおおまかな動作は以下のようになっています。

  1. 起動時にabrtdを起動。ログの監視や、各種クラッシュの検出設定を仕込む
  2. 問題が発生。abrtが問題を検出
  3. 検出した問題の関連情報をできるだけ収集してファイルに保存
  4. 管理者へのメール送信などで問題があったことを通知
  5. レポート送信

ABRTはどのような問題を検出するか?

問題にはいろいろな種類がありますが、現在ABRTが対応する問題は以下のものです。クラッシュなどが発生せず意図しない動作をするような場合には対応できません。

  • C/C++, Python, Ruby, Java で作成されたプログラムのクラッシュ
  • linux kernel が"OOPS"メッセージを出力した場合
  • linux kernel がクラッシュしkdumpを出力した場合
  • Xサーバがクラッシュした場合

問題時の情報収集

ABRTが具体的にどのような情報を収集するかは、対応する問題によっても変わりますが、典型的には問題が発見されたプロセスがどのような状態であったかが収集されます。

収集した情報は/var/spool/abrt以下に保存されます。abrt-cliコマンドでその一覧を見ることができます。

# abrt-cli list
id cb36e53c4f8d61a7b93520735df0448349ee8936
reason:         systemd-logind killed by SIGABRT
time:           Tue 24 May 2016 10:43:23 AM JST
cmdline:        /usr/lib/systemd/systemd-logind
package:        systemd-219-19.el7_2.9
uid:            0 (root)
count:          2
Directory:      /var/spool/abrt/ccpp-2016-05-24-10:43:23-679
Run 'abrt-cli report /var/spool/abrt/ccpp-2016-05-24-10:43:23-679' for creating a case in Red Hat Customer Portal



この中のDirectoryが対応するディレクトリで、この中に問題に関連する情報が含まれています。

# ls /var/spool/abrt/ccpp-2016-05-24-10 
abrt_version    dso_list     machineid   pkg_name           type
analyzer    environ         maps         pkg_release       uid
architecture    event_log     open_fds    pkg_version       ureports_counter
cgroup        executable     os_info     proc_pid_status   username
cmdline        global_pid     os_release  pwd           uuid
component    hostname     package     reason           var_log_messages
core_backtrace    kernel         pid         runlevel
coredump    last_occurrence  pkg_arch    sosreport.tar.xz
count        limits         pkg_epoch   time


これらの定義については以下のナレッジベースに記載があります。
https://access.redhat.com/articles/2134281

収集した情報をレポート送信

ABRTではレポート送信がlibreportとしてモジュール化されており、レッドハットのカスタマーサポートに送信する他にもメールでの送信やbugzillaへ送信するなどいくつかの処理ができるようになっています。冒頭の「[abrt] full crash report」というメールはABRTがrootユーザ宛にこのレポートを送信したメールです。

RHELのデフォルトでは以下のコマンドにより、レッドハットのカスタマーサポートへレポートを送信できます。このふるまいは /etc/libreport/report_event.conf の設定により変更できます。

# abrt-cli report /var/spool/abrt/ccpp-2016-05-24-10:43:23-679

上記のようにコマンド入力すると、カスタマーポータルヘ接続可能であればアカウント情報を求められたのち、viでレポート入力をおこなってその場でレポートを送信できます。

ABRTの注意点

以上のようにABRTは問題解析を手助けしてくれる強力なツールなのですが、自分でプログラムを開発している場合はABRTの仕組みが邪魔になってしまうことがあります。たとえば同じ問題が繰り返し発生することを想定して、ABRTでは同じプログラムの同じような問題が繰り返されていれば一旦保存したダンプを削除しますが、開発中はこのような動作は望ましくありません。

このような場合には  /etc/abrt/abrt-action-save-package-data.conf でABRTの対象外となるパッケージや、ディレクトリ名を指定することで通常のパッケージについてはABRTを利用しつつ自分の作業についてはABRTを使わないような工夫ができるようになっています。

関連ドキュメント

Red Hat Enterprise Linux 7 システム管理者のガイド 「第20章 自動バグ報告ツール (ABRT)」 https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/ch-abrt.html

お問い合わせ

問い合わせボタン

RHEL サポート

最近の更新
Red Hat Satellite 6でerrataを適用してみる 2016年11月28日
VMware環境上でのRed Hat Enterprise Linux 7.2以前から7.3へアップデート時の注意点と、その解説 2016年11月24日
RHEL4の延長サポートおよびRHEL5の通常サポート終了 2016年10月17日
Red Hat Enterprise Linuxの互換性維持 2016年08月31日
RED HAT FORUM 2016 Tokyo The power of participation -アイデアとテクノロジーが生むオープンイノベーションの破壊力- 2016年08月12日
Red Hat Network ClassicからRed Hat Subscription Managementへ移行のおねがい 2016年07月27日
ABRTで障害時の情報収集とレポートを自動化しよう 2016年06月03日
Red Hat Enterprise Linux 7、使ってますか? 2016年04月27日
Red Hat Developer Programに参加して開発者用サブスクリプションを入手しよう 2016年04月01日
Relax and Recoverでのシステム回復 2016年03月08日
Red Hat Insightsとは 2015年11月13日
Red Hat Enterprise Linuxを仮想化環境で動作させる時の注意点 2015年10月05日
RHEL7でpingをreniceしようとすると失敗する話 2015年08月31日
Red Hat Satellite使いはじめガイド 2015年08月20日
ELS? EUS? RHELの延長サポート製品について知ろう 2015年08月13日
Performance Co-Pilotでパフォーマンス測定を簡単にしよう 2015年08月06日
Red Hat Enterprise Linuxでの独自コンテナイメージの作成 2015年07月29日
RHELセキュリティ情報の入手と対応 2015年07月23日
systemd-journaldを活用しよう 2015年07月16日
Red Hatテクニカルサポートのつかいかた 2015年07月09日