Prometheus + Grafana を Mac 上で docker-compose で起動 - Qiita
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
Dockerコンテナのメトリクス監視してますか？ - Qiita
どうも僕です。タイトルどおりです。 Dockerコンテナのメトリクス監視してますか？？？ 本番環境ならDataDogとかそのへんで監視していてもローカル環境のやつ確認してないこと多くないですか？ ※ 僕はしてないです。dd-agentローカルにも入れれば終わりじゃんって話なんですが、なんかあれじゃないですか。。。 監視してなかったお陰で、高負荷時に突然死する原因を調査したい場合に、無事頭を抱えました。(原因はメモリ枯渇してた) そこで、コンテナ名, コンテナID, CPU, MEM, NET RX/TX, IO R/W, PIDS 情報が見れたらいいのになーを調べてたらさくっと見れることに気づいたので記事にまとめておきます。 やりたかったのはこういうやつです。 本家の付随機能を利用する コンテナのリソース使用状況をライブで流し続ける 使い方
KubernetesにデプロイするDockerコンテナのログ形式を選ぶ - Qiita
TL;DR; プログラム的にparseやすい、構造化されたログメッセージを採用するとよいです。 また、構造化されたログメッセージにするためには、 ndjson形式(俗称? jsonlog) bunyan形式 logfmt形式 のいずれかをおすすめします。 なぜ構造化されたログメッセージがよいか? アプリケーションによって、デバッグや稼働確認、障害調査等の目的でログに含めたいデータは異なります。 アプリケーションの部分部分を担当したエンジニアによって、ログに含まれるデータのフォーマットが異なると、それが利用しづらい状態になってしまいます。 また、 KubernetesのCluster-Level Loggingにはfluentdが使われるということと、 アプリケーションが後の分析のためにログメッセージに付与しておきたいメタデータと、アプリケーションが動作している環境との関連付けのためにKub
Kubernetes のメトリクスを Prometheus を使って監視する - Qiita
$ 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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
docker-composeのログを雑にCloudWatchに投げつける - Qiita
Dockerのlogging driver: それぞれの特徴と使いどころ(json-file, syslog, journald, fluentd) - Qiita
Dockerコンテナのログは標準オプションでローテートできる - Qiita
