投稿者「nekoponti」のアーカイブ

キャンプに向けて「O.D.メンテナンス マルチクリーナー」でテントを洗う

どうもネトヲです。

今回は「O.D.メンテナンス マルチクリーナー」を使ってテントをキレイキレイします。

今回洗っていくテント

5年くらい愛用しているmont-bellの「ムーンライト テント2」(旧モデル)を洗います。

基本的に2回キャンプしたら1回洗うようにしているので実はそんなに汚れてないんですが、最後にキャンプしたのは多分1年前とかでその後洗ってないです。

中身はインナーとアウターテント、ポール、ペグ、そしてハンマーとなります。

ハンマーのみ別で買った物で他は純正品です。

極力、ペグはその場で綺麗にしているので土汚れはなく、そもそも前行ったサイトがウッドデッキだったのでテント自体も綺麗です。

クリーナー

mont-bellの「O.D.メンテナンス マルチクリーナー」を使います。

確認したところ私が使っているのは旧製品で、現行のやつとはパッケージの見た目が違っています。

【モンベル】O.D.メンテナンス マルチクリーナー 300mL

防水透湿性素材やはっ水加工を施したウエアやギアなどの繊維製品の洗濯に適した洗剤です。中性なので繊維を傷めることなく、優れた洗浄成分が汗や皮脂などの汚れをしっかり落し、高機能素材の性能を長持ちさせます。レインウエアの防水透湿性を損なわずに洗浄でき、はっ水剤が効果的に塗布できる下地を作ります。O.D.メンテナンスシリーズのはっ水剤と併せての使用が効果的です。詳しい使い方はこちらをご覧ください。

とは言え恐らく中身は同じかと思いますので、あまり気にする必要はないかと。

浴槽にぶち込んで洗う

畳んだ状態では面と面が重なる面積が大きくなり上手く洗えない可能性があるので、ぐしゃぐしゃにした状態で浴槽にぶち込みます。

あと、インナーテントは内外をひっくり返すとよりよいと思います。

↓ぐしゃぐしゃにする前

ぐしゃぐしゃにしつつ内外をひっくり返します。

まだ水を含んでいないので片手でも持ち上げられますが、水を含むと重くなるんですよねぇ。

季節的にまだ真水は冷たすぎるのでお湯を投入します。

お湯の量は全部浸かるほど入れる必要はなく、浴槽1cmで十分かと思います。

つづいて「O.D.メンテナンス マルチクリーナー」を投入。

めんどくさいので分量は量りませんが、前一度入れすぎてしまい泡がなかなか切れない事があったので気持ち少なめがいいかと思います(まあそれでも泡切れは優秀ではある)。

あとはひたすら踏んづけて洗っていきます。

私はいつも素足で踏んづけてますが、テントのフックや装飾品等で怪我をする可能性が大いにあるのでオススメはしません。サンダルとか履いた方がいいです。

なんかデカい物体が浮いてるなと思って引き上げたところカメムシでした。

死後かなりの期間経っているようで、あの匂いは全くしなかったです。コイツ何処にでもいますね。

踏み続けること5分経過後の水の色がこちら。

なかなか伝わらないと思いますが、茶色く濁っています。

ある程度の時間踏んづけたところで、一旦水を抜いていきます。

この時、洗い物を全て引き上げておくと、幾分スムーズに水が抜けていきいます。

水がぬけたら再度水を溜めていきならが踏んづけていき、すすぎをしていきます。

すすぎは2,3回やっておけばいいと思います。多少泡が残っていても死ぬわけではないため適当で大丈夫です。

すすぎが終わったらテントを引き上げつつ、汚れや泡切れが不十分な所が無いか確認します。

特段問題無ければ、一旦浴槽内に干しておきます。

干す

いきなりベンダに干してもいいんですが、テントって結構防水性能が高く引き上げて直ぐ直ぐは角に溜まった水がしたたり落ちてきて床が悲惨なことになります。

なので個人的には一旦風呂場に干して置くのがオススメです。

この状態で10分位放置したのち、テント一式をベランダに持っていき干します。

単身向け賃貸物件なので干すスペースはあまり取れなく、重ならないよう干すのが大変なんですがあまり気にせず適当で大丈夫です。

テントの生地はペラいので直ぐ乾きます。

で、このまま乾くまで放置しても良いんですが、短時間で済ませたい場合は、定期的に裏表をひっくり返すのがオススメです。

表面はカラッカラだけど裏返すと水滴が残っているなんてことはザラです。

あと「テントの口」を下に向けておくと水が変に溜まらず綺麗にしたたり落ちるので、余裕があればやっておくと良いかもです。

袋に戻す

今日は天気がよく、気温が高めだったので3時間ほどで乾きました。

あとはたたんで元に戻すだけ。

たたみ方は色々ありますが、私の場合はペグを”芯”にしてインナー、アウターの順でくるくる丸めて行くやり方が気に入ってます。

こんな感じ。

その際、金具類を袋の底に来るようにしておくと、より綺麗に入ります。

キャンプも楽しいですが道具のメンテナンスも楽しいですね。

まとめ

ということで、今回は「O.D.メンテナンス マルチクリーナー」を使ってテントをキレイキレイしました。

私のようなアパマン民であっても、浴槽と干す場所さえあれば問題なくキレイキレイできるので是非トライしてみてください。

あと、このクリーナーでなくとも問題なく洗えるとは思いますが、泡切れがいいクリーナーを選ぶのがミソです。

小物ならまだしも、テントのように面積が大きいとすすぎですら一苦労なので。

【独身男のずぼら料理】#2 パンケーキ

今回はキッチン奥に眠っていたパンケーキミックスを使ってパンケーキを作っていきます。

というか最近はホットケーキって言わないんですかね、おっさんには違いが分からないです。

中身はこんな感じ。

大抵中身のパッケージってコスト優先で無地な事が多い気がしますが、コレについては紀伊国屋の主張がなかなか激しいですね。

材料は牛乳と卵のみです。

フルーツだのバターだの洒落たトッピングはしません。漢ですから。

材料を入れたら箸で混ぜ混ぜ。

泡立て器だのボウルだのオシャレな用具はないです。

今度キャンプに行くので、久しぶりにスキレットを出してコレで調理します。

気持ち多めに油をしいて調理開始です。

何回も調理するのは面倒なので一回で済ませるため全部ぶち込みました。

パンケーキもといホットケーキを作る際に大事なのは火力です。

早く調理しようとして火力強めにすると表面は焦げて中身は生という悲しいことになるので、火力は弱火です。コレ重要。

暫く放置していると表面に気泡が出てきたのでひっくり返します。

縁があるフライパンでひっくり返すのは結構大変です。

箸でパンケーキの縁をつついて浮かせたあと持ち上げます。

あとはこれをひっくり返すだけですが、パンケーキの外形はスキレットと同じなので100%の精度が求められる結構大変な作業です。

セイッ…..

はい。ミスりました。

一方、焼き色はかなり良い感じ。

多少追い油をして放置したら完成です。

トッピング無しなので木台に乗っけただけですが、それだけでもアウトドア感でますねー。

で、肝心の味ですが、塩味が効いていて美味しい。

まるでバターをトッピングしたような塩加減で美味いっすね。

また、追い油したことで表面がカリカリしているのも良いアクセントになってます。

意外と食が進み、一枚ペロッと完食しました。

そしたら、やる気あるうちに片付けをしました。

スキレットはスポンジで洗ったのち油でコーティング。

次使うときはキャンプ場ですかね。

【独身男のずぼら料理】#1 ちゃんこ鍋

今日はGW最終日です。

私はカレンダー通りの休暇なので11連休フルフルエンジョイしたわけではないですが、前半は友人と皇居ランしました。

週後半は、Webサーバへのアクセス分析のためElasticSearchの構築と近所をツーリングしたくらいで基本ダラダラ過ごしてました。

GW通じて暴飲暴食をしてしまったので、最終日の夜はヘルシーな料理を作りたいと思います。

ちゃんこ鍋をつくる

まずスープを作ります。

まあー市販のタレでもよかったんですが、家にある物を調合して作れそうなので自作です。

塩分が結構入ってるだしの素を投入。

料理酒。目分量でぶち込みます。

みりんも目分量。

醤油も目分量。

親からは「減塩タイプにしなさい」と言われましたが、結局目分量でぶち込んでいるので意味ないと思い普通の醤油を買ってます。ごめんなさい。

スープ完成です。

ここで味見しても野菜の水分で薄くなって味変するのでこのまま進めます。

続いて具材をぶち込みます。

投入する具材は写真の通りですが、このほかに豆腐も入れてます。

