こんにちは、あまねです。

感想や興味のあるトピックについて、ぜひコメントしてください。

人間と科学

サーバ監視のこと

最近、あまねけ！などのアクセス解析（Shynet）の口を誤って塞いでしまったり、自前で運用しているMatrixサーバ（Synapse）のフェデレーション用ポートの設定を誤ったりする事故が続いたので、ちゃんとサーバ監視をやろうかなと思い立ちました。

これまでもUptimeRobotで雑に死活監視をしたり（status.amane.moeでダッシュボード提供中）、glancesのWebインターフェースでたまに負荷を眺めたりしていますが、個別のエンドポイントやポートを監視する解像度ではなかったので今回のトラブルは検知できませんでした。

そこで、手始めにGrafanaにLokiとPromtailを置いてnginxのログを食べさせています。LogQLはちょっと難しいですね。Splunk SPLは少しだけ使ったことがあります。ウンウン唸りながら、各サービスでエラーステータスが増えたら赤くなるダッシュボードを作ったので、今後はまぁなんとなく気づけるでしょう。

ログ収集から数日経ったので4xx/5xx系のログを集計してみたところ、興味深いアクセスがいくつかありました。もちろん一番多いのは誤って 晒しがち なファイルへの定期的なクロールで、よくある /wp-login.php へのアクセスならまだしも、適当なディレクトリの .git/HEAD を掘ったりしていてなかなか渋いです。

また、どこかのクローラが古いキャッシュを保持し続けているのか、過去のあまねけ！に含まれているリンクへのアクセスも増えています。たとえば、「読んだ」ボタンの古いv1 API（現在はv2です）の呼び出しや、Pocketへのシェアボタンに使っていた大きな赤い丸の絵文字などへのアクセスが見られます。あまりケアする必要はなさそうですが、アクセス経路について確認したいところです。

P.S Cloudflareが落ちてからUptimeRobotも息をしてなかったので、外部で提供してるサービスの監視もある程度手元でやっておいた方がよさそうです。

長方形ではない郵便はがきのこと

#31で紹介した文フリ34のふりかえり（ポストカード編）について、形状のことを記載するのを忘れていたなと思って少し調査しています。

内国郵便約款に「長方形の紙」と明記されている通り、はがきが第二種郵便物として取り扱われるには、少なくとも長方形である必要があります。正方形は（長方形の定義を満たしていますが）短辺と長辺の範囲が重複していないので不可ですし、ハート型や円形はもちろん使えません。しかし、現実世界で完全な長方形を作るのは無理ですから、どこまで許容されるのか気になるところです。

インターネットでは、以下のような情報が多く見つかります。

• 縁に2mm以内の切り込みや波加工を施してもよい
• 角に2mm以内の角丸加工を施してもよい
• 私製はがきは、8mm以内の円形の穴を1箇所のみ開けてもよい（8mmを超える穴、円形ではない穴、複数の穴は不可）
• 通常はがきは、2mm以内の穴を開けてもよい（形状、個数の規則は不明）

このうち、根拠となりそうな資料と共にこれらの情報を記載しているのは郵便ゆうパック・個人向け郵便局発送お役立ち情報というサイトです。日本郵便のガイドラインとおぼしき写真と共に、淡々と第二種郵便物の規則について解説しています。この資料の出どころが気になるところです。

また、はがきの差出し方 :エンドレールには、

約款附則第5条第3項の規定による経過措置により当分の間、第二種郵便物として差し出すことができます。1969年当時の規則第16条第5項の2の規定では”私製葉書の裏面を蓄音機用レコードとするため…”となっていることから、裏面へソノシートを貼付したはがきを第二種郵便物として取り扱うために設けられた規定です。

という記載があるため、おそらく古い内国郵便約款には8mmの穴に関する規定が明示されていそうです（この用途なら形状や個数の制限も納得です）。一方、2mmについては内国郵便約款第24条の「針孔又は浮出による小さい記号」の限度としてどこかに記載されていそうですが、今のところは見つかっていません。

これらの規則の根拠が見つかりしだい、随時記事に追記していこうと思います。

P.S. 最近Amazonから楽天ブックスに軸足を移していますが、小包に広告が同梱されているのがちょっと気になります。

プラン・インターナショナルのチラシに印刷されていたはがきは、必要事項を記載して縁を貼り合わせると郵送できるように見えますが、全面をしっかりとのり付けしていないはがきは第二種郵便物として取り扱われません（料金受取人払なので、もともと第一種郵便物として送られることを想定しているのかも）。

ウソ・大げさ・まぎらわしい文字のこと

Latin-1と0x85のなぞという記事を書きました。こちらは、Proton Calendarというカレンダーサービスから共有できるiCalendar形式のファイルの生成処理にバグがあり、不適切な改行が挿入されていた事象について解説したものです。

見た目や意味がよく似た異なる文字はバグの温床ですね。今回解説した改行（ \n \r に対して、次の行 U+0085 、行区切り文字 U+2028 、段落区切り文字 U+2029 がある）と同じく、UnicodeにはもともとASCIIで定義されていた文字をルーツとして複数の意味を定義しているものがみられます。

スペースやハイフン、ダッシュなどを置換・統一する際は、対象となる文字を過不足なく挙げることはもちろん、適切に処理しなければいけません。特に、\x80 ～ \FF のようないわゆる拡張ASCII範囲の文字がUnicodeに引き継がれている場合（たとえば © ➡ U+00A9 ）は、コードポイント上は1バイトに見えてもUTF-8で表現すると2バイト（ たとえば © ➡ \xC2\xA9 ）になります。この場合、単に \xA9 を置換するとUTF-8のシーケンスが壊れてしまうので注意が必要です。

アマネイメージズ

今回はありません。