Performance Testing là một loại kiểm thử nhằm xác định khả năng đáp ứng tối đa, các điểm tắc nghẽn của một hệ thống, từ đó đưa ra những điều chỉnh hợp lí để cải thiện hiệu suất của hệ thống. Trong bài viết này chúng tôi sẽ giới thiệu về Locust - một công cụ hỗ trợ cho load testing được viết bằng Python.

Mặc dù không được phổ biến như một số tool khác (như Jmeter, Gatling, ...) nhưng Locust cũng có nhiều tính năng khác thú vị rất phù hợp cho một số trường hợp.

Locust là gì?

Locust là một user load testing tool được viết bằng python, rất dễ sử dụng. Nó thường được dùng để load testing cho website, các hệ thống api, ... và để tìm ra số lượng người dùng đồng thời mà hệ thống có thể xử lí.

Ý tưởng của nó là dùng một nhóm các Locust để giả lập các requests tới website. Các hành vi của người dùng do chúng ta định nghĩa bằng python. Quá trình load testing được theo dõi real-time bằng UI.

Locust là event-based, do đó nó có thể hỗ trợ tạo ra hàng ngàn người dùng đồng thời trên một máy duy nhất. Trái ngược với nhiều ứng dụng event-base khác, nó không sứ dụng call-backs thay vào nó sử dụng light-weight processes, thông qua gevent.

Ưu điểm:

• Kịch bản test được viết bằng Python phù hợp cho các pro python (nhưng là nhược điểm cho người không thành thạo python), hơn nữa giúp dễ dàng quản lí kịch bản test với git
• Dễ dàng setup môi trường phân tán, khả năng mở rộng tốt - hỗ trợ giả lập hàng trăm nghìn user
• Có giao diện web, một số biểu đồ đơn giản để xem kết quả testing
• Nhờ cơ chế event-based nên Locust dùng ít tài nguyên hơn một số tool khác (như Jmeter, Gatling). Có thể dễ dàng giả lập hàng nghìn user trên một laptop.
• Và đặc biệt vì kịch bản được viết Python thay vì dùng giao diện như các tool khác nên chúng ta có thể Hackable nếu pro Python.

Nhược điểm:

• Cần biết python.
• Không có cơ chế recording như một số tool (Jmeter,Gatling...).
• Phần thống kê báo cáo kết quả testing còn đơn giản.
• Mặc định chỉ hỗ trợ giao thức http/https tuy nhiên chúng ta cũng có thể mở rộng ra các giao thức khác nhưng đòi hỏi cần nhiều kinh nghiệp lập trình Python

Thao khảo thêm bài so sánh Locust với Jmeter:

Jmeter vs locust what to use when

Cài đặt

pip install locustio
locust --help

Chú ý:

Mỗi kết nối HTTP trên một máy sẽ mở một file mới (technically a file descriptor). Hệ điều hành có thể giới hạn số lượng file có thể mở. Nếu số lượng giới hạn này thấp hơn số lượng người dùng giả lập trong lúc test sẽ xảy ra lỗi. Vì thế chúng ta nên cấu hình lại số lượng giới hạn này (tùy thuộc vào từng hệ điều hành sẽ có các cách điều chỉnh khác nhau).

Sử dụng đơn giản

Tạo một file locustfile.py đơn giản (các tham số chúng tôi sẽ giải thích sau)

from locust import HttpLocust, TaskSet

def login(l):
    l.client.post("/login", {"username":"ellen_key", "password":"education"})

def index(l):
    l.client.get("/")

def profile(l):
    l.client.get("/profile")

class UserBehavior(TaskSet):
    tasks = {index: 2, profile: 1}

    def on_start(self):
        login(self)

