A new tool that blends your everyday work apps into one. It's the all-in-one workspace for you and your team
突然ですが... あなたは、あるゲームプロジェクトの本番リリース2日前にサーバエンジニアとしてJOINしました。いざリリースを迎えたとき、ElastiCacheのメモリが突然危険域を超え、さらにあと2時間で枯渇しそうな状況になりました。 さて、この状況におかれたあなたは何をしますか? はじめに モバイルゲームのシステムは新しいイベントをopenするとトラフィックが2倍、3倍、時には普段の10倍以上来ることがあり、トラフィックの変動が非常に大きい特性があります。 新しいゲームのリリース時はより顕著で、想定以上のトラフィックが来ることもしばしばあります。 この記事は、あるゲームプロジェクトの本番リリース時に大規模トラフィックが来た際のサーバトラブルを題材に、 どのような観点で問題を切り分けていったのか、トラブルシュートのプロセス どのような準備(負荷テスト)をしていれば防げるのか という話をし
12/3 Mackerelアドベントカレンダー 3日目です。 昨日は @daiksy さんによるエントリでした。 プロダクトとユーザの距離感について考えてみる http://blog-ja.mackerel.io/entry/advent-calendar2015/day2 Mackerel のメール、毎回楽しく読んでます! 何したの? Mackerel 自体については、既に家の中のサーバーや VPS などを監視しており、agent 入れるだけでこんなにできるんだ、便利だなーというところで止まっていました。 何か面白いことができないかな、と思っていたら、最近買って家に導入した RTX1200 (本当はIPX) というルーターが目に入ったので、以前から気になっていた API の使い方を調べて、実際にルーターのメトリックを Mackerel に集約してみました。 RTX シリーズ、およびほかの
この記事は Mackerel プラグインアドベントカレンダー(全部CRE) の23日目です。 qiita.com soudai.hatenablog.com それでは23日目は mackerel-plugin-snmp です。 mackerel-plugin-snmpはSNMP (Simple Network Management Protocol)をつかってデータを取得し、それを可視化するSNMP専用のプラグインです。 github.com インストールと設定手順 mackerel-plugin-snmpのプラグインは先程も説明したとおりSNMPを利用します。 そのため、対象にはSNMPが利用できる設定がされていることが条件になります。 ですがSNMPを使いたい=ある程度ご理解がある前提なので割愛します。 そもそもSNMPについては良い資料が沢山あります。 例えば下記のサイトがとてもわか
検索すると Lua スクリプトを RTX にいれる方法もあるみたいだが、別途プロキシが必要みたいなので LAN 内の raspberrypi から SNMP で取得して投げるほうを選んでみた。raspberrypi には既に mackerel-agent が入れてあるので、追加の設定をするだけ。 mackerel-agent-plugins mackerel-agent は arm 版もリリースされているが、プラグインはリリースされていない。自分でビルドする必要がある。 mackerel-plugin-snmp だけあればいいので、mackerel-plugin-snmp のディレクトリで env GOOS=linux GOARCH=arm GOARM=5 go build するだけでバイナリができる。できたバイナリを raspberrypi の /usr/local/bin とかにコピー
あなたのシステムはきちんと動いていると言えますか? 本書は、システムのどの部分をどのように監視すべきか、また監視をどのように改善していくべきかについて解説する書籍です。 前半で監視のベストプラクティス、デザインパターン/アンチパターンを示して、監視の基本原則を詳しく説明し、後半でフロントエンド、アプリケーション、サーバ、ネットワーク、セキュリティの各テーマで強力な監視の基盤を設計して実装するための方法を示します。 監視対象が変化し、システムアーキテクチャが進化する中で、従来から変わらない監視の基本を示しながら、時代に合った監視の実践を解説する本書は、監視についての理解を深めたいエンジニア必携の一冊です。日本語版では、松木雅幸(@songmu)氏による監視SaaSの導入や活用方法を付録として収録しています。 正誤表 ここで紹介する正誤表には、書籍発行後に気づいた誤植や更新された情報を掲載して
トレーディングツールといえば Windows 用のソフトウェアが多く、多くのトレーダーも多数のモニターを備えた Windows を使うというのが比較的多いと思う。そんな中、 Mac を始めとする iOS や GNU/Linux の環境でどのように相場を監視したら良いだろうか。このたびトレーディング環境を整えたのでちょっと書いてみようと思う。 Mac/iPad まず Mac でのトレーディングツールといえば楽天証券が強い。 iOS で利用できる iSPEED はかなり高機能だし、それと連携して監視銘柄を共有できる MARKET SPEED for Mac もなかなか便利。 楽天証券で発注するかどうかはともかく、監視ツールとしてはなかなか良い感じですね。特に後者の MARKET SPEED はチャートや板も見やすいし、リアルタイムで監視するのにはちょうどいい。 GNU/Linux じゃあ GN
運用監視に必要な知識はOS、コマンド、そしてプログラミング~ゼロからの運用監視設計(後編)。July Tech Festa 2016 運用監視の自動化は、複雑化するアプリケーションやサービスに対して効率的かつ確実な運用監視を実現する上で、またコスト削減の意味でも重要な要素になってきています。しかし運用監視の自動化は、どのように考えて実現していけばいいのでしょうか。 (本記事は「正しく運用されているかを評価するのが監視である~ゼロからの運用監視設計(前編)。July Tech Festa 2016」の続きです。) ゼロからの監視設計 ひとつはサービスレベルの定義、もうひとつは非機能要件としてのシステム監視ですね。こういうことは以外と職場でも学校でも教えてくれなかったことです。 なぜかというと、だいたい担当部署によってみているレイヤが違うわけです。物理層を見ているところ、ネットワーク層、あるい
「Raspberry Pi 3でファイルサーバ兼iTunesサーバを作る」ではサーバ監視ツールとしてnetdataをインストールしたが、ディスク使用率の監視に難があるためZabbixに切り替えることにした。 ここでは、Raspberry PiにZabbixをインストールし、サーバの状態を表すグラフを一覧表示するダッシュボード(Screen)を作ってみる。 環境 Raspberry Pi 3 (Raspbian Jessie Lite) $ uname -a Linux raspberrypi 4.1.19-v7+ #858 SMP Tue Mar 15 15:56:00 GMT 2016 armv7l GNU/Linux $ cat /etc/os-release PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)" NAME="Raspbian GNU/
次世代 Web カンファレンスで監視について話すことになったので、ネタとしてWEB系各社で使っている監視ツールを調査中。 うちはこれ使ってるよ!!!ってのがあったら@mikedaにメンションください! Cookpad Zabbix 昔はNagios+muninだけど台数増えて性能的に破綻した ビューはそのままじゃ辛いのでmunin風に表示するのを自作 StatusCake DataDog。サービス系、サーバに紐付かない系の監視に。DashBoard便利 waker。通知用。PagerDuty高い、と言ってryot_a_raiが秒で作ったらしい Kibana imon。独自のリアルタイムなサービス稼働状況表示ツール NewRelic 試し中なもの Real-User Monitoring : JSでbeacon飛ばしてfluentd -> BigQuery。Google SpreadShee
ずっと読もうと思っていたけど読めていなかった「ウェブオペレーション」を読んだ.読んでたら週末終わってしまった! 2011年に発行された本だし結構古くなってるのかなとも思ったけど,全然そんなことなく,今読んでも目から鱗な知見ばっかりだった.確かにウェブオペレーションを取り巻く環境は広くなってたり,デファクトスタンダードな技術も推移して便利になってきているけど,マインドの部分は不変なものだなと感じた. ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE) 作者: John Allspaw,Jesse Robbins,角征典出版社/メーカー: オライリージャパン発売日: 2011/05/14メディア: 大型本購入: 10人 クリック: 923回この商品を含むブログ (50件) を見る ビジネスメトリクス メトリクスって言うと Zabbix や Mack
8. SIGKILLしたらどうなるか # systemctl status httpd httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled) Active: active (running) since Thu 2014-07-24 03:57:50 JST; 1min 21s ago Main PID: 1311 (httpd) Status: "Total requests: 0; Current requests/sec: 0; Current traffic: 0 B/sec" CGroup: /system.slice/httpd.service ├─1311 /usr/sbin/httpd -DFOREGROUND ├─1451
完全に個人の日記レベルの話ですが、コンピュータのログと通知の話を書きます。 ログといってもまぁいろいろあるわけですが、何のためにログ取ってるかというと、異常なことが起こったことが分かるように、とか異常が発生したときに原因が分かるように、とかもっと進んだ考え方でいえば異常の予兆をとらえるとか、そんな感じかと思います。 なので最初はとりあえず異常なことが起こったら分かるようにログに記録するというのが最初に一歩になります。それが出来たら異常が発生したときの原因究明がすぐできるように詳細な情報をログに残すようにして、最後に正常な処理もログに残していけば危険な予兆をとらえることができるようになるかなと。なんか書いてみたら至極当たり前っぽい感じになりました。おそらく運用をやっているエンジニアはみんな気をつけていることだと思います。 ログというのは大量に存在して価値があるものなので、記録することに価値が
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く