Sensu Casual Talks #1
Component • Server – Checkを実⾏行行するにあたっての準備やCheckの結果の処理理やイベントのハンドリ ングを⾏行行う • Client – 実際にCheckが⾏行行われる監視対象上にインストールする。Clientはチェック実⾏行行 のリクエストを取得したり、Checkを実⾏行行したり、RabbitMQにCheckの結果を 送信。Client単体で定期的にチェックを実施するように制御することも可能 • API – Sensuのデータに対するRESTベースのAPIを提供。このAPIをコールすると登 録済みのClientの情報や現在のイベントなどを取得可能 • Dashboard – SensuのWebベースのダッシュボード。ただし機能は少ない(しょぼい)
最近モチベがあがらん。まあ酒飲めばどうでもよくなってしまうんだけど。温泉入りたい。 sensu-server、sensu-api、sensu-dashboard、redis、rabbitmqのプロセスが入ってるdockerイメージ作ったのでそれについて。これでsensuサーバの構築がdocker pull, docker runの2コマンドだけでできる。 作った githubとdocker indexに置いた。 github https://github.com/hiroakis/docker-sensu-server docker index https://index.docker.io/u/hiroakis/docker-sensu-server/ docker入れてるマシンから↓みたいな感じで、docker indexからdocker pullで持ってきてdocker runでバー
ゴールデンウィークに突入したタイミングで色々忘れてしまいそうなので、ここにSensu Serverの作り方をメモっておく。 ちなみに、Sensuは最近ナウなヤングにバカうけのモニタリングツール。インストールした環境は、CentOS 6.5 (Linux version 2.6.32-431.11.2.el6.x86_64)。 ちなみに、Sensu関連のインストールについてはChefやPuppetの使用が、推奨されてるっぽいので、今回はChefのCookbookをありがたく利用させていただいた。(このエントリではchef-soloを使って環境構築している。) SensuのChef Cookbookは以下のGitHubリポジトリで公開されている。 https://github.com/sensu/sensu-chef sensu-chefの取得 # yum install -y git gcc
データベースが落ち着いているので、その間に別のことに着手。 チームの監視システムが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概要
こんにちは。@jedipunkz です。 今まで監視システムの Sensu やクラウドプラットフォームの OpenStack、コンフィギュ レーションマネージメントツールの Chef やクラウドライブラリの Fog 等使ってきま したが、これらを組み合わせるとオレオレオートスケーラ作れるんじゃないか？と思い、 ちょろっと作ってみました。 ちなみに自分はインフラエンジニアでしかも運用の出身なので Ruby に関しては初心者 レベルです。Chef で扱っているのと Rails アプリを作った経験はありますが、その程 度。Fog というクラウドライブラリにコントリビュートしたことはアリますが..。ちな みに Fog のコントリビュート内容は OpenStack Neutron(当時 Quantum) の仮想ルータ の操作を行う実装です。 そんな自分ですが…設計1周間・実装1周間でマネージャと C
このときにやった可視化部分の話。急いで作ったのでいろいろ雑な部分が多い。 開発合宿でDockerとMesosを使っていい感じにリソース提供とデプロイするやつを作ってた - wtatsuru's blog はじめに 元のやつから内部情報を削ったサンプルを置いておきます。適当にサーバ名など修正すれば使えるかもしれません。 https://github.com/tatsuru/docker-sample-app 全体の仕組みについてはここの図がわかりやすいと思います Docker + Mesos + Marathon + Graphite + Fluentd + Sensuを組み合わせたデプロイ管理ツールの話 - ゆううきブログ やりたいこと 目的はアプリケーションの現状を俯瞰できるダッシュボードを作ること。 それぞれのDockerコンテナは短命なので、下記の情報をうまく集約してやる必要がある。
こんにちは。@jedipunkz です。 自動化の基盤を導入するために色々調べているのですが、監視も自動化しなくちゃ！と いうことで Sensu を調べてたのですが Chef との相性バッチリな感じで、自分的にイ ケてるなと思いました。 公式サイト http://www.sonian.com/cloud-monitoring-sensu/ ドキュメント http://docs.sensuapp.org/0.9/index.html 開発元が予め Chef の Cookbook (正確にはラッパー Cookbook 開発のための Cookbook で Include して使う) を用意してくれていたり、インストールを容易にする ための Omnibus 形式のパッケージの提供だったり。Omnibus なのでインストールと共 に Sensu が推奨する Ruby 一式も一緒にインストールされます
バージョン 0.9 くらいのときの公式ドキュメントのざっくり訳＋個人のメモ 情報が古い＋理解が間違ってるとこあるかもなので注意して欲しいけど、需要がありそうなので出してみる Overview Sensu は監視ツールの一つ。Sensu はよく "monitoring router" と記述される。もっと平たく言うと、Sensu は多くのノードに対して "check" スクリプトを実行し、1 つまたは複数の Sensu サーバーにて "handler" スクリプトを実行する。 例えば、Apache の死活チェックをするとしよう。チェックスクリプトにより死活だけでなくメトリクスも収集する。そしてそのアウトプットは 1 つまたは複数の Handlers にルーティングされる。Handlers はチェック結果によって何をするのか定義するものだ。Handlers は今のところ E メール、IRC、T
SensuとはSensuはhttp://sensuapp.org/で公開されているオープンソース(MITライセンス)のモニタリングフレームワークです。 特徴以下のような特徴があります（公式サイトの記述を整理） シンプルで融通が効き拡張性があるモニタリングフレームワークエージェント、メッセージバス、イベントプロセッサーの機能を提供要件にあわせて他のツールとの組み合わせが可能クラウドを意識して開発自動でクライアント(監視対象）を登録コミュニティが活発RubyのEventMachineを使って作られているコードはGitHubでホストされ、テストコードは高いカバレージ。TravisCIで継続的インテグレーションを実施Nagiosのプラグインを再利用可能設定はすべてJSONファイルで行うRabbitMQを使ったメッセージ型のアーキテクチャーオムニバスインストーラーを提供個人的な見解としては、Sens
全国1億2000万人の監視マニアのみなさん、こんにちは。 Sensuは、非常にシンプルなアーキテクチャーで、さまざまなカスタムスクリプトを使っていろいろな監視を行ったり、メトリクスデータを取得することができます。メトリクスデータはさらにGraphiteなんかに送信してあげれば、どんどんグラフ化できます。このあたりの話が前提になっていますので、Sensuってなにそれ？な方は先に「Sensuを使って自由度の高い監視システムの構築を行う方法」をご覧ください。 チェックスクリプトを書くのは非常に簡単ですが、SensuではCommunity Pluginという形で非常にたくさんのプラグインが既に公開されていますので、今日はそれを紹介します。 Community Pluginの入手なにも考えず、git clone https://github.com/sensu/sensu-community-plu
AWSなど様々な環境でサーバを管理してくると、すべて同一の監視ツールを使うのがなかなか難しくなってきます。そんなこともあり、私も定期的にいろいろな監視ツールを試しています。 http://nanapi.co.jp/blog/2013/09/11/monitor_nanapi_servers/ nagiosとクラウドの相性が悪い！ 監視するには様々なツールがありますが、その中でも特に有名なツールはnagiosでしょう。古くから使われているツールで、プラグインも数多くあり様々な監視を行うことができます。 クライアント側にnrpeをインストールすることで、各ホストの詳細の状態まで監視することができますし、うまく活用すればかなり細かい監視までできます。 しかし、AWSのようなクラウド環境で使うには非常に使いづらいです。というのも、nagiosはサーバ側にどのホストを監視するのかという情報を持たなけ
本番環境の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のプロトタイプのようなものを作っていた。この前は非常にざっくりと書いただけだったので、もう少し中身に突っ込んで書いてみる。かなり長くなったので時間があるときにでもどうぞ。 デプロイや運用の
新規サービス用の監視をNagiosからsensuに切り替えて2ヶ月経ったので、 導入時の調査で社内で公開してたissueと、投入して2ヶ月間運用した記録を公開しておこうと思う。 というか以前Sensuの事を書くと公言していたのに、すっかりサボっていて 昨日@ma0eさんのブログを見て下記のやり取りを思い出して急いで書いた… @ma0e We started using it. @glidenote will report the detail soon, I think. — kentaro (@kentaro) 2013, 10月 30 @kentaro @glidenote that would be nice — Mitsutoshi Aoe/maoe (@ma0e) 2013, 10月 30 導入環境はCentOS 6.4で、利用しているsensuのバージョンは0.12.1-1にな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
