designetwork

ネットワークを軸としたIT技術メモ

LogstashでFluentdのforest+copy同様に複数処理の設定をする

f:id:daichi703n:20170409131212p:plain

LogstashでFluentd(td-agent)のforestプラグインとcopyを組み合わせたものと同様の設定をしてみる。これにより、ログ種別、送信元が増えていっても出力設定を都度追加することなく、簡素化できる。

また、Logstashは日本語情報が少ないため、少しでも日本のユーザーとして普及に貢献したい。

期待する動作・Fluentdでの設定例

Fluentd(td-agent)でtag変数を元に、forestで処理する汎用的な設定をする。Fluentdでの設定イメージはこちらの通り。Chunk、Bufferなどの最適化は未実装。

ベース設定。個別の設定ファイルをincludeする。検証バージョンはtd-agent 0.12.31

/etc/td-agent/td-agent.conf

<source>
  @type forward
  port 24224
</source>

@include ./conf/*.conf

シンプルにローカルのログファイルを取り込む。ここで設定するtagをElasticsearchのindexなどに使用する。

/etc/td-agent/conf/local_messages.conf

<source>
  @type tail
  path /var/log/messages
  pos_file /var/log/messages.pos
  tag "sys.messages.#{Socket.gethostname}"
  format syslog
</source>

Elasticsearchへの送信設定。バックアップ・長期保存のためにファイルとしても保存する。forest+copyを使用することで、tagを変数として取り込んでindexやファイル名に使用できる。

/etc/td-agent/conf/elasticsearch.conf

<match *.*.**>
  type forest
  subtype copy
  <template>
    <store>
      @type elasticsearch
      host localhost
      port 9200
      logstash_format true
      logstash_prefix ${tag_parts[0]}.${tag_parts[1]}
      type_name ${tag_parts[0]}
      flush_interval 20
    </store>
    <store>
      @type file
      path /var/log/td-agent/${tag_parts[0]}/${tag_parts[1]}.log
      compress gzip
    </store>
  </template>
</match>

forestプラグインはこちら。

これにより、新規のログ種別が増えてもmatchディレクティブの中には追加の設定が不要になる。複数のログを複数のサーバからそれぞれ収集・集約したいときに効率が良い。

Logstashでの設定例

Logstashのバージョンは5.3.0で試験する。

$ /usr/share/logstash/bin/logstash --version
logstash 5.3.0

/etc/logstash/logstash.ymlpath.config: /etc/logstash/conf.dの設定がされていることを確認する。(デフォルトのため問題ないはず)

Logstashでのforest+copyは次のような設定になる。パーツごとに区切って解説するが、設定は/etc/logstash/conf.d/messages.confとして一つのファイルにまとめてよい。

inputでtagsを付与してFluentdと同様にtagで振り分ける。sourceディレクティブに相当する部分。%{host}環境変数を参照するため変更不要。なお、Fluentdに沿ってtagを使用したが、idtypeなど、他のフィールドを使用することもできる。

input {
  file {
    path => "/var/log/messages"
    tags => ["sys", "logstash_messages", "%{host}"]
    type => syslog
  }
}

filterで正規表現によるindex付け、日付の処理をする。FluentdだとSourceディレクティブ内のformatdate_formatに該当する部分。filter単体で動作するため、inputで取り込んだ複数のログに適用される。そのため、ifでフィルタ対象を限定する。

filter {
  if [type] == "syslog" {
    grok {
      match => { "message" => "%{SYSLOGTIMESTAMP:syslog_timestamp} %{SYSLOGHOST:syslog_hostname} %{DATA:syslog_program}(?:\[%{POSINT:syslog_pid}\])?: %{GREEDYDATA:syslog_message}" }
      add_field => [ "received_at", "%{@timestamp}" ]
      add_field => [ "received_from", "%{host}" ]
    }
    date {
      match => [ "syslog_timestamp", "MMM  d HH:mm:ss", "MMM dd HH:mm:ss" ]
    }
  }
}

outputでelasticsearchとfileにそれぞれ出力する。Fluentdのmatchディレクティブに該当する。Logstashではcopy、forestといったプラグインを使用せず、シンプルにoutput内で複数出力、変数使用ができる。同一サーバでElasticsearchを動作させている場合のサンプルのため、環境に合わせてhostsを変更する。

なお、<match <tag1>.<tag2>.*>といった指定をしないため、出力形式を共通化する必要がある。

output {
  elasticsearch {
    hosts => ["localhost:9200"]
    index => "%{tags[0]}.%{tags[1]}-%{+YYYY.MM.dd}"
  }
  file {
    path => "/var/log/logstash/%{tags[0]}/%{tags[1]}.log"
  }
}

出力結果

tags変数が展開されindexとして使用されている。

$ curl http://localhost:9200/sys.logstash_messages-*
{"sys.logstash_messages-2017.04.09":{"aliases":{},"mappings":{"syslog":{"properties":{"@timestamp":{"type":"date"},"@version":{"type":"text","fields":{"keyword":{"type":"keyword","ignore_above":256}}},"host":{"type":"text","fields":{"keyword":{"type":"keyword","ignore_above":256}}},"message":{"type":"text","fields":{"keyword":{"type":"keyword","ignore_above":256}}},"path":{"type":"text","fields":{"keyword":{"type":"keyword","ignore_above":256}}},"received_at":{"type":"date"},"received_from":{"type":"text","fields":{"keyword":{"type":"keyword","ignore_above":256}}},"syslog_hostname":{"type":"text","fields":{"keyword":{"type":"keyword","ignore_above":256}}},"syslog_message":{"type":"text","fields":{"keyword":{"type":"keyword","ignore_above":256}}},"syslog_program":{"type":"text","fields":{"keyword":{"type":"keyword","ignore_above":256}}},"syslog_timestamp":{"type":"text","fields":{"keyword":{"type":"keyword","ignore_above":256}}},"tags":{"type":"text","fields":{"keyword":{"type":"keyword","ignore_above":256}}},"type":{"type":"text","fields":{"keyword":{"type":"keyword","ignore_above":256}}}}}},"settings":{"index":{"creation_date":"1491720002393","number_of_shards":"5","number_of_replicas":"1","uuid":"AO_MMCiqQYqcNIIEG8XmQg","version":{"created":"5020299"},"provided_name":"sys.logstash_messages-2017.04.09"}}}}

ファイルアウトプットも同様、tags変数が展開され、tag情報に基づいてディレクトリ、ログファイルが作成された。

$ tree /var/log/logstash/
/var/log/logstash/
├── logstash-plain.log
└── sys
    └── logstash_messages.log

まとめ - LogstashでFluentdのforest+copy同様に複数処理の設定をする

LogstashでFluentdのforest+copy同様の設定をした。これにより、ログ種別、送信元が増えていっても出力設定を都度追加することなく、簡素化できる。

GrafanaでElasticsearchのデータを表示する

f:id:daichi703n:20170404012051p:plain

Elasticsearchのデータ・ログ可視化ツールとしてはKibanaが用意されているが、ZABBIXなどのデータを組み合わせてGrafanaでダッシュボードを作りたいときもある。使い始めとして、GrafanaのデータソースとしてElasticsearchを連携させる設定方法を記載する。

KibanaとGrafanaの使い分け

はじめに簡単に私のKibanaとGrafanaの使い分け。

Kibana:検索・抽出(詳細)

こちらの記事に書いたとおり、Kibanaの拡張版を使用すればDiscoverタブでの検索結果をCSVにエクスポートすることもできる。

Grafana:ダッシュボード(概要)

ひと目で現在の稼働状態を監視するためのダッシュボードとしての使用がメインと考えている。また、データソースとしてInfluxDBをはじめ、ZABBIXPrometheusといった統合監視など多彩なプラグインが用意されているため、ひとつの画面で多くの情報を集約できる。

Grafana・Elasticsearchインストール

割愛します。YumリポジトリやオフィシャルDockerもあるため導入は簡単。ログ収集はFluentd(td-agent)、Logstashどちらでも問題なし。

Grafana Data Sources

ElasticsearchをGrafanaのData Sourcesとして追加する。次の通りType:Elasticsearchを選択しURLを入力する。Nameは任意。AccessはProxyにするとGrafana自身がデータを取得しにいく。

f:id:daichi703n:20170404005617p:plain

Indexを入力する。通常だとPattern: Dailyとして[<logstash-prefix>-]YYYY.MM.DDとする。

f:id:daichi703n:20170404005823p:plain

なお、Pattern: No patternで<logstash-prefix>-*としても動作するが、オフィシャルではYYYY.MM.DDでの設定方法が記載されている。

f:id:daichi703n:20170404005928p:plain

Addで登録するとDatasource addedと表示される。

f:id:daichi703n:20170404010015p:plain

注意:設定が誤っていても登録は完了される。ダッシュボードでログが正常に読み込まれない場合は設定を再確認する。また、Grafana v3.xではES v5.xを未サポート。

ダッシュボード作成

Graphを作成する。Panel data sourceで連携したElasticsearchのインデックスを指定し、Metric: CountGroup by: Date Histgramとすると、ログ数のグラフが表示される。

f:id:daichi703n:20170404010810p:plain

TableからMetric: Raw Documentとして生ログを表示することもできる。

f:id:daichi703n:20170404010907p:plain

なお、JSONデータはカラム指定で表形式で表示することができる。

f:id:daichi703n:20170404011000p:plain

複数指定することで必要な情報を並べることができる。

f:id:daichi703n:20170404011111p:plain

パネル作成時にクエリ指定することができるため、あとはカスタマイズしていく。Kibanaとの差別化ができていないが、FWのアクセスログだけでもそれなりのダッシュボードを作成することができる。GEO IPなどを使ってさらにカッコ良くしたい。

f:id:daichi703n:20170404011358p:plain

まとめ

GrafanaにElasticsearchのデータを取り込むことができた。各種クエリも継続使用できるため、柔軟性は高く、用途に応じたダッシュボードを作成することができる。

Fluentd(td-agent)でCisco ASAのFWログを可視化する

f:id:daichi703n:20170403001540p:plain

ログ収集ツールとして人気の高いFluentd(td-agnet)でCisco ASAのFWログを可視化する。Fuentdで受け取ったログはElasticSearchでインデックスしKibanaで可視化する。

Fluentdプラグインと設定

Fluentdのプラグインで既に作成していた方がいたので使ってみる。

github.com

このFluentdプラグインは残念ながらtd-agent-gem install fluent-plugin-cisco-asa-parserではインストールできない。そのため、/etc/td-agent/plugin/配下にparser_cisco_asa.rbを配置する。

私の環境では汎用性を高めるためにforestプラグインを使用している。

td-agent-gem install fluent-plugin-forest

ログの読み込み設定は以下の通り。転送設定は適宜。

<source>
  @type tail
  path /var/log/ASA5505.log
  pos_file /var/log/ASA5505.log.pos
  tag net.asa5505.CentOS-01
  format cisco_asa
</source>

Cisco ASAログ出力設定

Cisco ASAのログ出力設定は以下の通り。(抜粋)

使用機器はCisco ASA5505 OS:9.2(3)。ASA5505に特化した設定ではなくASAシリーズ全般で同様設定になる。

logging enable
logging timestamp
logging trap informational
logging host management 192.168.1.60

ログ収集できず…

上記のプラグインでは、私のASAでのログフォーマットには合致せず(pattern not match)、ログ収集されなかった。

そのため、プラグインを自分でメンテしていこうと思う。

自作Cisco ASA Parser

こちらで継続メンテしていく。作成中のため商用利用はしないでください。既存で同様プラグインありましたら教えてください。

github.com

現状でもこのように各種情報を拾える。Elasticsearch + KibanaのDiscover画面の抜粋。

f:id:daichi703n:20170403001908p:plain

Kibana 5でDiscoverタブの検索結果をCSVエクスポートする

f:id:daichi703n:20170327005406p:plain

Kibanaで要望されつつもなかなか実装されない機能の一つに、Discover画面からのエクスポートがある。Githubでもissueとして長期的に要望されている。

github.com

その中で、次の通り機能実装版を提供してくれている方がいる。

If you are adventurous enough, you can implement it yourselves. It is fairly simple. For example this commit for version 5.1. Build instructions here.

Here is the screenshot:

f:id:daichi703n:20170326234449p:plain

今回は機能追加版のKibanaをビルドして動作確認をした。また、より簡単に導入できるようDockerコンテナを作成したので公開する。

前提条件

本記事の前提条件・知識は以下の通り。

  • Elasticsearchをインストールして使用している。
  • Kibanaの設定変更箇所が分かる。
  • Dockerを通常使用できる。

ちなみに、私はDocker歴が非常に浅いため至らない点が多いですがご了承ください。また、本記事ではKibana5.2.3を使用していますので、Elasticsearchのバージョンも合わせる必要があります。

公開手順でビルドする

公開いただいている手順でエクスポート機能追加版のKibanaをインストール・設定する。

github.com

つまづいた点はいくつがあるが、どうにかビルドできた。

  • 説明に記載はないがgit clone https://github.com/tongwang/kibana.gitする
  • nvm install "$(cat .node-version)"したときに存在しないと言われるときは~/.nvm/nvm.sh install "$(cat .node-version)"する

Kibanaを起動する

Kibanaの設定はファイルは/etc/kibana/config/kibana.yml。通常通りserver.port, server.host, server.name, elasticsearch.url, (kibana.indexもコメント外す必要あり?)等を設定する。

kibanaの起動方法は以下の通り。

cd /etc/kibana (when cloned kibana into /etc/)
npm start

このときにProxy?がどうのこうのでアクセス出来ないことがあった。kibana.ymlでserver.host: 0.0.0.0を指定していると0.0.0.0にリダイレクトされてしまった。起動オプションから--devを除外したらアクセス可能になった。

vi /etc/kibana/package.json

-  "start": "sh ./bin/kibana --dev",
+  "start": "sh ./bin/kibana",

各種設定後にnpm startして指定ポートにアクセスするとエクスポート機能付きKibanaにアクセスできる。再掲にはなるが、このようにexport付きの画面が表示される。

f:id:daichi703n:20170327001735p:plain

エクスポートしてみる

さっそくエクスポートしてみたが、CSVファイルをダウンロードできるものの出力されていない…

f:id:daichi703n:20170327001920p:plain

いろいろと試したところ、単純なDiscoverの状態ではだめで、左ペインでindexをAddした状態でないとエクスポートされないようだ。次の画面のようにカラムが表示されていればよい。

f:id:daichi703n:20170327002624p:plain

次の通りエクスポートできた。

f:id:daichi703n:20170327002710p:plain

Dockerコンテナで簡単に導入する

正直、git cloneして、ビルドして、と導入のハードルはやや高い(私自身が経験浅く難しかった)。また、Proxy環境では、Git(Port9418)の通信が発生するため、Proxyサーバの設定次第では通信できず、ビルドを完了できない。

導入を簡単にするために、ビルド済みのDockerコンテナを作成しました。ただし、Dockerhubへの自作コンテナpushも今回が初めてなので、全く最適化できていません…。容量もでかいですがご了承ください。(3GB程度)

https://hub.docker.com/r/daichi703n/kibana-exp-52/

導入手順

導入手順はこちらの通り。オフィシャルと同様、Elasticsearchのパスを起動オプションで指定できるようにしたいが、未実装。設定ファイルを編集ください。

docker pull daichi703n/kibana-exp-52
docker images
// daichi703n/kibana-exp-52 があることを確認する

docker run -d -p 5605:5601 --name some-kibana daichi703n/kibana-exp-52 /sbin/init
docker ps -a
// CONTAINER ID        IMAGE                      COMMAND             CREATED             STATUS              PORTS                    NAMES
// 2098d63548c3        daichi703n/kibana-exp-52   "/sbin/init"        3 minutes ago       Up 3 minutes        0.0.0.0:5605->5601/tcp   some-kibana

docker exec -it some-kibana /bin/bash  // dockerコンテナにログインする。
cd /etc/kibana/
vi ./config/kibana.yml  //環境にあわせて調整
npm start  // 以下のように表示されればOK

> kibana@5.2.3 start /etc/kibana
> sh ./bin/kibana

  log   [15:41:48.351] [info][status][plugin:kibana@5.2.3] Status changed from uninitialized to green - Ready
  log   [15:41:48.424] [info][status][plugin:elasticsearch@5.2.3] Status changed from uninitialized to yellow - Waiting for Elasticsearch
  log   [15:41:48.457] [info][status][plugin:console@5.2.3] Status changed from uninitialized to green - Ready
  log   [15:41:48.494] [warning] You're running Kibana 5.2.3 with some different versions of Elasticsearch. Update Kibana or Elasticsearch to the same version to prevent compatibility issues: v5.2.2 @ 192.168.1.81:9200 (192.168.1.81)
  log   [15:41:49.815] [info][status][plugin:timelion@5.2.3] Status changed from uninitialized to green - Ready
  log   [15:41:49.823] [info][status][plugin:elasticsearch@5.2.3] Status changed from yellow to green - Kibana index ready
  log   [15:41:49.824] [info][listening] Server running at http://0.0.0.0:5601
  log   [15:41:49.825] [info][status][ui settings] Status changed from uninitialized to green - Ready

これでhttp://<サーバIP>:<Kibanaフォワーディングポート>にアクセスすれば使用可能。ポート番号はコンテナ起動時 -p パラメータで変更可能。

まとめ - Kibana 5でDiscoverタブの検索結果をCSVエクスポートする

エクスポート機能が実装されたKibanaを導入して、DiscoverからCSVエクスポートできることを確認した。また、ビルド済みのDockerコンテナを作成したため、簡単に導入できる。

Cisco ASAシリーズはCDP/LLDPを未サポート

f:id:daichi703n:20170317005408p:plain

Cisco ASAはセキュリティデバイスであるため、隣接NW機器の情報を収集するCDP/LLDPをサポートしていない

Ciscoサポートコミュニティの情報

ASAのCDP/LLDPの対応状況に関する質問がいくつかされている。質問はASA5505についてだが、ASAシリーズ全般で同仕様となっている。

supportforums.cisco.com

ASA5505のPoEポートを使う際の注意

こちらの記事に記載した通り、ASA5505のPoEポートに無線APを接続する際、ASAを越えて別のCisco機器(Catalystスイッチなど)とCDPネイバーを張ってしまうと、PoEで正常に給電できない場合がある。

Cisco AIR1131AGでDot11Radioがresetになる原因のひとつ

f:id:daichi703n:20170317004520p:plain

自宅ラボの無線AP Cisco Aironet AIR1131AGで、停電から復旧後にDot11Radioインタフェースのステータスがresetになるトラブルが発生した。

停電の原因は単純な家の電源容量超過で、すべてのNW機器で突然の電源断となってしまった。configの保存はしてあったため変更は発生していない。切り分けで分かったこと、原因と対策を記載する。

Aironet AIR1131AGの接続構成

以下の通り、Cisco ASA5505のPoEインタフェース経由でPoE給電で接続している。なお、PC, サーバ接続にはCatalyst2960を使用し、各VLANのGWはASAにしている。

AIR1131AG
 |(access vlan 1)
ASA5505
 |   |(各VLAN access)
Cat2960
 |   |
(V1) (trunk)
 PC   ESXi

エラー調査

AP上部の通常は緑のランプが、明らかに異常な赤となっていた。インタフェース状態は以下の通り。

AIR1131#sh ip int b
Interface                  IP-Address      OK? Method Status                Protocol
BVI1                       192.168.1.11    YES NVRAM  up                    up      
Dot11Radio0                unassigned      YES NVRAM  reset                 down    
Dot11Radio1                unassigned      YES NVRAM  reset                 down    
FastEthernet0              unassigned      YES NVRAM  up                    up     

AIR1131#sh int Dot11Radio0
Dot11Radio0 is reset, line protocol is down 
  Hardware is 802.11G Radio, address is 001e.136e.1250 (bia 001e.136e.1250)

機器再起動、インタフェースshut/no shutをしても状態は変わらなかった。起動ログを見ると以下のようになっている。

AIR1131#sh log
<snip>
*Mar  1 00:58:26.214: %LINK-5-CHANGED: Interface Dot11Radio1, changed state to reset
*Mar  1 00:58:26.214: %LINK-5-CHANGED: Interface Dot11Radio0, changed state to reset
*Mar  1 00:58:26.215: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0, changed state to up
*Mar  1 00:58:26.906: %LINEPROTO-5-UPDOWN: Line protocol on Interface BVI1, changed state to up
*Mar  1 00:58:27.214: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio1, changed state to down
*Mar  1 00:58:27.214: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0, changed state to down
*Mar  1 00:58:39.279: %CDP_PD-2-POWER_LOW: All radios disabled - LOW_POWER_CLASSIC_NO_INJECTOR_CONFIGURED WS-C2960-24-S (0022.bd42.1d01)
*Mar  1 00:58:39.280:  -Verify the required power-injector is installed on this port: WS-C2960-24-S(Fas 0/1).
*Mar  1 00:58:39.280:  -If a power-injector is installed, issue the command:"power inline negotiation injector installed"

%CDP_PD-2-POWER_LOW: All radios disabled - LOW_POWER_CLASSIC_NO_INJECTOR_CONFIGURED WS-C2960-24-S (0022.bd42.1d01)

CDPでCat2960と情報交換し、PoEの状態確認に失敗しているようにみえる。上記構成の通り、PoE給電元はASA5505であり、Cat2960ではない。そのため、エラーになるのは当然だ。なお、CDPネイバーは正常に張れているので、動作そのものは異常ではない。

AIR1131#sh cdp neighbors 

Device ID        Local Intrfce     Holdtme    Capability  Platform  Port ID
CAT2960          Fas 0              154          S I      WS-C2960- Fas 0/1

停電前からCDPネイバーは張っていたが、Cat2960接続前にASAに接続しPoE給電が始まっていたため、起動時の確認がなく継続動作していたものと考えられる。

対策方法

シンプルに、AIR1131でCDPを無効化する。

AIR1131(config)#no cdp run 

(復旧しない場合はDot11 shut/no shut or reload)

*Mar  1 01:11:42.212: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio1, changed state to down
*Mar  1 01:11:42.213: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0, changed state to down
*Mar  1 01:12:42.711: %CDP_PD-4-POWER_OK: Full power - NON_CISCO-NO_CDP_RECEIVED inline power source
*Mar  1 01:12:42.742: %DOT11-6-FREQ_SCAN: Interface Dot11Radio1, Scanning frequencies for 14 seconds
*Mar  1 01:12:42.771: %DOT11-6-FREQ_SCAN: Interface Dot11Radio0, Scanning frequencies for 24 seconds
*Mar  1 01:12:56.524: %DOT11-6-DFS_SCAN_START: DFS: Scanning frequency 5260 MHz for 60 seconds.
*Mar  1 01:12:56.524: %DOT11-6-FREQ_USED: Interface Dot11Radio1, frequency 5260 selected
*Mar  1 01:12:56.524: %LINK-3-UPDOWN: Interface Dot11Radio1, changed state to up
*Mar  1 01:12:57.524: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio1, changed state to up
*Mar  1 01:13:07.030: %DOT11-6-FREQ_USED: Interface Dot11Radio0, frequency 2467 selected
*Mar  1 01:13:07.030: %LINK-3-UPDOWN: Interface Dot11Radio0, changed state to up
*Mar  1 01:13:08.030: %LINEPROTO-5-UPDOWN: Line protocol on Interface Dot11Radio0, changed state to up
*Mar  1 01:13:30.867: %DOT11-6-ASSOC: Interface Dot11Radio0, Station   0c3e.9f69.656f Associated KEY_MGMT[WPAv2 PSK]
*Mar  1 01:13:57.008: %DOT11-6-DFS_SCAN_COMPLETE: DFS scan complete on frequency 5260 MHz

AIR1131#
AIR1131#sh ip int b
Interface                  IP-Address      OK? Method Status                Protocol
BVI1                       192.168.1.11    YES NVRAM  up                    up      
Dot11Radio0                unassigned      YES NVRAM  up                    up      
Dot11Radio1                unassigned      YES NVRAM  up                    up      
FastEthernet0              unassigned      YES NVRAM  up                    up      

正常にDot11(無線)インタフェースが使用可能な状態になった。

まとめ - Cisco AIR1131AGでDot11Radioがresetになる原因

Cisco Aironet AIR1131AGはPoE起動時に、可能な場合はCDPで対向PoE機器との接続状態を確認する。停電復旧後にその確認でFailとなり、PoE異常でDot11インタフェースが起動できなかった。

AIR1131のCDPを無効化することで、通常通りPoE受電しDot11インタフェースが起動、無線通信が可能となった。

Express + Node.jsでDNS名前解決の状況を確認する

サーバ間のAPI連携などの際のDNS名前解決確認ツールをExpress + Node.jsで作成した。サーバ上でNode.jsで名前解決をするため、実際のアプリケーションと同じ環境での確認ができる。

確認できること

DNSの名前解決 (Webアプリケーション自身から)

以下の通り、FQDNに対するAレコード、PTRレコードを確認できる。

f:id:daichi703n:20170311201728p:plain

公開プログラム

Herokuにてプログラムを公開している。(フリープランなので立ち上がり遅い場合あり)

DNS Checker - Heroku

できないこと・修正したい点

こちらと同様

designetwork.hatenablog.com

ソースコード

Express + Node.jsのソースコードはこちらで公開している。ご自由にお持ちください。

仕組みとしては、jadeのformでFQDNを入力し、クエリとしてNode.jsで読み込む。与えられたFQDN(クエリ)に対してnpm dnsモジュールでアクセスして名前解決情報を取得する。なお、localhostについてはDNSでの名前解決ができないため、npm pingモジュールで同様情報を取得する。

www.npmjs.com

www.npmjs.com

まとめ - Express + Node.jsでDNS名前解決の状況を確認する

Express + Node.js dns, pingモジュールにより、アプリケーション自身がFQDNの名前解決して結果を表示するプログラムを作成した。Webアプリケーション, API基盤の動作確認等の用途に使用できる。