適当に買った鶏肉が唐揚げ用だかなんかで1ブロックがデカかったものの、包丁で切るのが面倒なのでそのままぶち込みました。

普段は適当に具材をぶち込んでいますが、今回はブログ用に気持ちキレイめに配置しました。

ほうれん草ですが、なんとなくシュウ酸が気になるので一旦ゆでます。

こういうとき2口のIHコンロでよかったなぁと思います。

蓋をして5分ほどゆでました。

ほうれん草と豆腐を投入したら、あとは放置

今更ですが、ちゃんこ鍋にほうれん草が合うのかなんとも言えないですね。

まあレシピサイトで紹介されていたので大丈夫でしょ。

水分が多いので蓋をせず10分中火で煮込みます。

良い感じに煮立ってきたので味見。

適当に作った割には結構良い感じの味ですわ。

もう少しパンチが欲しいので生姜をぶち込みます。

当然、目分量です。

完成

鍋は簡単でいいですねー。

放置してれば勝手にできあがっています。

ここにきてカメラを切り替えてBALMUDA Phoneの料理モードで撮影しましたが、あんまよくないですね。

まあ味の方は普通に美味しいですね。

生姜のパンチが思いのほか少ないですが、これ以上入れると味が大きく変わるので追い生姜するのは止めておきます。

あと、和食ということで前買った日本酒「しぼりたて生原酒 小谷杜氏」を用意しました。

元々お酒がそんなに飲めない(美味しいと思えない)のでホント申し訳ないんですが、やっぱりお酒ダメですね。

一瞬ビールが美味しいと思った時期がありましたが、やっぱりお酒美味しくないです。

日本酒のラベルが気に入ったので購入→飲んでみる→やっぱりダメ→料理酒として利用

という負のループに陥っています。

【RHEL 9.5】ApacheのログをElasitcSearchで可視化してみる

どうもネトヲです。

当ブログは「業務用ネットワーク機器を運用するため」という目的で、自宅にサーバをたてそこで日夜動いています。

Google Search Console上は2023年末からデータが残っているので、少なくとも1年半ブログを運用していることになります。

アクセス数はピークで100件/日なので大したこと無いんですが、これはあくまで正規の手順でアクセスした件数で、直接IPアドレスを直打ちした無差別型のサイバー攻撃を受けた件数は全く分からないのが現状です。

ちゃんとその辺りの記録を見ようとすると、ログファイルを1行ずつ読んでいては日が暮れてしまいます。

なので、今回はElasitcSearchでApacheのログ可視化してしまおうという作戦です。

ElasitcSearch + Kibanaの構築

Webサーバであまりプロセスを動かしたくないので、ElasitcSearchは「運用監視サーバ」と呼んでいる別サーバにインストールします。

また、あまり環境を汚したくないので、Docker上に構築することにします。

環境構築手順はElastic公式ドキュメントをまんま実行するだけです。シンプル。

Install Kibana with Docker | Elastic Docs

Docker images for Kibana are available from the Elastic Docker registry. The base image is ubuntu:20.04. A list of all published Docker images and tags…

①Install Docker. Visit Get Docker to install Docker for your environment.

すでにDocker導入済みなのでスキップします。ちなみにRHEL8からはDockerは非推奨でPodmanが推奨です。

②Create a new Docker network for Elasticsearch and Kibana.

docker network create elastic

③Start an Elasticsearch container.

#メモリ割当を1GB→4GBに変更した以外はそのまま
docker run --name es01 --net elastic -p 9200:9200 -it -m 4GB docker.elastic.co/elasticsearch/elasticsearch:9.0.0

③を叩いたところ以下のエラーが発生しました。



