Lycolog

mont-bellの登山靴の一つにトレールウォーカーという靴があり、幅広版にはワイドという名前がついている。

これが最近リニューアルされたようで、だいぶ靴の形が変わってしまって履けなくなった話。

以下はリニューアル後のトレールウォーカーワイド（品番：1129773）と、リニューアル前のトレールウォーカーワイド（品番：1129652）の比較だ。青い方がリニューアル後、灰色がリニューアル前。

リニューアル後はつま先が曲がっており、つま先の高さも低くなっており、真ん中の紐が横断している隙間も1cmほど狭くなっているように思う。これによって私の幅広甲高な足だと指が圧迫され、指の第一関節が押し付けられ、かなり苦しかった。

試着の時はそこまで気にならなかったが、実際に路上を歩くと五分で違和感を覚え、数時間歩くと痛みで歩行が困難になるほどだった。

余談だがワイドでない方にも同様の変更がありそうだった。

リニューアル前のトレールウォーカーワイドは通常店舗では手に入れることが出来ないが、公式通販やアウトレットショップには型落ち品として在庫があるため、手持ち品を更新する場合はこちらを買うと良い。また、公式の店舗在庫はかなりリアルタイムに更新されているようで、購入して30分後に確認した時には既にサイト上で店舗在庫が消えていたので、店舗で購入する場合は有力な指標になると思う。恐らく目の前の客が今買った以外以外のケースでは概ねアテになるのではなかろうか。

Google Analyticsを廃止してMatomoを導入してから集めていたIPv6のアクセス比率を集計した結果をメモしておく。

集計期間は2025/08/17～2025/10/21。

以上の結果からIPv6は約四割、v4は約六割ということが分かった。また最もアクセスがあるのはECO-Wikiで、ツールサイトにはほぼアクセスがないことも明確になった。まぁツールは私が使えればいいので仕方ないね。

lycolia.infoは突出してIPv6のアクセスが多いが、実数が少なすぎるので余りアテにならない。ただ恐らく、リンク元の特性的に、ITオタク周りのアクセスが多いことが想定されるため、この結果はある程度妥当かもしれない。ツールサイトもそういう人が興味を持って踏んでるのだとしたら納得だ。ブログも技術記事がある関係で比率が高い可能性がある。

逆にECO-Wikiは比較的一般向けのサイトなので比率が少なくなっていると思った。

あとがき

まだまだIPv4の環境は多く、IPv6シングルスタックへの移行はやや戸惑うレベルだ。GitHubのWebhookもIPv4だったりするので、しばらくはデュアルスタックで運用していくのが無難だろう。

現状さくらのレンタルサーバー上にある資源を自宅サーバーにフル移行する場合、DNS側の制約でマルチドメインのDDNSが面倒な問題があるため、専用のスクリプトを作る必要が出てきそうだ。

これは契約しているDNSサーバーのDDNSが1回に1レコードしか更新できず、レートリミットが60秒に1回という面倒な仕様なため、ドメインが複数あると厄介なのだ。現状Mastodonだけが自宅サーバーにある状態なのでどうにかなっているが、どうにかして対処しないといけない。

契約しているDNSサーバーにはDDNS API以外にも、DNSレコードを全部書き換えられるAPIがあり、こちらは1回に複数レコードを触れるため、比較的レートリミットを気にする必要がなくなる。なので、これを使って自力で書き換えるスクリプトを組めばDDNS APIのレートリミットは無視できるようになる。まぁ、こっちのAPIはレートリミットが緩いので何度でも叩けるのだが、バルク編集できるAPIを何度も叩く意味もないので…。

これとは関係なく、将来的には自宅サーバー側に権威DNSを立てて、レジストラのDNSサーバー側にはNSレコードだけというのもやってみたさがある。この場合、ドメインの追加や削除で一々レジストラの管理画面にアクセスする頻度が減らせ、管理が楽になるメリットがありそうだし、レジストラのDNSでは実現できないことが出来るようになる可能性もあるだろうから面白いかもしれない。

luci-app-statisticsとcollectdを入れて下図のように各メトリクスのグラフを見れるようにした。collectdは、システム情報を定期的に収集し、さまざまな方法で値を格納するメカニズムを提供する小さなデーモンで、luci-app-statisticsはそれをLuCI上に表示するためのものっぽい。

• 確認環境
• セットアップ
• Collectdのプラグイン設定
• Collectdのプラグイン
  • collectd-mod-cpu：CPU使用率
  • collectd-mod-interface：ネットワーク転送量
  • collectd-mod-load：負荷(Load Average)
  • collectd-mod-memory
  • collectd-mod-thermal
  • collectd-mod-uptime
  • collectd-mod-rrdtool
• トラブルシューティング
  • Thermalタブに壊れて表示されていない画像や、集計対象外のグラフが表示される
• 参考

確認環境

セットアップ

