Pull型の監視サービスであるPrometheusの使い方を説明します。
Prometheusのアーキテクチャはこの様になっています。
大まかな特徴としては以下です。
GitHubではMergeコミットなどで
といったマークを見ます。これは署名されたcommitを示すものなのですが、
を今回説明します。
gitのコミットは
commit 91e8e61ee6601576e358201315b6624181529879 (HEAD -> refactor-chain, origin/refactor-chain)
Author: Junpei Tsuji <junpei.tsuji.ams@gmail.com>
Date: Sun Jul 14 11:42:29 2019 +0900
Fixed a bug
のようにAuther名やEmailが付きますが、これらは自分で設定可能です。
ということは他人の名前やEmailを設定してcommitすることもできるため、なりすましが可能です。
GitHub上ではcommitにそういったなりすましではないことを保証するための仕組みとして署名をしたらVerifiedマークが付くようになってます。
以前
にてgRPCのUnary Interceptorの基本的な使い方を説明しました。
このInterceptorを複数設定したい時に使われるのがgo-grpc-middlewareの出している
です。READMEにありますが、以下のように複数のInteceptorをセットできます。
import "github.com/grpc-ecosystem/go-grpc-middleware" myServer := grpc.NewServer( grpc.StreamInterceptor(grpc_middleware.ChainStreamServer( grpc_ctxtags.StreamServerInterceptor(), grpc_opentracing.StreamServerInterceptor(), grpc_prometheus.StreamServerInterceptor, grpc_zap.StreamServerInterceptor(zapLogger), grpc_auth.StreamServerInterceptor(myAuthFunction), grpc_recovery.StreamServerInterceptor(), )), grpc.UnaryInterceptor(grpc_middleware.ChainUnaryServer( grpc_ctxtags.UnaryServerInterceptor(), grpc_opentracing.UnaryServerInterceptor(), grpc_prometheus.UnaryServerInterceptor, grpc_zap.UnaryServerInterceptor(zapLogger), grpc_auth.UnaryServerInterceptor(myAuthFunction), grpc_recovery.UnaryServerInterceptor(), )), )
ここで実行順序について疑問に思ったので確認してみました。
続きを読むオブジェクト指向についてClean Architectureでは
OOとは「ポリモーフィズムを使用することで、システムにあるすべてのソースコードの依存関係を絶対的に制御する能力」である。
これにより、アーキテクトは「プラグインアーキテクチャ」を作成できる。これは、上位レベルの方針を含んだモジュールを下位レベルの詳細を含んだモジュールから独立させることである
と説明されています。
このようにソフトウェアの拡張性を持たせるためにプラグイン機構を用意することは非常に大切です。
今回はhashicorpのgo-pluginを使って実現してみます。
プラグイン機構にすることでメリットがありそうなケースってなんだろう？と思って簡単にいくつか挙げてみます。
こんなところでしょうか？
fluentdのようなETLツールはプラグイン開発が非常に活発ですね。
プラグイン機構にすることで自分は本体の堅牢さ・パフォーマンスに注力し、プラグイン開発は他の開発者に作ってもらってスピード開発といった両立が可能になります。
Go言語のuuid生成で有名な satori/go.uuid はこちらのコミットでUUIDv4を生成する際にエラーを返すように変わりました。
理由は
このissueに対応するためなのですが、内部で使っているrand.Read()はそもそもどんな時にエラーが起きるのだろう？と気になって調べてみました。
Kubernetesには以下のフィールドでCPUやメモリを制限することが可能です。
spec.containers[].resources.limits.cpuspec.containers[].resources.limits.memoryspec.containers[].resources.requests.cpuspec.containers[].resources.requests.memoryref: Resource Management for Pods and Containers | Kubernetes
cpu: 1、cpu:2といった整数値はイメージが湧きやすいですが、
cpu: 100mといった時にどういう動きをするのか？という疑問があったので調べてみました。
