Amazon CloudWatchの得意なこと苦手なこと:これからAWS監視を始める人へ その2 CloudWatch 2015.08.04 Amazon CloudWatchをどうやって活かすか? 前回の記事では、AWSの運用監視にAmazon CloudWatchを利用することは最も一般的なケースということを書きました。(前回:Amazon CloudWatchとは:これからAWS監視を始める人へ) かといって、監視ツールはCloudTriageを選んでおけばよい、と単純に断じてしまうのはよくない。実際に、AWSの監視も可能なツールは多く存在します。 ということで、分かりやすくするため、他の監視ツールと並べて比較してみました。 EC2を監視する場合
Zabbixで監視設定を行う前に、監視対象のサーバのどのような項目(CPU負荷やメモリ使用率など)を監視するかを検討し、設定する監視項目をまとめておきます。とはいえ、Zabbixで監視できる項目は多岐にわたりますので迷ってしまいますね。 そこでまずは、監視対象のLAMPサーバではWEBサイトが運営されていると仮定して、運営者としてこのWEBサイトに発生したら真っ先に困ることを思い浮かべてみます。 発生したら真っ先に困ること WEBサイトにアクセスできない WEBサイトの表示が遅くなり閲覧しづらくなる 他にもあるかと思いますが、WEBサイトにちゃんとアクセスができて、内容がサックと表示できていればまずは良しとします。 続いて、この「困ること」が発生する原因を考えてみます。 WEBサイトにアクセスできない原因 通信事業者のネットワーク障害なども原因として考えられますが、今回は自分で監視できる範
はじめに モニタリングサービスまとめ No.1 Site24x7 No.2 StatusCake No.3 Pingdom No.4 UPTRENDS No.5 GTMetrix No.6 DareBoost No.7 NodePing No.8 Monitoring Plus No.9 UptimeRobot まとめ おわりに はじめに 今年4月に中途で入社したインフラストラクチャーグループ所属の内河です。 最近、ジョブセンスのインフラ担当になりました。 オンプレのサーバを触りつつAnsibleのPlaybookを書いたり、AWSのリソース設定をTerraform化しています。 現在、リブセンスではサーバの監視・外形監視にはMackerelを、WebサイトのモニタリングにはNewRelicやDatadogを利用していることが多いです。 しかし、こういったサービスの移り変わりは早く、新しい
って海の向こうの人が言ってました。 私はjQueryさえあれば概ね生きていけるので全然知らないけど、 あなたは全部知ってるフロントエンドエンジニアなんだね。すごーい! 以下はFront-End Developer Handbook 2017の第三部、Front-end Developer Toolsからリンクされているツールと、その簡単な紹介です。 ドキュメントツール Dash 150以上のライブラリのAPIリファレンスを検索できる。有料、Mac専用。 DevDocs 200以上のライブラリをオンラインで検索できる。無料。 Velocity 中身はDashと同じ。 有料、Windows専用。 Zeal 200以上略 無料のオフラインドキュメント。 SEOツール Keyword Tool 検索ワードを入れると関連キーワードを教えてくれる。 Google Webmasters Search C
原資は保有していて急成長したnem(XEM)を30,000通貨ほど使いました。 気持ちとしては「値上がりすればラッキー」くらいなもので、値下がりしたり消えてしまったら「まぁそうなるよねw」で済むような額だけを投入。 100万通貨ずつ購入している理由 「100万通貨」というのは私なりの基準で、これだけ保有していれば仮に10円台まで達したら値段の上下がほとんど1円単位で推移していって、利益が加速していくからです。(落ちも加速しますが) 1円高くなれば含み益が100万円増加してくので、超ハイリターンを期待できます。 人によっては1円未満の通貨を30ビットコイン分など大量に買って大量に売る、という方法で利ザヤを稼がれていますが、流動性が悪いとこれが難しくなることから、大量買いは基本的にしません。 各通貨について DOGEは開発が中止になっているという情報を得たのですが、それでもここ最近は相場が上が
Webオペレーションエンジニアの id:y_uuki です。 2017年8月7日に、メンテナンスの完了報告及びデータ消失とカスタムダッシュボード、式監視の不具合に関するお詫びにてお知らせしたメンテナンス作業時間中のデータ消失について、本エントリにて技術的な観点から原因の詳細をお伝えいたします。 概要 2017年8月7日(日本時間)に、オンプレミスデータセンターからAWSへ、Mackerelをシステム移行するためのメンテナンスを実施しました。 メンテナンス開始時間である14:30以降のデータ同期に失敗していたPostgreSQLデータベースサーバへの意図しないフェイルオーバーが、メンテナンス作業途中の15:30に発生した結果、14:30から15:30の間に更新されたデータを消失しました。 移行作業後のアプリケーションの動作確認中に、特定時間帯のデータを消失していることを発見し、データの復旧を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く