Fitibit Charge2 のアクティビティから走行 (歩行) 距離を Fitbit Web API で取得して Pixela で草生やしている. 色が濃くなれば濃くなる程強度が高い (歩行, 走行距離が長い) ということで. 実装の詳細はこちら.
EKS matsuri は Kubernetes 初心者の自分でもとてもわかり易く説明さされていて EKS 色があんまり感じられないイベントだった.
Fitibit Charge2 のアクティビティから走行 (歩行) 距離を Fitbit Web API で取得して Pixela で草生やしている. 色が濃くなれば濃くなる程強度が高い (歩行, 走行距離が長い) ということで. 実装の詳細はこちら.
ふと思い立って CloudWatch Alarm を Slack に通知する Lambda ファンクションを作ったけど, 半分くらい出来たところで AWS Chatbot がリリースされていることを思い出して笑えた.
シュッと使いたい場合には, AWS Chatbot で十分なんだろうなあ.
Fitibit Charge2 のアクティビティから走行 (歩行) 距離を Fitbit Web API で取得して Pixela で草生やしている. 色が濃くなれば濃くなる程強度が高い (歩行, 走行距離が長い) ということで. 実装の詳細はこちら.
Fitibit Charge2 のアクティビティから走行 (歩行) 距離を Fitbit Web API で取得して Pixela で草生やしている. 色が濃くなれば濃くなる程強度が高い (歩行, 走行距離が長い) ということで. 実装の詳細はこちら.
WEB+DB PRESS Vol.116 の記事を読んでみたメモです.
読みながら気になる単語や内容をマインドマップにまとめていきたいと思います. 今回は「特集 1: トラブルシューティング」の「第 3 章データベース」を読みました.
眺めていた top コマンドだけど, 以下のように見ることでボトルネックの特定が捗ることが判りました.
知らなかった. すいません.
$ mysqldumpslow --help Usage: mysqldumpslow [ OPTS... ] [ LOGS... ] Parse and summarize the MySQL slow query log. Options are --verbose verbose --debug debug --help write this text to standard output -v verbose -d debug -s ORDER what to sort by (al, at, ar, c, l, r, t), 'at' is default al: average lock time ar: average rows sent at: average query time c: count l: lock time r: rows sent t: query time -r reverse the sort order (largest last instead of first) -t NUM just show the top n queries -a don't abstract all numbers to N and strings to 'S' -n NUM abstract numbers with at least n digits within names -g PATTERN grep: only consider stmts that include this string -h HOSTNAME hostname of db server for *-slow.log filename (can be wildcard), default is '*', i.e. match all -i NAME name of server instance (if using mysql.server startup script) -l don't subtract lock time from total time
ちょっと試してみる.
Docker でシュッと用意します.
$ docker run -i -t --name mysql -p 3306:3306 -e MYSQL_ROOT_PASSWORD=mysql -d mysql:latest \ --slow-query-log=true \ --slow-query-log-file=/tmp/slow.log \ --long-query-time=1
スローログは /tmp/slow.log に出力するようにして, 1 秒以上のクエリは記録するようにします.
以下のようにクエリを断続的に投げつつ, mysqldumpslow を実行してみます.
#!/usr/bin/env bash while true do docker exec -t -i mysql mysql -uroot -pmysql -hlocalhost --execute="SELECT SLEEP($(($RANDOM % 10)));" sleep 2 done
SELECT SLEEP(N) しか投げていないので, 以下のようにちょっと寂しいけど, mysqldumpslow の出力を確認することが出来ました.
$ docker exec -t -i mysql mysqldumpslow -s c /tmp/slow.log Reading mysql slow query log from /tmp/slow.log Count: 61 Time=4.94s (301s) Lock=0.00s (0s) Rows=1.0 (61), root[root]@localhost SELECT SLEEP(N)
シンプルに件数をカウントする -s c オプションの実行結果です.
なかなかデータベースのパフォーマンスチューニングとかに携わる機会はありませんが, とても奥深く且つ, 日頃から手を動かしておく必要があるなあと思った次第です。
WEB+DB PRESS Vol.116 の記事を読んでみたメモです.
読みながら気になる単語や内容をマインドマップにまとめていきたいと思います. 今回は「特集 1: トラブルシューティング」の「第 2 章バックエンド」を読みました.
HTTP プロトコル以外にも対応してるということなので, curl で SMTP と会話してみたいと思います.
こちらの記事を参考にさせて頂きました.
Docker を利用します.
$ docker run -d -p 25:25 \ --name mailserver \ -e maildomain=example.com \ -e smtp_user=username:password \ catatnight/postfix $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 367c3f04439a catatnight/postfix "/bin/sh -c '/opt/in…" 16 minutes ago Up 16 minutes 0.0.0.0:25->25/tcp mailserver
一旦, telnet で会話してみます.
$ telnet localhost 25 Trying ::1... Connected to localhost. Escape character is '^]'. 220 example.com ESMTP Postfix (Ubuntu) HELO example.com 250 example.com MAIL FROM: from@example.com 250 2.1.0 Ok RCPT TO: to@example.com 454 4.7.1 <to@example.com>: Relay access denied QUIT 221 2.0.0 Bye Connection closed by foreign host.
こちらの記事を参考にさせて頂きました.
以下のようなテキストファイルを用意します. このテキストファイルを test.txt というファイル名で保存します.
To: to@example.com From: from@example.com Subject: this is a test hello world!
以下のように curl コマンドでメールを送信します.
$ curl -sv smtp://localhost:25 --mail-from 'from@example.com' --mail-rcpt 'to@example.com' -u username -T test.txt
以下のように出力されました.
Enter host password for user 'username': * Trying ::1... * TCP_NODELAY set * Connected to localhost (::1) port 25 (#0) < 220 example.com ESMTP Postfix (Ubuntu) > EHLO test.txt < 250-example.com < 250-PIPELINING < 250-SIZE 10240000 < 250-VRFY < 250-ETRN < 250-STARTTLS < 250-AUTH PLAIN LOGIN CRAM-MD5 DIGEST-MD5 NTLM < 250-AUTH=PLAIN LOGIN CRAM-MD5 DIGEST-MD5 NTLM < 250-ENHANCEDSTATUSCODES < 250-8BITMIME < 250 DSN > AUTH DIGEST-MD5 < 334 bm9uY2U9IjJJZnVhc1JVbnRTdjVpcmFuRXpYY0k1NklPeWFiMXF2YmdrKzdSL2JhMkE9IixyZWFsbT0iZXhhbXBsZS5jb20iLHFvcD0iYXV0aCIsY2hhcnNldD11dGYtOCxhbGdvcml0aG09bWQ1LXNlc3M= > dXNlcm5hbWU9InVzZXJuYW1lIixyZWFsbT0iZXhhbXBsZS5jb20iLG5vbmNlPSIySWZ1YXNSVW50U3Y1aXJhbkV6WGNJNTZJT3lhYjFxdmJnays3Ui9iYTJBPSIsY25vbmNlPSJlODcwZWFlMDNhOWQ5MGYwZjQyNTQ4OWJlMmNjOGI4YiIsbmM9IjAwMDAwMDAxIixkaWdlc3QtdXJpPSJzbXRwL2V4YW1wbGUuY29tIixyZXNwb25zZT1lZWFhNTliY2ZiNjJkMmUwZWI2MWYzM2JiOGU2MTA1Mixxb3A9YXV0aA== < 334 cnNwYXV0aD1kMWYxNmI4ODUzZGJkMjRlZTdjZmY0YTE4MjhiZjM3MQ== > < 235 2.7.0 Authentication successful > MAIL FROM:<from@example.com> SIZE=80 < 250 2.1.0 Ok > RCPT TO:<to@example.com> < 250 2.1.5 Ok > DATA < 354 End data with <CR><LF>.<CR><LF> } [80 bytes data] * We are completely uploaded and fine < 250 2.0.0 Ok: queued as 1448D342D47 * Connection #0 to host localhost left intact
SMTP のやりとりを確認することが出来ました.
ログを SQL ライクな構文で検索出来る trdsql というツールを初めて知ったので少し触ってみました. 尚, 動作検証環境は以下の通りです.
root@6dc811524b1d:/work# cat /etc/os-release PRETTY_NAME="Debian GNU/Linux 10 (buster)" NAME="Debian GNU/Linux" VERSION_ID="10" VERSION="10 (buster)" VERSION_CODENAME=buster ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/" root@6dc811524b1d:/work# ruby --version ruby 2.7.1p83 (2020-03-31 revision a0c7c23c9c) [x86_64-linux] root@6dc811524b1d:/work# gem list | grep apache apache-loggen (0.0.5) root@6dc811524b1d:/work# ./trdsql_v0.7.5_linux_amd64/trdsql --version trdsql version v0.7.5 $ sw_vers ProductName: Mac OS X ProductVersion: 10.14.6 BuildVersion: 18G3020 $ ~/bin/trdsql --version trdsql version v0.7.5
Apache のログを用意します. Apache のダミーログを用意するには, apache_log_gen がとても便利です.
以下のように出力しました.
$ apache-loggen --json --limit=5000 sample.log
JSON フォーマットで 5000 件のログを生成して sample.log というファイルを生成しています.
trdsql でログを検索してみたいと思います. まずは, ステータスコード 200 以外のログを抽出してみます.
$ ~/bin/trdsql -ijson -oat "SELECT path,code,count(path) AS count \ FROM sample.log WHERE code != '200' \ GROUP BY path, code ORDER BY count DESC"
-ijson はJSON フォーマットのログを読み込むオプション, -oat は ASCII Table 形式で出力するオプションです.
以下のように出力されました.
+------------------------+------+-------+ | path | code | count | +------------------------+------+-------+ | /item/games/2228 | 404 | 4 | | /item/electronics/2168 | 404 | 3 | | /item/games/452 | 404 | 3 | +------------------------+------+-------+
念の為, ログを Linux コマンドを駆使して抽出してみました.
$ grep -v '"code":200' sample.log | jq -r .path | sort | uniq -c | sort -r 4 /item/games/2228 3 /item/games/452 3 /item/electronics/2168
続いて, 接続元の IP アドレス毎にアクセス件数を確認してみます.
$ ~/bin/trdsql -ijson -oat "SELECT host, count(host) AS count \ FROM sample.log GROUP BY host ORDER BY count DESC LIMIT 20"
以下のような結果となりました.
+-----------------+-------+ | host | count | +-----------------+-------+ | 84.144.85.122 | 11 | | 28.186.132.148 | 10 | | 216.93.121.144 | 10 | | 216.177.205.222 | 10 | | 208.135.120.209 | 10 | | 188.123.189.209 | 10 | | 180.225.208.155 | 10 | | 124.75.103.212 | 10 | | 112.69.129.87 | 10 | | 104.21.41.136 | 10 | | 100.90.123.168 | 10 | | 96.132.66.43 | 9 | | 96.126.37.143 | 9 | | 92.144.43.39 | 9 | | 88.162.143.128 | 9 | | 60.90.182.138 | 9 | | 40.21.86.73 | 9 | | 40.141.66.26 | 9 | | 28.105.160.88 | 9 | | 24.189.98.124 | 9 | +-----------------+-------+
おおー. 素晴らしい. SQL でログを直接検索出来るのは SQL が苦手な自分でも頑張りたくなります.
やっぱ, 「憶測するな計測せよ」はトラブルシューティングの鉄板. そして, trdsql に出会えたのは最高でした. これはギョームで使っていこうと思います.
昔, 以下のようなブログを書いていました.
7 年経って vagrant はまだ健在. 良いプロダクトは時を超えて使われ続けるんだなあと. ということで, 改めて macOS 上で vagrant で仮想マシンを立ち上げたのでメモしておきます.
$ sw_vers ProductName: Mac OS X ProductVersion: 10.14.6 BuildVersion: 18G3020 $ vagrant version Installed Version: 2.2.7 Latest Version: 2.2.7
VirtualBox のバージョンは バージョン 6.1.6 r137129 (Qt5.6.3) となります.
上記のサイトより, 環境に応じたインストールパッケージをダウンロードしてインストーラーに従ってインストールするだけです. 2013 年の記事では, gem install していたことを考えると敷居が少し下がった感じです.
2013 年の記事では, 以下のサイトからマシンイメージを探していました.
ですが, 現時点では,
Discover Vagrant Boxes よりイメージをしました.
例えば, Ubuntu 16.04 (ubuntu/xenial64) を検索すると, 以下のように Vagranfile のサンプルまでサジェストしてくれるので有り難いです.
ドキュメントによると, vagrant の始め方としては vagrant init で Vagrantfile を生成するところ書かれています.
vagrant init で生成される Vagrantfile には多くの貴重な情報が書かれていて, Vagrantfile を書く上では非常に参考になりますが, 今回は, 以下のように最小限の Vagrantfile を直接作成して始めました.
$ mkdir project1 $ cd project1 $ vim Vagrantfile
以下の内容で作成します.
Vagrant.configure("2") do |config| config.vm.box = "ubuntu/xenial64" config.vm.provider "virtualbox" do |vb| vb.memory = '512' end end
あとは, vagrant up で仮想マシンを起動するだけです.
$ vagrant up
しばらくすると, 仮想マシンが起動するので vagrant ssh でログインします.
$ vagrant ssh Welcome to Ubuntu 16.04.6 LTS (GNU/Linux 4.4.0-177-generic x86_64) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support: https://ubuntu.com/advantage * Ubuntu 20.04 LTS is out, raising the bar on performance, security, and optimisation for Intel, AMD, Nvidia, ARM64 and Z15 as well as AWS, Azure and Google Cloud. https://ubuntu.com/blog/ubuntu-20-04-lts-arrives 0 packages can be updated. 0 updates are security updates. New release '18.04.4 LTS' available. Run 'do-release-upgrade' to upgrade to it. Last login: Sun Apr 26 01:28:56 2020 from 10.0.2.2 vagrant@ubuntu-xenial:~$
おっしゃ.
素敵な VirtualBox 生活をお楽しみください.
Fitibit Charge2 のアクティビティから走行 (歩行) 距離を Fitbit Web API で取得して Pixela で草生やしている. 色が濃くなれば濃くなる程強度が高い (歩行, 走行距離が長い) ということで. 実装の詳細はこちら.
会社から借りっぱなしの Software Design 2020 年 2 月号で特集されている Docker コンテナランタイムについての記事を読んでみたメモです.
読みながら気になる単語や内容をマインドマップにまとめていきたいと思います.
今回は cgroup について手を動かしてみたいと思います.
ホスト側の OS は以下の通り.
$ cat /etc/os-release NAME="Ubuntu" VERSION="18.04.4 LTS (Bionic Beaver)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 18.04.4 LTS" VERSION_ID="18.04" HOME_URL="https://www.ubuntu.com/" SUPPORT_URL="https://help.ubuntu.com/" BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" VERSION_CODENAME=bionic UBUNTU_CODENAME=bionic
各種ツールのバージョンは以下の通り.
$ runc --version runc version spec: 1.0.1-dev $ unshare --version unshare from util-linux 2.31.1 $ taskset --version taskset from util-linux 2.34
巣の Alpine Linux には taskset ユーティリティはインストールされていなかったので, util-linux パッケージをインストールします.
尚, インストールに際しては, 改めて docker コンテナを起動してパッケージをインストールしてから rootfs を再作成することになります.
$ docker run --rm -d --name rootfs alpine tail -f /dev/null $ docker exec -t -i rootfs /bin/sh / # apk update && apk add bash util-linux / # exit $ docker export rootfs > rootfs.tar $ tar xvf rootfs.tar -C bundle/rootfs
taskset を動かしてみる. 以下のように隔離環境において 0 及び 1 のプロセッサが利用出来ることが判ります.
$ unshare -pfmur chroot bundle/rootfs /bin/sh / # taskset -c 0 echo 'test 0' test 0 / # taskset -c 1 echo 'test 1' test 1 / #
ホスト上で以下のように実行して利用可能なプロセッサを確認します.
$ cat /sys/fs/cgroup/cpuset/cpuset.cpus 0-1
0 と 1 の二つのプロセッサが利用可能であることが判ります. また, この値は, 以下のように /proc/cpuinfo の processor 項目に該当します.
$ cat /proc/cpuinfo | grep 'processor' processor : 0 processor : 1
まずはホスト側で以下を実行する. (すでに隔離環境は unshare -pfmur chroot bundle/rootfs /bin/sh で起動している前提.)
$ sudo mkdir /sys/fs/cgroup/cpuset/demo $ cd /sys/fs/cgroup/cpuset/demo # -> 利用可能なプロセッサの設定 0 番のプロセッサのみを利用する $ sudo su - # echo 0 > cpuset.cpus # -> 既存の設定を継承 # echo 0 > cpuset.mems # -> 隔離環境で実行されるプロセスのホスト側から見える PID を tasks に書き込む # ps ao pid,cmd | grep '[/]bin/sh' | grep -v unshare | awk '{print $1}' > tasks
隔離環境で実行されるプロセスのホスト側から見える PID を書き込むことで, そのプロセスから作られるすべての子プロセスに対して, 0 番の CPU のみを利用するように制限が掛かることになります.
実際に確認してみます.
/ # / # taskset -c 0 echo 'test 0' test 0 / # taskset -c 1 echo 'test 1' taskset: failed to set pid 3's affinity: Invalid argument / #
確かに 1 番のプロセッサを利用しようとすると, taskset: failed to set pid 3's affinity: Invalid argument というエラーが出力され, 期待通りに 0 番のプロセッサのみが利用可能な状態を確認出来ました.
namespace, cgroup と触ってきて, あれ, コンテナのランタイムどこ行った！って思ってしまうほど, runc については Linux の環境隔離の仕組みをゴリゴリと使って実現していることを実感出来ました. Kubernetes や Docker のような上モノを触るのも楽しいけど, コンテナランタイムを通してコンテナの深淵に触れてみることで, このレイヤーのことについて何も知らないことに愕然となりましたが, 今後も引き続き, このあたりのインプットはやっていきたいなと思います.
とても面白い記事でした. 借りっぱなしなってしまい本当に申し訳ございません.
