システム監視について

こんばんは、カズヤんです。

今日は、ドライアイのため、7時間睡眠でもかなり眠かったですが、何とか乗り越えました。

 

今回は、Basis運用管理者としてはマストとなるシステムの監視について書いてみます。

正直、私も習っている最中ではありますが、最近少しずつわかってきたところなので、共有します。正直こういうのって、僕のブログよりわかりやすい記事なんて山ほどあるわけだけど、新人SEのためアウトプットしているので、ご了承ください。

わけわかんなかったら下のサイトとかみてくださいw

thinkit.co.jp

ちなみにSAP Basis経験者の方が、BPR案件に携わるとなると運用設計、とりわけこの監視設計のスキルが重要視されるそうです。システム監視をしっかり理解して設計とかしてみたいっすね!!

 

1、システム監視とは?

システム監視とは、システム運用段階にて、稼働中のシステムが停止せず正常なパフォーマンスを維持するために行う、運用の活動です。システム監視を行うことで、システムの可用性やサービス継続性を担保します。

システムを継続的に監視することにより、お客様の本番環境にて障害(エラー)が起きた際に、すぐに運用管理者の元に連絡が来るようになっており、その連絡を受け私たちがエラー内容を調査してシステム影響を判断したりして対応します。

多くのシステム監視では、自前のデータセンターにて、お客様のサーバを監視しています。私の場合は、お客様のSAPシステムを物理レベル、ネットワークレベル、OSレベルで監視しています。次に監視の種類を説明しますので、そこで、イメージを持っていただけたらと思います。

 

2、監視の種類

監視には、たくさんの種類がありますが、私がSAP Basis運用管理者として触れるものでは、下記が挙げられます。

 

Ping 監視

シスログ監視

・ワークプロセス監視

・リソース監視

・ジョブ監視

・表領域監視 

などです。(これら以外にもURL監視とか聞いたことあります)

 

Ping 監視とは、各ネットワークノードに対して、電気信号を送りつながれば、ノードが停止していないことを確かめるための監視です。もし、ノードが停止していると、ハードの上のOSも停止てしているため、システムは完全に停止していることを表し、死活監視と呼ばれることもあります。おそらく、一番短い間隔で行われている監視だとおもいます。

シスログ監視は、システムにとって何か重要な変更やエラーが出力された際に、システムログに書き込まれる内容を検知し、アラートにて知らせてくれる監視です。SAPの場合は、SM21のシスログのOS上での監視や、Oracleのアラートログ、DB2ならDiaglogなどが該当します。私は、一番馴染みがあります。

ワークプロセス監視は、プログラムを実行する際には、各プログラムを構成するジョブはワークプロセス(通称、プロセス)上にて実行されます。このワークプロセスに異常があるとアラートで知らせてくれるものです。

リソース監視は、ディスク監視が一般的であり、コンピュータの物理リソースの監視を行います。ディスク監視の場合は、閾値を設け、閾値以上の値が登録された場合に、アラートがなる設定がされています。

ジョブ監視は、SAPの場合はデータセンターではなく、運用管理者の定常業務で行います。ジョブとは、プログラムを構成する小さな単位です。SAPでは、SM37を実行し、ジョブの情報を参照することができます。ちなみにSM37で参照可能な古いジョブはハウスキーピングジョブの設定により異なるため、自分のシステムのハウスキーピングジョブの設定をしっかり把握する必要があります。

最後に、表領域監視ですが、これはOracleDB2などのデータベースの表領域を監視するものです。表領域はその中に表(つまり、テーブル)データを含み、テーブルデータはアプリでどんどんデータを流すと蓄積されるため大きくなります。これも、データセンター側ではなく、運用管理者の定常業務の中で実施し、設けた閾値よりも値が上回る場合に、報告するよう業務設計されています。

 

3、現場における監視の役割

監視に関しては、精緻な設計が行われ、厳密な運用が要求されますが、実際に業務を行う中で監視の設計が不適切なものなどは設定を変えたりということは十分にありえます。もちろんその場合も、運用管理フレームワークITILで言うところの、変更管理を回して、構成情報を変更する必要があるので、面倒なところではありますが、とても管理が行き届いています。

私が、チームに配属されてから、監視の漏れからお客様システムが停止し、業務影響がでると言う局面はなかったですが、監視をしていてもエラーの具合によっては、復旧が難しいものはもちろんあります。

そして、そもそも、システムがただ動いているだけなのに、業務にとってクリティカルなエラーが起きる仕組みがいまいちよく分からないと言う人もいると思います。

実は、インシデント(障害、エラー)が発生する主な原因は、開発者やシステム運用者の変更作業がトリガーになることが多いです。特に、多いのが開発者ですが...

システムに何か変更が加わることにより、システムの変更が代わり不具合をだす。さらには、OSのアップデートにより、システムのバージョン不整合が起き、不具合を出す。さらには、システムのプログラムエラーによる不具合などです。インシデントを発生させる要素というものは、実は限りなく存在しており、システムは常に脅威にさらされています。

 

4、最後に

最近になって、SAP Basisにおける変更作業を多く任せてもらっているため、システムの監視設定に関しても頻繁に考えることがあります。運用管理者の立場では、設計された既存のシステム監視設定の中で業務を行うため、あまり面白みがないですが、構築の部隊に行く機会があって、この運用設計に携われたらすごく楽しいだろうなと胸が躍ります。

SAPに限らず、運用管理者の方は多くいると思うので、こういった監視設計の話などができたら嬉しい今日この頃です。

つらつらと話しが長くなりましたが、今日はここまでにしたいと思います。

では、明日以降も頑張りましょう。

にほんブログ村 IT技術ブログ IT技術メモへ
にほんブログ村