GCP関連のモニタリングを俺なりに検討してみる

2 年 ago
新, 韵
2 minutes

我可能是个懒人。当我想到“如果监控系统坏掉了，警报没有响起会怎么办？”和“要运作多少种不同的系统？”时，我就不想自己来运作监控系统。

因此，我将使用我擅长的Datadog来探索Google云平台能够监视到的范围。

Datadog是GCP合作伙伴生态系统的成员。

根据2014年11月4日的新闻稿，Datadog加入了Google Cloud Platform合作伙伴生态系统，以便在大规模上监控基础设施和应用程序。他们宣布了与GAE的集成，可以轻松开始监控。

僕の記憶を紐解くと、GCPは、5月にStackdriver購入していたと思う。このタイミングでなぜDatadogをパートナーエコシステムに加えのかも興味深い動向のような気がする。僕は、「GCPとして各部品を統合的に監視できるサービスを早急に用意しておく必要があった。」のではないかと個人的に思っている。そして僕は、GAEをGoogleのコンソール以外から監視できるサービスをDatadog以外から見つけることができなかった。(検索不足かな〜….)

就Docker（谷歌容器引擎）来说，

Dockerに関していうと、GoogleによってContainer Advisor (cadvisor)を公開しているものの、単独でメトリクスが取れるだけで他の監視情報と連携して監視ができるとは言い難い状況ではないかと推測する。(間違っていたら、是非ご指摘ください。)

进一步观察受到应用层工程师喜爱的New Relic的情况，发现如果不在各个独立的容器中安装New Relic代理，就无法收集到各个容器内的信息。

查看Datadog的当前情况，有三种方式可以收集容器的度量指标。

1.Datadog Agent 専用コンテナをメトリクス収集
2.各独立したコンテナー内とホストOS上にインストールしたDatadog Agentによるメトリクス収集
3.Docker Engineが動作している、ホストOS上にインストールしたDatadog Agentでプリビレッジモードを使ってメトリクス収集

このように柔軟に対応できるのはDatadogが独自に持っているAPI群に加えて、Etsyが公開しているStatsdのfork版を、Datadog Agentに内包しているからである。

[1个案例和2个案例] (Yī gè ànlì hé èr gè ànlì)

Traditional-2.png

[情况3]

DockerImage1.png

从选择第一种和第三种方法的角度来看，感觉Datadog是一个具有优势的选择。尽管对于Docker容器监控的收费方式尚未确定，但由于可以自由选择安装Agent的配置，因此可以实现最大程度的费用削减。

Datadogが持っているGCP Integrationsを調べて見る。

DatadogのIntegrationには、 **既にDocker, GAE, GCPのインテグレーションが準備されている。 **Datadogのダッシュボードから、ボタンをクリックして最小限の設定を追記するのみで、数分以内には監視が始められるのである。早急に、Google Contener Engine専用のIntegrationが公開されるのを期待したいものだ。

gcp-integration_1.png

この赤枠で囲ったGCPのインテグレーションを使えば、GCPで集めたメトリクスと、他のイベント情報(例えば:github, その他)やミドルウェアから集めたメトリクスを同じ画面で見ることができる。

请参考”Datadog的真正魅力”，通过汇集指标和事件，并利用标签来实现基础架构的深入查看。

探访Google App Engine的监控服务。

我个人一直以来与GAE=松尾＝Python有着某种深厚的历史渊源，但是从Google运营的角度来看，我从来没有考虑过对GAE进行监视。更进一步说，我从来没有想象过可以利用标签将GAE的状态与周边事件叠加起来进行监视。

どのような情報が集められるのかなと思いソースを覗いてみると次のものが取れそうだ。

    • project_name

 

    • datastore

 

    • memcache

 

    • task_que

queue_name
tasks
oldest_eta_usec
executed_last_minute
in_flight
enforced_rate

request

start_time
api_mcycles
cost
finished
latency
mcycles
pending_time
replica_index
response_size
version_id

とりあえず、Datadogのblog記事を基に使い方を見ていくことする。”Setup and configuration”の部分に3ステップに分かれて手順が書かれ、最も重要な部分が端折って書かれているが、Datadogへのユーザー登録後に実際に必要なステップは、以下の通りである。

1. 在Datadog的仪表板上，点击”Integrations”标签 -> “Integration”下拉菜单 -> 移动到”Google App Engine”板块，并将光标放在”Available”上，然后点击。
2. 在弹出窗口中选择”configuration”标签，并按照指示中的说明进行设置工作。

Screen Shot 2014-12-14 at 00.46.23.png
    • DatadogのGAEモジュールをgithubから取得する。

 

    • GAEのapp.yamlに、datadogのhandlerの記述を加える。

 

    GAEのapp.yamlに、Datadoへメトリクスを送信するために必要なAPIキーの情報を書き込む。

3.アプリケーションのURLをポップアップのDatadog endpoint URLの部分に入力する。
4.Task queuesの情報を、Task queues (comma separated)の部分に入力する。
5.Install Integrationボタンをクリックする。

如果能够进行到这一步设置，在datadog的仪表板上选择“仪表板”选项卡->“仪表板列表”下拉菜单，并在右侧的“集成仪表板”列中显示Google App Engine，然后双击它以显示屏幕仪表板。

GAE-Dashboard-Final.png

先に示した一般的に収集できる情報以外に、アプリケーションから直接収集したメトリクスを送信したい場合は、DogStatsDかdatadogのAPIライブラリーを使って、Datadogのサービスへ送信することができます。

以下是一个在Python程序中通过DataDog API发送指标的示例。这个示例是一个简单示例，它会持续发送值为1000的指标到名为”page.view”的标签。

from dogapi import dog_http_api as api

api.api_key = 'YOUR_API_KEY'
api.application_key = 'YOUR_APPLICATION_KEY'

# Submit a single point with a timestamp of `now`
api.metric('page.views', 1000)

#see more examples here: http://docs.datadoghq.com/api/

ここまで、表示されれば、Datadogの機能を使ってGAEのメトリクスを基にアラートを設定したり、他のイベント情報と重ねわせて表示しつつ、GAEで動いているアプリの状況をより詳しく把握できるようになりました。(重ねわせて把握するところは、別の機会に詳しく書くとします。)

探索Google Cloud Platform的监控之旅。

這一部分，我已經確認了專用儀表板的存在以及每個實例的指標都可取得，但為了將其作為部落格文章，我認為還需要花一些時間進行驗證，因此這次就不再寫下去了。（請期待後續內容。）

参观Docker（Google容器引擎）的监控。

在搜索过程中，我深切感受到与我撰写文章相比，参考Qiita上的”Docker与Datadog”的Howto集要好得多。请务必查看下面的网址链接。

[Docker DataDog的搜索结果]

总结

昨今、GAEとDockerの部分がIntegrationで簡単に監視がスタートできれば、GCEに関しては各インスタンスにDD-agentをインストールし、ミドルウエア用のIntegrationを設定すれば、GCPが出しているインスタンスのメタデータさえとれれば、それ以降はホストタグを使った紐付けになるような気がする。(調べ終えていたいので、断定的には発言することはできないが…)

尽管如此，时间不可避免地紧迫感弥漫着。

虽然这是一个很好的机会，但没有深入探讨GCP集成，非常遗憾。所以，我打算重新调查并撰写一篇关于如何在基于GCP基础设施上有效使用Datadog的文章。

我真心希望大家能在2014年迎来美好的圣诞节。

✖
广告
将在 10 秒后关闭
bannerAds