astamuse Lab

astamuse Labとは、アスタミューゼのエンジニアとデザイナーのブログです。アスタミューゼの事業・サービスを支えている知識と舞台裏の今を発信しています。

Monit+Webhookでslack通知してみる

f:id:astamuse:20180709175656p:plain

お久しぶりです。インフラ・開発部のyanagitaです。
変わらず宮崎からリモートワークを行っております。

弊社ではサービス障害や優先度の高いインシデントの発生時に開発メンバー全員へのメール通知と合わせて、 担当のスケジューリングとエスカレーション機能を持つ外部サービス(https://www.pagerduty.com/)を使用していち早く対応を行っています。
ただ、中にはそれほど優先度の高くないインシデントや限られたメンバーのみで検知したい事があります。
そこで今回はその条件を満たす例として、Monit + Slackのwebhookを利用してSlackに通知する方法を紹介したいと思います。

とりあえず、全体図

f:id:astamuse:20180709175556j:plain 全体図は非常にあっさりしています。
前述したとおり、サーバ内の異常をMonitで検知して、MonitからSlackのWebhookにメッセージを送信するShellをキックする流れとなります。

では、手順を紹介します。

着信Webフックの登録

着信Webフックとは、着信Webフック用のURLに向けてメッセージをPostするだけでSlack上にメッセージを表示することできるインテグレーション用のアプリになります。
まず、着信Webフックの登録に移ります。
※ サインオン前提で進めます。

slack.com

登録はアイコン下の「設定を追加」から行います。ざっと手順は下記の通りです。

  1. メッセージを投稿するチャンネルの選択する。

  2. 以下の項目を他の着信Webフックと被らないよう変更する。
     ・着信Webフック名
     ・アイコン

ここでWebhook URLの値がPost用のURLになりますので取扱いにご注意ください。

通知Shellの実装

Webhook URLをキックするShellを実装します。以下は簡略化したサンプルです。

/opt/slack/SlackNotification.sh

#!/bin/bash

# 着信Webフックで発行したWebhook URL
webHookUrl="https://hooks.slack.com/services/XXXXXXXX/YYYYYYYY/0123456789abcdefg"

# メッセージの情報はjson形式で定義します。
# パラメータの詳細はこちら(https://api.slack.com/docs/message-attachments#when_to_use_attachments)
payload='payload={
  "attachments": [
    {
      "color": "warning",
      "fields": [
        {
          "title" : "サンプル警告タイトル",
          "value" : "サンプル警告メッセージ"
        }
      ]
    } 
  ]
}'

# Webhoookに向けてメッセージ情報をPostします。
curl -s -X POST --data-urlencode "$payload" $webHookUrl

出力結果はこんな感じです。
f:id:astamuse:20180710102626p:plain

メッセージの表示フォーマットは細かくカスタマイズ可能です。気になる方はこちらをご確認ください。

api.slack.com

payloadのメッセージ確認はこちらで行うも事ができます。
Message Formatting | Slack

Monitの設定

Monitではサーバ内の細かいチェックが可能ですが、今回はlogファイルにworningが出力されたタイミングでSlackに通知させたいと思います。
Monitの設定は以下の通りです。

check file sample_notification with path /opt/batch/sample_batch/logs/application.log
    if match "WORN" then exec "/opt/slack/SlackNotification.sh"

check fileで監視ファイルを指定し、3行目のif match句で警告ログを検知させます。検知した際は通知Shellをキックさせるためexec句で通知Shellのパスを指定します。
この時、monitの設定で検知時にメールを送信する設定を入れている場合は、通知をSlackのみに限定したいのでnoalert句でメール通知を停止させます。

check file sample_notification with path /opt/batch/sample_batch/logs/application.log
    noalert xxxxxxxx@test.astamuse.co.jp
    if match "WORN" then exec "/opt/slack/SlackNotification.sh"

以上の工程で簡単にSlackへの通知が可能になります。

最後に

monit+webhookの組み合わせでSlackへの簡単な通知を紹介ました。
通知Shellの実装次第で詳細な情報の通知することもできますし、webhookの追加開発を行えば誰が対応しているかSlack上で共有することも可能です。

アスタミューゼではまだまだエンジニア&デザイナを募集しています。 気になる方は下からご応募下さい!新しい出会いをメンバー一同お待ちしてます!

何気に便利に使えるかもしれない authorized_keys のオプション

f:id:astamuse:20180704111737j:plain

こんにちは。並河(@namikawa)です。

関東ではすでに梅雨が明けたということで水不足が心配ではありますが、すっかり気候は夏ですね。夏といえば、海にアイスクリームにラーメンといったところでしょうか。

