mutao.net

いわゆる雑記。

Grafanaのパスワードがわからなくなった。

タイトルの通り、adminユーザのパスワードが分からなくなって困ってしまった。

ちなみに以下の記事で構築したラズパイ上のGrafana。

mutaonet.hatenablog.com

英語の記事だけどここに書いてありました。(日本語訳しました。)

ahelpme.com

# ps axuf|grep grafana
root     1775938  0.0  0.0 215532   796 pts/0    S+   20:01   0:00              \_ grep --color=auto grafana
grafana     1185  0.1  1.3 3124532 52104 ?       Ssl   8月20  95:31 /usr/sbin/grafana-server --config=/etc/grafana/grafana.ini --pidfile=/var/run/grafana/grafana-server.pid --packaging=rpm cfg:default.paths.logs=/var/log/grafana cfg:default.paths.data=/var/lib/grafana cfg:default.paths.plugins=/var/lib/grafana/plugins cfg:default.paths.provisioning=/etc/grafana/provisioning
# vi /etc/grafana/grafana.ini

#################################### Paths ####################################
[paths]
# Path to where grafana can store temp files, sessions, and the sqlite3 db (if that is used)
;data = /var/lib/grafana ⭐

# Temporary files in `data` directory older than given duration will be removed
;temp_data_lifetime = 24h

# Directory where grafana can store logs
;logs = /var/log/grafana

# Directory where grafana will automatically scan and look for plugins
;plugins = /var/lib/grafana/plugins

# folder that contains provisioning config files that grafana will apply on startup and while running.

sqliteを内部で使ってるんですね。

ということでsqliteでadminユーザのパスワードを初期化します。

# sqlite3 /var/lib/grafana/grafana.db
SQLite version 3.26.0 2018-12-01 12:34:55
Enter ".help" for usage hints.
sqlite> update user set password = '59acf18b94d7eb0694c61e60ce44c110c7a683ac6a8f09580d626f90f4a242000746579358d77dd9e570e83fa24faa88a8a6', salt = 'F3FAxVm33R' where login = 'admin';
sqlite>

Email for username: admin

Password: admin

で入力すると、パスワード変更画面が表示されてパスワードの変更&Loginができました!

f:id:mutaonet:20211010200616p:plain

やったことない手順だったのでメモ。

Apacheでロードバランシング

mod_proxy_balancerとは?

Apache2.2系から使えるようになったらL7のロードバランシング機能を持つmodule。

触れる機会があったのでちょっと調べてみる。

実際にはApacheでロードバランシングしているところを、AWSで言うELBに置き換えたいので調べてみたというところ。

httpd.apache.org

ロードするmoduleは以下。

LoadModule status_module modules/mod_status.so
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
LoadModule lbmethod_bybusyness_module modules/mod_lbmethod_bybusyness.so
LoadModule lbmethod_byrequests_module modules/mod_lbmethod_byrequests.so
LoadModule lbmethod_bytraffic_module modules/mod_lbmethod_bytraffic.so
LoadModule lbmethod_heartbeat_module modules/mod_lbmethod_heartbeat.so
LoadModule proxy_http_module modules/mod_proxy_http.so

ロードバランシングの設定は以下。

<Proxy balancer://mycluster>
BalancerMember http://127.0.0.1:81 retry=10 loadfactor=10
BalancerMember http://127.0.0.1:82 retry=10 loadfactor=50
</Proxy>
ProxyPass /test balancer://mycluster

このように設定すると http://127.0.0.1:8080/test でLB機にアクセスした場合にBalancerMemberで指定した2つのバックエンドサーバへとアクセスを振り分けられる。

BalancerMemberのパラメータについて

パラメータ 説明
retry コネクションを保持するためのリトライのタイムアウト値を秒単位で指定する。デフォルトで60秒。
loadfactor 1~100までの値で負荷係数を重み付けできる。デフォルトで1。

詳細は以下

httpd.apache.org

ロードバランサの管理画面

