• このエントリーをはてなブックマークに追加

linuxサーバのトラブルシューティング基礎

  • このエントリーをはてなブックマークに追加

linux
zaco muraです。

私はサーバエンジニアになって約5年ですが、その中で数え切れないトラブルがありました。下手な鉄砲数撃ちゃ当たるじゃないですが、回数を重ねてみればアホでも覚えるということで、ある程度はトラブルシューティングの方法はわかってきました。そこで今回、自分の経験則をまとめてみたいと思います。

スポンサーリンク
Sponsords Link

トラブルシューティングで大事なこと

自分が大事だと思うことは

・どんな場合でもまずログを見る
・切り分けは低いレイヤから行う
・考えてもわからないことはさっさと聞く(google含む)

です。

なんか聞いたことがありそうなことばかりですが、詳細を書いてきます。

20151007-004

どんな場合でもまずログを見る

当たり前ですが、意外とできないのがこれです。いろいろ調べて誰かに相談した結果、「ログにはなんか出てないの?」と聞かれてハッと気付く、みたいなことがよくあります。

言わずもがなですが、トラブルの一番詳細な情報はログにあります。何はなくともまずログを見ましょう。

ちなみに、確認しようにもどこにログがあるのかわからない場合もあると思いますが、linuxではある程度ログ出力先は決まっています。ログの場所がわからない場合は、まず

/var/log/”アプリケーション名” の辺りを調べてみましょう。
(例: /var/log/httpd/ や /var/log/maillog)

ここにログがない場合は、システムログ(/var/log/messages)も見てみましょう。それでもなければgoogle先生に質問です。

切り分けは低いレイヤから行う

ログを見て今起きている事象が把握できたら、次は原因の特定です。私が経験してきたトラブルの大半は設定ミスかネットワーク的な問題ですので、今回はネットワーク疎通の切り分けについてです。

例えば、システムからメールが送れないというトラブルがあって設定には問題が無いとします。この時に考えられるのは


①メールサーバにIP的につながっていない
②メールサーバのIPアドレスがわからない(名前解決できない)
③メール用のポートが閉じられている
④相手サーバでメール送信を拒否されている

といったところです。
この中で、まず切り分けるべきなのは①だと思います。①が問題である場合、②や③の原因にもなり、根本原因を見つけるのに時間がかかるからです。

考えてもわからないことはさっさと聞く(google含む)

エラーメッセージの意味など、考えてもあまりわからないことはさっさと聞く(or調べる)ほうが早く解決する、ということです。あくまで私の経験上ですが、エラーメッセージと根本原因が直結する場合は意外と少ないです。

先程の例で行くと、ネットワーク疎通ができない場合に


“ネットワーク疎通ができません”

という直球なエラーメッセージを出してくれることは少ないです。大抵の場合は

“名前解決できません”
とか “セッションが張れません”

のように、それによって起こされる別の事象についてのエラーが出ることが多いのです。
ということで、エラーメッセージを見つけたら、迷わずgoogleにコピー&ペーストしましょう(極論)

まとめ

ということでトラブルシューティングの基礎ということで書かせて頂きました。
スーパーエンジニアな人たちはエラーメッセージを手がかりにソースコードを読むとか、コアダンプからデバッグする、とかできると思います。
が、私のような半端エンジニアは自分のできることから頑張ることが重要なのかな、と書きながら思いました。

スポンサーリンク
Sponsords Link
  • このエントリーをはてなブックマークに追加

ZacoDesign

スポンサーリンク
Sponsords Link