GKE上でのblog運用や監視が大分形になってきました。 次に目指すところ ここから以下のようなデータパイプラインとログの分析基盤を作って行きたいと思います。 nginx prometheus grafana | | | ------------------- | fluentd cluster | ------------------- | | | bigquery gcs papertrail | spark(data proc) TODOは以下のようなイメージです。 nginx logをLTSVに変える 自前のfluentd clusterを準備する fluentd clusterからbigquery, gcs, papertrailにfunoutするようにする nginx, prometheus, grafanaなどの稼働するcontainerのlog driverを上記で準備したものに変える google analyticsのデータをembulkを利用した定期バッチで GCSやbigqueryにpertitioningされた形で格納する 上記のログを元に、spark(data proc)を回していい感じに分析できるようにする mllibを使って遊ぶ 今回はその中での一つ目に着手します。 What ltsv 改めてltsvについてまとめます。 http://ltsv.org/ Labeled Tab-separated Values (LTSV) format is a variant of Tab-separated Values (TSV). you can parse each line by spliting with TAB (like original TSV format) easily, and extend any fields with unique labels in no particular order. ... Read more

現在のblogでは以下のようなredirect処理を追加しています。 # redirect http to https if ($http_x_forwarded_proto = "http") { rewrite ^/(.*)$ https://$host/$1 redirect; } これは以下を目的としています。 鍵をnginxで管理せず、GCPのloadbalancerで管理する。 また、https通信の複合処理はGCPで行い、そこから後ろはhttpでアクセスしたい。 このとき、blogはhttps通信しか許可しない。 そのため、ユーザーのrequest時のprotocolがhttpであるかどうかnginxで判断し、httpの場合はhttpsにredirectする localでわざわざ証明書を準備して作業するのもとても面倒。つまり ＿人人人人人人人＿ ＞　localで邪魔　＜ ￣Y^Y^Y^Y^Y^Y^Y^￣ bypass redirect ideas bypassするには以下のような方法がわかりやすいのですが、それぞれに問題があります。 local用のconf + dockerfileを分ける 管理が手間ですし、本番設定ファイルとの乖離が発生するリスクが十二分にあります 環境変数を使ってredirectしないよう処理を分岐する nginxのperl moduleもしくはlua moduleを利用しなければnginxで環境変数を利用することができない そういえば自社でやっている方法やれば良いですね、環境変数とentrykitを利用してconfを制御するようにします。 templating by entrykit entrykit は以下のようなツールです。 Entrypoint tools for elegant containers. Entrykit takes common tasks you might put in an entrypoint start script and lets you quickly set them up in your Dockerfile. ... Read more

とりあえず通知は飛ぶようになったが、２つ問題がある。 現在の通知 通知情報が不足している recover状態が通知されない これを解決します。 Notify recover alert 復旧通知をするには send_resolved optionをtrueにするだけで済みます。 receivers:-name:slackslack_configs:-send_resolved:true これはdefaultでtrueにしてよいきもするので、少しだけ掘ってみます。 https://github.com/prometheus/alertmanager/blob/master/config/notifiers.go#L27 // DefaultSlackConfig defines default values for Slack configurations. DefaultSlackConfig = SlackConfig{ NotifierConfig: NotifierConfig{ VSendResolved: false, }, commit messageを読むと、以下のように一般的に使うチャットシステムだし、通知が多いとスパムっぽくなるからとのこと。 brian-brazil committed on Jan 6, 2016 Don’t send resolved to Slack by default. Slack is a general chat system, it has no notion of resolved messages. Default it to false to avoid spamming people as we do with all other such systems. ... Read more

downtimeの観測ができるようになったので、downtimeがslackに通知されるようにしたいと思います。 そのためにもprometheusのalertingを理解します。 Alerting https://prometheus.io/docs/alerting/overview/ Prometheusのalartは２つのパートに分かれている。 prometheus alert ruleは alert managerに alertを送信する alertmanagerは silencing, inhibition, aggregation をしたり その通知を行う Alert manager behavior https://github.com/prometheus/alertmanager The Alertmanager handles alerts sent by client applications such as the Prometheus server. It takes care of deduplicating, grouping, and routing them to the correct receiver integrations such as email, PagerDuty, or OpsGenie. It also takes care of silencing and inhibition of alerts. ... Read more

