#hbstudy 79 で Prometheus の話をしました
こんにちわ。昨日はドムの日でしたが全問正解できなかったガノタ市田です。 今回は新しくリリースされたcollectdのCloudWatchプラグインについて紹介します。 New – CloudWatch Plugin for collectd | AWS Blog 何ができるか CloudWatchがcollectdに対応したことによりサーバ上の様々な情報をcollectd経由でCloudWatchに送ることができ、そこでモニタリングできるようになりました。 導入の概要 collectd用のIAMポリシー作成 収集対象のインスタンスにポリシーアタッチ 対象インスタンスにcollectdのインストールと設定 それでは早速見ていきたいと思います。 手順 IAMの画面でポリシーを作成します。 ポリシーの作成をクリックします。 Policy Generatorを選択します。 次の画面の通り、Clou
微力ながらレビューに協力させていただいた @koemu 先輩の単著(マジすごい!) ITインフラ監視実践入門をいただきました。 ソフトウェアエンジニアのための ITインフラ監視[実践]入門 (Software Design plus) 作者: 斎藤祐一郎出版社/メーカー: 技術評論社発売日: 2016/01/16メディア: 単行本(ソフトカバー)この商品を含むブログを見る 詳細な目次は gihyo.jp を参照してください。http://gihyo.jp/book/2016/978-4-7741-7865-3 なし崩し的にサービス運用を担当しているWebアプリケーションエンジニア……あるいは先輩(インフラ)エンジニアがどのような選択肢を考えた上で現在の方法を選んでいるか?をうかがい知るためにうってつけの本 長い見出しで恐縮です。 ただ、自分のように専門のインフラ担当というわけではないものの
Mackerelを使い始めました CTO 小芝です。この記事はanimateLAB Advent Calendar 2015 2日目の記事です。 先日、"エンジニアをワクワクさせる「直感的サーバ監視サービス」 "Mackerelを数十台のホストに一斉導入しました。 既存サービスで外部に任せていたシステム運用をインハウス化し、運用クオリティを自分たちで高めていくための取り組みの一つです。 Mackerelとは 株式会社はてなが開発・運営しているサーバ監視サービスです。 mackerel.io このような特徴がWebサイトに書かれています。 *1 経緯 アニメイトラボでは今年の夏よりエンジニアを積極採用し、当初1名だったのですが現在では総勢10人でチームを組んで新サービスの開発に邁進しています。 それと並行して、既存サービスでは外部委託されていたシステム運用をインハウス化し、ビジネス面、開発面
VPSによるWebサーバー運用講座の連載3回目です。 今回は、サーバーの状態を監視するためのツールMuninをインストールします。 サーバーは生き物。末永くサーバーを利用するために、こまめに監視を行おう。 今まで順調に稼働していたWebサイトに突然アクセスできなくなったことってありませんか? そんなとき、誰しも慌てふためくと思います。 今、障害が起こっている場所がネットワークなのか、サーバーなのか、それとも自分の端末なのか? いろいろ調べているうちに、サーバーに原因があると分かった場合は、次のステップとしてサーバーにログインして何がトラブルになっているのか調べますよね。 トラブル対応は通常そのような手順を踏むと思いますが、とは言っても突発的なトラブルはできるだけ避けたいものです。 トラブルの発生を100%避けることは難しいのですが、日頃からサーバーの稼働状況をを見て異常がないかどうか観察し
2015年2月27日に、大阪で開催された「第23回 さくらの夕べin大阪」に参加してきました。 大阪では半年ぶりの開催で、100人近い方々が参加されました。 今回は、株式会社はてな(以下、はてな)のサーバー管理サービス「Mackerel(マカレル)」や、ウェブペイ株式会社の決済サービス「WebPay」についてご紹介します。 「Mackerelによる簡単サーバー管理入門」 はてなのCTO、田中慎司さんに「Mackerel」を紹介していただきました。Mackerelは、はてなが2014年9月にリリースしたクラウド型(SaaS)のサーバー管理ツールです。 サーバーを複数管理している個人や会社にとって、サーバーの管理や運用などの手間は面倒だし煩わしいものです。できれば、サーバーの保守にはあまり手間をかけたくないでしょう。 そんなニーズにマッチするサービスがMackerelです。 Mackerelは
ES + kibanaでサーバモニタリングをやってみたのですが、ESのCPU負荷がかなり高くて、リアルタイムにモニタリングできない状況だったので、graphite + grafanaにしてみた。ちなみに、ESのサーバのCPU負荷はこんな感じ。 GrafanaはGraphite用のDash boardを作るツール。最近、influxDBにも対応していてなかなか野心的。 Grafana - Graphite Dashboard kibanaをforkしただけあって、画面はそっくり。まだ修正もれがあるのか、メッセージにkibanaって文字がでてくることもある セットアップ もろもろのセットアップのメモ 監視サーバ まず、監視サーバにGraphiteとGrafanaをいれる。環境はCentOS6 CentOS6.x - CentOSにRPMでGraphite+Diamondをインストールする -
新規サービス用の監視を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にな
Welcome to the Monitorix project Take control over your small server Monitorix is a free, open source, lightweight system monitoring tool designed to monitor as many services and system resources as possible. It has been created to be used under production Linux/UNIX servers, but due to its simplicity and small size can be used on embedded devices as well. It consists mainly of two programs: a col
新しい機能をリリースした際に、MySQLに対して効率的ではないクエリが発行されてしまって、それが積もってサービス全体に影響が出てしまう前に発見してアラートをあげたい。 発見する手立てとしてはCPU使用率やInnoDBのROW OPERATIONSが考えられるところですが、今回はスロークエリが発生した回数を監視することにした。ちなみにいつものことながら対象とするMySQLは4.0系。long_query_timeがオンラインで変更できません。。。はい MySQLのスロークエリが発生した回数は、show status のSlow_queriesという項目でみることができて mysql> show status like 'Slow_queries'; +---------------+-------+ | Variable_name | Value | +---------------+---
異常値検知、素敵な響きですね!fluent-plugin-anomalydetect 作りました - PolyPeaceLight あらかじめ固定値でアラートの条件を決めておかなくても、通常と異なる数値変化を検出してアラートできたら大変嬉しい、ということでインストールして一週間ほど運用してみました。 fluent-agent-lite で送信されてくる nginx のアクセスログの数を対象 60秒間隔で集計 <match nginx.access.**> type copy <store> ... </store> <store> ... </store> <store> type anomalydetect tag nginx.anomaly.access_log tick 60 store_file /var/log/td-agent/anomalydetect.dat </store
MySQLの監視はCacti+Percona Monitoring Pluginsがおすすめ(監視サーバ構築編) 2012-05-18 MySQLをリソース監視する仕組みにはいくつかあるが、対象のMySQLサーバが5台以上ある場合はCactiがおすすめ。導入のしやすさだけでMuninを選ぶ人が多い気がするが、その選択基準は間違っている! Cactiのいいとこわるいとこ 多数のグラフを見やすく並べられる muninと比べて多数のサーバから軽快に情報を収集・表示できる 監視対象には、MySQLのユーザを追加するだけでかなりの項目数を監視できる データの保存にデータベースが必須だったりしてセットアップがやや面倒 慣れるまで監視プラグインを書くのに手間取る Muninのいいとこわるいとこ 監視プラグインを書くのが簡単 監視サーバにデータベースなどが必要なく、セットアップが簡単 グラフの並び方などが
uptimeはnode.jsで作られたWebサーバ死活チェッカーです。 Webサーバがきちんと正常に動き続けているかどうか一番簡単にチェックするのは定期的にアクセスしてレスポンスタイムを見ることです。そんなWebサービスの死活チェックに使えるのがuptimeです。 サーバを立ち上げました。最初に監視するWebサーバを設定します。 URLと監視する間隔を指定するくらいです。 監視を開始しました。グラフは自動更新されないのでご注意ください。 イベントがあればこちらに出力されます。 グラフではなく一覧で結果を確認できます。 徐々にグラフが更新されていきます。 uptimeは1000以上のWebサーバを一括で監視できるパフォーマンスを持っています。またダウンしている際にはWebアラートを表示できます。エラーがあった際にはHTTPステータスやその内容を記録してくれます。サーバはタグを使ってグループ管
fluentd の出力プラグイン、fluent-plugin-zabbix をリリースしました。 Github fujiwara/fluent-plugin-zabbix https://github.com/fujiwara/fluent-plugin-zabbix fluent-plugin-zabbix | RubyGems.org https://rubygems.org/gems/fluent-plugin-zabbix] 監視とメトリクス収集に Zabbix を使っているので、fluentd で収集した値を zabbix に送って扱いたかったのです。 挙動としては zabbix_sender でホスト側から送信するのと同様です。主に datacounter や flowcounter で集計した値を送るのを想定していますが、送信頻度に気をつければなんでも送れると思います。 作成
muninはサーバのさまざまな情報をグラフ化して表示するソフトです。 つい”ムーニン”と言ってしまいますが、”ムニン”がいいようです。 サーバ監視ツールということですが、例えて言うなら、自動車のメーター類のような働きをします。Ganglia、CactiやCloudForecastが同分類のソフトになります。 具体的にどのような場面で重宝するかと言いますと、サーバを増やす際のスペックを検討するときも、失敗する可能性が減らせます。 メモリをいくら搭載するものを用意すればいいのか、CPUはもう少し安いものでも問題無いのかなど、見積もることが簡単になります。 例)メモリを48GB搭載したサーバの利用状況 また以前は、何か障害が起きたときに、人間が手動でデータをかき集めてくるということをよくやっていましたが、Muninを入れてからはその手間は減り、より詳しい情報を参照して原因の特定・対策を講じること
これだけ見れば大丈夫!ーMySQLパフォーマンス監視のツボ(クエリ編) こんにちは、インフラ担当新人の nob です。 サーバー監視ツールで MySQL を監視しているのにデータが多すぎて活用していない。という方はいませんか?その豊富なデータをパフォーマンス・チューニングに活用しない手はありません。今回はサーバー監視ツールのグラフを読み解いた実戦経験を元に、「これだけ見れば大丈夫」というツボをまとめてみました。 これだけ見れば大丈夫! クエリ編 3つのつぼと5つのグラフ (その1)監視ツールが何を見ているのか知る (その2)監視のキモ、グラフ3点セット (Questions, Lock Waits と Transaction Handler) (その3)グラフでチェックする SQL チューニング ( Select Type と Handler) シンプルでお勧め、サーバー監視グラフ化ツール
去年のYAPC::Asia2011では、運用の話が活発に行われており、監視周りの話も多かったように記憶しています。そこで、監視の基本となる死活監視について、今回は私が普段使っているtokuhiromさん作の死活監視ツールApp::MadEyeを紹介しつつまとめたいと思います。 「死活」の通り、「死んでいるか、活きているか」について監視することです。具体的には、サーバーにPingを飛ばして死んでいるか活きているか確認したり、サーバーのハードディスクが一定量を超えているかどうか確認したりすることです。つまり、継続的に「1/0」で確認し続けることが、死活監視です。実務的な用途としては、「サイトが落ちている!」っていう状況に素早く対応するための準備となります。 リソース監視 一方で、リソース監視は、システム特定リソースの状態の変化を確認し続けることといえます。例えば、サーバーのロードアベレージの推
Ganglia is a scalable distributed monitoring system for high-performance computing systems such as clusters and Grids. It is based on a hierarchical design targeted at federations of clusters. It leverages widely used technologies such as XML for data representation, XDR for compact, portable data transport, and RRDtool for data storage and visualization. It uses carefully engineered data structur
このエントリーは、MySQL Casual Advent Calendar 2011 – MySQL Casual の第 19 日目のエントリーです。 皆さんこんにちは、n0ts こと、Naoya Nakazawa です。 今日は、みなさん日頃からカジュアルに MySQL を運用して、日々生活されていることと思います。MySQL は、非常に安定したオープンソースソフトウェアだと思いますが、どんなものでもときにはおかしくなったりするものです。 「備えあれば憂いなし」ということで、僕は日頃から Nagios というオープンソースソフトウェアを利用して、MySQL がおかしくなっていかいか日々カジュアルに監視しています。 今日は、カジュアルに MySQL を Nagios を使って監視する方法を紹介したいと思います。なお、今回は CentOS 5.7 x86_64 というカジュアルな Linux
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く