2021年1月18日月曜日

Ubuntu 16.04LTS から 18.04LTS に do-release-upgrade

概要

Ubuntu を do-release-upgrade で 16.04 から 18.04 にアップグレードしてみました
特に詰まるところはなかったのですが備忘録として残しておきます　

環境

  • macOS 11.1
  • Virtualbox 6.1.16
  • vagrant 2.2.14

アップグレードコマンド

  • sudo apt update
  • sudo apt upgrade
  • sudo do-release-upgrade

いろいろ聞かれるが基本は Yes で OK です
最後に再起動を促されるので再起動後ログインしてバージョンを確認すれば OK です

  • cat /etc/issue

=> Ubuntu 18.04.5

時刻: 0 件のコメント:
ラベル:

2021年1月17日日曜日

Omnibus Gitlab でロールごとにインスタンスを作成して連携する方法

概要

前回 Gitlab の各種ロールについて調べました
今回はロールごとにインスタンスを作成して連携する方法を紹介します

環境

  • Ubuntu 18.04
  • Gitlab-ee 13.7.3

postgres_role と redis_master_role インスタンスの作成

まず PostgreSQL と Redis を管理するインスタンスを作成します

Gitlab の構築

こちらを参考にまずは Gitlab を各インスタンスにインストールしてください
なお postgres_role を作成する場合は EXTERNAL_URL を設定しないで作成してください

PostgreSQL に接続する gitlab ユーザのパスワード設定

  • gitlab-ctl pg-password-md5 gitlab

生成されたパスワードは後で使うのでメモしておきます

設定ファイル変更

PostgreSQL と Redis を起動するための設定をします
外部から接続する想定なので listen_address や認証情報を設定します
sql_user_password には先程作成したパスワードのハッシュ文字列を入力してください
また PostgreSQL12 から repmgr が使えないので false にしておきます

  • vim /etc/gitlab/gitlab.rb
roles ['postgres_role', 'redis_master_role']

repmgr['enable'] = false

postgresql['listen_address'] = '0.0.0.0'
postgresql['port'] = 5432
postgresql['sql_user'] = "gitlab"
postgresql['sql_user_password'] = "335158fc1aa26a831656b369e233217d"
postgresql['trust_auth_cidr_addresses'] = %w(0.0.0.0/0)

redis['port'] = 6379
redis['bind'] = '0.0.0.0'


* gitlab-ctl reconfigure
* gitlab-ctl status

5432 と 6379 が 0.0.0.0 で LISTEN していることを確認しましょう
以下のようにプロセスが起動していることを確認します


run: consul: (pid 24806) 116s; run: log: (pid 24842) 113s
run: logrotate: (pid 24707) 140s; run: log: (pid 24715) 139s
run: node-exporter: (pid 24822) 114s; run: log: (pid 24746) 133s
run: postgres-exporter: (pid 24835) 113s; run: log: (pid 24787) 119s
run: postgresql: (pid 23639) 454s; run: log: (pid 23638) 454s
run: redis: (pid 20593) 1216s; run: log: (pid 20604) 1213s
run: redis-exporter: (pid 24828) 113s; run: log: (pid 24764) 127s

application_role インスタンスの作成

次に Rails アプリが動作するインスタンスを作成します

Gitlab の構築

こちらを参考にまずは Gitlab を各インスタンスにインストールしてください

application_role を設定する

事前に作成した PostgreSQL と Redis に接続します
また起動するロールは application_role にします
IP の部分は先程作成した postgres_role と redis_master_role のインスタンスの IP を指定しましょう

application_role のみだと nginx が起動しないので nginx は別途有効にします

  • vim /etc/gitlab/gitlab.rb
roles ['application_role']

nginx['enable'] = true

gitlab_rails['db_username'] = "gitlab"
gitlab_rails['db_password'] = "335158fc1aa26a831656b369e233217d"
gitlab_rails['db_host'] = "192.168.100.11"
gitlab_rails['redis_host'] = "192.168.100.11"


再起動してプロセスの確認をしましょう
8080 が 0.0.0.0 で LISTEN していることも確認します


* gitlab-ctl reconfigure
* gitlab-ctl status 

