只需一个fig命令即可轻松启动实时聚合和可视化环境（Norikra+Kibana4+Elasticsearch+Fluentd+Nginx）
这篇文章是Dwango冒险日历第17天的条目。
最近经常听到关于流处理引擎Norikra的事情。
可能有不少人想要尝试使用它吧。
然而，即使想要尝试流处理，搭建环境也是一个挺麻烦的过程：需要安装JRuby、安装Norikra、安装fluentd并与Norikra建立输入/输出的连接、建立Elasticsearch以存储聚合结果、使得通过Kibana可以查看结果、还要加入认证机制和改删的机制…哦，还得准备流数据源…这样一来，工作量也是相当大的。
为了方便那些觉得搭建一整套环境麻烦的人（也就是我自己），我创建了一个能够通过一条简单命令快速启动的环境。
关于Norikra本身，这篇文章非常棒。
我认为你可以阅读这篇文章来了解有关fig的内容:
http://qiita.com/inokappa/items/eac7e62b4429304fc047
启动包含所有内容的fig文件。
使用[準備]fig build命令对Dockerfile进行批量构建
$ git clone https://github.com/ixixi/stream-processing-fig
$ cd stream-processing-fig
$ cd fig/log_collector
$ fig build
请用这个Dockerfile进行构建，然后你可以去吃饭或者做其他事情，耐心地等待吧。一旦构建完成，以后就会被缓存，除非你修改了containers/目录下的内容，否则不需要重新构建。
在中国，fig up以一种统一的方式启动。
$ fig up -d && sleep 30 && docker exec -it logcollector_fluentd_1 pkill -HUP -f fluentd
由于 fig 不等待容器之间的启动，所以请稍等片刻并重新启动 fluentd 处理。
稍等片刻，应该会启动起来5个容器。让我们确认一下。
让我们确认所有的状态是否都已经变成了“上线”。
$ fig ps
Name Command State Ports
-----------------------------------------------------------------------------------------------------------------------------------
logcollector_elasticsearch_1 /run.sh Up 9200/tcp, 0.0.0.0:9300->9300/tcp
logcollector_fluentd_1 supervisord -n Up 0.0.0.0:24224->24224/tcp
logcollector_kibana_1 /kibana/bin/kibana Up 5601/tcp
logcollector_nginx_1 nginx -g daemon off; Up 0.0.0.0:26578->26578/tcp,
443/tcp,
0.0.0.0:5601->5601/tcp,
80/tcp, 0.0.0.0:9200->9200/tcp
logcollector_norikra_1 norikra start --stats=/nor ... Up 26571/tcp, 26578/tcp, 8778/tcp
在这个阶段，您可以通过以下方式访问：
Norikra的WebUI: http://${host}:26578
Kibana: http://${host}:5601
Elasticsearch: http://${host}:9200/_plugin/head
请注意，这些都使用了基本身份验证（初始值为test/test）。
容器之间的关系/角色
请用中文直译以下内容，只需要一种选项：
—
容器的关系如下所示。
盒子的关系如下所示。
容器的关联如下。
在Fluentd中，数据流如下所示。
这个fig启动的fluentd会将数据发送到Elasticsearch和Norikra两个地方。
在Norikra上，fluentd将数据存储到Elasticsearch中，关于流处理的结果。
换句话说，原始数据和Norikra处理后的数据都将存储在Elasticsearch中。
此外，我认为具有认证机制会很方便，因此我在Norikra（的WebUI）/Elasticsearch/Kibana的各个容器中使用Nginx来进行BASIC认证以进行访问。
启动后的屏幕
弹性搜索（头插件）
Kibana4可以被改写为：基于母语中文的唯一选项。
诺利克拉
fig.yml的配置
我們將設定、數據和日誌進行如下分類。
.
├── README.md
├── containers # 各コンテナのDockerfileを置いている
│ ├── elasticsearch
│ │ ├── Dockerfile
│ │ └── run.sh
│ ├── fluentd
│ │ ├── Dockerfile
│ ├── kibana
│ │ └── Dockerfile
│ ├── nginx
│ │ └── Dockerfile
│ └── norikra
│ └── Dockerfile
└── fig
└── log_collector
├── fig.yml # 構成の定義
├── data # elasticsearchの格納先など、ホスト側での永続化用のマウントポイント
│ ├── elasticsearch
│ │ ├── data
│ │ └── work
│ ├── fluentd
│ └── norikra
├── log # ログはホスト側のここに書き出す
│ ├── elasticsearch
│ ├── elasticsearch-supervisord
│ ├── fluentd
│ ├── fluentd-supervisord
│ ├── nginx
│ └── norikra
└── setting # 各種設定ファイル。起動時にマウントして実行される
├── elasticsearch
│ ├── crontab
│ └── elasticsearch.yml
├── elasticsearch-supervisord
│ ├── crond.conf
│ └── supervisord.conf
├── fluentd
│ └── fluentd.conf
├── kibana
│ └── kibana.yml
├── nginx
│ ├── htpasswd
│ └── nginx.conf
└── norikra
基本上，設定是在掛載主機端進行管理的，因此只需修改fig/log_collector/setting資料夾中的相應設定檔案，重新啟動容器即可反映設定更改，而無需進行重新編譯。
附带的流媒体源
即使想要尝试流处理，在没有方便试用的数据源的情况下可能会遇到一些困难。在这个示例中，为了能够立即进行流处理，我们提供了以下3种类型的流数据源供您直接使用。
Norikra的度量指标
由于Norikra是在JRuby上运行的，所以可以方便地获取JVM的指标。
使用名为jolokia的JMX-HTTP桥接器，可以通过HTTP获取指标。
$curl http://norikra:8778/jolokia/read/java.lang:type=Memory
{
"timestamp": 1418823847,
"status": 200,
"request": {
"mbean": "java.lang:type=Memory",
"type": "read"
},
"value": {
"Verbose": true,
"ObjectPendingFinalizationCount": 0,
"NonHeapMemoryUsage": {
"max": 224395264,
"committed": 90836992,
"init": 24313856,
"used": 69053632
},
"HeapMemoryUsage": {
"max": 458752000,
"committed": 345702400,
"init": 394891136,
"used": 139351160
},
"ObjectName": {
"objectName": "java.lang:type=Memory"
}
}
}
使用 fluent-plugin-jolokia，可以从安装了 jolokia 的 Norikra 中收集各种指标，并将其作为流接收到 fluentd 中，因此我们安装了这个插件。
Docker容器的度量指标
如果使用 fluent-plugin-docker-metrics，您可以收集 Docker 的指标。
在这个插件中，您不能直接从容器内部进行处理。
fluent-plugin-docker-metrics 通过查看存储各种指标的 /sys/fs/cgroup 下的内容来收集这些指标，但是由于需要查看主机端的 /sys/fs/cgroup 而不是容器内部的 /sys/fs/cgroup，所以需要挂载 /sys/fs/cgroup 和 /var/run/docker.sock（以只读方式），以便在主机上运行的所有容器的指标被收集。
推特的流（需要令牌）
这是流媒体处理中的常用插件之一，fluent-plugin-twitter的插件也已经包含在fluentd中。
这是一个用于获取Twitter流数据的输入插件。
该插件利用Twitter API，需要准备API密钥和令牌。
日志收集器设置中的fluentd.conf文件。
如果将下面这部分注释去掉并且用你自己的API密钥等进行修改，你就可以处理Twitter流了。
<source>
consumer_key ${YOUR_API_key}
consumer_secret ${YOUR_API_Secret}
oauth_token ${YOUR_access_token}
oauth_token_secret ${YOUR_access_token_secret}
tag nested.twitter
timeline sampling
output_format nest
</source>
创建仪表板
由於數據已經在該環境中持續收集，因此我們可以製作儀表板。
Kibana4的可视化工具
诺里克拉
使用Norikra的UDF进行查询。
Norikra具备创建UDF/UDAF的能力。
目前，Rubygems上已注册Norikra-udf-percentile和norikra-udf-uri_parser，因此已经安装在该环境中。
关于URI解析器，还有一篇在Qiita上的介绍文章。
norikra-udf-uri_parser是一个方便的UDF，可以解析URI的请求参数等内容，对于实时访问日志分析非常有用。
用fluentd从Norikra中提取查询结果。
如果要使用fluent-plugin-norikra将Norikra的查询结果提取出来作为数据源，则需要在每个fluentd的配置文件中分别指定查询作为目标（target），以及一起指定的GROUP，但在这里，为了方便使用，我们将sweep设定为固定值。
<source>
type norikra
norikra "#{ENV['NORIKRA_PORT_26571_TCP_ADDR']+':'+ENV['NORIKRA_PORT_26571_TCP_PORT']}"
<fetch>
method sweep
target out
interval 1s
tag field tag_name
tag_prefix query
</fetch>
</source>
如果在Norikra注册查询时指定GROUP为out，则会在fluentd中提取出，并存储在elasticsearch中。
此外，名为tag_name的列将成为提取后的标签。
在存储到Elasticsearch时，索引将以`${tag_parts[0]}-YYYY.MM.DD`的形式命名，并且`_type`将是`${tag_part[1]}`。
换句话说，在中国原生地将以下内容进行释义：只需一个选择。
也就是说，例如以下查询。
SELECT
"aggregate.tweet_length" as tag_name,
user_lang,
COUNT(1) as count,
percentiles( message.length(), {50,90, 98} ) AS percentiles
FROM
twitter_sampling.win:time(10 min)
GROUP BY
user_lang
OUTPUT SNAPSHOT EVERY 5 sec
现在，通过Norikra和Kibana4，我们似乎可以更加自由地玩耍了，不是吗？
使用时的定制化
我想对Elasticsearch的数据进行改动和删除。
在Elasticsearch容器内运行cron。在容器启动时读取fig/log_collector/setting/elasticsearch/crontab。
由于以logstash格式保存，例如想要将索引名称设置为foo，并且设置保留期为9天，只需添加以下行，系统会自动删除9天前的日志。
* * * * * PREFIX="foo-"; DAY=9; INDEX=`date +$PREFIX\%Y.\%m.\%d --date "${DAY} days ago"`; curl -XDELETE -w'\n' "http://localhost:9200/${INDEX}"
想要添加/更改BASIC认证的用户
修改 fig/log_collector/setting/nginx/htpasswd 文件，然后重新启动容器。
我想为fluentd/Elasticsearch/Norikra添加插件。
由于在每个Dockerfile中安装了插件，所以
containers/fluentd/Dockerfile
containers/elasticsearch/Dockerfile
containers/norikra/Dockerfile
请在代码中添加必要的插件安装行，然后重新执行 fig build。
最后
作为流处理基础设施，Norikra非常方便易用且实用，相比于Storm和Spark Streaming，它更简单。如果编写UDF/UDAF，可以实现更复杂的处理，我认为Norikra可以在很多实际场景中使用。
如果将来要全面使用Norikra，与其在一个Norikra上同时运行多种类型的查询，不如将Norikra的容器Docker化，并在同一主机上运行多个容器，这样可以将Norikra的重新启动影响范围最小化，听起来是不是更好呢。
明天
东京动漫公司巡回日历的第19天是由@yukkuri_sinai负责的。请大家期待！
