Open toantd1202 opened 4 years ago
packets
, errs
, drop
, fifo
, compressed
, multicast
cho cả luồn receive
và transmit
. Ngoài ra
Colls
(va chạm) và carrier
chỉ có trong luồng transmit
.ip address
, MAC address
, device name
, tình trạng hoạt động, loại giao diện.Đối với bandwidth
, các metrics
ứng với tiền tố như node_network_receive
và node_network_transmit
. Các metrics
này trả về kiểu dữ liệu là counter
. node_network_receive
trả về các giá trị ứng với luồng xuống(nhận) về host tại các mốc thời gian tương ứng, ngược lại các metrics node_network_transmit
trả về các giá trị, thông số của luồn up(truyền), trong cùng một thời điểm, cả hai luồng đều có thể hoạt động, vì vậy, độ rộng của bandwidth
là tổng của cả luồng lên và luồng xuống.
Các đơn vị thường dùng cho các luồng như:
byte
: các dữ liệu đựơc đo bằng đơn vị là byte
-đơn vị chuẩn, nếu muốn trả về đơn vị là bit
thì ta thực hiện nhân giá trị trả về của metrics
tương ứng với 8, ví dụ: rate(node_network_transmit_bytes_total[5m]) * 8
, tốc độ truyền dữ liệu trong 5 phút được trả về với đơn vị là bit
packets
: gói data truyền/nhậnerrs
: lỗi xảy ra trong quá trình truyền/nhậndrop
, fifo
, compressd
.colls
: số lượng các va chạm trên luồng truyềncarrier
: số lượng sóng mang sử dụngMetrics | description | types |
---|---|---|
node_network_receive_bytes_total | Network device statistic receive_bytes | counter |
node_network_receive_compressed_total | Network device statistic receive_compressed | counter |
node_network_receive_drop_total | Network device statistic receive_drop | counter |
node_network_receive_errs_total | Network device statistic receive_errs | counter |
node_network_receive_fifo_total | Network device statistic receive_fifo | counter |
node_network_receive_frame_total | Network device statistic receive_frame | counter |
node_network_receive_multicast_total | Network device statistic receive_multicast | counter |
node_network_receive_packets_total | Network device statistic receive_packets | counter |
node_network_speed_bytes | speed_bytes value of /sys/class/net/ |
gauge |
node_network_transmit_bytes_total | Network device statistic transmit_bytes | counter |
node_network_transmit_carrier_total | Network device statistic transmit_carrier | counter |
node_network_transmit_colls_total | Network device statistic transmit_colls | counter |
node_network_transmit_compressed_total | Network device statistic transmit_compressed | counter |
node_network_transmit_drop_total | Network device statistic transmit_drop | counter |
node_network_transmit_errs_total | Network device statistic transmit_errs | counter |
node_network_transmit_fifo_total | Network device statistic transmit_fifo | counter |
node_network_transmit_packets_total | Network device statistic transmit_packets | counter |
node_network_transmit_queue_length | transmit_queue_length value of /sys/class/net/ |
gauge |
node_network_receive_bytes_total
: tổng số byte dữ liệu nhận vềnode_network_transmit_bytes_total
: tổng số byte dữ liệu truyềnTổng băng thông được sử dụng:
node_network_receive_bytes_total
+
node_network_transmit_bytes_total
node_network_transmit_errs_total
: tổng số lỗi truyền đinode_network_transmit_packets_total
: tổng số gói truyềnĐể tính tỷ lệ lỗi truyền trong 5 phút ta có thể sử dụng:
rate(node_network_transmit_errs_total[5m])
/
rate(node_network_transmit_packets_total[5m])
Ta cũng có thể xác định đơn vị truyền cực đại thông qua metrics
: node_network_mtu_bytes
, metrics trả về kiểu dữ liệu là gauge.
Đối với các container, đê giám sát network, ta sử dụng cAdvisor
, một node exporter hỗ trợ việc giám sát các container.
Tương tự như node exporter
, cAdvisor
cũng có các metrics như:
Metrics | description | types |
---|---|---|
container_network_receive_bytes_total | Cumulative count of bytes received | counter |
container_network_receive_errors_total | Cumulative count of errors encountered while receiving | counter |
container_network_receive_packets_dropped_total | Cumulative count of packets dropped while receiving | counter |
container_network_receive_packets_total | Cumulative count of packets received | counter |
container_network_transmit_bytes_total | Cumulative count of bytes transmitted | counter |
container_network_transmit_errors_total | Cumulative count of errors encountered while transmitting | counter |
container_network_transmit_packets_dropped_total | Cumulative count of packets dropped while transmitting | counter |
container_network_transmit_packets_total | Cumulative count of packets transmitted | counter |
Với việc sử dụng metrics
node_network_info
, các thông tin của interface được trả về với với các giá trị như ip address
, device name
, tình trạng hoạt động.
ví dụ:
node_network_info{address="00:00:00:00:00:00",broadcast="00:00:00:00:00:00",device="lo",duplex="",ifalias="",operstate="unknown"} 1
node_network_info{address="02:42:ac:17:00:03",broadcast="ff:ff:ff:ff:ff:ff",device="eth0",duplex="full",ifalias="",operstate="up"} 1
Hay với node_network_address_assign_type
cho biết địa chỉ MAC đến từ đâu.
Giao diện mạng máy chủ có thể đang nhận quá nhiều dữ liệu (> 100MB/s)
- alert: HostUnusualNetworkThroughputIn
expr: sum by (instance) (irate(node_network_receive_bytes_total[2m])) / 1024 / 1024 > 100
for: 5m
labels:
severity: warning
annotations:
summary: "Host unusual network throughput in (instance {{ $labels.instance }})"
description: "Host network interfaces are probably receiving too much data (> 100 MB/s)\n VALUE = {{ $value }}\n LABELS: {{ $labels }}"
Giao diện mạng máy chủ có thể đang gửi quá nhiều dữ liệu (100 MB/s)
- alert: HostUnusualNetworkThroughputOut
expr: sum by (instance) (irate(node_network_transmit_bytes_total[2m])) / 1024 / 1024 > 100
for: 5m
labels:
severity: warning
annotations:
summary: "Host unusual network throughput out (instance {{ $labels.instance }})"
description: "Host network interfaces are probably sending too much data (> 100 MB/s)\n VALUE = {{ $value }}\n LABELS: {{ $labels }}"
Lỗi truyền bạn có thể sử dụng
- alert: networktransmiterr
expr: rate(node_network_transmit_errs_total[5m]) / rate(node_network_transmit_packets_total[5m])
for: 5m
labels:
severity: warning
annotations:
summary: "transmit error > (instance {{ $labels.instance }})"
description: "Host network interfaces are transmit error too much (> 100 MB/s)\n VALUE = {{ $value }}\n LABELS: {{ $labels }}"
Ansible cung cấp rất nhiều module. khi sử dụng playbook, ta chỉ cần khai báo tên module và tên dịch vụ trong các tasks, module được khai báo tự khắc sẽ nhận lệnh và thực thi theo yêu cầu. Nếu muốn tự tạo một module riêng thì ansible vẫn hỗ trợ và cho phép viết module để chạy trên python.
command
lấy tên lệnh theo sau là các đối số được phân tách bằng dấu cách.$Home
và các toán tử "<", ">", "|", ";" và "&" sẽ không khả dụng. Nếu muốn thực hiện các tính năng trên thì dùng module shell
.command
dễ đọc hơn, các tasks sử dụng các đối số được phân tách bằng dấu cách, truyền tham số bằng cách sử dụng từ khóa args
hoặc sử dụng tham số cmd
.argv
: Truyền lệnh dưới dạng một danh sách chứ không phải là một chuỗi. Sử dụng argv
để tránh trích dẫn các giá trị không được hiểu sai (ví dụ "user name", đường dẫn).
Chỉ có thể cung cấp chuỗi hoặc mẫu danh sách.
- name: Run command if /path/to/database does not exist (with 'args' keyword).
command: /usr/bin/make_database.sh db_user db_name
args:
creates: /path/to/database
cmd
: Lệnh thực thi.
- name: Run command if /path/to/database does not exist (with 'cmd' parameter).
command:
cmd: /usr/bin/make_database.sh db_user db_name
creates: /path/to/database
copy
sao chép một tệp từ máy local hoặc remote đến một vị trí trên máy remote.fetch
để sao chép các tệp từ các remote locations vào local box.template
.dest (path): Đường dẫn duy nhất tại remote, nơi tập tin sẽ được sao chép vào.
Nếu src
là một thư mục, đây cũng phải là một thư mục.
Nếu dest
là một đường dẫn không tồn tại và nếu kết thúc bằng '/' hoặc src
là một thư mục, thì Dest
được tạo.
Nếu src
và Dest
là các tệp, thư mục cha của dest
không được tạo và task sẽ fails nếu nó chưa tồn tại.
src (path): Local path đến một tệp để sao chép vào remote server.
Nếu đường dẫn là một thư mục, nó được sao chép đệ quy. Trong trường hợp này, nếu đường dẫn kết thúc bằng '/', chỉ bên trong nội dung của thư mục đó được sao chép đến đích. Mặt khác, nếu nó không kết thúc bằng '/', thì chính thư mục có tất cả nội dung sẽ được sao chép.
docker-compose.yml
hoặc docker-compose.yaml
.project_src (path): Đường dẫn đến thư mục chứa tệp docker-compose.yml hoặc docker-compose.yaml.
project_name (string): Cung cấp một tên dự án. Nếu không được cung cấp, tên dự án được lấy từ tên cơ sở của project_src.
state (string): Trạng thái mong muốn của project.
Chỉ định present
giống như chạy docker-compose up
.
Chỉ định absent
cũng giống như chạy docker-compose down
.
- name: run prom
hosts: localhost
tasks:
- name: docker compose
docker_compose:
project_src: /home/toan/prometheus
--check
và --diff
để xem sự khác biệt về cấu hình và danh sách các hành động sẽ được thực hiện.command: Lệnh thực thi khi container bắt đầu. Một lệnh có thể là một chuỗi hoặc một danh sách.
hostname: Tên container.
image: Đường dẫn của repo và tag được sử dụng để tạo container. Nếu một image không được tìm thấy hoặc pull được thỏa mãn, image sẽ được pull từ registry. Nếu không có tag được bao gồm, latest
sẽ được sử dụng.
Cũng có thể là một image ID. Nếu đây là trường hợp, image được giả định là có sẵn tại local. Tùy chọn pull được bỏ qua cho trường hợp này.
mounts: Chỉ định mounts được thêm vào container. Thay thế mạnh mẽ hơn cho volumes.
network_mode: Kết nối container với mạng. Lựa chọn là bridge
, host
, none
hoặc container:<name|id>
.
state: absent
- Một container khớp với tên được chỉ định sẽ bị dừng và xóa. Sử dụng force_kill
để kill container hơn là dừng nó. Sử dụng keep_volume
để giữ lại volumes được liên kết với container bị xóa.
present - Xác nhận sự tồn tại của một container khớp với tên và mọi tham số cấu hình được cung cấp. Nếu không có container nào khớp với tên, một container sẽ được tạo. Nếu một container khớp với tên nhưng cấu hình được cung cấp không khớp, container sẽ được cập nhật, nếu có thể. Nếu không thể cập nhật, nó sẽ bị xóa và được tạo lại với cấu hình được yêu cầu.
started - Xác nhận rằng container có mặt lần đầu tiên và sau đó nếu container không chạy sẽ chuyển nó sang trạng thái chạy. Sử dụng khởi động lại để buộc một container phù hợp bị dừng và khởi động lại.
Đã dừng - Xác nhận rằng container hiện diện lần đầu tiên và sau đó nếu container đang chạy sẽ chuyển nó sang trạng thái dừng.Sử dụng tùy chọn tạo lại để luôn bắt buộc tạo lại một thùng chứa phù hợp, ngay cả khi nó đang chạy.
- name: Create a data container
docker_container:
name: mydata
image: busybox
volumes:
- /data
playbook
playbook là một file định dạng bằng YAML, có cú pháp đơn giản để không bị biến thành một ngôn ngữ lập trình hay script phức tạp. Trong ansible, một playbook miêu tả những hosts nào được config và một danh sách các tasks hoặc command mà ta sẽ thực thi trên những hosts đó.
Nếu các module Ansible là công cụ trong workshop của bạn, thì playbooks là bản hướng dẫn sử dụng bạn cần và inventory của bạn là nguyên liệu thô.
Mỗi playbook bao gồm một hay nhiều "plays" trong danh sách đực liệt kê.
Mục tiêu của một playbook là ánh xạ một nhóm các hosts đến một số roles được xác định rõ, được thể hiện bằng những thứ gọi là tasks. Ở cấp độ cơ bản, một task thực thi nhiệm vụ bằng cách gọi đến một ansible.
ví dụ: thực hiện 3 modules khác nhau bằng command line:
ansible webservers -m service -a "name=httpd state=started"
ansible webservers -m ping
ansible webservers -m command -a "/sbin/reboot -t now"
Mỗi module sẽ có các tham số truyền vào là khác nhau, và hầu như tất cả các module đều có tham số theo dạng key=value, các tham số cách nhau bởi dấu cách. Ngoài ra cũng có 1 số module không có tham số như ping...
Thay cho việc thực thi các công việc bằng từng dòng lệnh, ta sắp xếp các công việc đó thành một danh sách theo thứ tự các công việc cần thực hiện để dễ dàng theo dõi. ví dụ:
- hosts: webservers
vars:
http_port: 80
max_clients: 200
remote_user: root
tasks:
- name: ensure apache is at the latest version
yum:
name: httpd
state: latest
- name: write the apache config file
template:
src: /srv/httpd.j2
dest: /etc/httpd.conf
notify:
- restart apache
- name: ensure apache is running
service:
name: httpd
state: started
handlers:
- name: restart apache
service:
name: httpd
state: restarted
Ví dụ trên là một playbook chỉ chứa một play
, nó thực hiện các tasks trên các hosts trong group webservers
, remote_user: root
cấp quyền người dùng root
, bao gồm 3 tasks:
yum
template
Đối với mỗi lần chạy `play` trong playbook, bạn có thể chỉ định máy nào trong cơ sở hạ tầng của mình để nhắm target và remote user nào sẽ hoàn thành các bước (được gọi là các tasks).
Dòng hosts
là một danh sách của một hoặc nhiều groups hoặc host patterns, được phân tách bằng dấu hai chấm. Remote_user
chỉ là tên của tài khoản người dùng.
Tham số remote_user
trước đây chỉ được dùng để gọi user
. Nó đã được đổi tên trong Ansible 1.4 để làm cho nó dễ phân biệt hơn với user module (được sử dụng để tạo người dùng trên các remote system).
Ta cũng có thể xác định user trong tasks, hoặc chạy play dưới quyền người dùng khác(với các chỉ thị become
, become_user
, become_method,...)
order={sorted, reverse_storted(theo tên), inventory, reverse_inventory(theo thứ tự định nghĩa trong file inventory), shuffle(ngẫu nhiên)}
Mỗi play gồm một danh sách các tasks. Các tasks được thực thi lần lượt theo thứ tự trên tất cả các máy trong danh sách hosts
. Khi thực thi playbook, nếu như một máy nào đó failed với một task bất kỳ, nó sẽ bị loại ra khỏi vòng lặp.
Mỗi task có mục đích là thực thi một module nào đó với các tham số cụ thể. Các tham số này có thể được truyền trực tiếp hoặc truyền gián tiếp thông qua danh sách biến định nghĩa trước.
Các module là idempotent, nếu đã chạy một module nào đó và đạt được trạng thái mong muốn rồi thì yêu cầu chạy lại sau đó với danh sách tham số cũ sẽ không được thực hiện.
Mỗi task có tên cụ thể. Ten này được hiển thị ra trong output của playbook. Vì vậy, tên nên được đặt một cách dễ hieur và mô tả chính xác công việc mà task thực thi.
Handler có chức năng giống như 1 task, nhưng chỉ xảy ra khi có điều kiện nào đó. Handler được run khi được notified
bởi 1 task. Một task sẽ kích hoạt notification nếu Ansible phát hiện ra task đó đã thay đổi state của hệ thống, notify của 1 task được khai báo như sau:
template:
src: template.j2
dest: /etc/foo.conf
notify:
- restart memcached
- restart apache
Mốt số điều cần lưu ý về handlers, đó là các handlers chỉ run sau khi tất cả các task đã được hoàn thành, và chỉ run đúng 1 lần, ngay cả khi chúng được notify nhiều lần. Các handler luôn run theo thứ tự mà chúng xuất hiện trong play chứ không run theo thứ tự notification.
Kể từ Ansible 2.2, handlers có thể "lắng nghe" một topic nào đó, các tasks notify một topic cũng đồng thời notify các handlers lắng nghe luôn:
handlers:
- name: restart memcached
service:
name: memcached
state: restarted
listen: "restart web services"
- name: restart apache
service:
name: apache
state:restarted
listen: "restart web services"
tasks:
- name: restart everything
command: echo "this task will restart the web services"
notify: "restart web services"
Cách làm này giúp cho việc kích hoạt nhiều handlers dễ dàng hơn. Nó cũng tách các handlers khỏi tên của chúng, giúp chia sẻ handles giữa các playbook và vai trò dễ dàng hơn (đặc biệt là khi sử dụng roles của bên thứ 3 như là Galaxy).
Thực thi một playbook với số lượng tiến trình song song xác định:
ansible-playbook playbook.yaml -f 10
Để kiểm tra cú pháp của một playbook:
ansible-playbook <name> --syntax-check
Để xem những máy chủ sẽ bị ảnh hưởng bởi một playbook trước khi chạy:
ansible-playbook playbook.yml --list-hosts
import urllib.request import pandas as pd import json import csv from bs4 import BeautifulSoup page= urllib.request.urlopen('http://127.0.0.1:9093/api/v1/silences') soup = BeautifulSoup(page, 'html.parser').get_text()
lists = json.loads(soup)
f=open('am.json') data=json.load(f) f.close with open('am.json', 'w+') as f: json.dump(lists, f)
print('ghi thanh cong') ad = pd.read_json(r'/home/toan/PycharmProjects/list_API/am.json') export_csv = ad.to_csv(r'/home/toan/PycharmProjects/list_API/AM.csv', index = None, header = True) read_file = pd.read_csv(r'/home/toan/PycharmProjects/list_API/AM.csv') a = read_file.to_osd(r'/home/toan/PycharmProjects/list_API/test.xlsx', index = None, header = True)
Load config từ 1 file khác để kéo vào extension, viết các def sử dụng config đó. Các config đó được đẩy vào từ việc định nghĩa hàm trên hàm. Chỉ viết thôi, không có main
Fluentd là một trình thu thập dữ liệu nguồn mở cho các logs. Fluentd cho phép bạn thống nhất thu thập, quản ly, sử dụng và hiểu dữ liệu tốt hơn.
Fluentd được cấp phép theo các điều khoản của Apache License v2.0. Dự án này được thực hiện và tài trợ bởi Treasure Data.
Fluentd coi các bản ghi là JSON, một định dạng phổ biến có thể đọc được bằng máy. Nó được viết chủ yếu bằng C với các phần nhạy cảm về hiệu năng, Ruby cũng được sử dụng chút ít giúp người dùng linh hoạt.
Fluentd thực hiệt thu thập logs của sự kiện từ các ứng dụng, hệ thống,... giúp người dùng phân tích, đưa ra thông báo và quản lý các phần tử đó.
Step 1: Pull Fluentd's Docker image
$ docker pull fluent/fluentd:v0.12-debian
Step 2: Launch Fluentd Container
Thử nghiệm đơn giản, tạo cấu hình ví dụ tại /tmp/fluentd.conf
. Ví dụ này chấp nhận các bản ghi từ http và xuất ra thiết bị xuất chuẩn.
# /tmp/fluentd.conf
<source>
@type http
port 9880
bind 0.0.0.0
</source>
<match **>
@type stdout
</match>
Khởi chạy Fluentd với lệnh docker run
.
$ docker run -d \
-p 9880:9880 -v /tmp:/fluentd/etc -e FLUENTD_CONF=fluentd.conf \
fluent/fluentd
Step3: Post Sample Logs via HTTP
Hãy post sample logs qua HTTP và xác nhận nó đang hoạt động. Sử dụng lệnh curl
$ curl -X POST -d 'json={"json":"message"}' http://localhost:9880/sample.test
Sử dụng lệnh docker ps
để truy xuất ID container và sử dụng lệnh docker logs
để kiểm tra nhật ký của container cụ thể.
$ docker logs container id | tail -n 1
docker-compose
version: '3'
services:
fluentd:
image: fluent/fluentd:v0.12-debian-1
volumes:
- ./fluentd/conf:/fluentd/etc
ports:
- "9880:9880"
- "9880:9880/udp"
Thời gian tồn tại của một Fluentd Event
Tệp cấu hình cho phép người dùng kiểm soát hành vi đầu vào và đầu ra của Fluentd bằng cách (1) chọn các plugin đầu vào và đầu ra, (2) chỉ định các tham số plugin. Tập tin được yêu cầu để Fluentd hoạt động đúng.
Với Docker container, vị trí mặc định được đặt tại /fluentd/etc/fluent.conf. Để mount tệp cấu hình từ bên ngoài Docker, sử dụng bind-mount.
docker run -ti --rm -v /path/to/dir:/fluentd/etc fluentd -c /fluentd/etc/<conf-file> -v
Tệp cấu hình bao gồm các chỉ thị sau:
Các nguồn đầu vào của Fluentd được bật bằng cách chọn và định cấu hình các plugin đầu vào mong muốn bằng cách sử dụng các chỉ thị nguồn. Các plugin đầu vào tiêu chuẩn của Fluentd bao gồm http
và forward
. http
biến fluentd thành điểm cuối HTTP để chấp nhận các tin nhắn HTTP đến trong khi forword
biến fluentd thành điểm cuối TCP để chấp nhận các gói TCP.
# Nhận các events từ 24224/tcp
# Sử dụng log forwarding và fluent-cat command
<source>
@type forward
port 24224
</source>
# http://this.host:9880/myapp.access?json={"event":"data"}
<source>
@type http
port 9880
</source>
Mỗi source phải bao gồm một tham số @type
. Tham số @type
chỉ định plugin đầu vào nào sẽ sử dụng.
Interlude: Routing
source
gửi các sự kiện vào công cụ định tuyến của Fluentd. Một sự kiện bao gồm ba thực thể: tag, time và record. Tag
là một chuỗi được phân tách bằng .
(Ví dụ: myapp.access) và được sử dụng làm chỉ đường cho công cụ định tuyến nội bộ của Fluentd. Trường thời gian được chỉ định bởi các plugin đầu vào và nó phải ở định dạng thời gian Unix. Bản ghi là một đối tượng JSON.
Fluentd chấp nhận tất cả các ký tự không phải là một phần của tag
. Tuy nhiên, vì đôi khi tag
được sử dụng trong một ngữ cảnh khác bởi các đích đầu ra (ví dụ: tên bảng, tên cơ sở dữ liệu, tên khóa, v.v.), nên sử dụng bảng chữ cái chữ thường, chữ số và dấu gạch dưới, vd: ^[a-z0-9 _]+$
.
Trong ví dụ trên, plugin đầu vào HTTP gửi sự kiện sau:
# generated by http://this.host:9880/myapp.access?json={"event":"data"}
tag: myapp.access
time: (current time)
record: {"event":"data"}
Có thể thêm các nguồn đầu vào mới bằng cách viết các plugin riêng. Để biết thêm thông tin về các nguồn đầu vào của Fluentd, vui lòng tham khảo bài viết Tổng quan về Plugin đầu vào.
Lệnh 'match' tìm kiếm các sự kiện với các matching tags và xử lý chúng. Việc sử dụng phổ biến nhất của lệnh match là để xuất các sự kiện cho các hệ thống khác (vì lý do này, các plugin tương ứng với lệnh khớp được gọi là 'plugin đầu ra'). Các plugin đầu ra tiêu chuẩn của Fluentd bao gồm file
và forward
. Nó được thêm vào tập tin cấu hình.
# Match events tagged with "myapp.access" and
# store them to /var/log/fluent/access.%Y-%m-%d
# Of course, you can control how you partition your data
# with the time_slice_format option.
<match myapp.access>
@type file
path /var/log/fluent/access
</match>
Mỗi match
phải bao gồm một match pattern (mẫu) và tham số @type. Chỉ các sự kiện có tag matching với mẫu sẽ được gửi đến đích đầu ra (trong ví dụ trên, chỉ các sự kiện có thẻ 'myapp.access' được matched. Tham số @type chỉ định plugin đầu ra sẽ sử dụng.
Giống như các nguồn đầu vào, ta có thể thêm các đích đầu ra mới bằng cách viết các plugin của riêng.
Lệnh filter
có cú pháp tương tự như match
nhưng filter
có thể được kết nối để xử lý pipeline. Sử dụng filters, luồng sự kiện như dưới đây:
Input -> filter 1 -> ... -> filter N -> Output
Ví dụ thêm bộ lọc record_transformer
vào ví dụ match
.
# http://this.host:9880/myapp.access?json={"event":"data"}
<source>
@type http
port 9880
</source>
<filter myapp.access>
@type record_transformer
<record>
host_param "#{Socket.gethostname}"
</record>
</filter>
<match myapp.access>
@type file
path /var/log/fluent/access
</match>
Sự kiện đã nhận, {'event': 'data'}
, trước tiên chuyển đến bộ lọc record_transformer
. Record_transformer
thêm trường 'host_param' vào sự kiện và sự kiện được lọc, {'event': 'data', 'host_param': 'webserver1'}, đi đến đầu ra tệp.
system
Các cấu hình toàn hệ thống được đặt theo chỉ thị system
. Hầu hết trong số chúng cũng có sẵn thông qua các tùy chọn dòng lệnh. Ví dụ: các cấu hình sau đây có sẵn:
ví dụ: process_name Nếu được đặt tham số này, tên fluentd's supervisor và worker sẽ được thay đổi.
Nhóm chỉ thị label
lọc và đầu ra cho định tuyến nội miền. label
làm giảm sự phức tạp của việc xử lý tag.
lable
hữu ích cho phân tách luồng sự kiện mà không có tiền tố thẻ.
Chỉ thị trong các tệp cấu hình riêng biệt có thể được nhập bằng chỉ thị @include:
# Include config files in the ./config.d directory
@include config.d/*.conf
Lệnh @include hỗ trợ đường dẫn tệp thông thường, mẫu toàn cục và các quy ước URL http:
# absolute path
@include /path/to/config.conf
# if using a relative path, the directive will use
# the dirname of this config file to expand the path
@include extra.conf
# glob match pattern
@include config.d/*.conf
# http
@include http://example.com/fluent.conf
Có thể kiểm tra cấu hình của mình mà không cần plugin bắt đầu bằng cách chỉ định tùy chọn --dry-run.
$ fluentd --dry-run -c fluent.conf
lamthu