ブログトップ 記事一覧 ログイン 無料ブログ開設

wyukawa’s blog

2016-09-26

オホーツク網走マラソン走ってきた

http://www.abashiri-marathon.jp/

記録はネットタイムが4時間39分16秒で自己ワーストなんだけど、練習不足と暑かったのでこれはしょうがない。

それはそれとして素晴らしい大会でした。僕が参加したマラソン大会のなかでもっとも景色がいい大会でした。

あとエイドも充実してました。

スタートして4kmでかに汁がでました。その後も網走名物らしきものが出ました。菜根糖、しじみ汁、長天、監獄和牛などなど。あと何気にコーラが冷えててうまかった。

網走刑務所をスタートしてポスターにもなってる能取岬の景色には感動しました。その後のレイクサイドパーク・のとろもよかった。去年は途中で雨が降ったらしいのですが、今年は晴れて青空でした。

f:id:wyukawa:20160926132444j:image

最後はひまわり畑の中をゴールして完走メダルをもらいました。

f:id:wyukawa:20160926130521j:image

ゴール地点には飲食店ブースがあり、ランナーはそこで使える券を何枚か無料でもらえるので多少飲み食いできます。

僕はすぐにはお腹がうけつけなかったので、休憩してた場所の目の前で売ってた長崎ちゃんぽんみたいなやつだけ食いました。

去年は問題があったらしいシャトルバス待ちや荷物受け渡し等の運営も今年はまったく問題なかったです。

僕は女満別空港経由で網走湖荘に宿泊して、当日はホテルのバスでスタート地点まで送ってもらって、完走後はシャトルバスでホテルまで送ってもらいました。

荷物預かりのための袋にはキャリーケースは入らないのでホテルに預かってもらったという次第です。

あとゴール後に風呂入りたかったというのもある。

交通の便は良くないけど来年も出たいなと思いました。

2016-09-14

Podcastの始め方

Podcastを雑に始めた - wyukawa’s blogで書いたように雑にPodcastを始めました。

https://itunes.apple.com/jp/podcast/wyukawas-podcast/id1152456701

から購読することができます。現在3エピソードを配信しています。

最初の1話目はひとりでしゃべって雑音カットも少しやったのですが、ゲストを呼んだ2,3話目は少し長くて面倒なので編集してません。

完全ノーカット版をお楽しみください。


このエントリではPodcastを僕がどうやっているかを書きます。ググると情報が色々出てきますが、若干古いような気がしました。今だと割と簡単にできます。

手順は下記の通りです。なお環境はMacBookAirでOSはEl Capitanです。

ゲストがいなくて一人でやるならSkypeも不要でGarageBandもそんなにいじる必要なく録音してSoundCloundにアップロードできます。GarageBandが標準でSoundCloundにアップロードする機能を持っているので楽です。

Skype経由でやる場合はGarageBandとSkypeの設定が必要で、基本的には How To Record A Podcast Guest Over Skype Using a... - Omny Studio blogの通りにやればいけると思います。

僕がやったのは、

https://github.com/mattingalls/Soundflower/releases/download/2.0b2/Soundflower-2.0b2.dmg

をダウンロードしてインストール。

Skypeは以下のようにサウンドをSoundflower(2ch)にする。

f:id:wyukawa:20160914221740p:image

ユーティリティ -> Audio MIDI設定で、ここではSkypeという名前で追加。

f:id:wyukawa:20160914221913p:image

GarageBandで追加したSkypeを入力デバイスに指定する。

f:id:wyukawa:20160914221907p:image

GarageBandで新規ファイルを作成し既存のトラッックを削除して2つ追加する。

入力1+2(skype側)は入力モニタリングオンで入力3+4(自分側)は入力モニタリングオフにする。入力モニタリングオフにしないとキーンという音が聞こえた。

f:id:wyukawa:20160914221914p:image

f:id:wyukawa:20160914221908p:image

トラックヘッダーコンポーネントから録音を可能にするを表示する。

f:id:wyukawa:20160914221909p:image

録音をスタートする。動作確認はSkypeの音声テストサービスを使う。

f:id:wyukawa:20160914221910p:image

録音が終わったらSoundCloundにアップロードする。

https://soundcloud.com/settings/content からRSSフィードが取れる。

f:id:wyukawa:20160914221911p:image

あとは https://podcastsconnect.apple.com でRSSフィードを登録する。

f:id:wyukawa:20160914221912p:image

「アートワークはサイズが1400x1400ピクセルから3000x3000ピクセルであること、JPGまたはPNG形式であること、RGB色空間を使用していること、およびHTTP headリクエストが可能なサーバにホストされていることが必要です。」とか言われたらMacのプレビューでも使ってSoundCloundに登録した画像のピクセルを調整する。

RSS登録が完了してしばらく経てば https://itunes.apple.com/jp/podcast/wyukawas-podcast/id1152456701 のようになってiTunesから聞けるようになります。

f:id:wyukawa:20160914223447p:image

SoundCloundを使えば https://blog.riywo.com/2013/02/22/132712 にあるようなRSSフィードを自分で用意する必要が無いので楽です。

Prometheusで有名なSoundCloundをまさかこういう形で使うことになるとは思わなかったけど、GarageBandとも標準で連携しているので便利です。

2016-09-13

Prometheusのストレージ

Prometheusのストレージ周りに関してちょっと調べたのでメモっておく。

間違っているところや補足すべきものがあれば教えてもらえると嬉しいです。

公式ドキュメントはこちら

