UNIX的なアレ

UNIX的なこととかいろいろ

fluentdで集約したerror_logをslackに流すと捗る

f:id:wadap:20140819095929j:plain

nanapiでは社内のチャットツールに、Slackを導入しています。Slackの便利なところはintegration周りで、要するに他のツールとの連携が非常にし易いんですね。そういった、Chatを中心にした業務効率化を最近ではChatOpsと呼んだりします。

http://nanapi.co.jp/blog/2014/07/24/nanapi_chatops/

ChatOpsの重要な点はコンテキストを共有できる点ですよね。「○○ってエラーログが出てるよ」みたいな情報を直接誰かに伝えるのではなく、ログが出ているという状態をChatを経由して同じものを見ることで、説明が非常にラクになります。

ほかにもデプロイをHubot経由で指示したり、ステータス取得をしたりなど様々な使い方がありますがやはり重要なのは同じ画面を皆が見ているということですね。そういった点がChatOpsの大きなメリットとしてあると思います。

集約したログもchatに流す

というわけで、error_logもChatに流したほうが捗るよねという話です。fluentdはみんな使っていると思うのでこのあたりの細かい説明は割愛します。Slackに流すためのpluginもすでに開発されています。

GitHub - sowawa/fluent-plugin-slack

これをつかうことで簡単に流すことができます。ただ、そのままだと若干不便なのでnanapiの設定の仕方を紹介します。使用するPluginはこのあたりです。

次からは、設定方法を紹介します。

環境構築用のVagrant

とりあえず試すにはVagrant + Chef + Berkshelfを使うのが便利です。td-agent用のcookbookが用意されているので、それを使ってインストールがラクでしょう。Vagrantfileは以下のようになります。

# -*- coding:utf-8 mode:ruby -*-
Vagrant.configure('2') do |config|
  config.berkshelf.enabled = true

  config.vm.define :vm do |config|
    config.vm.box     = 'centos-6.4'
    config.vm.box_url = 'http://developer.nrel.gov/downloads/vagrant-boxes/CentOS-6.4-x86_64-v20130731.box'
    config.vm.provision :chef_solo do |chef|
      chef.json = {
        'td_agent' => {
          'plugins' => [
            'file-alternative',
            'forest',
            'slack',
            'rewrite-tag-filter',
          ],
        }
      }
      chef.run_list = [
        'recipe[td-agent]',
      ]
    end
  end
end

ログ送信側のtd-agent.conf

まず、error_logを集約する必要があります。fluentdは標準でapacheもcombinedをparseする設定をもってくれていますが、error_logはそのままだと動きません。以下のようにして、設定することでerror_logをちゃんと取得できます。

<source>
  type forward
  port 24224
</source>

<source>
  type tail
  format apache
  path /var/log/httpd/access_log
  pos_file /tmp/access_log.pos
  tag nanapi.httpd.access_log
</source>

<source>
  type tail
  format /^\[[^ ]* (?<time>[^\]]*)\] \[(?<level>[^\]]*)\] (?<message>.*)$/
  time_format %b %d %H:%M:%S.%L %Y
  pos_file /tmp/error_log.pos
  path /var/log/httpd/error_log
  tag nanapi.httpd.error_log
</source>

# apache logs
<match **.**>
  type forward
  <server>
    host forward_host
    port 24224
  </server>
</match>

APIKEYの発行

f:id:wadap:20140819094826j:plain

SlackのIncomingWebHookという機能を使います。以下のURLからアクセスできます。

https://xxx.slack.com/services/new

f:id:wadap:20140819094914j:plain

ここから設定すると、この画面にいきます。このURLの中で指定されているTokenがあとで使用するAPIKEYになります。

集約した側のtd-agent.conf

さて、つぎは集約してSlackに送る側の設定です。まずディレクティブで受け取ります。nanapiでは、タグの先頭をサービス名にするというルールで運用しているので、先頭に複数のサービス名をmatchさせるルールを書いています。

そして、そのあと、rewrite_tag_filterを経由してerror_logのlog_levelをみてタグを付け直しています。これによってというディレクティブにマッチします。このあたりは、実際に本番で運用している設定の簡易版となっていますので、実運用に合わせて変更すると良いと思います。

<source>
  type forward
</source>

