Vapor Trail

明るく楽しく元気よく

Prometheusのインストール

環境

Node exporterのインストール

$ mkdir /usr/local/src/prometheus
$ cd /usr/local/src/prometheus
$ wget https://github.com/prometheus/node_exporter/releases/download/v0.18.0/node_exporter-0.18.0.linux-amd64.tar.gz
$ tar zxvf node_exporter-0.18.0.linux-amd64.tar.gz
$ sudo cp node_exporter-0.18.0.linux-amd64/node_exporter /sbin/
$ sudo chown root:root /sbin/node_exporter
$ sudo vi /etc/systemd/system/node-exporter.service

[Unit]
Description=Node Exporter for Prometheus
After=network.target

[Service]
Type=simple
User=prometheus
ExecStart=/sbin/node_exporter
PrivateTmp=true

[Install]
WantedBy=multi-user.target
$ sudo systemctl daemon-reload
$ sudo systemctl start node-exporter.service

http://ipアドレス:9100/metricsにアクセスできる
アクセスできない場合は、firewallをチェックする

  • ポート開放
$ firewall-cmd --add-port=9100/tcp --zone=public --permanent
$ firewall-cmd --reload
$ firewall-cmd --list-ports --zone=public

Prometheusのインストール

  • Prometheusユーザの作成
$ sudo groupadd prometheus
$ sudo useradd -d /var/lib/prometheus -g prometheus -s /bin/false -m prometheus
$ cd /usr/local/src/prometheus
$ wget https://github.com/prometheus/prometheus/releases/download/v2.9.2/prometheus-2.9.2.linux-amd64.tar.gz
$ tar xvzf prometheus-2.9.2.linux-amd64.tar.gz
$ sudo cp -a prometheus-2.9.2.linux-amd64 /usr/local/src/prometheus/prometheus
$ cd prometheus
$ sudo cp prometheus promtool /sbin/
$ sudo chown root:root /sbin/prometheus /sbin/promtool
$ sudo mkdir /etc/prometheus
$ sudo mkdir /var/lib/prometheus/data
$ sudo chown -R prometheus:prometheus /var/lib/prometheus/data
$ sudo cp -r prometheus.yml consoles console_libraries /etc/prometheus/
$ sudo chown -R root:prometheus /etc/prometheus
$ sudo vi /etc/systemd/system/prometheus.service

[Unit]
Description=Prometheus Server
Documentation=https://prometheus.io/docs/introduction/overview/
After=network-online.target

[Service]
User=prometheus
ExecStart=/sbin/prometheus --config.file=/etc/prometheus/prometheus.yml --storage.tsdb.path=/var/lib/prometheus/data --web.console.templates=/etc/prometheus/consoles  --web.console.libraries=/etc/prometheus/console_libraries
ExecStop=/bin/kill -TERM ${MAINPID}
ExecReload=/bin/kill -HUP ${MAINPID}

[Install]
WantedBy=multi-user.target
$ sudo vi /etc/prometheus/prometheus.yml

# my global config
global:
  scrape_interval:     15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
  evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
  # scrape_timeout is set to the global default (10s).

# Alertmanager configuration
alerting:
  alertmanagers:
  - static_configs:
    - targets:
      # - alertmanager:9093

# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
  # - "first_rules.yml"
  # - "second_rules.yml"

# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
  # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
  - job_name: 'prometheus'

    # metrics_path defaults to '/metrics'
    # scheme defaults to 'http'.

    static_configs:
    - targets: ['localhost:9090']

  - job_name: 'node'

    file_sd_configs:
    - files:
       - /etc/prometheus/nodes.yml
$ sudo vi /etc/prometheus/nodes.yml

- targets:
   - localhost:9100
  labels:
    role: prometheus
  • ymlファイルのチェック
$ promtool check config /etc/prometheus/prometheus.yml 
$ systemctl daemon-reload
$ systemctl start prometheus.service
$ systemctl status prometheus.service

Grafanaインストール

grafana.com

$ sudo yum install -y https://dl.grafana.com/oss/release/grafana-5.4.2-1.x86_64.rpm
$ sudo systemctl start grafana-server.service 

http://ipアドレス:3000にアクセス 初期ID・Passwordはadmin

