shnagaiのインフラ備忘録

インフラ周りの自分の作業エビデンスとして記述しています。おかしな点あればツッコミいただければ幸いです。

はじめてansibleを触って、playbookを実行するまで

ansibleよりChef派でしたが、エージェント要らなかったり気軽という評判を聞きつけて、今度リリース要件にはansibleがよさそうなのでとりあえず使ってみた。

環境

Mac上にVagrantでCent0S6.6を2台

ansibleサーバ:192.168.50.5 プロビジョン対象:192.168.50.6

EPELのリポジトリを追加してインストール

$ sudo rpm -ivh http://ftp.iij.ad.jp/pub/linux/fedora/epel/6/i386/epel-release-6-8.noarch.rpm
http://ftp.iij.ad.jp/pub/linux/fedora/epel/6/i386/epel-release-6-8.noarch.rpm を取得中
警告: /var/tmp/rpm-tmp.sZnYCN: ヘッダ V3 RSA/SHA256 Signature, key ID 0608b895: NOKEY
準備中...                ########################################### [100%]
   1:epel-release           ########################################### [100%]

$sudo yum install -y ansible

設定ファイル場所とか(デフォルトのパス)

/etc/ansible
            --ansible.cfg
            --hosts
            --roles
                --各playbookを置く??

事前準備 対象サーバに事前にsshの鍵なし認証を出来るようにしておく

秘密鍵作って公開鍵を相手サーバに登録する 下記参照で!! http://qiita.com/nagais/items/a4e3d7ef2aba43bb0e4d

初めてのansibleコマンド実行まで

hostsに対象マシンを追加

[グループ名]でグループ定義らしいのでとりあえずtestgrpを作る

# This is the default ansible 'hosts' file.
#
# It should live in /etc/ansible/hosts
#
#   - Comments begin with the '#' character
#   - Blank lines are ignored
#   - Groups of hosts are delimited by [header] elements
#   - You can enter hostnames or ip addresses
#   - A hostname/ip can be a member of multiple 
[testgrp]
192.168.50.6

ついに初めてのansibleコマンド!!

-mオプション

引数でモジュールを指定するらしいので、まずはテスト用に標準で用意されているpingモジュールを試してみる!

$ansible testgrp -m ping
192.168.50.6 | success >> {
    "changed": false,
    "ping": "pong"
}

-aオプション

指定したコマンドを対象ホスト上で実施してくれる

$ansible testgrp -a "/bin/pwd"
192.168.50.6 | success | rc=0 >>
/home/vagrant

ついでに、初めてのplaybookも実行してみる

やりたいのは、新規リリースサーバの手順をcode化することなので、Chefでいうレシピ的なものという噂のplaybookを使ってみる。

どこにplaybookを置くのが最適なのかはわからなかったので、とりあえず/etc/ansible配下においてみた。

かなり簡単だけどbind-utilsをインストールして、yahoo.co.jpを引いてみるplaybook
- hosts: testgrp
  remote_user: vagrant
  sudo: yes
  tasks:
    - name: install bind-utils
      yum : name=bind-utils
      notify: dig test
  handlers:
    - name: dig test
      command: /usr/bin/dig yahoo.co.jp

で、実行

全部通った。 すごい簡単というか、Chefの時はchef-soloで初回実行するまでに、結構時間かかったが、ここまで1時間程で。

1__tmux.jpg

所感

想像以上に障壁が低かった。ここらのツールは冪等性が最重要だと思ってるので、どこまでコマンド類が揃っているのかはまだまだわからないが、プロビジョニングはplaybookでやって、複数台で同じコマンド打ちたい時は、ansibleコマンドをグループに対して実行とかやるとかなり使えそう。 どうやら、web見てると出来ないと思ってた、ファイルのプッシュとかも出来そうなのでかなり楽にプロビジョニングの土台出来そう! 只、ディレクトリ構成とか細かいとこは全然わかってないので、もう少し触ってみようと思った。

※Qiitaに投稿か、ブログにしようかいつも迷うな。。。

参考

http://knowledge.sakura.ad.jp/tech/3124/ http://docs.ansible.com/ansible/playbooks_intro.html

【レポート】SmartNews Tech Night Vol.2 ~クラウド事業者に就職する以外の インフラエンジニアの生きる道~

久々に面白いイベントだったので、メモを公開。

