投稿

ラベル(監視)が付いた投稿を表示しています

小さな会社で一人で監視サーバ立てて運用して一年以上たったのでそのまとめ

MECE目指して書き始めたけど全然無理でした。多分、初心者向けです。 仕事で書いたドキュメントの流用です。 会社にはインフラでズバッと意見を出す人がいないので、こういう割と広いこと見れてそうな入門ドキュメントを会社のドキュメントとしてためておくことで、将来誰か監視システムを刷新するときとかの方向性になれればという考えです。 持つべきか、もたざるべきか まず大枠の設計として、監視システムを持つべきか、持たざるべきかという点について考える必要があると思います。 これは監視をするかしないかという意味ではなく、監視システムのサーバを持つかどうかという意味を指します。 つまりZabbixやmuninといった監視サーバを構築して運用していくのか、それともMackerelやNew Relicといった SaaS監視システムにお金を払って利用するのか、という監視システム運用の方向性の問題です。 私の場合は、会社でインフラエンジニアが私一人だったので、私の興味からZabbixを立てることにしました。 Zabbixに惹かれたのは主に「ネット上に先人の記事がそれなりに上がってる」「カスタムスクリプト書けばなんでもできる」「成長したイケてるベンチャーも使ってて実はダサくない」という3点で、とくにスクリプトを書けばなんでもできそうというのは、私自身のコーディング経験の足しにもできるし、アプリケーションエンジニアにも説明すれば監視業務にコミットしてもらえそうという期待からでした。  CTOは新しくてイケてるSaaSを使うのが大好きだったので、実はすでにNew Relicが入っていました。しかし有料プランは結構高く、財布事情が許してくれなかったので、私の提案をしぶしぶ飲んで、Zabbixとの並行運用になりました。 そしていま運用して一年ちょいになりますが、Zabbixでできることが増えてきたので、New Relicはほとんど見ていません。 エージェント自体は残っているけど…。 監視システムに欲しい機能 監視システムには下にあげる機能が基本的に存在しているでしょう。 一部の特化型システムにはないものもあるかもしれないですが…。 そして、それらができるだけ自動化されていることが望ましいです。 ここでいう自動化とは、少ない手作業で必要な多くの作...

監視の種類とカバーできる範囲について考えてみた

昔なんかそれっぽい表が必要だったので、書いてみたやつが、チケット整理してたら出てきた。どっかで使いそうなので、備忘録とします。 監視の種類 死活確認 症状確認 傾向確認 ログ監視 ◯ △ △ 性能監視 △ △ ◯ バッチ監視 ◯ △ △ レスポンス監視 ◯ △ △ プロセス監視 ◯ △ × 監視の種類としては ログ監視 性能監視 バッチ監視 レスポンス監視 プロセス監視 の5種類あれば、システムの一通りの状態確認が可能なのかな、と思いました。 で、確認すべき状態ってなんだ?ということになりますが、これは、死活の確認、症状(トラブルの程度)の確認、傾向(リソースの利用量)の確認を行うという方向性で考えればいいのかなと。