run: gitaly: (pid 103720) 29s; run: log: (pid 103719) 29s
run: gitlab-exporter: (pid 103881) 13s; run: log: (pid 103880) 13s
run: gitlab-workhorse: (pid 103857) 19s; run: log: (pid 103856) 19s
run: logrotate: (pid 98390) 2737s; run: log: (pid 22584) 67534s
run: node-exporter: (pid 23113) 67415s; run: log: (pid 22616) 67528s
run: puma: (pid 103888) 11s; run: log: (pid 103839) 23s
run: sidekiq: (pid 103898) 6s; run: log: (pid 103846) 21s

動作確認

application_role にアクセスして正常に Gitlab が動作するか確認しましょう
nginx を有効にしているので application_role インスタンスの IP にアクセスすれば Gitlab が動作しているのが確認できると思います

最後に

application_role と postgres_role, redis_master_role にインスタンスを分けて Gitlab を起動する方法を紹介しました
ロールごとにインスタンスを分けることで冗長化できる他管理も楽になるかなと思います

今回の構成であれば application_role を増やして LB を追加すればアプリケーションレイヤーのスケールは簡単にできるようになると思います

参考サイト

時刻: 0 件のコメント:
ラベル:

2021年1月16日土曜日

Omnibus Gitlab の各種 role がどのプロセスを管理しているのか調べてみた

概要

Omunibus インストールした Gitlab では Gitlab にロールを設定することができます
ロールは簡単に言うと「アプリだけ」「データベースだけ」「キャッシュだけ」という感じでロール単体で動作させることができロールごとにインスタンスを準備することで HighAvailability を実現することができます

今回は導入という意味でまずロールの種類とロールに紐付いて動作するプロセスについて調べてみました

環境

  • Ubuntu 18.04
  • Gitlab-ee 13.7.3

準備: Gitlab の通常インストールと reconfigure

Omunibus インストールした Gitlab を各ロールのみにするにはまず普通に Gitlab をインストールし reconfigure する必要があります

まずは過去の記事を参考に Gitlab をインストールします


* apt -y update
* apt install -y curl openssh-server ca-certificates
* curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash
* EXTERNAL_URL="http://192.168.100.10" apt -y install gitlab-ee

ここから各種ロールを試していきたいと思います
Gitlab をロール化するには /etc/gitlab/gitlab.rb の role セクションを変更していきます
変更後に reconfigure をかけて動作しているプロセスを調べてみました

redis_sentinel_role にする

  • vim /etc/gitlab/gitlab.rb
roles ['redis_sentinel_role']
redis['master_ip'] = '192.168.100.10'
redis['master_password'] = 'pass'
  • gitlab-ctl reconfigure
run: logrotate: (pid 88362) 3368s; run: log: (pid 22584) 57365s
run: node-exporter: (pid 23113) 57246s; run: log: (pid 22616) 57359s
run: sentinel: (pid 92832) 5s; run: log: (pid 91962) 393s


生成される sentinel のログと設定ファイルのパスは以下の通りです

  • ls /var/opt/gitlab/sentinel/sentinel.conf
  • ls /var/log/gitlab/sentinel/current

redis_master_role にする

  • vim /etc/gitlab/gitlab.rb
roles ['redis_master_role']
  • gitlab-ctl reconfigure
run: logrotate: (pid 92869) 48s; run: log: (pid 22584) 57645s
run: node-exporter: (pid 23113) 57526s; run: log: (pid 22616) 57639s
run: redis: (pid 93107) 30s; run: log: (pid 93106) 30s
run: redis-exporter: (pid 93123) 24s; run: log: (pid 93122) 24s


生成される sentinel のログと設定ファイルのパスは以下の通りです

  • ls /var/opt/gitlab/redis/redis.conf
  • ls /var/log/gitlab/redis/current

redis_replica_role にする

  • vim /etc/gitlab/gitlab.rb
roles ['redis_replica_role']
redis['master_ip'] = '192.168.100.10'
redis['master_password'] = 'pass'
  • gitlab-ctl reconfigure
run: logrotate: (pid 93574) 2104s; run: log: (pid 22584) 63301s
run: node-exporter: (pid 23113) 63182s; run: log: (pid 22616) 63295s
run: redis: (pid 93554) 3518s; run: log: (pid 93106) 5686s
run: redis-exporter: (pid 93123) 5680s; run: log: (pid 93122) 5680s


生成される sentinel のログと設定ファイルのパスは以下の通りです

  • ls /var/opt/gitlab/redis/redis.conf
  • ls /var/log/gitlab/redis/current

geo_primary_role にする

  • vim /etc/gitlab/gitlab.rb
