狠狠撸

狠狠撸Share a Scribd company logo
障害発生时に抑えておきたい基础知识
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
障害発生时の基本确认编
Munin
Cacti
障害発生时の基本确认编
このような監視に特化したツールを
予め導入しておくと楽です。
というより台数増えると使わないと無理です。
障害発生時、技術以外に
気をつけなきゃいけないこと
技術以外に気をつけなきゃいけないこと
障害の着地地点の確保として
以下のことを確認しておかないと
判断に迷いが生じてよろしくないです。
? 最終的な意思決定は誰が行うか
? 意思決定者へは何を使ってどこに連絡をするか
判断に迷った時は誰に相談?
電話?メール?IRC?
アドレスは?番号は?チャンネルは?
技術以外に気をつけなきゃいけないこと
システム障害の発生時のHowToのようなものを
見ているとついつい
「技術的にどこが問題だったのか?」
という視点に陥りがちです。
確かにそれは最終的に対応しなければならないです。
技術以外に気をつけなきゃいけないこと
けど、障害対応というのは
「問題が発生しているサービスをどうするか」
という事であって
「技術的に原因を取り除かなければならない」
とは限りません。
技術以外に気をつけなきゃいけないこと
1秒でもダウンタイムを減らせるなら
コンソールに張り続けてApacheやMySQLの再起動を手
動で何度も続けたほうが
サービス提供者にとってもサービスユーザーにとって
もいい結果になることだってあります。
それは立派な障害対応です。
技術以外に気をつけなきゃいけないこと
「障害対応」はサービス提供者側が受けるダメージを
最小限に食い止めることであると思っています。
そのためにはまず、
サービス提供者への状況報告?相談?提案を行い、
目の前で発生している問題を解決することが
最優先です。
技術以外に気をつけなきゃいけないこと
技術的にその場で根本対応ができてしまうのは
それはそれで本当にすごいことなのですが、
もしかしたらそれはサービス提供者が望んでいない方
針かもしれません。
サービス提供者に余計なコストを発生させることにつ
ながるかもしれません。
技術以外に気をつけなきゃいけないこと
「障害対応」は一種の問題解決です。
そのために必要な
技術力。提案力。報告力などなど。。
必要なスキルを必要な場所で使い分けることが
対応者もサービス提供者もハッピーになれる対応への
一歩ではないかと思います。

More Related Content

障害発生时に抑えておきたい基础知识