以下のように設定すると管理画面を表示することができる。

バランサマネージャと呼ぶらしい。この管理画面ではメンバを変更したり、特定のメンバをオフラインにするといった動的な管理ができる。

なので、Deny from all を指定して接続できる端末を制御する必要がある。ドメイン指定でも可能。

<Location /balancer-manager>
SetHandler balancer-manager

Order Deny,Allow
Deny from all
Allow from 127.0.0.1
</Location>

TODO

dockerで試したけど、キャプチャを取り忘れたのであとで貼ります。。。

LB用Apacheコンテナ * 1

バックエンドサーバ用Apacheコンテナ * 2

な最小構成を試してみました。

Apendix

github.com

load average

load average

「LAが急上昇しました。」とかそういうことを聞いたりする。

load averageについてこの機会におさらいかねてまとめておくことにした。

実行するタスクが増えてくるとタスクの実行待ちが発生する。

この待ち状態がプログラムの遅延状態としてload averageに表示される。

$ top
top - 18:59:58 up 27 days, 20:23,  1 user,  load average: 0.15, 0.30, 0.24 ⭐
Tasks: 134 total,   1 running, 133 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.9 us,  0.6 sy,  0.0 ni, 98.4 id,  0.1 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :   3797.7 total,    938.1 free,   1031.2 used,   1828.5 buff/cache
MiB Swap:    488.0 total,    488.0 free,      0.0 used.   2508.8 avail Mem

## 実行した時間が違うのでload averageが異なる。
$ uptime
 19:10:43 up 27 days, 20:33,  1 user,  load average: 0.07, 0.14, 0.17 ⭐

load average: 0.15, 0.30, 0.24

左から順に1分、5分、15分の単位でどの程度タスクの待ち時間が発生したかを表している。

load averageが高いということは、遅延が発生しているということになるので、負荷が高いということになる。

しかし、CPU負荷なのかI/O負荷なのかはこれだけでは判断できない。

Load averageの算出処理はカーネルのコードのこの辺りから追える。

github.com

sar

Load averageからCPU負荷なのかI/O負荷なのかを見極めていく。

$ sar
Linux 5.4.65-v8.2.el8 (localhost.localdomain)   2021年09月17日   _aarch64_   (4 CPU)

00時00分00秒     CPU     %user     %nice   %system   %iowait    %steal     %idle
00時10分00秒     all      2.14      0.00      1.09      0.17      0.00     96.60
00時20分00秒     all      1.55      0.00      0.76      0.14      0.00     97.55
00時30分00秒     all      1.61      0.00      0.81      0.14      0.00     97.45
00時40分00秒     all      1.61      0.00      0.78      0.40      0.00     97.21
00時50分00秒     all      1.62      0.00      0.79      0.18      0.00     97.41
01時00分00秒     all      1.54      0.04      0.76      0.15      0.00     97.51
01時10分00秒     all      1.61      0.00      0.80      0.34      0.00     97.24
01時20分00秒     all      1.62      0.00      0.81      0.13      0.00     97.44
01時30分00秒     all      1.60      0.00      0.80      0.34      0.00     97.26
01時40分00秒     all      1.59      0.00      0.78      0.16      0.00     97.47
01時50分01秒     all      1.57      0.00      0.77      0.20      0.00     97.46
02時00分01秒     all      1.62      0.22      0.84      0.17      0.00     97.15
02時10分00秒     all      1.67      0.00      0.83      0.32      0.00     97.18

CPU負荷

以下の項目に注目する。

  • %user: ユーザモード

ユーザプログラム(アプリケーション等)で実行したCPU使用率

  • %system: システムモード

カーネル(システム)で実行したCPU使用率

I/O負荷

  • %iowait:

ディスクI/O待ち。スワップアウト時などに値が上昇する。

プロセスの状態

load averageが分かり、CPU使用率・I/O待ち率が判明したら各プロセスからボトルネックを見つけていく。

mutaonet.hatenablog.com