感想

メモったことそのままで長くなるので最初に感想だけ。 かなり釣り気味のタイトルでしたが、インフラエンジニアがいっぱいいて楽しいイベントでした。 トークしてた人たちが、有名とこの人達だったのでオンプレを否定するような空気は全くなかった。

印象に残ったのは下記の部分

  • インフラエンジニアという括りはもうない(得意な技術領域の異なるエンジニアがいるだけ)

  • クラウドで環境作るのは簡単だけど、中身を知らないと存在価値ない(裏がどういう仕組みかを知っているかとか中身を知っているのは強みになる)

  • 世間的にアプリエンジニア・インフラエンジニアと言われている人の日常業務を比較すると実はあまり変わらなくて得意な領域が違うだけという世界

  • インフラの仕事(サーバ構築,適切な監視,必要な検証,障害対応)は変わらないが、ツールコモディティ化(Chef,Fabricとか)により、やり方は変わっている

  • 新サービスはクラウドでの方針、オンプレで育ったサービスはノウハウ・費用をどう考えてもオンプレが優位(グリー、CA,DeNA3社とも同じ見解)只、クラウド化を検討しないわけではなく明確な優位があれば常に検討はする。

  • 監視ツールの領域はみなさんかなりSaasを使っている(規模が大きいのでオープンソースをそのまま使えず、自分達で運用するよりそのサービスに全力を使っている会社に任せる方が正しいという考え方) DataDog,pagerduty,logentriesとか

  • アラートやり取りをslackに集約(これはメール、これはチャットとかでなく全て集約すると全体見えるしスピード上がる)

  • クラウドだとまず第一にみんなAWS使ってるからやはりスタンダードなのは間違いない。(只、各社得意分野違うので、GCEとかSoftLayerとか国内クラウドも組み合わせる)

  • 事業会社のインフラと呼ばれる人達は、サービスだけでなく社内も一緒に見ているのはどこでも一緒だった!

生き残る道

  • 事業会社のインフラなら、サービス目線で何でも出来る中で特定の得意技術をもつ人としてやっていく(RPGのステータスで一つとがって他は平均的みたいのが理想)
  • ミドルの一製品を極めたかったら、mysqlAWSでRDSの人になるとかそういう道はあり
  • 既得権益を守ろうとするのではなく、世の中の変化に対応して自分達のサービスにあった形で考えや行動を変えていくのは大事
  • 覚えた技術は裏切らない

インフラ専任エンジニアが一人も居ないSmartNewsにおけるクラウド活用法

SmartNews 大平さん(この人はアプリエンジニア)

  • サイバー→LINE→smartnewsと渡り歩く

1000万ダウンロード 日米 アルゴリズムで記事の選定をしているらしい

  • なぜインフラ専任がいないのか

少人数・クラウド活用している

エンジニアの数の推移 2012 1人 2013 5人 2014 15人

大事なところにだけ集中する

  • ネイティブ、サーバアプリAPI,機会学習、データ解析
  • AWSの肩にのりサーバ運用

→サーバ、ネットワーク、データセンタの管理から開放される APIプログラマブルに管理 スタートから現在まで全てクラウド上にある

なぜフル活用出来たのか クラウドサービス向けのアーキテクトになっているから タイミング良くAWSが整ってきて料金も下がった

向かないケース

write heavyな処理 over10Gbpsトラフィック リアルタイム性 低レイヤーでカリカルのチューニングやカスタマイズが必要なもの LINEとかは向かない

仮想環境の限界はある ・ネットワーク最適化(経路とか) ・ioDrive

向くケース

ディスクアクセス少ない トラフィック少ない とか向かないケースと相反するケース

smartnewsのシステムは?

疎結合アーキテクチャ ・バックエンドは非同期多様 ・ディスクアクセス減らす為、mem多様 →永続ストレージへは遅延書き込み ・キャッシュを多様している(自作のエンジンとフレームワーク)

どのようにAWSでサーバを管理??

・provisioning tool使う

chefやfabricで誰でも透過的に使えるように 各エンジニアが一定のルールにもとづいてレシピ書く

saasを使って運用系のサーバの運用がない姿勢

