手順書レビュー
どうも。
kiekunです。
今日はこれまでに構築しながら作成したZabbixの手順書のレビューを行いました。
今回は演習２なのですが、前回の演習１の時に担当した手順書はほんの一部で、レビューの際にもそんなに思入れもなかったですね。。
でも今回は結構悪戦苦闘しながら作業して作ったので、ここはこんな工夫をしましたー的な話もできて良かったなーと感じました。
演習２では「Zabbixチーム」「Alfresco構築チーム」「AlfrescoWebインターフェース設定チーム」といった感じで３チームに分かれての作業でした。
なので他のチームはZabbixについては触れていなかったので、工夫した点を説明する際には自分の中で言葉をまとめて、しっかり伝わるように話そうと心がけました。
学んだことをアウトプットする機会はまだそれほどないのでいい機会になりました。
そういった意味ではこのブログもどんどん活用して、学んだことを整理するという意味でもアウトプットしていけたらなーと感じます。
今日はこんなところで。
おやすみなさい。
Kali Linuxの存在を知った
どうも。
kiekunです。
最近研修の一環として、「調べたことをアウトプットしてみよう」的な流れになり、その際に日経NETWORKの「公開サーバの守りかた」という本を渡されました。
つまり、この本の中からおもしろいネタを見つけてアウトプットしようといった感じ。
土日で少しパラパラと読んでいると興味を惹かれるものがありました。
守るにはまず攻撃方法を知ること
その言葉からまず考えたのが、攻撃について調べるという事でした。
しかし、そこに書いてあったのは
敢えて防御力を弱めて攻撃させて、その攻撃方法を盗み見る
といった方法でした。
この方法には「おおーー！」と感心してしまいました。
また、攻撃手法の習得方法として用いられるものの一つに
攻撃用サーバとやられるサーバを構築して実際に攻撃してみる
という方法があることがわかりました。
この攻撃用サーバが「Kali Linux」というものです。
これを構築すると、攻撃のパターンが入っているらしくそこから実際に攻撃を仕掛けることで学習できるみたいです。
しかし、実際に動いているサーバなどに攻撃するのは違法なので、閉鎖したサーバを作ってその中で練習するのがいいみたいです。
最近思うのが、監視を学ぶことは監視のみならず様々なことの流れや繋がりも把握できる気がするということです。
そのため、初心者ながら監視という必要不可欠なツールを勉強していくことで知識を広げていきたいなと思いました。
今日はKali Linuxのさわりの部分しか調べられませんでしたが、時間があるときに実際に練習できる環境を作って、身に着けていきたいと思いました。
今日はこんなところで。
では。
Zabbixエラー対応
どうも。
kiekunです。
今日は昨日立ちはだかったエラーを解決することに取り組んでいました。
昨日のエラー内容は...
Tomcatが落ちてしまったときに自動で再起動してくれるというアクションの結果の不一致です。
ポート監視のグラフではきちんと再起動している。
しかし、障害のところのリモートコマンドのステータスは失敗になっている。
どういうことだ....!
というものでした。
昨日行き着いた仮説は/etc/zabbix/zabbix_agent.confのTimeoutという設定項目。
これを長くすることにより、Zabbixさんがリスタートの処理が終わるまで待ってくれると思っていました。
しかし。
MAX３０秒にしても一向に改善されませんでした。
色々考えた結果ある考えにたどり着きました。
zabbix_server.conf側にも似たような設定があるのでは..... と
見てみると
### Option: Timeout
# Specifies how long we wait for agent, SNMP device or external check (in seconds).
#
# Mandatory: no
# Range: 1-30
# Default:
# Timeout=3
あったー！
しかもwait for agentって書いてあるではないか。
これは来たと嬉しくなりました。
このTimeout項目を15秒にしてみたところ、問題は無事解決されました。
問題の解決ができた際にはとても達成感がありました。
こういったエラーが出た際にもめげずに立ち向かって経験値をためてレベルアップしていきたいなと感じた１日となりました。
今日はこんなところで。
では。
Zabbixテスト
どうも。
kiekunです。
今日は研修の一環としてこれまで構築した内容の手順書作成と、一通りのテストを行いました。今回Zabbixで監視する対象はAlfrescoと呼ばれるアプリケーションです。
このアプリ....便利なんです。
でもこのアプリ.....厄介なんです。。
このAlfrescoというアプリにはTomcatが組み込まれているので、監視する時にはTomcatを見ることになります。
新米としてはTomcatはどうやって監視するのだろうと色々調べてみるわけです。
そうすると色々出てきました。
なるほどーそうやってやるのかー。よしやってみよう！となって取り掛かろうとすると調べて分かったいじくるであろうファイルなどが見当たらないんです。
そう。Alfrescoに組み込まれてしまっているから。
Tomcat単体じゃないことによって全然上手くいかなくて苦労しました。
苦労の末なんやかんや手順書まで辿り着き、テストまで漕ぎ着けたわけです。
一通りの手順を終えて監視状態を見てみました。
するとシナリオの部分で「失敗」の文字が。
ガーーーン。
どこで失敗しているのか調べてみました。
するとどうやらTomucatが落ちてしまった時用の自動再起動が上手くいっていないらしい。
しかしここで新たな謎が浮上したんです。
それはTomcatのポート監視のグラフを見たことによる謎。
そこで見たものはポートが停止した後すぐに起動するグラフの動き。
グラフでは再起動している。
しかしシナリオだと失敗している。
ん？？？
ってなりました。
そこから再度調査してある可能性が見つかりました。
それは/etc/zabbix/zabbix_agentd.confという設定ファイルの
#Timeout=3 この項目
どうやらZabbixさんがエージェントさんに再起動の指示を飛ばしてから結果が出るまで待ってくれる時間の設定っぽいことがわかりました。
３秒間待ってやる。
何かのセリフに似ている。。
つまり３秒以内には再起動できずシナリオのところに失敗の文字が出てしまったけれどそこからエージェントさんが仕事を続けたおかげで再起動してグラフ上には現れたのではないかと推測しました。
実際どうなのかは今日検証できなかったので明日やってみようと思います。
今日はこんなところで。
では。
同期旅立ち。
どうも。
kiekunです。
１日のうちに２度投稿。
書きたいものがある時は書いていこう。
さて、この記事の本題ですが明日から同期の一人がアサイン先の現場での仕事をスタートするという事で一緒に研修を受けられるのも最後でした。
この同期は同期の中で一番初めに会った人であり、一番初めに話した人でした。
歳も同じだったのですぐ仲良くなりましたね。
未経験入社で同じスタートラインでしたが、彼はどんどん新しいことを吸収していって自分も負けてられないなーと日々刺激をもらっていました。
それはこれからも続いていくとは思いますが。
自分も色々なことを学び、吸収し、エンジニアとしてガシガシ成長していきたいと強く思った日になりました。
頑張れ同期。
頑張れ自分。
こんなところで。
では。
ZabbixのWeb監視アラート
どうも。
kiekunです。
今年の１月に転職して新しい会社で働いています。
そんな私は今社内研修にてインフラエンジニアとしての基礎知識を身につけるべく頑張っています。
最近取り扱っている内容はZabbixを用いた監視です。
そんな中、今日覚えたことを備忘録として書いてみたいと思います。
まずWeb監視でない監視から・・・
前に習った内容としては監視対象サーバのCPU稼働率などを見ていました。
その際には「アイテムキー」と呼ばれるものの中からCPUの稼働率の情報を得られるものを選択します。
次に「トリガー」と呼ばれるものを設定して、監視する上でこれ以上いったらマズイなーっていうラインを決めます。
そこから「アクション」を設定して、トリガーで設定した条件を超えた時にメールを飛ばしたりすることができるようになります。
簡単ではありますがこれが一通りな内容かなーと思います。
次に今回のテーマのWeb監視について。
Web監視をするにあたって設定するのは「シナリオ」。
新キャラです。。
シナリオとは何かと言うと、Zabbixに監視したい手順を記憶させて、Web上にて実行させてそれを監視するというもの。
今回引っかかったのは「アイテムキー」「トリガー」の選択をしていないということ。
つまりは「アクション」とどうやって紐づけるんだろうとなりました。
結論としてはシナリオを作成した時点で自動的にアイテムが追加されていました。
「Failed step of scenario...」というアイテムが。。
そうだったのかってなりました。
ここからはこれまでと一緒で、「トリガー」と「アクション」の設定をする事でシナリオで異常が発生してしまった際などにメールを飛ばしたりできるようになります。
本日はこんなところで。
では。
