Sensu Casual Talks #1 に行ってきた #sensucasual · さよならインターネット
September 17, 2014 Sensu Casual Talks #1にいってきた。 @timwataさんのGraphiteのスケールの話が興味深かった。 3000台ぐらいのクライアントをSensuとGraphiteで見てるの 相当貴重な知見だと思う。 自分が話してきたのは特にどうということもなくて Chefを使えばOfficial cookbookと自分で何個かcookbookを書くことで 比較的簡単に(※1)導入、運用ができるという話をしてきた。 cookbookはここにまとめてある。 https://github.com/kenjiskywalker/chef/tree/master/site-cookbooks Sensu、スケールしていくとどこがボトルネックになるか みたいな話はユースケースが増えていくとコツみたいなのが 見えてくると思う。だけどnagiosで困っていな
SensuのGUI/CUIの雑感
Sensuのユーザインターフェイスであるsensu dashboard, sensu admin, uchiwa, sensu-cliおよびhubot+sensuを用いたオペレーションに関する雑感について。Read less
Sensu on AWS - Speaker Deck
Component • Server – Checkを実⾏行行するにあたっての準備やCheckの結果の処理理やイベントのハンドリ ングを⾏行行う • Client – 実際にCheckが⾏行行われる監視対象上にインストールする。Clientはチェック実⾏行行 のリクエストを取得したり、Checkを実⾏行行したり、RabbitMQにCheckの結果を 送信。Client単体で定期的にチェックを実施するように制御することも可能 • API – Sensuのデータに対するRESTベースのAPIを提供。このAPIをコールすると登 録済みのClientの情報や現在のイベントなどを取得可能 • Dashboard – SensuのWebベースのダッシュボード。ただし機能は少ない(しょぼい)
監視システムをSensuに刷新した | Ore no homepage
データベースが落ち着いているので、その間に別のことに着手。 チームの監視システムがmonっつー超レガシーシステム。知っている人もいるかもしれないが、monはperl製のシンプルな監視システム。古くからあるものなんだけど「mon perl」で検索すると「もしかして: man perl」とgoogle様にも何だっけソレ？と言われてしまうかわいそうな奴(「mon monitoring tool」だとちゃんと出てくる)。なのでまあこの際だから俺が葬り去ってやる。導入したSensuのバージョンは0.12.6。GW前くらいから運用しているが今んとこ問題ない。まだ運用期間短いね。 割と長文になっちまったので、目次をば。 0. sensu概要 1. なぜsensu？ 2. インストール 3. コンフィグの配置 4. プラグインについて 5. API 6. デバッグ 7. 今後の展望 0. sensu概要
次世代監視ツール Sensu リファレンス - Qiita
バージョン 0.9 くらいのときの公式ドキュメントのざっくり訳＋個人のメモ 情報が古い＋理解が間違ってるとこあるかもなので注意して欲しいけど、需要がありそうなので出してみる Overview Sensu は監視ツールの一つ。Sensu はよく "monitoring router" と記述される。もっと平たく言うと、Sensu は多くのノードに対して "check" スクリプトを実行し、1 つまたは複数の Sensu サーバーにて "handler" スクリプトを実行する。 例えば、Apache の死活チェックをするとしよう。チェックスクリプトにより死活だけでなくメトリクスも収集する。そしてそのアウトプットは 1 つまたは複数の Handlers にルーティングされる。Handlers はチェック結果によって何をするのか定義するものだ。Handlers は今のところ E メール、IRC、T
Sensuを使ってクラウド環境の監視を効率よく行おう - UNIX的なアレ
AWSなど様々な環境でサーバを管理してくると、すべて同一の監視ツールを使うのがなかなか難しくなってきます。そんなこともあり、私も定期的にいろいろな監視ツールを試しています。 http://nanapi.co.jp/blog/2013/09/11/monitor_nanapi_servers/ nagiosとクラウドの相性が悪い！ 監視するには様々なツールがありますが、その中でも特に有名なツールはnagiosでしょう。古くから使われているツールで、プラグインも数多くあり様々な監視を行うことができます。 クライアント側にnrpeをインストールすることで、各ホストの詳細の状態まで監視することができますし、うまく活用すればかなり細かい監視までできます。 しかし、AWSのようなクラウド環境で使うには非常に使いづらいです。というのも、nagiosはサーバ側にどのホストを監視するのかという情報を持たなけ
docker + puppet + sensu で構築するセンス香る監視環境（1） - ようへいの日々精進XP
はじめに docker と puppet を使って sensu の環境を構築してみた sensu についてざっくり理解する 構築では chef ではなく puppet で試してみる ベタなタイトルですいません（記事の中身はセンスありません） 参考 Sensu Documentation Sensu Intro Sensuを使って自由度の高い監視システムの構築を行う方法 監視ソフトをNagiosからSensuに切り替えて2ヶ月経ったのでまとめた Sensu 監視システムを Chef で制御 Getting Started With Sensu Using Puppet. For Real. sensu について sensu の詳細についてはこちらやこちらがとても参考になったので割愛させて頂く。以下は sensu のダッシュボード。 以下は自分が使ってみてセンスを感じたポイントと「？」なポイン
Sensuを使って自由度の高い監視システムの構築を行う方法
SensuとはSensuはhttp://sensuapp.org/で公開されているオープンソース(MITライセンス)のモニタリングフレームワークです。 特徴以下のような特徴があります（公式サイトの記述を整理） シンプルで融通が効き拡張性があるモニタリングフレームワークエージェント、メッセージバス、イベントプロセッサーの機能を提供要件にあわせて他のツールとの組み合わせが可能クラウドを意識して開発自動でクライアント(監視対象）を登録コミュニティが活発RubyのEventMachineを使って作られているコードはGitHubでホストされ、テストコードは高いカバレージ。TravisCIで継続的インテグレーションを実施Nagiosのプラグインを再利用可能設定はすべてJSONファイルで行うRabbitMQを使ったメッセージ型のアーキテクチャーオムニバスインストーラーを提供個人的な見解としては、Sens
Docker, Mesos, Sensu等を利用したBlue-Green Deploymentの仕組み - $shibayu36->blog;
本番環境のBlue-Green Deploymentの仕組みのプロトタイプを作っていた - $shibayu36->blog; 開発合宿でDockerとMesosを使っていい感じにリソース提供とデプロイするやつを作ってた - wtatsuruの技術方面のブログ Docker + Mesos + Marathon + Graphite + Fluentd + Sensuを組み合わせたデプロイ管理ツールの話 - ゆううきブログ この辺に書いたとおり、id:wtatsuru, id:y_uuki, id:hagihala と一緒に、DockerやMesosなどを利用してBlue-Green Deploymentのプロトタイプのようなものを作っていた。この前は非常にざっくりと書いただけだったので、もう少し中身に突っ込んで書いてみる。かなり長くなったので時間があるときにでもどうぞ。 デプロイや運用の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Sensu と PagerDuty を使って眠れない日々を実装する
Mspからみたsensu