saasを組み合わせて自前ではやってない DataDog 監視ツール(nagiosとか) newRelic プログラム側の pagerduty (通知系) logentries (es+kibana) chartio クラウド版のBIツール slack 監視アラートを集約 →情報の分断を防ぐために相談もアラートも全てslackに集約 →ビジネスの人も チラ見するだけで色んなチームの状況わかる →情報をAPUを使ってプロフラマブルに組み立てる

インフラエンジニアとは。。

設計・構築・運用する人

ミドルから下見る でもsクラウド出てきて、OSまではクラウド事業者がカバーしてきた

インフラとアプリのレイヤが重なってきてきた

smartnews アプリ・インフラもやってる業務は同じで、得意領域が少し違うだけ →そこには境目はない

これからのインフラエンジニアについて考えていること

グリー 梶原さん

社内インフラ・サービスインフラ共に見ている

・新サービスはAWSでやってる

グリーの事例

情報システムのインフラ

業務アプリ オンプレ ファイルストレージ クラウド・ストレージ →latencyとセキュリティの問題(機密情報どこまでおけるか)で一部オンプレ

サービスインフラ

オンプレ AWS Openstack(オンプレクラウド) ミックスで使っている

オンプレ

ほぼ物理 ラックとサーバの最適な配置は課題 複数DCで相当数サーバを管理(DR考えつつ)

OpenStack 2013

仮想化でリソースの有効活用 プライベートクラウド 本番環境・開発環境で利用 ポータル作って開発環境を楽に使えるように提供

AWS 2014〜

新規にリリースするサービスはAWS利用と決めてる

ハイブリット

DirectConnectを使って組み合わせる 保守切れのタイミングで考える 在庫を持ちたくない特殊なハード ピークとオフの差が大きいサービス

やりたい事

GCP,Softlayerを使いハイブリットクラウドに拡大 Openstackのコンテナ対応 Whiteboxスイッチ

選定基準 ・コスト 大規模調達するとまだまだ物理は安い 年に数会値下げはあるAWS

・メンテナンスのコスト サービスによってはメンテナンスの調整コストが高いものがある AWSのメンテナンスは結構あるので、それに耐えれないサービスはやらない

いいとこ

デリバリスピードはやい 不要なときにすぐすてれる

課題

ブラックボックスの為手が出せないレイヤがあり何か起きた時のインパクトが大きい

障害→サポート連絡→繰り返し、、 本質にたどり着くのに時間かかる →自分でログインしたりハードみたりというのと比較すると辛い 落ちて当然のアーキテクチャでアプリが出来てないので辛くなるとこがある(オンプレ用)

saasツールの利用も増えてきた

pagerduty datadog sumologic

これからのインフラエンジニア

サーバアプリ開発 サーバ運用 アプリ運用 ソースコードまでみてトラブルシュート DB NW DCやNWの設計

クラウド化進むとどのレイヤーも影響を受けかねない

クラウドに限った話ではないが変化を許容して柔軟に対応する事が重要

これから起きること 原因わからず負荷上がったからサーバ追加しよう

ビジネス的にはOK エンジニアリング観点はNG

何かわかんないけどioDrive入れたら早くなった

クラウドで運用は楽になるけど、これまで大変だった事がブラックボックス化され知識を得る機会がなくなってきた、 中身を知らないのは危険なことなので、競争力をつけるためにブラックボックスの中の知識をしっかりつける

要は使うのは簡単だけど、中身を知らないと存在価値ないという話

インフラエンジニアってなんでしたっけ

サイバーエージェント 桑野さん

web系インフラエンジニアの話

新サービスはほぼクラウド

でもDCがある ある程度の規模だとサーバ単価としてのコストは安い &ノウハウもある

やってること サーバ構築 適切な監視 必要な検証 障害対応 →クラウド時代になっても変わらない 只、やり方が変わっている

コード化する為のツールコモディティ化

手で自分では構築しない 基本的な部品のAPI化 スピード感ましてキャッチアップが必要

なんをするにもコード化なので、 コードを書く必要に迫られる事が多くなっている

コード化出来る土壌が整っている 仕事のやり方が変わっている

なんかが起きた時の切り分けの手段を多く持っている&出来る →これはおおきなスキルでいらなくならなくないか?

エンジニアの壁が薄くなっている 有限なパラメータをどう振り分けるか →周辺知識は伸ばしていきながら得意分野は伸ばす

サーバの負荷抑える あフォーマンス上げる 出来るだけコスト

