「入門 監視」社内輪読会から1年経過して 〜参加メンバーの意識の変化と今後〜 - BASEプロダクトチームブログ
はじめまして。 BASE株式会社 SRE Groupに所属している富塚(@tomy103rider)です。 先日、弊社CTOが 「もうさばき切れない」アクセスが激増したECプラットフォームにおける負荷対策 https://devblog.thebase.in/entry/bsucon という記事を公開しました。 社内ではこのアクセス激増をきっかけに「サービスの監視をどうしていくか」「サービス/システムのアラートに対してのアクションはどうあるべきか」といったような監視に関する話題も改めて盛り上がっています。 そんな中でふと1年くらい前にBASE BANK 株式会社の東口 (@hgsgtk)が社内で主催した「入門 監視」輪読会に参加したことを思い出し、その輪読会がどういう会だったかなど、改めて輪読会を振り返ってみようと思います。 「入門 監視」輪読会の目的は何だった？ この輪読会を開催するにあ
Mackerelにおける Cloud Nativeへの取り組みと チームへ与えた変化 / CloudNative Days Tokyo 2020
Mackerelにおける Cloud Nativeへの取り組みと チームへ与えた変化 / CloudNative Days Tokyo 2020
次世代デジタル保険を支える監視・通知の技術
監視・通知の仕組みの全体像また、弊社では Terraform を用いて IaC ( Infrastructure as Code ) を実現して、各AWSアカウント環境の状態をコードで一元管理していますが、 Datadog の監視項目も Provider が用意されているため、Terraform で管理をすることが可能です。現状はすべての Datadog の監視項目がコード化されているわけではないですが、こちらは随時対応を行っていきたいと思っています。 外形監視外形監視は、WebサイトやAPIエンドポイントが正常に動作していることを、定期的に特定のURLに対して問い合わせをして、期待されたステータスコードや要素を返すことを監視することを目的とします。 弊社では Datadog の Synthetic Monitoring という機能を利用して監視を行っていますが、この機能の特徴としては W
次世代監視の大本命！ Prometheus を実運用してみた - Qiita
こんにちは！freeeでインフラゾンビをやっている @sugitak です。ゲームではレベルを上げて物理で殴る派です。 freee ではたまにインフラエンジニアの数が減るのですが、その減ったインフラエンジニアはインフラゾンビへと進化し、社内を闊歩します。インフラゾンビは主に開発チームに所属して、アプリっぽいインフラの仕事をインフラからアプリ側へと持っていきます。デプロイとか、Dockerとか、Jenkinsとかの、いわゆる DevOps 系のところですね。こうすることで開発者は手を出せるものの自由度が増えるし、インフラはより本来のインフラとして純度を上げていける、 so, win-win ってわけです。 さて、そんなわけで監視です。freee Engineers Advent Calendar 2016の9日目の記事として、 Prometheus による監視が最高なのでみんなもっと使おうと
スタートアップ向け監視設計入門::Innova EngineerBlog
Image from Datadog はじめに こんにちは。エンジニアのみかみです。DevOpsを推進するための、ビルドツール、CI、監視系の設計や管理ツールの作成を担当しています。インフラエンジニアっぽいですが、実際はチーム内の困ったを拾うキャッチャーで、よろず相談屋をやっています。 さて、今回は監視についてのお話です。 最近、安価で柔軟に使えるクラウドサービスが提供され、新規サービスの開発が容易になりました。 しかし、サービスをリリースしたものの、ある程度サービスが認知されてくると突然システムが故障したり、予期せぬ不具合が突然発生し困ったことはないでしょうか？ サービスの稼働率を100％保証することは技術的に難しく、サーバー稼働率99.9％を保証しているサービスが多いですが、この数字でも年に9時間は停止する計算になります。100%の動作保証が難しいのならば、何時停止したとしても、すぐに
Google Cloud Monitoringを試してみた #gcpja
ども、takiponeです。 先日、長らくクローズドベータだったGoogle Cloud Monitoringがオープンベータとして公開されました。 Google Cloud Monitoringは、Stackdriver社をGoogleが買収して得たプロダクトで、元々AWSの監視を得意とするSaaS型の監視サービスでした。その辺りがGCPにどう統合されているのかなど、諸々解説してみます。 セットアップ まずは、Cloud Monitoringをセットアップし実際に使ってみます。 GCPの管理画面であるDevelopers Consoleのメニューから[監視] - [ダッシュボードとアラート]を選択します。サブタイトルのようについているPowered by Stackdriverがイイですね。初期状態ではMonitoringが無効になっているので、[Monitoringを有効にする]ボタン
監視アーキテクチャ(Sensu,Pingdom,Mackerel,StatusPage.io,PagerDuty)についてまとめてみる(2014年12月版) - Glide Note
Sensu Advent Calendarに便乗して、Kaizen Platform, Inc.の2014年12月現在の監視アーキテクチャの話をちょっとしてみようと思う。 モニタリング領域 サービスを監視している領域 Pingdom Pingdom - Website Monitoring 外部ネットワークからのサービスの死活監視。アメリカ、ヨーロッパ、アジアなどの拠点からサービスの死活監視が出来るため、特定の地域からアクセス出来ない場合なのが検知出来る。 後述するstatuspage.ioとの連携で、障害を検知すると、サービスのステータス状況が自動で変わるようになっている Sensu Sensu | The open source monitoring framework. 監視フレームワーク サーバを内部ネットワークから監視するために利用 サーバのプロセス監視、サーバ間の疎通監視、エラ
2分で設置完了！Uptime Robotで今すぐ始めるネットワーク監視 | 株式会社LIG(リグ)｜DX支援・システム開発・Web制作
こんにちは。ディレクターのエリカです。 突然ですが、Webサイトが完成するのはいつだと思いますか？ サーバ上ですべての機能が動き出したとき？ サイトを公開しプレスリリースを出したとき？ トラフィックが増えてPVが目標値に達したとき？ このように改めて考えてみると、Webサイトには完成がないということに気づきます。 だからこそ、ユーザに公開され長い長い運用フェーズがはじまると、気になってくるのがサーバなどのネットワークトラブルです。ネットワークトラブルが原因で、せっかくのPVやCVを逃したくはないですが、素人にはなかなか難しいのも事実。 「よくわからないから、ネットワークやサーバのことは全部専門の会社に任せきり」というWeb担当者も多数いらっしゃると思いますが、そこでおすすめしたいのが、「Uptime Robot」というネットワーク監視ツールです。 とても便利でしたので、今回はその詳細を解説
Nagiosによる企業向け監視システムの構築 第1回「監視サーバ構築」
はじめに 本ブログでは、Chefおよび、Vagrantを用いた仮想インフラの構築について取り上げてきました。今回は、構築した仮想インフラの障害監視を行う監視システムの構築方法を２回に分けて解説します。第１回は、サーバー監視ツールのNagiosのインストールから、監視対象サーバの設定方法を解説します。 なお、構築に必要なソフトウエアは、Chefを用いたLAMP開発環境の構築方法～仮想環境構築編を参考にして、インストールして下さい。また、全ての構築作業は、Chefを用いて行います。 監視サーバの構築 構築する監視サーバのベースとなる仮想マシンを作成し、HTTPサーバをインストールします。 Boxの初期化 ベースとなる仮想マシン(Box)の初期化を行います。 $ mkdir -p ~/vagrant/nagios-server && cd ~/vagrant/nagios-server $ va
CPU、メモリ、ディスク使用量…ひと目でわかるモニタリングツール『Glances』コマンド | 俺的備忘録 〜なんかいろいろ〜
以前、モニタリングコマンド『nmon』を紹介したが、今回は同様に便利な『Glances』というコマンドについて紹介する。 このコマンドの特徴としては、多くの情報をひと目で確認出来るということだ。 さて、それでは早速インストールをしてみよう。 以下のコマンドを実行する事で、インストールが行える。 sudo apt-get install python-pip build-essential python-dev sudo pip install Glances sudo pip install PySensors インストール完了後、以下のコマンドで『Glances』を実行する。 glances ぱっと見で多くの情報を参照出来て、かなり便利なコマンドだ。 これはいいね！！ 他には、どんな事が出来るんだろう？ヘルプの内容を見てみよう。 test@test-vm-ubuntu:~$ glance
サーバの負荷や使用率などを見るコマンドの一覧 - [Linux [Red Hat/CentOSなど]/サーバー] ぺんたん info
サーバの負荷などの監視に使うコマンドいろいろ [参考記事] ログをリアルタイムに表示させて監視する方法 [参考記事] PHPでロードアベレージを表示させる方法 [参考記事] Cacti RRDToolを利用したサーバ監視ツール ロードアベレージ(CPU負荷状態) w または uptime ディスク使用率 df メモリ使用状況 free 起動中のタスク ps aux ロードアベレージ、メモリ使用状況、タスク(負荷順) top ディスクI/O iostat リアルタイムで見るには watch iostat iostatを利用するにはsysstatのインストールが必要です。 yum install sysstat その他いろいろ sar -u 3 10 sarとはSystem Admin Reporterの略です。 CPUやネットワーク、メモリ、ディスクなどの情報を見ることができます。 ログは日
監視システムをSensuに刷新した | Ore no homepage
データベースが落ち着いているので、その間に別のことに着手。 チームの監視システムがmonっつー超レガシーシステム。知っている人もいるかもしれないが、monはperl製のシンプルな監視システム。古くからあるものなんだけど「mon perl」で検索すると「もしかして: man perl」とgoogle様にも何だっけソレ？と言われてしまうかわいそうな奴(「mon monitoring tool」だとちゃんと出てくる)。なのでまあこの際だから俺が葬り去ってやる。導入したSensuのバージョンは0.12.6。GW前くらいから運用しているが今んとこ問題ない。まだ運用期間短いね。 割と長文になっちまったので、目次をば。 0. sensu概要 1. なぜsensu？ 2. インストール 3. コンフィグの配置 4. プラグインについて 5. API 6. デバッグ 7. 今後の展望 0. sensu概要
Sensuを使ってクラウド環境の監視を効率よく行おう - UNIX的なアレ
AWSなど様々な環境でサーバを管理してくると、すべて同一の監視ツールを使うのがなかなか難しくなってきます。そんなこともあり、私も定期的にいろいろな監視ツールを試しています。 http://nanapi.co.jp/blog/2013/09/11/monitor_nanapi_servers/ nagiosとクラウドの相性が悪い！ 監視するには様々なツールがありますが、その中でも特に有名なツールはnagiosでしょう。古くから使われているツールで、プラグインも数多くあり様々な監視を行うことができます。 クライアント側にnrpeをインストールすることで、各ホストの詳細の状態まで監視することができますし、うまく活用すればかなり細かい監視までできます。 しかし、AWSのようなクラウド環境で使うには非常に使いづらいです。というのも、nagiosはサーバ側にどのホストを監視するのかという情報を持たなけ
dstat + fluentd + Elasticsearch + kibana でサーバモニタリングする - blog.nomadscafe.jp
普段はサーバのメトリクス可視化のためにcloudforecastを使っていますが、某案件用に数秒単位で数十台のサーバのメトリクスを表示したいので、記事タイトルのような構成を作ってみた。 dstatでとった各種値の他に、nginxとmemcachedの情報も合わせて表示させています。 セットアップ もろもろのセットアップのメモ 監視サーバ まず、監視サーバにElasticsearchとkibanaをいれる。環境はCentOS6 $ sudo yum install java-1.7.0-openjdk $ sudo rpm -Uvh https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-1.x.x.noarch.rpm Elasticsearchは特に設定なく起動 $ sudo service
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Docker監視環境 - Part1: cAdvisor, collectd, Riemann, InfluxDB, Grafana
ヌーラボが Mackerel に移行した３つの理由
ぱっと見でわかりやすいネットワークモニタリングコマンド『iftop』 | 俺的備忘録 〜なんかいろいろ〜
qpstudy 2014.04 ミドルウェア設計の勘所
http://paperboy-all.github.io/docs/nagios/learning.html