datadog で snmpコレクタを利用して監視をしようとして諦めた話。

背景

datadogというSaaSのモニタリングサービスがあります。

エージェントを対象に入れてデータを送るpush型モデルなのですが、ホストの情報だけでなく、様々な方法でメトリクスを取得できるよう担っており、その中にsnmpも存在しています。

ホスト監視のためにエージェントを入れていたので、ついでにネットワーク機器もまとめて監視できると嬉しいなと思い立ちました。

試したこと

https://docs.datadoghq.com/integrations/snmp/ にあることを一通り。

単一メトリック

OIDと名称(任意に指定可能)を指定して取得できます。

テーブル

MIBを用意してMIBとテーブルを指定、さらにテーブルのどれを取得するか選べます。 また、メトリックにテーブル内の値を任意のタグとしてつけることができます。

できなかったこと

OIDを指定したテーブル取得

OIDを利用する場合は、単一メトリックとして、最初に得られた値が利用されます。

他のテーブルの値をテーブルのタグとして利用

わかりやすくいうとifXTableにあるifHCInOctetsにifTableにあるifDescrを利用したいというようなケースです。

この場合はifTableにあるIfInOctetsを利用するか、ifXTableにあるifNameを利用すれば良いのですが、そのほかにも似たようなケースがあり、いい感じのタグがつけられませんでした。

結局どうしたのか。

prometheusのコレクタがあるので、snmp_exporterを利用しました。

datadog側でデータの取得元をsnmp_exporterにして取得する形です。

phpcon 2018にNOCとして参加した

phpcon 2018NOC(NetworkOperationCenter)要員として参加してきました。

phpcon 2018 NOC では、

  • Server
  • Network
  • WiFi

の3チームがあり、Serverチームの一員として参加しました。

テクニカルなところ

Serverチームで運用したものとして

くらいのものがあります。このうち、私が作成したのはDHCP、Monitorです。

DHCPでは、ISC DHCPdではなくISC Keaを利用するという個人的なチャレンジをしました。

MonitorではZabbix 4.0系をDockerイメージを利用して作成しました。4.0を触れたのと公式に提供されているDockerイメージの利用方法を知ることができました。

Monitorでは他に、Procmetheusもたてられており、こちらも会期中は特に不具合なく運用できていました。

logについては、開始直後はsyslogサーバにデータをためているだけでしたが、途中でElasticsearch+Kibanaで見られるようにだけはしました。(見たとは言ってない) おおむね、30秒で4万程度のログがsyslogサーバに集約されていました。

ログの提供元は会場のスイッチ、ルータ、それからクラウド上にあるWirelessLanController、サーバです。

基本、サーバが落ちることもなく大きな問題もなく終えることができました。

チームとしての感じ

NOC自体が、楽しくやろう。というような緩い感じだったので、結局誰が何をやるのかというのが最後までぼんやりしている感じでした。

実際に人があつまるミーティングでは、何を使いたいか?どのOSを使いたいか?という事をゆるく話をしたきり、特に決めるわけでもなく解散。オンラインでも誰が何を作るのか決めたりはせず。というゆるゆるな感じで、これで何とかなるもんなのかな?と疑問に思いつつ過ごしていましたが、なんだかんだで当日にはきちんと最低限提供すべきものは提供できており、会期中に突貫でちょいちょいものが作られていくという不思議な時間を過ごせました。

当日

NOCスペースにディスプレイが置かれ、Dashboardが見られるようになっていたので、興味を持った方がちょいちょい立ち止まって見たり、そばにいる人に聞いたりしてくれて、そこは良かったなぁという感じです。

ですが、一般公開もできる用意がしてあったのに、何の告知もしていないため、公開されてはいたけれど、誰もみてないのでは?みたいな気持ちでそこはもっとアピールしても良かったのかなと思っています。 ただ、アピールするということは当日突貫でものが作られていく、みたいなのはちょっと、さすがに、申し訳ない気もするので、こう、自己満足と楽しみを提供するというところの狭間で今のところ、自己満足で終わっているような気がしました。

当日のトラブルとして、無線の提供ができなくなる回数が3度ほどありました。初回は目撃できていないのですが、2回目、3回目はともに撤収を順次行っている際に、会場のアップリンクケーブルが誤って抜かれるという事が起こりました。 当日、物理的にどういう構成でどこが重要なのか、もう少しすり合わせをしておいた方が良かったんだろうなという反省です。(とはいえ最後のものは、NOCメンバーでない人が片づけ中にやってしまったものなのでどうしようもなかったとも言える)

感想

ちょこちょこ感想を交えて書いてきたのであんまりないのですが、今回、NOCとして初めて参加して、どうやって会場無線LANを提供しているのが、その全貌が見られてよかったです。また、その構築に準備段階からかかわっていけたのも良い経験になりました。もし次回以降があれば、今回得られたものを活かして、より良い感じにしていけたらと思います。

Ansible AWX でSAML SSO してみた

概要

Ansible AWX でSAML SSOしたときにちょっとつまずいたのでメモを残す。

環境

docker を利用して構築しました。バージョンは2.1.0 イメージは

普通に上記イメージを利用して構築すると、AWX のWebUIはコンテナ内で8052ポートで待ち受けます。

ここに443ポートで待ち受けるロードバランサから接続する割と一般的かな?と思う構成です。

つまずいた点

とても単純で、IdP側に設定をして、いざSSOしてみると https://<awxhost>:8052 instead of https://<awxhost> とメッセージが出るわけです。 つまり、 443ポートに着信してしかるべきなのに、8052ポートに着信してるからおかしいよと警告が出るんですね。

解決策

これを修正すべく、docker run時に -p<外部公開ポート>:443 とし、コンテナ内のnginxの設定を 443ポートでhttpを待ち受けるように設定しkill -HUP nginx で設定をリロードすることで、コンテナ内に着信したとき、ちゃんと443ポートが利用され、事なきを得る事が出来ました。

中期的にはDockerfileを作成し、上記修正をいれたイメージをビルドして利用することで解決できそうです。

根本的には、ちゃんと原因をつかんで修正することが大事だと思いつつ、時間がないのでそこは手を出せていません。

ちなみになんですが、ポート番号が変になることを承知の上で awx/nginx.conf at devel · ansible/awx · GitHub X-Forwarded-Port 443が設定されているのですよね。

この設定をアプリケーション側がちゃんと読んでいないのでは?と疑っております。