暮らしの技術

暮らしを豊かにする技術や、特に暮らしを豊かにしない技術があります

はてなブログの脚注を横に出すようにした Part2

2013年の今頃にはてなブログのカスタマイズをして脚注を傍注に変える*1、ということをしていた。

以来テンプレートを変更せずにいたのだけれど、最近ブログの名前を変えた*2流れでテンプレートも変えたくなってきたの6年ぶり? に手を入れた。カスタムドメインを有効にしたってのもある。

めちゃくちゃ腰が重くてめんどくさいな〜〜〜という気持ちだったのだけれど、やってみると意外とすぐ終わったので、こんなことならもっと気軽にやっておけばよかったと思った。

*1:https://tech-blog.tanatana.info/entry/2013/11/28/004413

*2:前は「無知を晒す」という名前でやっていたのだけれど、なんか逃げた感じの名前で気に入らなかった

最近やった Scrapbox の拡張

一週間の予定を入れる

最近あらゆるメモを Scrapbox で取っていて、当然仕事の進捗状況や家でのタスクも全て Scrapbox に書きながら生活している。

これまで結構スケジュールを雑にやってたのだけれど、最近忙しくなったり環境の変化もあって、このままではいかんということで、週に一回は Google カレンダーをメンテする時間をつくり、Scrapbox に写経するようにしている。*1

f:id:side_tana:20191019112923p:plain

写経無意味かと思いきや、

  • 予定をメンテすることにコストをかけることで、日頃から意識するようになる
    • 埋没費用効とはちょっと違うけど似たようなもんだと思う
  • 手で書き写すことでセルフチェック的に機能する

みたいなメリットがある気がしている。しているんだけれど、この表をつくるのが結構面倒。ということで Scrapbox のユーザスクリプトにした。

f:id:side_tana:20191019121844g:plain

日報生成ツール

会社での作業メモを日報フォーマットに変換するやつ。

- Task A
- Task B
----- ↑やった ↓これから--------
- Task C
- Task D

みたいなのを Scrapbox に毎朝書いていて、alt + カーソルキーでリストアイテムを上下に動かしながら仕事をしている。これはそのまま会社の日報フォーマットに変換できるので、選択した時に出てくるメニューに日報ボタンを作った。

f:id:side_tana:20191019115952p:plain

これを押すとシュッとフォーマットが変換され、その値が入力された日報投稿画面が登場する。ので、あとは投稿ボタンを押すだけで日報が終わって便利。

*1:不思議で、こうするようにしてから前より頻繁に Google カレンダー見る習慣がついた。

Mackerel で SSL 証明書の有効期限を監視する

最近は仕事で Mackerel を作っているので、機能理解も兼ねて自分のVPSへの導入を進めている。

parochially.hatenablog.com

この記事で書いたとおり、自分のサイトを作り直したときに let's encrypt を使って HTTPS 配信に切り替えた。証明書の発行と導入のためには let's encrypt のススメに従って certbot を使っている。

certbot を apt でインストールすると、自動で systemd timer または cron が設定され、これによって自動で証明書が更新される... はずなのだが、そのまま放置しているのは怖いので Mackerel で証明書の有効期限を監視するようにした。

Mackerel での証明書監視には以下の2つの方法がある。

1. 外形監視のオプションを利用する方法
2. mackerel-agent の [check-ssl-cert] プラグインを利用する

今回は外形監視を方を利用した。外形監視はTrialかStandardプランで利用できる。

左側のメニューから Monitors を選択し、右上の「監視ルールを追加」から外形監視を選択する。

f:id:side_tana:20190725234427p:plain

監視対象が HTTPS の場合、画面下部の「証明書の有効期限の監視」が利用できるので、ここからそれぞれの条件を入力する。

f:id:side_tana:20190725234546p:plain

7/25 はちょうど certbot が証明書を更新する日で、以下のように warning と crit が発火したあと、cert ボットによる更新が行われ、自動でアラートがcloseされた。

f:id:side_tana:20190725234731p:plain

証明書はほんとうについうっかりで無効にしてしまう事がある一方、うっかり無効にすると大変な目にあう。とくにメインシステムから切り出されたコンポーネントで、メインシステムとの通信にHTTPS を利用しているようなケースでは証明書の失効期限に気が付きにくかったり、開発者が存在に気が付かなかったりということが起きるケースが起きがち。そしてひとたび障害となると大きなダメージを残すことになる。

そういったコンポーネントでも外形監視は手軽に導入できるし、実際に導入されていることも多いので、追加で証明書の期限も監視できるのは嬉しいですね。

Mackerelのサービスメトリックで寿司の動きを可視化した

寿司に直近1時間のクリック数などを表示するグラフを追加した。

f:id:side_tana:20190723095219p:plain

グラフは Mackerel の機能を使っている。やったことは

  • ステータス取得用エンドポイントの追加
  • ステータスをMackerelに送信する systemd service の追加
    • アプリケーションサーバを直接ぶっ叩いてデータを引っ張り出す
    • curl -s localhost:$PORT/status | curl -s https://api.mackerelio.com/api/v0/services/sushi/tsdb -H 'X-Api-Key: $MACKEREL_API_KEY' -H 'Content-Type: application/json' -X POST -d @- みたいな感じ
  • ↑のサービスを定期的に叩く systemd timer の追加
  • グラフを外部公開する機能を使って埋め込む