さて、前回も書いた気がするのですが、近頃はすっかり本業のインフラ職人業が随分と減ってきていて、新鮮な技術ネタがあまりなく、エンジニアとして微妙な立ち位置ですが、せっかくの機会なので1年くらい前に気づいたLinux運用環境での小ネタでも書こうかと思います。

authorized_keys のオプション

authorized_keys は、SSHでログインする場合に、利用する公開鍵を指定しておくファイル(~/.ssh/authorized_keys)になっているのですが、実はオプションをつけることで色々と制約を設けることができます。

何もオプションを指定しない場合は、こういう感じのフォーマットになっているかと思います。

ssh-rsa AAAAB3NzaC1yc2EA........DV3UA/br namikawa@localhost

で、 man sshd とかを眺めると AUTHORIZED_KEYS FILE FORMAT の項目に色々なオプションの説明が書いてあり、使えるオプションとその概要のリストは以下の通りです。

  • cert-authority
    • CA認証局の設定
  • command="command"
    • 実行可能なコマンドの設定
  • environment="NAME=value"
    • 環境変数の設定
  • from="pattern-list"
    • 接続可能なIPアドレス(またはcanonical name)の設定
  • no-agent-forwarding
    • 認証エージェント転送禁止の設定
  • no-port-forwarding
    • ポート転送禁止の設定
  • no-pty
    • 仮想端末の割り当て禁止の設定
  • no-user-rc
    • ~/.ssh/rcの実行禁止の設定
  • no-X11-forwarding
    • X11(画面)転送禁止の設定
  • permitopen="host:port"
    • ssh -L のポート転送先を、指定されたホスト・ポートのみに限定する設定
  • principals="principals"
    • cert-authorityで認証が許可されている principal 一覧の設定
  • tunnel="n"
    • 使用する tun デバイスの設定



細かい説明については、下部に man の抜粋を転載しておきますので、そちらでご確認いただければと思います。

オプションの指定方法

こちらも man にサンプルの記載があるのですが、以下のように指定を行います。 例えば、 from オプションを使って接続元の制限をしたい場合は、以下のように指定します。

from="192.168.10.0/24,*.example.com" ssh-rsa AAAA(以下略)

また、複数の設定を同時に指定したい場合などは、カンマ区切りで以下のように指定します。

from="192.168.10.0/24,*.example.com",no-pty,no-port-forwarding ssh-rsa AAAA(以下略)

このような感じで、公開鍵情報の手前に用意されているオプションを指定することで有効となります。

所感

さて、 authorized_keys も色々とオプションが指定できるんだなー、という感じではあるのですが、ではどういう時に使うのだろうなという点です。

上記のオプションを眺めてわかることは基本的に制約に関する設定になっています。

サーバ管理者がユーザごとに何かしらの制約を課したくて、このやり方でオプションの設定を入れたとしても、ユーザは一度ログインできてしまえば、この設定は変な話、変更できちゃうんですよね。

なので、基本的には、ユーザ自身がオペミス防止などの観点から、必要以上の権限を持たない、もしくは使えなくするように入れる制約となりそうです。

こんな感じで、公開鍵単位で色々と制御できるのは、何かと便利なシーンもあったりするので、頭の片隅に置いておくと役にたつかもしれません。何かのお役に立てれば幸いです。

おまけ

本エントリとは、全く関係のない余談にはなるのですが、このエンジニアブログを始める際に、「企業向けエンジニアブログの作り方」のエントリで書いた通り、持ち回りのターン内でKPI値に沿った優秀エントリに選ばれると、豪華ランチがプレゼントされます。

で、3ターン目に書いた「nginx + ngx_mruby でSSL証明書の動的読み込みを実現して、作業がとても楽になった話」がなんと優秀エントリに選ばれたので、遠慮なく築地で濃厚なうに丼をいただき、大変幸せな気分になりました・・・!

f:id:astamuse:20180704111840j:plain

・・・はい。

最後に、弊社ではエンジニア・デザイナーを絶賛大募集しておりますので、少しでも気になれば、カジュアルにランチでもしながらお話ししましょう。疑問・質問などございましたら、お手数ですが (@namikawa) まで気軽にDM等いただければと思います。

それでは!=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́

@namikawa が書いた過去記事)

参考: man sshd - AUTHORIZED_KEYS FILE FORMAT