以前の記事で書いてある通り、プロセスの状態は以下の通り。

$ ps aux | head -1 && ps aux | grep httpd
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root        6849  0.0  0.1  44256  6536 ?        Ss    5月30   1:40 /usr/sbin/httpd -DFOREGROUND
www       225430  0.0  0.1  56460  4592 ?        S     6月13   0:00 /usr/sbin/httpd -DFOREGROUND
www       225431  0.0  0.1 2293576 6108 ?        Sl    6月13   1:59 /usr/sbin/httpd -DFOREGROUND
www       225432  0.0  0.1 2490256 6340 ?        Sl    6月13   2:03 /usr/sbin/httpd -DFOREGROUND
www       225433  0.0  0.1 2293576 6140 ?        Sl    6月13   1:59 /usr/sbin/httpd -DFOREGROUND
STAT 状態 説明
R (Run) TASK_RUNNING 実行可能状態。CPUが空きさえすればいつでも実行可能
S (Sleep) TASK_INTERRUPTED 割り込み可能。入力待ち、スリープ等
D (Disk Sleep) TASK_UNINTERRUPTIBLE 割り込み不可能。主に短時間で復帰する場合の状態。ディスク入出力待ち
Z(Zombie) TASK_ZOMBIE ゾンビ状態。子プロセスがexitとして親プロセスにリープされるまでの状態

SREに求められる知識?

SREとして働く上でどんなスキルセットが必要なのか、そして自分はどこまで知識を持っているかというのを洗い出したいので書き出してみる。

qiitaで「各社の募集要項からSREに求められるスキルをまとめた」という素晴らしいPOSTがあったので参考にしてみることにする。

qiita.com

大規模システムの構築・運用

DAU 10万以上のサービス(もしくはそれと同様)のインフラ運用経験(FiNC/歓迎スキル)

20,000 req/sec オーバーのAPIトラフィックを安定して処理するためのバックエンドシステムの開発、運用(mercari/業務内容)

具体的な数値が出ているのはこの辺。

mercariのTechBlogで以下のようなPOSTがあった。

トラフィックに耐えうるシステムの構築・運用の知識とはここまでできるエンジニアと思って差し支えなさそう。

engineering.mercari.com

ちなみにOpenRestyについての知識は私はないので宿題にする。

経験値

  • 20,000 req/secを超えるシステムの構築・運用・管理経験はある。
  • 負荷試験
    • 試験シナリオは直近で考えて最大でどこまで耐えられるか等、検証した経験あり
  • AWS使っている案件だとELBが高スループット保証しているので問題になることはなかったと記憶している。
    • ただスパイクアクセスの場合はPre-Warmingを申請が必要とかそういう経験はあったちなみにスパイクする時間はだいたい判明していた。
    • AutoScalingが間に合わなくてインスタンス事前に増やしておいたりとかもあった。

クラウド

パブリッククラウド(AWS/GCP...)の経験が求められている。

AWSクラウド環境の技術進化に興味を持ち続け、最新のサービスを当社のビジネつ実現に適切な形で、適応する提案や研究意識(BASE/必須スキル)

クラウド上でのインフラ構築経験、および、3年以上の運用経験(FiNC/必須スキル)

ここらへんが自身の経験に当てはめて考えやすい。

経験

  • AWSの運用経験は2年ほど
  • プライベートクラウドの運用経験は2年以上(現在進行系)。
  • AWSのカンファレンスとかその他勉強会は参加しているけど、研究まではしていない。
    • 研究を何と定義するかによるが、調査・仮設・実験・考察・アウトプットでそれなりに有名であること。とするとそのような経験も知名度もない。

開発スキル(プログラミングスキル)

システムのパフォーマンスや信頼性を向上させるのに必要なアプリケーション、ミドルウェアへの機能追加、バグ修正を行うためのプログラミング能力(mercari/必須スキル)

OSSの公開、コントリビュートの経験(mercari/歓迎スキル)

