Basic knowledge

[rainit2006]

---

[rainit2006]

目次

• Nagios
• Docker
• CRONコマンド
• Apache Camel
• JMS と ActiveMQ
• HAProxy
• OSGI
• Karaf
• 用eclipse搭建一个maven工程项目

[rainit2006]

Nagios Amazon CloudWatch vs. Nagios + Cacti 機能比較！ https://idc.lexues.co.jp/w/681/ 結論としては、CloudWatchと自社監視サーバを併用してお互いの不得意な部分を補完することで、より安定した運用ができると考えています。

「nagiosからAmazon CloudWatchに切り替えができるのか」 https://blog.situs.co.jp/tech/%E3%82%AF%E3%83%A9%E3%82%A6%E3%83%89/nagios%E3%81%8B%E3%82%89amazon-cloudwatch%E3%81%AB%E5%88%87%E3%82%8A%E6%9B%BF%E3%81%88%E3%81%8C%E3%81%A7%E3%81%8D%E3%82%8B%E3%81%AE%E3%81%8B/

CloudWatch はツールのインストール等何もいらないので、手っ取り早く監視が出来て良いと思いました。 標準メトリクスで監視できる項目は限られていますが、カスタムメトリクスの作成も容易で、 柔軟な監視が出来ると思います。

NRPE (Nagios Remote Plugin Executor ) The NRPE addon is designed to allow you to execute Nagios plugins on remote Linux/Unix machines.

Nagiosは監視ホスト（Monitoring Host）と被監視ホスト（Remote Linux/Unix Host）に分かれている。 この2ホストはNRPE（ Nagios Remote Plugin Executor。被監視ホストにある ）と対応check_nrpe（監視ホストにある）を通じて通信する。具体的なプロセスは下記の通りである。 Nagiosは周期的にheck_nrpeを実行する。 heck_nrpeが直接に被監視ホストのNRPEと通信し、NRPEにチェック内容を通知する。 NRPEが被監視ホストのローカルにインストールされているプラグインを呼んで、被監視ホストのサービスと状態（ディスク、CPU…）をチェックする。 NRPEがチェック結果を監視側のcheck_nrpeに渡して、check_nrpeが結果をNagios状態キューに入れる。 Nagiosは順番通りにキュー中の情報を読み取って、結果をWEB側に表示する。 Nagiosは取得した情報に異常有無を判断し（異常を事前に定義）、該当処理する（警告メール、メッセージ送信…）

NSCA NSCA is an addon that allows you to send passive check results from remote Linux/Unix hosts to the Nagios daemon running on the monitoring server.

Nagios plugin It would be a good idea to keep your plugins in same directory as other Nagios plugins (/usr/lib/nagios/plugins/ for example).

Nagiosで動くプラグインを作るための2つの約束事を、順番にご紹介しましょう。 約束事1：プラグイン自体の返り値が0,1,2,3のどれかであること: •0:OK •1:WARNING •2:CRITICAL •3:UNKNOWN 約束事2：最低でも一行のテキストを標準出力へ出力すること

#!/bin/sh

# 終了コード
OK=0
WARNING=1
CRITICAL=2
UNKNOWN=3

# オプションを1つ受け取って、変数 status に格納します。
if [ $# != 1 ]
then
  echo "Just 1 argument is permitted."
  exit $UNKNOWN
else
  status=$1
fi

# 変数 status が 0,1,2,3 のどれかなら、それに応じたステータスを返し、終了します。
# 0,1,2,3 以外であれば UNKNOWN としてみましょう。
case $status in
  0)  echo "** OK **"
      exit $OK ;;
  1)  echo "** WARNING **"
      exit $WARNING ;;
  2)  echo "** CRITICAL **"
      exit $CRITICAL ;;
  3)  echo "** UNKNOWN **"
      exit $UNKNOWN ;;
  *)  echo "The argument $status is not permitted."
      exit $UNKNOWN ;;
esac

# 上で分岐が網羅されていれば、ここには来ませんが、念のため。
echo "** Error **"
exit $UNKNOWN

[rainit2006]