結局は事業で御飯を食べているので、事業そのものの成長を妨げない 成長のスピードを上げる 技術を諦めることもある

インフラエンジニアという単語に悲観せずにやる 覚えた技術は裏切らない でも変化を避けることは出来ない

物理を握った人が変化を嫌い、 守りに入った時に既得権益感が出て、事業のスピードに影響 →調整・調整になりがち

コストセンターだけじゃないという事を

インフラエンジニアというくくりはもうない 得意な技術領域の異なるエンジニアがいるだけ

http://www.slideshare.net/akuwano/ss-47049999

トークセッション インフラ界のドン達に若手気鋭のエンジニアが切り込む!斬!

SmartNews 坂本さん(モデレーター) SmartNews 大平さん CyberAgent 桑野さん DeNA 小野さん GREE 梶原さん

特徴を活かしてつなぎこむ GCP,AWS,Softlayer

オンプレで育ってきたものに関してコスト逆転しないとオンプレをクラウドに移行はね。。 便利なものは使うけど、オンプレのノウハウもあるから移行コストは高いかな。

正直試算は難しい。。

サイバー 課金部分は出さないけど他はだしていけないものはない という認識

クラウド、セキュリティの壁はある。。 →今作り上げたものがあるから → 新規サービス、ゲームはAWSは共通認識でした。

監視サービスを本気でやっている人達に、片手間でやる監視ツールでは勝てないからsaasを使うのは正しい →ニッチなところにはておどかない

どこに興味を持って何をやっていきたいかを突き詰める smartnewsも社内インフラもある

SmartNewsさん素敵な面白いイベントをありがとうございました。

オフィス見学も出来たし。(ぶれぶれ。。) f:id:nagais:20150415223717j:plain f:id:nagais:20150415223452j:plain f:id:nagais:20150415223455j:plain

Elasticseach1.4にアップデートしたらkibana3からつながらなくなりはまった件

Elasticsearchを1.4にアップデートして、kibana3からアクセスしようとするとkibana3上で下記のようなエラーが出た。

Please ensure that Elasticsearch is reachable from your system

サーバ上で、curlではアクセス出来るし、自分のマシンからelasticsearch-headでもアクセス出来るのでElasticsearch自体は確実に動いている。。

curl -XGET http://localhost:9200

どうやら、kibana3からElasticsearch1.4を使うためにはkibanaのアップデートとelasticsearch.ymlへのパラメータ追加が必要そうなので下記を実施

最新版kibanaをダウンロードして、ドキュメントルート配下とかに設置

kibanaを最新版(この時だと3.1.2)にするとkibana3側でもっと親切なメッセージが出る。 Elasticsearchが落ちているか、パラメータを追記せよと書いてある。

f:id:nagais:20150116094746p:plain

②Elasticsearchにパラメータを追加 このページのままですが、下記を追加

http.cors.enabled: true
http.cors.allow-origin: "/.*/"

無事接続出来た。 テスト環境のElasticsearchをバージョンアップしたけど、kibana3からのアクセスではまるとは思わなかったのでメモとして。。

Elasticsearchで既にあるインデックスのスキーマを変更する方法

プロダクション環境でElasticsearch+kibana(fluentd)でログ可視化運用をしてみてわかった事でElasticsearchのマッピングについて記事を書いたところ、下記のようなツッコミをいただいたので実際に試してみた。

内容は、新しいフィールドが追加される時に、事前にスキーマ定義しないと型がStiringのanalyze(分かち書きあり)にされるので、事前にテンプレート作りましょという内容を書いたのですが、既存のインデックスについてもフィールドのスキーマ変更出来るという事でした。

今回の例では、[c-ip]というフィールドがdynamic_templatesでnot_analyzedが定義されていますが、このフィールドにmulti_fieldを使ってanalyze(分かち書きあり)のドキュメントも追加してみたいと思います。

まずは既存のスキーマ確認

