Skip to content

Nagiosのcheck_nrpe + check_procsでリモートプロセス監視

Nagiosのcheck_nrpe + check_procsでリモートプロセス監視 published on Nagiosのcheck_nrpe + check_procsでリモートプロセス監視 へのコメントはまだありません

Nagiosはあまり使いたくないんだけど、他にいい選択肢があまりないので、2014年になっても仕方なく使用している。

ログ監視に関しては、以前はてなブログの方に書いたけど、今回はプロセス監視。さくっと終わる予定。

リモートのプロセス監視をしたい

今回やりたいことは、リモートサーバーの特定のプロセス(例えばhttpd)が起動しているかを確認すること。

check_nrpe 及び check_procs を使う。check_nrpe に関しては、はてなの方に書いた第3回の方に少し説明が書いてあるので、そちらも参照していただければ幸い。

Continue reading Nagiosのcheck_nrpe + check_procsでリモートプロセス監視

EC2で、非LVMパーティションを拡張する

EC2で、非LVMパーティションを拡張する published on EC2で、非LVMパーティションを拡張する へのコメントはまだありません

最近だとAWS等のクラウドを使う機会が増えていて、逆に物理サーバーを使うことが少なくなってきており、以前みたいにサイジングを細かくやることが少なくなってきた。

また、随分前から多くのLinuxディストリビューションでは、デフォルトのセットアップでLVMを使うようになっているので、仮想ディスクを追加してLVMのボリューム拡張という方法で、サービスを止めずにディスク容量の拡張が可能になっている。

これだけだと「便利な時代になったね」でおしまいの話なんだけど、EC2の場合、非LVMのパーティションも比較的簡単に拡張が可能なので、それについて説明する。ただし以下の制約がある。

  • / パーティションは拡張できない
  • サービス停止は必要
  • (当然だけど)ext4等、拡張可能なファイルシステムを使用している必要がある

今回紹介する方法以外で、もっといい方法があれば是非教えて下さい。

Continue reading EC2で、非LVMパーティションを拡張する

DynamoDB + S3 + EMRでコホート分析(cohort analysis)をする(3)

DynamoDB + S3 + EMRでコホート分析(cohort analysis)をする(3) published on DynamoDB + S3 + EMRでコホート分析(cohort analysis)をする(3) へのコメントはまだありません

前回からかなり間が空いてしまったけど、今回で完結予定。

前回はHiveの話を中心に、S3に置いたファイルをHiveでどう扱うかなどについて書いた。また、第1回では全体の流れを書いたので、どんなことをやるかは詳しくはそちらを参照。

今回は、DynamoDBに書き込んでいるデータを定期的にS3にエクスポートしたり、MySQLからエクスポートしたデータに対して、EMR上のHiveからクエリーを実行して結果を取得してみる。

Continue reading DynamoDB + S3 + EMRでコホート分析(cohort analysis)をする(3)

Ubuntuで/var/lib/mysqlを移動したらエラーが

Ubuntuで/var/lib/mysqlを移動したらエラーが published on Ubuntuで/var/lib/mysqlを移動したらエラーが へのコメントはまだありません

開発環境(Ubuntu on VirtualBox)のディスク容量が少なくなってきたので、/var/lib/mysql を 別のディレクトリ ( /data の下)に移動して、シンボリックリンクを張ったんだけど、MySQL起動時に以下の様なエラーが出た。

/usr/sbin/mysqld: Can't find file: './mysql/plugin.frm' (errno: 13)
131203 18:27:23 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
131203 18:27:23  InnoDB: Initializing buffer pool, size = 8.0M
131203 18:27:23  InnoDB: Completed initialization of buffer pool
131203 18:27:23  InnoDB: Operating system error number 13 in a file operation.
InnoDB: The error means mysqld does not have the access rights to
InnoDB: the directory.
InnoDB: File name ./ibdata1
InnoDB: File operation call: 'open'.
InnoDB: Cannot continue operation.