Docker http://paiza.hatenablog.com/entry/docker_intro コンテナと仮想マシンの違い: コンテナはOSレベルの仮想化を行いその上でプロセスを動かしますが、仮想マシンはマシンレベルの仮想化を行いその上でゲストOSを動かします。コンテナ(Docker)と仮想マシンを比較すると、コンテナ(Docker)は、早い、リソース消費が少ない、OSはLinuxのみ、という特徴があります。

Dockerの構成(5つの要素) コンテナ: Dockerイメージから作られ、実行される仮想環境です。 Dockerイメージ: コンテナのファイルシステム、設定をひとまとめに保存しています。 Dockerサーバ: Docker本体ともいえる、コンテナ・イメージの管理を行うサービスです。 Dockerクライアント: ユーザが実際にDockerを操作すル時に使うコマンド、GUIツールです。Dockerを利用する周辺ツールも含まれます。 Docker Hub(レジストリ): Dockerイメージを集めたサイトです。OS、アプリケーションのイメージが多く公開されており、誰でも自由に利用できます。

http://bg.biedalian.com/2014/11/20/docker-start.html 什么是 docker? 为了更好理解, 你可以直接和别人说它是虚拟机, 实际上 docker 并不是虚拟机, 它做的是 linux 的隔离, 但它的隔离做的如此之真实以至于让人觉得自己拥有可以一台完整的 linux 系统.

那 docker 和 虚拟机具体是什么区别呢, 虚拟机在底层模拟出各种硬件, cpu, 硬盘之类的, 而 docker 是在软件层面给资源分组, docker 性能无限接近原生, 因为 docker 用的就是系统自己的进程, 而虚拟机做的再好, 也做不出原生的感觉.

docker 的隔离技术源自于 Linux 容器 LXC(linux container), 听起名字就知道, 这和沙箱应该差不多, 可以把东西分开放, 也就是隔离的意思, 甚至可以在某些仓库中看到 docker 的名字叫 lxc-docker. LXC 又是基于 cgroup 的 namespace, chroot 等. cgroup 对于 docker 是至关重要的, 了解它才会觉得 docker 不神秘, cgroup 全称为 control group, 是 linux 内核提供的功能, 简单的说, 它的作用就是把系统运行的进程按用户自定义的群组区分, 也就是说 一个 docker, 一个 group. cgroup 有限制使用资源的能力: •blkio -- 这个子系统为块设备设定输入/输出限制，比如物理设备（磁盘，固态硬盘，USB 等等） •cpu -- 这个子系统使用调度程序提供对 CPU 的 cgroup 任务访问 •cpuacct -- 这个子系统自动生成 cgroup 中任务所使用的 CPU 报告 •cpuset -- 这个子系统为 cgroup 中的任务分配独立 CPU（在多核系统）和内存节点 •devices -- 这个子系统可允许或者拒绝 cgroup 中的任务访问设备 •freezer -- 这个子系统挂起或者恢复 cgroup 中的任务 •memory -- 这个子系统设定 cgroup 中任务使用的内存限制，并自动生成由那些任务使用的内存资源报告 •net_cls -- 这个子系统使用等级识别符（classid）标记网络数据包，可允许 Linux 流量控制程序（tc）识别从具体 cgroup 中生成的数据包 •ns -- 名称空间子系统

[rainit2006]

CRON ：类似于TaskScheduler cron とは、ジョブ（スクリプト）を自動実行するためのデーモンプロセスです。 そして、Linux システムの管理を行なう場合、ログのローテートや、バックアップなど、定期的に自動実行したいジョブが数多くあります。

■サービスの起動 cron を使用するためには、crond が起動していなくてはいけません。通常は、インストール時にサービスが自動起動するように設定されていますが、以下のコマンドで、crond の状態を確認します。

# /etc/rc.d/init.d/crond status
crond (pid xxx) を実行中...

もし、crond が起動していなかった場合には、crond を手動で起動し、以後、OS起動時にcrond が自動起動するように設定します。