$ curl -XGET 127.0.0.1:9200/testindex/rs/_mapping?pretty
{
  "rs" : {
    "dynamic_templates" : [ {
      "string_template" : {
        "mapping" : {
          "index" : "not_analyzed",
          "type" : "string"
        },
        "match" : "*",
        "match_mapping_type" : "string"
      }
    } ],
    "_source" : {
      "compress" : true
    },
    "properties" : {
      "@log_name" : {
        "type" : "string",
        "index" : "not_analyzed",
        "omit_norms" : true,
        "index_options" : "docs"
      },
      "@timestamp" : {
        "type" : "date",
        "format" : "dateOptionalTime"
      },
      "c-ip" : {
        "type" : "string",
        "index" : "not_analyzed",
        "omit_norms" : true,
        "index_options" : "docs"
      }
    }
  }
}

マッピング更新APIを使って、c-ipフィールドをmulti_fieldにスキーマ変更

ana.c-ipで分かち書きされたドキュメントを検索出来るようにする

curl -XPUT  127.0.0.1:9200/testindex/_mapping/rs -d '
{
  "properties" : {
    "c-ip" : {"type":"multi_field",
      "fields":{
        "c-ip":{"type":"string","index":"analyzed"},
        "full":{"type":"string","index":"not_analyzed"}
      }
    }
  }
}'

変更後のスキーマ確認

変更後のスキーマを確認すると[c-ip]がmulti_fieldに変わっています。

#この変更は、次から投入されるドキュメントに対して有効になりますが、すでにインデックス上にあるドキュメントは変わらないので要注意です。
$ curl -XGET 127.0.0.1:9200/testindex/rs/_mapping?pretty
{
  "rs" : {
    "dynamic_templates" : [ {
      "string_template" : {
        "mapping" : {
          "index" : "not_analyzed",
          "type" : "string"
        },
        "match" : "*",
        "match_mapping_type" : "string"
      }
    } ],
    "_source" : {
      "compress" : true
    },
    "properties" : {
      "@log_name" : {
        "type" : "string",
        "index" : "not_analyzed",
        "omit_norms" : true,
        "index_options" : "docs"
      },
      "@timestamp" : {
        "type" : "date",
        "format" : "dateOptionalTime"
      },
      "c-ip" : {
        "type" : "multi_field",
        "fields" : {
          "ana" : {
            "type" : "string"
          },
          "c-ip" : {
            "type" : "string",
            "index" : "not_analyzed",
            "omit_norms" : true,
            "index_options" : "docs",
            "include_in_all" : false
          }
        }
      }
    }
  }
}

簡単ですが、@johtaniありがとうございました。

プロダクション環境でElasticsearch+kibana(fluentd)でログ可視化運用をしてみてわかった事

これは Elasticsearch Advent Calendar 2014 22日目の記事です。

今回は、プロダクション環境で、流行りのFluentd+Elasticsearch+Kibanaでログ可視化というのを数ヶ月やった中で苦労した点とかはまった点を書いてみます。 というか、書き終えて思うとこれからやる人はここに気をつけた方がいいというような内容になってしまったので、既に運用されている方にはあまり役に立たないかもです。。

内容は、大きく下記3つです。

①集計(検索)の条件を考えてtemplateでnot_analyzeを指定しておく

スキーマ変更があるindexは、日単位でindex作るべし

③数値型フィールドの罠(Fluentd寄りの話)

前提として、この流れで収集しているのは下記4パターンのログ達。

Apache accesslog ・Apache errorlog ・Application log ・Mysql slowlog

①集計(検索)の条件を考えてtemplateでnot_analyzeを指定しておく

ログをElasticsearchに入れるような環境では、例えばUser-Agentで下記のようにランキングを出したりしたいと思います。 只、スキーマを定義せずにtermとかでランキングをカウントするととても悲しい事が起こる。。 要は、下記の画像のような状態。 分かち書きされた単語毎にカウントされて全く意味のないランキングが出来る。。

スキーマ定義なし

分かち書きされたものがランキングされてとても悲しい意味のないランキングとなっている

スキーマ定義なし

スキーマ定義あり

これが出したいランキングの形! スキーマ定義あり

なので、index作成前に下記のような形でElasticsearchのテンプレートを登録しておく。 今回の例でいうとagentというフィールドを分かち書きしないで格納(not_analyzed)したいので、下記3パターンのいずれかのテンプレートを適用する。

ちなみに、kibanaでランキング簡単に表示するのは、Panel Typeに「terms」を指定して、下記のように集計したいフィールドを指定するだけで簡単に出るので素晴らしい。 terms

パターン1 agentを分かち書きなしのみで登録したい