結論から言うと、/etc/apparmor.d/usr.sbin.mysqld で、/data/mysql への権限を追加すればOK。

  /var/lib/mysql/ r,
  /var/lib/mysql/** rwk,
  /data/mysql/ r,
  /data/mysql/** rwk,

環境: Ubuntu 10.04.4 (面倒なのでアップグレードしていない・・・)

RDBMSでカレンダーデータを扱う方法

RDBMSでカレンダーデータを扱う方法 published on RDBMSでカレンダーデータを扱う方法 へのコメントはまだありません

Googleカレンダーで予定を登録したりするけど、そういうようなものをDBで扱いたい。

いくつかの方法があった

よく分からない方法(詳細は省略)

ググったらSOのこんなページが出てきたんだけど、ちょっと無駄に複雑な気がした。

毎週x曜日系の繰り返しイベントも、毎週分レコードを作成する方法

以下のように2つテーブル用意するというアプローチもいくつか見つかった。これとかこれとか。

  • イベント管理テーブル
  • イベント実施予定テーブル:イベント1回につき1レコードを格納するテーブル

例えば、1度きりのイベントであれば2つのテーブルに1レコードずつ書き込む。

また、2013/11/1以降の毎月1日に実施する繰り返しイベントの場合、管理テーブルには1レコード書き込み、2番めのテーブルには開催日毎(2013/11/1, 2013/12/1, 2014/1/1・・・・)に1レコードを書き込む。

これはシンプルな方法で、いい方法が見つからなければこれにしようかと思った。

ただ、イベントの数が最終的には100万レコードを超える予定だったので、これだとイベント実施予定テーブルが1億行を超える可能性があったので、ちょっと躊躇してた。

Continue reading RDBMSでカレンダーデータを扱う方法

DynamoDB + S3 + EMRでコホート分析(cohort analysis)をする(2)

DynamoDB + S3 + EMRでコホート分析(cohort analysis)をする(2) published on DynamoDB + S3 + EMRでコホート分析(cohort analysis)をする(2) への2件のコメント

ちょっと前回から間が空いてしまったけど、DynamoDB上のデータやその他のデータをS3に集めて、EMR上のHiveを使ってコホート分析をするという話の第2回。今回はHiveの話を中心に書いていく。

※Hiveを使うのは今回が実質初めてで、EMRについてもあまり経験は豊富ではないので、何かおかしい点などがあったらご指摘頂けると幸いです。

Continue reading DynamoDB + S3 + EMRでコホート分析(cohort analysis)をする(2)

DynamoDB + S3 + EMRでコホート分析(cohort analysis)をする(1)

DynamoDB + S3 + EMRでコホート分析(cohort analysis)をする(1) published on DynamoDB + S3 + EMRでコホート分析(cohort analysis)をする(1) への1件のコメント

コホート分析とは

定義に関してはWikipediaを見れば大体わかるかと。日本語のエントリーがないので、大雑把に説明すると、ユーザーをグループ(コホートと呼ばれる)に分割し、各コホート毎に指標(例えば、ユーザーごとの滞在時間)を集計して分析することをコホート分析(cohort analysis)と呼ぶ。

よくある質問として「セグメント分けとどう違うの?」っていうのがあって、セグメントは例えば性別とか年代とかのユーザーの属性によって分割するのに対して、コホートは登録日時、初回ログイン日時といった、ユーザーの行動を元にグループ分けするというのが違い、だと思う。

Continue reading DynamoDB + S3 + EMRでコホート分析(cohort analysis)をする(1)

Amazon RDS (MySQL)のslow query logを集計する

Amazon RDS (MySQL)のslow query logを集計する published on Amazon RDS (MySQL)のslow query logを集計する へのコメントはまだありません

RDSではslow query logはテーブルに書きだされる。

Amazon RDSのMySQLでは、デフォルトではslow query logはmysqlデータベースのslow_logというテーブルに保存される(※)。

今までの普通のMySQLであれば、slow query logを有効化するとデフォルトではファイルに書きだされて、それをmysqldumpslowで集計・解析するってのが一般的だったと思うけど、テーブルに書きだされると、それにもう一手間必要になってくる。

※以前は、slow_logテーブルに書き出す以外に選択肢は無かったと思うけど、最近はファイルに書き出すことも出来るらしい。

大まかな方針

  1. slow_logテーブルから通常のslow query logファイル形式にエクスポート
  2. mysqldumpslowで集計

slow_logをエクスポートするツール2つ

pythonのスクリプト

AWSのフォーラムのスレッド(AWSにログインしていないと見られない)で見つけたこちらのスクリプト。

mysql関連のモジュールがないと動かないので、今回は使用せず。

シェルスクリプト

MySQL Performance Blogの記事で紹介されていたこちらのツール群。そこにexport-slow-log-tableというスクリプトがあるので、それを使う。先頭に以下の行を追加して、

#!/bin/bash

.my.cnf にホスト名、ユーザー名、パスワードを以下のように記載して、

[client]
host=xxx.yyy.ap-northeast-1.rds.amazonaws.com
user=awsuser
password=secretpassword

スクリプトを実行すればOK。

その後

あとは通常通り、エクスポートしたファイルをmysqldumpslowで集計する。

集計が終わったらslow_logテーブルの内容は不要だと思うので、以下のストアドプロシジャでローテートしておく。

CALL mysql.rds_rotate_slow_log;

まとめ

Amazon RDS (MySQL) では、デフォルトではslow query logはslow_logというテーブルに書き込まれるので、それをファイルにエクスポートしてmysqldumpslowで集計する方法を紹介した。で、その結果を利用してボトルネックの調査・分析をする、という流れ。

slow query logを定期的に確認してパフォーマンスを改善させる運用フローを作っておくと、システムの規模が大きくなった時にも安心。

Amazon EC2のホスト名

Amazon EC2のホスト名 published on Amazon EC2のホスト名 へのコメントはまだありません

自分用メモ。

Amazon EC2だとサーバーを再起動するとIPアドレスが変わる。ちょっとググっていくつかいい方法を見つけた。

  • 自動でDNSに登録(これとかこれ
  • プライベートIPを自動的にhostsに登録(

EC2のメタ情報は色々あるみたい(参考1)。

 

postfix管理用コマンド

postfix管理用コマンド published on postfix管理用コマンド へのコメントはまだありません

自分用メモ。

postfixの管理系コマンド。

キューの確認

# /usr/sbin/postqueue -p

メールの中身を確認

# postcat -q [キューID]

キューの削除

# /usr/sbin/postsuper -d [キュー ID]