AUTHORIZED_KEYS FILE FORMAT
     AuthorizedKeysFile specifies the files containing public keys for public key authentica‐
     tion; if none is specified, the default is ~/.ssh/authorized_keys and
     ~/.ssh/authorized_keys2.  Each line of the file contains one key (empty lines and lines
     starting with a ‘#’ are ignored as comments).  Protocol 1 public keys consist of the
     following space-separated fields: options, bits, exponent, modulus, comment.  Protocol 2
     public key consist of: options, keytype, base64-encoded key, comment.  The options field
     is optional; its presence is determined by whether the line starts with a number or not
     (the options field never starts with a number).  The bits, exponent, modulus, and com‐
     ment fields give the RSA key for protocol version 1; the comment field is not used for
     anything (but may be convenient for the user to identify the key).  For protocol version
     2 the keytype is “ecdsa-sha2-nistp256”, “ecdsa-sha2-nistp384”, “ecdsa-sha2-nistp521”,
     “ssh-ed25519”, “ssh-dss” or “ssh-rsa”.

     Note that lines in this file are usually several hundred bytes long (because of the size
     of the public key encoding) up to a limit of 8 kilobytes, which permits DSA keys up to 8
     kilobits and RSA keys up to 16 kilobits.  You don't want to type them in; instead, copy
     the identity.pub, id_dsa.pub, id_ecdsa.pub, id_ed25519.pub, or the id_rsa.pub file and
     edit it.

     sshd enforces a minimum RSA key modulus size for protocol 1 and protocol 2 keys of 768
     bits.

     The options (if present) consist of comma-separated option specifications.  No spaces
     are permitted, except within double quotes.  The following option specifications are
     supported (note that option keywords are case-insensitive):

     cert-authority
             Specifies that the listed key is a certification authority (CA) that is trusted
             to validate signed certificates for user authentication.

             Certificates may encode access restrictions similar to these key options.  If
             both certificate restrictions and key options are present, the most restrictive
             union of the two is applied.

     command="command"
             Specifies that the command is executed whenever this key is used for authentica‐
             tion.  The command supplied by the user (if any) is ignored.  The command is run
             on a pty if the client requests a pty; otherwise it is run without a tty.  If an
             8-bit clean channel is required, one must not request a pty or should specify
             no-pty.  A quote may be included in the command by quoting it with a backslash.
             This option might be useful to restrict certain public keys to perform just a
             specific operation.  An example might be a key that permits remote backups but
             nothing else.  Note that the client may specify TCP and/or X11 forwarding unless
             they are explicitly prohibited.  The command originally supplied by the client
             is available in the SSH_ORIGINAL_COMMAND environment variable.  Note that this
             option applies to shell, command or subsystem execution.  Also note that this
             command may be superseded by either a sshd_config(5) ForceCommand directive or a
             command embedded in a certificate.

     environment="NAME=value"
             Specifies that the string is to be added to the environment when logging in
             using this key.  Environment variables set this way override other default envi‐
             ronment values.  Multiple options of this type are permitted.  Environment pro‐
             cessing is disabled by default and is controlled via the PermitUserEnvironment
             option.  This option is automatically disabled if UseLogin is enabled.
     from="pattern-list"
             Specifies that in addition to public key authentication, either the canonical
             name of the remote host or its IP address must be present in the comma-separated
             list of patterns.  See PATTERNS in ssh_config(5) for more information on pat‐
             terns.

             In addition to the wildcard matching that may be applied to hostnames or
             addresses, a from stanza may match IP addresses using CIDR address/masklen nota‐
             tion.

             The purpose of this option is to optionally increase security: public key
             authentication by itself does not trust the network or name servers or anything
             (but the key); however, if somebody somehow steals the key, the key permits an
             intruder to log in from anywhere in the world.  This additional option makes
             using a stolen key more difficult (name servers and/or routers would have to be
             compromised in addition to just the key).

     no-agent-forwarding
             Forbids authentication agent forwarding when this key is used for authentica‐
             tion.

     no-port-forwarding
             Forbids TCP forwarding when this key is used for authentication.  Any port for‐
             ward requests by the client will return an error.  This might be used, e.g. in
             connection with the command option.

     no-pty  Prevents tty allocation (a request to allocate a pty will fail).

     no-user-rc
             Disables execution of ~/.ssh/rc.

     no-X11-forwarding
             Forbids X11 forwarding when this key is used for authentication.  Any X11 for‐
             ward requests by the client will return an error.

     permitopen="host:port"
             Limit local ``ssh -L'' port forwarding such that it may only connect to the
             specified host and port.  IPv6 addresses can be specified by enclosing the
             address in square brackets.  Multiple permitopen options may be applied sepa‐
             rated by commas.  No pattern matching is performed on the specified hostnames,
             they must be literal domains or addresses.  A port specification of * matches
             any port.

     principals="principals"
             On a cert-authority line, specifies allowed principals for certificate authenti‐
             cation as a comma-separated list.  At least one name from the list must appear
             in the certificate's list of principals for the certificate to be accepted.
             This option is ignored for keys that are not marked as trusted certificate sign‐
             ers using the cert-authority option.

     tunnel="n"
             Force a tun(4) device on the server.  Without this option, the next available
             device will be used if the client requests a tunnel.

     An example authorized_keys file:

        # Comments allowed at start of line
        ssh-rsa AAAAB3Nza...LiPk== user@example.net
        from="*.sales.example.net,!pc.sales.example.net" ssh-rsa
        AAAAB2...19Q== john@example.net
        command="dump /home",no-pty,no-port-forwarding ssh-dss
        AAAAC3...51R== example.net
        permitopen="192.0.2.1:80",permitopen="192.0.2.2:25" ssh-dss
        AAAAB5...21S==
        tunnel="0",command="sh /etc/netstart tun0" ssh-rsa AAAA...==
        jane@example.net

時間の使い方について考えると見せかけつつ無駄な時間をどうコントロールするかという話

f:id:astamuse:20180627111049j:plain

こんにちはnishikawaです。最近、急に暑くなってきて一気に夏感が増してきておりますが、皆様どうお過ごしでしょうか。

さて、今回は時間について個人的な考えをつらつらと書いていこうと思います。対象は新社会人の方や人生に何か焦りや迷いを持っている人です。そういう人たちに何かきっかけを与えることができたらいいと思っています。

私は高校を卒業して諸事情によりコンピュータを触り始めてから12年ぐらい色んなことをしてきましたが、その間ずっと時間との向き合い方というのが人生の課題になってきました。学生の時には勉強と部活、バイトをしながら技術をどう磨いていくかに悩まされ、社会人になってからは仕事と人付き合いをしながらどう技術を磨いていくかに悩まされ続けております。きっとITエンジニアの中にはそのような悩みを持ちながら生きている人も多いのではないかと思います。

ITエンジニアには様々な時間が必要ですが、その中でも新しいことへのキャッチアップ学習についてはほぼ全ての方が取り組んでいるかと思います。

しかし、人間には悲しいことに1日24時間しか与えられていない上に、睡眠をはじめとする各種生理現象や生活に必要な作業で半分近くの時間を無条件に消費しなければなりません。加えて、コミュニティを形成するという人間の性質により社会活動を行うため残りの時間のほとんども自然と何かに消費させられます。(奇しくもそういうものがあるために技術が発展し我々に居場所があるのでここについてはとても難しい考えだとも思っています)

こうなってくると、本当に自由な時間というのはごく限られてくるのですが、一般的な時間でそれらを算出すると

24(1日) - 8(睡眠) - 3(風呂、食事、トイレなど) - 8(業務時間) - 2(移動時間) = 3 時間

で、3時間しか取れません。子供がいるとこの時間さえもなくなるため、結婚してスキルアップに割ける時間が減ったと感じている方は世の中には多いと思います。

時間の確保をどうするか

f:id:astamuse:20180627112658j:plain

前述の3時間という数字はすべてがまとまった時間として与えられる訳ではありません。冷静によく考えてみると分かることですが、これらの時間は非常に細切れの状態で私たちに与えられるのです。スキルアップにはこの細切れにされた時間のなかでできるものと、ある程度まとまった時間がないとできないものに分かれますが、後者を行うための時間を確保するためによく睡眠時間を削るという方法が用いられます。

この方法はすごく簡単にまとまった時間が手に入るので私もよくやりますが、多分、というか絶対に体にはよくないのでオススメはできません

ちなみに私は前職などの諸事情によりショートスリーパーになっているので、この方法をよく使うのですが、これによりどれだけの時間が得られているかというと

24(1日) - 4(睡眠) - 5(風呂、食事、トイレ、家事など) - 8(業務時間) - 3(移動) = 4 時間

最大で4時間ぐらいは得られています。金曜や土曜など次の日を考えなくていい時は丸っと睡眠を削ったりもするので、1日のアベレージは5時間を超えます。

ただ、もう一度言いますが、この方法は体に良くないのであまりオススメできません。というかやらない方がいいです。

仕事をスキルアップにつなげるという考え方

f:id:astamuse:20180627112051j:plain

睡眠時間を削らないならどうしたらいいのか?答えはすごく単純で業務をスキルアップに繋げればいいのです。なぜなら、会社で仕事をしている時間は1日の中でもかなり多くの時間を占有しているからです。これをスキルアップに繋げられるのであれば使わない手はありません。

しかし、全ての業務が常に自分の目指すところと向きを同じにしている訳ではありません。むしろその方向を向いていない業務の方が多いと思います。

ここがみんなを悩ませているところで、大人を腐らせる要因だと私は思っています。現に今までそうした先輩や後輩をたくさん見てきました。口癖は「この会社(もしくは部署や仕事)じゃスキルはたまらないよ」です。個人的にはそう思うなら飯食う時間や睡眠時間を削ってスキルためろよ!と思うのですが、そういう発言は炎上の元になる可能性があるので胸に秘めておくことにします。

さて、こうした大人にならないために我々が常日頃から意識しなければいけないことは上司にちゃんと自分の考えをアピールして提案することだと思います。こういう技術に興味がある。こういうことをやりたい。業務のここに不満がある・・・等々

これらをちゃんとしていれば、結構な割合で自分の目的に対してベクトルのあった業務が割当たる可能性が高くなります。逆にいうと、こういうアピールを日頃から行ってない人が多くいることも確かで、その結果が前述の腐った大人になる訳です。

以上の努力を行なったが何も改善されない場合は最後の手段として転職することをオススメします。その際は弊社の転職ナビを是非ご活用ください。

systemengineer-job.com

無駄な時間は本当に無駄なのか?

f:id:astamuse:20180627112332j:plain

さて、ここまでエンジニアとして時間を有効に使うために私がどいういう考えで生きてきたかを書いてみました。人間、本当に時間は限られていて社会人になったらもう向かうのは棺桶だけです。そのため、限られた時間を有効に使う上で無駄な時間の削減は必須です。しかしながら一見無駄に見える時間でも、それらが本当に無駄なものなのかはちゃんと吟味したほうがいいと思います。

私はよく1週間ごとに自分への振り返りを行なっており、その際に無駄だと思ったことをピックアップし、それらの分類を行うようにしています。

例えば、よく無駄な時間として以下のものが挙げられる傾向がありますが、

  • 移動時間
  • 不必要な会議
  • 人付き合い
  • 色々頑張ったが何も成果につながらなかった時間 ... etc

これらに対して、私は以下のように分類を作って分けています。

  • 本当に不要で排除できるもの (ex. なんの生産性もない会議とか)
  • 本当に不要だが排除できないもの (ex. 通勤時間とか)
  • 不要だと思うが時と場合によっては排除すべきではないもの (ex. 人付き合いとか)

この分類に従って本当に無駄だと思うものは次週から排除するように動きます。排除できないものについては有効活用できるようにあれこれ考え次週から行動します。

そして、一番難しいのが3番目の「不要だと思うが時と場合によっては排除すべきではないもの」です。何が難しいかというと、ピックアップした不要だと思っている時間をこの分類に入れるのが難しいです。

ここには一番頭と精神力を使います。自分の中で形成されている価値観を壊すことができないと大切なものを失います。これの最たるものが人付き合いです。特に苦手な人との人付き合いなんかはこの分類に入れるのは相当難しいです。

しかし、これをやることによって自分にどんなメリットがあり、後々時間を短縮してくれるかもしれないという可能性を考えられるかどうかがこの分類に入れるための最大のカギです。要するに時間に対して時間で投資するのです。

頑張ったが何の成果も上がらなかった時間についても同じです。得た失敗から対策を練ることにより、今後何回同じことが起きても即座に対応できます。

ここまで無駄な時間について色々と考察し、個人的に行なっていることをまとめましたが、重要なことが一つあります。それは、無駄な時間の取捨選択のバランスです。多くを拾いすぎてもダメですし、捨てすぎてもダメで、そこには常にバランス感覚が求められます。自分に向き合う時間を多く作れれば作れるほど、この分類の精度は上がると思うので週一回は自身に対して振り返りを行うことをオススメします。

時間を無駄にすることも時には必要

f:id:astamuse:20180627112500j:plain

最後の最後で今までの考え方を一気にひっくり返すようなタイトルになりましたが、時間を無駄にすることも時には大事だよということを最後に言っておきたいです。

学生のころは分からなかったですが、無駄な時間を過ごすというのはとても贅沢なことです。何も考えずに半日庭を眺めているというような時間を過ごすのも人生には時として必要です。特に仕事でもスポーツでもそうですが、スランプに陥ったりした時には一回投げ出して触れない期間を作ることも大事かなと思います。

なので、無駄が全て悪いとは思わずに広い心をもって生きていくことを強くお勧めしたいです。この記事を読んでくれた人が自分の時間に対する価値観を見つめる際に少しでも役に立ててくれれば幸いです。

Copyright © astamuse company, ltd. all rights reserved.