経験

  • アプリケーションエンジニア(インフラレイヤーもかじってる)ので満たしてはいそう。
    • 実際の経験を話せることが重要なので、事前に振り返って経験整理すれば問題なさそう。
  • OSSの公開、コントリビュートの経験なし
    • やりたいです。エンジニアのスキルを見極める分水嶺的なものと認識しているので、年内挑戦予定(3ヶ月程度しかない...)。

パフォーマンスチューニング

アプリチームと共同し、サービスのパフォーマンス改善の可視化、分析、提案(BASE/業務内容)

高速なレスポンスを実現するためのアプリケーション、ミドルウェアのパフォーマンス改善(mercari/業務内容)

経験

  • 前述した通り経験あり。
    • 勉強会に登壇している人達と比べたら見劣りはする。
  • 直近ではここらへんを業務担当範囲にしている気がする。

ネットワーク

TCP/IP、HTTPなどのネットワークプロトコルについての基礎知識(mercari/必須スキル) ネットワークに関する基礎知識(エニグモ/必須スキル)

ここが一番難しかったです。

経験についてはあとで調べて追記します。

Linux

インフラ(Linux)構築・運用経験 3年以上(エニグモ/必須スキル)

Linux カーネル関連の知識・開発経験(cybozu/歓迎スキル)

最近自分の中で一番「キテ」いる分野。すごい面白いです。

経験

  • インフラ(Linux)構築・運用経験 3年以上あり。
  • Linuc Level1 取得済み(早くlevel3まで取らねば)

冗長化・分散手法

大規模サービス運用ではもはや前提となるためか、明示的に書いているところは少ないかも。

なるほど。オンプレ/クラウドといったことは抜きにしてそもそも論で分かっているかどうかを問われていそう。

冗長化や分散手法に対する基本的な知識(SmartNews/必須スキル)

経験

  • 冗長化や分散手法に対する基本的な知識あり

ログ収集・解析基盤

ログ解析、モニタリング自動化経験(cybozu/歓迎スキル)

ログ(メトリクス)収集・解析基盤の開発・構築・運用(cybozu/業務内容)

データ分析を迅速に行うためのログ収集・分析基盤の構築、運用(mercari/業務内容)

もはや鉄板といった感じ。

経験

  • ログ解析、運用経験あり。
  • 地味にアウトプットもしている。

mutaonet.hatenablog.com

mutaonet.hatenablog.com

監視・モニタリングシステム

インフラ基盤のモニタリング・アラートシステムの開発・運用(cybozu/業務内容)

障害検知やキャパシティプランニングのためのモニタリング環境の構築、運用(mercari/業務内容)

経験

  • 監視システムの構築の経験はなし。
    • 0ベースで監視システム構築から入るってすごい経験。。。
  • 運用経験はあります。アラート組み込んだりも経験あり。
    • アラート検知の設定が悪くてオオカミ少年みたいなアラートを作ってしまった経験も恥ずかしながらある。

セキュリティ

OS セキュリティ関連の知識(cybozu/歓迎スキル)

セキュリティに関する深い知識(mercari/歓迎スキル)

経験

  • 自分の中で一番弱い箇所だと思う。
  • CVEを読んで脆弱性対策をするとかそういった経験はあり。

オペレーション自動化・効率化

CIや自動構成管理、オーケストレーション等の構築、運用経験(BASE/歓迎スキル) Infrastructure as Codeの運用経験、もしくは興味をお持ちの方(エニグモ/歓迎スキル) デプロイや各種オペレーション自動化ツールの開発、運用(mercari/業務内容)

これも好きな分野。効率化とか考えるの好きだし、逆に言うと非効率だったり手間がある作業はどんどん潰したい。

経験

  • Ansibleでの構成管理経験あり
  • Jenkins/Drone.io

RDBMS

3年以上のRDB運用経験(FiNC/必須スキル)

MySQL等のRDBMSの運用経験(mercari/歓迎スキル)

