.ioドメイン不調に伴うMackerelの死活監視アラートの誤報の発生とそれに対する対応について - Mackerel ブログ #mackerelio
Mackerelサブプロデューサーの id:Songmu です。表題の件、ユーザーの皆様には度々ご迷惑をおかけしており大変申し訳ありません。 本件の詳細に関する説明と、今後の対応に関してお知らせいたします。 死活監視のアラート誤報に関して Mackerelでは、mackerel-agentから一定時間メトリック投稿が途絶えた事をもって、サーバーがダウンしたと判断し、死活監視アラートを発報する仕組みになっています。 現在、 mackerel.io ドメインの名前解決が不安定になっております。それに伴い、 mackerel.io ドメインの名前解決が一定期間失敗し、Mackerelへのアクセスが一時的にできない環境において、 mackerel-agent がMackerelへのメトリック投稿をおこなうことができず、Mackerelシステム側でサーバーがダウンしたと判断してしまい、死活監視のアラ
Mackerel+IFTTTで運用担当者がアラートに絶対に気づく仕組みを作る - ワタナベ書店
Mackerelアドベントカレンダー 4日目です。 昨日は@dolpenさんの「RTX1200の状態をMackerelに監視させる」でした。 qiita.com ネットワーク機器が高負荷で落ちそうとかパケットロスしたときに、グラフでどんな通信があったのかとか確認できると便利ですよね。 そのアラート気付いてます？放置してません？ Mackerelとても便利ですよね。Mackerelサーバにクライアントから情報をプッシュするタイプの監視サービスなので、 自宅サーバと外部のサーバを1つの監視に集約できたり、 監視サーバの監視問題(監視サーバの監視はどうしたらいいか)もMackerelに監視を任せることで解決しました。 しかし、監視がどんなに便利になっても、アラートがなった時に対応が出来なければ意味がありません。 導入当時は、監視がこんな簡単にできるなんて便利だなぁとしみじみ思いつつ、アラートに対
Mackerelの監視設定も｢コード｣に落としこもう! - Masteries
前々から書こうと思ってて, すっかり忘れてたので, 書きます! Mackerelの監視 Mackerelでは, ホストの状態(CPU, メモリ, ファイルシステムの利用率とか, Mackerelと繋がっているかとか...)やURLの死活などを監視することが出来るのですが, 8月末に監視設定APIがリリースされ, これらのパラメータをAPI経由で実施出来るようになりました. というわけでReactioの開発チームでも, 早速このAPIを利用して, 以下のような仕組みを作ることで, Mackerelの監視パラメータを"コード"で管理するようにしました. 仕組み Reactioには, 開発者支援ツールが詰め込まれた｢Reactio-HQ｣というリポジトリがあるのですが, そこにMackerelの監視設定ファイルを用意しました. ちなみにReactioの開発者支援ツールは, Reactioそのもの
成長し続けるインフラの�安定運用事情
『ユーザーストーリーマッピング』 出会いと適用 / User Story Mapping encounter and application
Ansible + Mackerel APIによる1000台規模のサーバオペレーション - ゆううきブログ
Ansible と Mackerel API を組み合わせて、1000台規模のサーバ群に対して同時にパッケージの更新やその他のサーバオペレーションのための方法を紹介します。 タイトルに Mackerel とありますが、それほど Mackerel に依存しない話です。 (AnsibleとDockerによる1000台同時SSHオペレーション環境 - ゆううきブログに続編を書いています。) 背景 社内では、サーバ構成管理ツールとして Chef を使用しています。 Chef Server は運用が大変なので使用しておらず、knife-solo と Mackerel APIを組み合わせてホストと Chef role とのマッピングに Mackerel のロール情報を用いています。 また、Mackerel の Ruby クライアントを利用して recipe 内で API を叩いて、Mackerel か
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
