タグ

sensuに関するa2ikmのブックマーク (10)

  • Sensu Deep Talks #1

    Kaizen Platform, Inc.の監視の話

    Sensu Deep Talks #1
  • 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 on AWS - Speaker Deck
    a2ikm
    a2ikm 2014/06/21
    モニタリングの設定、楽にしたい
  • Sensu serverのdockerイメージ作った | Ore no homepage

    最近モチベがあがらん。まあ酒飲めばどうでもよくなってしまうんだけど。温泉入りたい。 sensu-server、sensu-api、sensu-dashboard、redis、rabbitmqのプロセスが入ってるdockerイメージ作ったのでそれについて。これでsensuサーバの構築がdocker pull, docker runの2コマンドだけでできる。 作った githubdocker 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に刷新した | 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に刷新した | Ore no homepage
  • 次世代監視ツール Sensu リファレンス - Qiita

    バージョン 0.9 くらいのときの公式ドキュメントのざっくり訳+個人のメモ 情報が古い+理解が間違ってるとこあるかもなので注意して欲しいけど、需要がありそうなので出してみる Overview Sensu は監視ツールの一つ。Sensu はよく "monitoring router" と記述される。もっと平たく言うと、Sensu は多くのノードに対して "check" スクリプトを実行し、1 つまたは複数の Sensu サーバーにて "handler" スクリプトを実行する。 例えば、Apache の死活チェックをするとしよう。チェックスクリプトにより死活だけでなくメトリクスも収集する。そしてそのアウトプットは 1 つまたは複数の Handlers にルーティングされる。Handlers はチェック結果によって何をするのか定義するものだ。Handlers は今のところ E メール、IRC、T

    次世代監視ツール Sensu リファレンス - Qiita
  • CentOS 6.5でChefからSensuをインストールしようとするとRabbitMQでコケる回避策 · さよならインターネット

    January 5, 2014 date : 2014/01/05 OS : CentOS 6.5 Sensu : sensu-0.12.3-1.x86_64 sensu-chef : 0.8.0 === (2014/01/06)追記 ======================= @kenjiskywalker CentOS 6.4 → 6.5 にしたら出なくなった・・・うーむ — Naoya Ito (@naoya_ito) January 6, 2014 ドラクエ氏によると、この解決策だと6.4は別のエラーがでるとのこと。 ================================ @kenjiskywalker centos? — Naoya Ito (@naoya_ito) January 5, 2014 @kenjiskywalker CentOS 6.4 の opens

  • sensu-chef で監視システム Sensu を管理 #2

    こんにちは。@jedipunkz です。 以前、Sensu を Chef で管理する方法について書きました。 http://jedipunkz.github.io/blog/2013/06/20/sensu-chef-controll/ これは今年(2013)の6月頃の記事ですが、この時はまだ sensu-chef を include して使う別の Chef Cookbook が必要でした。また Redis 周りの Cookbooks が完成度あまく、またこれも 公式とは別の Cookbooks を改修して再利用する形でした。この作業は結構しんどかっ た記憶があるのですが、最近 GlideNote さんのブログを読んで( ゚д゚)ハッ!と思い、 sensu-chef を再確認したのですが、だいぶ更新されていました。 下記が sensu-chef です。 https://github.com

    sensu-chef で監視システム Sensu を管理 #2
  • Stop using Nagios (so it can die peacefully)

    Stop using Nagios (so it can die peacefully)AI-enhanced description The document critiques Nagios as a monitoring tool, highlighting its simplicity and existing plugin support while pointing out its major shortcomings such as poor scalability, configuration complexity, and inadequate API integration. It suggests leveraging the strengths of Nagios alongside more modern and scalable tools like Sensu

    Stop using Nagios (so it can die peacefully)
  • Sensuを使って自由度の高い監視システムの構築を行う方法

    SensuとはSensuはhttp://sensuapp.org/で公開されているオープンソース(MITライセンス)のモニタリングフレームワークです。 特徴以下のような特徴があります(公式サイトの記述を整理) シンプルで融通が効き拡張性があるモニタリングフレームワークエージェント、メッセージバス、イベントプロセッサーの機能を提供要件にあわせて他のツールとの組み合わせが可能クラウドを意識して開発自動でクライアント(監視対象)を登録コミュニティが活発RubyのEventMachineを使って作られているコードはGitHubホストされ、テストコードは高いカバレージ。TravisCIで継続的インテグレーションを実施Nagiosのプラグインを再利用可能設定はすべてJSONファイルで行うRabbitMQを使ったメッセージ型のアーキテクチャーオムニバスインストーラーを提供個人的な見解としては、Sens

    Sensuを使って自由度の高い監視システムの構築を行う方法
  • Sensuについて - maoeのブログ

    最近Sensuというモニタリングフレームワークを試している。見ての通り公式はオサレで今時な感じで、Nagiosのような古くささやZabbixのようなエンタープライズ臭はない。 Sensuの特徴は何かと考えると、こんな感じのことが浮かぶ。 監視とメトリクス収集を一つの仕組みで行える。 ただし収集したデータの可視化はしない。 設定がlightweight 所定のディレクトリにJSONファイルをつっこんでおくと勝手にdeep mergeされるのでinclude指定とかいらないし、ポチポチやってデータベースに設定値を入れる必要もない。 キーがかぶったときにどうなるかとかは知らないので、設定がシンプルとは言わない。 JSONなのでコメントは書けない。コメントはChefのレシピ側に書こうという発想。 クライアント一覧は自動的に作られるので自分で能動的に登録する必要もない。 Chefで設定するためのco

    Sensuについて - maoeのブログ
  • 1