{
  "template":"weblog-*",
  "order":"1",
  "mappings":{
    "_default_":{
      "_source":{"compress":true},
      "propaties":{
        "agent":{"type":"string","index":"not_analyzed"},
        "code":{"type":"integer"},
        "size":{"type":"integer"},
        "restime":{"type":"integer"}
      }
    }
  }
}

パターン2 agentは分かち書きなしにしたいが、分かち書きありも必要

multi_fieldという形式でテンプレート定義する事で、特定フィールドに複数スキーマを適用出来る kibana等で検索する場合は、[full.agent:AAA]のような形で指定すると分かち書きされたフィールドが対象になる

※今回の例だとこちらのフィールドを指定してtermでグラフ作成すれば意図したUser-Agent一覧が出る

agent:分かち書きされたフィールドが対象になる
{
  "template":"weblog-*",
  "order":"1",
  "mappings":{
    "_default_":{
      "_source":{"compress":true},
      "propaties":{
        "agent":{"type":"multi_field",
          "fields":{
            "agent":{"type":"string","index":"analyzed"},
            "full":{"type":"string","index":"not_analyzed"}
          }
        },
        "code":{"type":"integer"},
        "size":{"type":"integer"},
        "restime":{"type":"integer"}
      }
    }
  }
}

パターン3 一つ一つ定義するのは面倒臭いので、string型を全て分かち書きしないようにする

dynamic_template(特定のフィールドタイプに対して全て同じスキーマを当てるイメージ)というElasticsearchが提供している素敵な機能を使う

{
  "template":"weblog-*",
  "order":"1",
  "mappings":{
    "_default_":{
      "_source":{"compress":true},
      "dynamic_templates":[{"string_template":{"match":"*","mapping":{"type":"string","index":"not_analyzed"},"match_mapping_type":"string"}}],
      "propaties":{
        "code":{"type":"integer"},
        "size":{"type":"integer"},
        "restime":{"type":"integer"}
      }
    }
  }
}

適用方法も一応書いておく。

#weblog_templateというテンプレートを登録
$ curl -XPUT localhost:9200/_template/weblog_template -d "`cat ~/template1.json`"
#下記コマンドでweblog_templateの中身を確認し意図したものが適用されてるか確認
$ curl -XGET "localhost:9200/_template/weblog_template?pretty" 

次回index作成時に、elasticseach-headとかでmetadataを見てテンプレートがあたったかを見てみる

スキーマ変更があるindexは、日単位でindex作るべし

fluent-plugin-elasticsearchを使って収集したログをElasticsearchに突っ込むわけですが、デフォルトでは下記のように日単位でindexが作られます。

config_param :logstash_dateformat, :string, :default => "%Y.%m.%d"

デフォルトで使ってればよかったんですが、メンテンスを考えるとindex数は少ないほうが楽という勝手な思い込みで下記の様に、月単位でindexを作成

logstash_dateformat %Y.%m

ちなみに、全ログを同じように月単位indexしてました。

ところが、、ある日、 下記のような声がチームから聞こえてきました。。

「Application logに新しい項目を追加します」

Access logに新しい項目追加します」

elasticsearchはスキーマレスなので、どんなデータでも突っ込む事は出来ますが、デフォルトだとanalyzeされてstring型で格納されます。 只、kibanaでログ解析のようなシーンで使いたい場合は、①で書いたようにデータをanalyze(分かち書き)せずに格納して使いたいシーンが多いと思います。

Fluentd側で収集する部分直せばElasticsearchに突っ込む事は出来ますが、テンプレートを作りなおしても、

適用されるのは新規index作るタイミング=1ヶ月に一回なのでそれまで新しい項目を有効に使えないという事実に直面しました。

結局は、そのタイミングでindexを日単位にする修正を入れたのですが、サービスインしている中でバックアップ取ってindexを作り直すのは辛かったので、スキーマ変更のあるログを扱う際は特段理由のない場合は、

日単位でのindex作成がおすすめかと思います。

※既にあるインデックスに対しても、ElasticsearchのAPI経由でスキーマ変更可能と@johtaniからコメントをいただきました。その手順も下記に書いてみたのでご参考までに。

日毎でインデックスを作って、リリース前にAPIで既存インデックスにマッピングを追加しておく事で無駄データを作らず、新規項目をすぐに使える運用が出来るかなと思います。

