開発環境からElastic APMを仕込むときの一言メモ
概要
Angular SPAのフロントエンドと、バックエンドのサーバアプリケーションがあって、これを開発していると想定します。
だいたい、npm startなどとして実行していると、ポート4200番でフロントエンドは動き、
サーバサイドは、dotnet runとすれば5100あたり、VisualStudioからデバッグ実行すれば、40000番代だかそのあたりのポートで起動しているかと思います。
それぞれにElastic APMを仕込むとして、フロントエンド側からバックエンドまで一気通貫に見て分析したい、というのが人情です。今回はこうした環境でそれを行うための手順メモです。
なぜこれをやろうと思ったか
一個前の記事で、RUMと.NETAgentを仕込んでAPMの画面から確認する、というのをやりました。
しかし、このときの設定では、AngularのSPAのトランザクション、サーバサイドのトランザクションと分けて出力されていて、一気通貫に見られるようにはなっていませんでした。
Elastic APM 7.4.0リリース記念 Angular SPAと.NETCoreアプリにAPMを仕込む - 今日もショートドリップをマグで。
「分散トレーシングできるので、出来るはず」と勉強会で聞いたので試してみようとしたのです。
実現すること
下の絵を見てください。ServicesのところにAngular-appとserver-appと2種類表示されています。
フロントエンド側のAngularでは、HTTPリクエストの時間が、呼び出されたサーバ側では、そのコントローラ以降の処理がタイムラインとして表示されています。
こうした画面を出すには、どうすればいいのかを提示するのが今回の目的です。
ドキュメントの確認
まず公式ドキュメント、原典にあたるのは基本動作ですので、これをまず行います。
このリンク先にある分散トレースの例としてあげられている画像では、既に実現することで確認したような内容になっています。 が、AngularのSPA用の記事の中身をコピペしただけでは、こうなりません。 （Angular integration | APM Real User Monitoring JavaScript Agent Reference [4.x] | Elastic）
その答えは、こちらのドキュメントにありました。
Distributed tracing is enabled by default in the RUM agent, however, it only includes requests made to the same origin. In order to include cross-origin requests you must set the distributedTracingOrigins configuration option.
RUMエージェントでは、デフォルトで分散トレースができますよ！でも、Same Originのリクエストに限られるよ！！！！！違うところへのリクエストも含めたいなら、指定してね！
開発環境などで、フロントエンドとサーバサイド側のポートが違う場合も、この例に該当することになります。
distributedTracingOriginsを指定してやることにしましょう。
app.module.tsへの追加
今回手元の.NETCoreのサーバアプリケーションは、44394ポートでデバッグ実行されるようになっていたので、これを追加するようにします。
export class AppModule {
constructor(service: ApmService) {
// API is exposed through this apm instance
const apm = service.init({
serviceName: 'angular-app',
serverUrl: 'http://localhost:8200',
distributedTracingOrigins: ['https://localhost:44394'] // ←これ
})
apm.setUserContext({
'username': 'foo',
'id': 'bar'
})
}
}
もちろんArrayになっているので、複数の場所を指し示す必要があるときは、必要に応じてdistributedTracingOriginsに追加するのが良いでしょう。
この1行を足すことで、先に示していたようなSPAの画面とサーバサイドの画面のトランザクションが１つのタイムラインで表示させることができるようになりました。パチパチパチ。
動作確認環境
- Elasticsearch 7.4.0
- Kibana 7.4.0
- APM 7.4.0
すべて公式(docker.elastic.co）のDockerイメージを利用
まとめ
- 異なるサーバ、ポートの環境も含めてAPMを入れるときは、distributedTracingOriginsに宛先を追加する
- だいたいのことは公式ドキュメントに書いてあるので、（個人ブログを見るより）まずは原典にあたるのが良い
では、よい月曜日をお迎えください。
Elastic APM 7.4.0リリース記念 Angular SPAと.NETCoreアプリにAPMを仕込む
概要
10月2日、Elasticの各種プロダクトの7.4.0がリリースされました。
APM（Application Performance Monitoring）も7.4.0が出ており、ブログも書かれております。
この中で２つ注目するところがありました。
- We have also further strengthened our support for Single Page Applications (SPA) by adding out of the box Angular instrumentation.
- .NET agent full framework support
AngularのSPA向けサポート強化と、.NETのAgentのことが入っています。
2019年5月末のElastic{ON} Tour Tokyoでは、今年中に.NETのAgent出るかもね、と話されていたように思いますが、やはり年内に出てきていましたね。
ちょうど手元にある環境が、フロントがAngular8のSPAで、サーバ側が.NETCore2.2という環境があったので、APMを試してみた記録の記事です。
Angularに仕込む
Angular SPAへの組み込み方は、この本家の記事が一番参考になります。
npm install
npm install @elastic/apm-rum-angular --save
何はなくとも、npm installでangular用のライブラリを入れます。
app_module.tsへの適用
お手持ちのapp_module.tsに対して設定を入れていきます。
import { Routes, RouterModule } from '@angular/router'
import { ApmService } from '@elastic/apm-rum-angular'
const routes: Routes = [
{ path: 'contact', component: ContactListComponent },
{ path: 'contact/:id', component: ContactDetailComponent }
]
@NgModule({
imports: [BrowserModule, RouterModule.forRoot(routes)],
declarations: [AppComponent, ContactListComponent, ContactDetailComponent],
providers: [ApmService],
bootstrap: [AppComponent]
})
export class AppModule {
constructor(service: ApmService) {
// API is exposed through this apm instance
const apm = service.init({
serviceName: 'angular-app',
serverUrl: 'http://localhost:8200'
})
apm.setUserContext({
'username': 'foo',
'id': 'bar'
})
}
}
まず大事な設定の箇所を確認します。
apmサーバの指定
// API is exposed through this apm instance
const apm = service.init({
serviceName: 'angular-app',
serverUrl: 'http://localhost:8200'
})
ここでは、serviceNameとserverUrlを書いていますが、serverUrlはAPMサーバの場所を指定します。
serviceNameは、KibanaのAPM画面で、ここで指定したサービス名が表示されることになります。
routeの設定
const routes: Routes = [
{ path: 'contact', component: ContactListComponent },
{ path: 'contact/:id', component: ContactDetailComponent }
]
pathとcomponentを対にして設定していますが、いろんなコンポーネントから成り立つようなSPAを作っている場合、すべてのrouteをここで書いておくのは難しいかと思います。
そういう場合は、const routesの部分を丸っと消して、NgModuleのimport箇所をこう書き換えてしまいましょう。
@NgModule({
imports: [BrowserModule, RouterModule],
declarations: [・・・],
})
ここまでのまとめ
ここまでにやったことは大きく２つです。
- npm installでエージェントを入れる
- app_module.tsにAPMの設定を足す
念のためここでビルドエラーが出ないかを確認し、npm startできるかどうか確かめておきましょう。
.NET CoreアプリのAPMを仕込む
nugetでインストール
本家のドキュメントを確認します。
今回の.NETCoreアプリは、EntityFrameworkCoreも入っているため、Elastic.Apm.NetCoreAllをnugetで選択して入れます。
この時点でのバージョンは、1.1.0でした。
設定ファイルを書く
appsettings.jsonにAPMの設定を追加します。
{ "ConnectionStrings": { "Default": "Data Source=*****************;Initial Catalog=*************;Integrated Security=True;Pooling=False;Connect Timeout=30" }, "AllowedHosts": "*", "ElasticApm": { "LogLevel": "Debug", "ServerUrls": "http://localhost:8200", "TransactionSampleRate": 1.0, "ServiceName": "server-app" } }
やはり肝心なのは、ServerUrlsでAPMサーバの場所を指定するのと、ServiceNameで分かりやすい名前を設定しておきましょう。
何も指定しない場合は、プロジェクト名がServiceNameとなって表示されます。
Startup.csに追加する
public void Configure(IApplicationBuilder app, IHostingEnvironment env) { app.UseStaticFiles(); app.UseAllElasticApm(Configuration); // ← これ
Configurationを引数で渡しておくことで、先ほど設定したappsettings.jsonの設定を使ってくれます。
もし、引数無しの app.UseElasticApm(); とした場合については、ドキュメントにこう書かれています。
By simply calling app.UseElasticApm() without the overload, the agent will read configurations only from environment variables.
設定ファイルを読まずに環境変数を使うとのことです。
例えばAzureでAppServiceを使っている人などは、設定ファイルより環境変数を使うことが多いかと思うので、その用途に向いていそうです。
APMサーバの設定
忘れてはならないAPMサーバの設定を２つほど紹介しておきます。
APMサーバの中にある設定ファイル、apm-server.ymlを編集します。
# Enable Real User Monitoring (RUM) Support. By default RUM is disabled.
rum:
enabled: true
# Comma separated list of permitted origins for real user monitoring.
# User-agents will send an origin header that will be validated against this list.
# An origin is made of a protocol scheme, host and port, without the url path.
# Allowed origins in this setting can have * to match anything (eg.: http://*.example.com)
# If an item in the list is a single '*', everything will be allowed.
allow_origins : ['*']
まず1点目です。
rum.enabledがデフォルトでは、falseになっています。
今回はRUMを使いたいので、これをtrueにします。
rum:
enabled: true
次に2点目です。
CORS設定をしておかないと、APMサーバとフロントエンドのAngularのSPAが動くところが違うなどした場合、データを送れないため、これを許可するようにしておきます。
allow_origins: ['*']
KibanaのAPM画面で確認
Angular側の見え方
Transactionsのところを見ると、SPAのRouteのところが表示されています。
リンクになっているので、選択すると詳細画面に遷移します。
home/system/logが、外部にPOSTでアクセスしていて、そこで3秒近くかかっていることが見て取れます。
また、赤枠で囲ったuser: barとなっているところを見てください。
これは、app_module.tsでAPMの設定をいれたときにid:bar といれたところからきています。
TimelineではなくMetadataのタブに遷移すると、usernameも確認することができます。
.NETCore側の見え方
今度は、.NETCoreで作られたサーバ側の方を見てみましょう。
GETやらPOSTやらRESTのエンドポイントになっているところがリストアップされています。
Transactionのリンク部分をクリックして、詳細を見てみます。
発行されているSQL(EntityFrameworkCoreを使っているところ）の呼び出しと処理時間がTimelineとして表示されています。
遅いな？と思ったとき、SQLを投げている回数が多いのか、SQLそのものの処理に時間がかかっているのか、一目で確認することができますね。
まとめ
たとえば、このようなアプリケーションをAzure上のPaaSにのせて動かしていたことを考えますと、何もElasticのAPMじゃなくてもAzure Monitorで足りるじゃないか、という考え方もできます。
一方で、ElasticのAPMの良さを考えてみますと次のように言えそうです。
- オンプレでもどこのベンダーのクラウドでも、同じようにアプリケーションのパフォーマンスを監視できる
- 各種のメトリクスやアプリケーションのログの監視とツールを統合することによる学習コスト低減が実現できる
- 監視する対象の台数で課金されない
機械学習との連携も組み込まれていますが、そんな本格的な利用でなくても、ある時点で組み込んでパフォーマンスの調査をしてみる、という用途でも十分に活用できるかと思います。
Azure blob storageからLogstashを使ってデータを読む
概要
公式ドキュメントで、Logstashの標準でInputできるものを確認しますと、Azure関連ではazure_event_hubsevent_hubsはありますがAzure Blob Storageはありません。
AWS S3はあるのに何でAzure Blob Storageは無いんや！というAzure大好きっ子（もしくは、やんごとなき大人の事情でAzure使う人）は思うことでしょう。
安心してください。Elastic公式にはないけど、GithubのAzureのレポジトリにはあるよ！
これを使ってやってみますよっと。
実践
環境の準備
上のレポジトリには対応しているLogstashのバージョンについての言及がないので、最新版を用意します。 ９月１６日時点の最新は、7.3.2なのでこれを使います。
誰でも同じ環境となるように、Dockerを使って確認していきます。
docker pull docker.elastic.co/logstash/logstash:7.3.2
WebApps（Windows）のログファイルをAzure Blob Storageに出力するようにし、これをLogstashで読み込んでみる、というシナリオです。
インストール
dockerコンテナの中で以下のコマンドを実行します。
logstash-plugin install logstash-input-azureblob
インストール結果
気になるログが数点出ています。
- unsupported Java version "11", defaulting to 1.7
WARNING: Illegal reflective access by org.jruby.util.io.FilenoUtil (file:/usr/share/logstash/.m2/repository/org/jruby/jruby-core/9.1.2.0/jruby-core-9.1.2.0.jar) to method sun.nio.ch.SelChImpl.getFD()
sh: line 0: cd: uri:classloader:/: No such file or directory org.glassfish:javax.json:1.1:compile
しかし、Installation successfulと出ているので、成功しているのでしょう。
設定ファイルの準備
ドキュメントに従いlogstashの設定ファイルをこしらえます。
見る限りポイントは、BlobStorageのアカウント名、アクセスキ―、コンテナ名、フィルタするならフィルタの指定ぐらいです。
このあたりは同じinputの中でもfileと似ていて想像しやすいですね。
input {
azureblob
{
storage_account_name => 'mystorageaccount'
storage_access_key => 'VGhpcyBpcyBhIGZha2Uga2V5Lg=='
container => 'wad-iis-logfiles'
path_filters => "hoge-APP/**/*.log"
codec => line
}
}
filter {
## Ignore the comments that IIS will add to the start of the W3C logs
#
if [message] =~ "^#" {
drop {}
}
grok {
# https://grokdebug.herokuapp.com/
match => ["message", "%{TIMESTAMP_ISO8601:log_timestamp} %{WORD:sitename} %{WORD:computername} %{IP:server_ip} %{WORD:method} %{URIPATH:uriStem} %{NOTSPACE:uriQuery} %{NUMBER:port} %{NOTSPACE:username} %{IPORHOST:clientIP} %{NOTSPACE:protocolVersion} %{NOTSPACE:userAgent} %{NOTSPACE:cookie} %{NOTSPACE:referer} %{NOTSPACE:requestHost} %{NUMBER:response} %{NUMBER:subresponse} %{NUMBER:win32response} %{NUMBER:bytesSent} %{NUMBER:bytesReceived} %{NUMBER:timetaken}"]
}
## Set the Event Timesteamp from the log
#
date {
match => [ "log_timestamp", "YYYY-MM-dd HH:mm:ss" ]
timezone => "Etc/UTC"
}
## If the log record has a value for 'bytesSent', then add a new field
# to the event that converts it to kilobytes
#
if [bytesSent] {
ruby {
code => "event.set('kilobytesSent', event.get('bytesSent').to_i / 1024.0)"
}
}
## Do the same conversion for the bytes received value
#
if [bytesReceived] {
ruby {
code => "event.set('kilobytesReceived', event.get('bytesReceived').to_i / 1024.0 )"
}
}
## Perform some mutations on the records to prep them for Elastic
#
mutate {
## Convert some fields from strings to integers
#
convert => ["bytesSent", "integer"]
convert => ["bytesReceived", "integer"]
convert => ["timetaken", "integer"]
## Create a new field for the reverse DNS lookup below
#
add_field => { "clientHostname" => "%{clientIP}" }
## Finally remove the original log_timestamp field since the event will
# have the proper date on it
#
remove_field => [ "log_timestamp"]
}
## Do a reverse lookup on the client IP to get their hostname.
#
dns {
## Now that we've copied the clientIP into a new field we can
# simply replace it here using a reverse lookup
#
action => "replace"
reverse => ["clientHostname"]
}
## Parse out the user agent
#
useragent {
source=> "useragent"
prefix=> "browser"
}
}
output {
stdout { }
}
これを /tmp/azure.confとして保存しました。
logstash起動
Logstashを起動してみます。
logstash -f /tmp/azure.conf
起動してみると、以下のようなメッセージが表示されました。
Using version 0.9.x input plugin 'azureblob'. This plugin should work but would benefit from use by folks like you. Please let us know if you find bugs or have suggestions on how to improve this plugin.
This pliugin should work. 動くはずである、と。
処理結果
grokパースエラーとはなりましたが、無事にBlobStorageに保存されたWebAppsのログが出力されていることが確認できました。
改めて、サンプルを見てみますと、Example for Wad-IISとなっていました。
Microsoftのドキュメントを確認すると、以下のようになっています。
現在、Azure Websites からの IIS ログはサポートされていません。
Wad-IISを対象としたGrokのパターンだとエラーになるのは分かりましたが、自分でパターンを用意すれば良いということが分かれば十分です。
まとめ
ここまでやってみて、まとめます。
- Azure Blob Storageから読み出すプラグインは、いくつか警告が出ているものの動くといえば動く
- 細かなオプションは要調査
- 実運用するには、事前に十分なテストを
「転んでも泣かない」
こういう姿勢が大事だろうと思います。ではでは。
Elasticsearch Service (Elastic Cloud)でKuromojiのユーザ辞書を使う方法
概要
同義語辞書を入れたはいいけれど、同義語が展開されたあとの形態素でうまくヒットしなくて困ることがありますよね。
多くの人は、ユーザ辞書と同義語辞書を同時にメンテナンスしているのではないでしょうか。
Elasticsearch Service(Elastic Cloud)は、Elastic社さんが運営するSaaSです。 SaaSなので、ホストに何かを置かなければいけないものは実現できないのか？というと、そうではありません。
ユーザ辞書だけでなく同義語辞書のファイル、自作したプラグインなどを置かせてくれるという心憎い仕様となっております。
Elasticが運営するElasticsearch Serviceは、Amazon Elasticsearch Serviceとは別物なので、そこんとこよろしく。
英語が苦ではない方は、以下を読めば簡単にできます。
ここから先は、日本語でスナップショット多めで、実際に手を動かさなくても動かした気になれる感じでやっていきましょう。
手順
大まかに辞書を使うときの手順は、以下の２つです。
以上です。簡単ですね。恐ろしいですね。
カスタムプラグインの作成
新規作成
左側のメニュー「Custom plugins」を選択し、「Add plugin」をボタンを押下します。
作成画面
| 項目 | 説明 |
|---|---|
| Pliugin name | プラグイン名を指定します。表示名になります。 |
| Version | どのElasticsearchのバージョンで使うかを書きます。 7.*なら、7系で使えるという意味になります |
| Description | 中身を示す説明を書いておきます |
| Plugin type | 「辞書かスクリプトが入った」の方を選択します。 |
できたら、「Create plugin」を押下します。
辞書ファイルの作成
にがうり,にがうり,ニガウリ,カスタム名詞
こんな１つの単語を登録する辞書ファイルを userdict_ja.txtとして作成しました。
ファイルのアップロード
ここで、辞書ファイルを含んだzipファイルを登録します。
辞書ファイルについては、以下のような構造でzipにしました。
.
└─dictionaries
userdict_ja.txt
「dictionaries」というフォルダを作って、その下にファイルを置くのが良いです。
添付が成功すると、「Upload successful」と表示されます。
作成確認
左側のメニューより再度、Custom pluginsを選択すると、いま作成したkuromoji用の辞書がカスタムプラグインとして登録できていることが確認できます。
Elasticsearchの設定
次に、カスタムプラグインとして登録できたので、これをElasticsearchで使えるようにしましょう。
Elasticsearch plugins and settings
Elasticsearchの編集画面の中ほどに「Elasticsearch plugins and settings」という箇所があります。
ここを展開すると、先ほど登録したCustom Pluginsが表示されるので、チェックボックスにチェックをいれ、Elasticsearchを編集します。
あとは、保存ボタンを押しましょう。
settings
あとは、辞書ファイルが使えるようになったので、このファイルを使うsettingsをやってみましょう。
PUT forum0913
{
"settings": {
"analysis": {
"analyzer": {
"kuromoji_dic_analyzer": {
"type": "custom",
"tokenizer": "kuromoji_dic_tokenizer",
"filter": ["synonym"]
}
},
"filter": {
"synonym": {
"type": "synonym",
"synonyms": [
"ゴーヤ,にがうり"
]
}
},
"tokenizer": {
"kuromoji_dic_tokenizer": {
"type": "kuromoji_tokenizer",
"user_dictionary": "userdict_ja.txt"
}
}
}
},
"mappings": {
"properties": {
"item": {
"type": "text",
"analyzer": "kuromoji_dic_analyzer"
}
}
}
}
tokenizerの設定の中で、user_dictionaryを指定しているところに着目してください。
先ほどzipにするときは、dictionaries/userdict_ja.txtという階層になっていたはずですが、ここではuserdic_ja.txtと指定してください。
もし、dictionaries/userdict_ja.txt と指定した場合、こんなエラーになります。
"error": {
"root_cause": [
{
"type": "illegal_argument_exception",
"reason": "IOException while reading user_dictionary_path: /usr/share/elasticsearch/config/dictionaries/userdict_ja.txt"
}
],
"type": "illegal_argument_exception",
"reason": "IOException while reading user_dictionary_path: /usr/share/elasticsearch/config/dictionaries/userdict_ja.txt",
"caused_by": {
"type": "no_such_file_exception",
"reason": "/usr/share/elasticsearch/config/dictionaries/userdict_ja.txt"
}
},
"status": 400
}
まとめ
辞書ファイルが使える、独自のプラグインが使えるというところは、Elasticsearch Servicceの大きな特徴かと思います。
他にも良い点をあげるとすれば・・・ 1. 新しいバージョンが即日使えるようになる 2. 画面の左側Helpのメニューから、サポートに問い合わせができる。（本家の人が対応してくれる）
決して回し者じゃありませんことよ。ではでは。
１級ファイナンシャルプランニング技能士で独学するのに個人的に役立ったもの
はじめに
ファイナンシャルプラニング技能士は、FP試験として２級、３級は割と人気があるようです。
ちょうどスターバックスで隣の席の方が、１級の勉強をしていたので、自分が勉強をしていたときに使っていたものを紹介します。
書籍
きんざい 1級FP技能士(学科)精選問題解説集
試験元が作っている精選問題集。
本家が作っているだけに的中率は高いのでは？と期待するところですが、思いのほか当たらないんだな、これが。
学科は、広く薄く、重箱の隅をつついて壊すぐらいの勢いの問題が多いので、この問題集に出てくる内容は基本的に出てきたら正解したいところ。
じゃあ、どこが役立つの？と言われたら、解説。
テキストをじっくり体系的に理解するのが正攻法だと思うところですが、どのような点を問うているのか？というところは問題解説になるので、解説がおすすめ。
応用編の方については、学科に比べてれば得点しやすく、年金の問題など、２級やAFPを取った人にはおなじみだと思う。
2019年9月試験をあてる TAC直前予想 FP技能士1級
独学だと、ついつい「あてる」というところに期待をしがちだけども、これをやればカバーできるという生易しい試験じゃない。 穴を探す模擬試験として使うのは良いかもしれないが、時間と費用と相談かなぁ。
学校系
TAC 過去問解説
過去問解説の動画が見られるTACのサービス。スマホに入れて通勤途中に確認する利用法が良いと思う。
年とともに記憶力が弱くなってくると、音声、画像、いろんなところで反復してインプットしないと、なかなか脳に定着しない。
そんな方にはおすすめ。
Webサイト
こちらは定番中の定番かな。
老齢基礎年金の額など過去問を解く際には数字が違うので、そこは注意する必要があるかなぁ。
解き方を覚える、身に着けるのには繰り返しが一番だと思うので、過去問がずらーっと載せてあるため、それを行う場としてはとても良いと思う。
個人的感想
1級は定番問題というよりは、法改正された内容もすぐに出てくる印象があります。
私が運良く合格したときは、積み立てNISAが始まったときで、その限度額は何年でおいくらですか？のような問題が出ました。
小規模宅地等の特例についても、面積が280㎡から330㎡になったことや、家なき子特例など時代が変わると中身がちょっとずつ変わっていくところも、しっかり追っておく必要があるかと思います。
これを踏まえて３つほどあげるとするなら・・・
- 新しい本でやる（基本となる数字が試験のときに使うものと同じ正しいものを使う）のが良いと思う。
- 身近な話題になるところでの法改正は要チェック
- CFPの学科試験とは問われる問題のタイプが全然違うから、きんざい試験用の準備が必要
最期に、漢字で書けるように！書く練習もお忘れなく。 Good luck!
Elasticsearch Service(Elastic Cloud)のKibanaを日本語化する
概要
Elastic CloudのKibanaの画面を日本語化するためのTipsです。
Elastic Cloudでクラスタ作成画面
Elastic Cloudのクラスタ作成画面にて、「User Setting overrides」からKibanaの設定項目を開きます。
ここで、i18n.locale: "ja-JP" と入力してクラスタを作成することで、日本語化されたKibanaの画面となります。
設定できる項目の一覧は、以下のマニュアルに記載があります。
確認
この状態で作成されたKibanaにアクセスしてみたところの画面です。
ようこその下の方、「Elastic Stackへのi入口」となっています。
タイポ発見！！！
Elastic CloudのKibanaをリバースプロキシを通してアクセスする
概要
Elastic Cloudで運用しているKibanaの画面を、独自ドメインのURLで公開したいと思ったとき、
リバースプロキシを立てたくなると思うのですが、その設定方法の一例を備忘録がてら書いておきます。
2019年7月時点では、独自ドメインでの公開は本家の機能にありません。
nginxを使って公開する
結論から先にいうと、Let’s Encryptでも正式なのでも、オレオレ証明書でも良いのでSSLを使う前提で証明書を用意しましょう。
ssl_certificateとssl_certificate_keyの箇所です。
あとは、proxy_passのところにElastic CloudのkibanaエンドポイントのURLを書きます。
以下のファイルをserver.confとして作成しました。
server {
listen 443 ssl;
server_name localhost;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP;
ssl_prefer_server_ciphers on;
ssl_certificate /etc/nginx/server.crt; # サーバー証明書のパス
ssl_certificate_key /etc/nginx/server.key; # 秘密鍵のパス
location / {
proxy_pass https://**********************.us-east-1.aws.found.io:9243;
}
}
これで https://localhost/ とアクセスすると、ブラウザ --> nginx --> Elastic Cloud と処理がされ、あたかもlocalhostでkibanaが動いているかのように見えます。
起動例
docker run -d -it -v /hoge/server.conf:/etc/nginx/conf.d/default.conf \ -v /hoge/server.crt:/etc/nginx/server.crt \ -v /hoge/server.key:/etc/nginx/server.key \ --name nginx \ -p 80:80 \ -p 443:443 \ nginx:latest
Trap point1
httpでのアクセスでログイン画面を表示するとエラーになる。
もっともシンプルなnginxを使ったリバースプロキシの設定かと思いますが、これだとエラーになります。
server{
listen 80;
server_name localhost;
location / {
proxy_pass https://**********************************.us-east-1.aws.found.io:9243;
}
}
A secure connection is required for log in
Contact your system administrator.
メッセージを見てもわかるように、ログイン画面をhttpでアクセスする画面でやるな、ということでしょう。
Trap point2
server{
listen 80;
server_name localhost;
location /kibana {
proxy_pass https://**********************************.us-east-1.aws.found.io:9243;
}
}
http://localhost/kibana としてアクセスしたいと思い、上記のような設定にしたとします。
この場合は、ログイン画面への遷移が発生したときに、意図しないURLとなってしまうため、404エラーが発生します。
Elastic Cloud側の設定はSaaSであるため、変更できないと考えた方が良いと思います。したがって、locationとしては、 ”/” で指定しておくのがシンプルで良いかと考えます。