class WebsiteUser(HttpLocust):
    task_set = UserBehavior
    min_wait = 5000
    max_wait = 9000```

hoặc sử dụng cách sau tương đương:

from locust import HttpLocust, TaskSet, task

class UserBehavior(TaskSet):
    def on_start(self):
    """ on_start is called when a Locust start before any task is scheduled """
        self.login()

    def login(self):
        self.client.post("/login", {"username":"ellen_key", "password":"education"})

    @task(2)
    def index(self):
         self.client.get("/")
    @task(1)
    def profile(self):
        self.client.get("/profile")

class WebsiteUser(HttpLocust):
    task_set = UserBehavior
    min_wait = 5000
    max_wait = 9000

Start Locust

locust --host=http://example.com

Nếu sử dụng tên file khác locustfile.py ta có thể sử dụng tham số -f

locust -f locust_files/my_locust_file.py --host=http://example.com

Ngay sau khi chạy script ta truy cập: http://127.0.0.1:8089

Tại đây chúng ta sẽ xác định số lượng user giả lập, tiến hành chạy load testing và xem kết quả monitoring

Hình minh họa:

Còn tiếp ...

Phần sau chúng tôi sẽ hướng dẫn cách viết kịch bản testing, mong các bạn tiếp tục theo dõi.

Tham khảo:

https://docs.locust.io/en/latest/quickstart.html
https://www.blazemeter.com/blog/jmeter-vs-locust-which-one-should-you-choose
https://www.blazemeter.com/blog/locust-assertions-a-complete-user-manual

Tiếp theo loại bài về Docker hôm nay chúng tôi sẽ trình bày các cách để quản lí data của container khi sử dụng Docker.

Mặc định tất cả các file được tạo bên trong container được lưu trữ trên một writable container layer. Nó có nhiều nhược điểm:

• Dữ liệu sẽ mất khi container đó bị xóa, khó có thể truy xuất dữ liệu nếu một container khác hoặc process khác cần dữ liệu này.
• Container layer được gắn chặt với máy host khi mà container running. Khi đó chúng ta không dễ để chuyển dữ liệu được lưu trên container layer tới chỗ khác.
• Ghi dữ liệu trên container layer cần phải đi qua 1 lớp storage driver => giảm hiệu năng ghi dữ liệu so với data volume (ghi trực tiếp lên host filesystem).

Docker hỗ trợ 3 cách để lưu trữ dữ liệu của Docker container là: volume, bind mount và tmpfs volume (Docker on Linux). Volume thường là lựa chọn tốt nhất.

• Dữ liệu trên volume được lưu trên filesystem của Docker host (/var/lib/docker/volumes/) và được quản lý bởi Docker deamon. Các process không liên quan đến Docker sẽ không sử dụng đến phần dữ liệu này. Volumes là cách lưu trữ dữ liệu tốt nhất trên Docker.
• Bind mount có thể được lưu ở bất cứ đâu trên máy host. Các process không liên quan đến Docker hoặc một container khác có thể chỉnh sửa các file này bất kỳ lúc nào.
• Tmpfs mount được lưu trên bộ nhớ (RAM) của máy host và không ghi lên trên host filesystem (không ghi lên disk).

Docker Storage

Volume

Được khởi tạo và quản lý bởi Docker. Chúng ta có thể khởi tạo một volume bằng cách sử dụng lệnh docker volume create hoặc tạo volume khi khởi tạo một  container/service.

Khi chúng ta khởi tạo một volume, volume này sẽ nằm trong một thư mục xác định  trên Docker host. Khi chúng ta mount volume này lên container tức là chúng ta mount thư mục đó vào container. Cách thức hoạt động của volume tương tự như bind mount, ngoại trừ việc volume được quản lý bởi Docker và được tách biệt (isolate) với các thành phần khác của máy host.

Một volume có thể được mount lên nhiều container cùng một lúc. Khi không có container nào sử dụng volume đó, volume này vẫn tồn tại và được quản lý bởi Docker mà không bị xóa đi như container layer. Chúng ta có thể xóa tất cả các volume không sử dụng bằng cách dùng lệnh docker volume prune.

Chúng ta có thể đặt tên cho một volume, nếu chúng ta không đặt tên thì Docker sẽ tự động đặt tên cho volume đó và tên này là duy nhất trên một Docker host.

Volume trên Docker hỗ trợ dùng nhiều loại volume drivers, cho phép lưu trữ dữ liệu trên remote host hoặc trên hạ tầng lưu trữ của các nhà cung cấp dịch vụ cloud.

Khi nào nên dùng volume

Volume là cách thường được dùng khi cần lưu trữ dữ liệu lâu dài trong container và services. Một số ứng dụng của volumes gồm:

• Chia sẻ dữ liệu giữa nhiều container đang chạy cùng lúc. Nhiều container có thể đồng thời mount cùng 1 volume. (read-write hoặc read only). Volume không tự động xóa đi, chúng ta cần phải gõ lệnh nếu muốn xóa volume.
• Khi chúng ta muốn lưu trữ dữ liệu của container trên remote host hoặc trên cloud provider (AWS, GCE, Azure…).
• Hoạt động được trên cả Linux và Windows container.
• Dữ liệu được lưu trên volume sẽ không làm tăng kích thước của container.
• Khi chúng ta cần backup, phục hồi hoặc di chuyển dữ liệu từ một Docker host này sang một host khác, volume là sự lựa chọn lý tưởng trong những trường hợp này. Ta có thể tạm dừng một container, backup volume của container này (thường nằm trong /var/lib/docker/volumes/)

Bind mounts

Có từ thời xửa thời xưa khi Docker mới ra đời. So với volume thì bind mount có ít chức năng hơn. Khi chúng ta dùng bind mount, chúng ta có thể mount 1 file hoặc một thư mục vào container. File hoặc thư mục này được truy cập theo đường dẫn tuyệt đối trên máy host. Bind mount có hiệu năng truy xuất rất cao, nhưng phụ thuộc vào file system của máy host.

Chú ý: khi dùng bind mount, các process trong container có thể thay đổi filesystem của máy host (tạo file, thêm xóa sửa các dữ liệu hoặc thư mục quan trọng của hệ thống). Tính năng này tuy mạnh nhưng có thể tạo ra nhiều nguy cơ về bảo mật, gây ảnh hưởng tới các process khác trên máy host.

Khi nào nên dùng bind mount

• Chia sẻ các file cấu hình từ máy host sang container. Ví dụ: bind mount file /etc/resolv.conf từ máy host lên mỗi container.
• Chia sẻ source code từ Docker host sang container.
• Khi file container cần file và thư mục phải đồng bộ với Docker host.

tmpfs mounts

tmpfs mount không được lưu trên đĩa cứng. tmpfs mount thường được dùng để lưu dữ liệu khi container đang chạy (dữ liệu này không cần được lưu trữ lâu dài).

Khi nào nên dùng tmpfs mount

tmpfs mount được dùng khi chúng ta không muốn lưu dữ liệu lâu dài trên cả máy host hoặc trong container vì lý do an ninh. Hoặc do chúng ta muốn đảm bảo hiệu năng của container khi cần xử lý một lượng lớn dữ liệu tạm thời

Một số chú ý khi dùng bind mount hoặc volume

Khi dùng bind mount hoặc volume thì cần chú ý những điều sau:

• Nếu chúng ta mount một volume trống từ host lên container, và trong thư mục tương ứng trên container đã có sẵn dữ liệu thì các file trên đó sẽ được copy vào volume. Tương tự vậy, nếu chúng ta khởi động một container và yêu cầu một volume (volume này chưa tồn tại), Docker engine sẽ tạo ra một volume trống cho ta.
• Nếu chúng ta mount một bind mount hoặc một volume đã có dữ liệu vào một thư mục trên container và thư mục này cũng đã có dữ liệu, dữ liệu trên container sẽ bị “tạm thời thay thế” bởi dữ liệu mới mount. Khi chúng ta unmount thì dữ liệu này sẽ hiện ra như cũ.
• Khi chúng ta dùng cờ -v hoặc --volume để bind-mount một file hay thư mục chưa tồn tại trên Docker host thì Docker sẽ tạo ra một thư mục mới.
• Nếu chúng ta dùng cờ --mount để bind-mount một file hay thư mục chưa tồn tại trên Docker host thì Docker không tự động tạo thư mục mới mà sẽ thông báo lỗi.

Ví dụ về sử dụng docker storage

Gỉa sử chúng ta cần develop một ứng dụng wordpress bao gồm 2 container:

• wordpress: chứa mã nguồn và chạy ứng dụng wordpress
• mariadb: chạy ứng dụng mariadb database (giống với mysql database)

Khi đó chúng ta sẽ sử dụng bind mount mã nguồn của wordpress vào container wordpress, sử dụng volume để persist data của mariadb database. Sử dụng với docker compose ta có thể xem file docker-compose.yml sau. (các bạn có thể xem chi tiết file docker-compose.yml và cấu trúc thư mục tại đây: https://github.com/cuongtransc/docker-training/tree/master/compose/wordpress)

services:
    wordpress:
        image: cuongtransc/wordpress:4.8
        ports:
            - "80:80"
        networks:
            - back
        volumes:
            - ./wordpress-data/:/var/www/html/ 

    mariadb:
        image: mariadb:10.1
        networks:
            - back
        volumes:
            - mariadb-data:/var/lib/mysql/

networks:
    back:
    
volumes:
    - mariadb-data

Với cách làm như trên, khi chúng ta sửa source code của wordpress trên máy host của chúng ta thì source code wordpress trong container cũng được thay đổi theo mà không cần build lại image. Còn với mariadb dữ liệu cũng được persistent và được Docker đảm bảo an toàn, không cho tiến trình khác có thể sửa đổi.

Tham khảo:

https://docs.docker.com/storage/

https://cloudcraft.info/nhap-mon-docker-phan-2-gioi-thieu-cac-kieu-luu-tru-du-lieu-tren-docker/

Phần 1: Docker là gì?

Phần 2: Ai sẽ dùng Docker?

Phần 3: Làm việc với Docker thế nào?

Phần 4: Có thể dùng Docker trong các trường hợp nào?

4.1 Các trường hợp dùng Docker

Docker có thể dùng trong các trường hợp:

• Hiện đại hóa các ứng dụng truyền thống.
• Microservices.
• DevOps (CI/CD).
• Tối ưu hóa hạ tầng tính toán.
• Hybrid Cloud.
• Dev Labs, tạo môi trường thử nghiệm cho Dev.

4.2 Các ví dụ thực tế

Một số công ty đã áp dụng Docker vào hệ thống thực.

• Shopify: chỉ cần 2 phút để triển khai ứng dụng monolithic của Shopify (bao gồm website bán hàng, quản lí khách hàng, ứng dụng Facebook, email marketing...)
• Baidu: sử dụng Docker để thay thế OpenStack cho hệ thống PaaS.
• eBay: sử dụng Docker để đơn giản hóa việc deploy ứng dụng.
• Uber: giảm thời gian triển khai từ vài tuần xuống còn vài phút.
• BBC New: giảm thời gian 30 phút triển khai cho 500 developer.

5. Docker Mindmap

Tài liệu tham khảo

1. Docker helped turbocharge Uber deployment. http://thenewstack.io/docker-helped-turbocharge-ubers-deployments/

2. Cuong Tran. Docker Training. https://github.com/cuongtransc/docker-training

Phần 1: Docker là gì?

Phần 2: Ai sẽ dùng Docker?

Phần 3: Làm việc với Docker thế nào?

Phần 4: Có thể dùng Docker trong các trường hợp nào?

3.1 Kiến trúc của Docker

Docker là có kiến trúc Client-Server, gồm:

• Docker Daemon: chạy ở trên host, đóng vai trò server, nhận các RESTful requests từ Docker Client và thực thi.
• Docker CLI: có vai trò là client, cung cấp giao diện tương tác với người dùng (command line) và gửi các RESTful requests tương ứng đến Docker Daemon.
• Docker Registry: private hay public registry, là nơi lưu trữ và chia sẻ các Docker Image.

Docker Daemon (còn gọi là Docker Engine) là một lightweight runtime giúp build, run và quản lí các containers và các thành phần liên quan.

Docker Engine quản lí 4 đối tượng chính. Tất cả các đối tượng đều có tên và ID.

• Image: là read-only template dùng để tạo containers. Được cấu tạo theo dạng layers, và tất cả các layers là read-only. Có thể tạo Docker Image bằng cách buid từ Dockerfile hoặc commit từ Docker Container.
• Container: là một runnable instance của một Docker Image. Khi chạy một container từ một Image, sẽ có một wriable layer được tạo ra và tất cả các thay đổi về dữ liệu sẽ diễn ra ở layer này. Lúc này, có thể sử dụng lệnh commit một container để tạo ra một image mới.
• Network: cung cấp private network (VLAN) để các container trên một host có thể liên lạc được với nhau, hoặc các container trên nhiều hosts có thể liên lạc được với nhau (multi-host networking).
• Volume: dùng để lưu trữ các dữ liệu độc lập với vòng đời của container và giúp cho các containers có thể chia sẻ dữ liệu với nhau và với host.

Sơ đồ minh họa các lệnh phổ biến của Docker Client và mối quan hệ của 4 đối tượng trên.

3.2 Một số câu lệnh cơ bản của Docker

3.3 Docker Container

Docker Container có đặc điểm là chóng tàn (emphemeral), nghĩa có thể khởi tạo nhanh và cũng có thể xóa nhanh. Không nên lưu dữ liệu trong container. Nếu cần lưu thì nên sử dụng Volume.

Docker Container sử dụng cơ chế process-based. Người dùng có thể tạo Docker Container bằng:

• docker run <image_name> <command>
• docker run <image_name>

Khi thực hiện một trong hai cách trên, một Docker Container sẽ được tạo và thực thi câu lệnh truyền vào hoặc câu lệnh mặc định đã được định nghĩa trong Docker Image. Câu lệnh này sẽ sinh process có pid = 1.

Nếu process này kết thúc thì Docker Container kết thúc. Khi đó, tất cả các process con của pid = 1 sẽ bị kill.

Vấn đề được đặt ra: Làm sao để start, stop application trong container đúng cách?

3.3 Docker Image

Để có thể chạy ứng dụng với Docker, bước đầu tiên cần làm là đóng gói ứng dụng vào Docker Image.

Ở đây, có một số điểm cần lưu ý, ví dụ như cần đóng gói ứng dụng như thế nào để ứng dụng có thể start, stop đúng cách.

Sử dụng entrypoint để quản lí việc start, stop application:
Một kịch bản được sử dụng khi build Docker Image là: sử dụng entrypoint để thực hiện các thao tác để chuẩn bị các điều kiện, start, stop application đúng cách.

Cụ thể, nhiệm vụ của entrypoint là:

1. Chuẩn bị các điều kiện môi trường để start application đúng cách.
2. Start application.
3. Thực hiện các thao tác để stop application đúng cách.

Sử dụng shell để làm entrypoint: nhận và xử lí các command được truyền vào khi chạy Docker Container.

1. Sử dụng python jinja2 để sinh ra các file cấu hình từ template. File cấu hình = jinja2(file cấu hình, tham số truyền vào bằng biến ENV)
2. Copy file cấu hình bằng lệnh cp.
3. Thực hiện các lệnh để khởi tạo ứng dụng, chown quyền các file cần thiết. Đảm bảo ứng dụng có thể start được.
4. Chạy ứng dụng.
5. Để ứng dụng handle SIGTERM hoặc sử dụng shell script để handle SIGTERM. Đảm bảo tắt ứng dụng đúng cách.

(Còn tiếp ...)

Tài liệu tham khảo

1. Luis Herrera Benítez, Docker Captain and AWS Ambassador. Exploring Docker. https://medium.com/@lherrera/mapping-docker-d003aa9017c1
2. Hệ sinh thái Docker. https://kipalog.com/posts/He-sinh-thai-Docker
3. Nguyễn Sỹ Thanh Sơn. Docker - Hướng tiếp cận mới của xu thế DevOps, SFD 2016.
4. Cuong Tran. Docker Image Template. https://github.com/cuongtransc/docker-image-tmpl

Phần 1: Docker là gì?

Phần 2: Ai sẽ dùng Docker?

Phần 3: Làm việc với Docker thế nào?

Phần 4: Có thể dùng Docker trong các trường hợp nào?

2.1 Docker cho lập trình viên (Dev)

Với lập trình viên, Docker mang lại những giá trị sau:

• Tính đóng gói (encapsulation): không lo lắng về việc thiếu thư viện phụ thuộc, thông tin cấu hình (config) khi triển khai một ứng dụng. Build một lần và chạy mọi nơi.
• Tính cô lập (isolation): tránh được xung đột khi chạy nhiều ứng dụng trên cùng một máy.
• Tính di động (portable): có thể dễ dàng chạy ứng dụng trên nhiều máy khác nhau. Không cần cài đặt lại.
• Có thể kịch bản hóa (script) hóa các công việc như kiểm thử tự động (automation testing), tích hợp (integration), đóng gói (packaging).
• Nhỏ gọn, chạy nhanh và ít tốn kém (overhead) hơn rất nhiều so với máy ảo (Virtual Machine).

2.2 Docker cho quản trị viên (Ops)

Với Ops, Docker mang lại những giá trị sau:

• Giúp cho việc quản lí toàn bộ vòng đời (lifecycle) của ứng dụng hiệu quả, nhất quán và có thể lặp lại
• Tăng chất lượng code.
• Loại bỏ xung đột giữa các môi trường phát triển, thử nghiệm và môi trường thực (production).
• Cải thiện đáng kể về tốc độ và độ tin cậy của hệ thống tích hợp liên tục và triển khai liên tục (CI/CD System)
• Tiết kiệm chi phí về thời gian, tài nguyên.

2.3 Dev và Ops quan tâm gì khi làm việc với Docker?

(Còn tiếp ...)

Tài liệu tham khảo

Nguyễn Sỹ Thanh Sơn. Docker - Hướng tiếp cận mới của xu thế DevOps, SFD 2016.

DevOps là một văn hóa làm việc đề cao sự hợp tác, kéo hai giai đoạn phát triển (development) và vận hành (operations) xích lại gần nhau hơn. Khái niệm DevOps ra đời nhằm tối ưu hóa chu trình phát triển phần mềm, giúp sản phẩm IT được release nhanh và thường xuyên hơn.

Để giúp các bạn mới bắt đầu làm quen với DevOps có cái nhìn tổng quan và dễ tiếp cận hơn, chúng tôi đã tổng hợp các Technologies được sử dụng phổ biến trong DevOps. (Click vào link mindmap để xem rõ hơn)

Link mindmap: https://www.mindmeister.com/1118050770#

P/S:  Nếu bạn nào biết thêm công nghệ nào hay, hữu ích thì hãy chia sẻ với mọi người ở dưới phần bình luận nhé!

Ở phần 1, chúng ta đã cùng tìm hiểu về tổng quan một hệ thống monitoring và các thành phần của TIG Stack - một stack monitoring phổ biến. Phần này chúng ta sẽ tìm hiểu cách deploy TIG Stack bằng Docker.

TIG stack Docker

Sử dụng Docker sẽ giúp chúng ta deploy TIG stack một cách dễ dàng và nhanh chóng, nhưng sẽ có một vài điểm cần lưu ý.

Trong thực tế hầu hết các trường hợp chúng ta thường monitor một cluster hơn là một máy đơn, vì thế bài viết này sẽ hướng dẫn deploy lên một cluster được quản lí bởi Docker Swarm.

Với Swarm cluster, InfluxDB và Grafana sẽ được cài trên cùng một node để tối ưu việc query, Telegraf sẽ được deploy với mode là global.

Telegraf

Mặc định khi chạy Telegraf bằng container nó chỉ collect metrics của container đó, để có thể collect data của host chúng ta cần mount một số file từ host vào và thay đổi một số config.

• Chúng ta cần mount các file sau (chú ý mode là ro):

- /var/run/docker.sock:/var/run/docker.sock:ro # collect docker metrics
- /sys:/rootfs/sys:ro
- /proc:/rootfs/proc:ro
- /etc:/rootfs/etc:ro

• Mặc định khi gửi metric đến database, Telegraf sẽ gửi kèm hostname (hostname của container). Vì thế chúng ta nên thay đổi config hostname trong file config của Telegraf hoặc đặt tên hostname của container cho phù hợp.
• Để collect thông tin của các docker containers chạy trên host chúng ta cần uncomment phần [[inputs.docker]] trong file config, và mout file /var/run/docker.sock của host
• Trong trường hợp muốn collect dữ liệu file log của một ứng dụng chạy trên host (có thể là container) chúng ta cần mount các file log vào trong Telegraf container và sử dụng plugin logparser để collect log. Tham khảo thêm: https://github.com/influxdata/telegraf/tree/release-1.5/plugins/inputs/logparser
• Trường hợp muốn collect các metrics của các services như mongo, rabbitmq (chạy trong container), chúng ta cần container của Telegraf có thể kết nối với các container của các services kia. Để giải quyết vấn để này chúng ta có thể làm theo 2 cách sau:
  Cách 1: Tạo external docker network và sử dụng cho tất cả các container
  Cách 2: Mapping port của services ra bên ngoài và Telegraf có thể sử dụng ip của host hoặc docker0 để truy cập

InfluxDB

Chạy InfluxDB với docker container chúng ta cần chú ý giữ an toàn dữ liệu của nó bằng cách sử dụng volume:

volumes:
     - "influxdb-data:/var/lib/influxdb"

Chúng ta có thể thêm biến environment để tạo sẵn database cho Telegraf:

environment:
     - INFLUXDB_DB=telegraf

Cấu hình data retention cho database của Telegraf. Mặc định InfluxDB sẽ tạo một RETENTION POLICY có tên là autogen với DURATION là vô hạn cho mỗi database, vì thế để cấu hình lại data retention cho database ta có thể sửa policy này:

ALTER RETENTION POLICY autogen ON telegraf DURATION 30d REPLICATION 1 SHARD DURATION 24h0

Grafana

Với Grafana chúng ta cũng cần giữ an toàn các dữ liệu của nó bằng cách sử dụng volume:

volumes:
      - grafana-data:/var/lib/grafana

Chúng ta cũng có thể sử dụng các biến environment để cấu hình password cho admin, hoặc tài khoản để gửi mail alert, ...

Grafana cung cấp một tập các dashboard được cấu hình sẵn tại đây: https://grafana.com/dashboards . Chúng ta tìm dashboard phù hợp rồi import vào Grafana thay vì phải config từ đầu. Với Telegraf, chúng tôi thường import dashboard này: https://grafana.com/dashboards/61

Để mọi người dễ hình dung các config, chúng tôi đã tạo sẵn Github repo. Mọi người có thể tham khảo tại: https://github.com/devopszcom/tig-monitoring

Screenshot

Tham khảo

https://angristan.xyz/monitoring-telegraf-influxdb-grafana/

Bài viết này sẽ giới thiệu tổng quan về hệ thống monitoring và giới thiệu Telegraf - Influxdb - Grafana (TIG) một stack monitoring phổ biến. Qua phần 2 chúng ta sẽ tìm hiểu cách deploy TIG stack với docker.

Khái niệm

Monitoring system là một hệ thống theo dõi, ghi lại các trạng thái, hoạt động của máy tính hay ứng dụng một cách liên tục.

Tại sao chúng ta cần Monitoring system?

• Dựa vào kết quả của hệ thống monitoring chúng ta có thể điêù chỉnh việc sử dụng tài nguyên (cpu, ram, disk, ...) sao cho phù hợp
• Ngăn chặn các sự cố có thể xảy ra, nếu có xảy ra chúng ta cũng có thể phát hiện sớm hơn
• Giảm thiểu thời gian quản lý hệ thống

=> Một hệ thống Monitoring tốt sẽ giúp tăng năng suất, chất lượng sản phẩm

Các đặc điểm của một hệ thống monitoring

• Xử lí real time
• Có hệ thống cảnh báo
• Visualization
• Có khả năng tạo reports
• Có khả năng cài cắm các plugins

Thành phần

Thông thường một hệ thống monitoring thường có 4 thành phần chính:

Collector: Được cài trên các máy agent (các máy muốn monitor), có nhiệm vụ collect metrics của host và gửi về database. Ví dụ: Cadvisor, Telegraf, Beat, ...

Database: Lưu trữ các metrics mà colletor thu thập được, thường thì chúng ta sẽ sử dụng các time series database. Ví dụ ElasticSearch, InfluxDB, Prometheus, Graphite (Whisper)

Visualizer: Có nhiệm vụ trực quan hóa các metrics thu thập được qua các biểu đồ, bảng, .... Ví dụ: Kibana, Grafana, Chronograf

Alerter: Gửi thống báo đến cho sysadmin khi có sự cố xảy ra

Có rất nhiều stack phổ biến như:

• Logstash - Elasticsearch - Kibana

• Prometheus - Node Exporter - Grafana

• Telegraf - InfluxDB - Grafana

Telegraf - Influxdb - Grafana Stack

Telegraf và Influxdb đều là sản phẩm của InfluxData, cả hai đều mà mã nguồn mở và được viết bởi Go. Mặc dù InfluxData cung cấp một stack hoàn chỉnh để monitor với Chronograf để visualize và Kapacitor để alerting (TICK stack) nhưng chúng ta có thể sử dụng Grafana để thay thế cho cả Chronograf lẫn Kapacitor.

Telegraf

https://www.influxdata.com/time-series-platform/telegraf/

Telegraf là một agent để collecting và reporting metrics và data được viết bởi Go.

Nó có thể tích hợp để collect nhiều loại nguồn dữ liệu khác nhau của metrics, events, và logs trực tiếp từ containers và system mà nó chạy trên đó. Nó cũng có thể pull metrics từ các third-party APIs, Kafka. Nó cũng có nhiều output plugin để gửi metrics thu thập được tới nhiều dạng datastores, services, message queues khác nhau như  InfluxDB, Graphite, OpenTSDB, Datadog, Librato, Kafka, ...

InfluxDB

https://www.influxdata.com/time-series-platform/influxdb/

InfluxDB là một Time Series Database (là database được tối ưu hóa để xử lý dữ liệu chuỗi thời gian, các dãy số được lập chỉ mục theo thời gian. )

InfluxDB được sử dụng để lưu các dữ liệu cho các trường hợp liên quan đến một lượng lớn time-stamped data, bao gồm DevOps monitoring, log data, application metrics, IoT sensor data, và real-time analytics. Nó có thể tự động xóa các dữ liệu cũ, không cần thiết và cung cấp một ngôn ngữ giống SQL để tương tác với dữ liệu.

Data trong InfluxDB được tổ chức dưới dạng time series. Time series có thể có một hoặc nhiều points, mỗi point là một mẫu rời rạc các số liệu. Point gồm:

• Time (timestamp)

• Một measurement (ví dụ "cpu_load")

• Ít nhất một key-value field (giá trị đo được, ví dụ "value=0.64", hoặc "temperature=21.2")

• Không hoặc nhiều key-value tags chứa metadata của value (ví dụ “host=server01”, “region=EMEA”, “dc=Frankfurt”)

Chúng ta có thể xem measurement như là table trong sql có primary index luôn là time. tags và field là columns của table, tags được index còn field thì không. Điểm khác biệt ở đây là InfluxDB có thể có hàng triệu measurements, chúng ta không cần định nghĩa schemas trước và giá trị null không được lưu trữ.

Downsampling and data retention

InfluxDB có thể xử lí được hàng trăm ngìn dữ liệu trong 1 giây. Cách lưu trữ dữ liệu giúp nó làm được điều này.

InfluxDB cung cấp 2 tính năng là Continuous Queries (CQ) và Retention Policies (RP). Chúng sẽ tự động xử lí downsampling data và expiring old data.

Continuous Query (CQ) là một InfluxQL query cái mà sẽ chạy tự động và theo định kỳ trong database. CQs yêu cầu một function trong mệnh đề SELECT và phải bao gồm mệnh đề GROUP BY time() - có thể hiểu là thằng này sẽ chạy trước các câu truy vấn của mình.

Retention Policy (RP) là một phần của InfluxDB’s data structure, biểu thị thời gian mà InfluxDB lưu giữu data. InfluxDB sẽ so sánh giữa thời gian của host với thời gian của dữ liệu và xóa bỏ các dữ liệu có thời gian cũ hơn RP’s DURATION (do chúng ta cấu hình). Một single database có thể có một số RPs và RPs là duy nhất cho mỗi database.

Grafana

https://grafana.com/grafana

Là một mã nguồn mở cho phép chúng ta query, visualize, alert các metrics thu thập được.
Khẩu hiệu của Grafana:

No matter where your data is, or what kind of database it lives in, you can bring it together with Grafana. Beautifully.

Các tính năng của Grafana:

• Visualize: table, chart, ...
• Alert: alert to email, slack, ...
• Unify: Hỗ trợ nhiều loại database như InfluxDB, ElasticSearch, Graphite, ...
• Open: mã nguồn mở, có thể chạy trên nhiều hệ điều hành, có office Docker image
• Extend: Cung cấp nhiều plugin, nhiều dashboard template
• Collaborate: Hỗ trợ teamwork

(Còn tiếp)

Tham khảo

https://hackernoon.com/monitor-your-infrastructure-with-tig-stack-b63971a15ccf

https://angristan.xyz/monitoring-telegraf-influxdb-grafana/

https://blog.pandorafms.org/why-you-need-a-monitoring-system/

Trong những năm gần đây, công nghệ Container ngày càng phát triển và trở nên phổ biến, với gương mặt nổi bật là Docker. Docker được sử dụng từ các công ty hàng đầu thế giới như Google, Uber đến các công ty khởi nghiệp, từ các lập trình viên (Dev) đến những người vận hành hệ thống (Ops).

Vậy Docker là gì? Vì sao Docker trở nên phổ biến như vậy? Vì sao tập người dùng của Docker rộng như vậy (Dev + Ops)? Chúng tôi xin được trình bày một số kiến thức về Docker thông qua chuỗi bài Docker 101.

Phần 1: Docker là gì?

Phần 2: Ai sẽ dùng Docker?

Phần 3: Làm việc với Docker thế nào?

Phần 4: Có thể dùng Docker trong các trường hợp nào?

1.1 Vấn đề triển khai hệ thống phần mềm

Với sự phát triển của công nghệ, việc triển khai hệ thống phần mềm trong thực tế ngày càng trở nên phức tạp.

Vấn đề: Các hệ thống phần mềm rất đa dạng về công nghệ.

Câu hỏi: Làm thế nào để các services (dịch vụ) và apps (ứng dụng) có thể tương tác với nhau một cách thích hợp (kết nối được với nhau, không xảy ra xung đột).

Vấn đề: Môi trường triển khai rất đa dạng, từ môi trường Dev, QA server đến môi trường Production Servers, Public Cloud.

Câu hỏi: Làm thế nào để có thể di chuyển (migrate), triển khai hệ thống phần mềm một cách trôi chảy và nhanh chóng?

Với hệ thống phần mềm trên, việc triển khai là một việc phức tạp và tốn nhiều công sức.

Nếu chúng ta có:

• n: là số lượng phần mềm
• m: là số lượng môi trường

Chúng ta sẽ cần triển khai nxm lần như hình dưới đây.

1.2 Vấn đề vận chuyển hàng hóa trong giao vận

Trước khi giải quyết vấn đề này, chúng ta cùng xem lại một vấn đề tương tự đã có trong lịch sử: vấn đề vận chuyển hàng hóa trong giao vận.

Việc vận chuyển hàng hóa trước những năm 1960 gặp vấn đề tương tự:

Vấn đề: Có rất nhiều loại hàng hóa khác nhau.

Câu hỏi:Các hàng hóa có bị trỗn lẫn vào nhau và làm giảm chất lượng không? Ví dụ: Vận chuyển hạt cà phê và gia vị cùng nhau.

Vấn đề:Vận chuyển trên nhiều loại phương tiện khác nhau.

Câu hỏi: Làm thế nào để có thể vận chuyển một cách trôi chảy và nhanh chóng? Ví dụ: vận chuyển hàng hóa từ thuyền lên tàu hỏa, rồi lên xe tải.

Một cách tương tự, chúng ta cũng có ma trận vận chuyển hàng hóa, với:

• n: là số lượng hàng hóa.
• m: là số lượng phương tiện.  

Chúng ta sẽ cần nxm lần đóng gói hàng hóa trên các phương tiện khác nhau.

1.3 Giải pháp gì cho ngành giao vận?

Những người trong ngành giao vận đã phát minh ra Container, phương tiện đóng gói đa năng.

• Một container tiêu chuẩn có thể chứa được hầu hết các loại mặt hàng và đóng kín cho đến khi đến được đích cuối cùng.
• Trong quá trình vận chuyển, container có thể được đặt vào các phương tiện khác nhau, có thể xếp chồng lên nhau, được vận chuyển hiệu quả trên các khoảng cách dài và dễ dàng chuyển từ phương tiện này sang phương tiện khác.

Kết quả: Việc phát minh ra container đã tạo nên một hệ sinh thái vận chuyển sử dụng container.

• 90% hàng hóa được vận chuyển trong các container tiêu chuẩn.
• Giảm được chi phí và thời gian để nạp và dỡ hàng.
• Giảm đáng kể tổn thất do trộm cắp hoặc hư hỏng.
• Giảm tỉ trọng của chi phí vận chuyển trong giá thành phẩm (từ hơn 25% xuống dưới 3%).
• Hiện nay, có hơn 5000 tàu vận chuyển hơn 200 triệu containers mỗi năm.

1.4 Giải pháp gì cho việc triển khai hệ thống phần mềm?

Tương tự như ngành giao vận, những người trong ngành công nghệ thông tin đã phát minh ra công nghệ container cho phần mềm. Và Docker là một giải pháp tiêu biểu cho công nghệ container.

• Docker là một động cơ (engine) cho phép đóng gói phần mềm như một container nhẹ (lightweight), di động (portable), hoạt động độc lập (self-sufficient).
• Có thể thao tác bằng cách sử dụng các lệnh tiêu chuẩn, và chạy nhất quán trên hầu hết các nền tảng phần cứng.

Bằng cách sử dụng công nghệ container, vấn đề triển khai hệ thống phần mềm đã được giải quyết, giảm được độ phức tạp của việc triển khai nxm lần xuống còn n lần đóng gói phần mềm vào container.

Kết quả:

• Thời gian triển khai từ hệ thống phát triển (Dev) sang hệ thống thực (Production) giảm từ 9 tháng xuống còn 15 phút (ING)
• Thời gian để chạy công việc tích hợp (job) trong hệ thống tích hợp liên tục (CI) giảm hơn 60% (BBC)
• Thời gian triển khai từ hệ thống phát triển (Dev) sang hệ thống thực (Production) giảm từ vài tuần xuống còn vài phút (Uber)

1.5 Khái niệm cơ bản về Docker

Docker là một công cụ dùng để đóng gói, vận chuyển và chạy container một cách đơn giản và dễ dàng trên các nền tảng khác nhau.

Docker đóng gói một phần mềm trong một hệ thống tập tin (file system) hoàn chỉnh, có chứa mọi thứ cần thiết để chạy, bao gồm:

• Mã (Code)
• Runtime
• Các công cụ hệ thống (System Tools)
• Các thư viện hệ thống (System Libraries)
• Bất cứ thứ gì bạn có thể cài trên một server

Docker thực hiện ảo hóa ở mức hệ điều hành. Mỗi container là cô lập (isolated), nhưng dùng chung Kernel và một số bin/thư viện thích hợp. Điều này giúp container triển khai nhanh hơn, ít tốn kém hơn (overhead), di chuyển (migration) dễ dàng và khởi động lại nhanh hơn.

(Còn tiếp ...)

Tài liệu tham khảo

https://www.docker.com/