<match {nanapi,nanapiworks}.httpd.error_log>
  type copy
  <store>
    type forest
    subtype file_alternative
    <template>
      buffer_chunk_limit 2g
      path /var/log/fluent/${tag_parts[0]}/httpd/%Y/%m%d/${tag_parts[2]}.%Y%m%d
      time_slice_format %Y%m%d
      compress gzip
    </template>
  </store>

  <store>
    type rewrite_tag_filter
    rewriterule1 level error slack.error
  </store>
</match>

<match slack.**>
  type buffered_slack
  api_key xxxxxxxxxxxxxx
  team xxxxxx
  channel %23fluentd
  username fluentd
  color danger
  icon_emoji :fluentd:
  buffer_path /tmp/td_slack_buffer
  flush_interval 5s
</match>

より効率的なchannel運用を

さて、こんな感じでerror_logを運用していたりします。slackのpluginは設定にもある通り、colorなども設定できます。このあたりと、投稿するchannelをうまく設定することでベストなerror_log運用を目指したいですね。

JAMTRACK CENTRALを知った

最近知ったのですが、こんなサービスがあるんですね。

JTC Guitar

ギタリスト向けのサービスで、プロギタリストの曲の楽譜+動画+オケトラックが販売されているサイトです。僕が知っている有名なギタリストもそこそこいました。

実際は、このサイトをしるきっかけになったギタリストがいます。Jack Thammaratというギタリストでこのサイト内で販売もされています。この曲に完全に虜になってしまい、つい購入してしまいました。


Jack Thammarat - &quot;Awakening&quot; (Original) Live in ...

iTunesでも販売されていますが、素晴らしいギタリストだなぁと思います。なんかの大会の優勝者らしいですね。タイの方のようです。

http://www.jackthammarat.net/

アンプもLANEYとエンドース契約をしているみたいですね。素晴らしい音しています。あまり高くないしちょっと気になるところですね。

http://www.soundhouse.co.jp/shop/ProductDetail.asp?Item=451%5Eirtstudio%5E%5E

Route53でドメインが購入できるようになった

f:id:wadap:20140801100214p:plain

Route53のGUIが変更されたのと同時にドメインの購入まで出来るようになったみたいですね!

ドメインが空いてるか調べる

f:id:wadap:20140801100258p:plain

f:id:wadap:20140801100308p:plain

こんな感じで空きを調べられます。howtojapanというのは、nanapiを作るときの仮の名前でした。howtojapanにしなくて本当に良かったと思っています。

登録する

f:id:wadap:20140801100448p:plain

f:id:wadap:20140801100506p:plain

こんな感じで登録できます。すごくシンプルで簡単に購入できます。若干高いですが、AWSのアカウントでドメインまですべて管理できるのはすごく便利です。事業でつかっているドメインを管理するときの決定版になるかもしれませんね!

文章の書き方を変えるだけで社内の情報共有は加速する

社内の情報共有で困っている会社は多いみたいですね。でも実は、nanapiという会社ではそこまで困っていなかったりします。元々文章を扱う会社というのもありますし、ドキュメント化して共有しようという風土が染み付いているからだと思います。

そういったこともあり最近登壇するときなど、社内の情報発信などについて話す機会が増えました。弊社では社内における情報共有のツールとして、Qiita:Teamを使用しています。

生産性を向上させる情報共有ツール - キータチーム(Qiita Team)

全員がMarkdownで文章を書く

実際にnanapiではQiita:Teamを導入してから、現在ではエンジニアだけでなくアルバイトも含めた全社員がここに様々なドキュメントを投稿しています。

Qiita:TeamはMarkdownで書けるようになっています。つまり、社内のメンバーは全員がMarkdownで文章を書くことができます。これが情報共有においてはすごく重要なことだと思っています。

文章構造を意識する

Markdownで文章を記述するということは、ちゃんと文章構造を考えて書く必要があります。マークアップほどこだわる必要もありませんが、headingやparagraphやlistくらいは理解する必要がありますね。

このあたりをしっかりと使いこなすということは、結果的に文章が簡潔になり読みやすくなりますよね。

最初から出来ないにしても、nanapiでは社内がそのような文化になっているため全員ができてあたりまえという風土になっています。その結果、メンバー全員が簡潔な文章をかけるようになり、より意思疎通がスムーズできるようになっています。

個人依存の記号は使わない

よくあるパターンが、アジェンダや議事録でその人ルールの記号がでてくる場合です。

☆本日のアジェンダ

【議題1】次期プロジェクトについて

<決議事項>
・プロジェクトメンバー
・予算
・リリーススケジュール