prometheusとgrafanaを入れたみたが、どうグラフとか出すといいのか? - Qiita

grafana.com

  • ポートを開放した場合、誰でもアクセスできるので認証をかけるか、閉じる
$ firewall-cmd --remove-port=9090/tcp --zone=public --permanent
$ firewall-cmd --remove-port=9100/tcp --zone=public --permanent
$ firewall-cmd --reload

prometheus.io

『Head First オブジェクト指向設計』第5章 前半

第5章 良い設計=柔軟なソフトウェア

この章で学ぶこと

ソフトウェアの変更が困難になっていれば顧客からの変更要求に対応することが難しくなる。既存のソフトウェアの設計を改善することを通して、柔軟な設計を学ぶ。

ギターだけでなくマンドリンも扱えるようにする

  • 変更前のクラス図

diagram-782802414211719472

  • 変更後のクラス図

diagram-218270032049871976

  1. 抽象クラスは、振る舞いを定義し、サブクラスがそのふるまいを実装する。
  2. 同じ振る舞いが2箇所以上の場所に存在するのであれば、その振る舞いを1つのクラス内に抽出し、再利用する。
    Instrumentクラス・InstrumentSpecクラス

クラス図の詳細

  • クラス名の斜線は抽象クラスを表す
  • 白い三角形は汎化を表す ClassA ◁-- ClassB
    Guitarなどのクラスが、Instrumentなどの汎用的なクラスから振る舞いを拡張および継承することを示す
  • 白い菱形は集約(aggregation)を表す ClassA ◇-- ClassB
    集約は、あるものが(部分的に)別のものから構成されることを意味する。
    Instrument は部分的に InstrumentSpec から構成される。

     論理的に「全体と部分」の意味を持つものです。例えば、会社クラスと社員クラスの関係として会社は社員によって構成されるという概念から集約として表すことができます。ただ、このようにして使う集約は非常に曖昧(あいまい)で、集約にすべきか、関連にすべきか、悩むこともあります。なぜなら、実世界の会社と社員という概念はそれぞれ自立して存在しているという側面もあるからです。ここでは、これを「論理的な全体-部分構造」とします。
    【改訂版】初歩のUML:第4回 少しだけ高度なモデリング技術(その1)関連クラスと集約、コンポジション

  • 黒い菱形はコンポジションを表す ClassA ◆-- ClassB

    コンポジションは、集約の一種です。2つのクラスの依存関係は、両オブジェクトのライフサイクル(生成と消滅)がほぼ一致する場合に使います。コンポジションについても、集約かコンポジションのどちらを使うかは曖昧(あいまい)です。「両オブジェクトのライフサイクルが同じ」「物理的に1つのものを分けた」ということを強調したいときに使ってください。
    【改訂版】初歩のUML:第4回 少しだけ高度なモデリング技術(その1)関連クラスと集約、コンポジション

現在の設計の問題点

  • 新しい楽器を追加することが難しい。
  • Inventoryクラス
    Instrumentのサブクラスが追加されるたびにコードを変更しなければいけない
  • Instrumentクラス
    楽器を追加するたびに新しいサブクラスがどんどん増えていく
  • InstrumentSpecクラス
    異なるプロパティを持つ楽器を追加する際にコードを変更しなければいけない
    コードが重複しやすい

すべてが密に結合し、InstrumentSpecはInstrumentの一部(集約)の関係にある。

オブジェクト指向の3つの原則

1. インターフェース

diagram-8264521749727867540

実装ではなく、インターフェースに対してコードを作成するようにすると、ソフトウェアの拡張が容易になる。
インターフェースに対してコードを作成すれば、インターフェースを実装したあらゆるサブクラスでそのコードを扱えるようになる。
固有の実装はサブクラスに記述する

2. カプセル化

カプセル化はクラスを不要な変更から守るのに役立つ。
変更が生じやすそうな振る舞いがあれば、振る舞いを必ず分離(= 変動しやすい部分をカプセル化)する。

diagram-3394751198258345913

paint()は色々な描き方があるので、変更が生じやすい。

diagram-3138915151318724466

Painterクラスから変動するものをカプセル化し分離する。

3. クラスごとに変更の理由を1つだけにすること