経験

  • ざっくり言うとあり。
  • Cluster構成考えるとかレプリケーションとるとかは経験なし。知識としてかじったぐらい。

コンピュータサイエンス

コンピュータサイエンス修士またはそれに相当するスキル・経験(Retty/必須スキル)

ものすごいハードルが高い。。。大学院を修了してもいないし、そういった経験のある人とコミュニケーションをとった記憶もない気がする。

経験

  • 前述の通り自分のレベルは低い。
  • 体系的に学んだという実績を示すものはない。

感想

今回はqiitaに取り上げられていた募集要項の中から判断しやすいものを抜粋して自分がどのレベルにあるかざっくり探ってみました。

自分はまだまだ未熟であり、インプット・アウトプットの質と量を向上させていく必要があると感じました。業務経験も浅い気がしますね(5年目エンジニア)。

今回を気に知らないOSSも知れたので勉強の種が更に増えてモチベが上がりました。

(お家ラズパイKubernetes化計画を年内目処にやろう)

SREに求められているのは広範に渡る高いスキルだと知れたとともにSREとして働いている皆様に頭が上がりません。

Nmap(Network Mapper)

Nmapとは

nmap.org

ポートスキャンを行えるツール。

私はポートが開放されているかどうかくらいでしか、使用したことがなかったので改めて使い方を調べる。

※ポートスキャンは不正アクセス禁止法には抵触しませんが、「攻撃された」と判断する可能性もあるので自分の保有していないものに関しては実行しないほうが懸命です。

自宅のRassberry pi へとnmapを実行してみました。

ホスト名ではなく、IPアドレスでも実行可能です。

