もりはやメモφ(・ω・ )

インフラなエンジニアからSREへ

入門 監視を読みました

あまり余裕の無い数週間が終わり、のんびりできる休日がやってきたので積読になっていた「入門 監視 モダンなモニタリングのためのデザインパターン」を読みましたので感想をメモ。

f:id:morihaya:20200614233145p:plain

システム運用に関わるエンジニアには広くお勧めしたい一冊

読み終わった第一声としては「めっちゃ良かった」でした。新人時代からインフラエンジニアとしてキャリアを中心に積んできた手前、システム監視にはある程度経験を持っているつもりでしたが

  • ストーリーとして申し分ない章構成
  • 内容の抜群の粒度(入門、というタイトルの通りのレベル感)
  • 適切に整理され、上手く言語化されたノウハウの数々
  • Witに富んだTipsやメモ

などに魅了され一気に読破してしまいました。本の厚さとしても丁度よく梅雨の休日のおともに最適でしょう。

章構成について

名著とされる多くの専門書と共通し、本書の章構成も素晴らしいものとなっています。 目次はオライリー社のページで確認できますので見ていただければ良いですが、どのように素晴らしいかの感想を述べます。

シンプルな2部構成

本書は以下の2部から構成されています。

  • 第Ⅰ部 監視の原則
  • 第Ⅱ部 監視戦略

原則を学び、戦略を実践する。シンプルですがわかりやすいストーリーです。

歴戦の監視上級者であれば、第Ⅱ部から読み進めるのも悪くはありませんが、ぜひ第Ⅰ部から順に読み進めるのが良いでしょう。日頃から実践している工夫や取り組みが本文で言語化されて新たな自信につながるかもしれませんし、アンチパターンなどを通して新たな気づきを得られるでしょう。

原則の多くは基本だが、基本がどれほど重要か

第Ⅰ部は "監視の原則" と題して以下の4章で構成されています。

  • 1章 監視のアンチパターン
  • 2章 監視のデザインパターン
  • 3章 アラート、オンコール、インシデント管理
  • 4章 統計入門

"1章 監視のアンチパターン"で紹介されるいくつか*1に胸を痛めたあとで、"2章 監視のデザインパターン"でなるほどそれな!となり、"3章 アラート、オンコール、インシデント管理"で共感と明日から実践したいノウハウを学び、"4章 統計入門"でフワッとしていたいくつかの用語の理解を改めて行う素晴らしい流れです。

特に3章では、週単位でオンコールをチームで回しながら夜間アラートに叩き起こされる生活をしばしば送っているだけに、実体験を伴った共感と学びがありました。すぐやりたい内容としては

  • アラートの棚卸し
  • 自動復旧の取り組み

の2点で、不要なアラートの見直しと、そもそもアラートを上げさせないための自動復旧についてより意識して取り組んでいきたいと考えました。

もちろんこれまでも同様の動きはチームでもたびたび行ってきましたが、言語化されたことでより方針が固まった感触があります。

実践的な第Ⅱ部

第Ⅱ部は "監視戦略" と題して以下の章立てです。

  • 5章 ビジネスを監視する
  • 6章 フロントエンド監視
  • 7章 アプリケーション監視
  • 8章 サーバ監視
  • 9章 ネットワーク監視
  • 10章 セキュリティ監視
  • 11章 監視アセスメントの実行

私は大抵の技術書を読み始める前にざっと目次を確認するのですが、第Ⅱ部の各章の並びを見ただけで反省の気持ちと、この本はとても良いはずとある程度確信しました。

反省の理由として、私が日頃から意識し改善を行う監視を順番に並べるとすると以下になり、"5章 ビジネスを監視する"と"6章 フロントエンド監視"はあまり意識していませんでした。

  • 8章 サーバ監視
  • 9章 ネットワーク監視
  • 7章 アプリケーション監視
  • 10章 セキュリティ監視

