運用管理ツール「Hinemos」によるサーバー死活監視 | OSDN Magazine
サーバーの運用環境において、トラブルがいつ発生するのかを予測することは難しい。そのため、サーバーやそのサーバー上で動作するソフトウェアに問題が発生した際に迅速にそれを知ることができるよう、ツールなどを使ってサーバーを監視するのが一般的だ。このようなツールの1つにNTTデータが開発するオープンソースの運用管理ツール「Hinemos」がある。今回はHinemos 4.0を使ってサーバーの死活監視を行う方法について解説する。 無料で利用できるオープンソースの運用管理ツール「Hinemos」 複数台のサーバーマシンを運用している場合、運用を容易にするためになんらかの監視ツールを使用することが一般的だ。監視ツールは一定の間隔でマシンの状態をチェックし、問題が発生していれば管理者にそれを通知する。これにより、管理者は迅速にトラブルの発生を知ることができる。 監視ツールにはシンプルなものから多機能なもの
「業務マニュアル」と「操作マニュアル」の違い - 設計者の発言
「ユーザマニュアル」という言い方があるが、業務システム開発の文脈でこの表現は使わないほうがいい。「ユーザマニュアルを作りなさい」では、「操作マニュアルを作りなさい」なのか「業務マニュアルを作りなさい」なのか判然としないからだ。いずれも重要な設計要素ではあるが、内容も目的も異なっている。 まず「操作マニュアル」とは、パネルやページの操作方法を説明したものだ。たとえば「パネルＡが表示されたなら、ボタンＢを押してください。するとデータが一覧されるので、一覧のいずれかを選択状態にしてエンターキーを押せば、続くパネルＣが表示されます」といった説明は「操作マニュアル」にありそうな記述だ。文章だけでなく、関連するスクリーンショットを伴うことが多い。 いっぽう「業務マニュアル」とは、文字通り「個々の業務の説明書」のことである。ここで言う「業務」とは、「受注登録業務」や「出荷指示業務」や「実棚報告業務」とい
ファーストサーバの手順の問題点 - きしだのHatena
えらいことなってますが。 正規手順と今回の現象の説明などを含めた中間報告が出されています。 http://support.fsv.jp/info/nw20120625_01.html ここで、正規手順で、途中でオペレーションミスがあったときに復旧できない状態になってしまう可能性があることがわかります。 具体的には「原因3：メンテナンス仕様」のこの部分。 脆弱性対策のメンテナンスに関しては対象サーバー群とそのサーバー群のバックアップ領域に対して同時に更新プログラムを適用する この時点でこの更新プログラムに不具合があった場合には、リストアできなくなることになるわけです。そして今回はそれがおきたようです。 より安全な手順であれば、バックアップ側にパッチをあてている間は正常系がバックアップのバックアップということになるはず*1ですが、どこにもバックアップがない状態になってしまったわけです。 手順１
トラブルをわざと発生させサーバ問題解決能力を鍛える「Trouble-Maker」 - GIGAZINE
ほとんどのシステム管理者が経験したことがあるはずの状況は「何か悪いことが起きていて、サーバがダウンしているが、しかし何が起きているのか分からない」というシチュエーション。サーバを管理するシステムアドミニストレーターなどの立場でいると何が大変かというと、実際の製品として動かしている実環境でこのような問題が発生した場合です。 そこで役に立つのがこのオープンソースソフト「Trouble-Maker」です。 Trouble-Maker http://trouble-maker.sourceforge.net/ システム管理者の仕事を簡単にするため、多くのツールが存在していますが、未知の状況を経験している場合になんとかしてくれるわけではありません。この一連のソフトウェア群「Trouble-Maker」は既存の便利なツールとは異なり、問題を解決するのではなく、むしろ問題を引き起こします。インストールし
第2回 mixi.jpを支える運用監視 | gihyo.jp
はじめに 株式会社ミクシィの小池知裕です。運用部でアプリ運用を担当しています。前回は年末年始や突発的な負荷に耐えられるシステムの改善について紹介しました。連載2回目となる今回は、mixi.jpを支える運用業務でどのようにシステムの監視と測定が行われているのか、紹介します。 監視／測定って？ まず、前号からのおさらいになってしまいますが、筆者の所属する部署の「アプリ運用グループ」は mixi.jpのミドルウェア層以上の運用／維持管理／改善をおもに担当しています。 そこでは、「システムが正常に稼働しているか」「サーバの（CPUやメモリ、トラフィックなど）どういうリソースがどのくらい使われているのか」などを把握しておくことが非常に重要になってきます。 mixiでの監視／測定には大きく分けると2つあります。 死活監視／サービス監視 リソース監視 これらはそれぞれにシステムを運用し、改善するため
公共機関ソーシャルメディアポータル » 国、地方公共団体等公共機関における民間ソーシャルメディアを活用した情報発信についての指針
報道発表 国、地方公共団体等公共機関における民間ソーシャルメディアを活用した情報発信についての指針 平成２３年４月５日 内閣官房 情報セキュリティセンター 情報通信技術（ＩＴ）担当室 総務省 経済産業省 近年、インターネット上のさまざまな民間ソーシャルメディアサービス（以下、「ソーシャルメディア」という。）の普及に伴い、国、地方公共団体等の公共機関において、情報発信等の強化のために、こうしたサービスを利用する事例が増えてきています。特に、平成２３年３月１１日の東日本大震災の発生以降、震災対応に関する情報の発信のため、多くの機関でソーシャルメディアが活用されています。 震災対応のような時々刻々と状況が変化する情報を迅速に国民に発信していくためには、Ｗｅｂサイトへの情報掲載とともに、ソーシャルメディアも積極的に併用していくことが望まれます。一方で、ソーシャルメディアサービスの利用に当たって
情報システム部門は計画停電にどう対処すべきか--ガートナーが緊急提言
東日本大震災の発生を受け、東京電力が計画停電を実施している。3月17日には海江田万里経済産業大臣が予測不能な大規模停電が発生するおそれがあるとして、一層の節電を呼びかけた。企業は今、計画停電への早急な対応を迫られているのだ。 リサーチ企業のガートナージャパンが3月18日、特別レポート「東日本大震災における情報システム部門の行動指針:計画停電にどう 対処するか」（PDF)と題するドキュメントを公開した。ガートナージャパンでセキュリティ分野のリサーチを統括する石橋正彦氏などがまとめた提言だ。 レポートでは、「情報システム部門は東日本大震災のような大規模災害で、ITインフラが設置されているデータセンター側とユーザー側（オフィスまたは在宅勤務）の2つの側面から、確実かつ漏れのない、常に最悪の状況を想定した行動指針を持つ必要がある」と提言している。 データセンター側では、自家発電装置を設置しているデ
災害にあったITシステムを操作しなければならない人が知るべきこと
東北地方太平洋沖地震が金曜日に発生し、被災された皆様には心よりお見舞い申し上げます。 そんな中でも、この月曜日から多くのIT関係者が被災したかもしれないITシステムの復旧に取りかかるのではないかと思います。そうした方々に役に立つ記事を届けられないだろうかと、ユニアデックスの高橋優亮氏に相談したところ、大いなるご賛同をいただき有志の方々とノウハウをまとめたこの文書「災害にあったITシステムを操作しなければならない人が知るべきこと v0.2」を作り上げていただきました。 本文書の主眼は被災したITシステムを復旧させようとする方々に向けた情報提供ですが、システムに電源を入れる前の注意事項、電源投入順序の考え方などの説明は、これから関東地方で計画されている停電が起きたあとのシステム再起動の際などにも参考になると思います。 本文書はどなたにでも活用していただけるようにGNU Free Documen
顧客のサーバにパッチを適用する際のベストプラクティス
文：Erik Eckel（Special to TechRepublic） 翻訳校正：村上雅章・野崎裕子 2010-10-19 08:00 数多くのITコンサルタントが、月々の保守契約の一環として、顧客の所有しているサーバに対する適切なパッチの適用を保証するというサービスパッケージを提供している。またITコンサルタントによっては、パッチやアップデートの適用を通じてOSを最新の状態に保ち続けるという責任を負っている場合もある。いずれの場合でも、AppleやLinux、Microsoftから提供されるセキュリティパッチやパフォーマンスアップデート、その他の修正モジュールのダウンロードやインストールを定期的に行うことは、大した作業ではないと考えてしまいがちである。しかし、OSに対する誤ったアップデートをまずいタイミングで適用してしまうと、顧客の業務に大きな影響が及ぼされるというのは、経験豊富な技
うまく職場を抜け出すために--ネットワーク管理者が休暇前にやっておくべき7つの作業
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 夏がやってきた。もちろん公式にはまだだが、そろそろオフィスを抜け出して夏休みに入ることを考えてもいい時期だ。ネットワーク管理者にとっては、これは難しい仕事になる。あなたがIT部門の唯一の人員であれば、あなたの休暇はユーザーにとっては少々恐ろしいものになるかもしれない。この記事では、あなたが職場を抜け出すためのヒントを紹介する。 1．助けてくれる人を探す これは、同じオフィスにいる、ITにある程度興味がある人や、非常時には支援してくれると思える人で構わない。その人物に、システムへのアクセスを含め、必要なものを渡しておく。「どうしても必要な場合」のアクセスについては、各システムごとに管理者権限のパスワードを封筒に入れておくという方法も考えて
業務をアウトソーシングした後の社員は何をするの：ナレッジ！？情報共有・・・永遠の課題への挑戦：オルタナティブ・ブログ
ずいぶん前の話だが、ある会社から現在運用しているインフラ系システムのひとつをアウトソーシング（今流行のSaaS)にしたいという引き合いをうけて訪問した。対象のシステムは24H365Dの稼働が求められるため運用が大変で自社の運用管理者を貼り付けておくのが勿体ないというのがきっかけで、システム名を聞く限りどこの会社にもある一般的で共通的なシステムだったので、この意見にさもありなんと同意をして訪問することにした。 当日詳しく話を聞いてみると、このシステムには今でも自社の開発者が数名はり付いて継続的に追加開発やメンテナンスを行っいるとのこと。採用していたプロダクトが独自アーキテクチャーだったことも影響しているのだろうが、ユーザからのきめ細かい要望に対応する為に自社ＳＥをそこに特化させて抱え込んでいたようだ。 ところが本社の企画部門から情報子会社に異動してきたという担当者が声高に叫んでいるのは「単純
オープンソースのモニタリングツールを集めた「MonitoringForge.org」がオープン
GroundWork Open Sourceは、モニタリングに関連したオープンソースプロジェクトを集めたWebサイト「MonitoringForge.org」（β版）を開設した。 米GroundWork Open Source（GWOS）は米国時間の9月15日、オープンソースのITモニタリングツールやプラグインを集めたWebサイト「MonitoringForge.org」（β版）を開設した。IT管理者はオープンソースモニタリング技術を容易に比較できるという。 MonitoringForge.orgは、モニタリングに関連したオープンソースプロジェクトを集めたWebサイト。大規模なプロジェクトから小規模なプラグインまで、オープンソースとITモニタリングをキーワードにする技術のハブとする。機能やライセンスなどの情報のほか、ユーザー評価などのソーシャル機能も用意した。IT管理者は容易に比較、選択で
IT業の残念な秘密:Geekなぺーじ
「Sanity check: 10 dirty little secrets you should know about working in IT」という記事がありました。 「ああ、あるある」的な項目もあって面白かったです。 個人的には3番と4番がツボでした。 10番はアメリカ事情っぽいですね。 以下、要約です。 誤訳等が含まれている可能性が高いので、是非原文をご覧下さい。 10. IT専門家は他の専門家よりも給料が良い傾向にあるが、そのため経営者はあなたを所有していると勘違いすることがある ドットコムバブル時と比べると下がったものの、IT専門家が受け取る給与は高い方だ。 ただ、そのために「高い給料払ってるんだから、やれ」というような態度に出る雇用者もいる。 9. ユーザが馬鹿な行動を取るとあなたのせいになる 「コンピュータが壊れた！」「何したんだ！」などと怒鳴り込んで来るユーザがいる。
Geekなぺーじ : 失敗できる時代を生きていた人は幸せ
「新人が育たない」「同じ人がずっと管理/運営をし続けている」という話(悩み)を聞く事があります。 この話を聞く度に、教育や引継ぎは時として非常に難しいと思うとともに、失敗できる時代を生きれた人はある意味幸せなのではないかと思う事があります。 ある特定の作業がインフラ化する前から色々と出来た人は、恐らく様々な実験を行いながら経験を積んでいます。 失敗が許される環境、許されない環境 インフラ化する前であれば「失敗」が許されます。 失敗をする事は良いことではありませんが、それによって誰かの人生が終わるぐらいの事にはなりません。 大目玉を喰らって激しく落ち込む程度で済みます。 しかし、利用者が多くなり、インフラ化すると実験をする事は許されなくなり、無難に運営する事が第一になってしまいます。 自由に楽しく学ばせる事よりも監視下で失敗をさせない事に主眼が置かれがちです。 自由に楽しく学ばせるための箱庭
マルチコア時代のロードアベレージの見方 - naoyaのはてなダイアリー
ちょっと煽り気味のタイトルですが、CPU がマルチコアになり 2個、4個と増えていく中 Linux の負荷の指針になるロードアベレージをどう読むべきか、という話です。気になったところを少し調べたのでそのまとめを。 http://d.hatena.ne.jp/naoya/20070222/1172116665 でも書いたとおり、Linux のロードアベレージは「ロードアベレージは過去1分、5分、15分の間の実行待ちプロセス数の平均数 = 実行したくても他のプロセスが実行中で実行できないプロセスが平均で何個ぐらい存在してるか」を示す値です。ボトルネックが CPU、メモリ、ディスク等々どこにあるかは関係なく、仕事の実行までにどれぐらい待たされているかを示す値なので、システムのスループットを計測する指標の入り口になる値です。 このロードアベレージですが、実装を見るとランキュー(待ち行列)に溜まった
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サーバ運用の現場でひたすら監視し続けるエンジニアの手の内のすべて
United States
テクノロジー : 日経電子版