1. LuCIを開く
2. System→Software
3. luci-app-statisticsを入れる
4. 画面リロード
5. Statics→Graphからグラフが見れることを確認

この時点で幾つかのプラグインが導入されたが、消したり入れたりして、結果として以下のものを導入した。

• collectd-mod-cpu
• collectd-mod-interface
• collectd-mod-load
• collectd-mod-memory
• collectd-mod-thermal
• collectd-mod-uptime
• collectd-mod-rrdtool

Collectdのプラグイン設定

/etc/collectd.confをいじると変更できる。

基本的にはLoadPlugin hogeでhogeプラグインを読み込み、以下の書式で設定するようだ。設定がなければLoadPlugin hogeだけでよい。

<Plugin hoge>
        Foo true
        Bar 1
        Baz "fuga"
</Plugin>

Collectdのプラグイン

collectd-mod-cpu：CPU使用率

collectd-mod-cpu

設定はデフォルトのままで良さそう。

collectd-mod-interface：ネットワーク転送量

collectd-mod-interface

Network→Interfaces→Deviceにあるものが見れる。

br-lanとMAP-E、PPPoEが見たいので以下のようにした。

LoadPlugin interface
<Plugin interface>
        Interface "br-lan"
        Interface "map-wanmap"
        Interface "pppoe-wanppp"
</Plugin>

collectd-mod-load：負荷(Load Average)

• collectd-mod-load

uptimeコマンドで出てくる内容と思われる。1を超えていれば過負荷、割っていれば余裕がある。

Wikipediaによると、1ならその時間平均で全てのプロセスが実行され、1.73なら73%のプロセスが実行待ちになったと言う事のようだ。これを1分、5分、15分の平均で出しているとのこと。

設定項目がない。

collectd-mod-memory

• collectd-mod-memory

メモリの使用量を取れる。

設定はデフォルトのままで良さそう。

collectd-mod-thermal

• collectd-mod-thermal

デバイスの温度を取れる。

R86S U1の場合、thermal_zone1以外無価値に見えたので、thermal_zone1のみとした。thermal_zone0はマザーボードの温度のようだが、固定値しか出てこない。

LoadPlugin thermal
<Plugin thermal>
        Device "thermal_zone1"
</Plugin>

これだけだと余計なグラフが出てくるため、設定後に余計なグラフデータを削除する。

collectd-mod-uptime

公式にマニュアルはなさそうだが、起動時間を見れる。

LoadPlugin uptime

collectd-mod-rrdtool

• collectd-mod-rrdtool

collectdが取得したメトリクスを保存したり、メトリクスのグラフを書くのに使われている模様。特に設定せずとも勝手に設定されるため設定を気にする必要性はなさそう。

ログは標準では/tmp/rrd/OpenWrt/に保存されているようなのでストレージの摩耗は気にしなくていい。（/tmp/はオンメモリストレージ）

トラブルシューティング

Thermalタブに壊れて表示されていない画像や、集計対象外のグラフが表示される

上図の青枠のように壊れて表示されていない画像や、集計対象外のものが表示されている場合、/tmp/rrd/OpenWrt/配下にある不要なメトリクスを削除することで非表示にできる。

例えば上図にあるthermal-cooling_device*にはまともにデータが入っていないため、画像が壊れて表示されている。rm -Rf thermal-cooling_device*で消すと出てこなくなる。

上図の状態になると、下図のように不要なグラフが表示されなくなる。

但しcollectd.confで以下のようにデバイスを絞っていないと、再び出てくると思われるので、設定で表示したいものだけに絞ってから消した方がよい。

LoadPlugin thermal
<Plugin thermal>
        Device "thermal_zone1"
</Plugin>

参考

• [OpenWrt Wiki] Performance and logging

PCでもやれるが、スマホが必須になるためPCでやる意味は余りないと思う。

事前に必要なもの

• 証明写真
  • 写真屋で一枚撮っておくとJPEGを貰えて様々な場面で使えるので一枚作っておくと良い
• 自筆署名の画像
  • コピー紙などの白い紙に署名してコンビニのスキャナで画像に落とすと良い
    • スマホの写真で撮ると影が入って却下されるかもしれないので…
  • ペンタブがある人はそれで作ってもよいだろう
• マイナンバーカード
• PaSoRi
  • PCでやる人向け
• マイナンバーカードに対応したスマホ
• Androidの場合、Chrome（Chromeでしかできない）

やったこと

途中までPCでやっているため内容が煩雑になっている。

1. パスポート（旅券）申請について ｜ マイナポータルを開く
2. 適当に進めていく
3. 旅券を受け取る場所を聞かれるので受け取る場所を入れる
   

   

4. 受け取る窓口をクリックして先へ進む
   

   

5. 各種情報の登録画面が出るので事前準備を受けから順に登録する
   

   