# /etc/rc.d/init.d/crond start
crondを起動中:
# chkconfig --level 2345 crond on     ･･･(注１)
# chkconfig --list crond              ･･･(注２)
crond     0:オフ  1:オフ  2:オン  3:オン  4:オン  5:オン  6:オフ

■cronの設定ファイル crond は、毎分、以下の設定ファイルの内容に変更がないかを確認し、変更があった場合には、それを反映して実行します。

■crontabコマンドの書式 crontabファイルは、cron を操作する際に作成し、プロセスを定期的に実行するためのファイルで、crontabコマンドで作成します。書式は、以下の通りです。 # crontab [- u user] {-l|-r|-e}

rootユーザが、testユーザの crontabファイルを表示する場合。

crontab -l -u test

自分自身の crontabファイルを編集する場合。 $ crontab -e

crontabファイルでは、crond への命令を、「この日付のこの時刻に、このコマンドを実行して下さい。」といった形式で書き込みます。 そして、ユーザは、それぞれのcrontabファイルを「/var/spool/cron」配下にuser という名前で所有しており、使用するコマンドは、そのcrontabファイルを所有しているユーザの権限で実行されるので、コマンド使用の際には注意が必要です。

■cron コマンドの設定 crontabファイルで、cron コマンドの実行を記述する行は、6つのフィールドで形成されており(システムの crontabファイル(/etc/crontab)は、7つ(分、時、日、月、曜日、ユーザ名、コマンド))、コマンドの実行時間をさまざまな形式で指定することが出来ます。

■設定ファイル（/etc/crontab） 通常、このファイルには、以下のように、「cron.monthly」、「cron.weekly」、「cron.daily」、「cron.hourly」配下のファイルが、指定時間ごとに実行されるように設定されています。

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/

# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly

0-59/5 * * * * root /usr/bin/mrtg /etc/mrtg/mrtg.cfg

注意： 7个区域：“分　時　日　月　曜日　ユーザ　コマンド”

このファイルも、「/var/spool/cron/user」ファイルと同様に、コメント行、環境変数の設定、cronコマンドの実行の3つで形成されますが、cronコマンドの実行を設定する行の書式が若干異なっています。

■「/etc/cron.monthly、cron.weekly、cron.daily、cron.hourly」 上述の通り、これらのディレクトリは、「/etc/crontab」ファイルによって呼び出され、指定時間ごとに、配下にあるシェルスクリプトを実行します。

[rainit2006]

Apache Camel http://bestlixiang.site/2017/07/15/%E6%B5%85%E5%B0%9DApache-Camel/

Camel的定位是Routing Engine。

■理解起来很简单：始端》（过滤器+路由处理器）》终端 Apache Camel核心概念： endpoint,所谓的endpoint,就是一种可以接收或发送数据的组件。可以支持多种协议，如jms,http,file等。 processor,它是用来处理具体业务逻辑的组件。 route,用来路由，指示数据从哪里来到哪里去，中间用哪个processor处理。 exchange,processor之间用exchange对象来传送数据，有点像jms,通俗一点就像上学时传的小纸条,所以：exchange对象就是processor，endpoint所有camel组件之间传送数据的小纸条:)。 filter，用来确定哪些东西可以传递，哪些东西不可以传递。

■应用场景：

[rainit2006]

JMSとは JMSとはJava Message Serviceの略で、Javaでメッセージングサービスを利用するための標準APIです。 メッセージングとはプログラム間でデータを細かにわけるのではなく、一つのメッセージオブジェクトを作成して通信を行うことです。 常に接続が維持されている必要はなく、非同期に通信を行うことが出来ます。

メッセージングの概念を理解するために、宅配便に例えて解説を行います。 あなたは、ある宛先に対して送りたい物（オブジェクト）あったとします。 送るためには封筒やダンボールを用いて梱包を行う必要があります。 梱包された荷物（メッセージオブジェクト）に宛先を記入し、 数ある運送業者（中継サーバ）の中から一つを選択して荷物の配達をお願いします。 送り主がするべきことはこれで終わりますが、現在の荷物の状況を確かめることなどが運送業者によって可能になっていることもあります。 運送業者は書かれた宛先に対して荷物を配達します。もしその宛先が留守であれば（接続されていないならば）いったん持ち帰り、荷物を保存しておきます。 受け取り主が運送業者に対して配信を申し込んだ場合や、指定した時間が立った後、運送業者は再配信を行います。 受け取り主は届いた荷物から中身を取り出すことで、送信された物（オブジェクト）を受け取ることが出来ます。

