Zenn
👻

運用監視時代に対応した監視不具合アラートの削減とは？

2021/11/06に公開
Linux
運用監視
運用改善
idea

はじめに

僕が運用監視オペレーター時代に対応していた監視不具合アラートの削減について、どんなことをしたのかざっくばらんにまとめました。

※注意
4年程前の内容のため、思い出しながら記載しています。
曖昧な点がありますが、ご了承下さい。

今回のトピック

  • 監視不具合アラートとは？
  • 使用していた監視ソフトウェア
  • 今回対応した結果
  • 監視不具合アラートを削減するまでのプロセス
  • 所感

監視不具合アラートとは？

監視不具合アラートとは、「監視対象サーバ自体は正常であるにも関わらず、異常が発生している旨検知されるアラート」になります。

具体的なアラートは以下になります。

  • 「Ping疎通不可」という旨のアラートが検知されるが、実際は監視対象サーバにPing疎通可能
  • 「CPU使用率が取得できませんでした。」「メモリ使用率が取得できませんでした。」という旨のアラートが検知されるが、実機で確認コマンドを実行した場合に取得可能

他にも監視不具合アラートには種類がありましたが、「～の情報が取得できませんでした。」と表示されるにも関わらず、実際は取得できるものばかりでした。

使用していた監視ソフトウェア

使用していた監視ソフトウェアはエージェントレス方式で監視が可能なソフトウェアになります。

当時の監視対象サーバはRHEL/CentOS等Linux中心になります。

※申し訳御座いません。監視ソフトウェアの製品名は差し控えます。



このように、定期的にサーバにSSH(or Telnet)接続してLinuxの確認コマンドを叩きに行くような形になります。

例えば、このようなコマンドを定期的にLinuxサーバに接続して叩きに行く形です。

実行例
[root@testlinux01 ~]# w
 21:04:01 up 0 min,  1 user,  load average: 0.70, 0.26, 0.09
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
root     pts/0    192.168.2.3      21:04    1.00s  0.00s  0.00s w
[root@testlinux01 ~]#

(rootですいません。これはテストサーバです。)

根本的な監視不具合アラートの原因について

常駐先で僕が在籍していた期間中ずっと話題になっていたのですが、こちらのエージェントレス方式の監視もしくは監視ソフトウェア自体の問題ということで話が落ち着いていました。
※問題管理としても管理されていました。

対策として監視ソフトウェアの変更が予定されておりました。
しかし、変更される前に僕が現場から退場する形になりました。

今回対応した結果

今回対応した結果は、以下になります。

改善前
月に監視不具合アラートが300件程検知

改善後
月に監視不具合アラートが100件程検知

まとめると、監視不具合アラートの件数を1/3にしたということになります。

※監視ソフトウェアの変更は影響度が大きいため、水際で何かできないか？ということが発端になります。

監視不具合アラート削減までの期間は1ヶ月程になります。

監視不具合アラートを削減する迄のプロセス

以下になります。

①監視不具合アラートの洗い出し
②監視設定変更の調整
③メンバーにタスクの割り当て/監視設定変更

では、掘り下げていきたいと思います。

①監視不具合アラートの洗い出し

直近1ヶ月で発生している監視不具合アラートの情報を洗い出し、Excelにまとめました。

具体的には、以下の情報を確認しました。

  • アラート名
  • サーバ名
  • 1ヶ月毎の件数

確認したところ、月に300件程監視不具合アラートが検知されておりました。

確認した上で変更可能な監視設定を洗い出しました。
※必要に応じて、他の監視メンバーや現場リーダーに相談しながら進めました。

②監視設定変更の調整

①監視不具合アラートの洗い出しにて洗い出したアラートを元に「どのような形で監視設定を変更するか」を考えました。

具体的には以下になります。

  • 監視間隔の変更
  • 監視除外
  • 監視閾値の変更

CPU/メモリ/ディスク等のリソース系のアラートやログアラートの誤検知が多かったため、それぞれのアラートに適応した監視設定変更を考えました。

その後に、考えた案を各システム担当者へ提案し、監視設定変更を実施しても問題ないか確認をしました。

システム担当者から監視設定変更の許可が下りたアラートに対して、監視設定変更対応を実施する流れになります。

③メンバーにタスクの割り当て/監視設定変更

洗い出したアラート数が多いため、監視メンバー間で相談し、監視設定変更のタスクを割り振りました。

具体的な順序としては、以下になります。

1.監視メンバーがそれぞれ調整済みのアラートに対して、監視設定変更対応を実施
2.対応完了したら、監視不具合アラートを洗い出したExcelの該当の部分に「○」を付ける

このような形で無事対応が完了しました。
その後に1ヶ月経過観察をしたところ、月の監視除外アラートの発生件数が100件程迄に削減できていることを確認しました。

所感

  • 調整を経験することができた
  • 進捗管理を経験することができた

調整を経験することができた

今回の経験を通して、各システム担当者や監視メンバーとの調整を経験することができました。

具体的な調整は以下になります。

  • 監視設定変更を実施して問題ないかシステム担当者へ確認
  • 監視メンバーへタスクの割り振り

特にシステム担当者へ提案する際には、緊張をした記憶があります。
理由としては、「しっかり意図が伝わるかどうか」という不安があったからです。
そのため、内容をまとめた上で提案するように心がけました。

当時、調整の経験がなかったため、将来のキャリアのために良い経験ができたと感じております。

進捗管理を経験することができた

今回の監視不具合アラートの削減対応によって、進捗管理を経験することができました。

具体的には、メンバーがどこまでアラートの監視設定対応を実施しているのか確認するという形になります。

意識したことは、

  • 監視設定変更対応の期限を設定する
  • Excelにて作成した管理表を分かりやすくする
    ※どの監視設定のどの部分を変更すべきか詳細に記載

になります。

リーダーや他の監視メンバーに相談しながら進めた形にはなりますが、進捗管理をしっかり実施したことによってアラートの削減に繋がったのかと思います。

振り返ると、進捗管理の経験も将来に活かせるものであるため、良い経験になったと痛感しております。

さいごに

今回は運用監視時代にどのような形で監視不具合アラートを削減してきたのかざっくばらんに書きました。

頭の中で思ったことをそのまま文章にしているため、分かりづらかったら申し訳ないです。

僕の中で大きな成果であるため、このような経験ができたことに関して感謝しかないです。

今後のキャリアでも調整や進捗管理を実施することがあると思いますので、活かせればと思います。

Discussion