カテゴリー「server」

fluentdとelasticsearchを長時間つないでいると、

「Cannot get new connection from pool.」というエラーが出る。

これが出ると、fluentdを再起動しなければならなかった。

そのため、logrotateでfluentdを再起動して、この問題を回避していた。

この現象が出るfluentdのプラグインのバージョンは以下の通りであった。

(たぶん、これより古いバージョンでも出てたのでは)

  • elasticsearch : 1.1.pre
  • elasticsearch-api : 1.1.pre
  • elasticsearch-transport : 1.1.pre
  • fluent-plugin-elasticsearch : 1.9.2

 

上記を以下のバージョンに変更したところ、コネクションエラーは一切起きなくなった。

  • elasticsearch : 5.0.4
  • elasticsearch-api : 5.0.4
  • elasticsearch-transport : 5.0.4
  • fluent-plugin-elasticsearch : 1.9.5

 

念のためresurrect_afterという設定も入れてはいる。

 

一応、これで1か月以上再起動かけなくても、エラーは出なくなった。

ちなみに、elastic search本体のバージョンは5系である。

 

以上

投稿日時:2017年07月22日 23:48   カテゴリー:elasticsearch, server   [コメントがあればどうぞ]

以前の記事で、monitいいね!なんて書いたので、

monitの設定を残しておく。

なお、バージョンは5.1.4である。

 

[monit.rc]

set daemon 30

set logfile syslog

set eventqueue basedir /var/monit slots 100

set mailserver smtp.gmail.com port 587
 username XXX password XXX
 using tlsv12 with timeout 30 seconds

set mail-format {
 from: XXX@XXX
 subject: Monit Alert ($HOST)
 message: Monit
 ACTION : $ACTION
 SERVICE : $SERVICE
 EVENT : $EVENT
 at $DATE on $HOST.
 DESCRIPTION : $DESCRIPTION
}

set alert XXX@XXX not on {
 instance, action, exec
}

set httpd port 2812 and
 use address 0.0.0.0
 allow localhost
 allow XXX.XXX.XXX.XXX/255.255.255.0
 allow XXX:XXX
 allow XXX:XXX read-only

include /etc/monit.d/*.rc

monit.d以下のファイル。

[disk.rc]

check device root with path /
if space usage > 80% for 5 times within 15 cycles then alert
if inode usage > 90% then alert
if space usage > 95% then stop

[net.rc]

check network eth0 interface eth0

[system.rc]

check system XXX
if cpu > 80% for 5 cycles then alert
if memory usage > 90% for 5 cycles then alert
[mariadb.rc]
check process mariadb with pidfile /var/run/mysqld/mysqld.pid
start program "/usr/bin/systemctl start mariadb.service"
stop program "/usr/bin/systemctl stop mariadb.service"
[maxscale.rc]
check process maxscale with pidfile /var/run/maxscale/maxscale.pid
start program "/usr/bin/systemctl start maxscale.service"
stop program "/usr/bin/systemctl stop maxscale.service"

ほんとはもっとあるけど、

重要なもののみとしました。

 

ポイントとしては、

「データを保持するものは、安易に再起動をかけない」

というところでしょうか。

mariadbについては、今回レプリケーションを組んでいる関係上、

落ちた場合の即再起動が、逆に悪影響を及ぼす可能性があるためです。

 

あとは、うまいこと通知をいれること、

monit自体のプロセス監視などをいれておくことも大事です。

現状、以下2つのcron処理において、

  • monitプロセスの死活監視および再起動
  • monitの再監視設定

を行うようにしています。

*/5 * * * * /usr/bin/pgrep "monit" || /usr/bin/systemctl start monit > /dev/null 2>&1
7 * * * * /usr/bin/pgrep "monit" && /usr/bin/monit monitor all > /dev/null 2>&1

 

やはり、m/monitと連動させたいな。。

 

投稿日時:2016年12月26日 23:48   カテゴリー:server   [コメントがあればどうぞ]

以前の記事でnginxのIPv6対応を書いた。

しかし、設定上、


ipv6only=on

という記述は、1度しか書けないため、

virtualhostで複数運用している場合に、この設定は邪魔となる。

 

virtualhostで運用する場合が多いので、

最終的には以下のようにすればよいのではないだろうか。

 

/etc/nginx/nginx.conf

