・2年で月間10億PVを支えるまで成長した ZenClerkの運用上の工夫を紹介 ・AWSのTipsとあるある話の共有
IDCフロンティアのUI・UXチームです。 前回はフロントエンド領域の開発に関する業務フローを中心にご紹介しました。今回は利用技術だけでなく、効率的に開発を進めるための工夫や普段気を付けている点などをご紹介します。 前回のブログ内容と合わせて読んでいただくと、実際の業務イメージが想像しやすいかもしれません。 利用技術 JavaScriptライブラリ ライブラリの取り扱い 静的解析ツール CI CD 生産性を上げるための工夫 デザインシステムを用いたUI仕様の決定 テスト駆動開発を用いた手戻り・抜け漏れの防止 Autifyを用いたE2Eテストの実施 普段開発やコードレビューで意識していること 長期メンテを考慮した設計・実装にする 初心者でも読める実装を心がける どんな方が向いているか お客さまの分かりやすさを追及するためにどんなUIがいいか考えられる方 より読みやすく保守しやすいコードを書く
新規サービス用の監視を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にな
こんにちは、Hazama チームの萩原(@hagifoo)です。 ハードウェアは故障し、ソフトウェアにはバグがあり、運用ではミスがおきるもの。もちろん、障害が発生しないのが理想ですが人間が作ったものに完璧はありません。そこで、障害の前兆や発生を捉え、その詳細を運用チームに知らせるための監視システムが必要となります。cybozu.com でも以下のようにありとあらゆるものを監視するシステムを構築し日夜監視を行なっています。 今回は、そんな cybozu.com の監視(モニタリング)システムについてお話しします。 cybozu.com と障害 監視システムの設計 3つの監視 外形監視 症状監視・リソース監視 ログ監視 その他の監視 モニタリングフレームワーク 誰が監視者を監視するのか？ まとめ cybozu.com と障害 まずは、監視対象である cybzou.com について説明します。
Chef使おうとしてるけどChefいろいろつらい． 具体的には以下がつらい． 独自概念多い chefのクライアントを対象ホストに入れなければならない knifeとか覚えないといけない外部ツールがある 最初からディレクトリ構成がわいわい (rails newしたときのあのきもち） 公式ドキュメントの量が多いかつわかりにくい 以前にmiyagawaさんのpodcast を聞いてたらnaoyaさんがAnsibleっていうシンプルなプロヴィショニングツールがあるっていう話をされていたので，使ってみた． AnsibleWorks | Radically simple IT orchestration Ansible 触ってて感じるイメージは，ChefがRailsでAnsibleがSinatraな感じ． ディレクトリ構成がない (一応大規模運用を考えたディレクトリ構成のベストプラクティス Best P
Munin の監視ノードが増えてくると、ストレージの IO がボトルネックになりがち。Munin によるランダムなファイルの読み書きが主な原因。改善するためには、 rrdcached と Munin を連携する方法が手軽で確実な方法です。Muninサーバの処理が重いなと思ったら、SSD など高速ストレージを導入する前に、まずは rrdcached の導入がおすすめです。 記事内容は、rrdcached のメリット（1台で300ノードまでの監視に対応）と、RHEL5 で導入したときの手順メモ、そして rrdcached の効果を知る為の rrdcached プラグインの導入方法です。 ■rrdcached を何故使うのか？ Munin は収集データを RRD ファイルに格納し、グラフ描画時に再び参照します。このとき、ストレージに対する読み書き(IO)が増えます。 とりわけ、負荷になりがちなの
ミラクル・リナックスは2013年6月27日、オープンソースの統合監視ソフトウエアである「Zabbix」と「Nagios」を利用した複数の監視サーバーを一括監視する「Hatohol（はとほる）」をオープンソースソフトウエアとして公開した。また、Hatoholの開発などを行うコミュニティ「Project Hatohol」を設立した。 Hatoholはミラクル・リナックスが独自に開発したもの。複数のZabbixサーバーを一元管理することで、監視対象の規模に応じてZabbixサーバーを拡張できるとしている。またそれぞれの独立したZabbixサーバーで動作しているため、いずれかのZabbixサーバーで障害が発生しても他のZabbixサーバーに影響を与えないという。
先日、GitHub に Munin のデータを取得する CLI を公開しました。 muninwalk and muninget – GitHub https://github.com/zembutsu/muninwalk 今日のポストは、Munin についてと、コミットした muninwalk と muninget の概要。そして、簡単なチュートリアルです。使い方だけが知りたい場合は、後半をご覧くだしあ。 muninwalk および muninget は、コマンドラインで munin-node から、手軽にデータを取得出来るツールです。 ＜実行例＞ $ muninwalk localhost load localhost::load.load = 0.21 ◆munin とは？ Munin というリソースモニタリング用のツールはご存知ですか？ Munin は、サーバのリソース推移の監視に特
とりぐらふは複数のサーバ情報を一元的に管理し、その運用状態もモニタリングできるソフトウェアです。 Webサービスが大きくなっていくのに従って、サーバの台数も増えていきます。そうしたサーバ群の管理については企業独自の取り組みがいろいろ行われていますが、オープンソースとして公開されたのがとりぐらふです。 トップページです。GitHubのアカウント認証でログインできます。 アクティビティです。ログも確認できます。 提供しているサービスの一覧。 編集できます。MuninのURLを設定するようになっています。 ロールの設定です。 ホストの一覧です。 ホストの詳細画面です。 とりぐらふは複数のサーバのステータス、提供しているサービスを一つの画面で管理できるソフトウェアです。デプロイ対象のホスト管理も行い、Capistranoなどと連携します。一定数以上のサーバ管理を行うようになったら立ち上げたいソフト
ベストセラーとなった「SNMPによるネットワークモニタリング」を刷新する特集が登場。SNMP入門のバイブルとして、再びリファレンスとなるよう最新バージョンを元として1から10までを語っていく。 すべて表示 新着記事 関連記事 関連リンク 新着記事 第7回 RRDtoolでグラフ化モニタリング SNMPを使った機器のモニタリングには、統計を把握するためにグラフ化させることが一般的だ。今回の記事では、RRDtoolとフロントエンドツールを使って視覚化させる方法を解説しよう。 （2007/5/30） 第6回 サーバ異常をSNMPで通知させるには SNMPでサーバリソースを監視するとさまざまな状況を把握することができる。異常となる予兆をとらえることができ、その予兆はメールなどで受け取ることが可能だ。 （2007/5/25） 24時間稼働のために――サーバ管理者が知っておくべき自動復帰ノウハウ 24
chef-server は仕組みが大げさでインストールも大変だし、10〜20台ぐらいなら chef-solo と capistrano を組み合わせればいいよね？（同案多数） Capistranoとchef-soloを組み合わせて使う | ひげろぐ capistrano + chef-soloで構成管理する - delirious thoughts 実はこれまでもずっと、適当に書き殴った shell script で rsync && chef-solo 実行というのをやっていたのですが、複数の json をいい感じにマージして適用したかったので、capistrano で書き直してみました。 fujiwara/chef-solo-with-capistrano · GitHub 方針 cookbook などのファイルの同期は rsync で 共通で使用する json とホストごとにそれを上
fluentdでNagiosアラートの集約 « ボーダーレスライフ
RRDなどにメトリクスを書き込んでグラフを生成している場合、標準的なサーバだとCPUかHDDがボトルネックになって、Nagiosサーバ1台あたり持てるクライアントは、300台〜700台くらいが限度といったところでしょう。 数万台のサーバを管理する様な環境では、Nagiosサーバ単位で情報が分断されてしまうので、関連するシステム（特に他部署が管理している様な）の状況が把握しづらいことがよくあります。 全サーバの状況を横断して検索、リスティングができると、障害時の対応時間を短縮できるし、統計情報の取得ができるとメトリクスdrivenな運用＆開発もしやすくなり、プロダクトの質も向上するだろうということでfluentdでやってみました。とは言ってもまだ始まったばかりなのですが、下の図の様な構成で、Nagios上のイベントログをfluentdがtailし、必要なイベントログをfluentd serv
7. Chefを使って、急なサーバ増設も、 普通にこなせるようになってきました！ http://www.flickr.com/photos/jonathanbeard/3307862620/ 7 8. 「Chef」とは • サーバの構築作業 システム の ール – システムのあるべき状態を設定する • オープンソース、Ruby製 • 匏用実 – 37signals – Engine Yard – Rackspace hosting – etc… http://www.flickr.com/photos/jonathanbeard/3307862620/ 8 9. サーバ構築・システム 自動化の厧勥勯 • 手作業では、そもそも時間がかかる – 数十台、数百台のレベルになると・・・ – 叓割のサーバ とに が発生したりとか サーバ匐 までのリード イムが くなることで 機会損失を発生させること
GT Nitro: Car Game Drag Raceは、典型的なカーゲームではありません。これはスピード、パワー、スキル全開のカーレースゲームです。ブレーキは忘れて、これはドラッグレース、ベイビー！古典的なクラシックから未来的なビーストまで、最もクールで速い車とカーレースできます。スティックシフトをマスターし、ニトロを賢く使って競争を打ち破る必要があります。このカーレースゲームはそのリアルな物理学と素晴らしいグラフィックスであなたの心を爆発させます。これまでプレイしたことのないようなものです。 GT Nitroは、リフレックスとタイミングを試すカーレースゲームです。正しい瞬間にギアをシフトし、ガスを思い切り踏む必要があります。また、大物たちと競いつつ、車のチューニングとアップグレードも行わなければなりません。世界中で最高のドライバーと車とカーレースに挑むことになり、ドラッグレースの王冠
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
