Effective Operational Visibility - Velocity pythian operational visibility
Operational visibility is more than simply monitoring and graphing. In this tutorial, we will discuss theory and execution of this key pillar of operational excellence, from business requirements to user story to collection, analysis, storage, and visualization. Additionally, we will be sharing our easily-deployed, open source OpsViz stack, available for AWS CloudFormation, accessible by GitHub.Re
Sensu発表資料
13. 新監視システム要件 ☁ 監視クライアント自身がチェック結果をサーバへ通知するパッシブ チェック – SensuならStandaloneモードがあるよ ☁ 監視設定・管理が自動化なり単純化ができること – SensuならChef LWRPがあるよ ☁ Sensu ServerへのClient登録名をrecipe(attribute)に書きたくない – ssh_configのHost文字列+Instance IDを結合してノード名を登録 ☁ 複数のAWSアカウントで稼働するEC2/RDS等を監視,メトリクを収 集・一元管理ができること – sensu community pluginがあり,Graphite用のHandlerもある。さらに Rubyistな同僚とPJを担当することになので何とかなりそう
成長し続けるインフラの�安定運用事情
『ユーザーストーリーマッピング』 出会いと適用 / User Story Mapping encounter and application
5 Years of Metrics & Monitoring
Video of this talk from DevOpsDays Ghent: http://www.ustream.tv/recorded/54694069 --- 5 years ago, monitoring was just beginning to emerge from the dark ages. Since then there's been a Cambrian explosion of tools, a rough formalisation of how the tools should be strung together, the emergence of the #monitoringsucks meme, the transformation of #monitoringsucks into #monitoringlove, and the rise of
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で困っていな
zabbixで運用していた人間がsensuを触ってみた感想 - 右往左往ブログ
zabbixでシステム運用に関わっている人間が、sensuを使った運用にチャレンジした話です。 結論としては、運用に本格的に入る前に、sensuの導入を断念しました。 sensuとは sensuは、クラウド環境に親和性の高い監視・モニタリングソフトウェアです。 http://sensuapp.org/ 大まかなポイントは以下だと思います。 Chefやpuppetで簡単に導入できる community pluginが豊富 設定が全てコードで記載されている。変更するときもjsonファイルの書き換え クライアント側からサーバへ通知して監視が始まる(サーバ側にクライアントの定義が必要ない) → AWS EC2のようなImmutableに扱う環境で便利 詳細は以下の記事が詳しいです。 【DevOpsDays Tokyo 2013】クラウド時代のモニタリングツール、UNIXの思想が息づくsensuチュ
Sensu Serverをインストールする手順メモ - 元RX-7乗りの適当な日々
ゴールデンウィークに突入したタイミングで色々忘れてしまいそうなので、ここに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
Sensuのclient.jsonをChefで管理する場合のsubscriptionの作成方法 - Qiita
Sensuの管理をChefで行う場合、subscriptionsの設定をどうするか考えた結果 下記のようにtemplate側でまとめるという方法があるのかなと思ったのですが (attributesはrole to roleのみmergeされる。その際にnodeのattributesは破棄されてしまうので) 他に何か良い方法ありますかね。 もしくはそもそも私の認識に誤りがある可能性が高いので、 ご指摘頂ければありがたいです。 roles/web_foo.json "sensu": { "node_subscriptions": [ "web_foo" ] }, "run_list": [ "role[web]" ] { "name": "web", "description": "web", "json_class": "Chef::Role", "override_attributes":
CentOS6にSensuをインストールする – Fish and Tips
CentOS6にChef(Solo)を使ってSensuをインストールする手順 rbenvで美しくRubyをインストール CentOS 6.4にrbenvでRuby 2.0.0をインストールする epelリポジトリ追加 [code] [root@sensu ~]# rpm -ivh "http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm"[/code] 必要なものをインストール [code] [root@sensu ~]# yum -y install –enablerepo=epel git make gcc zlib-devel openssl-devel readline-devel ncurses-devel gdbm-devel db4-devel libffi-dev
sensu + fluentd + norikra で sensu server のログを眺めてみる - ようへいの日々精進XP
追記 追記（1）Failed: Incorrect syntax near 'output' (a reserved keyword) のエラー こちらが参考になった esper の予約語のようですな はじめに タイトル通り sensu server を検証するあたりログをチラチラ見れたら嬉しいよね しかもせっかくログまでも JSON な sensu は fluentd との相性は抜群！ということで試した 準備 細かい設定については割愛させて頂きます... 既に稼働している sensu server に td-agent と norikra をインストールする 以前に作った Dockerfile を一部流用 fluentd.conf(td-agent.conf) 今回は td-agent を利用したので td-agent.conf は以下のような感じでシンプルに。 <source> typ
Dockerfile + chef-solo - orenoblog
既存のChefレシピをDockerfileに流用してみます。 Dockerコンテナそのものは状態を持たない(ステートレス)ように動かすのが良さそうなので mysqld等のRDBMSを始めとした状態を持つ(ステートフル)なイメージは作成しません。 またserviceコマンドで利用される/etc/init.d配下のスクリプトはDockerコンテナ内では利用できないのが注意です。 ↑使えました docker run実行時に起動スクリプトを用いずプロセスを起動する必要があります。 そのためchefのserviceリソースは流用できませんが（意味ない） package, template, attribute等のパラメータを設定するためのリソースは流用できるのでDockerイメージの作成に十分役立つと考えています。 さて作成順序は以下のとおりです。 Berkshelfで利用するCookbookを取得
次世代監視ツール Sensu リファレンス - Qiita
バージョン 0.9 くらいのときの公式ドキュメントのざっくり訳＋個人のメモ 情報が古い＋理解が間違ってるとこあるかもなので注意して欲しいけど、需要がありそうなので出してみる Overview Sensu は監視ツールの一つ。Sensu はよく "monitoring router" と記述される。もっと平たく言うと、Sensu は多くのノードに対して "check" スクリプトを実行し、1 つまたは複数の Sensu サーバーにて "handler" スクリプトを実行する。 例えば、Apache の死活チェックをするとしよう。チェックスクリプトにより死活だけでなくメトリクスも収集する。そしてそのアウトプットは 1 つまたは複数の Handlers にルーティングされる。Handlers はチェック結果によって何をするのか定義するものだ。Handlers は今のところ E メール、IRC、T
Sensu,Chef,OpenStack,Fog を使ったオレオレオートスケーラを作ってみた！
こんにちは。@jedipunkz です。 今まで監視システムの Sensu やクラウドプラットフォームの OpenStack、コンフィギュ レーションマネージメントツールの Chef やクラウドライブラリの Fog 等使ってきま したが、これらを組み合わせるとオレオレオートスケーラ作れるんじゃないか？と思い、 ちょろっと作ってみました。 ちなみに自分はインフラエンジニアでしかも運用の出身なので Ruby に関しては初心者 レベルです。Chef で扱っているのと Rails アプリを作った経験はありますが、その程 度。Fog というクラウドライブラリにコントリビュートしたことはアリますが..。ちな みに Fog のコントリビュート内容は OpenStack Neutron(当時 Quantum) の仮想ルータ の操作を行う実装です。 そんな自分ですが…設計1周間・実装1周間でマネージャと C
Sensuを使って自由度の高い監視システムの構築を行う方法
SensuとはSensuはhttp://sensuapp.org/で公開されているオープンソース(MITライセンス)のモニタリングフレームワークです。 特徴以下のような特徴があります（公式サイトの記述を整理） シンプルで融通が効き拡張性があるモニタリングフレームワークエージェント、メッセージバス、イベントプロセッサーの機能を提供要件にあわせて他のツールとの組み合わせが可能クラウドを意識して開発自動でクライアント(監視対象）を登録コミュニティが活発RubyのEventMachineを使って作られているコードはGitHubでホストされ、テストコードは高いカバレージ。TravisCIで継続的インテグレーションを実施Nagiosのプラグインを再利用可能設定はすべてJSONファイルで行うRabbitMQを使ったメッセージ型のアーキテクチャーオムニバスインストーラーを提供個人的な見解としては、Sens
Docker コンテナにアプリケーションを立てて Graphite でいい感じに可視化するまで - wtatsuruの技術方面のブログ
このときにやった可視化部分の話。急いで作ったのでいろいろ雑な部分が多い。 開発合宿でDockerとMesosを使っていい感じにリソース提供とデプロイするやつを作ってた - wtatsuru's blog はじめに 元のやつから内部情報を削ったサンプルを置いておきます。適当にサーバ名など修正すれば使えるかもしれません。 https://github.com/tatsuru/docker-sample-app 全体の仕組みについてはここの図がわかりやすいと思います Docker + Mesos + Marathon + Graphite + Fluentd + Sensuを組み合わせたデプロイ管理ツールの話 - ゆううきブログ やりたいこと 目的はアプリケーションの現状を俯瞰できるダッシュボードを作ること。 それぞれのDockerコンテナは短命なので、下記の情報をうまく集約してやる必要がある。
Docker + Mesos + Marathon + Graphite + Fluentd + Sensuを組み合わせたデプロイ管理ツールの話 - ゆううきブログ
開発合宿でDevOps界隈やモニタリング界隈で流行りのツールを組み合わせてBlue Green Deploymentできる何かを作りました。 同じチームで開発したid:shiba_yu36 先生やid:wtatsuru 先生が既にブログを書いてますが、自分の視点で書いてみます。（13/12/24追記: より詳細な内容が新規に書かれたのでリンク先を入れ替えました） Docker, Mesos, Sensu等を利用したBlue-Green Deploymentの仕組み - $shibayu36->blog; Docker コンテナにアプリケーションを立てて Graphite でいい感じに可視化するまで - wtatsuru's blog 僕は主に、各ツールから得られる情報をまとめて管理し、デプロイを実行するデプロイ管理ツールを作成していましたので、それについて書きます。 普段は運用の修行をして
監視ソフトをNagiosからSensuに切り替えて2ヶ月経ったのでまとめた - Glide Note
新規サービス用の監視を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にな
Sensuについて - maoeのブログ
最近Sensuというモニタリングフレームワークを試している。見ての通り公式はオサレで今時な感じで、Nagiosのような古くささやZabbixのようなエンタープライズ臭はない。 Sensuの特徴は何かと考えると、こんな感じのことが浮かぶ。 監視とメトリクス収集を一つの仕組みで行える。 ただし収集したデータの可視化はしない。 設定がlightweight 所定のディレクトリにJSONファイルをつっこんでおくと勝手にdeep mergeされるのでinclude指定とかいらないし、ポチポチやってデータベースに設定値を入れる必要もない。 キーがかぶったときにどうなるかとかは知らないので、設定がシンプルとは言わない。 JSONなのでコメントは書けない。コメントはChefのレシピ側に書こうという発想。 クライアント一覧は自動的に作られるので自分で能動的に登録する必要もない。 Chefで設定するためのco
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