しかし本書の章構成は私に対して以下の言葉を力強く語りかけてきたように感じました。

「何よりもまずはビジネスの観点が大事で、次にユーザに近いフロントエンドだ」

実際に章を読み進めるとKPIのダッシュボードは別のチームの別のツールで実現されていることに気づき「あれもまた監視だったのだ」と再発見につながりました。

フロントエンド監視についてもNewRelicやGoogle Analyticsを通して既に行っている内容も多くありましたが、リアルユーザ監視とシンセティック監視など言葉として整理されたことで理解が進んだと感じています。

付録もナイス

付録についても見過ごせません。特に付録Cについては MackerelのPMを担当されていたsongmu氏による監視SaaSへの手引書になっていて、これもまた読み応えのある内容でした。私はmackerelユーザの端くれでもあるため共感と共に読み進めていましたが"C.6.4 自動復旧のためのアイデア"でmackerel-agentのアクションを自動復旧に利用する部分を読み、すぐにでも実装したい機能を思いつくことができました。

mackerel-agentのアクション機能自体は知識としては知っていましたが、本書で具体的に自動復旧と紐付けられたことで実装のアイデアが浮かんできました。これでまたトイルを一つ滅ぼすことができそうで大変嬉しい気持ちです。

まとめ

以上、入門監視についてざっと感想を書きました。改めて良い本だったと思います。 なお余談ですが本書の大部分は家のリビングでそれぞれ自分のことをやっている家族を横目に黙々と読んでいたのですが、子供からは「表紙のトカゲ?がなんか怖い」とか、妻からは「監視...?」と訝られるなどエンジニアではない層にも話題性があってすごいと思いました。*2

*1:CPUなどOS監視をアラートとして通報とか

*2:これは半分冗談です

物理RHEL7サーバにUSBを接続したときのUSB対応バージョンによるログの違い

業務で少し古めのサーバにUSB3.0の外付けSSDドライブを接続する機会があり、USB3.0対応の機器と、USB2.0までしか対応していない機器が混在しており戸惑ったのでメモします。

調べ方としては接続した時のシスログ(/var/log/messages)を見ればOKです。

USB 2.0 (high-speed)

ポイントは high-speed USB の部分。ここに SuperSpeed と出てないので2.0と判断します。

厄介なのはUSBデバイス側が3.0対応のせいか Direct-Access TO Exter nal USB 3.0 などと3.0に見えるようなログが出るので注意したいです。

May 31 13:47:10 localhost kernel: usb 1-1.3: new high-speed USB device number 3 using ehci-pci
May 31 13:47:10 localhost kernel: usb 1-1.3: New USB device found, idVendor=0080, idProduct=a001
May 31 13:47:10 localhost kernel: usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
May 31 13:47:10 localhost kernel: usb 1-1.3: Product: External USB 3.0
May 31 13:47:10 localhost kernel: usb 1-1.3: Manufacturer: TOSHIBA
May 31 13:47:10 localhost kernel: usb 1-1.3: SerialNumber: 201503310007F
May 31 13:47:10 localhost mtp-probe: checking bus 1, device 3: "/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.3"
May 31 13:47:10 localhost kernel: usb-storage 1-1.3:1.0: USB Mass Storage device detected
May 31 13:47:10 localhost kernel: scsi host3: usb-storage 1-1.3:1.0
May 31 13:47:10 localhost kernel: usbcore: registered new interface driver usb-storage
May 31 13:47:11 localhost kernel: scsi 3:0:0:0: Direct-Access     TO Exter nal USB 3.0      0204 PQ: 0 ANSI: 6

最終行に USB 3.0 と出ているけど勘違いしないで!

USB 3.0 (SuperSpeed)

ポイントは SuperSpeed 。2.0が high-speed のため highとsuperのどっちが早いのか混乱しそうになります。 USBの世界では少なくとも SuperSpeed の方が早いらしいです。

