要約：例に出している完全なコード：https://github.com/teamzerolabs/mirth_channel_exporter、インストラクションにゆっくり目を通してください。 バックグラウンドエクスポーターは、 Prometheus モニタリング パイプラインの心臓部であり、魂です。エクスポーターがまだ存在しないのであれば、ぜひ自分で書いてみてください。エクスポータを作るために必要な手順について書きました。心配ありません、とても簡単ですから！ 目標 GOでエクスポーターを書くエクスポータは、スクレイプされるとアプリケーション（この例ではMirth Connect）に対してREST APIを呼び出す。エクスポータは結果のペイロードをメトリクスに変換する。1. GO と*パッケージディペンデンシーの設定 https://golang.org/doc/installの手順に従っ

自作Exporter Prometheusでスクレイプする用のExporterを自作してみた. やったことのまとめ GoのPrometheusクライアント1を使って, 自分で設定したメトリクスを表示できるExporterを作成した 作成したExporterとPrometheusをDockerで動かし, スクレイプできることを確認した https://github.com/uzimihsr/example-exporter つかうもの macOS Mojave 10.14 go version go1.14.6 darwin/amd64 prometheus/client_golang v1.7.1 Docker Desktop for Mac 2.1.0.3 Docker version 19.03.2 docker-compose version 1.24.1 やったこと Exporte

この記事はブログに投稿されたものの転載です。 Prometheusとはオープンソースの監視ツールです。このツールの主な特徴は以下の通りです。 メトリクスの収集をHTTPを通じたPull型で行います。 柔軟性に富んだクエリで集計した後にグラフとして表示することができます。このクエリのことを公式的に「PromQL」と称しています。 複数のコンポーネントから構成されています。Prometheus自体は監視サーバであり、GUI部分はGrafana、アラート部分はAlertManagert等のコンポーネントが担っています。 上記の特徴が全て私のニーズにマッチしており、非常にお気に入りのツールになっています。 さて、この記事で取り扱うのはBlackbox Exporterというコンポーネントです。このコンポーネントは各種通信プロトコルを通じて対象サーバの死活状態に関するメトリクスを生成します。Prom

global: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: 'blackbox' metrics_path: /probe params: module: [icmp] static_configs: - targets: - 192.168.100.55 relabel_configs: - source_labels: [__address__] target_label: __param_target - source_labels: [__param_target] target_label: instance - target_label: __address__ replacement: blackbox_exporter:9115

どうやって決める？kubernetesでのシークレット管理方法 （Cloud Native Days 2020 発表資料） 2020年9月8日 株式会社NTTデータ デジタル技術部 里木、山田Read less

MS Ignite 2019というMicrosoft社のイベントで Mohammad Nofalさんにより話されていた、 AKSのクラスタ管理と高可用性に関するベストプラクティス (原題: Applying best practices to Azure Kubernetes Service (AKS)) について内容を紹介します。 前編では高可用性設計について説明します。 大まかにはMohammad Nofalさんの説明に沿ってますが、 自分が説明するとしたらこんな感じかな…という風に作成したので Nofalさんのセッションもご参照いただけると幸いです。 参考資料映像https://myignite.techcommunity.microsoft.com/sessions/81598?source=SessionDeck ソースコード等(スライドもあります)

こんにちは、もーすけです。 本日はKubernetesのノード障害が起きたときのPodの挙動について確認します。 いままで、ノード障害が起きたときのPodの挙動、スケジューリングについて誤った認識をしていました。 お恥ずかしい限りなのですが、同じような誤った認識をしているかたに向けて確認したことを解説します。 概要 まずはじめに、状況を説明します。Workerノード3台があって、アプリケーションが動作しているとします。 Worker#1がシャットダウンした、kubeletが停止した、ネットワーク的に疎通ができなくなったなどが起きたときに、その上で動いていてPodはどうなるの？という話です。 感覚的にいうと、レプリカ数を維持するために他のノードに移って起動するんでしょ！、と思いたいところなのですが、実際はそれほど単純でもありません。 どのような動きをしていくのか、Deploymentを使った

k8sクラスタのノードの一つが、ハードウェア障害などでダウンした場合の振る舞いについて検証した記録です。 検証システムの構成 Kubenetes v1.10 クラスタをVagrantで構築したメモのVagrantで構築したk8sクラスタを利用して、障害時の振る舞いについて、調べてみました。 マスターノードであるk8s1にもNodePortが動作していますから、このk8s1をロードバランサーに見立て、HTTPクライアントからk8s1のTCP31514をアクセスして、k8s2とk8s3のNginxのウェブサーバーをアクセスします。 そして、 k8s2 仮想サーバーの模擬障害としてシャットダウンした場合のクライアント視点での動作、ポッドのマイグレーションについて検証します。 正常稼働の状態 初期状態として、すべてが正常に稼働している状態の動作を確認しておきます。 この画面の表示は、上から順に、以

