Upgrade to Pro — share decks privately, control downloads, hide ads and more …

freeeにおける Kubernetes監視基盤

freeeにおける Kubernetes監視基盤

JAWS 2019 セッション "EC2からKubernetesへの移行をセキュリティ/モニタリングから考える"の後半部分です。

前半はこちら
https://speakerdeck.com/eijisugiura/ec2karakuberneteshefalseyi-xing-wosekiyuriteikarakao-eru

Atsushi Kawamura

February 23, 2019
Tweet

More Decks by Atsushi Kawamura

Other Decks in Technology

Transcript

  1. 8 なぜ監視をするのか • 予防保守 ◦ 近い将来起こり得る問題を監視システムで救い上げる • 異常検知 ◦ サービス・ビジネスの継続に係る障害の場合、最速で復旧させる必要がある

    ◦ そして少なくとも、発生している問題にすぐに気づけることが重要 • 改善指標 ◦ 何か新しい施策を入れたとしても、metricsが取れていなければ効果を測れない
  2. 9 監視システムに求められるもの • 必要なコンポーネント ◦ データ収集 ◦ ストレージ ◦ 可視化

    ◦ 分析 ◦ アラート • 正しい監視をする • コスト • 継続的改善が可能
  3. 10 Kubernetesでの監視要件 • 監視対象 ◦ クラスタ、クラスタノード、pod • 多様性 ◦ podが大量(pod

    ≒ process)かつ多様 ◦ 個別に設定をいちいち入れていくのは無理 • 自動スケール ◦ ノードもpodも自動でスケールする ◦ 監視システムも自動で追従しないとつらい
  4. 13 Elastic Stack - コンポーネント • Data store … Elasticsearch

    • Visualize … Kibana • Etl tool … Logstash • Data Collector … Elastic Beats
  5. 15 Elastic Stack - SaaS • Elastic提供のElastic Cloud ◦ 最新のreleaseに追従、新機能をすぐ使える

    ◦ 3rd Party pluginが使える ◦ X-Pack(有償機能)が使える ▪ 全機能の有効化は追加ライセンス必要 • AWS提供の Elasticsearch Service ◦ 上記のElastic Cloudのメリットがない代わりに低コスト ◦ IAMやSG、CognitoといったAWSの機能を活用できる ▪ freeeでは現状こちらを利用
  6. 19 filebeat • Lightweight Log Shipper • sourceとログ送付先のoutputが基本設定項目 • k8sクラスタでは`kubectl

    logs`コマンドで取得できるログを簡単にoutput先に送れる https://kubernetes.io/docs/concepts/cluster-administration/logging/ Kubernetes公式のlogging architecture解説図 - filebeatはログエージェントとして各ノードにdaemonset で配置 - ノードが増えたら自動で配置 - 各podのログファイル(標準出力先)を監視し、設定さ れたバックエンドに送付する - アプリケーション側は特に設定不要 - 個別設定不要(入れても良い)
  7. 20 filebeat 設定と導入 • helm chartあります $ helm upgrade --install

    filebeat stable/filebeat -f values.yaml $ helm list | grep filebe filebeat • 簡単! ◦ elasticsearchのsetupは省略 config: filebeat.prospectors: - type: log enabled: true paths: - /var/log/*.log - type: docker containers.ids: - '*' processors: - add_kubernetes_metadata: in_cluster: true - drop_event: when: equals: kubernetes.container.name: filebeat output.file: enabled: false output.elasticsearch: hosts: ["https://<elasticsearcht>"] username: “xxx" password: "yyy" rbac: create: true values.yaml
  8. 22 metricbeat • Lightweight Shipper for Metrics • 基本的にはfilebeatと同じくnode毎に配置にエージェントとして配置され、メトリクスを収集する •

    クラスタメトリクスの採取は別途`kube-state-metircs`のデプロイが必要 • メトリクスとしてはnode/pod単位のcpu/memory/network/storage、などが取得できる
  9. 23 metricbeat 設定と導入 • helm chartあります $ helm upgrade --install

    filebeat stable/metricbeat -f values.yaml • 簡単! ◦ values.yamlは取得metricsに応じて設定がだいぶ膨ら むのでかなり省略しています ◦ クラスタメトリックを取る場合は ▪ kube-state-metricをhelmでインストール ▪ deploymentのmodules設定に取得設定を追加 daemonset: config: json.keys_under_root: true json.ignore_decoding_error: true output.file: enabled: false output.elasticsearch: hosts: ["https://<elasticsearcht>"] username: “xxx" password: "yyy" modules: modules: system: enabled: true config: - module: system period: 10s metricsets: - cpu - ... deployment: config: <daemonsetと同じ設定> modules: <取得対象metrics設定> values.yaml
  10. 27 Kinesisでの中継 • Kinesisの役割 ◦ ログを確実に送るための中継 ◦ ログの送付先選択・加工に拡張性をもたせる ▪ ここではElasticsearchとS3に送付する構成

    ▪ 必要であれば送付先を増やしたり、lambdaを間に挟んで加工したりすることも可能 • Kinesis送付のための設定 ◦ filebeat/metricbeatの送付先としてkinesisはデフォルトに含まれていない ◦ 追加のログ送付先(output)はpluginとして拡張可能 ◦ ここではawsbeatsというOSSを使用
  11. 28 アラート • ログを取るだけでは片手落ち、アラートを設定しましょう • AWS Elasticsearch Serviceで提供されるElasticsearch, KibanaにはAlert機能がない ◦

    Elastic社の提供する有償パッケージ(X-Pack)にはKibanaに統合されたAlert機能あり ◦ Elastic Cloudを契約すれば使えます • 一旦OSSでできることを模索 ◦ ElastAlertを導入 28
  12. 29 elastalert • developed by Yelp ◦ https://github.com/Yelp/elastalert • 何ができるのか

    ◦ elasticsearchに対してクエリを投げて、条件にマッチした場合にアラートを投げる ◦ 通知方法は色々。とりあえずslackへ
  13. 30 elastalertの構築 • 構築方法1: k8s cluster内にdeployする ◦ helm chartがあるので導入は容易 ◦

    課題 ▪ cluster単位障害で巻き込まれる ▪ ruleの管理・渡し方 • CRDを定義し、operatorごしに渡すなど検討 • 構築方法2: AWS lambdaにデプロイし定期起動 ◦ https://github.com/beezz/elastalert-lambda ◦ 課題 ▪ ルール数に合わせて起動頻度の見直しが必要 ▪ 新しいルールを追加するのにlambdaをbuildしなおす必要 • 構築方法3: AWS ECSにデプロイ ◦ https://hub.docker.com/r/bitsensor/elastalert/ ▪ 半公式のrest api付きelastalertのdockerfileが公開 ◦ これを元にECS上で動作させる ◦ 今はこちらを検証しています アラート
  14. 31 elastalert 例 • 一定頻度以上に指定のwordがログにあればalert • filterにはKibanaのquery(lucene)が使える • alert先はslackを始めいくつか用意されている 公式のrest

    api付きdocker imageだと、 • ルールのテスト、投入 • 存在するルールやステータス確認 ...などができます # Alert when the rate of events exceeds a threshold name: OutOfMemoryError type: frequency index: logstash-%Y.%m.%d* use_strftime_index: true num_events: 1 timeframe: hours: 1 filter: - query_string: query: "message: OutOfMemoryError OR log: OutOfMemoryError" alert: - "slack" rules.yaml
  15. 33 良かったこと • 導入が楽 ◦ agentはhelm chartが用意されており、環境に合わせて設定を書き換えればすぐ入れられる ◦ バックエンドは共通なので、一度構築すれば同じデータフローに乗ってくれる •

    logとmetrics管理を共通化 ◦ バックエンドが同じ(elasticsearch + kibana)なので、同じ感覚で参照できる • Kibanaの柔軟なクエリ(lucene)で大体のVisualizeはできる • 同じくluceneを使ってフィルタをかけるelastalertも、大体のことはできる
  16. 34 微妙だったところ • Kibanaのvisualizeはまだexperimentな機能がいくつか • Visualize/Dashboardのアイテムを作るのがなれるまで難しい ◦ luceneが自由度高すぎて逆に難しい ◦ metricbeatからsetupコマンドで作れるが、必要十分でない(おおすぎ)

    ◦ ダッシュボードのexport/import機能でなんとか乗り切れるか • ElastAlertは設定難易度高い ◦ 単純に複雑 ◦ 正しく書けているか検証し辛い、testコマンドあるが遅い(ログ検査範囲が1日単位) ◦ ルールの管理方法は検討要 • beats系でたまにバグを踏む(修正は早い ◦ kinesis送付plugin(awsbeats)を公式が取り込んでくれると嬉しいlogstashからkinesisはある) • 監視システム自体の監視 ◦ elasticsearchの容量枯渇や、kinesisの設定ミスによる詰まり ◦ ログ基盤の死活監視もまた必要
  17. 35 今後 • elasticstackをそのまま使うかもしれないし、他の方法に変えるかも知れない ◦ 導入が簡単で、かつ、コンポーネント単位での置き換えが容易な構成の強み ◦ 運用中での改善・試行錯誤がしやすい • 他のデータ収集ツールの導入

    ◦ apm serverやheart beat等を入れて監視を強化 ◦ 基本的に今のアーキテクチャ(elasticsearch + elastalert)であればスムーズに組み込める • 権限委譲の仕組みをすすめる ◦ ダッシュボードやアラートルールなどをテンプレ化して、新規作成を容易にする ◦ CIを整備して、誰でも簡単に機能追加できるようにする
  18. 39 他のソリューションとの比較 • Elastic Cloud ◦ 少し高い、アラートついてる、最新機能使える、plugin入れられる • fluentd ◦

    ログだけ ◦ ログに色々加工ができる ◦ helmある ◦ バックエンドは選択可能(s3なりelasticsearchなり) • mackerel ◦ helmない ◦ kubernetesは最近対応 ◦ 有料、バックエンドは固定(マネージドサービス)
  19. 40 他のソリューションとの比較 • prometheus ◦ helmある ◦ ログはとれない ◦ exporterだけprometheusにしてバックエンドはelasticsearchとかもできる

    ▪ metricbeatがprometheus end pointに対応している ▪ grafanaやprometheus serverを用意する場合は自前運用必要 • grafanaはプリセットの設定がいい感じな気がする • それぞれについてもhelmある。k8sクラスタ内で導入するなら案外楽かも • data dog ◦ fluentd + data dog logs使えばログとメトリックの統合管理も可能 ◦ agentはhelmある ◦ 有料 ◦ ちゃんと触れていないので、後日トライアル版触ってみたい… ありふれた教訓ではあるが、無料であることは必ずしもメリットではない(最終的に何にコストを払うか
  20. 41 Elastic Stack vs. Prometheus • push / pull ◦

    agentとexporter • 導入はどっちも簡単 ◦ helm chartあり • 高い汎用性 vs. メトリクス監視特化 • マネージドサービスあり、なし • lucene、PromQL • elastalertでのalert作成は結構しんどい(グラフを見ながら設定したりできない) grafana お試し https://play.grafana.org/d/000000012/grafana-play-home?orgId=1