いままでgkeの監視に利用するprometheusやgrafanaをimage buildをしていた。 やっていることは設定ファイルの更新でしかないので、これをconfigmapに移行して管理を容易にします。 configmap ConfigMap とは onfigMaps bind configuration files, command-line arguments, environment variables, port numbers, and other configuration artifacts to your Pods’ containers and system components at runtime. ConfigMaps allow you to separate your configurations from your Pods and components, which helps keep your workloads portable, makes their configurations easier to change and manage, and prevents hardcoding configuration data to Pod specifications. ConfigMaps are useful for storing and sharing non-sensitive, unencrypted configuration information. ... Read more

prometheus + grafanaでのmetric収集とvisualizeが大分馴染んできたので、次に prometheus/blackbox_exporter を利用した死活監視を行います。 What is blackbox expoter? The blackbox exporter allows blackbox probing of endpoints over HTTP, HTTPS, DNS, TCP and ICMP. probing という表現なかなかいいですね。 各種プロトコルを用いて様々なendpointの探査をできるめちゃめちゃ便利です。 どのようなprobe outputが得られるのか？ 存在するエンドポイントと存在しないエンドポイントの両方に通知を送るとどのような結果が得られるのか見てみます。 blackbox-exporter を立ち上げる。 docker run --rm -p 9115:9115 prom/blackbox-exporter:latest 存在するエンドポイント curl -H 'Accept: application/json' 'http://localhost:9115/probe?module=http_2xx&target=threetreeslight.com' # HELP probe_dns_lookup_time_seconds Returns the time taken for probe dns lookup in seconds # TYPE probe_dns_lookup_time_seconds gauge probe_dns_lookup_time_seconds 0.0028015 # HELP probe_duration_seconds Returns how long the probe took to complete in seconds # TYPE probe_duration_seconds gauge probe_duration_seconds 0. ... Read more

kubernates上でblogを運用していることから、kubernatesや各contaienr, nodeのmetricをkubernates上で動かしたprometheusで収集し、grafanaで描写するようにしました。 Overview 以下のような方針で構成する ingress <-> monitor service <-> monitor deployments - grafana -> prometheus GKEを利用している node, containerのmetricを収集する grafanaはpublic urlからアクセスできる prometheusはアクセス制御ができないので、port forwardingでアクセスする grafana, prometheusのデータは永続化しておく monitorというdeploymentを用意し、grafana, prometheusを同居させる monitor podsはdowntimeを許容する Prometheus kubernatesから各contaienrおよびnodeのmetricをkubernates apiserverを通して取得する。 以下のprometheusにrepoに同梱されているexpampleを参考にすることでイメージが付くと思います https://github.com/prometheus/prometheus/blob/master/documentation/examples/prometheus-kubernetes.yml nodeのmetric収集 # Scrape config for nodes (kubelet).-job_name:'kubernetes-nodes'kubernetes_sd_configs:-role:nodescheme:httpstls_config:ca_file:/var/run/secrets/kubernetes.io/serviceaccount/ca.crtbearer_token_file:/var/run/secrets/kubernetes.io/serviceaccount/tokenrelabel_configs:-action:labelmapregex:__meta_kubernetes_node_label_(.+)-target_label:__address__replacement:kubernetes.default.svc:443-source_labels:[__meta_kubernetes_node_name]regex:(.+)target_label:__metrics_path__replacement:/api/v1/nodes/${1}/proxy/metrics container metrics # Scrape config for Kubelet cAdvisor.-job_name:'kubernetes-cadvisor'kubernetes_sd_configs:-role:nodescheme:httpstls_config:ca_file:/var/run/secrets/kubernetes.io/serviceaccount/ca.crtbearer_token_file:/var/run/secrets/kubernetes.io/serviceaccount/tokenrelabel_configs:-action:labelmapregex:__meta_kubernetes_node_label_(.+)-target_label:__address__replacement:kubernetes.default.svc:443-source_labels:[__meta_kubernetes_node_name]regex:(.+)target_label:__metrics_path__replacement:/api/v1/nodes/${1}/proxy/metrics/cadvisor node, container以外にも、pod, service, endpoint, ingress, kubernates api-serverの状態を監視することも可能です。 今回は、pod, endpoint, apiserverのmetricを収集します。 # Scrape config for API servers.-job_name:'kubernetes-apiservers'kubernetes_sd_configs:-role:endpointsscheme:httpstls_config:ca_file:/var/run/secrets/kubernetes.io/serviceaccount/ca.crtbearer_token_file:/var/run/secrets/kubernetes.io/serviceaccount/tokenrelabel_configs:-source_labels:[__meta_kubernetes_namespace,__meta_kubernetes_service_name,__meta_kubernetes_endpoint_port_name]action:keepregex:default;kubernetes;https# scrape config for service endpoints. ... Read more

