Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 今年一年Kubernetes on AWSをやってきて、kube-awsメンテナ目線で、「今日から、できるだけ楽に、安定して本番運用」するための個人的ベスト・プラクティスをまとめておきます。 TL;DR EKSはまだプレビュー申込の段階。実際に動くものがあるかもわからない。 EKSとkops、kube-aws、kubesprayなどは組み合わせて使うもの。代替えにはならない。 SaaSありなら分散ログ、分散トレース、リソースモニタリングはDatadogに寄せると運用が楽 istioは安心して本番運用できるフェーズではない(Service
TL;DR; 分散トレーシングシステムの４要素を理解する 分散トレーシングシステムの「バックエンド」と「それ以外」は分けて選択してもいい 一例として、分散トレーシングシステムのバックエンドとしてDatadog APM、クライアントライブラリとしてOpenTracing Tracer、PropagationフォーマットとしてB3、SpanフォーマットとしてZipkin v1を採用すると楽 アプリの設定例だけ知りたい方はここから読んでください 何がうれしいの? Zipkinの運用保守 枯れてないトレーサのバグや機能不足という悩み ログ・メトリクス・トレースそれぞれ別のサービスに見に行く手間 などから解放されます。 分散トレースといったらZipkinなんでしょ? そんなことはありません。 実際、Zipkinをデプロイせずに、Zipkin以外のサービスにZipkinトレースを集約・閲覧することがで
Prometheus、流行ってますね。 pull 型で、metrics の収集を HTTP 経由で行えるので、テスト用の監視サーバーをローカルの作業マシンに立ち上げて動作確認をしたりするのが楽なのも良い点だと思います。 Prometheus 本体も exporter も docker image が提供されており、docker での環境構築が楽なのも今風の OSS だなという感じがします。 ここでは、docker-compose を用いてローカルの Mac で起動を試みてみようと思います。 How to install Prometheus and Grafana on local Mac docker https://docs.docker.com/docker-for-mac/install/ 上記から Mac 用の dmg をダウンロードしてインストールしてください docker-c
Kubernetes Meetup Tokyo #7 https://k8sjp.connpass.com/event/67092/
どうも僕です。タイトルどおりです。 Dockerコンテナのメトリクス監視してますか？？？ 本番環境ならDataDogとかそのへんで監視していてもローカル環境のやつ確認してないこと多くないですか？ ※ 僕はしてないです。dd-agentローカルにも入れれば終わりじゃんって話なんですが、なんかあれじゃないですか。。。 監視してなかったお陰で、高負荷時に突然死する原因を調査したい場合に、無事頭を抱えました。(原因はメモリ枯渇してた) そこで、コンテナ名, コンテナID, CPU, MEM, NET RX/TX, IO R/W, PIDS 情報が見れたらいいのになーを調べてたらさくっと見れることに気づいたので記事にまとめておきます。 やりたかったのはこういうやつです。 本家の付随機能を利用する コンテナのリソース使用状況をライブで流し続ける 使い方
Loggly is a great platform to send your Kubernetes logs into. While you can run an ELK setup in the Kubernetes cluster, you still have to manage it and understand how it works. If you have high volumes of logs coming in, it’s not an easy job to scale ELK for ingestion and searching needs. Using Loggly allows you to concentrate on running your applications instead of running infrastructure. Loggly
TL;DR; プログラム的にparseやすい、構造化されたログメッセージを採用するとよいです。 また、構造化されたログメッセージにするためには、 ndjson形式(俗称? jsonlog) bunyan形式 logfmt形式 のいずれかをおすすめします。 なぜ構造化されたログメッセージがよいか? アプリケーションによって、デバッグや稼働確認、障害調査等の目的でログに含めたいデータは異なります。 アプリケーションの部分部分を担当したエンジニアによって、ログに含まれるデータのフォーマットが異なると、それが利用しづらい状態になってしまいます。 また、 KubernetesのCluster-Level Loggingにはfluentdが使われるということと、 アプリケーションが後の分析のためにログメッセージに付与しておきたいメタデータと、アプリケーションが動作している環境との関連付けのためにKub
$ kubectl create -f https://raw.githubusercontent.com/kkohtaka/kubernetes-metrics/master/prometheus/service.yml $ kubectl create -f https://raw.githubusercontent.com/kkohtaka/kubernetes-metrics/master/prometheus/deployment.yml $ kubectl create -f https://raw.githubusercontent.com/kkohtaka/kubernetes-metrics/master/prometheus/configmap.yml 検証に利用した Kubernetes リソースは次のとおりです. Service kkohtaka/kubernete
Performance analytics UI for Kubernetes Clusters. The goal of Kubedash is to allow the user or an administrator of a Kubernetes cluster to easily verify and understand the performance of a cluster and jobs running within it through intuitive visualizations of aggregated metrics, derived stats and event patterns. It is not intended to be a general-purpose Kubernetes UI. Instead, kubedash uses multi
![GitHub - kubernetes-retired/kubedash: [EOL] Analytics dashboard for Kubernetes](https://cdn-ak-scissors.b.st-hatena.com/image/square/819079370032e756c102773a289ad465ed5bf894/height=288;version=1;width=512/https%3A%2F%2Fsiteproxy.ruqli.workers.dev%3A443%2Fhttps%2Fopengraph.githubassets.com%2Fd12938085fe382bede94d542b4cc86f651e5171f9e081d440f8b4552e73b0b6c%2Fkubernetes-retired%2Fkubedash)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