Elasticsearchで既にあるインデックスのスキーマを変更する方法 - shnagaiのインフラ備忘録

③数値型フィールドの罠(Fluentd寄りの話)

ログには当然数値として扱って分析したデータもあります。例えば、access logのレスポンスタイムとか。 只、これも考えれば当然の話なのですが下記のようなトラブルに遭遇しました。

当初、②の流れに沿ってrestime(レスポンスタイム)というフィールドにintegerタイプをテンプレートとしてあてたので、kibana上から下記のようなクエリを投げてレスポンスタイム3秒以上のリクエストをグラフ化しようとしたところ、レコードが一件もヒットしない事態が発生しました。。。

restime:[3000000 TO *]

なぜだ、、、

しばらく色々調べて気づいたのですが、Fluentdがログをパースする段階では全てのキーをstringとして扱うので、Elasticsearchとしては、Stringをintegerとしては格納出来ず上記のようなクエリが効かない状態になっていました。

なので、私の場合はログをパースするwebサーバのfluentd側の設定で、下記のようにtypesを使いrestimeを数値型に変換して、Fluentdの収集サーバに渡すようにしました。

※収集側でももちろんtypecast とかを使えば変換可能ですが、収集側にElasticsearchも同居しているという負荷を考え収集元で変換するようにしています。

types restime:integer

これで、Elasticsearch側でもテンプレートが効いて、restimeを数値としてフィールド登録するようになり無事3秒以上のリクエストを可視化する事に成功しました。

他にも、書きたいことはいくつかありますが、長くなってきたので今回はこの辺にしておこうと思います。

所感をまとめると、Elasticsearchはスキーマレスではあるけれど、ログをつっこむにあたっても事前にどう分析したいかを検討した上で、テンプレートを作成して意図したデータを取り出せるようにするのが重要だなーと思いました。

まだ、収集したものをそこまで効果的に活用出来ていないので、Elasticsearchの動向を見守りつつ意味あるログ基盤を作っていこうと思います。

elasticsearch データディレクトリを変更する

elasticsearchをローカル内で、別のマウントポイントに移動したいというシーンがあり、すごく簡単にデータ移動が行えたので一応メモとして備忘録

基本的には、elasticsearchのサービスを停止し、データを旧dirから新dirにコピーし、/etc/sysconfig/elasticsearchのDATA_DIRを新dirに向けてサービス再開するだけ。

 

感覚的には、上記方法でいけると思ったけど不安だったので、@johtaniに質問させていただいて多分いけるとの回答を得たのでいざGO!

 

ざっくり手順↓

サービス停止
$ sudo /etc/init.d/elasticsearch stop

コピー
$ pwd
新dir /opt/xxx
$ sudo cp -r /var/lib/elasticsearch/elasticsearch ./elasticsearch

所有者変更
$ sudo chown -R elasticsearch:elasticsearch elasticsearch/

データファイル変更
sudo vim /etc/sysconfig/elasticsearch

#変更部分
#DATA_DIR=/var/lib/elasticsearch
DATA_DIR=/opt/xxx/elasticsearch

サービス再開
$ sudo /etc/init.d/elasticsearch stop

正常開始のログ確認
$ sudo tail -f /var/log/elasticsearch/elasticsearch.log

[2014-07-29 21:30:48,449][INFO ][node                     ] [LOG] version[1.1.1], pid[29011], build[f158
5f0/2014-04-16T14:27:12Z]
[2014-07-29 21:30:48,449][INFO ][node                     ] [LOG] initializing ...
[2014-07-29 21:30:48,464][INFO ][plugins                  ] [LOG] loaded [], sites [bigdesk, head]
[2014-07-29 21:30:52,950][INFO ][node                     ] [LOG] initialized
[2014-07-29 21:30:52,950][INFO ][node                     ] [LOG] starting ...
[2014-07-29 21:30:53,048][INFO ][transport                ] [LOG] bound_address {inet[/0.0.0.0:9300]}, p
ublish_address {inet[/192.168.1.4:9300]}
[2014-07-29 21:30:56,181][INFO ][cluster.service          ] [LOG] new_master [LOG][PtxePQVyShGyNz0W0XW3F
A][inet[/192.168.1.4:9300]], reason: zen-disco-join (elected_as_master)
[2014-07-29 21:30:56,217][INFO ][discovery                ] [LOG] elasticsearch/PtxePQVyShGyNz0W0XW3FA
[2014-07-29 21:30:56,247][INFO ][http                     ] [LOG] bound_address {inet[/0.0.0.0:9200]}, publish_address {inet[/192.168.1.4:9200]}
[2014-07-29 21:30:57,465][INFO ][gateway                  ] [LOG] recovered [9] indices into cluster_sta
te
[2014-07-29 21:30:57,478][INFO ][node                     ] [LOG] started