roles ['geo_primary_role']
  • gitlab-ctl reconfigure
run: alertmanager: (pid 94196) 45s; run: log: (pid 94195) 45s
run: gitaly: (pid 93896) 77s; run: log: (pid 93895) 77s
run: gitlab-exporter: (pid 94162) 53s; run: log: (pid 94161) 53s
run: gitlab-workhorse: (pid 94124) 61s; run: log: (pid 94123) 61s
run: grafana: (pid 94219) 42s; run: log: (pid 94218) 42s
run: logrotate: (pid 93574) 2487s; run: log: (pid 22584) 63684s
run: nginx: (pid 94149) 55s; run: log: (pid 94148) 55s
run: node-exporter: (pid 23113) 63565s; run: log: (pid 22616) 63678s
run: postgres-exporter: (pid 94208) 44s; run: log: (pid 94207) 44s
run: postgresql: (pid 94013) 71s; run: log: (pid 94012) 71s
run: prometheus: (pid 94174) 51s; run: log: (pid 94173) 51s
run: puma: (pid 94105) 65s; run: log: (pid 94104) 65s
run: redis: (pid 93885) 80s; run: log: (pid 93106) 6069s
run: redis-exporter: (pid 93123) 6063s; run: log: (pid 93122) 6063s
run: sidekiq: (pid 94112) 63s; run: log: (pid 94111) 63s


デフォルトではすべてのプロセスが動作するようです

geo_secondary_role にする

  • vim /etc/gitlab/gitlab.rb
roles ['geo_secondary_role']
  • gitlab-ctl reconfigure
run: alertmanager: (pid 94196) 462s; run: log: (pid 94195) 462s
run: geo-logcursor: (pid 95654) 118s; run: log: (pid 95541) 142s
run: geo-postgresql: (pid 95424) 151s; run: log: (pid 95435) 150s
run: gitaly: (pid 93896) 494s; run: log: (pid 93895) 494s
run: gitlab-exporter: (pid 94162) 470s; run: log: (pid 94161) 470s
run: gitlab-workhorse: (pid 94124) 478s; run: log: (pid 94123) 478s
run: grafana: (pid 94219) 459s; run: log: (pid 94218) 459s
run: logrotate: (pid 93574) 2904s; run: log: (pid 22584) 64101s
run: nginx: (pid 94149) 472s; run: log: (pid 94148) 472s
run: node-exporter: (pid 23113) 63982s; run: log: (pid 22616) 64095s
run: postgres-exporter: (pid 94208) 461s; run: log: (pid 94207) 461s
run: postgresql: (pid 94013) 488s; run: log: (pid 94012) 488s
run: prometheus: (pid 94174) 468s; run: log: (pid 94173) 468s
run: puma: (pid 95694) 112s; run: log: (pid 94104) 482s
run: redis: (pid 93885) 497s; run: log: (pid 93106) 6486s
run: redis-exporter: (pid 93123) 6480s; run: log: (pid 93122) 6480s
run: sidekiq: (pid 95679) 114s; run: log: (pid 94111) 480s


geo_primary_role と比べて geo-logcursor と geo-postgresql が動作しているようです

postgres_role にする

  • vim /etc/gitlab/gitlab.rb
roles ['postgres_role']
  • gitlab-ctl reconfigure
run: consul: (pid 97826) 2682s; run: log: (pid 97840) 2681s
run: logrotate: (pid 98390) 2405s; run: log: (pid 22584) 67202s
run: node-exporter: (pid 23113) 67083s; run: log: (pid 22616) 67196s
run: postgres-exporter: (pid 94208) 3562s; run: log: (pid 94207) 3562s
run: postgresql: (pid 102922) 21s; run: log: (pid 102921) 21s
down: repmgrd: 0s, normally up, want up; run: log: (pid 103040) 15s


Gitlab 13 からは PostgreSQL 13 が使われており repmgrd が廃止になり Patroni を使うようになっているので有効にする必要があります

consul_role にする

  • vim /etc/gitlab/gitlab.rb
roles ['consul_role']
  • gitlab-ctl reconfigure
run: consul: (pid 97826) 2884s; run: log: (pid 97840) 2883s
run: logrotate: (pid 98390) 2607s; run: log: (pid 22584) 67404s
run: node-exporter: (pid 23113) 67285s; run: log: (pid 22616) 67398s

application_role にする

  • vim /etc/gitlab/gitlab.rb
roles ['application_role']
  • gitlab-ctl reconfigure
