javaからのmail送信ですが、
いろいろ情報が混在しております。
ただ、現時点で、
pom.xmlに以下を記載すれば、
javaSEでも動きます。
<dependency> <groupId>javax.mail</groupId> <artifactId>mail</artifactId> <version>1.5.0-b01</version> </dependency>
以上
アーカイブ「2015年01月」
前回、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());
のような方法がある。
以上
awsにtd-agentを導入して、
httpのアクセスログと、phpの任意のログを、
td-agent -> s3 -> redshift
の流れで投入してみた。
awsのEC2ではtd-agentのバージョン2の導入が大変なので、
バージョン1を導入してみた。
インストールは公式ドキュメントにある通り、以下です。
$ curl -L http://toolbelt.treasuredata.com/sh/install-redhat.sh | sh
※v2はcentos7での動作は確認しましたが、awsではv1を利用
いろいろ情報が混在していたのですが、
S3プラグインは最初から入っていて、
フォーマットはjsonでS3に送信することが可能です。
こんな感じ。
/etc/td-agent/td-agent.conf
<source>
type tail
path /var/www/test/logs/access.log
tag apache.test.access
pos_file /var/log/td-agent/test.access.log.pos
format /^\[(?<date>.*?)\]\[(?<ip>.*?)\]\[(?<header>.*?)\]\[(?<code>.*?)\]\[(?<size>.*?)\]\[(?<aaa>.*?)\]\[(?<bbb>.*?)\]\[(?<ccc>.*?)\]\[(?<second>.*?)\]$/
</source>
<match apache.test.access>
type s3
aws_key_id XXX
aws_sec_key YYY
s3_bucket MYBUCKET
s3_endpoint s3-ap-northeast-1.amazonaws.com
path logs/httpd/
buffer_path /var/log/td-agent/httpd/test-access.log
time_slice_format %Y%m/%d/test-acccess.log.%Y%m%d%H%M
retry_wait 30s
retry_limit 5
flush_interval 1m
flush_at_shutdown true
format json
</match>
※httpdアクセスログのフォーマットは、
LogFormat “[%{%Y-%m-%d %H:%M:%S %Z}t][%h][%r][%>s][%b][%{X-AAA}i][%{X-BBB}i][%{X-CCC}i][%T]” hoge
です。
でもって、S3には
test-acccess.log.201501270938_0.gz
こんな感じのログが保存されている。
中身は、
{“date”:”2015-01-27 09:38:10 JST”,”ip”:”182.118.55.177″,”header”:”GET / HTTP/1.1″,”code”:”200″,”size”:”11″,”aaa”:”-“,”bbb”:”-“,”ccc”:”-“,”second”:”0″}
みたいな感じ。
んでもって、
s3上にlogs/httpd/test_access_log_jsonpath.jsonってファイルを作成しておく
{
"jsonpaths": [
"$['date']",
"$['ip']",
"$['header']",
"$['code']",
"$['size']",
"$['aaa']",
"$['bbb']",
"$['ccc']",
"$['second']"
]
}
そして、テーブルを作成しておく。
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)
);
この状態でredshift上から、
# COPY test_access_logs 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;
ってやれば、あらかじめ作成しておいたテーブルにデータが突っ込まれる。
上記のcreateでは、圧縮オプションはつけていないが、
繰り返しが多い項目に圧縮オプションつけておくと、
かなり削減になる。
【参考】
1000万件のデータを突っ込んだ際、元容量の70%くらいになった。
（あくまで一例ね。）
だた、アクセスログなんかは、比較的繰り返しが多い項目もあるので、
その辺は効果的にやるとよいかもね。
websocketにおいて、
node.jsでpm2を使う際の問題点をまとめてみる。
バージョンは、
＜node.js＞
v0.10.xx
＜pm2＞
v0.11.xx
v0.12.xx
上記の場合、pm2のバージョンに関わらず、
- windowsでは使えない
- clusterモードで再起動（restart）を行うと、ポート開放されない（→killする必要あり）
- GodDaemonを起動したユーザ以外では操作不可能（pm2 listでもGodDaemonが起動するので要注意）
- 再起動の抑制オプションがない
という感じです。
clusterモードの最悪な点として、
１．アプリが落ちる⇒２．再起動⇒３．ポート開放されずにアクセス不可能
となる点かなと。
これが4プロセス起動していたら、
1プロセスのダウンが全プロセスに影響すること。
つまり、
pm2 start app.js -i 4
なんてして、4プロセス起動しても、
1プロセスダウンすれば、もうおしまい。
1つのプロセスの再起動が、他プロセスにも影響して、アクセス不可能になる。
再起動の抑止オプションがあれば、まだいけそうな気もするが。。。
回避するには、
node自体をv.11.xx（現時点でunstable）にすればいけるようだが、未検証なので、何とも言えない。。。
じゃあ、forkモードで起動すればいいじゃんとなりますが、
forkの場合は、プロセスとポートが1対1なので、
4プロセス起動するには、4ポート必要になりますので、柔軟性は低くなる。
ただ、forkモードでは、再起動時にポート開放されますので、
node.jsの前に置くフロントサーバをコントロールできれば問題はないかなと。
まだまだ、node.jsは発展途上なわけなので、
このあたりのリスクを十分に踏まえる必要がありますね。
余談ですが、websocketは再起動が命取りになるので、
foreverでポート分散して、再起度を抑止するようにしておくほうが
現在取りうる手段としてはベターかなと感じています。