概要 自前の認証機能を持っていない、既存のウェブサイトや独自アプリがある Basic認証などで都度ID/パスワード設定するのは古臭いし管理たいへんなので止めたい シングルサインオンできる 自前の認証機能 を使いたい はじめに この記事は以下の続編です。 OAuth2 Proxyで外部認証(1) GitHub編 Keycloakによる認証基盤の立ち上げ(1) Wildfly版 OAuth2で「外部の」認証基盤を利用する仕組みは出来た。 Keycloakで「自前の」認証基盤立ち上げは出来た。 なので、（満を持して）自前の認証基盤でSSOできる仕組みへ移行。 設定の流れ OAuth2 Proxyのドキュメント確認 ドキュメントの Keycloak OIDC Auth Provider の項を見ておく。 この項と別に Keycloak Auth Provider という項もあるが、冒頭のnoteに

こんにちは。 僕はぶんとくといいます。 これはただの一人のヲタクの自分語りです。 興味がある方は読んでくれると幸いです。 ・はじめにまず最初に自己紹介させてください。 ぶんとくという名前はニックネームで本名は「文徳」と書いて「ふみのり」と言います。 1997年9月11日大阪生まれ、24歳です。 なぜ今回このようなものを書こうと思ったのか、特に理由はありません。笑 高卒、教養無しのクソガキが書くものなので優しく読んでください。 では早速、 ・人生最初のミスタイトルの通り人生最初のミスについてですが、 「俺、女嫌いだから」 と小学5年生の時に母に言った一言です。 冷静に考えて、これを真に受ける母も母だと思いますが、いわゆる教育ママだった母はこれを理由に僕を中高一貫の男子校へ進学させることを決意します。 5歳から剣道を続けていたこともあり、進学校で剣道部のある男子校(世界一臭そう)への受験をし、

1 年ぐらい Public Preview だった Azure Front Door の Standard / Premium がやっと GA しました。 ぶっちゃけ機能的には劇的な変化はないですが、長らく問題となっていた Subdomain Takeover 対策が標準で入ったことや、Private Link を使ってオリジンへの安全な接続が行えるようになっているのは大きいです。 これまでの Azure CDN (Microsoft) や Front Door からの移行は今後数か月以内に対応されるようなので、準備が整った時点でサクッと移行するのが良いでしょう。CDN 周りの移行は DNS レベルで簡単に切り替えできるので、さっさとやっておくのも手です。 Azure Portal から作成する際には新しい Front Door とこれまでの Front Door / Azure CDN

技術部プラットフォームグループ SRE の akichan です。 私が所属する技術部プラットフォームグループは SUZURI や minne といったサービスごとにある事業部に所属しないサービス横断のSREの集団です。運用の効率化、サービスレベル目標を達成できるようにするための支援を行っています。 今回はペパボのSREが普段利用している便利なツールの紹介を通し、具体的な業務の内容について知っていただこうと思います。 Kubernetes関連 SRE は各サービス事業部のKubernetesクラスタの管理者でもあります。 日常的なクラスタの維持管理や、トラブルシュートに対応します。 stern sternは複数のPodのログをまとめて見ることができるツールです。 kubectl logsを使ってPodのログをみる場合、Podの正確な名前を指定する必要があり手間です。 sternはPod名の

インフラ初心者がいきなり実務でKubernetesを使うことになったので、その学習記録✎ 流れとしては、 概念的なところを抑える 実際に手元で動かしてみる です！ また、すでにKubernetesについて書かれたわかりやすい記事がたくさんあるので、本記事はそれらをもとに自分の理解をまとめたものになります。 概念的なこと まずはこれで概要把握 まずは👇を読もう。（ありがたやありがたや...） 僕らは何故Kubernetesを使うのか Kubernetesというものが出てきた背景を、オンプレの時代からどういうふうに変わっていったかわかる KUbernetesの概要がわかる メリデメがわかる Argo CDの例などを用いてどういうふうに使われているのかイメージが付く Kubernetesとは ざっくりいうと、 サービスをコンテナ上で動かすようになったことで起こった、 複数のサーバ上で複数のコン

※岡本、正野、宇都宮はNTTデータ所属 Kubernetesやクラウドネイティブをより便利に利用する技術やツールの概要、使い方を凝縮して紹介する本連載「Cloud Nativeチートシート」。第13回から「Observability（オブザーバビリティ）」「可観測性」にフォーカスしています。第13回ではObservabilityの概要と、その構成要素や考慮点を、第14回ではそれを活用したトラブルシューティングフローを紹介しました。 第15回となる今回は、最もベーシックなObservabilityのシグナルであるメトリクスにフォーカスして、デファクトスタンダードなオープンソースソフトウェア（OSS）「Prometheus」「Grafana」に関連したポイントを紹介します。 1章：Prometheusの概要 連載第13回で説明したように、「メトリクス」は、サーバのリソース状況（CPU使用率など