6. 事前準備が終わったら「保存して中断」を押してファイルを保存する。これをしないと何かでエラーになったとき全部最初からやり直しになり、非常に面倒
7. 申請へ進む
8. ここから先PCは役に立たないため、先ほど保存したファイルをスマホに転送して、スマホで手続すると具合が良い
9. 作りたいパスポートの年数や過去に不法行為をしたかどうかなど聞かれるので答える
   

   

10. そのまま適当に進めていると「券面写真の確認」というのが出てくるが、私はここでPCからスマホへのQR転送が上手く行かなかったので、スマホでやり直す羽目になった。
    

    

    

11. スマホに移動し再開
12. 「顔写真を読み取る」では「生年の表記」「マイナンバーカード有効期限」「セキュリティコード」の入力が必要だが、これらはすべて券面に記載されている内容を読み取って入力する。間違えた情報を入れるとセキュリティロックされる恐れがあるため、ここで暗証番号を入れてはいけない
    

    

13. あとはそのまま適当に進めていけば完了画面が出て終わった
    

    

あとがき：何故パスポートを取ろうと思ったのか？

卓球少女 -閃光のかなたへ-（原題：白色闪电 Pingpong！）が余りにもよすぎたので、実際に現地杭州を見てみたくなったからだが、結構めんどそうなのと予算の関係で、今のところはやめようかなという感じもしている。

Google Analyticsを廃止してMatomoを導入してみたから一ヶ月が過ぎ去っていたので簡単に集計をまとめてみる。

集計内容

8月17日～9月16日の30日間で自分のIPを除くMatomoの集計結果を出している。今回記事にする対象サイトはこのブログのみ。

主な指標

ビジットが何なのかについては正直よくわかっていない。PVでもUVでもない概念なのは確かだが、Matomo内の数値は大抵これがベースである。30分以内にもう一度ページを訪れたユーザーと解釈しようにも直帰率80%である以上、直帰して別経路でアクセスされないとカウントされない気がするので謎。ほとんどのユーザーがタブを開きなおしているとか、そんなことはないと思う。

バウンスは直帰率のことらしい。

IPv6対応状況

これはIPv6に対応しているアクセスの数で、IPv6に対応しているがIPv4でアクセスしてきているユーザーは「IPv6対応ユーザー」にカウントしている。

集計方法としてはAAAAレコードを持つドメインに対しJSでfetchし、200OKが出たら対応、それ以外は非対応としている。この関係で、JS非対応ユーザーは集計から外れてしまい「IPv6対応状況不明ユーザー」になっている。

IPv6対応状況不明ユーザーをBOTと仮定した場合、IPv6対応は45.1%で非対応は54.9%となる。およそ半数弱がIPv6に対応した環境でアクセスしていることがわかる。

アクセスページ、上位10位

なぜかここはビジットではなく、PVとUVの表現だった。PVのみ記載する。

OSバージョン別、上位10位

概ねWindowsユーザーからのアクセスが多いが、iOS, Mac系のアクセスも無視できない程度にあるようだ。

OS種類別

バージョンやディストリの差異を束ねたもの。

Androidユーザーが少ない…。地味にLinuxやChrome OSもあった。

ブラウザ種類別、上位10位

バージョンは束ねている。

意外とEdgeのアクセスが多く、個人的にはうれしい。変わり種ではIronやSleipnir, Operaも見られた。

流入元検索エンジン

地味にBingからの流入が多い。ちなみにこのブログはBingのほうがヒットしやすい。

バックリンク

国内都市別アクセス

基本的に人口比そのままだと思われる。

期間内のアクセスグラフ

日別

昔からそうだが、基本的に平日に伸び、週末や祝日に下がる傾向がある。開発係記事の割合が高いので、恐らく業務中に見られることが多いのだろう。

時間別

業務時間中にアクセスが伸び、通退勤や昼休みには減っているように見える。

雑感

Google Analyticsを使っていたころはUIと動作の重さで、ここまで細かく見る気さえ起きなかったが、MatomoはUIが良く動きも機敏なため、こういったことがしやすいのがいい。事実ほぼ毎日見ているくらいだ。GAのころは年に一回見るかどうか位だった。

何より自分のアクセスが普通に弾けるので、ノイズが減るのもいい。GAでもはじく方法はあるにはあるが、全てのデバイスで無設定に弾くというのは不可能に近いし、設定しても何故か弾けなかったりして困ることが多かった。オプトアウトする拡張機能はほかのサイトにとって迷惑そうなので入れたくなかったし、そもそもスマホでは入れる手段もない。

今回の集計では前回のサーバーログベースの集計を大きく覆す結果が出たのもあり、かなり満足している。

関連記事

集計手法がすべて異なるので単純比較できないが、時期によって順位に変動があることがわかる。

• 最近のGoogle検索からの流入統計 - 2025/07/17執筆
• 2024年振り返り - 2025/01/30執筆