【その他確認事項】
・elastic-search-headでindexが表示されていて検索出来る
・BigDeskでFile systemが新dirに変更している事
・kibanaでグラフの更新が走っている=fluentdからデータの更新が出来ている

※旧dirは1週間問題なければ削除する

簡単ですが。。

mysql ibdata1を小さくする。テーブル全て作り直したというお話

fluentd経由でmysqlにログつっこんで、レンジパーティション切ってパーティション毎にdropで楽な運用にと思ってたのに、デフォルトだとinnodbのデータはibdata1にすべて格納されると知らず、それが肥大化しすぎて圧縮不可と知ったので、物理ファイルをテーブル毎に分けるため作り直した話

やった作業の備忘録(自分の為に)


$ sudo vim /etc/my.cnf

innodbのテーブル毎ファイル保管をオンにする
※新規にテーブル作成時に適用され圧縮等できるようになる
innodb_file_per_table = 1
innodb_data_file_path = ibdata1:1G:autoextend

自作スクリプトにて対象全テーブルのdump取得
$ sudo sh winevt_dump.sh

各テーブルの件数を確認しとく

対象テーブルを削除
mysql> drop database **db;
mysql> drop database **db;
mysql> drop database **db;

サービス停止
$sudo service mysqld stop

$sudo mv /var/lib/mysql/ibdata1 /tmp/
$sudo mv /var/lib/mysql/ib_logfile0 /tmp/
$sudo mv /var/lib/mysql/ib_logfile1 /tmp/

DB作成
mysql> create database **db;
mysql> create database **db;
mysql> create database **db;

dump取得時に一番小さいテーブルをまずリストアしてみる
解凍
$ gunzip tbl_**_db.sql.2014-05-13.gz

$ mysql -uroot -p -d **db --default-character-set=utf8
<tbl_**_db.sql.2014-05-13.gz

リストアして*.idbが作成されたことを確認する

ll /var/lib/mysql

drwx------ 2 mysql mysql       4096  5月 13 10:40 2014 **db

DB毎にディレクトリが切られてその下に.idbが出来てる

# ll **db
合計 135188
-rw-rw---- 1 mysql mysql        61  5月 13 10:40 2014 db.opt
-rw-rw---- 1 mysql mysql      8722  5月 13 10:40 2014 tbl_**.frm
-rw-rw---- 1 mysql mysql 138412032  5月 13 10:40 2014 tbl_**.ibd

ここで直近のデータ引いてデータ入っていることと件数を確認

ここまでくれば後は、同じ手順を繰り返す

退避したibdata1とログを消すの忘れずに。


一番感動したのは、パーティショニングしているテーブルはこんな感じでパーティション毎に物理ファイル分かれる。
これぞ求めていた形。

合計 506649600
-rw-rw---- 1 mysql mysql           61  5月 13 11:17 2014 db.opt
-rw-rw---- 1 mysql mysql 209660674048  5月 14 01:11 2014 tbl_**#P#p201403.ibd
-rw-rw---- 1 mysql mysql 202505191424  5月 14 09:23 2014 tbl_**#P#p201404.ibd
-rw-rw---- 1 mysql mysql 106640179200  5月 14 17:15 2014 tbl_**#P#p201405.ibd
-rw-rw---- 1 mysql mysql        98304  5月 13 16:44 2014 tbl_**#P#p201406.ibd
-rw-rw---- 1 mysql mysql        98304  5月 13 16:44 2014 tbl_**#P#p201407.ibd
-rw-rw---- 1 mysql mysql        98304  5月 13 16:44 2014 tbl_**#P#p201408.ibd
-rw-rw---- 1 mysql mysql        98304  5月 13 16:44 2014 tbl_**#P#p201409.ibd

自分の無知さでリカバリにだいぶ時間かかったがいい経験になったかな。。