恐らくこういったテキストを目にしたことがある方は多くいるのではないでしょうか。テキストを書いた本人にしかわからない、謎の記号であふれています。

たちがわるい場合は、アジェンダや議事録によって記号の意味が変わります。こういった訳のわからない独自ルールを使わせないという意味でも、Markdown化する意味はあると思います。

スピードが大事

議事録など、会議が終わった瞬間に出てて欲しいんですよ。Qiita:TeamならPull Requestみたいなのが送れるし、違っていたらすぐに指摘できます。

でも会議がおわって翌日に議事録があがる時点で価値が半減します。参加した人の記憶も薄れるからです。お互いに記憶が新鮮なうちにブラッシュアップしなければいけない。

もっというと、プロジェクタに映しながら直接Markdownで書きながら終わった時点で議事録があがってるくらいにすべきですね。

どのようにして社内に浸透させるか

これは導入した人が必死に書き続けるしか無いです。そのようにして社内の風土は形成されますし、口でいうより使い方を見せた方が早いです。

nanapiでは以下の順番で広めました。

  1. 和田1人が書き続ける
  2. エンジニア中心に展開
  3. デザイナー・ディレクターを含め展開
  4. 全社員に展開
  5. アルバイトを含めた全従業員に展開

実際に、非常にうまくワークしていると思います。やり方はいろいろあると思いますが、変に敷居をあげすぎずにとりあえず投稿させていくというところから始めるのがコツなのかな、と思っています。

最後に

というわけで、文章の共有方法についてすこし考えてみました。重要なのは、自分のやっていることを自分に閉じないような風土にすることだと思っています。

これにより社内の情報共有は加速しますし、確実に成果がでるものだと思っています。nanapiではTechBlogをやっていることもあるので、社内・社外問わずこれからも情報発信を続けていきたいと思っています。

http://nanapi.co.jp/blog/

nanapiの開発現場をどのようにして回しているかというテーマで話してきました

【StartupWeekendTokyo x DevLOVE】イケてるスタートアップの開発現場の話が聞きたい! - スタートアップウィークエンド東京 | Doorkeeper

というわけで、話してきました。資料はこちら!

「会社は学校じゃねぇんだよ」というエントリで思ったこと

http://ameblo.jp/junpei-1114/entry-11889404525.html

なんとなく便乗エントリー。

まぁこの内容は絶対にはてな民は嫌うだろうなーという内容ですよね。サイバーエージェントってだけで敵視するわけだし、そのうえイケメンっぽいし、若くして社長だし。はてな民が敵視するだけの要素はたくさん持っているわけです。

正直なところ、彼の文章はすごく感情的な文章だし、表現方法も拙い。やっぱり若いなぁというのが僕自身の印象です。ただ、正直このあたりの彼の主張はどうでもいいかな。うちの代表も触れていますが、彼のすごいところって視点の高さだと思うんですよね。

サイバーエージェントグループの一員として、 21世紀を代表する会社を創るため。 そして、WAVESTを日本を代表する会社にするため。 そのためだけに会社に来ています。

ここで注目したいところは、サイバーエージェントが掲げている企業理念をそのまま受け継いでいるところ。

自分自身がこうなりたい、こういうことをしたいという目線で話す人はたくさんいます。それ自体は悪いことじゃないし、大切なことです。

でも、「自分の会社をこうしたい」という目線で話せるのはなかなかだと思いますよ。まさにサイバーエージェントのDNAなのでしょうが、それでもこういう高い視点というのは、立場が作るものですよね。

出来たばかりの会社かもしれないけど、代表という立場にならないと見えないことってたくさんあると思います。そういう高い目線の人間を増やすという意味でも、サイバーの抜擢人事ってすごく価値があることなんだなぁと思いますね。

nanapiではエンジニア向けインターンを募集します!

f:id:wadap:20140702103915j:plain

nanapiでは、学生向けのサマーインターンを実施します!実際に社員が働いているオフィスで、一緒に開発をしてみませんか?

実際にやってもらう内容はテーマに沿った開発を5日間かけて行います。開発の面倒をみてくれるメンターも、現在nanapiの現場で開発をしているメンバー。

実際にnanapiを作っている現場を味わうことができます。

5日間で5万円の報酬と、昼食はそれとは別に支給します。応募はwantedlyからどうぞ!

学べる!作れる!新規サービス制作に挑戦するエンジニアインターン - Supershipのエンジニアリングの採用 - Wantedly