障害発生時にも漏れなし！ Zabbixの監視アラートでRedmine上にチケットを起票する仕組みをつくろう
* About to connect() to redmine-server port 80 (#0) * Trying redmine-server... * Adding handle: conn: 0x21b3278 * Adding handle: send: 0 * Adding handle: recv: 0 * Curl_addHandleToPipeline: length: 1 * - Conn 0 (0x21b3278) send_pipe: 1, recv_pipe: 0 * Connected to redmine-server (xxx.xxx.xxx.xxx) port 80 (#0) > POST /issues.json HTTP/1.1 > User-Agent: curl/7.30.0 > Host: redmine-server > Accept: *
監視アーキテクチャ(Sensu,Pingdom,Mackerel,StatusPage.io,PagerDuty)についてまとめてみる(2014年12月版) - Glide Note
Sensu Advent Calendarに便乗して、Kaizen Platform, Inc.の2014年12月現在の監視アーキテクチャの話をちょっとしてみようと思う。 モニタリング領域 サービスを監視している領域 Pingdom Pingdom - Website Monitoring 外部ネットワークからのサービスの死活監視。アメリカ、ヨーロッパ、アジアなどの拠点からサービスの死活監視が出来るため、特定の地域からアクセス出来ない場合なのが検知出来る。 後述するstatuspage.ioとの連携で、障害を検知すると、サービスのステータス状況が自動で変わるようになっている Sensu Sensu | The open source monitoring framework. 監視フレームワーク サーバを内部ネットワークから監視するために利用 サーバのプロセス監視、サーバ間の疎通監視、エラ
0〜10分前と、10分前〜20分前の変化を比べてアラート
0->10分前の差異と10分前->20分前の差異を比べます。 どのくらい変化したか？という数値をだします。 rubyで書くと、このような感じですね。案外簡単です。 variability = ((last - second) / (second - third)) ※ほかにも良い方法がありましたら、ぜひ教えてください。 0.6 < N < 1.4 だったらアラートする。などといった使い方ができます。 @kazeburoさんのGrowthForecastのJSON APIを叩いて、モニタリングしている数字に急激な変化があったときに、nagiosでアラート通知する。みたいなやり方をしています。 しきい値を見てアラート。というのも大事ですが、大事な数値を見るときはこのくらい細かくチェックできると安心できますね。
Java トラブル解析支援ツール HeapStats のご紹介
Introduction of HeapStats. (In Jpanese only)Read less
dstat + fluentd + Elasticsearch + kibana でサーバモニタリングする - blog.nomadscafe.jp
普段はサーバのメトリクス可視化のためにcloudforecastを使っていますが、某案件用に数秒単位で数十台のサーバのメトリクスを表示したいので、記事タイトルのような構成を作ってみた。 dstatでとった各種値の他に、nginxとmemcachedの情報も合わせて表示させています。 セットアップ もろもろのセットアップのメモ 監視サーバ まず、監視サーバにElasticsearchとkibanaをいれる。環境はCentOS6 $ sudo yum install java-1.7.0-openjdk $ sudo rpm -Uvh https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-1.x.x.noarch.rpm Elasticsearchは特に設定なく起動 $ sudo service
監視ソフトを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
TechCrunch | Startup and Technology News
Live Nation says its Ticketmaster subsidiary was hacked. A hacker claims to be selling 560 million customer records. An autonomous pod. A solid-state battery-powered sports car. An electric pickup truck. A convertible grand tourer EV with up to 600 miles of range. A “fully connected mobility device” for young urban innovators to be built by Foxconn and priced under $30,000. The next Popemobile. Ov
Zabbixで10,000台のサーバーを監視する
Linux/OSS関連のエンジニアです。OSS監視ツールZabbixの日本支社、Zabbix Japanの代表も務めています。 Zabbixは重い！というツイートや情報があったりするのですが、海外ユーザーのサポート経験からZabbixのパフォーマンスは驚くほど良くなっていると思っていて、どこに違いがあるのか不思議に思っていたりします。 Zabbix社で大規模システムというと、監視対象が数千台規模以上、1秒あたりの監視項目数(Zabbixのダッシュボードやレポートメニューから見れる値、以降nvpsと書きます)が1000を超えるくらいからです。本社ではこのnvpsの値が1万に到達しようとしているユーザーをサポートしています。 海外のZabbixサポートユーザーはボトルネックになっている点についてZabbix本体に修正要望を出し、Zabbix本体のパフォーマンスを上げつつ監視規模を拡大していって
完璧な監視システムの作り方 in cybozu.com - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、Hazama チームの萩原(@hagifoo)です。 ハードウェアは故障し、ソフトウェアにはバグがあり、運用ではミスがおきるもの。もちろん、障害が発生しないのが理想ですが人間が作ったものに完璧はありません。そこで、障害の前兆や発生を捉え、その詳細を運用チームに知らせるための監視システムが必要となります。cybozu.com でも以下のようにありとあらゆるものを監視するシステムを構築し日夜監視を行なっています。 今回は、そんな cybozu.com の監視(モニタリング)システムについてお話しします。 cybozu.com と障害 監視システムの設計 3つの監視 外形監視 症状監視・リソース監視 ログ監視 その他の監視 モニタリングフレームワーク 誰が監視者を監視するのか？ まとめ cybozu.com と障害 まずは、監視対象である cybzou.com について説明します。
Sensu 監視システムを Chef で制御
こんにちは。@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 一式も一緒にインストールされます
gfspark: GrowthForecastのグラフをターミナルに表示する - ( ꒪⌓꒪) ゆるよろ日記
というコマンドを作った。みんな大好きGrowthForecast!! gfspark yuroyoro/gfspark · GitHub Installation $ gem install gfspark Usage 以下の3つのいずれかの方法でグラフを指定してくれ。 gfspark "グラフのURL" gfspark your_service/your_section/your_graph h --url=http://your.gf.com gfspark your_service your_section your_graph h --url=http://your.gf.com Complex Graphには対応してない。あと、内部でsttyコマンドを使ってるのであっWindows…… グラフが上手く表示されない場合は、`-n`オプションを試してみてくれ。例えば、フォントがRic
今後の負荷を RRDTool を使って予測してみよう
斎藤です。 今日は、RRDToolを使って、今後かかる負荷を手軽に予測する方法をご紹介します。あわせて、プログラムと連携して性能限界を越えそうなサーバがあるかを判定してみます。人手ではまかないきれない数のサーバに対して、一台ずつ問題の予兆を調べるときなどにお試しください。 ※CentOS 6.3 (64bit) + RRDTool の2013/2/20頃の最新ソースを用いて試しています 「限界」を早く知りたい！ ITインフラを運用している方の多くは、Cacti, Munin等で負荷を日々モニタリングされているかと思います。モニタリングしたデータを用いて今後を予測する際、どのようにされていらっしゃいますでしょうか？描かれたチャートの動きをもとに、経験と勘を駆使して「ヨイショ！」っとされている方も、いらっしゃるのではないでしょうか。 特に、ディスク容量やネットワークトラフィック等、根本的な対策
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Docker監視環境 - Part1: cAdvisor, collectd, Riemann, InfluxDB, Grafana
ご注文は監視自動化ですか？
http://blog.udcp.net/2013/12/05/fluent-plugin-network-probe/
今日から業務で使える17の運用系Linuxツール、そして円環の理
CloudStackをMuninで監視・序 ～リソースをAPI経由で監視してみる話～