消息队列

ActiveMQ http://www.techscore.com/tech/Java/JavaEE/JMS/1/ http://www.jianshu.com/p/8caa6d66b10d

■ActiveMQサーバ／MessageBrokerの起動 ActiveMQでは中継を行うサーバのことをMessageBrokerと呼んでいます。 JMSを使用するためにはサーバを起動しておく必要があります。

起動するためにはいくつか方法があります。

1. バッチファイルを実行する。 ActiveMQを解凍したフォルダの中にある「bin」フォルダの中の「activemq.bat(.sh)」というバッチファイルを起動することでMessageBrokerが立ち上がります。
2. org.activemq.broker.impl.Mainクラスを実行することでMessageBrokerを立ち上げることが出来ます。
3. 埋め込みサーバを使用する コネクションを作成するConnectionFactoryオブジェクトにサーバを埋め込み起動することが出来ます。詳しくは別の章で解説します。

■ ActiviteMQ消息有3种形式

1. 使用JMS方式发送接收消息

2. 点对点方式（point-to-point） 点对点的消息发送方式主要建立在 Message Queue,Sender,reciever上，Message Queue 存贮消息，Sneder 发送消息，receive接收消息.

3.发布/订阅 方式（publish/subscriber Messaging） 发布/订阅方式用于多接收客户端的方式.作为发布订阅的方式，可能存在多个接收客户端，并且接收端客户端与发送客户端存在时间上的依赖。一个接收端只能接收他创建以后发送客户端发送的信息。作为subscriber ,在接收消息时有两种方法，destination的receive方法，和实现message listener 接口的onMessage 方法。

[rainit2006]

HAProxy 多機能なプロキシサーバです。ソフトウェアロードバランサの一種でもあります。

[rainit2006]

OSGi （Open Services Gateway initiative） ソフトウェア統合開発環境の1つ「Eclipse」のコア技術というとピンと来る方も多いと思います。本稿では、ここ数年さまざまなアプリケーションの（SpringやJBoss、GlassFishでも）基盤技術として採用されている.

OSGiを一言でいうと、「Javaモジュールの動的追加や実行を管理するための基盤システム」です。この基盤システムの仕様をOSGi Service Platform仕様として、非営利団体であるOSGi Allianceが規定しています。

OSGiフレームワーク自身はいくつかの基本的な機能を提供しますが、あくまでフレームワークでありそれだけでは何もできません。 OSGiフレームワーク上にバンドルという機能提供するプログラムをインストールすることで機能追加を行います。このバンドルを組み合わせてアプリケーションを構成していきます。

OSGi Bundle OSGiでは、Javaモジュールを「バンドル(Bundle)」と呼び、このバンドルの実行基盤を「OSGiフレームワーク」と呼びます。このバンドルが、Eclipseのプラグインに当たります。Eclipseは、OSGiフレームワーク上で動作するように設計されており、プラグインだけでなくEclipseの実行環境もバンドルとして実装されています。

「バンドル」は、複数のクラスファイルとリソースファイルをアーカイブとして1つにまとめたJARファイルです。通常のJARファイルとの違いは、マニフェストファイルにOSGiの仕様特有の属性を加える点と、Mainクラスの代わりにBundleActvatorインタフェースを実装したクラスが必要であることだけです。

OSGi Blueprint 在OSGi Service Platform Release 4 V4.2中， 提到了很多的企业级规范(Enterprise Specification)， 其中包括了规范121：Blueprint容器规范(Container Specification)。Buleprint容器规范规定了一个OSGi容器(不是OSGi rumtime)的方方面面. Buleprint(或者说，OSGi Enterprise)目前有两个主要的实现：Eclipse Gemini和Apache Aries。