http {
    :
    :
    # serverディレクティブは書かない
    include /etc/nginx/conf.d/*.conf;
}

 

/etc/nginx/conf.d/default.conf

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name localhost;
    :
    :

 

/etc/nginx/conf.d/your-ssl-vh.conf

server {
    listen                  80;
    listen                  [::]:80;
    listen                  443 ssl;
    listen                  [::]:443 ssl;
    server_name             your-ssl-vh;
    ssl_certificate         /etc/pki/tls/certs/server.crt;
    ssl_certificate_key     /etc/pki/tls/certs/server.key;
    :
    :   

 

このように記載しておくと、your-ssl-vhホストでは、

ipv4、v6の、non-sslまたはsslでのlistenとなる。

non-sslサイトを生きにしつつ、sslも併用し、

念のためipv6対応も入れたいというケースはこのような対応となるだろう。

 

以上

投稿日時:2016年10月16日 23:52   カテゴリー:nginx, server   [コメントがあればどうぞ]

muninでMariaDB10.0.4を監視してたら、

情報がほとんどあつまっていなかった。

 

munin自体はepelからインストールしたのだが、

これに内包されている「mysql_」プラグインはMySQL5.1レベルのものまでしかサポートしていないため、

以下にあるファイルで上書きする必要がある。

 

https://github.com/munin-monitoring/munin/blob/8abb3faf7865af125ecc18b4feece35c59c90fd9/plugins/node.d/mysql_.in

 

このファイルで上書き、

1行目の


#!@@PERL@@


#!/usr/bin/perl

に直したら、MariaDB10.0.4でも問題なく動いた。

 

以上

投稿日時:2016年07月29日 23:20   カテゴリー:mariadb, rdb, server   [コメントがあればどうぞ]

monitというとプロセス監視をしてくれるだけのイメージがあったが、

深く触ってみると、こいつはすごいなと思った。

基本的にmonitあれば大半のことは事足りると思う。

ちなみに環境は、centos7で、monitはepelレポジトリからインストールしました。

 

monitの便利なところとして、以下があげられる。

  • プロセスの死活監視(ダウンしてくれれば、勝手に起動してくれるし、勝手に起動しない形も可能。DBなんかは勝手に起動して問題あるケースもあるよね?)
  • 閾値と発砲の関連付け
  • SMTPを使った発砲機能(リトライ機能もある)
  • web管理画面

さらに、m/monitをつかえば、情報の集約も可能となる。

(有料だけど、買い切りでそれほど高くないのは、良心的)

 

クラウド環境では、かなりの監視ツールがあるが、

こねたことはできないので(できても意外に金がかかる。。)、

monit(もしくはm/monit)を併用すると、結構安心して夜も眠れる環境が出来そう。

 

どこかで、monitの設定を書いてみようと思う。

 

以上

投稿日時:2016年07月11日 00:46   カテゴリー:server   [コメントがあればどうぞ]

glibcにバッファオーバフローの脆弱性があったようなので、

アップデートすることにした。

 

centos7では、以下のバージョンがパッチ適用済みらしい。

2.17-106.el7_2.4

 

そして、updateが完了したら、

再起動する必要があります。

 

[参考]

https://jvn.jp/vu/JVNVU97236594/

 

以上

投稿日時:2016年02月19日 16:05   カテゴリー:server   [コメントがあればどうぞ]

td-agentはプラグインが豊富だけど、

結構品質(というか、どこまで想定して作られているか)がよくないものが多いように感じる。

 

OSS時代の申し子的な存在だけど、

意外にプラグインの品質が悪くて、修正してしまうケースもある。

 

本体はとても優れたプロダクトですが、

プラグインの品質は優劣が激しいので、

気をつけましょう。

 

・・・それに毎回設定で苦労してるから、

td-agentに代わるものを、akkaで作りたいな。。

 

投稿日時:2015年10月26日 17:09   カテゴリー:server   [コメントがあればどうぞ]

ちまたでは、chefやらansibleといった

インフラ構成ツールが流行っている。

 

しかし、個人的にはどっちもめんどくさい。

ドキュメントは充実しているが、

それなりに扱うには独自の書き方を習得する必要がある。

 

そこで、以下のように考えてみた。

  • ssh接続でコマンドを発行できる
  • ssh接続でファイルを操作し、部分置換・全体置換・追記ができる

以上があれば十分で、あと必要なものは、

  • 環境ごとの設定
  • サーバ用途でのグルーピング

ってくらいだろうか。。

 

そして、「冪等性」ってのを保つのは非常に重要。

 

これらを踏まえつつ、

基本的にはシェルスクリプトを作成し、

WEBベースで、実行・管理できればよいかなと思っている。

そんなツールに着手してみようかな。。

 

投稿日時:2015年04月16日 10:40   カテゴリー:server   [コメントがあればどうぞ]

どうも「バッチサーバ」というのが好きでない。

 

WEB系をやっていると、WEBサーバ(APサーバも含む)とは別に、

バッチサーバなるものを用意するケースがあるが、

これって実はあんまりいらないと思っている。

(というか、外したいと思っている)

 

確かに、WEBサーバ側の負荷と切り離して考えられるメリットもある。

しかし、自分にとってはリソースを有効活用できていない感がある。。

 

最近では、

スクリプト言語でも、WEBサーバ内にバッチ処理用のソースコードを持つことが多々ある。

これは、どのサーバでも代替実行が出来るようにするという狙いからのものであるが、

実際はWEBサーバは複数あるケースが多く、

夜間などのアクセスが少ない時間帯で、

複数サーバで、一気にバッチを実行してしまうほうが処理が速く終わってよいと思う。

 

javaなんかでは、APサーバ内の1スレッドとして、

バッチ処理を動かすケースなんかもあるだろう。

 

ということで、こんな風にできたらいいなと思うバッチ処理をまとめてみる。

  • WEBサーバ(APサーバも含む)の1スレッドとしてバッチが実行できる
  • 手動でも実行できる
  • 同一のバッチが複数サーバで動いて欲しくないケースは排他制御をかける
  • 空いているリソースを見つけて分散できる
  • さらに、実行結果を1か所で確認できる

という感じ。

 

zookeeperなどの組み合わせることで、

上記を実現できるが、

インフラがやや複雑になり、プログラマーの管理ではなかなか厳しい。。

 

javaではcron4jなどがあったり、

nodeではcronのモジュールがあったりするので、

上手いことスレッドとして、組み込みつつ、

外側からも実行可能で、分散的に、必要あらば排他的に、

そして、出来るだけ簡素に。

そんなバッチが組めるような仕組みを考えてみたい。

 

投稿日時:2015年04月14日 17:01   カテゴリー:server   [コメントがあればどうぞ]

前回、awsにtd-agentを入れて、

s3→redshiftとの連携を図ったけど、

さらにうまくやる方法を記載しておく。

 

●カラムを超えた場合のデータについて

TRUNCATECOLUMNS

オプションを付けておくことで回避できる

 

●redshiftに取り込まれた日時を登録する方法

テーブル側にカラムを追加して、jsonpathとのカラムミスマッチを防ぐ

 

具体的には、

CREATE TABLE test_access_logs (
    date            datetime sortkey,
    ip              varchar(64),
    header          varchar(256),
    code            varchar(16),
    size            varchar(16),
    aaa             varchar(64),
    bbb             varchar(128),
    ccc             varchar(128),
    second          varchar(16),
    insert_date     datetime  not null default convert_timezone('JST', getdate())
);

上記みたいに、insert_dateを追加する。

 

ただし、このまま取り込むと、

{
    "jsonpaths": [
        "$['date']",
        "$['ip']",
        "$['header']",
        "$['code']",
        "$['size']",
        "$['aaa']",
        "$['bbb']",
        "$['ccc']",
        "$['second']"
    ]
}

カラムのミスマッチがおきてしまう。

 

これを回避するために、

# COPY test_access_logs
  (date, ip, header, code, size, aaa, bbb, ccc, second)
  FROM 's3://MY-BUCKET/logs/httpd/201501/26/'
  credentials 'aws_access_key_id=XXX;aws_secret_access_key=YYY'
  JSON AS 's3://MY-BUCKET/logs/httpd/test_access_log_jsonpath.json'
  GZIP
  COMPUPDATE ON
  RUNCATECOLUMNS;

上記のように、カラム指定で取り込むと、

insert_dateはnullになり、defaultが適用される。

 

なぜこのような方法をとるかというと、

もし再取り込みが発生した場合に、

以前のデータを消さないで取り込むと、

重複で取り込まれてしまう。

重複を回避するには、

以前取り込んだデータを削除しなければならない。

insert_dateを登録しておけば、

以前登録したデータを検索できる。

 

ちなみに、redshift上で、日本時間を取得するには、

# select convert_timezone(‘JST’, getdate());

# select dateadd(hour, 9, getdate());

のような方法がある。

 

以上

投稿日時:2015年01月29日 11:02   カテゴリー:aws, server   [コメントがあればどうぞ]