障害発生時に抑えておきたい基礎知識

障害発生時に抑えておきたい基礎知識Linuxサーバ編

@laugh_k

NODE-Setagaya#0 2013.04

Profile

• 名前

Kei Iwasaki

• Twitter

@laugh_k

• 職業

MSP(監視運用代行)の会社で

サーバ・ネットワークエンジニア的なもの

3月某日のこと

参加してきました！

そして痛感しました...

自分のホーム以外の環境だと思ったように対応できないと。

しかもこの

「トラしゅ」

は6月にもう一度開催予定とのことで色々おさらい＆予習をしておきたい！

障害発生時の基本確認編


誰がログインしているか？していたか？

作業影響によるものなのか？

ログインしているユーザーを確認

# w

これまでログインしていたユーザー＆リブートがあったかどうかを確認

# last

# w

# last


以前にどういう作業が行われたか？

特にrootユーザーでやると効果絶大

# history

※ただし、Ubuntuサーバのような

rootユーザー以外がsudoで管理するようなOSだと

root以外のユーザーでもやったほうがいいかも

# history


聞き耳を立てているポート・プロセスはないか？

※プロセスの情報もセットで追いかける場合は

rootで実行する。

# netstat -nplt# netstat -nplu# netstat -nplx


CPU、MEMなどのシステムリソースは

どうなっているか？

Mem

# free -m

Load Average(CPU)

# uptime

# free -m

# uptime


CPU、MEMなどのシステムリソースは

どうなっているか？

入っていたら

# sar -A

現状のプロセスと照らし合わせながら

# top

※topは表示中にfを押すと詳細な表示オプションが

選択できる！

# sar -A

# top


何かシステムがエラーを吐いていないか？

システムログの確認

※ /etc/rsyslog.conf,/etc/syslog.confを確認すると

他にもどこかに吐かれていることがわかる！

# dmesg# less /var/log/messages# less /var/log/syslog# less /var/log/secure# less /var/log/auth


何かバッチ処理が動いていないか？

Cronの確認

※ cronは管理者によって書き方が色々なので注意！

# ls /var/spool/cron/crontab/*# cat /etc/crontab# ls /etc/cron*

## /etc/cron* のファイルを全部表示# find /etc/cron* -type f -exec cat '{}' \;


何かバッチ処理が動いていないか？

atコマンドジョブの確認

# atq

# at -c [ジョブ番号]

# atq | awk '{print $1}' | xargs at -c

※ 「トラしゅ」ではこいつに苦しめられましたね。。

# atq# at -c [ジョブ番号]

## 一行で確認# atq | awk '{print $1}' | xargs at -c


ミドルウェアは何が入っている？

必ずしもyumやaptで行儀よく入っているとは

限らない

※ ソースコンパイルでインストールする際は

/usr/local/[ミドルウェア名]

に突っ込むことが多い。というかほぼ暗黙の了解。

また、モノによっては /opt配下も好まれる場合もあり

# ls /usr/local# ls /opt


ミドルウェアのログを見よう！

単純にエラーを探すだけでなく、

タイムスタンプが不自然に切れていないかなども重要

Apacheだと大体はこんな感じ

※vimが入っている場合はハイライトが効いて

見やすくなることもある。

## yumやaptなどの場合# less /var/log/apache2/access.log

## ソースコンパイルの場合# less /usr/local/apache2/logs/access.log


自動起動しているプロセスはあってる？

意図しているもの

今起動しているもの

※ちゃんと意図したとおりに動いているのか確認

# chkconfig –list# cat /etc/rc.local# ls /etc/rc{1..5}.d/

# ps auxwww# pstree -p


さてここまではコマンドを使ってサーバの情報の探り方を中心に見てきましたが、


NagiosZabbix


MuninCacti


このような監視に特化したツールを予め導入しておくと楽です。

というより台数増えると使わないと無理です。

障害発生時、技術以外に気をつけなきゃいけないこと

技術以外に気をつけなきゃいけないこと

障害の着地地点の確保として

以下のことを確認しておかないと

判断に迷いが生じてよろしくないです。

• 最終的な意思決定は誰が行うか

• 意思決定者へは何を使ってどこに連絡をするか

判断に迷った時は誰に相談？電話？メール？IRC？アドレスは？番号は？チャンネルは？


システム障害の発生時のHowToのようなものを

見ているとついつい

「技術的にどこが問題だったのか？」

という視点に陥りがちです。

確かにそれは最終的に対応しなければならないです。


けど、障害対応というのは

「問題が発生しているサービスをどうするか」

という事であって

「技術的に原因を取り除かなければならない」

とは限りません。


1秒でもダウンタイムを減らせるなら

コンソールに張り続けてApacheやMySQLの再起動を手動で何度も続けたほうが

サービス提供者にとってもサービスユーザーにとってもいい結果になることだってあります。

それは立派な障害対応です。


「障害対応」はサービス提供者側が受けるダメージを

最小限に食い止めることであると思っています。

そのためにはまず、

サービス提供者への状況報告・相談・提案を行い、

目の前で発生している問題を解決することが

最優先です。


技術的にその場で根本対応ができてしまうのは

それはそれで本当にすごいことなのですが、

もしかしたらそれはサービス提供者が望んでいない方針かもしれません。

サービス提供者に余計なコストを発生させることにつながるかもしれません。


「障害対応」は一種の問題解決です。

そのために必要な

技術力。提案力。報告力などなど。。

必要なスキルを必要な場所で使い分けることが

対応者もサービス提供者もハッピーになれる対応への一歩ではないかと思います。

障害発生時に抑えておきたい基礎知識

Documents

Transcript of 障害発生時に抑えておきたい基礎知識