No one is an island. Learnings from fostering a developers community.
No one is an island. Learnings from fostering a developers community.
今日は freee で開催された Tech Meetup に参加してきた.ダッシュボード厨としては最近導入した grafana-zabbix の紹介もしたいと思って「grafana-zabbix 活用術」というタイトルで LT もしてきた.懇親会でいろいろお話もできたし凄く楽しかった! plaidtech.connpass.com freee を支えるインフラ技術 @manabusakai Monyog - Monitor & optimize MySQL database performance は知らなかった! 「障害が起きることを前提に」は本当に重要 AWS Well-Architected Framework にも「コンポーネントの障害に対応するべし」と書かれてるし 理解はしてるけど SPOF になってしまうこともあるよなぁ…と思ったり 「トラッキングして見える化」も重要だなと思っ
Zabbix関連のセミナーや勉強会でWebインターフェースに対する不満が、たびたび話題にあがります。 (個人的には他のプロプラ・OSSな監視ツールを一通り使ってきた中では良く出来てると思うのですが) 設定に関してはAPIを使用して自動化・省力化した事例を良く聞きますが、日々のモニタリングにおけるイベントやリソースグラフのビューアとしての機能については、あまり改善事例の情報がなかったので今回はネットで見かけたビューア機能を改善をしてくれるツールを中心にまとめてみました。 統合監視 HyClops for Zabbix https://github.com/tech-sketch/hyclops http://tech-sketch.github.io/hyclops/jp/ http://www.atmarkit.co.jp/ait/articles/1311/07/news004.html
障害対応・運用におけるトリアージ的対応とZabbixの活用 Zabbix Conference Japan 2015 発表資料 http://www.zabbix.com/jp/conference_japan_2015.php 日時:2015年11月20日(金) 会場:パレスサイトビル マイナビルーム #zabconfjp2015Read less
こんにちは、インフラストラクチャー部の菅原(@sgwr_dts)です。 インフラストラクチャー部は基本的にクックパッドのインフラに関わる業務を行っていますが、関連会社やグループ会社のインフラまわりについても作業を行ったりお手伝いしたりします。今回、グループ会社である「みんなのウェディング」のAWS化に伴ってそのお手伝いをさせていただいたので、そのときのモニタリングシステムの構築についての失敗談をお話ししたいと思います。 みんなのウェディングのAWS移行 みんなのウェディングは2015年4月にクックパッドグループに加わった結婚式場の口コミサイトです。いままでみんなのウェディングはVPSのホスティングサービスで動いていたのですが、グループ会社化に伴って大規模なリニューアルを進めており、その一環としてAWSへの移行を行いました。 AWSへの移行作業では様々な要素を検討する必要があります。パフォー
概要 Zabbixのデータをソースとして、Grafanaでサーバの状態を可視化できるgrafana-zabbixのインストール〜初期設定までの手順です。 http://play.grafana-zabbix.org/ にオンラインのデモ環境があります。 とてもステキな感じです。 環境 すでにZabbixサーバ(2.4系)がインストールされているCentOS6上で構築しました。 Zabbixサーバは2.2系以下だと設定が若干異なるようです。 https://github.com/alexanderzobnin/grafana-zabbix/wiki/Installation#note-for-zabbix-22-or-less Grafanaは未インストールの状態です。今回は2.0系を使います。
こんにちは。インフラストラクチャー部の加藤(@EugeneK)です。 今回はWebサービスを運用する上で欠かせない、モニタリングをクックパッドでどうしているかという話をします。 死活監視と性能監視 Webサービスを運用している以上、そのサービスを稼働しているサーバがあり、サーバには故障やトラブルが発生します。 また、どれくらいのパフォーマンスが出ているか、リソースをどのくらい消費しているかなどのトレンドを把握することは、成長するサービスを支えていく上で欠かせません。 故障やトラブルにいち早く気づくための仕組みを死活監視と言います。 また、サーバリソースの時系列での推移を知るために、グラフとしてトレンドを可視化する仕組みを性能監視と言います。 ポーリング監視の限界とZabbixのアクティブ監視 クックパッドでは死活監視にNagios、性能監視にMuninを使用してきましたが、サーバ台数の増加
4月から劇団サーバーワークスに加わりました。伊藤です。 社内ではくりゅーと呼ばれております。 AWS環境では、わずか数クリックでサーバーができたり、AutoScalingで自動的にサーバーが増えたり、 オンプレミスの監視運用のスピードでは全く追いつけません。 そこで、今回はAuto Scalingなどで監視対象のインスタンスが自動で増えたり減ったりしても、Zabbixで常に対象インスタンスを自動登録し、監視対象にする方法をご紹介します。 自動構成ツールなどには依存しないので、どんな方法で(マネージメントコンソール、SDK、CLI、API、Elastic Beanstalk等々)構築、運用していても適用できます。 監視対象インスタンスのAgent側設定 zabbix_agentd.confにおいて、以下の点を設定します。 Server=127.0.0.1 #Zabbix-serverのIPも
CloudWatchがあればZabbixとできること大して変わらないし 「CloudWatchでだいたいの要件は満たせそうですね。」 とおっしゃる方もいらっしゃるようですが私たちServerworksが、そして私伊藤がなぜZabbixをおすすめするのか今回はそのことについてお話ししたいと思います。 統合監視ができる CloudWatchはあくまでもAWSの中の事象だけを見ます。 しかし実際のシステム運用ではAWSだけでなく他のクラウドシステムやオンプレミス、 クラウドとの接続ポイントとなるネットワーク機器など、監視すべき部分はAWSの中だけではありません。 そういった場合すべてを統合的に見られる監視ツールが必要となります。 またAWSの中だけであったとしてCloudWatchではアカウント毎に表示されることになります。 たとえば経費分割のために1つの会社で事業部毎に別々のAWSアカウントを
Immutableなインフラがなんやかんやと喧しい今日この頃ですが、インスタンスが頻繁に増えたり減ったりすると、監視サービスで継続的な値を追うのが難しくなるよね、という問題を最近感じています。 サービス全体で複数のホストの合計値を取得しておくことで使用量の推移を見たいような値、具体的には以下のようなものです。 外向けのネットワークトラフィック クライアントと永続接続する daemon の持っているコネクション数 ジョブの処理数 複数のMySQL slaveが処理した参照クエリ数 ということで、zabbix-agent への proxy として動作する、複数 agent からの数値を合計して返すようなものがあったら捗るんじゃないかと書いてみました。 公式ページ fujiwara.github.io/zabbix-aggregate-agent リポジトリ zabbix-aggregate-a
Linux/OSS関連のエンジニアです。OSS監視ツールZabbixの日本支社、Zabbix Japanの代表も務めています。 Zabbixは重い!というツイートや情報があったりするのですが、海外ユーザーのサポート経験からZabbixのパフォーマンスは驚くほど良くなっていると思っていて、どこに違いがあるのか不思議に思っていたりします。 Zabbix社で大規模システムというと、監視対象が数千台規模以上、1秒あたりの監視項目数(Zabbixのダッシュボードやレポートメニューから見れる値、以降nvpsと書きます)が1000を超えるくらいからです。本社ではこのnvpsの値が1万に到達しようとしているユーザーをサポートしています。 海外のZabbixサポートユーザーはボトルネックになっている点についてZabbix本体に修正要望を出し、Zabbix本体のパフォーマンスを上げつつ監視規模を拡大していって
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く