みたいな感じ。systemd 周りで意外と時間がかかった*1けど、4はサクッとできて便利!

所感

*1:というかアプリケーションサービスに追加したエンドポイントがぶっ壊れてて常にサーバ起動時のタイムスタンプを使ってステータスを吐いていて、そこに気が付かなかった...

入門監視 読んだ

読んだ。

入門 監視 ―モダンなモニタリングのためのデザインパターン

入門 監視 ―モダンなモニタリングのためのデザインパターン

モチベーション

  • 監視設定はこれまでもしてきたけど、結構新規に入れることが多かった。
  • 使い込まれて成熟した監視設定、みたいなのを知らない
    • そういうベスト・プラクティスを知りたかった。

読んだ結果

  • 1章, 2章が良かったので定期的に読みたい
  • 結構幅広くて、ビジネスKPIとか対応チームの組み方、ネットワークからセキュリティまでカバーされててびっくりした
  • 一方で、絶対動いててほしいところは最低これぐらいあるでしょみたいな感じで下限を設定した監視をする*1、みたいな、システムの特性を加味した監視設定のテクニックみたいなのはあんまりなかった気がする。
    • これはちょっと残念、サンプリングエラーの話とかはありましたが...

読書メモ

1章: アンチパターン

  • 何度も読みたい
  • `5. 手動設定` がよい(つらい...)
    • Stackdriver を使ってた頃に開発環境とステージングと本番のため、同じ設定を3回繰り返すといったことがあったのを思い出した。
      • チームは締切に迫られていて、設定の自動化について調べる余裕がなかった
      • テスト環境では手動で設定を試していたので、それなら勉強せずに設定ができた
    • その後なんども設定を変えることはないと思っていた
    • 実際にはアプリケーションの進化と共に設定は増えたり減ったりするはず
      • そのためにも自動化は必要そう

2章: デザインパターン

  • 全体的にデザインパターンというよりベストプラクティスっぽい
  • 2.2
    • たしかにユーザに近いところから始めるのは導入が楽そう
  • 2.3
    • 作るのではなく買う!!!!
      • OSS活用しつつ内部で用意してペイする規模ならかわってくるのかも、どれぐらいからそういう話になってくるんだろ

3章: アラート、オンコール、インシデント管理

  • 3.3 インシデント管理 が参考になったので読み直したい
    • ITIL のインシデント管理の紹介
    • インシデントの際の役割の整理と、そのうち2つ以上を兼務するのは避けるべきであること、またインシデント時の役割分担は通常時の役割と関係なく設定できたほうがいいことが指摘されている
      • 例えばチームマネージャーは現場指揮官(IC, Incident Commander)よりコミュニケーション調整役として社内外の関係者に最新の情報を提供する役割のほうがおすすめ、とか
        • 過去を振り返っても自然とそうなっていた気がする
          • いいチームだったと言えそう

4 章: 統計入門

  • とくにあまり感想がない

5章: ビジネスを監視する

  • 会社KPIを監視と結びつけるのは結構重要な気がしている
    • KPI から企画が決まることが多い
      • 事前にKPIを知っておけば、システム内でどこの負荷が高まる可能性が高いか予測がつく
    • ビジネスメトリクスとシステムメトリクスが結びついてると振り返りもしやすそう

6章: フロントエンド監視

  • やったことないからやってみたいのだよなあ
    • 6.4. ロギングについて でログの収集について書かれている
      • 一回ちゃんとやってみたい
        • SaaS がどう実現しているかも興味がある

7章: アプリケーション監視

  • NewRelic の APMJava アプリケーション監視してたときはなんかいい感じでよかった
    • しかし基本的に APM ってむずいですよね
  • `/health` エンドポイントパターンはなんどかやった、あれは便利
  • 7.4 アプリケーションロギング
    • 7.4.1 メトリクス vs ログ
      • 興味深いテーマな気がする。そりゃログのほうが表現力は高いよね。
    • 7.4.2 なんのログを取るべきか
      • これは開発中も迷っていて、ログレベルについてはいつも悩んでる気がする。
        • けど手元で不具合の再現するときは DEBUG レベルのログで全部出したいと思うし、しかし本番でそんなに吐き出すわけにもいかなくてむずい。答えがないと思う。
          • それがチームにとってどういう条件で有益なのか次第といえる
  • 分散トレーシングの話もちょっと出てきた
    • GAE の古い SDK は分散トレーシングの機能があって、SDK 経由での gRPC 呼び出しはすべて記録されて、それぞれのサービスの呼び出しにどれぐらいかかったかがサンプリングされて記録される
      • 便利でした

8章: サーバ監視

  • システムを構成するさまざまなコンポーネントに対しての監視アプローチが出てきておもしろい
    • スケジュールジョブの監視面白いけど、結構ないがしろにしがちな箇所なので参考にしたい
      • 手軽に実践できそうな例が載ってて助かった

9章、10章、11章

  • それぞれネットワークとセキュリティと監視アセスメントの章
    • 確かにこの辺も監視対象になってくることがあるのか、、、と思った

*1:これはアリなんですかねえ?