良い設計のアプリケーションは変更が容易だが、そうではないアプリケーションはあっさり崩壊する。
クラスが変更される原因を減らし変更を最小限に留めること。

diagram-9095652297658069928

変更される理由が複数存在するクラスは、1つのクラスで多くのことを行っている可能性が高い。

diagram-6927912838860376318

機能を複数のクラスに分割し、各クラスが一つのことだけを行うようにする。

『Head First オブジェクト指向設計』第4章

第4章 分析

テキスト分析によって、今まで作成してきたユースケースを顧客が必要とする内容を表現するクラスやメソッドに変換する方法を学ぶ。
ソフトウェアは理想の世界ではなく、現実世界で動作する必要がある。
システムを不確実性が高く混沌とした現実世界の状況で動作させるのに役立つのが分析である。

良い分析の第1歩は潜在的な問題を把握すること

問題点

今回の例では、所有者の犬ではない犬が吠えた場合でもドアが開いてしまう。
そのため、所有者の犬の鳴き声と所有者の犬ではない鳴き声を識別できるようにする。

ユースケースの更新

  1. ユースケースは、作成者、上司、顧客に対して意味があるように作成する。
  2. 分析とユースケースは顧客、マネージャ、その他の開発者に対して、現実世界の状況におけるシステムの動作方法を明確にする。

ユースケース内の名詞(人・もの・場所)に着目する。
ユースケース内の名詞は通常、クラスとして作成する必要があり、システム内で注意を払う必要がある。

ユースケース内の名詞(と動詞)に着目して、クラスとメソッドを識別することをテキスト分析と呼ぶ。

インパス 代替パス
1. 所有者のに出たいと吠える
2. 鳴き声認識装置鳴き声を検知する 2.1 所有者鳴き声を聞く
3. 鳴き声認識装置ドアを開くための要求を送信する 3.1 所有者リモコンボタンを押す
4. 犬用ドアが開く
5. 所有者のに出る
6. 所有者のが用を済ます
  6.1 ドアが自動的に閉まる
  6.2 所有者のに入りたいと吠える
  6.3 鳴き声認識装置が再び鳴き声を検知する
  6.4 鳴き声認識装置ドアを開くための要求を送信する
  6.5 犬用ドアが再び開く


6.3.1 所有者がふたたび所有者の鳴き声を聞く
6.4.1 所有者リモコンボタンを押す
7. 所有者のが家のに戻る
8. ドアが自動的に閉まる
鳴き声認識装置 犬用ドア 所有者 要求 リモコン ボタン 中/外 鳴き声
BarkRecognizer DogDoor DogDoor.Open() Remote Bark
  • 「所有者の犬」は名詞だが犬はアクターでありシステムの外部に位置するのでそのためのクラスは必要ない。
  • 要求もクラスにはなってないが、鳴き声認識装置が犬用ドアのopen()メソッドを呼び出すことを表してる。

新しいユースケースの追加

元のユースケースのユーザ目標は、犬を出入りさせること。
新しく追加したユースケースのユーザ目標は、犬の鳴き声を記録すること。

ユースケース
1. 所有者の犬が犬用ドアに向かって吠える
2. 犬用ドアが所有者の犬の鳴き声を記録する

テキスト分析=何に着目するべきかを明らかにする

テキスト分析は、何に着目するかを明らかにするのであって、どのクラスを作成すべきかだけを扱っているのではない。

今までは「所有者の犬の鳴き声」に着目していたが、「所有者の犬」に着目すべきだったことが明らかになる。

  • 再確認 ユースケース内の名詞に着目する ユースケース内の動詞は、システム内のオブジェクトのメソッドになりやすい。
  • DogDoorクラスのopen(),close()・RemoteクラスのpressButton()がこれに当たる。

  • ではなぜDogクラスが存在しないのか

  • 犬はシステムの外部にある、アクターだから。システムの外部にある事柄を通常クラスで表現する必要がない。
  • Dogはソフトウェアオブジェクトではない。生物に関する長期的な情報をシステムが記録するのでなければ、通常は生物をクラスで表現しない。 UserやManagerというクラスはよく存在するが、それらはシステムにおける役割を表現しているか、クレジットカードや住所などの情報を格納しているかのいずれか。
  • Dogクラスがあっても、システムの他の部分には役立ちそうにない。