あの記事どこだっけ?を避けるためのメモです.
監視やログ,可観測性の一般的な話からKubernetesでの話までわかりやすく解説しています.
Kubernetes & Observability 入門 – Speaker Deck
外形監視を入門する人におすすめな資料です.
より意味のある監視を目指して、外形監視の有効活用 – Speaker Deck
監視設計に入門する人におすすめな資料です.
*書籍「入門監視」がおすすめです.
あの記事どこだっけ?を避けるためのメモです.
監視やログ,可観測性の一般的な話からKubernetesでの話までわかりやすく解説しています.
Kubernetes & Observability 入門 – Speaker Deck
外形監視を入門する人におすすめな資料です.
より意味のある監視を目指して、外形監視の有効活用 – Speaker Deck
監視設計に入門する人におすすめな資料です.
*書籍「入門監視」がおすすめです.
ElasticSearch + Logstash + FileBeat + KibanaでUnboundのクエリログを解析してみました。UnboundはキャッシュDNSサーバなので、DHCPで配布するDNSサーバをこれに向けることでログを収集します。
※細かなコマンドやファイアウォールの設定手順は他のサイトにも書いてあるので省略します。
Unboundはパフォーマンスの観点からか、デフォルトではクエリログを出力しません。そのため、設定にuse-syslog: yes
を追加します。
unbound.confの例
server:
username: unbound
use-syslog: yes
# verbosity: 1 # uncomment and increase to get more logging.
log-queries: yes
interface: 0.0.0.0
interface: ::0
access-control: 192.168.254.0/24 allow
access-control: eeee:eeee:eeee:1::/64 allow
forward-zone:
name: "."
forward-addr: 8.8.8.8
forward-addr: 8.8.4.4
このままでは/var/log/syslog
がUnboundのクエリログで肥大化するためsyslogの設定を変更します。rsyslogでunboundの出力するログを別ファイルへ保存するよう設定します。
以下の設定ファイル(30-unbound.conf)を/etc/rsyslog.d
に設置します。
if $syslogfacility-text == 'daemon' and $programname contains 'unbound' then
-/var/log/unbound
& ~
ログの出力先を分けることができるものの、ログのローテーションがされていません。そのため、ログファイルのサイズが巨大に成長してしまいます。そこで、ログのローテーションを設定します。
以下のファイル(unbound)を/etc/logorate.d
へ配置します。
/var/log/unbound
{
rotate 30
daily
copytruncate
nocompress
olddir unbound.old
su syslog adm
postrotate
/usr/lib/rsyslog/rsyslog-rotate
endscript
}
ログ・ファイルを監視してLogstashへ送るためにFileBeatを導入します。インストールは公式のドキュメントを見ながら行います。
Repositories for APT and YUM | Filebeat Reference [6.6] | Elastic
以下はFilebeat設定ファイル(filebeat.yml)の例です。ElasticSearchのIPアドレスを 192.168.254.200 に設定しています。
#=========================== Filebeat inputs =============================
filebeat.inputs:
- type: log
enabled: true
paths:
- /var/log/unbound
- /var/log/unbound.old/*
exclude_lines: ['message repeated']
filebeat.config.modules:
path: ${path.config}/modules.d/*.yml
reload.enabled: false
#==================== Elasticsearch template setting ==========================
setup.template.settings:
index.number_of_shards: 3
#============================== Kibana =====================================
setup.kibana:
host: "192.168.254.200:5601"
#----------------------------- Logstash output --------------------------------
output.logstash:
# The Logstash hosts
hosts: ["localhost:5044"]
#================================ Processors =====================================
processors:
- add_host_metadata: ~
- add_cloud_metadata: ~
LogstashではFilebeatから受け取ったデータをパースしてElasticSearchへ送ります。以下のガイドを見ながらインストールを行います。
Installing Logstash | Logstash Reference [6.6] | Elastic
以下は/etc/logstash/conf.d
に配置したLogstashの設定ファイル(unbound.conf)の例です。inputとoutputをそれぞれ stdin, stdoutにするとデバッグ時に便利です。
input {
beats {
port => "5044"
type => "beats"
}
# stdin {}
}
filter {
grok {
patterns_dir => ["/etc/logstash/patterns.d"]
match => { "message" => "%{PATTERN}" }
}
}
output {
if "_grokparsefailure" not in [tags] {
elasticsearch {
hosts => ["192.168.254.200:9200"]
index => "unbound-%{+YYYY.MM.dd}"
}
# stdout {}
}
}
クエリログ用のパターンファイル(unbound)を作成して/etc/logstash/patterns.d
へ配置します。以下はその設定ファイルの例です。
PATTERN %{SYSLOGTIMESTAMP:timestamp} %{SYSLOGHOST:logsource} %{SYSLOGPROG:prog}: [%{INT:pid}:%{INT:tid}] %{LOGLEVEL:loglevel}: %{IP:ip_src} %{HOSTNAME:domain} %{WORD:record} %{GREEDYDATA}
ElasticSearchとKibanaはDockerを使って構築します。
Docker-CEをインストールします。aptでそのまま入れるとバージョンが古いので注意が必要です。docker-composeもインストールします。
以下のdocker-copose.yml(例)を作成しました。ulimitsでファイルディスクリプタの設定を変更しないと起動しないため注意が必要です。
version: '3'
services:
elasticsearch:
image: docker.elastic.co/elasticsearch/elasticsearch:6.6.0
ports:
- 9200:9200
- 9300:9300
#volumes:
# - ./elasticsearch/data:/usr/share/elasticsearch/data
ulimits:
nproc: 65535
nofile:
soft: 65536
hard: 65536
kibana:
image: docker.elastic.co/kibana/kibana:6.6.0
ports:
- 5601:5601
links:
- elasticsearch
environment:
- ELASTICSEARCH_URL=http://elasticsearch:9200/
ElasticSearchをインストールしたホストの5601/tcpへアクセスします。
DashBoardを作り込むとドメインのトップ100を表示することもできます。
これを見るとAWS S3が顕著なことがよくわかります。
今回はElasticSearchへログの投入を行いました。この他にログ解析に特化したGraylogもあるので、余裕があれば試してみたいと思います。
FROM alpine:3.8
MAINTAINER Tomoyuki KOYAMA <webmaster@koyama.me>
ENV SSH_USER guest22
ENV SSH_PASSWORD L1nuxCLU8
ENV SSH_PORT 22
ENV MAX_SESSION 3
ENV PERMIT_ROOT_LOGIN no
ENV SYSLOG_SERVER 172.17.0.2
ENV SYSLOG_PORT 514
RUN apk add --update --no-cache openssh openssh-sftp-server bash tzdata rsyslog &&
: "Configure timezone" &&
cp /usr/share/zoneinfo/Asia/Tokyo /etc/localtime &&
echo "Asia/Tokyo" > /etc/timezone &&
apk del tzdata &&
rm -rf /var/cache/apk/*
EXPOSE $SSH_PORT
VOLUME /www-data
VOLUME /var/log
ADD ./entrypoint.sh /
ADD ./motd /etc
# ADD ./sshd_banner /etc/ssh
CMD /bin/bash /entrypoint.sh &&
/bin/rm -f /entrypoint.sh &&
/usr/sbin/sshd -4 -f /etc/ssh/sshd_config &&
/usr/sbin/rsyslogd -f /etc/rsyslog.conf -n
その他のコードはGitHubにあります。
tomoyk/ssh-rental-space:
Dockerfileを書く時に、環境変数で実行時に後からポート番号やユーザ名などを変更できるように工夫しました。また、コンテナ内のタイムゾーン設定に配慮しました。ベースイメージをalpineにすることでイメージサイズが軽量になるよう注意しました。
実行
次のdocker-compose.ymlファイルを作成し、複数のコンテナを同時起動しています。
version: '3'
services:
ssh-server1:
container_name: circleA
hostname: circleA
image: ssh-server:latest
restart: always
environment:
- SSH_USER=sshuser
- SSH_PASSWORD=Password1
- SSH_PORT=10022
- SYSLOG_SERVER=syslog-server
volumes:
- ./www-data:/www-data/public_html
depends_on:
- syslog-server
deploy:
resources:
limits:
cpus: '0.50'
memory: 50M
reservations:
cpus: '0.25'
memory: 20M
# cpu_percent: 50
# cpu_shares: 73
# cpu_quota: 50000
# cpuset: 0,1
ports:
- 10022
syslog-server:
container_name: common-syslog
image: syslog-server:latest
restart: always
volumes:
- ./log:/var/log
docker-compose up -d
を実行しています。図の右のコンテナからssh接続を行っています。左中央がsyslogコンテナのログです。図の下が watch docker ps
の実行結果です。
:(){ :| :& };:
を実行したところフリーズしてしまいました。ファイルディスクリプタやI/Oなどの制限についてカーネル周りを中心に改めて調べてみる必要がありそうです。Wikipediaのforkbombに書かれたいた /etc/security/limits.conf
なども確認してみようと思います。
restart=always
では再起動を行ってくれません。
そのため、コンテナの状態を監視する仕組みを作り監視の自動化を行いたいと考えています。ここまでやるのであれば素直にKubernetesを使ってもいい気がします。
hiww
さんです!
9/14 – 9/17に開催されたPyCon JP 2018にスタッフとして参加したのでブログ記事にしておく。
今年は会場チームとNOCに関わって活動をした。開催の直前はNOCのメンバーとしてホットステージに参加した。ちょうどこの時期がインターンと重なっていたので、インターン先を退社して大手町のBBTに行くエクストリームな生活をしていた。
スタッフ参加も今年で2年目となり、ある程度の勝手がわかっていたのでそれほど困ることは無かった。事前のコミットが時期によってあまり出来なかったのが反省点としてある。。
NOCが面白かった!
NOCはPyConスタッフとCONBUから構成されていた。CONBUのもつナレッジがイベントネットワークの構築にかなり役立ってた。CONBUの方々とギークな話をするのも面白く、それと同時に知識が足りないことを痛感した。自分の役割がネットワーク利用者に役立っていることでやりがいと充実感を得ることができた。
PyCon NOCの追試で持ち込んだIX2105と格闘したのもいい思い出になった。来年までに修行をしてもっと強くなりたいと思った。自分のモチベーションを高められる良いきっかけになった。
そういえばWelcomeパーティーの会場でTyConになっていたな…。