May 31 14:17:35 localhost kernel: usb 5-2: new SuperSpeed USB device number 5 using xhci_hcd
May 31 14:17:35 localhost kernel: usb 5-2: New USB device found, idVendor=0080, idProduct=a001
May 31 14:17:35 localhost kernel: usb 5-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
May 31 14:17:35 localhost kernel: usb 5-2: Product: External USB 3.0
May 31 14:17:35 localhost kernel: usb 5-2: Manufacturer: TOSHIBA
May 31 14:17:35 localhost kernel: usb 5-2: SerialNumber: 201503310007F
May 31 14:17:35 localhost kernel: usb-storage 5-2:1.0: USB Mass Storage device detected
May 31 14:17:35 localhost kernel: scsi host16: usb-storage 5-2:1.0
May 31 14:17:36 localhost kernel: scsi 16:0:0:0: Direct-Access     TO Exter nal USB 3.0      0204 PQ: 0 ANSI: 6

余談

この時はUSBドライブ上にある数TBのデータを1GのLANで転送しようとしましたが、3.0対応のUSBドライブを取り外して転送先サーバに接続し直した方が速度が出ると思ってやったところ、転送先サーバがUSB2.0にしか対応しておらず結局LAN経由に戻したという経緯があります。

カタログスペックでの速度比較としては以下で、USB2.0を利用するよりはLAN経由の方がましですね。そして2019年に策定されたUSB4*1の桁違い感...

転送方法 速度(bps) 速度(Bps)
USB 2.0 480Mbps 60MBps
1G LAN 1,000Mbps 125MBps
USB 3.0 5,000Mbps 625MBps
USB4 40,000Mbps 5,000MBps

速度参考 - wiki/ユニバーサル・シリアル・バス

*1:USB4はSuperSpeedPlusと呼ぶそうです

digdagのループ for_each 利用時の _parallel 指定について

digdagのループ for_each 利用時の _parallel 指定について仕様を調べたのでメモ。

公式ドキュメントの Parallel execution にある通り「子タスクには効果があるが、孫タスクには効果が無い」ことを確認します。

If _parallel: true parameter is set to a group, child tasks in the group run in parallel (grandchildren are not affected):

ケース1: _parallel指定無し

_parallelを指定しなかった場合、デフォルトがシーケンシャルのため、全てがシーケンシャルに実行されます。

+testing:
  _export:
    sweet: &SWEETS
      - apple
      - banana
      - candy

  for_each>:
    sweet: *SWEETS

  _do:
    +task1:
      sh>: echo "$(date) - ${sweet} - 1" ; sleep 3

    +task2:
      sh>: echo "$(date) - ${sweet} - 2"

実行ログは以下のとおり。appleの1, 2が行われ、続いてbanana, candyという順に実行されます。