Blueprint Container 规范为 OSGi 定义了一个 依赖性注入（DI,Dependency Injection）框架，可以处理OSGi 的动态特性。 等等

---

在java的SOA (Service-Oriented Architecture) 中可以分为两个阵营，解决了两个不同层级的问题，第一阵营算是WebService，解决了分布式系统级别SOA问题；第二阵营就是OSGi了，解决了jar级别的SOA问题。 http://www.hifreud.com/2014/12/18/osgi-00-introduction/

[rainit2006]

Karaf Apache Karaf is a modern and polymorphic container. Karaf can be used standalone as a container, supporting a wide range of applications and technologies. It also supports the "run anywhere" (on any machine with Java, cloud, docker images, …​) using the embedded mode.

ActiveMQ Enterprise Integration Pattern Blueprint

Blueprint プログラミング・モデル

[rainit2006]

JDBC接続 http://www.javaroad.jp/opensource/js_tomcat8.htm

JNDI（Java Naming and Directory Interface)とはNIS、ActiveDirectoryなどのディレクトリサービスを利用するためのJavaAPIです。 JNDIリソースとしてJDBCを設定することにより、JavaアプリからはJNDIリソースを指定することでJDBCを利用することができます。データベースが変更された場合でもJNDIリソースを変更するだけでJavaアプリに影響を与えることはありません。

具体的にはserver.xmlにJNDIリソースの設定、web.xmlにJNDIリソースを参照する設定、JavaアプリにJNDIリソースを呼び出すコードを記載することでJDBC接続を行います。

■server.xmlの設定 server.xmlでJNDIリソースの設定を行います。 JNDIリソースの設定にはタグとタグを使用します。

タグでJNDIリソースの指定を行い、タグで指定の際に使用するパラメータの設定を行います。 タグ、タグはタグ、タグ、タグのサブ要素として指定できます。 タグにはタグでJNDIリソースの動作設定を行う必要があります。  [[Server.xmlサンプル]] ``` factory org.apache.commons.dbcp.BasicDataSourceFactory maxActive 20 maxIdle 30000 maxWait 100 username myuser password mypass driverClassName org.gjt.mm.mysql.Driver url jdbc:mysql://localhost/auth ``` １、タグのサブ要素としてタグを追加します。このタグで設定された要素はすべてのコンテキストに適用されます。 ２、タグを追加します。JNDIリソースは「MySQL_JDBC」という名前で参照され、リソースマネージャへの接続はTomcatコンテナが行い、JNDIリソースがJavaインタフェース型「javax.sql.DataSource」を返すことを表しています。 ３、タグを追加します。name属性に「MySQL_JDBC」を設定し、上記のタグに関連する設定であることを表しています。 ４、タグを使用し、JNDIリソースの動作設定を行います。タグにパラメータ名、タグにパラメータ名に対応する値を設定します。 ■web.xmlの設定 web.xmlではタグを使用してserver.xmlで設定したJNDIリソースを参照する設定を行います。これにより、JavaアプリからJNDIリソースが利用できるようになります。 タグのサブ要素  Web.xmlサンプル ``` MySQL_JDBC javax.sql.DataSource Container ```

[rainit2006]

用eclipse搭建一个maven工程项目 1，File->import->maven目录下maven exist project 2，设定Proxy [Window]-[Preference]-[Maven]-[User Settings]を選択します。 「User Settings:」に/home/user/.m2/settings.xmlが表示されていることを確認します。 デフォルトで上記のような設定になっているのですが、settings.xml は存在していないので新規に作成します。

<?xml version="1.0" encoding="UTF-8"?>
<settings xmlns="http://maven.apache.org/SETTINGS/1.1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.1.0 http://maven.apache.org/xsd/settings-1.1.0.xsd">
  <proxies>
    <proxy>
      <id>http_proxy</id>
      <active>true</active>
      <protocol>http</protocol>
      <host>proxy.example.net</host>
      <port>8080</port>
    </proxy>
    <proxy>
      <id>https_proxy</id>
      <active>true</active>
      <protocol>https</protocol>
      <host>proxy.example.net</host>
      <port>8080</port>
    </proxy>
  </proxies>
</settings>