$ nmap 192.168.11.1
Starting Nmap 7.70 ( https://nmap.org ) at 2021-08-20 17:19 JST
Nmap scan report for 192.168.11.1
Host is up (0.0064s latency).
Not shown: 996 closed ports
PORT      STATE SERVICE
53/tcp    open  domain
80/tcp    open  http
443/tcp   open  https
49152/tcp open  unknown
MAC Address: 60:84:BD:F6:39:18 (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 1.75 seconds

このように開放されているポートが確認できました。

STATEについては以下の表通りです。

state description
open ポートが開放されている
closed ポートが閉じている
filtered フィルタ処理されていて確認できない
unfiltered ポートへのアクセス可能、しかし、open closeを確認できない

TCP SYNスキャン

SYNパケットを送信し、ポートにアクセス可能な場合、SYN/ACKパケットを返します。

 $ nmap --packet-trace -sS 192.168.11.1

Nmap Script

nmap.org

nmapには現状で604個のscriptが用意されています。上記のサイトでカテゴリ毎にscriptが用意されています。

これらのscriptはNSE(Nmap Scripting Engine)上で動くLuaで書かれてたscriptです。

sctipt1つ実行することもできますし、カテゴリ指定でscript群を実行することもできます。

今回は様々な脆弱性を検出できるVlunカテゴリを実行してみました。

$ nmap --script vuln 192.168.11.1
Starting Nmap 7.70 ( https://nmap.org ) at 2021-08-20 17:37 JST
Nmap scan report for 192.168.11.1
Host is up (0.0052s latency).
Not shown: 996 closed ports
PORT      STATE SERVICE
53/tcp    open  domain
80/tcp    open  http
|_http-csrf: Couldn't find any CSRF vulnerabilities.
|_http-dombased-xss: Couldn't find any DOM based XSS.
|_http-stored-xss: Couldn't find any stored XSS vulnerabilities.
443/tcp   open  https
|_http-csrf: Couldn't find any CSRF vulnerabilities.
|_http-dombased-xss: Couldn't find any DOM based XSS.
|_http-stored-xss: Couldn't find any stored XSS vulnerabilities.
|_ssl-ccs-injection: No reply from server (TIMEOUT)
|_sslv2-drown:
49152/tcp open  unknown
MAC Address: 60:84:BD:F6:39:18 (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 103.09 seconds

nginxを入れただけのラズパイなので脆弱性は検出されずです。

MySQLを立てて外部からのアクセスが可能にしている場合は mysql-brute 等のscriptを使ってみて検証してもいいかもしれません。

今後、何かに使えそうと思ったのでメモメモ

Golangでopenweathermapを使ってみる

openweathermap.org

天気予報の個人使用無料のAPIを使ってみたかったので作成。

気象庁が公開している非公式のAPIもありますが、1時間毎のデータを取得できる等のメリットがあるopenweathermapを使用。

openweathermap.org

FreePlanでアカウントを作成してマイページからAPP_IDをコピペしてリクエストできます。

APP_IDが発行されたばかりではリクエストできず401が帰ってきます。数時間立てばリクエストできるようになります。

openweathermap.org

試しに東京の天気を取得します。

curl "https://api.openweathermap.org/data/2.5/onecall?lat=35.681236&lon=139.767125&units=metric&lang=ja&appid=#{appId}"
{
    "lat": 35.6812,
    "lon": 139.7671,
    "timezone": "Asia/Tokyo",
    "timezone_offset": 32400,
    "current": {
        "dt": 1629008734,
        "sunrise": 1628971183,
        "sunset": 1629019889,
        "temp": 19.85,
        "feels_like": 20.37,
        "pressure": 1012,
        "humidity": 95,
        "dew_point": 19.03,
        "uvi": 0.37,
        "clouds": 75,
        "visibility": 5000,
        "wind_speed": 2.06,
        "wind_deg": 350,
        "weather": [
            {
                "id": 701,
                "main": "Mist",
                "description": "霧",
                "icon": "50d"
            }
        ]
    },
{省略}

大量のデータを取得できます。

これをGoでParseして構造体にするにはこんな感じ。

github.com

使ってみてわかったこと。

  • 大量のデータを取得できるので色んなことができそう。
  • go get で扱えるようにしたい。
  • とりあえず動くようにしただけなのでもっと作り込みがしたい。

GolangでLinebot②

mutaonet.hatenablog.com

前回の続き。もう少し意味のあるものにしていく。

作るもの

楽天市場APIを使って1日1回、楽天市場に出品されているワインの中でレビュー平均の降順でいくつかLineBotで通知しようというもの。

f:id:mutaonet:20210809155415j:plain

webservice.rakuten.co.jp

まずはRakuten DevelopersでアプリIDを発行してAPIをcallできるようにします。

公式の手順がわかりやすいので割愛します。

リクエストURLは以下のものを使用します。

https://app.rakuten.co.jp/services/api/IchibaItem/Search/20170706?${params}

リクエストイメージ

Parameter Value
applicationId 自分のアプリID
genreId 100317
sort +reviewAverage
Hits 2

https://app.rakuten.co.jp/services/api/IchibaItem/Search/20170706?applicationId=${applicationId}&genreId=100317&sort=+reviewCount

applicationIdはHerokuの環境変数に設定してos.Getenv()で取得できるようにしときます。

以下が作成物になります。

github.com

あとは Heroku Schedulerで定期実行させます。

USTでしか指定できないので、9時間差で指定します。

f:id:mutaonet:20210809160023p:plain

作ってみてよかったこと

  • 基本的な文法をおさらいできたこと。
    • すでに結構身についていることが確認できてうれしい。
  • Goのパッケージについて理解できたこと。
  • JsonのParse処理を実装できたこと。
    • 特にネストした配列の構造体を部分が理解できたのが大きかった。

反省点

  • もっと拡張性を持たせて作成すべきだった。
    • Line MessagingAPIを使用するpackageと楽天市場の検索部分は分けて管理したかった。
  • リクエストパラメータは動的に変更できるように工夫すべきだった。
  • callbackを使ったものではなくなってしまったので、自宅のラズパイとかでも問題なかった。
  • 構成図的なものが雑というかチープすぎるので無料で使える便利なツール知りたい。