2020-04-15 22:26:29 +0900: Digdag v0.9.41
2020-04-15 22:26:41 +0900 [WARN] (main): Reusing the last session time 2020-04-14T00:00:00+00:00.
2020-04-15 22:26:41 +0900 [INFO] (main): Using session /Users/morihaya/work/testdig/.digdag/status/20200414T000000+0000.
2020-04-15 22:26:41 +0900 [INFO] (main): Starting a new session project id=1 workflow name=child session_time=2020-04-14T00:00:00+00:00
2020-04-15 22:26:42 +0900 [INFO] (0017@[0:default]+child+testing): for_each>: {sweet=[apple, banana, candy]}
2020-04-15 22:26:43 +0900 [INFO] (0017@[0:default]+child+testing^sub+for-0=sweet=0=apple+task1): sh>: echo "$(date) - apple - 1" ; sleep 3
Wed Apr 15 22:26:43 JST 2020 - apple - 1
2020-04-15 22:26:46 +0900 [INFO] (0017@[0:default]+child+testing^sub+for-0=sweet=0=apple+task2): sh>: echo "$(date) - apple - 2"
Wed Apr 15 22:26:46 JST 2020 - apple - 2
2020-04-15 22:26:46 +0900 [INFO] (0017@[0:default]+child+testing^sub+for-0=sweet=1=banana+task1): sh>: echo "$(date) - banana - 1" ; sleep 3
Wed Apr 15 22:26:46 JST 2020 - banana - 1
2020-04-15 22:26:50 +0900 [INFO] (0017@[0:default]+child+testing^sub+for-0=sweet=1=banana+task2): sh>: echo "$(date) - banana - 2"
Wed Apr 15 22:26:50 JST 2020 - banana - 2
2020-04-15 22:26:50 +0900 [INFO] (0017@[0:default]+child+testing^sub+for-0=sweet=2=candy+task1): sh>: echo "$(date) - candy - 1" ; sleep 3
Wed Apr 15 22:26:50 JST 2020 - candy - 1
2020-04-15 22:26:53 +0900 [INFO] (0017@[0:default]+child+testing^sub+for-0=sweet=2=candy+task2): sh>: echo "$(date) - candy - 2"
Wed Apr 15 22:26:53 JST 2020 - candy - 2
Success. Task state is saved at /Users/morihaya/work/testdig/.digdag/status/20200414T000000+0000 directory.
  * Use --session <daily | hourly | "yyyy-MM-dd[ HH:mm:ss]"> to not reuse the last session time.
  * Use --rerun, --start +NAME, or --goal +NAME argument to rerun skipped tasks.

ケース2: タスクの外で _parallel 指定は意味がない

以下のように、タスクの外で _parallel: true を指定しても効果がないことがわかりました。

_parallel: true

+testing:
  _export:
    sweet: &SWEETS
      - apple
      - banana
      - candy

  for_each>:
    sweet: *SWEETS

  _do:
    +task1:
      sh>: echo "$(date) - ${sweet} - 1" ; sleep 3

    +task2:
      sh>: echo "$(date) - ${sweet} - 2"

ログは以下の通り

2020-04-15 22:30:42 +0900: Digdag v0.9.41
2020-04-15 22:30:54 +0900 [WARN] (main): Reusing the last session time 2020-04-14T00:00:00+00:00.
2020-04-15 22:30:54 +0900 [INFO] (main): Using session /Users/morihaya/work/testdig/.digdag/status/20200414T000000+0000.
2020-04-15 22:30:54 +0900 [INFO] (main): Starting a new session project id=1 workflow name=child session_time=2020-04-14T00:00:00+00:00
2020-04-15 22:30:55 +0900 [INFO] (0017@[0:default]+child+testing): for_each>: {sweet=[apple, banana, candy]}
2020-04-15 22:30:56 +0900 [INFO] (0017@[0:default]+child+testing^sub+for-0=sweet=0=apple+task1): sh>: echo "$(date) - apple - 1" ; sleep 3
Wed Apr 15 22:30:56 JST 2020 - apple - 1
2020-04-15 22:30:59 +0900 [INFO] (0017@[0:default]+child+testing^sub+for-0=sweet=0=apple+task2): sh>: echo "$(date) - apple - 2"
Wed Apr 15 22:30:59 JST 2020 - apple - 2
2020-04-15 22:30:59 +0900 [INFO] (0017@[0:default]+child+testing^sub+for-0=sweet=1=banana+task1): sh>: echo "$(date) - banana - 1" ; sleep 3
Wed Apr 15 22:31:00 JST 2020 - banana - 1
2020-04-15 22:31:03 +0900 [INFO] (0017@[0:default]+child+testing^sub+for-0=sweet=1=banana+task2): sh>: echo "$(date) - banana - 2"
Wed Apr 15 22:31:03 JST 2020 - banana - 2
2020-04-15 22:31:03 +0900 [INFO] (0017@[0:default]+child+testing^sub+for-0=sweet=2=candy+task1): sh>: echo "$(date) - candy - 1" ; sleep 3
Wed Apr 15 22:31:03 JST 2020 - candy - 1
2020-04-15 22:31:06 +0900 [INFO] (0017@[0:default]+child+testing^sub+for-0=sweet=2=candy+task2): sh>: echo "$(date) - candy - 2"
Wed Apr 15 22:31:06 JST 2020 - candy - 2
Success. Task state is saved at /Users/morihaya/work/testdig/.digdag/status/20200414T000000+0000 directory.
  * Use --session <daily | hourly | "yyyy-MM-dd[ HH:mm:ss]"> to not reuse the last session time.
  * Use --rerun, --start +NAME, or --goal +NAME argument to rerun skipped tasks.