{“@timestamp”:”2025-04-27T03:52:15.877Z”, “log.level”:”ERROR”, “message”:”node validation exception\n[1] bootstrap checks failed. You must address the points described in the following [1] lines before starting Elasticsearch. For more information see [https://www.elastic.co/docs/deploy-manage/deploy/self-managed/bootstrap-checks?version=9.0]\nbootstrap check failure [1] of [1]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]; for more information see [https://www.elastic.co/docs/deploy-manage/deploy/self-managed/bootstrap-checks?version=9.0#bootstrap-checks-max-map-count]”, “ecs.version”: “1.2.0”,”service.name”:”ES_ECS”,”event.dataset”:”elasticsearch.server”,”process.thread.name”:”main”,”log.logger”:”org.elasticsearch.bootstrap.Elasticsearch”,”elasticsearch.node.name”:”3ec751148616″,”elasticsearch.cluster.name”:”docker-cluster”}

という訳で、「vm.max_map_count」というカーネルパラメータを変更します。

やり方は色々ありますが、恒久的な変更としたいので/etc/sysctl.confを編集する方法を取りました。

#バックアップ取得
cp -p /etc/sysctl.conf /etc/sysctl.conf.org
#あとから見たときに何で変更したか分かるようにコメント付与
echo -e "Change for Elastic 20250427" >> /etc/sysctl.conf
#エラーメッセージ通りvm.max_map_countを262144に変更
echo -e "vm.max_map_count = 262144" >> /etc/sysctl.conf
#変更を即反映
sysctl -p
sysctl: /etc/sysctl.conf(11): invalid syntax, continuing...
vm.max_map_count = 262144
#変更されたか確認
sysctl -a | grep "vm.max_map_count"
vm.max_map_count = 262144

ここまでやったら再度docker runを叩くのですが、すでに「es01」コンテナが出来ている状態で同じコマンドを叩くと

docker: Error response from daemon: Conflict. The container name “/es01” is already in use by container “bcb10939605af661ac8d6f3e5b6b97fbc7ab5c604f1964a70d359265d5c94120”. You have to remove (or rename) that container to be able to reuse that name

と出るので、docker rm es01でコンテナを消します。

docker ps -a
CONTAINER ID   IMAGE                                                 COMMAND                  CREATED          STATUS                       PORTS     NAMES
bcb10939605a   docker.elastic.co/elasticsearch/elasticsearch:9.0.0   "/bin/tini -- /usr/l…"   41 minutes ago   Exited (78) 41 minutes ago             es01
docker rm es01
es01

そしたら再度docker runを叩きます。

ドカドカとメッセージがでてきますが、その中に

Password for the elastic user (reset with bin/elasticsearch-reset-password -u elastic): ぱすわーど

とElacticSearchの初期パスワードが発行されますのでコレをメモっておきます。

続いて

~ Copy the following enrollment token and paste it into Kibana in your browser (valid for the next 30 minutes):とーくん

とElasticSearchのトークンが発行されますのでコレもメモっておきます。

万が一逃した場合は再発行できます。手順はドキュメントに記載されてるのでここでは取扱いません。

「es01」コンテナ起動後はプロンプトが返ってこないと思いますが、いったんこのウィンドウはそのまま放置しておいて、新しいウィンドウを開き次の手順に進みます。

④Pull the Kibana Docker image.

docker pull docker.elastic.co/kibana/kibana:9.0.0

⑤Start a Kibana container.

docker run --name kib01 --net elastic -p 5601:5601 docker.elastic.co/kibana/kibana:9.0.0


[2025-04-27T04:16:19.867+00:00][INFO ][root] Holding setup until preboot stage is completed.


i Kibana has not been configured.

Go to http://0.0.0.0:5601/?code=347391 to get started

「kib01」コンテナについても、起動後はプロンプトが返ってこないと思いますが、いったんこのウィンドウはそのまま放置します。

メッセージ末尾の

Go to http://0.0.0.0:5601/?code=347391 to get started

をコピペしつつKibanaが動いているIPアドレスに変更し、URLをブラウザで開きます。

ここで先ほどメモっておいたトークンをぶち込みます。

正しいトークンが入力されると認証コード(Verification-code)を入力する画面が出てきます。

ここで再度新しくウィンドウを立ち上げてkibana-verification-codeを入力しコードを発行します。

今回は「kib01」コンテナ上にKibanaを構築したので、ホストOS(RHEL)上で上記コマンドを叩いても意味がありません。

なので「kib01」コンテナ上で叩く必要があります。

やり方は色々ありますが、今回は以下のやり方でコマンドを叩きコードを発行しました。

docker exec -it kib01 /usr/share/kibana/bin/kibana-verification-code

Your verification code is: xxx xxx

コードが発行できたらブラウザに戻り、コードを入力しましょう。

ElacticSearchが起動することが確認できたはずです。

そしたらUsernameを「elastic」、Passwrodはさっきメモった奴を入れてログインします。

ElacticSearchのパスワード変更

ElacticSearchへログイン後、左のタブから

Stack Management > Users

とたどっていくとパスワード変更画面が出てくるのでよしなに変更しておきます。

再起動しても起動するか確認

よくある話として「再起動すると立ち上がらない」が有ります。

なのでいったん再起動してみます。

適当なウィンドウから

docker restart  kib01 es01

をたたきコンテナを再起動してみると…

はい。やっぱり上手く立ち上がってきません。

原因調査しましょう。

まずは「es01」コンテナから。

docker logs es01 | grep "WARN"
...
{"@timestamp":"2025-04-27T05:12:54.499Z", "log.level": "WARN", "message":"this node is locked into cluster UUID [hKWpHYMgRnGbbfk_6L2LmA] but [cluster.initial_master_nodes] is set to [0e04dbe110af]; remove this setting to avoid possible data loss caused by subsequent cluster bootstrap attempts; for further information see https://www.elastic.co/docs/deploy-manage/deploy/self-managed/important-settings-configuration?version=9.0#initial_master_nodes", "ecs.version": "1.2.0","service.name":"ES_ECS","event.dataset":"elasticsearch.server","process.thread.name":"main","log.logger":"org.elasticsearch.cluster.coordination.ClusterBootstrapService","elasticsearch.node.name":"0e04dbe110af","elasticsearch.cluster.name":"docker-cluster"}
...

「[cluster.initial_master_nodes] is set to [0e04dbe110af];」ということで、master_nodesの設定周りがおかしいっぽいので「elasticsearch.yml」を見てみます。

docker exec -it es01 cat /usr/share/elasticsearch/config/elasticsearch.yml
cluster.name: "docker-cluster"
network.host: 0.0.0.0

#----------------------- BEGIN SECURITY AUTO CONFIGURATION -----------------------
#
# The following settings, TLS certificates, and keys have been automatically
# generated to configure Elasticsearch security features on 27-04-2025 04:58:57
#
# --------------------------------------------------------------------------------

# Enable security features
xpack.security.enabled: true

xpack.security.enrollment.enabled: true

# Enable encryption for HTTP API client connections, such as Kibana, Logstash, and Agents
xpack.security.http.ssl:
  enabled: true
  keystore.path: certs/http.p12

# Enable encryption and mutual authentication between cluster nodes
xpack.security.transport.ssl:
  enabled: true
  verification_mode: certificate
  keystore.path: certs/transport.p12
  truststore.path: certs/transport.p12
# Create a new cluster with the current node only
# Additional nodes can still join the cluster later
cluster.initial_master_nodes: ["0e04dbe110af"]

#----------------------- END SECURITY AUTO CONFIGURATION -------------------------

なるほど、「cluster.initial_master_nodes」の値がコンテナID名になっているっぽいですね。であればコンテナ再起動で立ち上がらなくなったのも納得です。

直接コンテナ内でviしたいのですがviコマンドがないので、ホストOSから無理矢理書き換えます。

docker cp es01:/usr/share/elasticsearch/config/elasticsearch.yml .
vi elasticsearch.yml 

cluster.initial_master_nodes: [“0e04dbe110af”]

# cluster.initial_master_nodes: [“0e04dbe110af”]

cluster.initial_master_nodes: [“{ホストOSのIP}“]

と設定値を変更します。

そしてコンテナに送り返してやります。

docker cp elasticsearch.yml es01:/usr/share/elasticsearch/config/elasticsearch.yml

そしたらコンテナを再起動します。

無事上がることを確認します。

やったぜ

さも分かったようにトラブルを解決しているように見えるかもですが、実は解決までに3時間ほどかかってます。

理由としては

からです。

Random note

Have you wondered if you could just use http://localhost:9200 as the environment variable? The answer is no, and that’s because Kibana will just query its localhost network for port 9200, and Elasticsearch IS NOT on the same machine our Kibana is. It’ll just fail with the message: Unable to retrieve version information from Elasticsearch nodes. connect ECONNREFUSED 127.0.0.1:9200.

和訳

環境変数として http://localhost:9200 を使えるかと考えたことはありませんか?答えは「いいえ」です。Kibana はローカルホストネットワークのポート 9200 を照会するだけですが、Elasticsearch は Kibana と同じマシン上には存在しないからです。「Elasticsearch ノードからバージョン情報を取得できません。connect ECONNREFUSED 127.0.0.1:9200」というメッセージが表示され、失敗するだけです。

https://apollin.com/elasticsearch-kibana-docker-custom-ports/

つまり、コンテナ内のコンフィグに「localhost」と指定すると、ホストOSではなく、自身のコンテナにアクセスしに行きます。

なので、例えばkib01にてElasitSearchのIPアドレスを指定する際にlocalhostとすると、なんのサービスの立ち上がってない自身のコンテナの9200/HTTPSにアクセスし「Elasticにアクセスできないぞ」というエラー出るわけですね。

Kibana方は初回起動時に自動でElasticSearchを探すような設定が入っていて、elasticsearch.hostsの値が決まるのですが、elasticsearch.hostsの値を変えるとエラーになります。実はここでもハマりました(「ca_trusted_fingerprint」が関係してる?)。

今回はホストOSのIPを直書きしましたが、例えばコンテナのネットワークモードを「host」にすると、bridgeせずホストOSのNICを共有する形になるので、localhostと指定しても特段問題にならないと思います。多分…

逆に言うと、ネットワークモードを指定しないと「bridge」になるので、トラブルになるわけですねー。

いやぁ、こういったナレッジって、意外なところで業務に役立ったりするんですよね。

Logstashの構築 + データ投入

さて、ElasitcSearchとKibanaの構築が終わりましたので、続いてapcheのログを取り込むために必要な「Logstash」を構築していきます。

ちな、偉そうにいってますがLogstashを触るのは人生初になるので、イマイチよく分かってないのでCopilotに訊いてみると

Logstash とは?

Logstash は、データ収集やログ管理のためのオープンソースツールです。Elasticsearch や Kibana と組み合わせて利用される「Elastic Stack(旧称 ELK Stack)」の一部として知られており、さまざまなサーバーやアプリケーションから集めたログやメトリクスを一元的に管理、変換、保存するためのパワフルなツールです。

Logstash の役割

データの収集 (Input): Web サーバーやアプリケーションのログファイル、システムのメトリクス、さらにはデータベースや提供される API など、さまざまなデータソースから情報を収集します。たとえば、Apache のアクセスログ、システムのエラーログ、またはIOTデバイスのセンサーデータなど。

データの加工・整形 (Filter): 収集したデータは、そのままでは使いにくい場合が多いです。そこで Logstash は「フィルター」と呼ばれる仕組みで、データを分割したり、必要な情報を抽出したり、不要なデータを削除する処理を行います。たとえば、Apache のログから「クライアントの IP」や「リクエストの内容」を取り出すような処理です。

データの送信 (Output): 最終的に整形・加工されたデータは、Elasticsearch などのストレージに送信されます。送信されたデータは、Kibana を用いてグラフや地図などで可視化できるようになります。

らしいです。なるほど?

よく分かってないですが、とりあえず構築していきましょう。

例によって、環境構築手順はElastic公式ドキュメントをまんま実行するだけです。シンプル。

Running Logstash on Docker | Elastic Documentation

Docker images for Logstash are available from the Elastic Docker registry. The base image is Red Hat Universal Base Image 9 Minimal. A list of all published…

①Pulling the image

docker pull docker.elastic.co/logstash/logstash:9.0.0

②Pipeline Configuration

logstashコンテナ起動前に「Apacheログファイルの指定」「ログのフィルタ」「ElasticSearchへの接続」を設定するための設定ファイルを作成します。

今回は、設定ファイルをホストOS上に作成し、そのディレクトリをコンテナへマウントすることで、設定ファイルを読み込ませる感じの動きとします。

マウントは次の3つを指定しました。

  • ~/logstash/pipeline/:/usr/share/logstash/pipeline/
  • ~/logstash/apache_logs:/usr/share/logstash/apache_logs/
  • ~/logstash/apache_logs:/usr/share/logstash/completed_log_file/

ホストOS側のディレクトリは好き勝手変えて大丈夫です。

コンテナ側も恐らく好き勝手やっちゃって大丈夫かもですが、保証は出来ません。

続いて~/logstash/pipeline/:/usr/share/logstash/pipeline/に以下のファイルを作成します。

ファイル名は「apache_access_log_ship.conf」としました。ファイル名は何でもOKかと思います。

input {
  file {
    # ログファイルの指定(ファイル名はよしなに変更のこと)
    path => "/usr/share/logstash/apache_logs/access_log"
    # ログファイルを最初から読み取り
    start_position => "beginning"
    file_completed_action => "log"
    # なんかしらんけど必要(かも)
    file_completed_log_path => "/usr/share/logstash/completed_log_file"
  }
}

filter {
  grok {
    # COMBINEDAPACHELOG パターンでメッセージをパース
    match => { "message" => "%{COMBINEDAPACHELOG}" }
  }

  # Grok により抽出された timestamp を @timestamp に変換
  date {
    match => [ "timestamp", "dd/MMM/yyyy:HH:mm:ss Z" ]
    target => "@timestamp"
    # オリジナルの timestamp フィールドを削除したい場合
    remove_field => ["timestamp"]
  }
}

output {
  elasticsearch {
    hosts => [ "{ホストOSのIP}:9200" ]
    # ElasticSearchがHTTPS接続ならtrueに
    ssl_enabled => true
    # 証明書の検証をスキップ(自己署名証明書なら必須)
    ssl_verification_mode => "none"
    user => "{elasticのユーザ名}"
    password => "{elasticのパスワード}"
    # Elasticにデータ投入時のインデックス名
    index => "access-%{{yyyy.MM}}"
  }
}

これをlogstashコンテナ起動時に読み込ませることで、起動と同時にデータ投入が終わる感じですね。

続いて~/logstash/apache_logs:/usr/share/logstash/apache_logs/にApacheのログファイルを設置します。

そのログのフォーマットですが私はデフォルトのままです。カスタムしている場合はapache_access_log_ship.confの変更が必要かもです。

ちなみにこんな感じにの中身です。

154.81.156.54 - - [05/May/2025:14:25:03 +0900] "GET /cgi-bin/luci/;stok=/locale HTTP/1.1" 301 261 "-" "-"
154.81.156.54 - - [05/May/2025:14:25:04 +0900] "\x16\x03\x01\x05\xa8\x01" 400 226 "-"

1行目はどことは言わ(言え)ないですが、某有名ルータシリーズかどうかを判定するためのリクエストですねぇ。おもしろい。

ログファイルを設置したらコンテナをスタートします。

docker run  --rm -it -v ~/logstash/pipeline/:/usr/share/logstash/pipeline/ -v ~/logstash/apache_logs:/usr/share/logstash/apache_logs -v ~/logstash/apache_logs:/usr/share/logstash/completed_log_file  docker.elastic.co/logstash/logstash:9.0.0

上手くいくと

[2025-05-05T07:04:48,259][INFO ][logstash.javapipeline ][main] Starting pipeline {:pipeline_id=>”main”, “pipeline.workers”=>8, “pipeline.batch.size”=>125, “pipeline.batch.delay”=>50, “pipeline.max_inflight”=>1000, “pipeline.sources”=>[“/usr/share/logstash/pipeline/access_log_push.conf”, “/usr/share/logstash/pipeline/error_log_push.conf”], :thread=>”#”}]

が含まれるログが表示されます(error_log_push.confは無視してください)。

なんかトラブルとコンテナが落ちるので、適宜対応してください。

動作確認

Elasticの使い方はここでは取扱いません。

Elasticにアクセスし、データが投入されている事を確認できました。

ついでにDashboardを作成してみました。

ログファイルのパースが不十分で、UserAgentとか綺麗に入ってないのでもう少しapache_access_log_ship.confのチューニングが必要ですね。

あと、GeoIPとの紐付けもできるんですが、ちょっと面倒なので割愛。

思いのほか変なリクエストはないですね。

ElasticSearchを動作させた事によるリソース消費もあんまりですね。

ログファイルのレコード数が増えればキツくなる事もあるかもですが、その時はよさげなスペックのminiPCを複数買ってクラスタリングしてやりますわw

さいごに

という訳で今回はApacheのログをElasitcSearchで可視化してみました。

あえて言うことでも有りませんが、今回は「最低限動かすこと」を目標に構築しており、業務レベルでの利用となると証明書の部分やハードコードした認証情報等、結構ヤバい所が盛りだくさんです。

なので今回紹介した手順は、あくまで構築の足がかりとしての参考情報程度に留めておくようよろしくお願いします。

【GSX-S750】ツーリングサポートゲル&エアスルーシートを装着した【DAYTONA】

どうもネトヲです。

愛車二号ことGSX-S750(S750)ですが、納車されてから約半年経過しました。

距離にして1,500kmくらい走りましたが、

  • クラッチの重さ
  • サスペンションの突き上げ
  • ケツ痛シート

が気になるなぁと思う今日この頃です。

今回はその中でも一番お手軽な「ケツ痛シート」を改善する話です。

買った物

ケツ痛を改善する方法やアイテムは色々ありますが、今回はDAYTONAの「ツーリングサポートゲル&エアスルーシート」を買いました。

ツーリングサポートゲル&エアスルーシート|株式会社デイトナ

ツーリングでのお尻の痛みを軽減するバイク用クッション「ツーリングサポートゲル&エアスルーシート」。座圧分散と衝撃吸収に優れ、長距離ツーリングの痛みや不快感を軽減します。また、高速走行時の微振動によるお尻の痺れ対策にも最適です。 ツーリングサポートゲルは、DAYTONA COZYシート※1 …

決め手は、令和最新版中華ではなく日本企業が発売元なのと価格、そしてなんかスースーするやつが付いているからとなります。

一般にバイク用クッションと言えばプロトの「ゲルザブ(GEL-ZAB)」が有名だと思いますが、はっきりいって高いです。

その点、ツーリングサポートゲル&エアスルーシートは一万ちょっとで買えるのでいささか買いやすいです(まあそれでも安くはないが)。

本当は用品店で現物確認してから購入すべきでしょうが、めんどくさやがりの私、なにも考えずAmazonでポチりました。

装着

愛車一号こと701 Supermotoの感覚でいたので作業するまで気にもしなかったんですが、S750のシートを外すのが結構というかかなり面倒です。

タンデムシートは鍵一発で開けられるのですが、ライダーのシートはサイドカウルを外す必要があります。

やり方はネットに沢山転がっているので当ブログでは取り上げません。

ちなみに私は「tandem819」さんの記事を参考に作業しました。

サイドカウルを外すとシートを固定している六角がコンニチハしてきます。

この六角を外しシートを気持ち後方に力を入れつつ上に引っ張るとシートが取れます。

端から見たら大した作業ではないんですが、バイク整備が全く出来ない私にとっては達成感が半端ないですね。

シート下はバッテリと回路でごちゃごちゃしてました。

現状、スマホ充電に対応してないS750なので、DAYTONAのアクセサリー電源ユニット 「D-UNIT」を装着し、電源を取り出せるようにしたいんですよね。

話は戻り、シートに「ツーリングサポートゲル」を装着しました。

うーん…まあ分かってたけどダサいわ。。

シートが簡単に取り外せるなら、必要な時に装着してそれ以外は外す、みたいな運用も出来るんですが、S750はそうはいきません。

さらに「ツーリングサポートゲル」の上に「エアスルーシート」を装着。

色々ごちゃごちゃして後のシート裏はこんな感じになりました。

「ツーリングサポートゲル」のマジックテープが長かったので、双方を適当に結んで距離を稼いでからマジックテープで留めました。

「ツーリングサポートゲル」と「エアスルーシート」、おそらく同時開発ではないので、それぞれ固定方法がマジックテープとゴムバンドとちぐはぐです。

セット販売するならもう少しどうにかしてほしいとは思う所ではあります。

後は逆の手順で取り外したシートとカウルを装着するだけ。

元に戻せるかドキドキしましたが、カウルの爪が折れるようなこともなく元通り。

作業完了です。

なんかおっさんのバイクっぽい見た目に変化しました。

まあ私アラサーなので年相応になったとも言える訳ですが、スタイリング重視の701Supermotoには絶対装着したくないですねw

装着後の印象

どれくらい「ケツ痛」が改善されたかの確認のため適当に走りに行こうと思ったんですが、今日はGW真っ只中。何処行っても渋滞してます。

なので、跨がった時の印象のみとなります。すみません。

いわゆる社長イス的なフカフカとした感じではなく、高反発枕のような固さです。

S750標準シートより固いと思います。

バイクのシートって乗り始めの印象と数時間乗った時の印象って全然違くて、それこそ初めてS750に跨がった時は「このシートなら何時間でもツーリングできる」と思ったんですが、いざ乗ってみると直ぐケツ痛になったという経験があるので、現時点ではなんとも言えないですね。

ちなみに701 Supermotoはシートがかなり固いので「これで長距離は無理だな」と思っていたんですが、案外痛くならないんですよね、不思議。

あと、言わずもがなですが、シート高が1cmくらい高くなりました。

S750のようなシート高が低い車種なら気にならないレベルですが、アドベンチャーバイクみたいな必要以上にシート高が高いバイクは注意が必要です。

【サザナミインコ】性格や後悔について個人的まとめ

どうもネトヲです。

私のブログでたまに取り上げるサザナミインコの記事ですが、アクセス数的にはかなり上位に君臨する人気コンテナだったりします。

10年以上飼育して感じるサザナミインコのせいたいについて
サザナミインコ飼いの一日をまとめた
https://www.tuuzyouno3bai.com/?p=257
我が家のサザナミインコが10歳になりました

Google Search Consoleを使うとどんな検索クエリでたどり着いたかが分かるんですが、今回は「サザナミインコ」が含まれる検索クエリの中からネタに出来そうな物をピックアップして私感を述べていこうと思います。

サザナミインコ 性格

個体によるという前提にはなりますが、コレまでお迎えした2匹については

「おっとり」「マイペース」で、過度に干渉される事を嫌うが、構ってあげないと呼び鳴きする時もある

かなと思います。

例えば放鳥時、気に入った場所を見つけたら置物の如く留まり、そして、腹が減った時や飼い主の行動から何かを察した時に勝手にゲージへ帰っていきます。そんなインコです。

だからと言って、放鳥を怠ったり、放鳥時に飼い主の姿が見えなくなると結構なボリュームで呼び鳴きすることもあります。

人間とは一定の距離感を保ちつつも、たまに干渉してあげないといけない意外とワガママなところがあると思います。

例外として、幼鳥の頃は「コイツ本当にサザナミインコだよね...?」と思うくらいアクティブになります。

ピーピ-鳴きながら家中飛び回ってゲージに入ることを断固拒否、まるでコザクラインコのようです。

半年もすれば落ち着きます。多分。

サザナミインコ 寿命

これも個体によりけりですが、一般的には10~15年と言われています。

今飼っている2代目は11歳くらいですが、ここ数年で明らかに飛行能力が落ちました。あと溜め糞する量も減ったような。

睡眠時間も18時頃にゲージを暗くしないとピーピー鳴くようになりました。

食欲は健在で野菜やフルーツも普通に食べます。

若い頃から動作がノロノロしているので歳をとっても変化がわかりづらいですが、顔周りに白髪的な白い毛が生えてくるようになりました。

サザナミインコ 後悔

なんやこの検索クエリと思いますが、実際にサザナミインコを飼ってみて後悔した点を知りたいということでしょうね。

なので「外泊し辛い」「お金がかかる」などのペットに関する一般論は排除した上での話とします。

  • 意外と手がかかる

鳴き声の大きさや行動から「飼いやすい」と言われているサザナミインコですが、だからといって「手がかからない」訳ではないです。

普通のインコと同じように、ゲージの掃除,餌やり,日光浴,水浴び,放鳥,爪切りが必要です。

個人的な感覚にはなりますが、平日にゲージに入れっぱなしでもまあ大丈夫です。が、土日は一日放鳥する時間を作ってあげる必要があります。

  • インコらしくない

インコのなんとなくのイメージとして、人間と一緒に遊んだりおしゃべりしたりと人間との距離が近く、たまにお茶面な仕草をして楽しませてくれる、みたいな物が私にはあります。

しかし、サザナミインコは先述した通りの性格なので、そういったインコらしさはあまり持ち合わせていません。

同じ部屋の中にいても存在感がゼロで、意識しないと存在を忘れることがあります。

  • 糞がヤバい

溜めに溜めた糞を使って放鳥時に絨毯爆撃をしてきます。

糞も水っぽいので、素材によっては跡に残ります。

とにかく糞はヤバいですね。

なのでウチは放鳥前に糞をさせてから飛んでもらってます。

サザナミインコ 飼育 飼い方

特別病気にかかりやすいという訳でもなく、前飼っていたコザクラインコと同じかそれよりも飼いやすいと思います。

とにかく鳴き声が静かで無駄鳴きも少ない、噛まない、ちゃんと用意すれば2泊3日家を空けても大丈夫、とインコの中では一番といって差し支えないレベルで飼いやすいです。

ペット飼育初心者や私のような一人暮らしの人間にぴったりです。

巷で言われているほど室温や湿度を気にする必要はなく、人間が快適に過ごせる設定にしておけばOKですが、夏は基本エアコンつけっぱ、冬はヒーターつけっぱなので電気代はかかりますね。

飼い方も普通のインコと同じです。なにも特殊なことはありません。

まとめ

ということで、サザナミインコについてよく検索されている事について自分なりにまとめてみました。

一昔前は「マイナー」と言われていたサザナミインコですが、今となってはその辺のペットショップで見かけるようになりましたね。

なんかの参考になれば幸いです。

新品購入したSteinberg UR44Cに初期不良があったので修理してもらった件

どうもネトヲです。

私がDTMを始める際に店員さんにオススメされたSteinbergのUR22mkiiですが、多分5年くらい通電しっぱなしです。

ですが、全然ぶっ壊れません。

UR22mkii自体、コレと言った不満もないですしこのまま使い続けてもいいんですが、新しいもの好きのワタシ、我慢出来ずに新しいオーディオインターフェースを買いました。

そう、それが今回のネタ「UR44C RD」です。

無印のUR44Cでも4万はするのになぜか楽天市場で38,900円で売っていたので、これは買うしかなぇということです。完全に勢いでかいました。

まあUR22mkiiはINが2chしかなかったで、シンセを繋げると他の機材を使えなくなるのがUR44CはINが6chもあるのでギター等々繋げられるのでまあよしとしましょう。

第一印象、カッコいい。

ボタン配置に多少変更がありますが、基本UR22mkiiと使い勝手は同じ。

背面はUSB-C(USB 3.1 Gen 1)に対応していてバスパワー動作できますが、基本DC12Vで給電してやるのがいいでしょう。

で、UR44CというよりUR-Cシリーズの最大の売りはDSP内蔵によるほぼゼロレイテンシでのエフェクトです。

エフェクトはdspMixFx UR-Cというソフトウェア(Windows/Mac※/iOS)上から制御することになります。

※Appleシリコン搭載Macへのインストールはかなり特殊なので、よく手順書を読んでから作業することを強くオススメします。

jpfaq

No Description

私はそんなにエフェクトを使う機会がないで何が出来るかは公式を参照してほしいのですが、ぱっと触った感じでは以下のエフェクトがよさげかなと思いました。

  • ギターアンプシミュレータ(Clean/Crunch/Lead/Driveの計4つ)
  • DUCKER(オートミキサ)

特にアンプシミュレータは、ぱっとエレキの音を出したときに重宝します。

本ソフトウェアはreleaseされてから頻繁にアップデートがされており、初期バージョンから最新バージョンでは大きく見た目も使い勝手も変わっています。

なので、本体に付属していた取説は古いためあんまり参考にならないので公式サイトから最新の取説を持ってくるわけですが、差分しかありません。

No Title

No Description

設定する時にそれぞれの取説を右往左往する場面があって「マジ勘弁してくれ」って何回もなりましたわ。

ヤマハさん。UR-C V3.0対応の完全版取説作ってください。。

で、PCに接続し適当に音楽を聴いている時に問題発生。

全然ボリューム上げてない状態であっても簡単に音割れするんですよね。

ちょっと言葉で説明するのが難しいので、音割れ発生時の実際の音声を聴いてみてください。

高音域で明らかに音割れしていますよね。おまけに音飛びしてるしwコレは酷いわ

同じ環境にてUR22mkiiで再生した時の音声は以下。

なんの問題も無く再生できてます。音の解像感がまるで違います。

この時点では設定の問題かなと思い色々と検証しましたが結局改善せず。

なのでコレまでの検証結果を報告しつつヤマハに相談したところ…

> 当方
> ・Apple M3 Pro(15.2)
>  ・YAHAMA Steinberg USB Driver(V3.17)
> ・UR44C(V3.20)
>  ・MacとはUSBハブ経由で付属のUSBケーブルで接続
>  ・付属ACアダプタで電源共有
>  ・フロントのPHONESにヘッドホン接続
>  ・リアのMAIN OUTPUTにHS3W接続
> を使用しております。
>
> UR22mkⅡの更改のためUR44Cを購入し、Macへ接続後、TOOLS for UR-C V3.2.0にてソフトウェアのインストールやファームウェア最新の物にしたのち、Youtubeの音楽を再生したところ、UR22mkⅡの時と同じ音量でありながら低音域で音割れしてしまします。
>
> 当方で確認した事は以下です。
> ・USBハブを使わず直接Macと接続
> ・iPadとAndroidに接続し音楽再生
> ・USBバスパワーで給電
> ・TOOLS for UR-C V3.2.0再インストール
> ・Apple Musicや手持ちのMP3ファイル再生
> こちらの全てで音割れが発生してしまいます。
>
> 一時的な対策として、入力ソース(例えばYoutubeの音量調整スライダ)の音量を絞ってUR44C側の音量(dspMixFx側もしくはフロントのボリュームノブ)を上げることでなんとか聴けるレベルになりましたが、UR44C側のOUTPUTノブとHS3Wの音量調整ノブがほぼ最大であり、これ以上大きな音が出せないような状態です。
>
> つきましては、こういった際の確認事項や正しい設定方法があれば教えてください。
>

回答:
スタインバーグ製品をご愛用くださいまして、誠にありがとうございます。

お問い合わせの件、お困りの状況につきましては要因が多岐にわたるため、要因の特定が困難です。
※UR44Cが要因とは限らないことにご留意ください。

つきましては、既にご実行済みかと存じますが、念のため、再度下記Q&Aの内容をご確認ください。

・【CI/UR/UR-RT/UR-C シリーズ】再生の際にノイズや音切れが発生してしまいます。対処方法を教えてください。
 

jpfaq

No Description

上記をすべてご実行いただいても状況が改善され無い場合、お困りの現象がUR44C側の要因であるか、コンピューター側の要因であるか、問題の切り分けのため、UR44Cを点検・修理に出していただくようお願いいたします。

製品ご購入直後である場合は、初期不良の可能性も含めて、まずは製品をご購入いただいた販売店様にご相談ください。

仮に、何らかの理由により販売店様にご相談いただけない場合は、下記「ヤマハ修理ご相談センター」に点検・修理をお申し込みくださいますよう、お願い申し上げます。

修理ご相談センターはお電話での受付・ご相談をおこっております。
下記へご相談くださいますようお願い申し上げます。

 ・スタインバーグ製品サポートメニュー(ページ下部の「修理に関するお問い合わせ・ご依頼窓口」をご参照ください)
  

ヤマハ | スタインバーグ製品サポートメニュー – 日本国内でのスタインバーグ製品のサポートについて: 株式会社ヤマハミュージックジャパン

以下の内容をご確認いただき、お問い合わせください。 お問い合わせの前に よくあるお問い合わせ(Q&A)のご用意があります。ご活用ください。 クイックスタートガイド、取扱説明書、オペレーションマニュアル等(以下説明書とします)をお読みください。 最新のアップデータを適用することで解決する場合がございます。ダウンロードより該当製品の項目をご確認ください。 お問い合わせの前に、MySteinbergのユーザー名、メールアドレス、パスワード、eLiceser番号などをお手元にご用意ください。ご登録がお済みでない場合は、ご登録をお済ませになり、上記情報をご用意の上、お問い合わせください。 また、【Steinberg共通】お問い合わせを最短で確実に解決するためにをご確認ください。   サポートのご提供に際して 弊社が代理店としてSteinberg社からあらかじめ入手できている情報の範囲で、サポートをご提供いたします。 メールは受付順に対応しております。(電話でのサポートは、2017年3月31日をもちまして、終了させていただきました。) 弊社の判断により提携スクールによる有償サポートをご案内させていただく場合もございます。 (例) ・お問い合わせ件数が同一製品について累計で10件を越えた場合 ・お問い合わせ内容から、説明書等を充分にお読みいただけていないと判断できることが複数回続いた場合 ・本ページのご案内内容をご了承いただけない場合 弊社または担当スタッフに対する誹謗、中傷、暴言、恫喝等により、サポートが困難だと判断した場合、サポートを終了させていただきます。あらかじめご了承ください。   サポートの範囲につきましては、以下をご参照ください。 範囲内 製品のインストールに関するご質問 製品のライセンスに関するご質問 ユーザー登録及び製品登録に関するご質問 製品の操作方法に関するご質問 製品のプログラムの不具合に対するご質問   範囲外 以下の場合はサポート範囲に含みません。 弊社が販売していないSteinberg 製品、およびeLicenserを使用する他社製VSTプラグイン Cubase LE等サポート対象外製品を使用する場合のeLicenser Control Center 製品の譲渡についてのお問い合わせ データの破損・消失への回復と補償 製品に起因しないと考えられる問題 (例) ・製品が本来定めているディレクトリ以外へのインストール、ファイル/フォルダの移動 ※一例として、Windows OSで各ソフトウェアのプログラム本体をシステムドライブ(C:ドライブ)以外にインストールした場合。 ・動作環境外OS(BootCamp[Mac]、仮想OSでの使用を含む)におけるお問い合わせ ・システムの復元(Windows)、Time Machine/移行アシスタント(Mac)を使用して発生した問題 製品のアルゴリズムやテクノロジーに関わる部分の調査、解説 (例)ロジカルエディター / MIDI デバイスマネージャー / コードトラックのコード判別ロジック / マクロ機能 / エクスプレッションマップ / VSTシステムリンク / スクリプト言語(Lua) コンピューターの基本操作、およびネットワークの設定 (例)コンピューター、および他社製品のセキュリティ機能を解除しない状態でのインストール、およびそれに関連する操作、設定、解除方法 音楽理論、音響技術、音楽制作におけるノウハウ、テクニック 例)音圧の上げ方、ワブルベースの作り方、ボーカルに適切なEQのかけ方、スクリプト言語(Lua)の書き方 機種名、メーカー名、もしくは自作における部品名を挙げてのコンピューターの購入相談、動作保証※詳しくは 動作環境ページと、音楽制作環境についてページにある情報をご確認ください。 日本語以外でのお問い合わせ 製品およびコンピューターの OS を日本語以外にした状態でのお問い合わせ ヤマハ 修理対応終了 / コンピューター関連廃番製品 / サポート対象外製品 メール対応における担当者指名 メールアドレスの記入間違え、プロバイダーやキャリア等によるセキュリティ設定、メールソフト(ブラウザメールを含む)の設定等によりメール不達となった場合 技術・アイデアなどのご提案(新製品のアイデアなど)※ 詳しくはこちら をご参照ください。 当窓口からご提案した検証、および情報提供にご協力いただけない場合 その他、弊社がサポートの範囲を超えると判断した場合

※当窓口は土日祝日を休業とさせていただいておりますが、この度はお客様のご不便を鑑み対応させていただいております。

以上、要用のみにて失礼いたします。
今後とも、スタインバーグ製品のご愛顧を賜りますよう、お願い申し上げます。

という感じにで、一ヶ月以上かけて色々検証した時間を返してほしいと思ったくらいテンプレ対応でした。

なので購入店である「イシバシ楽器 WEB SHOP」に相談したところ「初期不良の可能性があるから着払いで送ってちょ」とメッセージがあり、色々やり取りしました。

結果としては購入店でも事象が再現することを確認したため、そのまま修理となりました。

修理に出したと連絡があってから2週間経たないうちに販売店から「修理完了したのでおくったよ」と連絡がりました。

修理から返ってきたUR44Cには「ヤマハアフターサービス完了報告書」が入っていて、音割れの原因が記載されてました。

「電源部を含むAM基板交換。動作点検。」

この「AM基板」が何かは調べても全く分からないのですが、とりあえずなんかの基板をまるごと交換したっぽいですね。

PCに接続して再生してみると、当たり前ですが音割れ等なくふつーに再生できました。

仕事柄トラシューする事が多いので今回色々と検証しましたが、ソフトウェアではなくハードウェアが原因だったとは。。次は何も考えずメーカ(販売店)送りにしようと思います。

あ、あと「イシバシ楽器 WEB SHOP」ですが、親身になって対応してくれました。通販で購入した商品でのトラブルって手続きが面倒で、販売店が適当な対応をするものと思ってましたが、全然そんな事ないですね。

イシバシ楽器さんの対応は神です。

GSX-S750と平日の「箱根ターンパイク」へ行ってきました

どうもネトヲです。

今日は休日出勤の振り替え休暇ということで、平日ではありますが愛車二号ことGSX-S750(以下、S750)にてツーリングへ行ってきました。

なにかきっかけがあった訳ではないんですが、なんとなく箱根ターンパイクへ行きたくなたのでそこを走りつつ、行き当たりばったり適当な場所で休憩しようという作戦です。

箱根ターンパイクのロードマップは以下の通りです。

社会人になって、時間はお金で買うモノという考えに至ったワタシ。問答無用で高速道路を使います。

ちなみに使用した高速道路はつい最近、ETCシステム障害で何かと話題になった中央道。一抹の不安を覚えつつも特に問題なくETCレーンの利用が出来ました。

S750で高速道路を走るのは結構久しぶりですが、4気筒の割に意外と手に振動が伝わるなと思いました。

愛車一号こと701 Supermoto(700cc単気筒のバケモン)程ではありませんがそれなりに振動がありますし、どっちも防風のためのカウルはついてないので大型バイクといえど高速道路をずっと走り続けるのはしんどいですね。

一回くらいはツアラー色の強いバイクに乗ってみたいです。R1250RSとか。

PAで休憩しつつ、無事目的地へ到着。

料金所ですが「ETCX」という名前のくせにETCとは互換性のないシステムを採用しており、利用には事前登録が必須であることを忘れていた私。

駐車場で通行料金650円を準備したりGoProを設定している間に何台も車やらバイクやらが通り過ぎていくわけですが、GT-Rやらフェラーリ、パニガーレ等々高級車がやたら多かったです。

お金持ちは平日こんなことしているんですぇ。うらやましい。

料金所でのやり取りを見てましたが全員現金で支払ってましたね。

ちょうど桜が満開だったので、皆さん駐車場なり路肩に車を停めて写真を撮ってました。

この辺りの区間を公式では「桜のトンネル」と呼んでいるようです。

私も写真を撮ろうかなとは思いつつも面倒くささが上回ったのでスルー。

平日の箱根ターンパイク、交通量が少なくて非常に走りやすい。

道幅も広く舗装も綺麗で、急なコーナーもないので尚ヨシ!

見えづらいかと思いますが、NSXにGT-R、そしてRX-7が連なってます。

いやぁ凄い。。。

「アネスト岩田スカイラウンジ」にも立ち寄らずスルー。

ココで「箱根ターンパイク(箱根小田原本線)」は終わりです。

箱根小田原本線は13kmしかないので、私みたいに停車せず走りきってしまうとものの数十分で終わってしまいます。

今振り返るとかなりもったいなかったなぁと思いますね。どっかに立ち寄れば良かったです。

そのまま箱根伊豆連絡線へ向かいます。

気温が高くなってせいか富士山がくすんで見えるようになりましたね(黄砂や花粉の可能性が微レ存)。

やっぱり富士山を見るなら冬の時期に限ります(写真は2月に撮影)。

結構路面を補修した跡があるので、この辺りは結構積雪するんでしょうね。

「平日に見かけるバイク、大体レア車説」コレ、前々から提唱しているのですが、だれか検証してくれると助かります。

この先箱根伊豆連絡線となりますので、170円の課金が必要です。

左に見える建物が「バイカーズパラダイス南箱根」という所でバイク乗りの聖地と言われているようです。この時も20台以上バイクが止まってました。

まあ、私は陰キャなのでこういうスポットが嫌いです。なので当然スルー。

箱根熱海峠線(静岡県道20号)を適当に走っていたら「森の駅 箱根十国峠」という道の駅的な何かがあったのでここで昼食を兼ねた休憩をすることにします。

ケーブルカーで「十国峠展望台」まで行けるようですが、先述の通りなんかくすんでいるのでスルー。

私は無課金エリアから見える富士山で十分です。

施設に入ると、お土産コーナーや食堂があったりと普通の道の駅でした。

折角なので自分用にお土産を買おうと思ったんですが、支払った分の価値があるかはともかくお土産コーナの物品って結構良い値段しますよね。

出張でお土産を買うと普通に1万円とか支払っているので、自分の金銭感覚が恐ろしくなります(必要経費だからまあいいんですけどね)。

という訳でお土産をスルーし、食堂でカツカレーを注文しました。

待っている間、暇だったので今日撮ったコンデジの写真を見ようとしたところ…

おいィィィ!

はい、本日ちょくちょくコンデジで写真を撮っていたんですが、それら全てSDカードではなく亜空間に保存されていたようです。

前半、全く写真がないのはそのせいなんですよね。

SDカードを挿入し忘れた私が悪いんですが、でも「NO CARD」という表示、点灯ではなく点滅する仕様なんですよ。

このコンデジ、電源を入れて数秒は絶対「NO CARD」が出るので、点滅のシーケンスと目視したタイミングが悪いと「NO CARD」が消えてSDカードを認識したと錯覚しました。最悪。

あと、NO CARDならシャッター自体押せなくするか、なんか警告画面を入れてほしいわ。

泣きながらカツカレーを食いました。

あ、そういえば熱海温泉の温泉むすめ「熱海初夏」ちゃんに遭遇

声優が本渡楓さんなんですねー。

飯坂ホテルジュラクにて撮影

ちなみに、私は飯坂温泉の「飯坂真尋」ちゃんが一番好きです。親の地元だし声優がWUGの吉岡茉祐さんだし。

すみません。話がそれました。

その後は直帰したわけですが、帰り道に納期という名の社畜ブーストがかかったタウンエースと遭遇。人のことをあれこれ言えるほど真っ当にに生きてる人間ではないですが、それにしてもマジでめちゃくちゃな運転してたのでアレは一発免停コースですね。

S750を軽く綺麗にしたのちバイクコンテナに置き、自宅へ戻る途中にいつも気になっていたお茶屋さん「菊川園」さんへ立ち寄りました。

なぜ気になっていたかというと…

まあ、この通りです。

中学生の時に視聴しアニメオタクに、さらにはDTMにハマるきっかけとなった「とある科学の超電磁砲」の等身大パネルが設置されているんですよ。

あのときはまさか自分がレールガンの聖地に住むなんて夢にも思わなかったなという話やらキャラクター(佐天さんと初春)かわいいよねぇ。等々店番をしていたおばちゃんとしていました。

ワイはどちらかというと佐天さん初春が好き。

自分の親よりも年上の方とレールガンの話が普通に出来るって結構新鮮な感覚です。

おばちゃんにレールガンはアニメ4期が決定したことを伝え、お店を後にしました。

ちなみに今日の戦利品ですが…

まあそうなるわな。

というわけで、お茶を飲みながらブログを書き上げたという報告を持って〆。

A Day in the Life of a Biker

どうもネトヲです。

本日3/27(木)ということで、なんてことない平日です。

しかしながら私にとっては貴重な休日であり、天気も良いのでバイク(701 Supermoto)のオイル交換をしてもらいにディーラへ行ってきました。

今日は暖かいを通り越して暑い。

一体春は何処へ行ってしまったのでしょうか。

インナープロテクタの上にKTMパーカー、オフヘルにオフブーツを装備して、バイクに乗る。

ショーウィンドウに映る姿を見て「やっぱモタードにはこの格好がいいなぁ」と思いつつディーラ「KTM府中/ハスクバーナ府中/ビーフリー府中店」に到着。

年次点検の時は数時間くらい作業に時間がかかるので、府中駅まで行って適当な映画を見て時間を潰すんですが、オイル交換は大体1時間かからないくらいなので時間の潰し方に困る時もあります。

しかし、今日の私は明確な目的があります。それは…

https://twitter.com/rico_hiroshima_/status/1904400559555367271

です。

VFX-WRというSHOEIのヘルメットは既に持っているので、ちょっと緩いですがLサイズを買っておけばまず問題無いことは分かってるため、通販で予約できないか色々調べましたがどこも取り扱いしてないんですよね。

ということで「2りんかん」な訳です。

ディーラから徒歩11分くらいで府中2りんかんへと到着。

平日の少し閑散としたバイク用品店の雰囲気というか空気、なんか好き。

気になっていた56デザインのフルメッシュジャケットの価格にビビって買うのをためらったのち、ヘルメットコーナへ足を運びました。

適当なカラーのZ-8を手に取りMサイズとLサイズを被ってみましたが、やはりMサイズはキツイ。

とは言えLサイズになると緩い。

「まあLサイズでええか」ということで近くの店員さんに初音ミクモデルの予約をしたい旨を話すと、「使用用ですしょうか、それとも観賞用でしょうか」と想像だにしない返事が返ってきました。

どうやら、直近で対応したお客さんが上記用途で初音ミクモデルを2個買ったらしく、それを受けての返事だったそうです。

私も本当はそうしたいんですが、88,000円するヘルメットを2個買えるほどの余裕はないので「基本観賞用ですがたまに使うかもです」と少しひねくれた回答をしました。

それで、偶然話しかけた店員さんが「SHOEI TECHNICAL SHOP・アドバイザリースタッフ」だったらしく、話の流れでフィッティングサービスをしてもらうことにしました。

頭のサイズを測ってもらうとMサイズとLサイズの中間あたりらしく、Lサイズに内装を追加する方針。

相手はプロなので一発目の調整で良い感じのフィット感になりました。VFX-WRも調整してくれんかねぇ。と思ったり。

Z-8 初音ミクは8月発売で、自宅に直接届けてもらうお願いしているので、今日は支払いのみ。

限定ではなく受注生産なので実物を見てからの購入でも十分なんですが、こういうのはノリと勢いですよね。

すでに大阪モータサイクルショーにて展示されいるらしく、いくつか写真を見るとマットではなくクリア塗装っぽいですね。良かった。

ヘルメット本体が88,000円、フィッティングで3,300円の計91,000円。うん高い。

ちょうど、ディーラからオイル交換が終わった旨連絡があったので少し遅れることを伝え、2りんかん最寄りの吉野家で牛丼を食べました。

牛丼も高くなりましたよね。セット頼むと1,000円超えますから。高級です。

そしてディーラへ戻りました。

点検やタイヤ交換、不具合対応、オイル交換等々かなり通っているので、一部のスタッフさんから顔を覚えてもらえるようになりまして、それで色々と立ち話しました。

話の中心はやはりKTMの司法再建手続きの件で、その関係で部品がバックオーダー状態で入りづらいらしいですね。

あと、890や990等の2気筒モデルの不具合がやたら多いこと、2025年モデルは日本ではほぼほぼ流通しないだろうこと、今年のノルマの話等、いろんな話を聞けました。

こういう裏話は大好きなので、これからも聞けるようディーラとの良い関係を築いていこうと思います。

このまま帰宅しようかなとも思いましたが、週末にかけて天気が崩れそうなので、駐輪場(バイクコンテナ)に戻ってGSX-S750に乗り換えてもう少しツーリングすることに。

結構貴重なツーショット。

しかしGSX-S750の正面、なんかアレですねw

側面はカッコいいんですがどうしてこうなったのか。。

久しぶりにS750乗りましたが、4気筒エンジンと少しレーシーなポジションで乗っていて非常に楽しい。

欲を言えばやっぱりクラッチレバーが軽ければ最高なんですが、まあいいか。

Google Mapで適当な目的地を探し、八王子の「戸吹スポーツ公園」に行くことにしました。

そして目的に到着してみると、ちゃんと駐輪場がありベンチもありました。

施設の雰囲気が実家近くのスポーツ施設と似ていて非常に落ち着きます。

あたりを散策するとアイスクリームの自販機を発見。

バイクを眺めながらアイスを食べてボーッとする。この時間が至福です。

生のいちごは嫌いですが、加工されたいちごは好き。

帰宅後、「魔法少女まどか☆マギカ MAGIA EXEDRA」のプレイし始めたんですが、ヤバい、ここ数日はずっとプレイしてそうなくらいハマっています。

リセマラせずとも一発目で「暁美ほむら」が出て、その後の10連で再び出るわで速攻1凸できました。

大型バイクを2台持ちした経緯とか感想とか

どうもネトヲです。

私は2023年3月からハスクバーナの「701 Supermoto(以下、701SM)」、2024年11月からスズキの「GSX-S750(以下、S750)」の計2台の大型バイクを所有しています。

今回は実際に所有してみての感想を書いてきたいと思います。

2台持ちしようと思ったきっかけ

元々2台持ちしたいという気持ちは毛頭無かったんですが、701SMでツーリング中に財布とスマホを落とし絶望していた時に話しかけてくださった”とあるバイク乗り”の影響で2台持ちしたいなと思うようになりました。

【愚痴】財布とスマホを道路に落とし、人生で最も最悪なツーリングになったけど新しい出会いもあった

バイクに限らずですが、どんな物も「あちらを立てればこちらが立たず」で、何かを得るためには何かを捨てる必要があります。

701SMは、およそ大型バイクとは思えない車体重量や、各所にわたって割り切った設計等々、一言で表すなら味の濃いラーメンのようなバイクです。

それ故にたまにはさっぱりヘルシーなホッケ定食を食べたくなることがあり、なんやかんや2台持ちする運びとなりました。

バイクの選定

2台持ちすると決めた後はさてバイクはどれにしたもんかと悩む訳ですが、最初は原付二種を考えてました。

特にDax125はレンタルしてまして、返却時に「コレください」と言いかけるくらいに気に入りました。

普通に公道を走る分には不満を感じないパワー感と取り回しのしやすさ、そしてなによりも見た目がいいんですよね。

セカンドバイク候補”Dax125″をレンタルしてきた

でも、Dax125は「原付二種の中で一番欲しいバイク」であり本当に欲しいバイクではなかったんですよね。

しかし、本当に欲しいバイクについても現実的な金額で購入できるもの・できないものがありますので「上限100万円まで」とラインを決めて再度、バイクを探していました。

メーカHPやGooBikeを見ていって「CRF450L」「GSX-S750」の2車種に絞り、メンテナンスの事、コレまで所有したバイクが全て単気筒で4気筒に憧れがあった事、いっちゃん好きなアニメに登場したバイクの姉妹車種である事を踏まえてGSX-S750(レンタルアップ)にしました。

【バイク納車】GSX-S750を購入しました

【ブログ版】https://www.tuuzyouno3bai.com/?p=2894 どうもネトヲです。 ということで前の動画の宣言通り、バイクを増車しました。 これまで単気筒エンジンのバイクしか乗ってこなかった私ですが、さすが4気筒。エンジンの滑らかさや乗りやすさが全然ちがっていてこれはこれで楽しいですね。 これからは701Supermotoとの2台体制となります。

実際に2台所有してみて

金銭面

私はお金持ちではありませんのでバイクに任意保険をかける必要があります。

任意保険はバイクことにかける必要があり、新規加入の場合、今加入している保険の等級は基本引き継げないため6等級からスタートしますので、単純に保険料が今の倍になるという世界ではありません。

また、オイル交換や定期点検といったメンテナンスにかかる費用や、軽自動車税(6,000円/台)と細々お金がかかります。

ここまでは想定内の出費なのでまあ良いとして、このほかに色々出費しているんですよね。

例えばヘルメット。

手元にはやれた「TOUR-CROSS3 」と、701SM用に買った「VFX-WR」というオフヘルがあるわけですが、どちらもS750用として使うのは微妙ということで、「ASTRO-GX」を買いました。

他にもスマホマウント(OXFORDのCLIQR)やシートバック、ETC車載器等々を買っていたりと、使い回しの利かない物が結構あるんですよね。

幸い、服装については上下共にインナープロテクタを持っていたので使い回し出来てますが、56designのジャケットが欲しいと思っている今日この頃。どうなることやら。

モチベーション

「バイクに乗りたいんだけど乗りたくない」という気持ちになったことはありませんか?

これって「バイクに乗りたいんだけど(今所有しているバイク)には乗りたくない」だと個人的には思っていて、2台持ちすることで解消することができます。

特に701SMとS750のように何から何まで異なる2台だと「今日はなんとなく単気筒の気分」「今日はなんとなく4気筒の気分」といった感じでその日の気分で乗るバイクを選択出来ます。

さらに、午前は701SM、午後はS750といった乗り方もできますので、バイクに乗る事へのモチベーションは1台持ちの時よりか高くなったなと感じています。

一方で、昨年実績ベースで年間走行距離が3,000km弱だったわけですが、2台持ちすることでそれが6,000kmに増える世界ではありませんので、1台あたりの年間走行距離は減ります。

S750が納車されてから1ヶ月弱ほど701SMを放置したのが災いしたのか、バッテリーが弱って交換したりエンジンヘッドカバー付近からオイル漏れしたりと色々ありまして、1台にに肩入れするのではなく満遍なく乗る必要があるということで、動態保存のために乗ることもあります。

特に冬季はバイクに乗るモチベーションが低いので、その中で2台に乗ってあげるのって意外と大変です。

でもそんなデメリットを差し引いてもあまりあるメリットがあるのが2台持ちなんですよねぇ。

結論

2台持ちしてみての感想は「その時の気分で乗るバイクを選択出来るのがいい」となるんですが、これってレンタルバイクでよくね?となりませんか。

レンタルバイクであればお財布事情や気分に応じて頻度や車種を選択できますし、恐らく増車するよりよっぽど費用を抑えることが出来ます。

オプションで車両保険に加入すれば、事故っても(程度にもよるかと思いますが)5万円程度の追い金で済みますし、最新モデルに乗れるもメリットですよね。

外車や販売終了モデルにについてはどうしてもレンタルバイクとして貸し出される事があまりないので、そういった場合は増車という選択肢を取らざるを得ないですが。

一方で、カスタムや洗車して綺麗になった愛車をただただ眺める(←コレ私の大好物)等、所有することでしか得られないことも沢山ありますので、そのあたりのバランスというか、自身のバイクライフと照らし合わせて2台持ちする・しないを判断するのが良いと思います。