kubernatesそのものや、kubernates上で稼働するnodeやcontainerを監視するのにとりあえずprometheusとやってしまっていたが、どのようなmetricを取得できるのか？ちゃんと知ったほうが良さそう。 そのためにも、 kubernates - Tools for Monitoring Compute, Storage, and Network Resources を読み進めていく。 Heapster Kubernatesは Heapsterを使ってログや各イベントの収集を行っているようだ。 ただ、当のHeapsterは以下の通りDeprecatedとなっている。 DEPRECATED: Heapster is deprecated. Consider using metrics-server and a third party metrics pipeline to gather Prometheus-format metrics instead. See the deprecation timeline for more information on support. We will not be adding any new features to Heapster. どうやらheapsterは廃止となり、prometheus formatのeventを処理するthird partyのメトリクス収集パイプラインを使うことを推奨しているようだ。 とはいえ、本ドキュメントを読んでどのような機構でmetric収集すべきか理解することは意味があるので読み進める。 Heapsterは各nodeに配置されたkubeletとcadvisorからデータを収集している。 イメージとしてはこんな感じ Heapster <- kubelet <- cadvisor これは、node_exporterやcAdvisorをdeamonsetとして各コンテナに配置する必要はすでにないことを意味する。 ... Read more

blogをオーバーキルするyaml職人です。そしてkubernates入門はまじで入門すぎて全然役に立たない日々です。 今日はkubernatesのRBACとGCP IAMを正しく理解していない結果、これどっちの権限の問題やねん？と詰まることが多かったので、そこらへんの理解を軽く深めます。 GCPはquota limitでだめだったり権限だめだったり辛い。機能はめっちゃイケてるんだけど、慣れていないのが辛い。 kubernatesにおける認可とは? Kubernatesの Authorization Overview を見てみる Kubernetes authorizes API requests using the API server. It evaluates all of the request attributes against all policies and allows or denies the request. All parts of an API request must be allowed by some policy in order to proceed. This means that permissions are denied by default. すべての操作はkubernates API server を通して行われ、基本的には拒否るよ。 Review Your Request Attributes を見ると、ざっとこれだけのきめ細やかな制御がきる。 ... Read more

業務改善のためにGAS (Google Apps Script) は書かせません ただ、script editorを使ってweb上でデバッグするのは少し効率の悪い作業です。 また、テストを記述することもできません。 そのため、localで如何にgoogle apps scriptを開発するべきか考えをまとめました。 manage and deploy google apps script by clasp Collaborating with Other Developers は必読。 localでgoogle apps scriptを管理するために google/clasp を利用します。 Claspはgasをgitのようにgasのversioning、push/pullなどをサポートします。 Prepare to use clasp Then enable Apps Script API: script.google.com/home/usersettings install clasp sudo npm i @google/clasp -g OAuth loginする。このとき、以下の通りownkey optionをつけて手元に持ってくる必要がある https://github.com/google/clasp/blob/4bc1e32d742e686532d4d51633b59e7c091dba53/index.ts#L766 * Note: to use this command, you must have used clasp login --ownkey clasp login --ownkey 既存projectを管理するための準備をする ... Read more