ケース3: タスク内で _parallel 指定はループの要素に効果はあるが、doの中には効果がない

タスクの中で _parallel: true を指定すると apple, banana, candy という各要素についてはパラレルで実行されるが、 _do: で指定したタスクはシーケンシャルで実行されました。子タスク=要素のループで、孫タスク=_doの中のタスクと分かりました。

+testing:
  _parallel: true
  _export:
    sweet: &SWEETS
      - apple
      - banana
      - candy

  for_each>:
    sweet: *SWEETS

  _do:
    +task1:
      sh>: echo "$(date) - ${sweet} - 1" ; sleep 3

    +task2:
      sh>: echo "$(date) - ${sweet} - 2"

以下はログ。apple, banana, candy はパラレルで実行されるため、順番も入れ替わって見えますが、task2 が task1 より先に実行されることはありません。

2020-04-15 22:35:13 +0900: Digdag v0.9.41
2020-04-15 22:35:26 +0900 [WARN] (main): Reusing the last session time 2020-04-14T00:00:00+00:00.
2020-04-15 22:35:26 +0900 [INFO] (main): Using session /Users/morihaya/work/testdig/.digdag/status/20200414T000000+0000.
2020-04-15 22:35:26 +0900 [INFO] (main): Starting a new session project id=1 workflow name=child session_time=2020-04-14T00:00:00+00:00
2020-04-15 22:35:27 +0900 [INFO] (0017@[0:default]+child+testing): for_each>: {sweet=[apple, banana, candy]}
2020-04-15 22:35:29 +0900 [INFO] (0018@[0:default]+child+testing^sub+for-0=sweet=1=banana+task1): sh>: echo "$(date) - banana - 1" ; sleep 3
2020-04-15 22:35:29 +0900 [INFO] (0019@[0:default]+child+testing^sub+for-0=sweet=2=candy+task1): sh>: echo "$(date) - candy - 1" ; sleep 3
Wed Apr 15 22:35:29 JST 2020 - candy - 1
Wed Apr 15 22:35:29 JST 2020 - banana - 1
2020-04-15 22:35:29 +0900 [INFO] (0017@[0:default]+child+testing^sub+for-0=sweet=0=apple+task1): sh>: echo "$(date) - apple - 1" ; sleep 3
Wed Apr 15 22:35:29 JST 2020 - apple - 1
2020-04-15 22:35:32 +0900 [INFO] (0017@[0:default]+child+testing^sub+for-0=sweet=0=apple+task2): sh>: echo "$(date) - apple - 2"
2020-04-15 22:35:32 +0900 [INFO] (0019@[0:default]+child+testing^sub+for-0=sweet=1=banana+task2): sh>: echo "$(date) - banana - 2"
Wed Apr 15 22:35:32 JST 2020 - apple - 2
Wed Apr 15 22:35:32 JST 2020 - banana - 2
2020-04-15 22:35:32 +0900 [INFO] (0018@[0:default]+child+testing^sub+for-0=sweet=2=candy+task2): sh>: echo "$(date) - candy - 2"
Wed Apr 15 22:35:32 JST 2020 - candy - 2
Success. Task state is saved at /Users/morihaya/work/testdig/.digdag/status/20200414T000000+0000 directory.
  * Use --session <daily | hourly | "yyyy-MM-dd[ HH:mm:ss]"> to not reuse the last session time.
  * Use --rerun, --start +NAME, or --goal +NAME argument to rerun skipped tasks.