https://prometheus.io/docs/operating/storage

他に参考になりそうな資料としてはこの辺

https://promcon.io/2016-berlin/talks/the-prometheus-time-series-database

簡単に説明するとchunkという1024bytesの固定長データをもとに処理しておりインデックスはLevelDBに保持している。

メモリにデータを保持して高速化をはかりつつ予期せぬ停止によるデータロストを最小限にするため定期的にディスクに書き出している。HBaseのようにWALを持っているわけではなさそうなのでデータロストはありそう。

storage.local.memory-chunksというのが何個のchunkをメモリに保持するかのパラメータでデフォルトは1048576(1024*1024)である。chunkが1024 bytesなので1024**1024*1024つまり1GBのメモリがmaxの使用量となっている。

英語の説明はこちら

How many chunks to keep in memory. While the size of a chunk is 1kiB, the total memory usage will be significantly higher than this value * 1kiB. Furthermore, for various reasons, more chunks might have to be kept in memory temporarily. Sample ingestion will be throttled if the configured value is exceeded by more than 10%.

storage.local.max-chunks-to-persistの英語の説明はこちら

How many chunks can be waiting for persistence before sample ingestion will be throttled. Many chunks waiting to be persisted will increase the checkpoint size.

まだディスクに書き込んでなくてメモリに保持しているchunkの数がこれを超えるとスロットルされるのでデータが書き込まれない。

デファルトが512*1024でstorage.local.memory-chunksの50%になっている。

storage.local.memory-chunksだけ増やしてstorage.local.max-chunks-to-persistがそのままだとスロットルされてしまうのでstorage.local.max-chunks-to-persist/storage.local.memory-chunksが0.5になるように設定しましょう。

storage.local.retentionはディスク保持期間でデフォルトは15日。

これを増やした場合、1ヶ月以上にした場合はstorage.local.series-file-shrink-ratioも増やす方がよい。

storage.local.series-file-shrink-ratioはデファルト0.1で、Prometheusがディスクに書き込んだファイルの10%を削除する必要があったらファイルを全書き換えする実装になっているが、ファイルサイズが大きい場合は0.3とかにする方が良い。

Prometheus自身のメトリクスをGrafanaで表示するためには以下のダッシュボードを参考にするといい。

How To Add a Prometheus Dashboard to Grafana | DigitalOcean

2016-09-08

Elasticsearchのモニタリング

今まではElasticSearch Headでシャードやノードの状態見てたんだけど、最近はGitHub - lmenezes/elasticsearch-kopf: web admin interface for elasticsearchを使い始めた。

こっちのほうが良いね。index templateも見れるし。

Marvelは最初は良いと思ったけどライセンス登録とかupgrade時の作業が面倒なわりにはそんなに使ってなかったので結局Marvelはリプレースのタイミングでやめることにした。

ただそうするとインデックス単位でモニタリングしたい場合どうするかなというのはある。

いつもはGitHub - ewr/elasticsearch_exporter: Elasticsearch stats exporter for Prometheusで取得したメトリクスをPrometheusに入れてGrafanaで見てる。

その辺はPrometheus London meetupでLTしてきました。 - wyukawa’s blogのスライドに少しある。

ただしelasticsearch_exporterはノードのメトリクスしか取得していない

Nodes Stats | Elasticsearch Reference [2.4] | Elastic

インデックス単位のメトリクスはIndices Stats | Elasticsearch Reference [2.4] | Elastic にあるURLをたたいて取ればいいっぽい。

ただし、elasticsearch_exporterのissueやpull requestは放置気味の模様。さてどうするか。まあ今まではインデックス単位でモニタリングしたいと思ったことないけど。

2016-09-07

fluentdからElasticsearchに書き込んだ際の運用メモ

fluentdからfluent-plugin-elasticsearchを使ってElasticsearchに書き込む部分でたびたびfluentdが詰まって苦労してたけど最近は落ち着いてきたのでその辺を備忘録としてメモっています。

最初はfluentdからElasticsearchに1プロセスで直接書き込んでいたけどなにかのイベント等でトラフィックがはねるとバッファ溢れがおきてました。なおこのときElasticsearch自体は特に問題は起きていません。

num_threads増やしたりbuffer_chunk_limit, buffer_queue_limit, flush_intervalあたりを調整したりというのをやっていたけど(実際にやったのは僕じゃないけど)、それでも厳しいのでプロセス分離してfluentd A -> fluentd B1,B2 -> Elasticsearchというように2プロセスでElasticsearchに書き込むようにしました。

それでも厳しのでfluentd B1,B2,B3,B4のように4プロセスにしたのですが、秒間12kmsgで100%CPU使っていました。

そのときの件数のグラフがこちら

f:id:wyukawa:20160907184618p:image

CPU使用率のグラフがこちら

f:id:wyukawa:20160907184617p:image

Elasticsearchの1秒間のindex件数がそれに対応して上がっています。

なおこのときのElasticsearchは2台, 2shard, 1replicaです。

f:id:wyukawa:20160907184616p:image

なので8プロセスにして安定はしたのですが、中継fluendマシンを1台から2台にして現在では合計16プロセスでElasticsearchに書き込んでいます。

さらにElasticsearchを8台, 8shard, 1replicaのものを用意してdouble writeして負荷を比較すると、確かに1秒間の1台あたりのindex件数が1/4になってる。他にjava heapの使用率とかもだいぶ減っていて良さげです。

f:id:wyukawa:20160907184620p:image

f:id:wyukawa:20160907184619p:image