1 | npm install json -g |
1 | # 标准输入 |
-e：修改
1 | $ echo '{"name":"trent","age":38}' | json -e 'this.age++' |
-c：添加
1 | json -I -f tmp.json -c 'this.deploy.branch="main"' |
资源清单是 yml 格式，api-server 会自动转成 json 格式
每个 API 对象都有 3 大类属性：元数据 metadata、规范 spec 和状态 status
spec 是期望状态，status 是实际状态，如果实际状态和期望状态有出入，控制器（通常是 deployment 控制器）的控制循环就会监控到差异，然后将需要做出的更改提交到 apiserver，调度器 scheduler 监控到 apiserver 中有未执行的操作，就会去找适合执行操作的 node，然后提交到 apiserver，kubelet 监控到 apiserver 中有关于自己节点的操作，就会执行操作，将执行结果返回给 apiserver，apiserver 再更新实际状态
1 |
1 | kind: HorizontalPodAutoscaler |
1 | apiVersion: v1 |
1 | kind: Deployment |
vxlan 是属于 overlay 中的一种隧道封装技术，实际上将 L2(数据链路层)的以太网帧封装成 L4(传输层)的 UDP 数据报文，然后在 L3 网络层传输，最终实现的效果就类似于在 L2 的以太网传输报文一样，但是不受 L3 网络层限制
1 | 为什么是在L3传输？ |
vxlan 标志位有 24 位，可以划分 2^24 个虚拟局域网
1 | 1. 感觉封装UDP是多余的，只靠IP也能通信 |
kubernetes 的网络模型主要用于解决四类通信需求
命名空间：linux 底层概念，在内核层实现，容器使用 namespce 技术实现容器间相互隔离
运行在同一个 pod 内的容器，共享 net、ipc、uts、一组存储卷，亲密关系，同进同退
网络模型：所有 Pod 在一个平面网络中，每个 Pod 拥有一个集群全局唯一的地址，可直接与其他 Pod 通信
k8s 设计了网络模型，但将其实现交给网络插件，主流的网络插件有：flannel、calico、kube-router 等
早期版本的 Flannel 使用 UDP 封装完成报文的跨越主机转发，其安全性及性能略有不足，现在已经废弃这种方式了，现在只能通过 vxlan 或 host-gw 进行通信
flannel VXLAN 后端：
flannel VXLAN Direct Routing 后端：
Directrouting 为在同一个二层网络中的 node 节点启用直接路由机制，类似于 host-gw 模式
host-gw 后端：
类似 calico，通过路由表完成报文转发
Calico 本身是一个三层的虚拟网络方案，它将每个节点都当作路由器（router），将每个节点的容器都当作是“节点路由器”的一个终端并为其分配一个 IP 地址，各节点路由器通过BGP（BorderGateway Protocol）学习生成路由规则，从而将不同节点上的容器连接起来
BGP 是互联网上一个核心的去中心化自治路由协议，性能非常高，需要物理路由器的支持，这也是公有云不提供 calico 的原因，因为公有云上节点连接的都是虚拟路由器
calico 核心组件：
BGP 模式下 calico 的通信过程：
1 | # traceroute命令查看请求ip为10.10.74.193的pod |
如果 node 需要跨网段通信，Calico 也提供了IPIP模式，IPIP 模式下，calico 会在每个节点上创建一个 tunl0 接口（TUN 类型虚拟设备）用于封装三层隧道报文。节点上每创建一个 Pod 资源，都自动创建一对虚拟以太网接口（TAP 类型的虚拟设备），其中一个附加于 Pod 的网络名称空间，另一个（名称以 cali 为前缀后跟随机字串）留置在节点的根网络名称空间，并经由 tunl0 封装或解封三层隧道报文，Calico IPIP 模式如下图：
IPIP 模式下 calico 的通信过程：
1 | / $ traceroute 10.10.58.65 # 请求ip为10.10.58.65的pod |
BGP 模式则直接使用物理机作为虚拟路由路（vRouter），请求直接通过路由跳转，不再创建额外的 tunnel，没有 tunnel 封装、解封的步骤，所以 BGP 的性能会比 IPIP 高很多，建议禁用 IPIP
请求流量首先到达外部负载均衡器，由其调度至某个工作节点之上，而后再由工作节点的 netfilter（kube-proxy）组件上的规则（iptables 或 ipvs）调度至某个目标 Pod 对象
集群外的流量先进入节点网络，再进入service 网络，最后进入pod 网络
网络策略（Network Policy）是用于控制分组的 Pod 资源彼此之间如何进行通信，以及分组的 Pod 资源如何与其他网络端点进行通信的规范。它用于为 Kubernetes 实现更为精细的流量控制，实现租户隔离机制。Kubernetes 使用标准的资源对象“NetworkPolicy”供管理员按需定义网络访问控制策略
Kubernetes 的网络策略功能由其所使用的网络插件实现，Calico、Canal 及 kube-router 支持网络策略，而 flannel 不支持
etcdctl is a command line client for etcd.
The v3 API is used by default on master branch. For the v2 API, make sure to set environment variable ETCDCTL_API=2. See also READMEv2.
If using released versions earlier than v3.4, set ETCDCTL_API=3 to use v3 API.
Global flags (e.g., dial-timeout, --cacert, --cert, --key) can be set with environment variables:
1 | ETCDCTL_DIAL_TIMEOUT=3s |
Prefix flag strings with ETCDCTL_, convert all letters to upper-case, and replace dash(-) with underscore(_). Note that the environment variables with the prefix ETCDCTL_ can only be used with the etcdctl global flags. Also, the environment variable ETCDCTL_API is a special case variable for etcdctl internal use only.
PUT assigns the specified value with the specified key. If key already holds a value, it is overwritten.
RPC: Put
lease – lease ID (in hexadecimal) to attach to the key.
prev-kv – return the previous key-value pair before modification.
ignore-value – updates the key using its current value.
ignore-lease – updates the key using its current lease.
OK
1 | ./etcdctl put foo bar --lease=1234abcd |
1 | ./etcdctl put foo bar --lease=1234abcd |
1 | ./etcdctl put foo bar1 --prev-kv |
If <value> isn’t given as command line argument, this command tries to read the value from standard input.
When <value> begins with ‘-‘, <value> is interpreted as a flag.
Insert ‘–’ for workaround:
1 | ./etcdctl put <key> -- <value> |
Providing <value> in a new line after using carriage return is not supported and etcdctl may hang in that case. For example, following case is not supported:
1 | ./etcdctl put <key>\r |
A <value> can have multiple lines or spaces but it must be provided with a double-quote as demonstrated below:
1 | ./etcdctl put foo "bar1 2 3" |
GET gets the key or a range of keys [key, range_end) if range_end is given.
RPC: Range
hex – print out key and value as hex encode string
limit – maximum number of results
prefix – get keys by matching prefix
order – order of results; ASCEND or DESCEND
sort-by – sort target; CREATE, KEY, MODIFY, VALUE, or VERSION
rev – specify the kv revision
print-value-only – print only value when used with write-out=simple
consistency – Linearizable(l) or Serializable(s)
from-key – Get keys that are greater than or equal to the given key using byte compare
keys-only – Get only the keys
<key>\n<value>\n<next_key>\n<next_value>…
First, populate etcd with some keys:
1 | ./etcdctl put foo bar |
Get the key named foo:
1 | ./etcdctl get foo |
Get all keys:
1 | ./etcdctl get --from-key '' |
Get all keys with names greater than or equal to foo1:
1 | ./etcdctl get --from-key foo1 |
Get keys with names greater than or equal to foo1 and less than foo3:
1 | ./etcdctl get foo1 foo3 |
If any key or value contains non-printable characters or control characters, simple formatted output can be ambiguous due to new lines. To resolve this issue, set --hex to hex encode all strings.
Removes the specified key or range of keys [key, range_end) if range_end is given.
RPC: DeleteRange
prefix – delete keys by matching prefix
prev-kv – return deleted key-value pairs
from-key – delete keys that are greater than or equal to the given key using byte compare
Prints the number of keys that were removed in decimal if DEL succeeded.
1 | ./etcdctl put foo bar |
1 | ./etcdctl put key val |
1 | ./etcdctl put a 123 |
1 | ./etcdctl put zoo val |
TXN reads multiple etcd requests from standard input and applies them as a single atomic transaction.
A transaction consists of list of conditions, a list of requests to apply if all the conditions are true, and a list of requests to apply if any condition is false.
RPC: Txn
hex – print out keys and values as hex encoded strings.
interactive – input transaction with interactive prompting.
1 | <Txn> ::= <CMP>* "\n" <THEN> "\n" <ELSE> "\n" |
SUCCESS if etcd processed the transaction success list, FAILURE if etcd processed the transaction failure list. Prints the output for each command in the executed request list, each separated by a blank line.
txn in interactive mode:
1 | ./etcdctl txn -i |
txn in non-interactive mode:
1 | ./etcdctl txn <<<'mod("key1") > "0" |
When using multi-line values within a TXN command, newlines must be represented as \n. Literal newlines will cause parsing failures. This differs from other commands (such as PUT) where the shell will convert literal newlines for us. For example:
1 | ./etcdctl txn <<<'mod("key1") > "0" |
COMPACTION discards all etcd event history prior to a given revision. Since etcd uses a multiversion concurrency control
model, it preserves all key updates as event history. When the event history up to some revision is no longer needed,
all superseded keys may be compacted away to reclaim storage space in the etcd backend database.
RPC: Compact
Prints the compacted revision.
1 | ./etcdctl compaction 1234 |
Watch watches events stream on keys or prefixes, [key or prefix, range_end) if range_end is given. The watch command runs until it encounters an error or is terminated by the user. If range_end is given, it must be lexicographically greater than key or “\x00”.
RPC: Watch
hex – print out key and value as hex encode string
interactive – begins an interactive watch session
prefix – watch on a prefix if prefix is set.
prev-kv – get the previous key-value pair before the event happens.
rev – the revision to start watching. Specifying a revision is useful for observing past events.
Input is only accepted for interactive mode.
1 | watch [options] <key or prefix>\n |
<event>[\n<old_key>\n<old_value>]\n<key>\n<value>\n<event>\n<next_key>\n<next_value>\n…
1 | ./etcdctl watch foo |
1 | ETCDCTL_WATCH_KEY=foo ./etcdctl watch |
Receive events and execute echo watch event received:
1 | ./etcdctl watch foo -- echo watch event received |
Watch response is set via ETCD_WATCH_* environmental variables:
1 | ./etcdctl watch foo -- sh -c "env | grep ETCD_WATCH_" |
Watch with environmental variables and execute echo watch event received:
1 | export ETCDCTL_WATCH_KEY=foo |
1 | export ETCDCTL_WATCH_KEY=foo |
1 | ./etcdctl watch -i |
Receive events and execute echo watch event received:
1 | ./etcdctl watch -i |
Watch with environmental variables and execute echo watch event received:
1 | export ETCDCTL_WATCH_KEY=foo |
1 | export ETCDCTL_WATCH_KEY=foo |
LEASE provides commands for key lease management.
LEASE GRANT creates a fresh lease with a server-selected time-to-live in seconds
greater than or equal to the requested TTL value.
RPC: LeaseGrant
Prints a message with the granted lease ID.
1 | ./etcdctl lease grant 60 |
LEASE REVOKE destroys a given lease, deleting all attached keys.
RPC: LeaseRevoke
Prints a message indicating the lease is revoked.
1 | ./etcdctl lease revoke 32695410dcc0ca06 |
LEASE TIMETOLIVE retrieves the lease information with the given lease ID.
RPC: LeaseTimeToLive
Prints lease information.
1 | ./etcdctl lease grant 500 |
LEASE LIST lists all active leases.
RPC: LeaseLeases
Prints a message with a list of active leases.
1 | ./etcdctl lease grant 60 |
LEASE KEEP-ALIVE periodically refreshes a lease so it does not expire.
RPC: LeaseKeepAlive
Prints a message for every keep alive sent or prints a message indicating the lease is gone.
1 | ./etcdctl lease keep-alive 32695410dcc0ca0 |
MEMBER provides commands for managing etcd cluster membership.
MEMBER ADD introduces a new member into the etcd cluster as a new peer.
RPC: MemberAdd
Prints the member ID of the new member and the cluster ID.
1 | ./etcdctl member add newMember --peer-urls=https://127.0.0.1:12345 |
MEMBER UPDATE sets the peer URLs for an existing member in the etcd cluster.
RPC: MemberUpdate
Prints the member ID of the updated member and the cluster ID.
1 | ./etcdctl member update 2be1eb8f84b7f63e --peer-urls=https://127.0.0.1:11112 |
MEMBER REMOVE removes a member of an etcd cluster from participating in cluster consensus.
RPC: MemberRemove
Prints the member ID of the removed member and the cluster ID.
1 | ./etcdctl member remove 2be1eb8f84b7f63e |
MEMBER LIST prints the member details for all members associated with an etcd cluster.
RPC: MemberList
Prints a humanized table of the member IDs, statuses, names, peer addresses, and client addresses.
1 | ./etcdctl member list |
1 | ./etcdctl -w json member list |
1 | ./etcdctl -w table member list |
ENDPOINT provides commands for querying individual endpoints.
ENDPOINT HEALTH checks the health of the list of endpoints with respect to cluster. An endpoint is unhealthy
when it cannot participate in consensus with the rest of the cluster.
If an endpoint can participate in consensus, prints a message indicating the endpoint is healthy. If an endpoint fails to participate in consensus, prints a message indicating the endpoint is unhealthy.
Check the default endpoint’s health:
1 | ./etcdctl endpoint health |
Check all endpoints for the cluster associated with the default endpoint:
1 | ./etcdctl endpoint --cluster health |
ENDPOINT STATUS queries the status of each endpoint in the given endpoint list.
Prints a humanized table of each endpoint URL, ID, version, database size, leadership status, raft term, and raft status.
Prints a line of JSON encoding each endpoint URL, ID, version, database size, leadership status, raft term, and raft status.
Get the status for the default endpoint:
1 | ./etcdctl endpoint status |
Get the status for the default endpoint as JSON:
1 | ./etcdctl -w json endpoint status |
Get the status for all endpoints in the cluster associated with the default endpoint:
1 | ./etcdctl -w table endpoint --cluster status |
ENDPOINT HASHKV fetches the hash of the key-value store of an endpoint.
Prints a humanized table of each endpoint URL and KV history hash.
Prints a line of JSON encoding each endpoint URL and KV history hash.
Get the hash for the default endpoint:
1 | ./etcdctl endpoint hashkv |
Get the status for the default endpoint as JSON:
1 | ./etcdctl -w json endpoint hashkv |
Get the status for all endpoints in the cluster associated with the default endpoint:
1 | ./etcdctl -w table endpoint --cluster hashkv |
Provides alarm related commands
alarm disarm Disarms all alarms
RPC: Alarm
alarm:<alarm type> if alarm is present and disarmed.
1 | ./etcdctl alarm disarm |
If NOSPACE alarm is present:
1 | ./etcdctl alarm disarm |
alarm list lists all alarms.
RPC: Alarm
alarm:<alarm type> if alarm is present, empty string if no alarms present.
1 | ./etcdctl alarm list |
If NOSPACE alarm is present:
1 | ./etcdctl alarm list |
DEFRAG defragments the backend database file for a set of given endpoints while etcd is running, or directly defragments an etcd data directory while etcd is not running. When an etcd member reclaims storage space from deleted and compacted keys, the space is kept in a free list and the database file remains the same size. By defragmenting the database, the etcd member releases this free space back to the file system.
Note that defragmentation to a live member blocks the system from reading and writing data while rebuilding its states.
Note that defragmentation request does not get replicated over cluster. That is, the request is only applied to the local node. Specify all members in --endpoints flag or --cluster flag to automatically find all cluster members.
For each endpoints, prints a message indicating whether the endpoint was successfully defragmented.
1 | ./etcdctl --endpoints=localhost:2379,badendpoint:2379 defrag |
Run defragment operations for all endpoints in the cluster associated with the default endpoint:
1 | ./etcdctl defrag --cluster |
To defragment a data directory directly, use the --data-dir flag:
1 | # Defragment while etcd is not running |
DEFRAG returns a zero exit code only if it succeeded defragmenting all given endpoints.
SNAPSHOT provides commands to restore a snapshot of a running etcd server into a fresh cluster.
SNAPSHOT SAVE writes a point-in-time snapshot of the etcd backend database to a file.
The backend snapshot is written to the given file path.
Save a snapshot to “snapshot.db”:
1 | ./etcdctl snapshot save snapshot.db |
SNAPSHOT RESTORE creates an etcd data directory for an etcd cluster member from a backend database snapshot and a new cluster configuration. Restoring the snapshot into each member for a new cluster configuration will initialize a new etcd cluster preloaded by the snapshot data.
The snapshot restore options closely resemble to those used in the etcd command for defining a cluster.
data-dir – Path to the data directory. Uses <name>.etcd if none given.
wal-dir – Path to the WAL directory. Uses data directory if none given.
initial-cluster – The initial cluster configuration for the restored etcd cluster.
initial-cluster-token – Initial cluster token for the restored etcd cluster.
initial-advertise-peer-urls – List of peer URLs for the member being restored.
name – Human-readable name for the etcd cluster member being restored.
skip-hash-check – Ignore snapshot integrity hash value (required if copied from data directory)
A new etcd data directory initialized with the snapshot.
Save a snapshot, restore into a new 3 node cluster, and start the cluster:
1 | ./etcdctl snapshot save snapshot.db |
SNAPSHOT STATUS lists information about a given backend database snapshot file.
Prints a humanized table of the database hash, revision, total keys, and size.
Prints a line of JSON encoding the database hash, revision, total keys, and size.
1 | ./etcdctl snapshot status file.db |
1 | ./etcdctl -write-out=json snapshot status file.db |
1 | ./etcdctl -write-out=table snapshot status file.db |
MOVE-LEADER transfers leadership from the leader to another member in the cluster.
1 | # to choose transferee |
LOCK acquires a distributed mutex with a given name. Once the lock is acquired, it will be held until etcdctl is terminated.
Once the lock is acquired but no command is given, the result for the GET on the unique lock holder key is displayed.
If a command is given, it will be executed with environment variables ETCD_LOCK_KEY and ETCD_LOCK_REV set to the lock’s holder key and revision.
Acquire lock with standard output display:
1 | ./etcdctl lock mylock |
Acquire lock and execute echo lock acquired:
1 | ./etcdctl lock mylock echo lock acquired |
Acquire lock and execute etcdctl put command
1 | ./etcdctl lock mylock ./etcdctl put foo bar |
LOCK returns a zero exit code only if it is terminated by a signal and releases the lock.
If LOCK is abnormally terminated or fails to contact the cluster to release the lock, the lock will remain held until the lease expires. Progress may be delayed by up to the default lease length of 60 seconds.
ELECT participates on a named election. A node announces its candidacy in the election by providing
a proposal value. If a node wishes to observe the election, ELECT listens for new leaders values.
Whenever a leader is elected, its proposal is given as output.
If a candidate, ELECT displays the GET on the leader key once the node is elected election.
If observing, ELECT streams the result for a GET on the leader key for the current election and all future elections.
1 | ./etcdctl elect myelection foo |
ELECT returns a zero exit code only if it is terminated by a signal and can revoke its candidacy or leadership, if any.
If a candidate is abnormally terminated, election rogress may be delayed by up to the default lease length of 60 seconds.
auth enable activates authentication on an etcd cluster and auth disable deactivates. When authentication is enabled, etcd checks all requests for appropriate authorization.
RPC: AuthEnable/AuthDisable
Authentication Enabled.
1 | ./etcdctl user add root |
ROLE is used to specify different roles which can be assigned to etcd user(s).
role add creates a role.
RPC: RoleAdd
Role <role name> created.
1 | ./etcdctl --user=root:123 role add myrole |
role get lists detailed role information.
RPC: RoleGet
Detailed role information.
1 | ./etcdctl --user=root:123 role get myrole |
role delete deletes a role.
RPC: RoleDelete
Role <role name> deleted.
1 | ./etcdctl --user=root:123 role delete myrole |
role list lists all roles in etcd.
RPC: RoleList
A role per line.
1 | ./etcdctl --user=root:123 role list |
role grant-permission grants a key to a role.
RPC: RoleGrantPermission
from-key – grant a permission of keys that are greater than or equal to the given key using byte compare
prefix – grant a prefix permission
Role <role name> updated.
Grant read and write permission on the key foo to role myrole:
1 | ./etcdctl --user=root:123 role grant-permission myrole readwrite foo |
Grant read permission on the wildcard key pattern foo/* to role myrole:
1 | ./etcdctl --user=root:123 role grant-permission --prefix myrole readwrite foo/ |
role revoke-permission revokes a key from a role.
RPC: RoleRevokePermission
from-key – revoke a permission of keys that are greater than or equal to the given key using byte compare
prefix – revoke a prefix permission
Permission of key <key> is revoked from role <role name> for single key. Permission of range [<key>, <endkey>) is revoked from role <role name> for a key range. Exit code is zero.
1 | ./etcdctl --user=root:123 role revoke-permission myrole foo |
USER provides commands for managing users of etcd.
user add creates a user.
RPC: UserAdd
User <user name> created.
1 | ./etcdctl --user=root:123 user add myuser |
user get lists detailed user information.
RPC: UserGet
Detailed user information.
1 | ./etcdctl --user=root:123 user get myuser |
user delete deletes a user.
RPC: UserDelete
User <user name> deleted.
1 | ./etcdctl --user=root:123 user delete myuser |
user list lists detailed user information.
RPC: UserList
1 | ./etcdctl --user=root:123 user list |
user passwd changes a user’s password.
RPC: UserChangePassword
Password updated.
1 | ./etcdctl --user=root:123 user passwd myuser |
user grant-role grants a role to a user
RPC: UserGrantRole
Role <role name> is granted to user <user name>.
1 | ./etcdctl --user=root:123 user grant-role userA roleA |
user revoke-role revokes a role from a user
RPC: UserRevokeRole
Role <role name> is revoked from user <user name>.
1 | ./etcdctl --user=root:123 user revoke-role userA roleA |
make-mirror mirrors a key prefix in an etcd cluster to a destination etcd cluster.
dest-cacert – TLS certificate authority file for destination cluster
dest-cert – TLS certificate file for destination cluster
dest-key – TLS key file for destination cluster
prefix – The key-value prefix to mirror
dest-prefix – The destination prefix to mirror a prefix to a different prefix in the destination cluster
no-dest-prefix – Mirror key-values to the root of the destination cluster
dest-insecure-transport – Disable transport security for client connections
The approximate total number of keys transferred to the destination cluster, updated every 30 seconds.
1 | ./etcdctl make-mirror mirror.example.com:2379 |
Migrates keys in a v2 store to a v3 mvcc store. Users should run migration command for all members in the cluster.
data-dir – Path to the data directory
wal-dir – Path to the WAL directory
transformer – Path to the user-provided transformer program (default if not provided)
No output on success.
If user does not provide a transformer program, migrate command will use the default transformer. The default transformer transforms storev2 formatted keys into mvcc formatted keys according to the following Go program:
1 | func transform(n *storev2.Node) *mvccpb.KeyValue { |
Users can provide a customized 1:n transformer function that transforms a key from the v2 store to any number of keys in the mvcc store. The migration program writes JSON formatted v2 store keys to the transformer program’s stdin, reads protobuf formatted mvcc keys back from the transformer program’s stdout, and finishes migration by saving the transformed keys into the mvcc store.
The provided transformer should read until EOF and flush the stdout before exiting to ensure data integrity.
1 | ./etcdctl migrate --data-dir=/var/etcd --transformer=k8s-transformer |
Prints the version of etcdctl.
Prints etcd version and API version.
1 | ./etcdctl version |
CHECK provides commands for checking properties of the etcd cluster.
CHECK PERF checks the performance of the etcd cluster for 60 seconds. Running the check perf often can create a large keyspace history which can be auto compacted and defragmented using the --auto-compact and --auto-defrag options as described below.
RPC: CheckPerf
load – the performance check’s workload model. Accepted workloads: s(small), m(medium), l(large), xl(xLarge)
prefix – the prefix for writing the performance check’s keys.
auto-compact – if true, compact storage with last revision after test is finished.
auto-defrag – if true, defragment storage after test is finished.
Prints the result of performance check on different criteria like throughput. Also prints an overall status of the check as pass or fail.
Shows examples of both, pass and fail, status. The failure is due to the fact that a large workload was tried on a single node etcd cluster running on a laptop environment created for development and testing purpose.
1 | ./etcdctl check perf --load="s" |
CHECK DATASCALE checks the memory usage of holding data for different workloads on a given server endpoint. Running the check datascale often can create a large keyspace history which can be auto compacted and defragmented using the --auto-compact and --auto-defrag options as described below.
RPC: CheckDatascale
load – the datascale check’s workload model. Accepted workloads: s(small), m(medium), l(large), xl(xLarge)
prefix – the prefix for writing the datascale check’s keys.
auto-compact – if true, compact storage with last revision after test is finished.
auto-defrag – if true, defragment storage after test is finished.
Prints the system memory usage for a given workload. Also prints status of compact and defragment if related options are passed.
1 | ./etcdctl check datascale --load="s" --auto-compact=true --auto-defrag=true |
For all commands, a successful execution return a zero exit code. All failures will return non-zero exit codes.
All commands accept an output format by setting -w or --write-out. All commands default to the “simple” output format, which is meant to be human-readable. The simple format is listed in each command’s Output description since it is customized for each command. If a command has a corresponding RPC, it will respect all output formats.
If a command fails, returning a non-zero exit code, an error string will be written to standard error regardless of output format.
A format meant to be easy to parse and human-readable. Specific to each command.
The JSON encoding of the command’s RPC response. Since etcd’s RPCs use byte strings, the JSON output will encode keys and values in base64.
Some commands without an RPC also support JSON; see the command’s Output description.
The protobuf encoding of the command’s RPC response. If an RPC is streaming, the stream messages will be concetenated. If an RPC is not given for a command, the protobuf output is not defined.
An output format similar to JSON but meant to parse with coreutils. For an integer field named Field, it writes a line in the format "Field" : %d where %d is go’s integer formatting. For byte array fields, it writes "Field" : %q where %q is go’s quoted string formatting (e.g., []byte{'a', '\n'} is written as "a\n").
etcdctl is still in its early stage. We try out best to ensure fully compatible releases, however we might break compatibility to fix bugs or improve commands. If we intend to release a version of etcdctl with backward incompatibilities, we will provide notice prior to release and have instructions on how to upgrade.
Input includes the command name, its flags, and its arguments. We ensure backward compatibility of the input of normal commands in non-interactive mode.
Output includes output from etcdctl and its exit code. etcdctl provides simple output format by default.
We ensure compatibility for the simple output format of normal commands in non-interactive mode. Currently, we do not ensure
backward compatibility for JSON format and the format in non-interactive mode. Currently, we do not ensure backward compatibility of utility commands.
参考：https://www.cnblogs.com/fuyuteng/p/11598768.html
kubernetes service 原理解析 - 知乎 (zhihu.com)
在 kubernetes 中，当创建带有多个副本的 deployment 时，kubernetes 会创建出多个 pod，此时即一个服务后端有多个容器，那么在 kubernetes 中负载均衡怎么做，容器漂移后 ip 也会发生变化，如何做服务发现以及会话保持？这就是 service 的作用，service 是一组具有相同 label pod 集合的抽象，集群内外的各个服务可以通过 service 进行互相通信，当创建一个 service 对象时也会对应创建一个 endpoint 对象，endpoint 是用来做容器发现的，service 只是将多个 pod 进行关联，实际的路由转发都是由 kubernetes 中的 kube-proxy 组件来实现，因此，service 必须结合 kube-proxy 使用，kube-proxy 组件可以运行在 kubernetes 集群中的每一个节点上也可以只运行在单独的几个节点上，其会根据 service 和 endpoints 的变动来改变节点上 iptables 或者 ipvs 中保存的路由规则
service 资源基于标签选择器将一组 pod 定义成一个逻辑组合，并通过自己的 ip 地址和端口调度代理请求至组内 pod 的对象之上，它向客户隐藏了真实的、处理用户请求的 pod 资源，使得客户端的请求看上去像是由 service 直接处理并进行响应一样
Service 对象的 IP 地址也称为 Cluster IP，是一种 VIP（虚拟 IP），k8s 集群内部的 VIP
service 网段不能跟机房网络、docker 网段、容器网段冲突，否则可能会导致网络不通
Service 以负载均衡的方式进行流量调度，Service 和 Pod 之间松耦合，创建 Service 和 Pod 的任务可由不同的用户分别完成
Service 通过 API Server 实时监控（watch）标签选择器匹配到的后端 Pod，不过 Service 并不直接链接至 Pod，它们中间还有一个中间层 －－Endpoints资源对象，默认情况下，创建 Service 对象时，其关联的 Endpoints 对象会自动创建
endpoints controller 是负责生成和维护所有 endpoints 对象的控制器，监听 service 和对应 pod 的变化，更新对应 service 的 endpoints 对象。当用户创建 service 后 endpoints controller 会监听 pod 的状态，当 pod 处于 running 且准备就绪时，endpoints controller 会将 pod ip 记录到 endpoints 对象中，因此，service 的容器发现是通过 endpoints 来实现的。而 kube-proxy 会监听 service 和 endpoints 的更新并调用其代理模块在主机上刷新路由转发规则
Endpoints 是一个由 IP 地址和端口组成的列表，这些 IP 和端口来自于其 Service 关联的 Pod
每个节点上的 kube-proxy 组件 watch 各 Service 及其关联的 Endpoints，如果有变动，就会实时更新当前节点上相应的 iptables 或 ipvs 规则，确保 Cluster IP 的流量能调度到 Endpoints
简单来讲，一个 Service 对象就是一个 Node 上的这些 iptables 和 ipvs 规则
pod 之间通信，一般不会 pod 直接访问 pod，而是 pod 先访问 service，然后 service 再到 pod
关于将 Cluster IP 的流量能调度到 Endpoints，有三种方式：userspace 代理、iptables 代理、ipvs 代理
userspace 代理
1.1 版本之前的默认代理模型，效率低
iptables 代理
通过 iptables 进行目标地址转换和流量调度，缺点是不会在后端 Pod 资源无响应时自动进行重定向
ipvs 代理
和 iptables 代理模型的区别仅在于，流量的调度功能由 ipvs 实现，其他功能仍由 iptables 完成
service 支持的类型也就是 kubernetes 中服务暴露的方式，默认有四种：ClusterIP、NodePort、LoadBalancer、ExternelName
kubernetes 集群默认的服务暴露方式，它只能用于集群内部通信，可以被各 pod 访问，其访问方式为：
1 | pod ---> ClusterIP:ServicePort --> (iptables)DNAT --> PodIP:containePort |
如果想要在集群外访问集群内部的服务，可以使用 NodePort 类型的 service，在集群内部署了 kube-proxy 的节点打开一个指定的端口，将访问 node 此端口的流量直接发送到这个端口，然后会被转发到 service 后端真实的服务进行访问。Nodeport 构建在 ClusterIP 上，其访问链路如下所示：
1 | client ---> NodeIP:NodePort ---> ClusterIP:ServicePort ---> (iptables)DNAT ---> PodIP:containePort |
主要在公有云如阿里云、AWS 上使用，LoadBalancer 构建在 nodePort 基础之上，通过公有云服务商提供的负载均衡器将 k8s 集群中的服务暴露到外网，云厂商的 LoadBalancer 会给用户分配一个 IP，之后通过该 IP 的流量会转发到你的 service 上
LoadBalancer service 类型的结构如下图所示：
通过 CNAME 将 service 与 externalName 的值(比如：http://foo.bar.example.com)映射起来，这种方式用的比较少。
Pod 与 Service 的 DNS：https://kubernetes.io/zh/docs/concepts/services-networking/dns-pod-service/
虽然 service 的 endpoints 解决了容器发现问题，但不提前知道 service 的 Cluster IP，怎么发现 service 服务呢？service 当前支持两种类型的服务发现机制，一种是通过环境变量，另一种是通过 DNS。在这两种方案中，建议使用后者：
在集群中部署 CoreDNS 服务， 来达到集群内部的 pod 通过 DNS 的方式进行集群内部各个服务之间的通讯
当前 kubernetes 集群默认使用 CoreDNS 作为默认的 DNS 服务，主要原因是 CoreDNS 是基于 Plugin 的方式进行扩展的，简单，灵活，并且不完全被 Kubernetes 所捆绑
1 | apiVersion: v1 |
1 | apiVersion: v1 |
当不需要负载均衡以及单独的 ClusterIP 时，可以通过指定 spec.clusterIP 的值为 None 来创建 Headless service，它会给一个集群内部的每个成员提供一个唯一的 DNS 域名来作为每个成员的网络标识，集群内部成员之间使用域名通信。
deployment 中对应的服务是 service，而 statefulset 中与之对应的服务就是 headless service
1 | apiVersion: v1 |
https://kubernetes.io/zh/docs/concepts/services-networking/ingress/
https://kubernetes.io/zh/docs/concepts/services-networking/ingress-controllers/
上面介绍的 ClusterIP 、NodePort 、LoadBalancer 都是基于 ip 和 port 做负载均衡，属于四层负载均衡
Ingress 可以作用于多个 service，被称为 service 的 service，作为集群内部服务的入口，Ingress 其实就是七层的反向代理，可以根据不同的 url，将请求转发到不同的 service 上
Ingress 的结构如下图所示：
kube-proxy 监听 node 的指定端口，将此端口的流量转发到 ingress，然后 ingress 再转发到不同的 service
1 | 反正都是实现七层代理，也可以使用deployment创建一组pod，提供nginx服务，实现代替ingress的效果： |
完全不使用 k8s 内置的 service，而是通过注册中心自动发现 pod 地址，如果开发有实力，推荐使用这种方式
网上的教程基本都给 dumpcap 设置 suid，修改 dumpcap 的属组为 wireshark，将 whoami 添加到 wireshark 附属组。其实后面的都是多余操作，只需给 dumpcap 设置 suid 即可。
1 | sudo chmod u+s /usr/bin/dumpcap |
kubernetes：容器的管理和编排系统
k8s 由多个组件组成，部署在一群服务器之上，将所有服务器整合成一个资源池，然后向客户端提供各种接口， 客户端只需要调用相应接口就可以管理容器，至于底层容器具体跑在哪台服务器，不可见也不需要关心
针对各种特定的业务，尤其是比较依赖工程师经验的业务（例如数据库集群宕机后的数据恢复、各种集群的扩缩容），可以将一系列复杂操作代码化，这个代码在 k8s 中就叫 operator，只要用好各种 operator，就可以方便高效的解决各种问题，这样，运维工程师的主要工作就变成了维护 k8s，确保 k8s 自身能够良好运行
k8s 内置了各种 operator，但是这些 operator 更重视通用性，很难完全匹配实际工作需要，所以就需要对 k8s 进行二次开发，编写各种 operator，这也是 SRE 工程师的必备技能之一
operator 能单独管理应用集群，实现复杂操作；controllor：控制器，只能实现简单的容器操作
开发人员为 k8s 开发应用程序的时候，通常不会完整的部署一个分布式 k8s 集群，而是使用一个叫做 MiniKube，它可以在单机上模拟出一个完整意义上的 k8s 集群
资源池中的各个服务器叫做节点，节点有两种：
k8s 组件分为三种： 控制平面组件、Node 组件、Addons
https://kubernetes.io/docs/concepts/overview/components/
控制平面（control plane）管理 Node 和 Node 上的 Pods
控制平面组件可以分别运行在任意节点上，但是为了简单，通常会将所有控制平面组件运行在同一个节点上，还可以以副本的形式运行在多个节点上，然后禁止在这种节点上运行 pod，这种节点就叫做 Master Node（后文简称 Master），当集群中只有一个 Master 时，就是单控制平面，有多个 Master 时，就是多控制平面，生产中肯定是多控制平面，但是学习中一般只使用单控制平面
https 服务器，监听在 6443 端口，它将 k8s 集群内的一切都抽象成资源，提供 RESTful 风格的 API，对资源（对象）进行增删改查等管理操作
apiserver 是整个 k8s 系统的总线，所有组件之间，都是通过它进行协同，它是唯一可以存储 k8s 集群的状态信息的组件（储存在 Etcd）
生产中，apiserver 需要做冗余，因为无状态，所以最少部署两个 apiserver，因为是 https 服务器，所以需要做四层负载，使用 Nginx、HAProxy、LVS 均可，然后搭配 keepalived 给负载均衡做高可用
关于健康监测，分为 AH（主动监测）和 PH（被动监测或者叫异常值探测）
控制器管理器，负责管理控制器，真正意义上让 k8s 所有功能得以实现的控制中心，controller-manager 中有很多 controller（deployment 等数十种），这些 controller 才是真正意义上的 k8s 控制中心，负责集群内的 Node、Pod 副本、服务端点（Endpoint）、命名空间（Namespace）、服务账号（ServiceAccount）、资源定额（ResourceQuota）的管理
当某个 Node 意外宕机时，Controller Manager 会及时发现并执行自动化修复流程，确保集群始终处于预期（yaml 配置文件指定）的工作状态
k8s 可以把运维人员日常重复性的工作代码化，就是将多 controller 打包起来，单一运行
默认监听本机的 10252 端口
controller loop：控制循环
调度器，调度 pod，它的核心作用就是运行应用，scheduler 时刻关注着每个节点的资源可用量，以及运行 pod 所需的资源量，让二者达到最佳匹配，让 pod 以最好的状态运行
在整个系统中起”承上启下”作用，承上：负责接收 Controller Manager 创建的新的 Pod，为其选择一个合适的 Node；启下：Node 上的 kubelet 接管 Pod 的生命周期
1 | 通过调度算法为待调度Pod列表的每个Pod从可用Node列表中选择一个最适合的Node，并将信息写入etcd中node节点上的kubelet通过API Server监听到kubernetes Scheduler产生的Pod绑定信息，然后获取对应的Pod清 |
https://etcd.io/
https://github.com/etcd-io/etcd
第三方、非 k8s 内置，它的目标是构建一个高可用的分布式键值(key-value)数据库，为避免脑裂，通常部署 3 个或 5 个节点
1 | 完全复制 # 集群中的每个节点都可以使用完整的存档 |
etcd 有多个不同的 API 访问版本，v1 版本已经废弃，etcd v2 和 v3 本质上是共享同一套 raft 协议代码的两个独立的应用，接口不一样，存储不一样，数据互相隔离。也就是说如果从 Etcd v2 升级到 Etcd v3，原来 v2 的数据还是只能用 v2 的接口访问，v3 的接口创建的数据也只能访问通过 v3 的接口访问
以下以内容以 v3 为准
etcdctl 是 etcd 的命令行客户端工具
1 | etcdctl [options] command [command options] [arguments...] |
1 | etcdctl member list |
验证成员状态：
1 | $etcdctl endpoint health \ |
增 put
1 | etcdctl put [options] <key> <value> (<value> can also be given from stdin) [flags] |
删 del
1 | etcdctl del [options] <key> [range_end] [flags] |
改 put
直接覆盖即可
1 | $etcdctl put /testkey "test data2" |
查 get
1 | etcdctl get [options] <key> [range_end] [flags] |
etcd v3 的 watch 机制支持 watch 某个固定的 key，也支持 watch 一个范围，发生变化就主动触发通知客户端
相比 Etcd v2, Etcd v3 的一些主要变化：
1 | 1. 接口通过grpc提供rpc接口，放弃了v2的http接口，优势是长连接效率提升明显，缺点是使用不如以前方便，尤其对不方便维护长连接的场景。 |
watch 测试：
1 | # 在 etcd node1 上watch一个key，没有此 key 也可以执行 watch，后期可以再创建 |
v2 版本数据备份与恢复：
1 | # 备份 |
v3 版本数据备份与恢复：
1 | etcdctl snapshot <subcommand> [flags] |
1 | $etcdctl snapshot save snapshot.db # 备份 |
略…
Node 组件运行在所有的节点上，包括 Master
与 api server 建立联系，监视 api server 中与自己 node 相关的 pod 的变动信息，执行指令操作
在 kubernetes 集群中，每个 Node 节点都会启动 kubelet 进程，处理 Master 节点下发到本节点的任务，管理 Pod 和其中的容器。kubelet 会在 API Server 上注册节点信息，定期向 Master 汇报节点资源使用情况，并通过 cAdvisor（顾问）监控容器和节点资源，可以把 kubelet 理解成 Server/Agent 架构中的 agent，kubelet 是 Node 上的 pod 管家
https://kubernetes.io/zh/docs/concepts/services-networking/service/
https://kubernetes.io/zh/docs/reference/command-line-tools-reference/kube-proxy/
守护进程，管理当前节点的 iptables 或 ipvs 规则，而且管理的只是和 service 相关的规则
监控 service，把集群上的每一个 service 的定义转换为本地的 ipvs 或 iptables 规则
kube-proxy 是运行在集群中的每个节点上的网络代理，实现了 Kubernetes 服务概念的一部分
kube-proxy 维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络会话到 Pods 进行网络通信
kube-proxy 使用操作系统包过滤层（如果有的话）并且它是可用的。否则，kube-proxy 将自己转发流量
通常是 docker，其他类型的容器也支持
附加组件扩展了 Kubernetes 的功能
插件使用 Kubernetes 资源(DaemonSet, Deployment，等等)来实现集群特性。因为它们提供了集群级的特性，所以插件的命名空间资源属于 kube-system 命名空间
CoreDNS，k8s 中，DNS 是至关重要的，所有的访问都不会基于 ip，而是基于 name，name 再通过 DNS 解析成 ip
prometheus
EFK、LG
入栈流量控制器，是对集群中服务的外部访问进行管理的 API 对象，典型的访问方式是 HTTP。
附件千千万，按需部署
CNI：Container Network Interface，容器网络接口
kubernetes 的网络插件遵从 CNI 规范的 v0.4.0 版本
网络插件有很多，最常用的是 flannel 和 Project Calico，生产环境用后者的最多
跨主机 pod 之间通信，有两种虚拟网络，有两种：overlay 和 underlay
OverLay 其实就是一种隧道技术，VXLAN，NVGRE 及 STT 是典型的三种隧道技术，它们都是通过隧道技术实现大二层网络。将原生态的二层数据帧报文进行封装后在通过隧道进行传输。总之，通过 OverLay 技术，我们在对物理网络不做任何改造的情况下，通过隧道技术在现有的物理网络上创建了一个或多个逻辑网络即虚拟网络，有效解决了物理数据中心，尤其是云数据中心存在 的诸多问题，实现了数据中心的自动化和智能化
以 flannel 为例，默认网段 10.224.1.0/16，flannel 在每个节点创建一个网卡 flannel.1，这是一个隧道，网段 10.2441.0/32 - 10.244.255/32，而每个节点上的容器的 ip 为 10.244.x.1/24 - 10.244.x.254/24，也就是说 flannel 默认支持最多 256 个节点，每个节点上又最多支持 256 个容器
UnderLay 指的是物理网络，它由物理设备和物理链路组成。常见的物理设备有交换机、路由器、防火墙、负载均衡、入侵检测、行为管理等，这些设备通过特定的链路连接起来形成了一个传统的物理网络，这样的物理网络，我们称之为 UnderLay 网络
UnderLay 是底层网络，负责互联互通而 Overlay 是基于隧道技术实现的，overlay 的流量需要跑在 underlay 之上
Pod、Deployment、Service 等等，反映在 Etcd 中，就是一张张的表
kube-apiserver 以群组分区资源，群组化管理的 api 使得其可以更轻松地进行扩展，常用的 api 群组分为两类：
/apis/$GROUP_NAME/$VERSION，例如 /apis/apps/v1/api/$VERSION，即 /api/v1打印 kube-apiserver 支持的所有资源：
1 | kubectl api-resources |
资源表中的每一条数据项就是一个对象，例如 Pod 表中的数据项就是 Pod 对象。所以资源表通常不叫 Pod 表、Deployment 表…，而是叫做 PodList、DeploymentList…
三种方式
配置清单：
1 | # 配置清单的规范叫做资源规范,范例： |
资源清单是 yml 格式，api-server 会自动转成 json 格式
如果实际状态和期望状态有出入，控制器的控制循环就会监控到差异，然后将需要做出的更改提交到 apiserver，调度器 scheduler 监控到 apiserver 中有未执行的操作，就会去找适合执行操作的 node，然后提交到 apiserver，kubelet 监控到 apiserver 中有关于自己节点的操作，就会执行操作，将执行结果返回给 apiserver，apiserver 再更新实际状态
1 | domain:6643/apis/$GROUP_NAME/$VERSION/namespaces/$NAMESPACE/$NAME/$API_RESOURCE_NAME |
以下三种访问方式是一样的：
1 | # 方式一，这种方式最方便 |
注：1.20 之前的版本可以直接curl 127.0.0.1:8080，并且通过--insecure-port可以修改默认的 8080 端口，1.20.4 之后的版本取消了这种不安全的访问方式，只能通过以上方式三，先kubectl proxy代理一下，默认端口也改成了 8001
The kube-apiserver ability to serve on an insecure port, deprecated since v1.10, has been removed. The insecure address flags
--addressand--insecure-bind-addresshave no effect in kube-apiserver and will be removed in v1.24. The insecure port flags--portand--insecure-portmay only be set to 0 and will be removed in v1.24. (#95856, @knight42, [SIG API Machinery, Node, Testing])
1 | $kubectl get pods net-test1 -o yaml |
以上返回的数据，每个字段表示的意义可以通过 kubectl explain 查询帮助
1 | kubectl explain <type>.<fieldName>[.<fieldName>] |
1 | $kubectl explain pod.apiVersion |
lease 是分布式系统中一个常见的概念，用于代表一个分布式租约。典型情况下，在分布式系统中需要去检测一个节点是否存活的时，就需要租约机制。
上图示例中的代码示例首先创建了一个 10s 的租约，如果创建租约后不做任何的操作，那么 10s 之后，这个租约就会自动过期。接着将 key1 和 key2 两个 key value 绑定到这个租约之上，这样当租约过期时 etcd 就会自动清理掉 key1 和 key2，使得节点 key1 和 key2 具备了超时自动删除的能力。
如果希望这个租约永不过期，需要周期性的调用 KeeyAlive 方法刷新租约。比如说需要检测分布式系统中一个进程是否存活，可以在进程中去创建一个租约，并在该进程中周期性的调用 KeepAlive 的方法。如果一切正常，该节点的租约会一致保持，如果这个进程挂掉了，最终这个租约就会自动过期。
在 etcd 中，允许将多个 key 关联在同一个 lease 之上，这个设计是非常巧妙的，可以大幅减少 lease 对象刷新带来的开销。试想一下，如果有大量的 key 都需要支持类似的租约机制，每一个 key 都需要独立的去刷新租约，这会给 etcd 带来非常大的压力。通过多个 key 绑定在同一个 lease 的模式，我们可以将超时间相似的 key 聚合在一起，从而大幅减小租约刷新的开销，在不失灵活性同时能够大幅提高 etcd 支持的使用规模。
tomcat 默认的格式比较简单，包含 ip、date、method、url、status code 等信息，例如：
1 | 10.0.0.1 - - [06/Mar/2021:09:26:09 +0800] "GET / HTTP/1.1" 200 11156 |
为了 kibana 能单独统计每个字段，需要日志记录成 json 格式，当然也可以是其他格式，只要有对应的 codec 插件可以解析就行
1 | [root@elk2-ljk conf]$pwd |
百度搜索 “tomcat 日志格式” 或 “apache 日志格式”，下面是部分格式说明：
1 | ％a - 远程IP地址 |
logstash 配置文件：
1 | input { |
重启 logstash，注意要以 root 用户身份启动，否则无法采集数据
1 | [root@elk2-ljk conf.d]$systemctl restart logstash.service |
基于 java 开发的应用，都会有 java 日志，java 日志会记录 java 的报错信息，但是一个报错会产生多行日志，例如：
为了方便观察，需要将一个报错的多行日志合并为一行，以 elasticsearch 为例：
1 | input { |
查看 kibana：
和采集 tomcat 日志类似，重点是把 nginx 日志修改为 json 格式
1 | # 注意：log_format要写在server外面 |
场景：没有安装 logstash 的服务器（A），向安装了 logstash 的服务器（B）发送日志信息，这个场景不多
实现：A 通过 nc 命令给 B 发送日志信息，B 监听本地的对应端口，接收数据
A：客户端
1 | [root@elk2-ljk ~]$nc 10.0.1.121 9889 |
B：服务端
1 | input { |
有些设备无法安装 logstash，例如 路由器、交换机，但是厂家内置了 rsyslog 功能，这里以 haproxy 为例
1 | # 1. haproxy.cfg 定义haproxy的日志设备为local6 |
考虑到 elasticsearch 的性能问题，通常不会直接往 elasticsearch 写日志，会加 redis 或 kafka 缓冲一下
从左向右看，当要访问 ELK 日志统计平台的时候，首先访问的是两台 nginx+keepalived 做的负载高可用，访问的地址是 keepalived 的 IP，当一台 nginx 代理服务器挂掉之后也不影响访问，然后 nginx 将请求转发到 kibana，kibana 再去 elasticsearch 获取数据，elasticsearch 是两台做的集群，数据会随机保存在任意一台 elasticsearch 服务器，redis 服务器做数据的临时保存，避免 web 服务器日志量过大的时候造成的数据收集与保存不一致导致的日志丢失，可以临时保存到 redis，redis 可以是集群，然后再由 logstash 服务器在非高峰时期从 redis 持续的取出即可，另外有一台 mysql 数据库服务器，用于持久化保存特定的数据，web 服务器的日志由 filebeat 收集之后发送给另外的一台 logstash，再有其写入到 redis 即可完成日志的收集，从图中可以看出，redis 服务器处于前端结合的最中间，其左右都要依赖于 redis 的正常运行，web 服务删个日志经过 filebeat 收集之后通过日志转发层的 logstash 写入到 redis 不同的 key 当中，然后提取层 logstash 再从 redis 将数据提取并安按照不同的类型写入到 elasticsearch 的不同 index 当中，用户最终通过 nginx 代理的 kibana 查看到收集到的日志的具体内容
https://www.elastic.co/guide/en/logstash/current/plugins-filters-geoip.html
写入数据库的目的是用于持久化保存重要数据，比如状态码、客户端 IP、客户端浏览器版本等等，用于后期按月做数据统计等
写个脚本从，定期从 elasticsearch 中获取数据，写入到 PostgreSQL
https://www.elastic.co/cn/what-is/elk-stack
ELK 全称 ELK Stack，它的更新换代产品叫 Elastic Stack
ELK = Elasticsearch + Logstash + Kibana
https://www.elastic.co/cn/what-is/elasticsearch
Logstash 是 Elastic Stack 的核心产品之一，可用来对数据进行聚合和处理，并将数据发送到 Elasticsearch。Logstash 是一个开源的服务器端数据处理管道，允许您在将数据索引到 Elasticsearch 之前同时从多个来源采集数据，并对数据进行充实和转换。
https://www.elastic.co/cn/what-is/kibana
ELK 组件在海量日志系统的运维中，可用于解决以下主要问题：
参考博客：https://www.cnblogs.com/qdhxhz/p/11448451.html
重点理解 index 和 document 这两个概念：index（索引）类似 kafka 的 topic，oss 的 bucket，要尽量控制 index 的数量；index 中的单条数据称为 document（文档），相当于 mysql 表中的行
之前的版本中，索引和文档中间还有个 type（类型）的概念，每个索引下可以建立多个 type，document 存储时需要指定 index 和 type，因为一个 index 中的 type 并不隔离，document 不能重名，所以 type 并没有多少意义。从 7.0 版本开始，一个 index 只能建一个名为_doc 的 type，8.0.0 以后将完全取消
下面是一个 document 的源数据：
_index：文档所属索引名称_type：文档所属类型名_id：doc 主键，写入时指定，如果不指定，则系统自动生成一个唯一的 UUID 值_version：doc 版本信息，保证 doc 的变更能以正确的顺序执行，避免乱序造成的数据丢失_seq_no：严格递增的顺序号，shard 级别严格递增，保证后写入的 doc 的_seq_no大于先写入的 doc 的_seq_no_primary_term：和_seq_no一样是一个整数，每当 primary shard 发生重新分配时，比如重启，primary 选举等，_primary_term 会递增 1found：查询的 ID 正确那么 ture, 如果 Id 不正确，就查不到数据，found 字段就是 false_source：文档的原始 JSON 数据elasticsearch 集群中 master 与 slave 的区别：
master：统计各节点状态信息、集群状态信息统计、索引的创建和删除、索引分配的管理、关闭节点等
slave：从 master 同步数据、等待机会成为 master
apt 安装
1 | [root@elk2-ljk src]$dpkg -i elasticsearch-7.11.1-amd64.deb |
主要目录：
1 | /usr/share/elasticsearch # 主目录 |
修改 hosts
1 | [root@elk2-ljk src]$vim /etc/hosts |
修改配置文件 elasticsearch.yml
1 | [root@elk2-ljk /]$grep '^[a-Z]' /etc/elasticsearch/elasticsearch.yml |
修改内存限制
1 | [root@elk2-ljk src]$vim /usr/lib/systemd/system/elasticsearch.service |
1 | [root@elk2-ljk src]$vim /usr/local/elasticsearch/config/jvm.options |
创建数据目录并修改属主
1 | [root@elk2-ljk src]$mkdir -p /data/elasticsearch |
启动
1 | [root@elk1-ljk src]$systemctl start elasticsearch.service # 稍等几分钟 |
启动总是失败，各种报错，解决不了…
插件是为了完成不同的功能，官方提供了一些插件但大部分是收费的，另外也有一些开发爱好者提供的插件，可以实现对 elasticsearch 集群的状态监控与管理配置等功能
在 elasticsearch 5.x 版本以后不再支持直接安装 head 插件，而是需要通过启动一个服务方式
github 地址：https://github.com/mobz/elasticsearch-head
1 | # git太慢，这里用迅雷下载zip包，然后上传 |
过时的插件，只支持 elasticsearc 1.x 或 2.x 的版本
新开源的 elasticsearch 集群 web 管理程序，需要 java11 或者更高版本
github 地址：https://github.com/lmenezes/cerebro
1 | [root@elk2-ljk src]$unzip cerebro-0.9.3.zip |
1 | [root@elk3-ljk ~]$curl http://10.0.1.122:9200/_cluster/health?pretty=true |
如果是单节点，status 会显示 yellow，设置副本数为 0 即可解决：
1 | [root@elk1-ljk ~]$curl -X PUT "10.0.1.121:9200/_settings" -H 'Content-Type: application/json' -d' {"number_of_replicas":0}' |
或者：
官方参考文档：https://www.elastic.co/guide/en/logstash/current/index.html
logstash 是一个具有 3 个阶段的处理管道：输入 –> 过滤器 –> 输出
输入生成事件，过滤器修改数据（日志），输出将数据（日志）发送到其他地方
logstash 依赖 java，可以自己配置 java 环境，如果不配置，logstash 会使用其自带的 openjdk
1 | [root@elk2-ljk src]$dpkg -i logstash-7.11.1-amd64.deb |
1 | [root@elk2-ljk bin]$./logstash --help |
-n：node name，就是节点的 hostname，例如：elk2-ljk.local
-f：从特定的文件或目录加载 logstash 配置。如果给定一个目录，该目录中的所有文件将按字典顺序合并，然后作为单个配置文件进行解析。您还可以指定通配符(globs)，任何匹配的文件将按照上面描述的顺序加载
-e：从命令行加载 logstash 配置，一般不用
-t：检查配置文件是否合法，配合-f 使用，-f 指定配置文件，-t 检查
1 | # 示例：检查test.conf的合法性 |
…
logstash 的输入和输出都依赖插件
不同的插件使用不同的配置，但是所有输入插件都支持以下配置选项：
| 配置项 | 类型 | 说明 |
|---|---|---|
add_field |
hash | Add a field to an event |
codec |
codec | 用于输入数据的编解码器。输入编解码器是一种方便的方法，可以在数据进入输入之前对其进行解码，而不需要在 Logstash 管道中使用单独的过滤器 |
enable_metric |
boolean | Disable or enable metric logging for this specific plugin instance by default we record all the metrics we can, but you can disable metrics collection for a specific plugin. |
id |
string | 唯一的 ID，如果没有指定，logstash 会自动生成一个，尤其是多个相同类型的插件时，强烈建议配置此项，例如有多个 file 输入，应当配置此项防止混淆 |
tags |
array | Add any number of arbitrary tags to your event. This can help with processing later. |
type |
string | 类型，例如收集 /var/log/syslog 日志，type 可以设置为 “system”；收集网站日志，type 可以设置为 “web”。 此项用的较多，一般会根据判断 type 值来进行输出或过滤 |
所有输出插件都支持以下配置选项：
| 配置项 | 类型 | 说明 |
|---|---|---|
codec |
codec | 用于输出数据的编解码器。输出编解码器是一种方便的方法，可以在数据离开输出之前对数据进行编码，而不需要在 Logstash 管道中使用单独的过滤器 |
enable_metric |
boolean | Disable or enable metric logging for this specific plugin instance. By default we record all the metrics we can, but you can disable metrics collection for a specific plugin. |
id |
string | 唯一的 ID，如果没有指定，logstash 会自动生成一个，尤其是多个相同类型的插件时，强烈建议配置此项，例如有多个 file 输出，应当配置此项防止混淆 |
可以看到 input 和 output 插件都支持 codec 配置项，input 的 codec 根据被采集的日志文件确定，如果日志是 json 格式，则 input 插件的 codec 应当设置为 json；而 output 的 codec 根据数据库确定，如果是 elasticsearch，codec 保持默认的 rubydebug 即可，如果是 kafka，codec 应该设置为 json
标准输入
日志输出到文件
| Setting | 说明 | 备注 |
|---|---|---|
path |
日志路径 | 必需 |
start_position |
从文件的开头或者结尾开始采集数据 | ["beginning", "end"] |
stat_interval |
日志收集的时间间隔 | 每个 input 文件都生成一个 .sincedb_xxxxx 文件，这个文件中记录了上次收集日志位置，下次从记录的位置继续收集 |
| Setting | 说明 | 备注 |
|---|---|---|
host |
当 mode 是server，host是监听的地址；当 mode 是 client，host是要连接的地址 |
默认0.0.0.0 |
mode |
server：监听客户端连接；client：连接到服务器； |
[“server”, “client”] |
port |
监听的端口或要连接的端口 | 必需 |
| Setting | 说明 | 备注 |
|---|---|---|
bootstrap_servers |
host1:port1,host2:port2 | |
topics |
要订阅的 topic 列表，默认为[“logstash”] | |
decorate_events |
是否添加一个 kafka 元数据，包含以下信息： topic、consumer_group、partition、offset、key |
布尔值 |
codec |
设置为 json |
标准输出
| Setting | 说明 | 备注 |
|---|---|---|
key |
list（列表）名，或者 channel（频道）名， 至于是哪个取决于 data_type |
|
data_type |
如果data_type为list，将数据 push 到 list；如果 data_type为 channel，将数据发布到 channel； |
[“list”, “channel”] |
host |
redis 主机列表，可以是 hostname 或者 ip 地址 | 数组 |
port |
redis 服务端口，默认 6379 | |
db |
数据库编号，默认 0 | |
password |
身份认证，默认不认证 | 不建议设置密码 |
写个脚本统计 redis 的 key 数量，使用 zabbix-agent 定时执行脚本，一旦 key 超过某个数量，就增加 logstash 数量，从而加快从 redis 中取数据的速度
| Setting | 说明 | 备注 |
|---|---|---|
bootstrap_servers |
host1:port1,host2:port2 | |
topic_id |
主题 | |
codec |
设置为 json |
|
batch_size |
The producer will attempt to batch records together into fewer requests whenever multiple records are being sent to the same partition. This helps performance on both the client and the server. This configuration controls the default batch size in bytes. | 默认 16384 |
合并多行，比如 java 的一个报错，日志中会记录多行，为了方便查看，应该将一个报错的多行日志合并成一行
| Setting | 说明 | 备注 |
|---|---|---|
| pattern | 正则匹配 | 必需 |
| negate | 匹配成功或失败，就开始多行合并 | 布尔值 |
| what | 如果模式匹配，向前多行合并，还是向后多行合并 | 必需，["previous", "next"] |
配置：https://www.elastic.co/guide/en/logstash/current/configuration.html
配置文件结构：https://www.elastic.co/guide/en/logstash/current/configuration-file-structure.html
配置文件语法：https://www.elastic.co/guide/en/logstash/current/event-dependent-configuration.html
使用环境变量：https://www.elastic.co/guide/en/logstash/current/environment-variables.html
配置文件示例：https://www.elastic.co/guide/en/logstash/current/config-examples.html
数据发送到 es：https://www.elastic.co/guide/en/logstash/current/connecting-to-cloud.html
1 | input { |
https://www.elastic.co/guide/en/logstash/current/multiple-pipelines.html
https://elasticstack.blog.csdn.net/article/details/100995868
示例：
1 | # 定义了两个管道 |
效果：
1 | [root@elk2-ljk conf.d]$cat /etc/logstash/conf.d/test.conf |
1 | # 1. 修改被采集日志文件权限，至少让logstash用户可以读 |
时间格式参考：http://joda-time.sourceforge.net/apidocs/org/joda/time/format/DateTimeFormat.html
elasticsearch 输出插件至少指定 hosts 和index，hosts可以指定 hosts 列表
1 | input { |
开源的数据分析和可视化平台，可以 对 Elasticsearch 索引中的数据进行搜索、查看、交互操作，可以很方便的利用图表、表格及地图对数据进行多元化的分析和呈现
1 | [root@elk1-ljk src]$tar zxf kibana-7.11.1-linux-x86_64.tar.gz |
因为笔记本的性能问题，将 elasticsearch 集群缩减为 elasticsearch 单节点，这导致 kibana 无法连接到 elasticsearch，启动失败。解决办法：将 elasticsearch 的数据目录清空，然后重启
1 | [root@elk1-ljk data]$systemctl stop elasticsearch.service # 停止elasticsearch |
https://www.elastic.co/cn/beats/
logstash 基于 java，资源消耗很大，容器等场景，大多跑的都是轻量级的服务，没有必要安装 logstash，就可以用 beats 代替 logstash 做日志收集，beats 基于 go，性能更强，资源占用更低，但是功能也相对简单
beats 是一个系列，具体包含以下类型的采集器：
除了 filebeat，其他的 beat 可以用 zabbix 替代
官方文档：https://www.elastic.co/guide/en/beats/filebeat/current/index.html
配置：只需要配置 input 和 output
1 | # ============================== Filebeat inputs ================== |
示例：
1 |
配套 B 站教程：https://www.bilibili.com/video/BV1Be4y167n9
| IP 地址 | 主机名 | CPU 配置 | 内存配置 | 磁盘配置 | 角色说明 |
|---|---|---|---|---|---|
| 10.0.0.101 | elk101.oldboyedu.com | 2 core | 4G | 20G+ | ES node |
| 10.0.0.102 | elk102.oldboyedu.com | 2 core | 4G | 20G+ | ES node |
| 10.0.0.103 | elk103.oldboyedu.com | 2 core | 4G | 20G+ | ES node |
参考链接：https://mirrors.tuna.tsinghua.edu.cn/help/centos/
1 | # 对于 CentOS 7 |
1 | cat <<EOF >> ~/.bashrc |
1 | sed -ri 's@^#UseDNS yes@UseDNS no@g' /etc/ssh/sshd_config |
1 | systemctl disable --now firewalld && systemctl is-enabled firewalld |
1 | sed -ri 's#(SELINUX=)enforcing#\1disabled#' /etc/selinux/config |
1 | # 1.修改主机列表 |
1 | # 1.安装常⽤的Linux⼯具，您可以⾃定义哈。 |
https://www.elastic.co/cn/downloads/elasticsearch
1 | # 1.安装服务 |
1 | egrep -v "^$|^#" /etc/elasticsearch/elasticsearch.yml |
1 | # 1.elk101同步配置⽂件到集群的其他节点 |
1 | pkill java |
1 | # 1.所有节点启动服务 |
1 | curl elk103:9200/_cat/nodes?v |
1 | yum -y localinstall kibana-7.17.3-x86_64.rpm |
1 | vim /etc/kibana/kibana.yml |
1 | systemctl enable --now kibana |
略。。。
1 | $ ./filebeat --help |
1 | yum -y localinstall filebeat-7.17.3-x86_64.rpm |
1 | mkdir /etc/filebeat/config |
1 | $ filebeat -e -c /etc/filebeat/config/01-stdin-to-console.yml |
1 | ... |
1 | filebeat.inputs: |
1 | filebeat.inputs: |
1 | filebeat.inputs: |
1 | filebeat.inputs: |
1 | filebeat.inputs: |
1 | filebeat.inputs: |
1 | filebeat.inputs: |
1 | filebeat.inputs: |
1 | filebeat.inputs: |
1 | filebeat.inputs: |
1 | # 1.配置nginx的软件源 |
1 | filebeat.inputs: |
1 | # 1. 修改nginx的源⽇志格式 |
1 | # 查看模块 |
1 | filebeat.config.modules: |
/etc/filebeat/modules.d/nginx.yml ⽂件内容：
1 | - module: nginx |
1 | # 1.部署tomcat服务 |
1 | filebeat.inputs: |
1 | # 1.⾃定义tomcat的⽇志格式 |
https://www.elastic.co/guide/en/beats/filebeat/current/multiline-examples.html
multiline.match
Specifies how Filebeat combines matching lines into an event. The settings are after or before. The behavior of these settings depends on what you specify for negate:
Setting for negate |
Setting for match |
Result | Example pattern: ^b |
|---|---|---|---|
false |
after |
Consecutive lines that match the pattern are appended to the previous line that doesn’t match. |  |
false |
before |
Consecutive lines that match the pattern are prepended to the next line that doesn’t match. |  |
true |
after |
Consecutive lines that don’t match the pattern are appended to the previous line that does match. |  |
true |
before |
Consecutive lines that don’t match the pattern are prepended to the next line that does match. |  |
The
aftersetting is equivalent topreviousin Logstash, andbeforeis equivalent tonext.
1 | filebeat.inputs: |
1 | filebeat.inputs: |
1 | filebeat.inputs: |
1 | filebeat.inputs: |
1 | filebeat.inputs: |
1 | filebeat.inputs: |
1 | yum -y install epel-release |
1 | vim /etc/redis.conf |
1 | systemctl start redis |
1 | redis-cli -a oldboyedu -h 10.0.0.101 -p 6379 --raw -n 5 |
1 | filebeat.inputs: |
1 | # 写⼊数据: |
1 | # 1. 完成课堂的所有练习; |
filebeat 实例⼀：
1 | filebeat.inputs: |
filebeat 实例二：
1 | filebeat.inputs: |
1 | filebeat.inputs: |
1 | yum -y localinstall logstash-7.17.3-x86_64.rpm |
1 | # (1)编写配置⽂件 |
1 | input { |
1 | input { |
1 | input { |
1 | # filebeat的配置:(仅供参考) |
1 | # filbeat配置: |
1 | input { |
1 | input { |
1.filebeat-to-redis 参考笔记
1 | filebeat.inputs: |
2.filebeat-to-logstash 参考笔记
1 | filebeat.inputs: |
3.logstash 配置⽂件
1 | input { |
1 | (1)完成课堂的所有练习，要求能够⼿绘架构图; |
1 | [root@elk101.oldboyedu.com ~]$ cat config-logstash/11-many-to-es.conf |
1 | # logstash接受redis示例： |
Grok 是将⾮结构化⽇志数据解析为结构化和可查询的好⽅法。底层原理是基于正则匹配任意⽂本格式。
该⼯具⾮常适合 syslog ⽇志、apache 和其他⽹络服务器⽇志、mysql ⽇志，以及通常为⼈类⽽⾮计算机消耗⽽编写的任何⽇志格式。
内置 120 种匹配模式，当然也可以⾃定义匹配模式:
https://github.com/logstash-plugins/logstash-patterns-core/tree/master/patterns
1 | [root@elk101.oldboyedu.com ~]$ cat config-logstash/14-beat-grok-es.conf |
1 | [root@elk101.oldboyedu.com ~]$ cat config-logstash/15-stdin-grok-stdout.conf |
1 | [root@elk101.oldboyedu.com ~]$ cat config-logstash/16-stdin-grok_custom_patterns-stdout.conf |
1 | [root@elk101.oldboyedu.com ~]$ cat config-logstash/17-beat-grok-es.conf |
1 | [root@elk101.oldboyedu.com ~]$ cat config-logstash/18-beat-grok_date-es.conf |
1 | [root@elk101.oldboyedu.com ~]$ cat config-logstash/19-beat-grok_date_geoip-es.conf |
1 | [root@elk101.oldboyedu.com ~]# cat config-logstash/20-beat-grok_date_geoip_useragent-es.conf |
1 | cat > generate_log.py <<EOF |
1 | [root@elk101.oldboyedu.com ~]# cat config-logstash/21-mutate.conf |
1 | [root@elk101.oldboyedu.com ~]# cat config-logstash/22-beats_tcp-filter-es.conf |
1 | 如上图所示，要求完成以下内容: |
1 | [root@elk102.oldboyedu.com ~]# cat ~/config/38-tomcat-to-logstash.yml |
1 | [root@elk102.oldboyedu.com ~]# cat ~/config/37-nginx-to-logstash.yml |
1 | [root@elk102.oldboyedu.com ~]# cat ~/config/39-apps-to-logstash.yml |
1 | [root@elk101.oldboyedu.com ~]# cat config-logstash/24-homework-01-to-es.conf |
1 | [root@elk101.oldboyedu.com ~]# cat config-logstash/24-homework-02-to-es.conf |
1 | [root@elk101.oldboyedu.com ~]# cat config-logstash/24-homework-03-to-es.conf |
1 | Page View(简称:"PV") |
1 | 客户端IP: |
1 | 带宽: |
1 | 访问资源统计: |
1 | 分析客户端的城市分布: |
1 | 分析客户端的城市分布: |
1 | IP的TopN统计: |
1 | kibana界⾯⿏标依次点击如下: |
1 | # 官⽅连接: https://www.oracle.com/java/technologies/downloads/#java8 |
1 | # (1)下载ES软件 |
1 | 前置知识: |
1 | $ cat > /usr/lib/systemd/system/es.service <<EOF |
1 | # (1)停⽌ES服务并删除集群之前的数据（如果是ES集群扩容就别删除数据了，我这⾥是部署⼀个"⼲净"的集群） |
1 | # (1)解压软件包 |
1 | # (1)解压logstash |
1 | # (1)解压软件包 |
1 | (1)解压es-head组件的软件包 |
1 | (1)下载postman组件 |
1 | (1)完成课堂的所有练习 |
| 数据类型 | 描述 | 举例 |
|---|---|---|
| 字符串 | 要求使⽤双引号（””）引起来的数据 | “oldboyedu” |
| 数字 | 通常指的是 0-9 的所有数字。 | 100 |
| 布尔值 | 只有 true 和 false 两个值 | true |
| 空值 | 只有 null 一个值 | null |
| 数组 | 使⽤⼀对中括号（”[]”）放⼊不同的元素（⽀持⾼级数据类型和基础数据类型） | [“linux”,100,false] |
| 对象 | 使⽤⼀对⼤括号（”{}”）扩起来，⾥⾯的数据使⽤ KEY-VALUE 键值对即可。 | {“class”:”linux80”,”age”:25} |
1 | Restful⻛格程序: |
1 | Document: |
1 | GET http://10.0.0.101:9200/_cat/indices # 查看全部的索引信息 |
1 | PUT http://10.0.0.101:9200/oldboyedu-linux82 # 创建索引并指定分⽚和副本 |
1 | PUT http://10.0.0.101:9200/oldboyedu-linux80/_settings |
1 | DELETE http://10.0.0.101:9200/oldboyedu-linux80 |
1 | POST http://10.0.0.101:9200/_aliases # 添加索引别名 |
1 | POST http://10.0.0.101:9200/oldboyedu-linux80/_close # 关闭索引 |
1 | POST http://10.0.0.101:9200/oldboyedu-linux80/_open # 打开索引 |
推荐阅读: https://www.elastic.co/guide/en/elasticsearch/reference/current/indices.html
1 | POST http://10.0.0.101:9200/teacher/_doc # 创建⽂档不指定"_id" |
1 | GET http://10.0.0.101:9200/teacher/_search # 查看所有的⽂档 |
1 | POST http://10.0.0.101:9200/teacher/_doc/4FHB0IABf2fC857QLdH6 # 全量更新，会覆盖原有的⽂档数据内容。 |
1 | DELETE http://10.0.0.101:9200/teacher/_doc/1001 |
1 | POST http://10.0.0.101:9200/_bulk # 批量创建 |
温馨提示: 对于⽂档的批量写操作，需要使⽤_bulk的 API，⽽对于批量的读操作，需要使⽤_mget的 API。
参考链接:
https://www.elastic.co/guide/en/elasticsearch/reference/7.17/docs-bulk.html
https://www.elastic.co/guide/en/elasticsearch/reference/7.17/docs-multi-get.html
将下⾯的数据存储到 ES 集群：
1 | {"name":"oldboy","hobby":["Linux","思想课"]} |
当写⼊⽂档时，字段的数据类型会被 ES 动态⾃动创建，但有的时候动态创建的类型并符合我们的需求。这个时候就可以使⽤映射解决。
使⽤映射技术，可以对 ES ⽂档的字段类型提前定义我们期望的数据类型，便于后期的处理和搜索。
参考链接：
https://www.elastic.co/guide/en/elasticsearch/reference/7.17/mapping.html
https://www.elastic.co/guide/en/elasticsearch/reference/7.17/mapping-types.html
1 | PUT http://10.0.0.101:9200/oldboyedu-linux80-elk # 创建索引时指定映射关系 |
1 | PUT http://10.0.0.101:9200/oldboyedu-linux80-elk-2022 # 创建索引 |
1 | GET http://10.0.0.101:9200/_analyze |
温馨提示: 标准分词器模式使⽤空格和符号进⾏切割分词的。
1 | GET http://10.0.0.101:9200/_analyze |
温馨提示: 标准分词器默认使⽤单个汉⼦进⾏切割，很明显，并不符合我们国内的使⽤习惯。
下载地址: https://github.com/medcl/elasticsearch-analysis-ik
安装 IK 分词器：
1 | install -d /oldboyedu/softwares/es/plugins/ik -o oldboyedu -g oldboyed |
重启 ES 节点，使之加载插件：
1 | systemctl restart es |
测试 IK 分词器：
1 | GET http://10.0.0.101:9200/_analyze # 细粒度拆分 |
1 | # (1)进⼊到IK分词器的插件安装⽬录 |
1 | # (1)⾃定义分词器 |
1 | (1)将"shopping.json"⽂件的内容使⽤"_bulk"的API批量写⼊ES集群，要求索引名称为"oldboyedu-shopping"; |
1 | { |
1 | 等你来完善... |
1 | POST http://10.0.0.103:9200/_bulk |
1 | # (1)启动filebeat |
索引模板是创建索引的⼀种⽅式。
当数据写⼊指定索引时，如果该索引不存在，则根据索引名称匹配相应索引模板的话，会根据模板的配置⽽建⽴索引。
索引模板仅对新创建的索引⽣效，对已经创建的索引是没有任何作⽤的。
推荐阅读: https://www.elastic.co/guide/en/elasticsearch/reference/7.17/index-templates.html
1 | GET http://10.0.0.103:9200/_template # 查看所有的索引模板 |
1 | POST http://10.0.0.103:9200/_template/oldboyedu-linux80 |
1 | DELETE http://10.0.0.103:9200/_template/oldboyedu-linux80 |
Elasticsearch 提供了基于 JSON 的完整 Query DSL（Domain Specific Language，领域特定语⾔）来定义查询。
1 | POST http://10.0.0.103:9200/oldboyedu-shopping/_search |
1 | POST http://10.0.0.103:9200/oldboyedu-shopping/_search |
1 | POST http://10.0.0.103:9200/oldboyedu-shopping/_search |
1 | POST http://10.0.0.103:9200/oldboyedu-shopping/_search |
1 | POST http://10.0.0.103:9200/oldboyedu-shopping/_search |
1 | POST http://10.0.0.103:9200/oldboyedu-shopping/_search |
1 | POST http://10.0.0.103:9200/oldboyedu-shopping/_search |
1 | POST http://10.0.0.103:9200/oldboyedu-shopping/_search |
1 | POST http://10.0.0.103:9200/oldboyedu-shopping/_search |
1 | POST http://10.0.0.103:9200/oldboyedu-shopping/_search |
1 | POST http://10.0.0.103:9200/oldboyedu-shopping/_search |
1 | POST http://10.0.0.103:9200/oldboyedu-shopping/_search |
1 | POST http://10.0.0.103:9200/oldboyedu-shopping/_search |
1 | POST http://10.0.0.103:9200/oldboyedu-shopping/_search # 统计每个品牌的数量。 |
1 | # (1)下载ES 6的软件包 |
1 | POST http://10.0.0.103:9200/_reindex |
1 | [root@elk101.oldboyedu.com ~]$ cat conf-logstash/03-es-to-es.conf |
1 | # (1)安装jq⼯具 |
1 | 如果您使⽤多种⽅法配置相同的设置，Elasticsearch 会按以下优先顺序应⽤这些设置： |
1 | 集群状态是⼀种内部数据结构，它跟踪每个节点所需的各种信息，包括： |
1 | Cluster Stats API 允许从集群范围的⻆度检索统计信息。返回基本索引指标（分⽚数量、存储⼤⼩、内存使⽤情况）和有关构成集群的当前节点的信息（数量、⻆⾊、操作系统、jvm 版本、内存使⽤情况、cpu 和已安装的插件）。 |
集群分配解释 API 的⽬的是为集群中的分⽚分配提供解释。
对于未分配的分⽚，解释 API 提供了有关未分配分⽚的原因的解释。
对于分配的分⽚，解释 API 解释了为什么分⽚保留在其当前节点上并且没有移动或重新平衡到另⼀个节点。
当您尝试诊断分⽚未分配的原因或分⽚继续保留在其当前节点上的原因时，此 API 可能⾮常有⽤，⽽您可能会对此有所期待。
1 | # (1)分析teacher索引的0号分⽚未分配的原因。 |
reroute 命令允许⼿动更改集群中各个分⽚的分配。
例如，可以将分⽚从⼀个节点显式移动到另⼀个节点，可以取消分配，并且可以将未分配的分⽚显式分配给特定节点。
1 | POST http://10.0.0.101:9200/_cluster/reroute # 将"teacher"索引的0号分⽚从elk102节点移动到elk101节点。 |
推荐阅读: https://www.elastic.co/guide/en/elasticsearch/reference/7.17/cluster-reroute.html
1 | (1)完成课堂的所有练习; |
⾯试题: 分⽚底层时如何⼯作的？
答: 分⽚底层对应的是⼀个 Lucene 库，⽽ Lucene 底层使⽤倒排索引技术实现。
我们 MySQL 为例，⽤ id 字段存储博客⽂章的编号，⽤ context 存储⽂件的内容。
1 | CREATE TABLE blog (id INT PRIMARY KEY AUTO_INCREMENT, contextTEXT); |
此时，如果我们查询⽂章内容包含”Jason Yin”的词汇的时候，就⽐较麻烦了，因为要进⾏全表扫描。
1 | SELECT * FROM blog WHERE context LIKE 'Jason Yin'; |
ES 使⽤⼀种称为”倒排索引”的结构，它适⽤于快速的全⽂检索。
倒排索引中有以下三个专业术语:
1、词条:
指的是最⼩的存储和查询单元，换句话说，指的是您想要查询的关键字(词)。
对应英⽂⽽⾔通常指的是⼀个单词，⽽对于中⽂⽽⾔，对应的是⼀个词组。
2、词典(字典):
它是词条的集合，底层通常基于”Btree+”和”HASHMap”实现。
3、倒排表:
记录了词条出现在什么位置，出现的频率是什么。
倒排表中的每⼀条记录我们称为倒排项。
倒排索引的搜索过程:
综上所述，假设有 10 亿篇⽂章，对于 mysql 不创建索引的情况下，会进⾏全表扫描搜索”JasonYin”。⽽对于 ES ⽽⾔，其只需要将倒排表中返回的 id 进⾏扫描即可，⽽⽆须进⾏全量查询。
1 | ⻆⾊说明: |
事务⽇志存储在哪⾥?
1 | 在索引分⽚⽬录下，取名⽅式如下: |
什么时候删事务⽇志？
1 | 在flush的时候，translog⽂件会被清空。实际的过程是先删掉⽼⽂件，再创建⼀个新⽂件，取名时，序号加1，⽐如图2中，flush后你只会看到 translog-2.tlog，原来的translog-1.tlog已被删除。 |
为什么要删？
1 | 因为数据修改已经写⼊磁盘了，之前的旧的⽇志就⽆⽤武之地了，留着只能⽩嫖存储空间。 |
两种⽅法通常被⽤来解决并发更新时变更不会丢失的解决⽅案:
1、悲观并发控制
这种⽅法被关系型数据库⼴泛使⽤，它假定有变更冲突可能发⽣，因此阻塞访问资源以防⽌冲突。⼀个典型的例⼦是修改⼀⾏数据之前像将其锁住，确保只有获得锁的线程能够对这⾏数据进⾏修改。
2、乐观锁并发控制
ES 中使⽤的这种⽅法假设冲突是不可能发⽣的，并且不会阻塞正在尝试的操作。然⽽，如果源数据在读写当中被修改，更新将会失败。应⽤程序接下来该如果解决冲突。例如，可以重试更新，使⽤新的数据，或者将相关情况报告给⽤户。
1 | # (1)创建⽂档 |
1 | #!/usr/bin/env python3 |
1 | #!/usr/bin/env python3 |
1 | #!/usr/bin/env python3 |
1 | #!/usr/bin/env python3 |
1 | #!/usr/bin/env python3 |
1 | #!/usr/bin/env python3 |
1 | #!/usr/bin/env python3 |
1 | #!/usr/bin/env python3 |
1 | #!/usr/bin/env python3 |
1 | #!/usr/bin/env python3 |
1 | # (1)部署nginx服务 略，参考之前的笔记即可。 |
1 | # (1)⽣成证书⽂件 |
1 | # (1)修改kibana的配置⽂件 |
具体实操⻅视频。
1 | input { |
温馨提示:
建议⼤家不要使⽤ elastic 管理员⽤户给 logstash 程序使⽤，⽽是创建⼀个普通⽤户，并为该⽤户细化权限。
1 | filebeat.inputs: |
温馨提示:
建议⼤家不要使⽤ elastic 管理员⽤户给 filebeat 程序使⽤，⽽是创建⼀个普通⽤户，并为该⽤户细化权限。
SonarQube 是一个用于代码质量管理的开放平台，通过插件机制，SonarQube 可以集成不同的测试
工具，代码分析工具，以及持续集成工具，例如 Hudson/Jenkins 等
略…
官方文档： https://docs.sonarqube.org/latest/analysis/scan/sonarscanner/
顾名思义，扫描器的具体工作就是扫描代码，sonarqube 通过调用扫描器 sonar-scanner 进行代码质量分析
下载地址： https://binaries.sonarsource.com/Distribution/sonar-scanner-cli/
1 | [root@jenkins src]$unzip sonar-scanner-cli-4.6.0.2311.zip |
1 | [root@jenkins src]$unzip sonar-examples-master.zip ^C |
在 sonar-project.properties 这个文件的目录下，执行 sonar-scanner 即可：
1 | [root@jenkins php-sonar-runner]$ll |
web 看测试结果：
上面是命令行执行 sonar-scanner 命令进行测试，可以结合 jenkins 进行测试，无非就是将命令写到脚本里，让 jenkins 自动执行
官方网站： https://jenkins.io/zh/
Jenkins 是开源 CI&CD 软件领导者， 提供超过 1000 个插件来支持构建、部署、自动化， 满足任何项目的需要。
Jenkins 支持各种运行方式，可通过系统包、Docker 或者通过一个独立的 Java 程序
Jenkins 基于 JAVA 实现，安装 Jenkins 前需要先安装 JDK
1 | [root@jenkins ~]$java -version |
1 | $wget https://mirrors.tuna.tsinghua.edu.cn/jenkins/debian-stable/jenkins_2.263.4_all.deb # 清华源下载dep包 |
主要文件：
1 | /etc/default/jenkins |
默认 jenkins 服务使用 jenkins 帐号启动，将文件复制到生产服务器可能会遇到权限问题，需要先 su 到对应的用户，这里学习环境为了方便，修改为 root 用户，注意：工作中还是使用 jenkins 普通用户
1 | [root@jenkins src]$vim /etc/default/jenkins |
先创建用户，然后使用刚创建的用户登录
Jenkins 是完全插件化的服务，我们想实现什么功能，不是改配置文件，而是下载插件
修改更新源为国内清华源：
1 | [root@jenkins src]$cat /var/lib/jenkins/hudson.model.UpdateCenter.xml |
有以下几种安装插件的方式：
在线安装：官网，也是默认的方式，比较慢
在线安装：清华大学镜像源，sed 或者编辑器把 update-center.json 中的 Jenkins 网址替换为清华源
1 | # 将： |
离线安装：手动下载插件，然后放到 /var/lib/jenkins/plugins/，重启 Jenkins 即可
通过 web 界面安装
搜索需要 gitlab（和 gitlab 相连）和 Blue Ocean（显示信息更加好看）的相关插件并安装
默认 jenkins 用户可以执行所有操作，为了更好的分层控制，可以实现基于角色的权限管理，先创建角色和用户，给角色授权，然后把用户管理到角色
安装插件：Role-based Authorization Strategy
如果直接下载失败，可以直接清华源下载，将插件放在 /var/lib/jenkins/plugins 目录下
新建 xiaoming 和 xiaogang 两个用户：
通常选择“构建一个自由风格的软件项目”，新建四个任务：test1-job1、test1-job2、test2-job1、test2-job2
创建全局角色
创建全局读角色，只有读权限
创建 item 角色
创建两个 item 角色，test1-role、test2-role，通过正则匹配分配任务
xiaogang 用户只能看到 test1.* 匹配的项目：test1-job1、test1-job2
xiaoming 用户只能看到 test2.*匹配的项目：test2-job1、test2-job2
邮件发送到组邮件地址，组邮件会转发到组内所有人
需要配置 ssh key （公钥）和 凭据（私钥）
实现 jenkins 服务器到 gitlab 服务器的基于密钥的验证，可以让 jenkins 连接到 gitlab 执行操作
凭据就是私钥，clone 项目的时候，可选择不同的凭据（私钥），只要他在 gitlab 上配置了 key（公钥），如果不指定，就以当前用户的私钥作为凭据去 clone 项目
管理凭据：系统管理 -> 安全 -> Manage Credentials
构建触发器（webhook），有的人称为钩子，实际上是一个 HTTP 回调，其用于在开发人员向 gitlab 提交代码后能够触发 jenkins 自动执行代码构建操作
以下为新建一个开发分支，只有在开发人员向开发（develop）分支提交代码的时候才会触发代码构建，而向主分支提交的代码不会自动构建，需要运维人员手动部署代码到生产环境
生产中千万不要用，测试一般也不用，都是由开发登陆自己的账号，只能看到自己的 job，然后开发自己手动部署
用于多个 job 相互关联，需要串行执行多个 job 的场景，不过这个操作基本不用
例如：克隆代码、编译代码、停止 tomcat、部署代码、启动 tomcat 这些操作使用不同的 job 执行，这些 job 需要串行执行
job 太多需要分类
视图可用于归档 job 进行分组显示，比如将一个业务的 job 放在一个视图显示，最常用的是列表视图
在众多 Job 的场景下，单台 jenkins master 同时执行代码 clone、编译、打包及构建，其性能可能会出现瓶颈从而会影响代码部署效率，影响 jenkins 官方提供了 jenkins 分布式构建，将众多 job 分散运行到不同的 jenkins slave 节点，大幅提高并行 job 的处理能力
slave 节点需要配置与 master 一样的基础运行环境，另外也要创建与 master 相同的数据目录，因为脚本中调用的路径只有相对于 master 的一个路径，此路径在 master 与各 node 节点必须保持一致
1 | # 配置java环境 |
可以限制项目只能在指定的节点中执行：
流水线 pipline 是 Jenkins 中的头等公民，官方介绍；https://www.jenkins.io/zh/doc/book/pipeline/
本质上，Jenkins 是一个自动化引擎，它支持许多自动模式。 流水线向 Jenkins 中添加了一组强大的工具, 支持用例 简单的持续集成到全面的 CD 流水线。通过对一系列的相关任务进行建模, 用户可以利用流水线的很多特性:
流水线是用户定义的一个 CD 流水线模型 。流水线的代码定义了整个的构建过程, 他通常包括构建, 测试和交付应用程序的阶段
每个 node 都是一个 jenkins 节点，可以是 jenkins master 也可以是 jenkins agent，node 是执行 step 的具体服务器
一个 pipline 可以划分为若干个 stage，每个 stage 都是一个操作，比如 clone 代码、代码编译、代码测试和代码部署，阶段是一个逻辑分组，可以跨多个 node 执行
step 是 jenkins pipline 最基本的操作单元，从在服务器创建目录到构建容器镜像，由各类 Jenkins 插件提供实现，例如： sh “make”
对 Jenkins 流水线的定义被写在一个文本文件中： Jenkinsfile，该文件可以被提交到项目的源代码的控制仓库。 这是”流水线即代码”的基础；将 CD 流水线作为应用程序的一部分，像其他代码一样进行版本化和审查。
Jenkinsfile 能使用两种语法进行编写，声明式和脚本化。
声明式和脚本化的流水线从根本上是不同的。 声明式流水线的是 Jenkins 流水线更近的特性。
在声明式流水线语法中, pipeline 块定义了整个流水线中完成的所有的工作。
示例：
1 | Jenkinsfile (Declarative Pipeline) |
stage块的信息。如 above 所述, 在脚本化流水线语法中，stage 块是可选的。agent。…
官方文档：https://www.jenkins.io/zh/doc/book/pipeline/syntax/
1 | node { |
立即构建，查看输出信息：
1 | master分支：稳定的分支 |
master 分支是上线的代码，develop 是开发中的代码，lujinkai、xiaoming 等是开发人员分支，开发在自己的分支里面写代码，然后下班前提交、合并到 develop 分支，等项目开发、测试完，最后再合并到 master 分支，然后上线
1 | [root@kafka2 testproject]$git branch # 查看本地分支 |
在 gitlab 创建个人分支 lujinkai
克隆 master 分支到本地
1 | [root@dev ~]$git clone git@gitlab.ljk.local:testgroup/testproject.git |
切换到自己分支
1 | [root@dev ~]$git checkout lujinkai |
将 develop 分支拉下来和个人分支合并
1 | [root@dev ~]$git pull origin develop |
以上命令是把远程分支 develop 拉下来，然后合并到当前分支 lujinkai，或者可以拆分成以下步骤：
1 | git checkout develop # 切换到分支develop |
开发代码
下班了，需要提交代码，但是在提交之前最好再执行一遍上一步，因为在你写代码的过程中，develop 分支可能有其他人提交
1 | [root@dev ~]$git pull origin develop |
添加文件到本地缓存区
1 | [root@dev ~]$git add . # . 表示当前目录下的所有文件 |
提交内容到本地分支上
1 | git commit -m "注释, 提交说明" |
上传本地分支到远程分支
1 | git push |
之后每天 3 - 9 步骤走一遍
1 | git clone [URL] && cd [仓库名] # 克隆git仓库,进入仓库 |
DevOps 是 Development 和 Operations 的组合，也就是开发和运维的简写
持续集成是指多名开发者在开发不同功能代码的过程当中，可以频繁的将代码行合并到一起并切相互不影响工作
是基于某种工具或平台实现代码自动化的构建、测试和部署到线上环境以实现交付高质量的产品,持续部署在某种程度上代表了一个开发团队的更新迭代速率
持续交付是在持续部署的基础之上，将产品交付到线上环境，因此持续交付是产品价值的一种交付，是产品价值的一种盈利的实现
GitLab 和 GitHub 一样属于第三方基于 Git 开发的作品，免费且开源，与 Github 类似，可以注册用户，任意提交你的代码，添加 SSHKey 等等。不同的是，GitLab 是可以部署到自己的服务器上，简单来说可把 GitLab 看作个人版的 GitHub
Git 在每个用户都有一个完整的服务器，然后再有一个中央服务器，用户可以先将代码提交到本地，没有网络也可以先提交到本地，然后在有网络的时候再提交到中央服务器，这样就大大方便了开发者，而相比 CVS 和 SVN 都是集中式的版本控制系统，工作的时候需要先从中央服务器获 取最新的代码，改完之后需要提交，如果是一个比较大的文件则需要足够快的网络才能快速提交完成，而使用分布式的版本控制系统，每个用户都是一个完整的版本库，即使没有中央服务器也可以提交代码或者回滚，最终再把改好的代码提交至中央服务器进行合并即可
每次提交的文件都单独保存， 即按照文件的提交时间区分不同的版本， 保存至不同的逻辑存储区域，后期恢复时候直接基于之前版本恢复。
Gitlab 与 SVN 的数据保存方式不一样，gitlab 虽然 也会在内部 对数据进行逻辑划分保存，但是当后期提交的数据如和之前交的数据没有变化，其就直接 快照之前的文件 ，而不是再将文件重新上传一份再保存一遍，这样既节省 了空间又加快了代码提交速度 。
git add 添加git commit 提交
测试环境：内存 4G 以上
生产环境：建议 CPU2C，内存 8G，磁盘 10G 以上配置，和用户数有关
清华源 centos7：https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/
清华源 ubuntu18.04：https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/ubuntu/pool/bionic/main/g/gitlab-ce/
1 | [root@gitlab src]$dpkg -i gitlab-ce_13.8.4-ce.0_amd64.deb # 得等一会 |
1 | # 需要配置gitlab服务器地址和邮件地址 |
gitlab 相关目录：
1 | /etc/gitlab #配置文件目录 |
修改完配置文件要执行此操作
1 | [root@gitlab src]$gitlab-ctl reconfigure |
常用命令：
1 | gitlab-rails #用于启动控制台进行特殊操作，如修改管理员密码、打开数据库控制台( gitlab-rails dbconsole)等 |
username：root
注意，使用域名访问需要做 hosts
默认情况下可以直接注册账号，一般都关闭此功能，由管理员统一注册用户
新添加的邮箱不是默认的通知邮箱，下面是设置新邮箱为默认邮箱
设置完后，需要重新登录才能生效，然后可以把之前的默认邮箱删除
创建成功后，需要查看邮件，在邮件链接中重置密码
使用管理员 root 创建组，一个组里面可以有多个项目分支，可以将开发添加到组里，再进行设置权限，不同的组对应公司不同的开发项目或者服务模块，不同的组中添加不同的开发人员帐号，即可实现对开发设置权限的管理
有三种方式：创建空项目、使用模板、导入项目
更多权限：https://docs.gitlab.com/ee/user/permissions.html
默认 develop 权限无法 merge 和 push 到 master 分支的，可以修改：
在这里，也可以设置也可以保护其他分支
使用 陆东生 用户登录，新建分支，继承自 master：
ssh 认证
1 | ssh-keygen -t rsa |
clone
1 | git clone git@gitlab.ljk.local:testgroup/testproject.git |
运维常用：git pull、git clone、git reset
有些文件不需要上传，在 .gitignore 文件中设置忽略规则，示例：
1 | # 项目根目录下创建.gitignore，规则如下：忽略.vscode目录和.gitignore文件 |
修改完 .gitignore 文件后，更新缓存：
1 | git rm -r --cached . |
备份前必须先停止 gitlab 两个服务
1 | [root@gitlab ~]$gitlab-ctl stop unicorn |
备份数据
1 | [root@gitlab ~]$gitlab-rake gitlab:backup:create |
备份数据位于 /var/opt/gitlab/backups/
1 | [root@gitlab ~]$ls /var/opt/gitlab/backups/ |
查看要恢复的文件
1 | /var/opt/gitlab/backups/ # Gitlab数据备份目录，需要使用命令备份的 |
删除项目和用户信息
执行恢复
1 | # 恢复前先停止两个服务 |
恢复后再将之前停止的两个服务启动
1 | gitlab-ctl start |
虽然不推荐，但是有需求，基于第三方开发爱好者实现
汉化包地址： https://gitlab.com/xhang/gitlab
1 | git clone https://gitlab.com/xhang/gitlab.git |
不停老版本代码（不影响上一个版本访问），而是在另外一套环境部署新版本然后进行测试，测试通过后将用户流量切到新版本，其特点为业务无中断，升级风险相对较小
具体过程：
金丝雀发布也叫灰度发布，是指在黑与白之间，能够平滑过渡的一种发布方式，灰度发布是增量发布的一种类型，灰度发布是在原有版本可用的情况下，同时部署一个新版本应用作为“金丝雀”(小白鼠)，测试新版本的性能和表现，以保障整体系统稳定的情况下，尽早发现、调整问题。因此，灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度
具体过程：
滚动发布，一般是取出一个或者多个服务器停止服务，执行更新，并重新将其投入使用。周而复始，直到集群中所有的实例都更新成新版本，此方式可以防止同时升级，造成服务停止
A/B 测试也是同时运行两个 APP 环境，但是和蓝绿部署完全是两码事，A/B 测试是用来测试应用功能表现的方法，例如可用性、受欢迎程度、可见性等等，蓝绿部署的目的是安全稳定地发布新版本应用，并在必要时回滚，即蓝绿部署是同一时间只有一套正式环境环境在线，而 A/B 测试是两套正式环境同时在线，一般用于多个产品竟争时使用
Nexus 是一个强大的 Maven 仓库管理器，它极大地简化了自己内部仓库的维护和外部仓库的访问
官方下载：https://help.sonatype.com/repomanager3/download/download-archives---repository-manager-3
下载、解压、创建用户
1 | [root@nexus src]$useradd -r -s /sbin/nologin nexus # 创建nexus用户 |
Service 启动文件，官方提供
1 | [root@nexus ~]$cat /lib/systemd/system/nexus.service |
设置向导：
验证默认仓库
配置仓库的数据目录
仓库配置，以 zabbix 为例
centos 7.x 配置 yum 仓库
1 | [root@c71 ~]$vim /etc/yum.repos.d/zabbix.repo |
测试：
下载过的包会缓存下来
Nexus 中普通数据信息和元数据是分开存储的，普通数据是保存在 blob 中，而元数据保存在数据库中，所以在备份的时候必须同时进行备份普通数据和元数据，才能在后期恢复数据的时候保证数据的最终完整性
数据量太大，而且不影响用户业务，数据备份没什么意义
ActiveMQ 是一种开源的基于 JMS（Java Message Servie）规范的一种消息中间件的实现，采用 Java 开发，设计目标是提供标准的、面向消息的、能够跨越多语言和多系统的应用集成消息通信中间件