ケース4: タスク内でも、do内でも parallel 指定をすると全てがパラレルで実行される

要素についても、タスクについてもパラレルで実行する場合のケースです。

+testing:
  _parallel: true
  _export:
    sweet: &SWEETS
      - apple
      - banana
      - candy

  for_each>:
    sweet: *SWEETS

  _do:
    _parallel: true
    +task1:
      sh>: echo "$(date) - ${sweet} - 1" ; sleep 3

    +task2:
      sh>: echo "$(date) - ${sweet} - 2"

全てが同じ時間に実行されています。

2020-04-15 22:40:14 +0900: Digdag v0.9.41
2020-04-15 22:40:26 +0900 [WARN] (main): Reusing the last session time 2020-04-14T00:00:00+00:00.
2020-04-15 22:40:26 +0900 [INFO] (main): Using session /Users/morihaya/work/testdig/.digdag/status/20200414T000000+0000.
2020-04-15 22:40:26 +0900 [INFO] (main): Starting a new session project id=1 workflow name=child session_time=2020-04-14T00:00:00+00:00
2020-04-15 22:40:27 +0900 [INFO] (0017@[0:default]+child+testing): for_each>: {sweet=[apple, banana, candy]}
2020-04-15 22:40:28 +0900 [INFO] (0018@[0:default]+child+testing^sub+for-0=sweet=0=apple+task2): sh>: echo "$(date) - apple - 2"
2020-04-15 22:40:28 +0900 [INFO] (0019@[0:default]+child+testing^sub+for-0=sweet=1=banana+task1): sh>: echo "$(date) - banana - 1" ; sleep 3
Wed Apr 15 22:40:28 JST 2020 - banana - 1
Wed Apr 15 22:40:28 JST 2020 - apple - 2
2020-04-15 22:40:28 +0900 [INFO] (0020@[0:default]+child+testing^sub+for-0=sweet=1=banana+task2): sh>: echo "$(date) - banana - 2"
2020-04-15 22:40:28 +0900 [INFO] (0022@[0:default]+child+testing^sub+for-0=sweet=2=candy+task2): sh>: echo "$(date) - candy - 2"
Wed Apr 15 22:40:28 JST 2020 - banana - 2
Wed Apr 15 22:40:28 JST 2020 - candy - 2
2020-04-15 22:40:28 +0900 [INFO] (0021@[0:default]+child+testing^sub+for-0=sweet=2=candy+task1): sh>: echo "$(date) - candy - 1" ; sleep 3
Wed Apr 15 22:40:28 JST 2020 - candy - 1
2020-04-15 22:40:28 +0900 [INFO] (0017@[0:default]+child+testing^sub+for-0=sweet=0=apple+task1): sh>: echo "$(date) - apple - 1" ; sleep 3
Wed Apr 15 22:40:28 JST 2020 - apple - 1
Success. Task state is saved at /Users/morihaya/work/testdig/.digdag/status/20200414T000000+0000 directory.
  * Use --session <daily | hourly | "yyyy-MM-dd[ HH:mm:ss]"> to not reuse the last session time.
  * Use --rerun, --start +NAME, or --goal +NAME argument to rerun skipped tasks.

まとめ

当たり前ですが、以下のドキュメントの通りの動きを確認できたので満足しました。 ループと _parallel の組み合わせは強力ですが乱用するとキューが詰まって他のWorkflowに影響が出ることもありますので要注意ですね。

If _parallel: true parameter is set to a group, child tasks in the group run in parallel (grandchildren are not affected):

AWS WorkspacesのDirectryを削除しようとしたら "Cannot delete the directory because it still has authorized applications" が出る対策

検証で利用していたAWS Workspacesのお掃除をしていたところ、以下のエラーが発生して消せなくて焦りました。