run: gitaly: (pid 103720) 29s; run: log: (pid 103719) 29s
run: gitlab-exporter: (pid 103881) 13s; run: log: (pid 103880) 13s
run: gitlab-workhorse: (pid 103857) 19s; run: log: (pid 103856) 19s
run: logrotate: (pid 98390) 2737s; run: log: (pid 22584) 67534s
run: node-exporter: (pid 23113) 67415s; run: log: (pid 22616) 67528s
run: puma: (pid 103888) 11s; run: log: (pid 103839) 23s
run: sidekiq: (pid 103898) 6s; run: log: (pid 103846) 21s

monitoring_role にする

  • vim /etc/gitlab/gitlab.rb
roles ['monitoring_role']
  • gitlab-ctl reconfigure
run: alertmanager: (pid 104334) 12s; run: log: (pid 104333) 12s
run: grafana: (pid 104346) 11s; run: log: (pid 104345) 11s
run: logrotate: (pid 98390) 2923s; run: log: (pid 22584) 67720s
run: node-exporter: (pid 23113) 67601s; run: log: (pid 22616) 67714s
run: prometheus: (pid 104322) 18s; run: log: (pid 104321) 18s

Tips: 存在しないロールを指定した場合

The following invalid roles have been set in 'roles': monitoring_role_dummy というエラーになります

Tips: ロールをしていしない場合のプロセス

un: alertmanager: (pid 104334) 339s; run: log: (pid 104333) 339s
run: gitaly: (pid 104690) 54s; run: log: (pid 104689) 54s
run: gitlab-exporter: (pid 104954) 30s; run: log: (pid 104953) 30s
run: gitlab-workhorse: (pid 104917) 38s; run: log: (pid 104916) 38s
run: grafana: (pid 104346) 338s; run: log: (pid 104345) 338s
run: logrotate: (pid 98390) 3250s; run: log: (pid 22584) 68047s
run: nginx: (pid 104941) 32s; run: log: (pid 104940) 32s
run: node-exporter: (pid 23113) 67928s; run: log: (pid 22616) 68041s
run: postgres-exporter: (pid 104984) 22s; run: log: (pid 104983) 22s
run: postgresql: (pid 104806) 48s; run: log: (pid 104805) 48s
run: prometheus: (pid 104322) 345s; run: log: (pid 104321) 345s
run: puma: (pid 104898) 42s; run: log: (pid 104897) 42s
run: redis: (pid 104679) 56s; run: log: (pid 104678) 56s
run: redis-exporter: (pid 104965) 28s; run: log: (pid 104964) 28s
run: sidekiq: (pid 104905) 40s; run: log: (pid 104904) 40s

まとめ

  • node-exporter, logrotate は必ず動作する模様
  • redis_master_role と redis_replica_role では動作するプロセスは同じ
  • postgres_role は PostgreSQL 12 から Patroni を使って冗長化するようになっている
  • 一番設定が面倒なロールは postgres_role かもしれない

参考サイト

時刻: 0 件のコメント:
ラベル:

2021年1月15日金曜日

自分のツイートを分析してみた2

概要

前回の続きで 20,000 ツイートに達したのでデータ分析してみました

環境

  • Ruby 3.0.0p0

全ツイート数

  • 21858

全ツイートをどれくらいの期間で行ったか

  • 2016/03/24 - 2021/01/12

1755 日分のツイートになります

月単位でどれくらいツイートを行ったか

月間最高ツイートは 2019/06 で 846 ツイートでした

日単位でどれくらいツイートを行ったか

日で最高ツイートは 2018/06/06 で 156 ツイートでした

月単位でどれくらいリツイートをされたか

最高でも月で 5 リツイートが一番多かったです

月単位でどれくらいファボをされたか

月間最高ファボは 2020/04 で 43 ファボでした

ツイートしているデバイスの割合

ほぼブラウザからツイートでした

