Monitoring Network

Xác định các tiêu chí giám sát network cho host.
Tìm hiểu các metrics tương ứng với các tiêu chí ấy ( trong phạm vị node_exporter, các em có thể tìm thêm trong một số exporter khác )
Viết alert rule dựa trên các tiêu chí đã định nghĩa ở 1. Cần giải thích được các operator, func PromQL sử dụng trong expr ấy.
Bonus: Trực quan các metric về network lên Grafana

1. Các tiêu chí giám sát network cho host

Lưu lượng luồng dữ liệu truyền, nhận hay còn gọi là băng thông. Trong đó, các luồng dữ liệu này có thể lấy theo các đơn vị, đặc tính nhau như: 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.
Các thông tin của các interface như ip address, MAC address, device name, tình trạng hoạt động, loại giao diện.

2. Các metrics tương ứng

Băng thông

Đố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
Ngoài ra, các kiểu đơn vị khác được cung cấp như:
- packets: gói data truyền/nhận
- errs: lỗi xảy ra trong quá trình truyền/nhận
- drop, fifo, compressd.
- colls: số lượng các va chạm trên luồng truyền
- carrier: số lượng sóng mang sử dụng

Metrics	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

ví dụ

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ền

Tổ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 đi
node_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

Thông tin trên các interface

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.

3. Viết alert rule

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 }}"

Modules

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.

Một số module

1. Commands - THực thi các lện h trên các targets

Module 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.
Lênh được gọi sẽ thực thi trên tất cả các node được chọn.
Các lệnh không được xử lý qua shell, nên các biến như $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.
Để tạo các 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

2. File

copy – Copy files to remote locations

Module 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.
Sử dụng module fetch để sao chép các tệp từ các remote locations vào local box.
Nếu cần thêm biến trong các tệp được sao chép, hãy sử dụng 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.

3. docker

docker_compose – Manage multi-container Docker applications with Docker Compose

Sử dụng Docker Compose để start, shutdown và scale dịch vụ.
Hoạt động với các compose version 1 và 2.
Cấu hình có thể được đọc từ tệp docker-compose.yml hoặc docker-compose.yaml.
Hỗ trợ chế độ kiểm tra.
Module này được gọi là docker_service trước Ansible 2.8. Cách sử dụng không thay đổi.

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

docker_container – manage docker containers

Quản lý vòng đời của container docker.
Hỗ trợ chế độ kiểm tra. Chạy với --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

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:

Tải httpd bằng module yum
Tạo apache config file bằng module template
Khởi động apache.
Khơi động lại apache.

Chi tiết

Hosts and Users

Chọn các hosts và người dùng để thực thi một play.

hosts: webservers remote_user: root


Đố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,...)

Xác định thứ tự chạy giữa các hosts:

hosts: all order: sorted gather_facts: False tasks:

debug: var: inventory_hostname


order={sorted, reverse_storted(theo tên), inventory, reverse_inventory(theo thứ tự định nghĩa trong file inventory), shuffle(ngẫu nhiên)}

Tasks List

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.

Handlers

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).

Executing A Playbook

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 = soup.find('body').get_text()

lists = json.loads(soup)

print(lists)

rows = []

rows.append(['status', 'data_id', 'data_matchers_name', 'data_matchers_value', 'data_matchers_isRegex', 'data_startsAt', 'data_endsAt', 'data_updatedAt', 'data_createdBy', 'data_comment', 'data_status_state'])

for result in results:

export_csv = lists.to_csv()

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à gì?

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.

Kiến trúc

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. Screenshot from 2020-06-23 15-37-19

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ử đó.

Fluentd

Cài đặt Fluentd với Docker

Download and install Docker

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

Screenshot from 2020-06-23 14-09-21

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"

Screenshot from 2020-06-23 14-08-59

Cấu hình của Fluentd

Config File Syntax

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:

source xác định các nguồn đầu vào.
match xác định các điểm đến của output.
filter xác định các pipelines xử lý sự kiện.
system chỉ thị thiết lập cấu hình hệ thống rộng.
label chỉ thị nhóm đầu ra và bộ lọc cho định tuyến nội miền.
@include chỉ thị bao gồm các tập tin khác.

"source": where all the data come from.

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>

Screenshot from 2020-06-23 17-04-54

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.

"match": Tell fluentd what to do!

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.

"filter": Event processing pipeline

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.

Đặt cấu hình toàn hệ thống: `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:

log_level
suppress_repeated_stacktrace
emit_error_log_interval
suppress_config_dump
without_source
process_name (only available in system directive. No fluentd option)

ví dụ: process_name Nếu được đặt tham số này, tên fluentd's supervisor và worker sẽ được thay đổi.

Group filter and output: the "label" directive

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ẻ.

Re-use your config: the "@include" directive

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

Check configuration file

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

toantd1202 / buoc1

vidu1 #1