An Error Has Occurred Cannot delete the directory because it still has authorized applications. Additional directory details can be viewed at the Directory Service console.

f:id:morihaya:20200403171821p:plain
エラー画面

対策: 利用中のアプリを先に削除する

原因は全てのアプリを削除していないためでした。エラーメッセージのリンク先に飛ぶと、ディレクトリの詳細ページが表示され、以下のように利用中のアプリケーションの一覧んを確認できます。

この図では Amazon WorkDocsEnabled になっているため、ディレクトリを削除できなかったのです。

f:id:morihaya:20200403172317p:plain
利用中のアプリ一覧

リンク先へ飛びWork Docsも削除します。WorkDocsの削除画面には親切なことに I also want to delete the user directory オプションが表示されましたので、チェックを入れて削除を行います。

f:id:morihaya:20200403172624p:plain
WorkDocs削除画面

念のため Workspacesのディレクトリ一覧に戻ると、 deleting ステータスを確認できました。こちらでお掃除が完了です。

f:id:morihaya:20200403172949p:plain
削除されつつあるディレクトリの図

まとめ。

GUIでサクサクと起動できるのはいいですが、裏で複数サービスが連携して作成されることで、一箇所で削除ができないのはよくある話ですが、直面すると少し焦りますね。

awsコマンドでEC2のGlobal IPとPrivate IPを取得する1行コマンド

開発者から「IPアドレスの一覧が欲しい」と言われて必要になったので作りました。メモとして残しておきます。

aws ec2 describe-instances | jq -c '.Reservations[].Instances[] | [ (.Tags[]? | select(.Key == "Name")).Value, .PrivateIpAddress, .PublicIpAddress]' | sed -E 's/\[|\]//g' | sed -E 's/,/\|/g' | tr -d '"' | sed -E 's/^/\|/g'| sed -E 's/$/\|/g' | sort

すると以下のような結果が取れます。(IPはサンプル)

|morihaya-test-01|192.168.1.13|203.0.113.1|
|morihaya-test-02|192.168.2.11|203.0.113.2|

ヘッダーをつけて、esaなどのMarkdown対応なドキュメントに載せます。

| Hostname | Private IP | Public IP |
| --- | --- | --- | 
|morihaya-test-01 |192.168.1.13|203.0.113.1 |
|morihaya-test-02|192.168.2.11|203.0.113.2 |

すると以下のように一覧になって良さ、という話でした。

Hostname Private IP Public IP
morihaya-test-01 192.168.1.13 203.0.113.1
morihaya-test-02 192.168.2.11 203.0.113.2

もちろんサーバは日々変動することがあり、現実とのデグレが発生する未来が見えるので必要なメンバにAWSコンソールを渡してしまうのも手なのですが、ささっと閲覧可能なドキュメントとして作る分には良し。

Prometheus Meetup Tokyo #3 に参加してきました

1/15に 行われた Prometheus Meetup Tokyo #3 にブログ枠で参加してきました。

prometheus.connpass.com

  • Prometheusと私
    • 昔ちょっとだけ触った
    • 今は全然触ってない...
    • 参加のモチベーション
  • Prometheus Meetup Tokyo #3の感想
    • 会場
    • 1 - Remote Write API と Thanos を活用したメトリクス永続化 (仮)
    • 2 - Victoria Metricsで作りあげる大規模・超負荷システムモニタリング基盤
    • 3 - 次世代のログ基盤 Grafana Lokiを始めよう!
    • LT
      • イベントネットワークのlog監視をlokiでやってみた - gen16k
      • レガシー環境でも Prometheus はイケるんです - Kazuhito_Omachi
      • Prometheus でデータの水平分割を試みる - watawuwu
      • Lokiでjurnal logを可視化する方法 - yosshi_
      • Grafana/Lokiの開発元にfluent-bitのプラグインを作成してフィードバックした話- Hiroshi Hatake
  • まとめ
続きを読む