よくツイートされている単語 Top100

  • t -> 1418
  • co -> 1394
  • https -> 1263
  • 感じ -> 865
  • ー -> 803
  • アプリ -> 793
  • 人 -> 616
  • 方法 -> 580
  • 自分 -> 563
  • ファイル -> 383
  • インストール -> 327
  • docker -> 322
  • あと -> 301
  • gt -> 292
  • 情報 -> 287
  • コンテナ -> 282
  • ゲーム -> 280
  • API -> 255
  • サーバ -> 249
  • アカウント -> 244
  • データ -> 243
  • コード -> 242
  • コマンド -> 224
  • 久しぶり -> 224
  • 記事 -> 223
  • 自動 -> 211
  • ruby -> 206
  • 気 -> 195
  • mac -> 187
  • s -> 181
  • 環境 -> 173
  • 別 -> 172
  • 動画 -> 170
  • 画面 -> 155
  • デフォルト -> 151
  • ポイント -> 150
  • ログイン -> 146
  • ドメイン -> 141
  • 複数 -> 139
  • ビルド -> 138
  • 名前 -> 133
  • ネットワーク -> 133
  • D -> 131
  • ユーザ -> 130
  • 個人 -> 129
  • k -> 128
  • ブログ -> 126
  • ツール -> 125
  • ページ -> 124
  • バージョン -> 123
  • アップデート -> 123
  • ケース -> 122
  • web -> 121
  • p -> 121
  • サイト -> 121
  • d -> 120
  • レベル -> 120
  • ホスト -> 119
  • google -> 116
  • ライブラリ -> 115
  • 他 -> 113
  • iPhone -> 108
  • モード -> 108
  • イベント -> 107
  • どん -> 106
  • 状態 -> 106
  • Mac -> 104
  • カード -> 104
  • 月 -> 104
  • デプロイ -> 103
  • wifi -> 102
  • クライアント -> 102
  • 文字 -> 101
  • UI -> 101
  • 変数 -> 98
  • 回線 -> 97
  • iOS -> 97
  • 次 -> 96
  • バグ -> 95
  • 仕組み -> 95
  • Ruby -> 93
  • 時代 -> 93
  • S -> 93
  • Google -> 93
  • 無料 -> 92
  • 最後 -> 92
  • タグ -> 92
  • or -> 90
  • ドキュメント -> 90
  • swift -> 89
  • コール -> 88
  • マイクラ -> 87
  • ローカル -> 87
  • クラス -> 87
  • 野球 -> 86
  • メソッド -> 86
  • golang -> 86
  • スタンプ -> 85
  • パスワード -> 84
  • 部分 -> 82

["ポイント", "d", "モード", "どん", "カード", "wifi", "回線", "バグ", "仕組み", "Ruby", "S", "最後", "コール", "野球", "パスワード"] が新規で登場していました

逆に ["Arduino", "xcode", "mini", "swagger", "画像", "端末", "プロジェクト", "Swift", "js", "使い方", "python", "ポート", "r", "デバイス", "ボタン"] が前回の Top100 からなくなっていました

最後に

30,000 ツイートしたら再度解析してみたいと思います
ちなみにフォロワー数はずっと横ばいです

参考サイト

時刻: 0 件のコメント:
ラベル: ,

2021年1月14日木曜日

docker で別のコンテナとリンクする場合は同じ network に参加させる必要がある

概要

--link オプションは使えないので同じネットワークに属するようにコンテナを作成しましょう

環境

  • macOS 11.1
  • docker 20.10.2

サンプル

test ネットワークの作成

  • docker network create test

test ネットワークに属する nginx コンテナの作成

  • docker run --network test --name web -d nginx

test ネットワークに属する動作確認用コンテナの作成

  • docker run --rm --network test ruby curl web

nginx の welcome ページが表示されることを確認しましょう

時刻: 0 件のコメント:
ラベル:

2021年1月13日水曜日

Zipkin のデータストレージに ElasticSearch を使う方法

概要

前回は In-Memory ストレージを使ったので再起動するとデータが消えてしました
今回はストレージに ElasticSearch を使ってデータの永続化を行ってみました

環境

  • Zipkin 2.23
  • ElasticSearch7.9.3

ネットワークの作成

  • docker create network test

このネットワークに Zipkin と ElasticSearch コンテナを属させます

ElasticSearch コンテナの起動

今回は zipkin が用意している ElasticSearch イメージを使って ElasticSearch コンテナを起動します


* docker run -d -p 9200:9200 -p 9300:9300 -e "discovery.type=single-node" --network test --name es docker.elastic.co/elasticsearch/elasticsearch:7.9.3
* curl 'localhost:9200/_cat/health'

green が返ってくることを確認しましょう

Zipkin コンテナの起動

STORAGE_TYPE=elasticsearch にして起動します


* docker run -d -p 9411:9411 -e STORAGE_TYPE=elasticsearch -e ES_HOSTS=es:9200 --network test --name zipkin openzipkin/zipkin

