こんにちは。株式会社パイプラインの濱田です。前回より日常の業務から"変化を感じる"にスポットを当て、異常検知について取り上げています。今回はその後編になります。

何かおかしいぞ？を気付けるか

インフラ運用担当にアサインされて最初に、Zabbixなどの監視ツールでグラフを見ることからはじめる方も多いかと思います。また、アラートメールを受信してから対応フローに則って障害対応を行うこともあるでしょう。

前回は監視グラフのスパイク検知からどう対応するかについて取り上げました。今回は、別の角度からグラフの変化を感じ取るにはどのような読み取り方をするべきか、について掘り下げてみたいと思います。

規則性の有無に気をつけよう

もし何らかの異常に規則性がある場合、cron処理で起動されたバッチが負荷を上げていることもあります。もちろん、複数のコマンドが同時に走り出すことそのものがいけないわけではなく、それによってサービスレベルが低下し、本来の価値が提供できないことが問題なのです。

しかし、これは1つのグラフを見ただけではわからず、実際にプログラムを走らせてみるのがよいでしょう。

crontab -l

を実行していつcron実行が行われたか、を確認してもよいのですが、自分のUNIXアカウントで実行予定の分しかわかりません。ユーザーの数だけcrontabコマンドを実行するのも悪くないですが、 /var/log/cron を確認するのがオススメです。

また、同時実行そのものがいけないのは先に申し上げた通りですが、実際にcron実行されるプログラムそのものの処理時間を計測するのがもっとも効果的です。もし手動実行を何度行ってもよいのでしたら、timeコマンドをつけて実行してみることをおすすめします。

規則性の有無に気をつけよう

もし何らかの異常に規則性がある場合、cron処理で起動されたバッチが負荷を上げていることもあります。もちろん、複数のコマンドが同時に走り出すことそのものがいけないわけではなく、それによってサービスレベルが低下し、本来の価値が提供できないことが問題なのです。

しかし、これは1つのグラフを見ただけではわからず、実際にプログラムを走らせてみるのがよいでしょう。

crontab -l

を実行していつcron実行が行われたか、を確認してもよいのですが、自分のUNIXアカウントで実行予定の分しかわかりません。ユーザーの数だけcrontabコマンドを実行するのも悪くないですが、 /var/log/cron を確認するのがオススメです。

また、同時実行そのものがいけないのは先に申し上げた通りですが、実際にcron実行されるプログラムそのものの処理時間を計測するのがもっとも効果的です。もし手動実行を何度行ってもよいのでしたら、timeコマンドをつけて実行してみることをおすすめします。

プログラムのロジックに問題がない、あるいはどうしてもある程度のCPU時間を専有してしまう場合、cron実行の時間帯を変えることも検討しましょう。前述のようにtimeコマンドをつけてプログラムを実行してみて、あるプログラムの処理に1分かかるとしたら、cron実行を1分以上前後させる、といったように、です。

もう1点、負荷上昇時に自ホストのcron登録がない場合、他ホストから同時に大量の接続が行われていることも可能性として排除できません。日ごろより、どのホストと通信が行われているのか、それがどのようなものかについて理解しておくことも重要になります。

監視しきい値は底も見よう

監視しきい値を超えていた、という状況は障害検知の観点ではすごく判りやすい指標になります。しかし、監視しきい値の妥当性については正解があるわけではなく、日々の運用で見直していくのもよいでしょう。

しかし、下記のようなグラフがあったとします。

恒常的に負荷がかかっているサーバーでこうした突然の負荷低下が生じた場合、あるいはグラフ描画が欠損している場合など、グラフに底が生じているときこそ要注意です。平日日中にアクセスの多いサイトで休日にアクセス数が下がる、というようなケースならまだしも、「この時間帯にアクセスが少ないのはおかしい」というケースもあり得る話で、大抵は

• 何らかの障害がおきていたため、アクセス数が下がっていた
• 監視サービス異常により、正しくグラフが取得できなかった

に収斂されます。このように、ピークとは真逆の底を見つけたときに「おかしいぞ？」と疑う姿勢を持つことで、より付加価値の高いエンジニアとして評価されるでしょう。

今回のまとめ

IT業界の登竜門としてサーバー・ネットワーク監視からアサインされることはよくあります。同じ監視エンジニアでも、以下のポイントを意識することでより付加価値の高い仕事を任せてもらえるようになります。

• 規則性の有無にも気を配ろう
  • 同じ曜日、同じ日付で負荷が高くなるときはcron実行されたコマンドによる負荷を疑おう
  • cron処理が重たい場合、プログラムのロジックを見直すほか、可能であればcron起動時刻を前後させることも検討に値する
• ピーク突出以外も気をつけよう
  • 監視しきい値はピークだけにあらず
  • グラフの底も気をつけよう

運用監視を行うにあたり、もっともやってはいけないアンチパターンは「自分で抱え込んでしまう」ことです。狼少年と呼ばれても、何かに気づいたらアラートをあげる習慣を身に着けてください。また、「自分で抱え込んでしまう」には「怒られたらどうしよう」という恐怖のほかに「このくらい放置してもいいだろう」という感覚の麻痺も含まれます。動機は何であれ、自分で抱え込んでしまうことだけは絶対にやめましょう。

まずはエンジニアデビューしたい、という方は、3 ヶ月間学びながらお給料が貰える AltX キャリテク！の門を叩いてみてはいかがでしょう。 https://www.kcct.co.jp/careetec/