動作確認用のアプリは前回の Sinatra アプリを使用しています
これでアプリを使って Zipkin にトレース情報を送信してみると以下のようにちゃんと ElasticSearch 側にインデックスが作成されているのが確認できると思います
また何回かアクセスしてみると docs.count が増えるのも確認できると思います


health status index uuid pri rep docs.count docs.deleted store.size pri.store.size yellow open zipkin-span-2021-01-12 KqvMFHDPSamS4jRX52DQrQ 5 1 1 0 416b 416b


また http://localhost:9411/zipkin/ にアクセスして serviceName=zipkin-test で検索してもちゃんとトレース情報が確認できると思います


最後に

Zipkin + ElasticSearch を試してみました
STORAGE_TYPE を変更するだけで簡単に使うことができます
既存の ElasticSearch があるのであればそれをそのまま流用してもいいと思います

参考サイト

時刻: 0 件のコメント:
ラベル: ,

2021年1月12日火曜日

Sinatra で Zipkin 超入門

概要

zipkin はトレーシングシステムです
複数の Web アプリケーションを使っているようなシステムで 1 つのリクエストがどうのような経路を辿ったかを可視化したりすることができます

今回は Sinatra アプリケーションを使って Zipkin と連携してみました

環境

  • macOS 11.1
  • Ruby 3.0.0
    • zipkin-tracer 0.47.3
    • sinatra 2.1.0
  • Zipkin 2.23

Zipkin の起動

今回は docker を使います
jar でも動かせるようですが一番簡単な docker を使います

  • docker run -d -p 9411:9411 openzipkin/zipkin

http://localhost:9411/zipkin/ にアクセスすると zipkin の UI が起動しているのが確認できると思います

Sinatra アプリケーションの作成

zipkin-ruby という Rack のミドルウェアとして使えるトレーサライブラリがあるのでこれを使います
使い方は簡単で Sinatra アプリ内でミドルウェアを use するだけです

今回は zipkin に直接トレーサ情報を送信するので特に細かい設定はしていませんがエンドポイントが異なっていたり SQS や RabbitMQ に送信する場合は config を変更してください

  • bundle init
  • vim Gemfile
gem "zipkin-tracer"
gem "sinatra"
gem "thin"
  • bundle config path vendor
  • bundle install

アプリケーションを書いていきます
config.ru 内で rack のミドルウェアとして宣言します

  • vim config.ru
require './app'
require 'zipkin-tracer'
require 'rack'

config = {
  service_name: 'zipkin-test',
  json_api_host: 'http://localhost:9411',
  sample_rate: 1.0,
  sampled_as_boolean: false
}
use ZipkinTracer::RackHandler, config

run ZipkinTest


service_name は必須パラメータです
UI で検索する場合に必ず必要になります
json_api_host は先程 docker 上に構築した Zipkin のエンドポイントを指定します
sample_rate はトレースするリクエストの割合を指定します
0 から 1 の間で指定し、1.0 の場合はすべてのリクエストが Zipkin に送信されます
アクセスが多い場合などは割合を小さくすることで HTTP 通信によるオーバヘッドも小さくすることができます
sampled_as_boolean は false に設定しないと警告が出るので設定しておきます

  • vim app.rb
require 'sinatra'

class ZipkinTest < Sinatra::Base
  get '/' do
    'ok'
  end
end


Sinatra アプリ側は特に何もしません

  • bundle exec rackup config.ru

これで起動しましょう
localhost:9292 でアプリが起動しているのが確認できれば OK です

動作確認

  • curl localhost:9292

でアプリにアクセスしてみましょう
そしてその後で Zipkin の UI から serviceName=zipkin-test で検索すると以下のようにリクエストのトレース情報が格納されているのが確認できると思います
何かしらのクエリで検索しないと結果が表示されないので注意しましょう

最後に

Sinatra を使って Zipkin に入門してみました
主要な各言語にはライブラリが用意されているのでアプリケーションには簡単に導入することができるかなと思います

Zipkin 自体も docker で簡単に起動することができます
ただ今回は Zipkin のデータは永続化していないので永続化する場合はこの辺りを参考に格納ストレージを選択してください

あと気になったのは自分で管理できないような外部のリソースのトレースでそういった場合はどうするのか気になりました

参考サイト

時刻: 0 件のコメント:
ラベル: , ,
登録: 投稿 (Atom)