mirror of
https://github.com/MichaelCade/90DaysOfDevOps.git
synced 2024-12-22 16:33:11 +07:00
Michael Cade
GitHub
commit
877de175fe
83
2022/vi/Days/day79.md
Normal file
83
2022/vi/Days/day79.md
Normal file
@ -0,0 +1,83 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - Bức tranh toàn cảnh: Quản lý log - Ngày 79'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Bức tranh toàn cảnh: Quản lý log
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1049057
|
||||
---
|
||||
|
||||
## Bức tranh toàn cảnh: Quản lý Log
|
||||
|
||||
Tiếp nối về giải pháp giám sát cơ sở hạ tầng, quản lý log là một mảnh ghép khác về khả năng quan sát tổng thể.
|
||||
|
||||
### Quản lý và tổng hợp Log
|
||||
|
||||
Hãy nói về hai khái niệm cốt lõi, trong đó khái niệm đầu tiên là tổng hợp log và cách thu thập và gắn tag các log ứng dụng từ nhiều dịch vụ khác nhau trong một bảng điều khiển duy nhất có thể tìm kiếm dễ dàng.
|
||||
|
||||
Một trong những hệ thống đầu tiên cần được xây dựng trong một hệ thống quản lý hiệu suất ứng dụng (APM) là tổng hợp log. Quản lý hiệu suất ứng dụng là phần của vòng đời DevOps khi mọi thứ đã được xây dựng và triển khai, bạn cần đảm bảo rằng chúng vẫn hoạt động liên tục, có đủ tài nguyên được phân bổ và lỗi không hiển thị cho người dùng. Trong hầu hết các triển khai trên môi trường sản xuất, nhiều sự kiện liên quan tạo ra log trên các dịch vụ. Ví dụ, với Google, một lần tìm kiếm duy nhất có thể phát sinh truy cập vào mười dịch vụ khác nhau trước khi kết quả được trả về cho người dùng. Nếu bạn nhận được kết quả tìm kiếm không mong đợi, điều đó có nghĩa là có vấn đề logic tại bất kỳ một trong mười dịch vụ đó. Tổng hợp log giúp các công ty như Google chẩn đoán, phát hiện các vấn đề trong môi trường sản xuất. Họ đã xây dựng một bảng điều khiển duy nhất, nơi họ có thể ánh xạ mọi request tới một ID duy nhất. Khi bạn tìm kiếm trên Google, request tìm kiếm của bạn sẽ nhận được một ID duy nhất và sau mỗi lần tìm kiếm đó đi qua một dịch vụ khác nhau, dịch vụ đó sẽ kết nối ID đó với những xử lý trong dịch vụ đó.
|
||||
|
||||
Đây là điều cơ bản của một nền tảng tổng hợp log tốt, giúp thu thập log từ mọi nơi tạo ra chúng và có thể dễ dàng tìm kiếm lại trong trường hợp có lỗi phát sinh.
|
||||
|
||||
### Ứng dụng ví dụ
|
||||
|
||||
Ứng dụng ví dụ của chúng ta là một ứng dụng web gồm có frontend và backend lưu trữ dữ liệu quan trọng trong cơ sở dữ liệu MongoDB.
|
||||
|
||||
Nếu một người dùng nói với chúng ta rằng trang web trắng toàn bộ và trả lại một thông báo lỗi, chúng ta sẽ gặp khó khăn trong việc chẩn đoán vấn đề với stack hiện tại. Người dùng sẽ cần phải gửi lỗi một cách thủ công và chúng ta cần phải kết hợp nó với log liên quan trong ba dịch vụ khác.
|
||||
|
||||
### ELK
|
||||
|
||||
Hãy cùng tìm hiểu về ELK, một stack tổng hợp log mã nguồn mở phổ biến được đặt theo tên ba thành phần của nó là Elasticsearch, Logstash và Kibana. Chúng ta sẽ cài đặt nó trong cùng một môi trường với ứng dụng ví dụ.
|
||||
|
||||
Ứng dụng web sẽ kết nối với giao diện frontend trước, sau đó kết nối với backend, backend sẽ gửi log đến Logstash và sau đó ba thành phần này sẽ hoạt động.
|
||||
|
||||
### Các thành phần của ELK
|
||||
|
||||
Elasticsearch, Logstash và Kibana: tất cả các dịch vụ gửi log đến Logstash, Logstash lấy những log này là văn bản được phát ra bởi ứng dụng. Ví dụ, trong ứng dụng web, khi bạn truy cập vào một trang web, trang web có thể ghi log truy cập của khách truy cập này vào trang này vào thời gian này, và đó là một ví dụ về một thông báo log. Những log đó sẽ được gửi đến Logstash.
|
||||
|
||||
Logstash sau đó sẽ trích xuất các thông tin từ chúng. Ví dụ, thông báo log ghi nhận người dùng đã **làm gì** vào **thời gian nào**. Bạn có thể tìm kiếm chúng một cách dễ dàng và tìm tất cả các yêu cầu được thực hiện bởi một người dùng cụ thể.
|
||||
|
||||
Logstash không lưu trữ thông tin mà lưu trữ trong Elasticsearch, một cơ sở dữ liệu hiệu quả để truy vấn văn bản. Elasticsearch hiển thị kết quả qua Kibana. Kibana là một máy chủ web kết nối với Elasticsearch và cho phép các quản trị viên hoặc các thành viên trong nhóm, như kỹ sư trực, xem các log trong môi trường sản xuất bất cứ khi nào có lỗi lớn. Bạn, với tư cách là quản trị viên, sẽ kết nối với Kibana, và Kibana sẽ truy vấn Elasticsearch để tìm các log khớp với yêu cầu của bạn.
|
||||
|
||||
Bạn có thể nhập vào thanh tìm kiếm của Kibana để tìm lỗi và Kibana sẽ yêu cầu Elasticsearch tìm các thông báo chứa chuỗi "error". Elasticsearch sẽ trả về các kết quả đã được Logstash lưu trữ. Logstash đã nhận những kết quả đó từ tất cả các dịch vụ khác.
|
||||
|
||||
### Cách sử dụng ELK để chẩn đoán vấn đề trong môi trường sản xuất
|
||||
|
||||
Một người dùng nói rằng họ thấy mã lỗi 1234567 khi họ cố gắng thực hiện một thao tác. Với cấu hình ELK, chúng ta sẽ vào Kibana, nhập 1234567 vào thanh tìm kiếm và nhấn Enter. Kết quả sẽ hiển thị các log tương ứng và một trong số đó có thể hiển thị "internal server error returning 1234567". Chúng ta sẽ thấy dịch vụ nào đã tạo ra log đó, và thời gian log đó được ghi lại. Chúng ta có thể xem các thông báo phía trên và dưới log đó trong backend để hiểu rõ hơn về những gì đã xảy ra với yêu cầu của người dùng. Chúng ta sẽ lặp lại quy trình này với các dịch vụ khác cho đến khi tìm ra nguyên nhân gây ra vấn đề.
|
||||
|
||||
### Bảo mật và truy cập vào log
|
||||
|
||||
Một phần quan trọng của việc quản lý log là đảm bảo rằng log chỉ hiển thị cho quản trị viên (hoặc những người và nhóm cần truy cập). Log có thể chứa thông tin nhạy cảm như token, chỉ những người dùng đã xác thực mới nên có quyền truy cập. Bạn không nên để Kibana lộ ra ngoài internet mà không có cách nào để xác thực.
|
||||
|
||||
### Ví dụ về các công cụ quản lý log
|
||||
|
||||
Một số nền tảng quản lý log bao gồm:
|
||||
|
||||
- Elasticsearch
|
||||
- Logstash
|
||||
- Kibana
|
||||
- Fluentd - một lựa chọn mã nguồn mở phổ biến
|
||||
- Datadog - hosted offering, thường được sử dụng tại các doanh nghiệp lớn
|
||||
- LogDNA - hosted offering
|
||||
- Splunk
|
||||
|
||||
Các nhà cung cấp dịch vụ đám mây cũng cung cấp các công cụ logging như AWS CloudWatch Logs, Microsoft Azure Monitor và Google Cloud Logging.
|
||||
|
||||
Quản lý log là một khía cạnh quan trọng của việc quan sát tổng thể các ứng dụng và môi trường cơ sở hạ tầng của bạn để chẩn đoán các vấn đề trong môi trường sản xuất. Việc cài đặt một giải pháp trọn gói như ELK hoặc CloudWatch khá đơn giản và nó giúp việc chẩn đoán và xử lý sự cố trong sản xuất dễ dàng hơn đáng kể.
|
||||
|
||||
## Tài liệu tham khảo
|
||||
|
||||
- [The Importance of Monitoring in DevOps](https://www.devopsonline.co.uk/the-importance-of-monitoring-in-devops/)
|
||||
- [Understanding Continuous Monitoring in DevOps?](https://medium.com/devopscurry/understanding-continuous-monitoring-in-devops-f6695b004e3b)
|
||||
- [DevOps Monitoring Tools](https://www.youtube.com/watch?v=Zu53QQuYqJ0)
|
||||
- [Top 5 - DevOps Monitoring Tools](https://www.youtube.com/watch?v=4t71iv_9t_4)
|
||||
- [How Prometheus Monitoring works](https://www.youtube.com/watch?v=h4Sl21AKiDg)
|
||||
- [Introduction to Prometheus monitoring](https://www.youtube.com/watch?v=5o37CGlNLr8)
|
||||
- [Promql cheat sheet with examples](https://www.containiq.com/post/promql-cheat-sheet-with-examples)
|
||||
- [Log Management for DevOps | Manage application, server, and cloud logs with Site24x7](https://www.youtube.com/watch?v=J0csO_Shsj0)
|
||||
- [Log Management what DevOps need to know](https://devops.com/log-management-what-devops-teams-need-to-know/)
|
||||
- [What is ELK Stack?](https://www.youtube.com/watch?v=4X0WLg05ASw)
|
||||
- [Fluentd simply explained](https://www.youtube.com/watch?v=5ofsNyHZwWE&t=14s)
|
||||
|
||||
Hẹn gặp lại vào [ngày 80](day80.md).
|
||||
106
2022/vi/Days/day80.md
Normal file
106
2022/vi/Days/day80.md
Normal file
@ -0,0 +1,106 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - ELK Stack - Ngày 80'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - ELK Stack
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048746
|
||||
---
|
||||
|
||||
## ELK Stack
|
||||
|
||||
Trong buổi này, chúng ta sẽ thực hành với một số tùy chọn mà chúng ta đã đề cập.
|
||||
|
||||
ELK Stack là sự kết hợp của 3 công cụ riêng biệt:
|
||||
|
||||
- [Elasticsearch](https://www.elastic.co/what-is/elasticsearch) là một công cụ tìm kiếm và phân tích miễn phí và mở rộng cho mọi loại dữ liệu, bao gồm dữ liệu văn bản, số, địa lý, cấu trúc và phi cấu trúc.
|
||||
|
||||
- [Logstash](https://www.elastic.co/logstash/) là một đường dẫn xử lý dữ liệu phía máy chủ miễn phí mã nguồn mở, nhận dữ liệu từ nhiều nguồn, chuyển đổi dữ liệu, và sau đó gửi nó đến nơi lưu trữ phù hợp.
|
||||
|
||||
- [Kibana](https://www.elastic.co/kibana/) là một giao diện người dùng miễn phí mã nguồn mở cho phép bạn trực quan hóa dữ liệu từ Elasticsearch và điều hướng trong Elastic Stack. Bạn có thể làm mọi thứ từ theo dõi tải truy vấn đến hiểu cách các yêu cầu luân chuyển qua các ứng dụng của bạn.
|
||||
|
||||
ELK stack cho phép chúng ta thu thập dữ liệu từ bất kỳ nguồn nào, ở bất kỳ định dạng nào, sau đó tìm kiếm, phân tích và trực quan hóa nó trong thời gian thực.
|
||||
|
||||
Ngoài các thành phần đã đề cập, bạn cũng có thể thấy Beats, là những tác nhân nhẹ được cài đặt trên các máy chủ biên để thu thập các loại dữ liệu khác nhau và chuyển tiếp vào stack.
|
||||
|
||||
- Logs: Log máy chủ cần được phân tích được xác định.
|
||||
|
||||
- Logstash: Thu thập log và dữ liệu sự kiện. Nó thậm chí còn phân tích và chuyển đổi dữ liệu.
|
||||
|
||||
- Elasticsearch: Dữ liệu đã được chuyển đổi từ Logstash được lưu trữ, tìm kiếm và lập chỉ mục.
|
||||
|
||||
- Kibana sử dụng cơ sở dữ liệu Elasticsearch để khám phá, trực quan hóa và chia sẻ.
|
||||
|
||||
|
||||
|
||||
[Hình ảnh từ Guru99](https://www.guru99.com/elk-stack-tutorial.html)
|
||||
|
||||
Một tài nguyên tốt giải thích về [Hướng dẫn hoàn chỉnh về ELK Stack](https://logz.io/learn/complete-guide-elk-stack/)
|
||||
|
||||
Với sự bổ sung của Beats, ELK Stack cũng được gọi là Elastic Stack.
|
||||
|
||||
Trong kịch bản thực hành, có nhiều nơi bạn có thể triển khai Elastic Stack nhưng chúng ta sẽ sử dụng docker-compose để triển khai cục bộ trên hệ thống của mình.
|
||||
|
||||
[Bắt đầu Elastic Stack với Docker Compose](https://www.elastic.co/guide/en/elastic-stack-get-started/current/get-started-stack-docker.html#get-started-docker-tls)
|
||||
|
||||
|
||||
|
||||
Bạn sẽ tìm thấy các tệp gốc và hướng dẫn mà tôi đã sử dụng tại đây [deviantony/docker-elk](https://github.com/deviantony/docker-elk)
|
||||
|
||||
Bây giờ chúng ta có thể chạy `docker-compose up -d`, lần chạy đầu tiên sẽ yêu cầu tải các images.
|
||||
|
||||
|
||||
|
||||
Nếu bạn theo dõi repository này hoặc repository mà tôi đã sử dụng, bạn sẽ có mật khẩu là "changeme" hoặc trong repository của tôi là "90DaysOfDevOps". Tên người dùng là "elastic".
|
||||
|
||||
Sau vài phút, chúng ta có thể truy cập `http://localhost:5601/` là máy chủ Kibana / container Docker của chúng ta.
|
||||
|
||||
|
||||
|
||||
Màn hình chính ban đầu của bạn sẽ trông giống như thế này.
|
||||
|
||||
|
||||
|
||||
Dưới phần "Get started by adding integrations", có một phần "try sample data", nhấp vào đây và chúng ta có thể thêm một trong những dữ liệu mẫu bên dưới.
|
||||
|
||||
|
||||
|
||||
Tôi sẽ chọn "Sample weblogs" nhưng điều này thực sự chỉ để có cái nhìn và cảm nhận về các tập dữ liệu bạn có thể nhập vào ELK stack.
|
||||
|
||||
Khi bạn đã chọn "Add Data", việc này sẽ mất một thời gian để nhập một số dữ liệu đó và sau đó bạn sẽ có tùy chọn "View Data" và danh sách các cách xem dữ liệu có sẵn trong dropdown.
|
||||
|
||||
|
||||
|
||||
Như được ghi trên bảng điều khiển:
|
||||
|
||||
**Dữ liệu Log Mẫu**
|
||||
|
||||
> Bảng điều khiển này chứa dữ liệu mẫu để bạn khám phá. Bạn có thể xem, tìm kiếm và tương tác với các trực quan hóa. Để biết thêm thông tin về Kibana, hãy kiểm tra tài liệu của chúng tôi.
|
||||
|
||||
|
||||
|
||||
Đây là việc sử dụng Kibana để trực quan hóa dữ liệu đã được thêm vào Elasticsearch thông qua Logstash. Đây không phải là tùy chọn duy nhất nhưng tôi muốn triển khai và xem qua nó.
|
||||
|
||||
Chúng ta sẽ đề cập đến Grafana vào lúc nào đó và bạn sẽ thấy một số điểm tương đồng trong việc trực quan hóa dữ liệu giữa hai công cụ này, bạn cũng đã thấy Prometheus.
|
||||
|
||||
Điểm mấu chốt mà tôi nhận thấy giữa Elastic Stack và Prometheus + Grafana là Elastic Stack hoặc ELK Stack tập trung vào log, còn Prometheus tập trung vào metrics.
|
||||
|
||||
Tôi đã đọc bài viết này từ MetricFire [Prometheus vs. ELK](https://www.metricfire.com/blog/prometheus-vs-elk/) để hiểu rõ hơn về các dịch vụ khác nhau.
|
||||
|
||||
## Tài liệu tham khảo
|
||||
|
||||
- [Understanding Logging: Containers & Microservices](https://www.youtube.com/watch?v=MMVdkzeQ848)
|
||||
- [The Importance of Monitoring in DevOps](https://www.devopsonline.co.uk/the-importance-of-monitoring-in-devops/)
|
||||
- [Understanding Continuous Monitoring in DevOps?](https://medium.com/devopscurry/understanding-continuous-monitoring-in-devops-f6695b004e3b)
|
||||
- [DevOps Monitoring Tools](https://www.youtube.com/watch?v=Zu53QQuYqJ0)
|
||||
- [Top 5 - DevOps Monitoring Tools](https://www.youtube.com/watch?v=4t71iv_9t_4)
|
||||
- [How Prometheus Monitoring works](https://www.youtube.com/watch?v=h4Sl21AKiDg)
|
||||
- [Introduction to Prometheus monitoring](https://www.youtube.com/watch?v=5o37CGlNLr8)
|
||||
- [Promql cheat sheet with examples](https://www.containiq.com/post/promql-cheat-sheet-with-examples)
|
||||
- [Log Management for DevOps | Manage application, server, and cloud logs with Site24x7](https://www.youtube.com/watch?v=J0csO_Shsj0)
|
||||
- [Log Management what DevOps need to know](https://devops.com/log-management-what-devops-teams-need-to-know/)
|
||||
- [What is ELK Stack?](https://www.youtube.com/watch?v=4X0WLg05ASw)
|
||||
- [Fluentd simply explained](https://www.youtube.com/watch?v=5ofsNyHZwWE&t=14s)
|
||||
|
||||
Hẹn gặp lại vào [ngày 81](day81.md).
|
||||
167
2022/vi/Days/day81.md
Normal file
167
2022/vi/Days/day81.md
Normal file
@ -0,0 +1,167 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - Fluentd & FluentBit - Ngày 81'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Fluentd & FluentBit
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048716
|
||||
---
|
||||
|
||||
## Fluentd & FluentBit
|
||||
|
||||
Một công cụ thu thập dữ liệu khác mà tôi muốn khám phá trong phần quan sát này là [Fluentd](https://docs.fluentd.org/). Đây là một logging layer mã nguồn mở.
|
||||
|
||||
Fluentd có bốn tính năng chính làm cho nó phù hợp để xây dựng các đường dẫn log dễ dàng và đáng tin cậy:
|
||||
|
||||
- **Ghi log hợp nhất với JSON:** Fluentd cố gắng cấu trúc dữ liệu dưới dạng JSON càng nhiều càng tốt. Điều này cho phép Fluentd hợp nhất tất cả các khía cạnh của xử lý dữ liệu log: thu thập, lọc, buffer và xuất log tới nhiều nguồn và điểm đích. Quá trình xử lý dữ liệu đầu cuối dễ dàng hơn nhiều với JSON vì nó có đủ cấu trúc để truy cập mà không cần sử dụng các schema cứng nhắc.
|
||||
|
||||
- **Kiến trúc Pluggable:** Fluentd có hệ thống plugin linh hoạt cho phép cộng đồng mở rộng chức năng của nó. Hơn 300 plugin do cộng đồng đóng góp kết nối hàng chục nguồn dữ liệu với hàng chục đầu ra dữ liệu, xử lý dữ liệu theo nhu cầu. Bằng cách sử dụng plugin, bạn có thể tận dụng log của mình tốt hơn ngay lập tức.
|
||||
|
||||
- **Yêu cầu tài nguyên tối thiểu:** Một công cụ thu thập dữ liệu nên nhẹ để nó có thể chạy thoải mái trên một máy có tải cao. Fluentd được viết bằng kết hợp giữa C và Ruby và yêu cầu tài nguyên hệ thống tối thiểu. Phiên bản thông thường chỉ sử dụng 30-40MB bộ nhớ và có thể xử lý 13.000 sự kiện/giây trên mỗi core.
|
||||
|
||||
- **Độ tin cậy tích hợp:** Mất dữ liệu không bao giờ nên xảy ra. Fluentd hỗ trợ buffer dựa trên bộ nhớ và tệp để ngăn ngừa mất dữ liệu giữa các node. Fluentd cũng hỗ trợ failover và có thể được thiết lập để có tính khả dụng cao (HA).
|
||||
|
||||
[Cài đặt Fluentd](https://docs.fluentd.org/quickstart#step-1-installing-fluentd)
|
||||
|
||||
### Các ứng dụng ghi log dữ liệu như thế nào?
|
||||
|
||||
- Ghi vào tệp `.log` (khó phân tích nếu không có công cụ và ở quy mô lớn).
|
||||
- Ghi trực tiếp vào cơ sở dữ liệu (mỗi ứng dụng phải được cấu hình đúng định dạng).
|
||||
- Các ứng dụng của bên thứ ba (NodeJS, NGINX, PostgreSQL).
|
||||
|
||||
Đây là lý do tại sao chúng ta cần một lớp ghi log hợp nhất.
|
||||
|
||||
Fluentd cho phép chúng ta sử dụng ba loại dữ liệu log trên và cho phép thu thập, xử lý và gửi chúng đến một điểm đích, ví dụ như gửi log đến các cơ sở dữ liệu Elastic, MongoDB hoặc Kafka.
|
||||
|
||||
Bất kỳ dữ liệu nào, từ bất kỳ nguồn dữ liệu nào cũng có thể được gửi đến Fluentd và từ đó có thể gửi đến bất kỳ điểm đích nào. Fluentd không bị ràng buộc với bất kỳ nguồn hoặc điểm đích cụ thể nào.
|
||||
|
||||
Trong quá trình nghiên cứu Fluentd, tôi đã gặp Fluent Bit như một tùy chọn khác và có vẻ nếu bạn muốn triển khai công cụ ghi log vào môi trường Kubernetes thì Fluent Bit sẽ cung cấp cho bạn khả năng đó, mặc dù Fluentd cũng có thể được triển khai vào các container cũng như máy chủ.
|
||||
|
||||
[Fluentd & Fluent Bit](https://docs.fluentbit.io/manual/about/fluentd-and-fluent-bit)
|
||||
|
||||
Fluentd và Fluent Bit sẽ sử dụng các plugin đầu vào để chuyển đổi dữ liệu đó sang định dạng Fluent Bit, sau đó chúng ta có các plugin đầu ra cho bất kỳ điểm đích nào như Elasticsearch.
|
||||
|
||||
Chúng ta cũng có thể sử dụng thẻ để kết nối các cấu hình.
|
||||
|
||||
Tôi không thấy lý do nào để sử dụng Fluentd và dường như Fluent Bit là cách tốt nhất để bắt đầu. Mặc dù chúng có thể được sử dụng cùng nhau trong một số kiến trúc.
|
||||
|
||||
### Fluent Bit trong Kubernetes
|
||||
|
||||
Fluent Bit trong Kubernetes được triển khai dưới dạng DaemonSet, có nghĩa là nó sẽ chạy trên mỗi node trong cluster. Mỗi pod Fluent Bit trên mỗi node sẽ đọc từng container trên node đó và thu thập tất cả các log có sẵn. Nó cũng sẽ thu thập siêu dữ liệu từ Kubernetes API Server.
|
||||
|
||||
Các annotations của Kubernetes có thể được sử dụng trong tệp YAML cấu hình của các ứng dụng của chúng ta.
|
||||
|
||||
Trước tiên, chúng ta có thể triển khai từ helm repository của fluent. `helm repo add fluent https://fluent.github.io/helm-charts` và sau đó cài đặt bằng lệnh `helm install fluent-bit fluent/fluent-bit`.
|
||||
|
||||
|
||||
|
||||
Trong cluster của tôi, tôi cũng đang chạy Prometheus trong namespace mặc định (cho mục đích kiểm tra), chúng ta cần đảm bảo pod fluent-bit của mình đang hoạt động. Chúng ta có thể làm điều này bằng cách sử dụng `kubectl get all | grep fluent` để hiển thị pod, service và daemonset đang chạy mà chúng ta đã đề cập trước đó.
|
||||
|
||||
|
||||
|
||||
Để fluent-bit biết nơi lấy log, chúng ta có một tệp cấu hình, trong triển khai Kubernetes của fluent-bit, chúng ta có một configmap đại diện cho tệp cấu hình.
|
||||
|
||||
|
||||
|
||||
ConfigMap đó sẽ trông giống như sau:
|
||||
|
||||
```
|
||||
Name: fluent-bit
|
||||
Namespace: default
|
||||
Labels: app.kubernetes.io/instance=fluent-bit
|
||||
app.kubernetes.io/managed-by=Helm
|
||||
app.kubernetes.io/name=fluent-bit
|
||||
app.kubernetes.io/version=1.8.14
|
||||
helm.sh/chart=fluent-bit-0.19.21
|
||||
Annotations: meta.helm.sh/release-name: fluent-bit
|
||||
meta.helm.sh/release-namespace: default
|
||||
|
||||
Data
|
||||
====
|
||||
custom_parsers.conf:
|
||||
----
|
||||
[PARSER]
|
||||
Name docker_no_time
|
||||
Format json
|
||||
Time_Keep Off
|
||||
Time_Key time
|
||||
Time_Format %Y-%m-%dT%H:%M:%S.%L
|
||||
|
||||
fluent-bit.conf:
|
||||
----
|
||||
[SERVICE]
|
||||
Daemon Off
|
||||
Flush 1
|
||||
Log_Level info
|
||||
Parsers_File parsers.conf
|
||||
Parsers_File custom_parsers.conf
|
||||
HTTP_Server On
|
||||
HTTP_Listen 0.0.0.0
|
||||
HTTP_Port 2020
|
||||
Health_Check On
|
||||
|
||||
[INPUT]
|
||||
Name tail
|
||||
Path /var/log/containers/*.log
|
||||
multiline.parser docker, cri
|
||||
Tag kube.*
|
||||
Mem_Buf_Limit 5MB
|
||||
Skip_Long_Lines On
|
||||
|
||||
[INPUT]
|
||||
Name systemd
|
||||
Tag host.*
|
||||
Systemd_Filter _SYSTEMD_UNIT=kubelet.service
|
||||
Read_From_Tail On
|
||||
|
||||
[FILTER]
|
||||
Name Kubernetes
|
||||
Match kube.*
|
||||
Merge_Log On
|
||||
Keep_Log Off
|
||||
K8S-Logging.Parser On
|
||||
K8S-Logging.Exclude On
|
||||
|
||||
[OUTPUT]
|
||||
Name es
|
||||
Match kube.*
|
||||
Host elasticsearch-master
|
||||
Logstash_Format On
|
||||
Retry_Limit False
|
||||
|
||||
[OUTPUT]
|
||||
Name es
|
||||
Match host.*
|
||||
Host elasticsearch-master
|
||||
Logstash_Format On
|
||||
Logstash_Prefix node
|
||||
Retry_Limit False
|
||||
|
||||
Events: <none>
|
||||
```
|
||||
|
||||
|
||||
Chúng ta bây giờ có thể chuyển tiếp cổng pod của mình tới localhost để đảm bảo rằng chúng ta có kết nối. Trước tiên lấy tên pod của bạn với `kubectl get pods | grep fluent` và sau đó sử dụng `kubectl port-forward fluent-bit-8kvl4 2020:2020` để mở trình duyệt web tới `http://localhost:2020/`.
|
||||
|
||||
|
||||
|
||||
Tôi cũng tìm thấy bài viết này trên medium giải thích thêm về [Fluent Bit](https://medium.com/kubernetes-tutorials/exporting-kubernetes-logs-to-elasticsearch-using-fluent-bit-758e8de606af).
|
||||
|
||||
## Tài liệu tham khảo
|
||||
|
||||
- [Understanding Logging: Containers & Microservices](https://www.youtube.com/watch?v=MMVdkzeQ848)
|
||||
- [The Importance of Monitoring in DevOps](https://www.devopsonline.co.uk/the-importance-of-monitoring-in-devops/)
|
||||
- [Understanding Continuous Monitoring in DevOps?](https://medium.com/devopscurry/understanding-continuous-monitoring-in-devops-f6695b004e3b)
|
||||
- [DevOps Monitoring Tools](https://www.youtube.com/watch?v=Zu53QQuYqJ0)
|
||||
- [Top 5 - DevOps Monitoring Tools](https://www.youtube.com/watch?v=4t71iv_9t_4)
|
||||
- [How Prometheus Monitoring works](https://www.youtube.com/watch?v=h4Sl21AKiDg)
|
||||
- [Introduction to Prometheus monitoring](https://www.youtube.com/watch?v=5o37CGlNLr8)
|
||||
- [Promql cheat sheet with examples](https://www.containiq.com/post/promql-cheat-sheet-with-examples)
|
||||
- [Log Management for DevOps | Manage application, server, and cloud logs with Site24x7](https://www.youtube.com/watch?v=J0csO_Shsj0)
|
||||
- [Log Management what DevOps need to know](https://devops.com/log-management-what-devops-teams-need-to-know/)
|
||||
- [What is ELK Stack?](https://www.youtube.com/watch?v=4X0WLg05ASw)
|
||||
- [Fluentd simply explained](https://www.youtube.com/watch?v=5ofsNyHZwWE&t=14s)
|
||||
- [Fluent Bit explained | Fluent Bit vs Fluentd](https://www.youtube.com/watch?v=B2IS-XS-cc0)
|
||||
|
||||
Hẹn gặp lại vào [ngày 82](day82.md)
|
||||
110
2022/vi/Days/day82.md
Normal file
110
2022/vi/Days/day82.md
Normal file
@ -0,0 +1,110 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - EFK Stack - Ngày 82'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - EFK Stack
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1049059
|
||||
---
|
||||
|
||||
### EFK Stack
|
||||
|
||||
Trong phần trước, chúng ta đã nói về ELK Stack, sử dụng Logstash để thu thập log. Trong EFK Stack, chúng ta sử dụng FluentD hoặc FluentBit để thay thế.
|
||||
|
||||
Nhiệm vụ của chúng ta trong phần này là giám sát logs của Kubernetes với EFK.
|
||||
|
||||
### Tổng quan về EFK
|
||||
|
||||
Chúng ta sẽ triển khai những thứ sau vào cụm Kubernetes của mình.
|
||||
|
||||
|
||||
|
||||
EFK stack là tập hợp gồm 3 phần mềm đi kèm với nhau, bao gồm:
|
||||
|
||||
- **Elasticsearch:** Cơ sở dữ liệu NoSQL được sử dụng để lưu trữ dữ liệu và cung cấp giao diện để tìm kiếm và truy vấn log.
|
||||
- **Fluentd:** Trình thu thập dữ liệu nguồn mở cho layer ghi log hợp nhất. Fluentd cho phép bạn thống nhất việc thu thập và tiêu thụ dữ liệu để sử dụng và hiểu dữ liệu tốt hơn.
|
||||
- **Kibana:** Giao diện quản lý và thống kê log, chịu trách nhiệm đọc thông tin từ Elasticsearch.
|
||||
|
||||
### Triển khai EFK trên Minikube
|
||||
|
||||
Chúng ta sẽ sử dụng Minikube cluster của mình để triển khai EFK stack. Hãy bắt đầu một cluster bằng cách sử dụng `minikube start` trên hệ thống. Tôi đang sử dụng hệ điều hành Windows có WSL2 được bật.
|
||||
|
||||
|
||||
|
||||
Tôi đã tạo [efk-stack.yaml](../../Days/Monitoring/EFK%20Stack/efk-stack.yaml) chứa mọi thứ chúng ta cần để triển khai EFK stack vào cluster. Bằng cách sử dụng lệnh `kubectl create -f efk-stack.yaml`, chúng ta có thể thấy mọi thứ đang được triển khai.
|
||||
|
||||
|
||||
|
||||
Thời gian triển khai trên hệ thống của bạn sẽ tuỳ thuộc vào việc nếu bạn đã chạy hệ thống này hoặc đã pull images, bây giờ bạn nên kiểm tra xem các pods đã ở trạng thái sẵn sàng chưa trước khi chúng ta có thể tiếp tục. Bạn có thể kiểm tra bằng lệnh `kubectl get pod -n kube-logging -w`. Quá trình này có thể mất vài phút.
|
||||
|
||||
|
||||
|
||||
Lệnh trên cho phép chúng ta theo dõi mọi thứ, nhưng tôi muốn chắc chắn mọi thứ đều ổn bằng cách chạy lệnh `kubectl get pod -n kube-logging` để đảm bảo tất cả các pods hiện đã hoạt động.
|
||||
|
||||
|
||||
|
||||
Khi chúng ta đã thiết lập và chạy tất cả các pods, chúng ta sẽ thấy:
|
||||
|
||||
- 3 pods được liên kết với ElasticSearch
|
||||
- 1 pod liên kết với Fluentd
|
||||
- 1 pod liên kết với Kibana
|
||||
|
||||
Chúng ta cũng có thể sử dụng `kubectl get all -n kube-logging` để hiển thị tất cả các thành phần trong namespace của mình. Fluentd (như đã giải thích trước đây) được triển khai dưới dạng daemonset, Kibana dưới dạng deployment và Elasticsearch dưới dạng statefulset.
|
||||
|
||||
|
||||
|
||||
Bây giờ, khi tất cả các pods đã hoạt động, chúng ta có thể thực hiện lệnh chuyển tiếp cổng với một terminal mới để có thể truy cập bảng điều khiển Kibana. Lưu ý rằng tên pod của bạn sẽ khác với những gì trong lệnh được sử dụng ở đây. `kubectl port-forward kibana-84cf7f59c-v2l8v 5601:5601 -n kube-logging`
|
||||
|
||||
|
||||
|
||||
Bây giờ, chúng ta có thể mở trình duyệt và truy cập địa chỉ `http://localhost:5601`, bạn sẽ thấy màn hình như bên dưới hoặc bạn có thể thấy màn hình dữ liệu mẫu. Hãy tiếp tục và tự định cấu hình. Dù có như thế nào, hãy xem xét dữ liệu mẫu, đó là những gì chúng ta đã đề cập khi xem xét ELK stack trong bài viết trước.
|
||||
|
||||
|
||||
|
||||
Tiếp theo, chúng ta cần nhấn vào tab "Discover" trên menu bên trái và thêm "\*" vào mục index pattern. Tiếp tục sang bước tiếp theo bằng cách nhấn "Next step".
|
||||
|
||||
|
||||
|
||||
Ở bước 2/2, chúng ta sẽ sử dụng tùy chọn @timestamp từ dropdown vì tùy chọn này sẽ lọc dữ liệu của chúng ta theo thời gian. Khi bạn nhấn "Create pattern", có thể mất vài giây để hoàn thành.
|
||||
|
||||
|
||||
|
||||
Nếu bây giờ chúng ta quay lại tab "Discover" sau vài giây, bạn sẽ bắt đầu thấy dữ liệu đến từ Kubernetes cluster của mình.
|
||||
|
||||
|
||||
|
||||
Chúng ta đã thiết lập và chạy EFK, cũng như đang thu thập logs từ cụm Kubernetes thông qua Fluentd. Chúng ta cũng có thể xem các nguồn khác mà chúng ta có thể chọn bằng cách điều hướng đến màn hình chính bằng cách nhấn vào biểu tượng Kibana ở trên cùng bên trái, bạn sẽ thấy trang web mà chúng ta đã thấy khi đăng nhập lần đầu.
|
||||
|
||||
Chúng ta có thể thêm APM, log data, metric data và security events từ các plugin hoặc nguồn khác.
|
||||
|
||||
|
||||
|
||||
Nếu chọn "Add log data", chúng ta có thể thấy bên dưới có rất nhiều lựa chọn về nguồn mà chúng ta có thể lấy log. Bạn có thể thấy rằng Logstash được đề cập ở đó là một phần của ELK stack.
|
||||
|
||||
|
||||
|
||||
Trong "Metrics data", bạn sẽ thấy rằng bạn có thể thêm nguồn cho Prometheus và nhiều dịch vụ khác.
|
||||
|
||||
### APM (Giám sát hiệu suất ứng dụng)
|
||||
|
||||
Ngoài ra còn có tùy chọn thu thập APM (Giám sát hiệu suất ứng dụng), thu thấp các số liệu và lỗi từ bên trong ứng dụng của bạn. Nó cho phép bạn theo dõi hiệu suất của hàng ngàn ứng dụng theo thời gian thực.
|
||||
|
||||
Tôi sẽ không nói nhiều về APM trong bài viết này nhưng bạn có thể tìm hiểu thêm tại [Elastic site](https://www.elastic.co/observability/application-performance-monitoring).
|
||||
|
||||
## Tài liệu tham khảo
|
||||
|
||||
- [Understanding Logging: Containers & Microservices](https://www.youtube.com/watch?v=MMVdkzeQ848)
|
||||
- [The Importance of Monitoring in DevOps](https://www.devopsonline.co.uk/the-importance-of-monitoring-in-devops/)
|
||||
- [Understanding Continuous Monitoring in DevOps?](https://medium.com/devopscurry/understanding-continuous-monitoring-in-devops-f6695b004e3b)
|
||||
- [DevOps Monitoring Tools](https://www.youtube.com/watch?v=Zu53QQuYqJ0)
|
||||
- [Top 5 - DevOps Monitoring Tools](https://www.youtube.com/watch?v=4t71iv_9t_4)
|
||||
- [How Prometheus Monitoring works](https://www.youtube.com/watch?v=h4Sl21AKiDg)
|
||||
- [Introduction to Prometheus monitoring](https://www.youtube.com/watch?v=5o37CGlNLr8)
|
||||
- [Promql cheat sheet with examples](https://www.containiq.com/post/promql-cheat-sheet-with-examples)
|
||||
- [Log Management for DevOps | Manage application, server, and cloud logs with Site24x7](https://www.youtube.com/watch?v=J0csO_Shsj0)
|
||||
- [Log Management what DevOps need to know](https://devops.com/log-management-what-devops-teams-need-to-know/)
|
||||
- [What is ELK Stack?](https://www.youtube.com/watch?v=4X0WLg05ASw)
|
||||
- [Fluentd simply explained](https://www.youtube.com/watch?v=5ofsNyHZwWE&t=14s)
|
||||
|
||||
Hẹn gặp lại vào [ngày 83](day83.md)
|
||||
154
2022/vi/Days/day83.md
Normal file
154
2022/vi/Days/day83.md
Normal file
@ -0,0 +1,154 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - Trực quan hóa dữ liệu - Grafana - Ngày 83'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Trực quan hóa dữ liệu - Grafana
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048767
|
||||
---
|
||||
|
||||
## Trực quan hóa dữ liệu - Grafana
|
||||
|
||||
Chúng ta đã thấy nói đến Kibana khá nhiều trong phần liên quan tới khả năng quan sát (Observability). Nhưng chúng ta cũng phải dành chút thời gian để tìm hiểu về Grafana. Chúng là hai thức khác biệt và cũng không hoàn toàn cạnh tranh cụ thể với nhau.
|
||||
|
||||
Tính năng cốt lõi của Kibana là truy vấn và phân tích dữ liệu. Bằng nhiều phương pháp khác nhau, người dùng có thể tìm kiếm dữ liệu được lập chỉ mục trong Elasticsearch cho các các sự kiện hoặc chuỗi cụ thể trong dữ liệu của họ để phân tích, phán đoán nguyên nhân gốc rễ. Dựa trên những truy vấn này, người dùng có thể sử dụng các tính năng trực quan hoá của Kibana, cho phép người dùng trực quan hoá dữ liệu theo nhiều các khách nhau, sử dụng biểu đồ, bảng, bản đồ địa lý và các loại trực quan hoá khác.
|
||||
|
||||
Grafana bắt đầu như một bản fork của Kibana, Grafana có mục đích cung cấp hỗ trợ cho các metrics aka monitoring, điều mà vào thời điểm đó Kibana không cung cấp.
|
||||
|
||||
Grafana là một công cụ trực quan hoá dữ liệu nguồn mở và miễn phí. Chúng ta thường thấy Prometheus và Grafana cùng nhau trong thực tế nhưng cũng có thể thấy nó hoạt động với ElasticSearch và Graphite.
|
||||
|
||||
Sự khác biệt chính giữa hai công cụ là Logging và Monitoring, chúng ta đã bắt đầu tuần này bằng việc giám sát bằng Nagios, sau đó là Prometheus trước khi chuyển sang Logging, nơi chúng ta đề cập tới ELK và EFK stack.
|
||||
|
||||
Grafana phục vụ cho việc phân tích và trực quan hoá các số liệu như CPU hệ thống, bộ nhớ, đĩa và mức sử dụng I/O. Nền tảng không cho phép truy vấn dữ liệu toàn văn (full-text data querying). Kibana chạy trên Elasticsearch và nó được sử dụng chủ yếu cho việc phân tích log message.
|
||||
|
||||
Như chúng ta đã tìm hiểu với Kibana, việc triển khai và lựa chọn nơi triển khai khá dễ dàng, điều này cũng tương tự với Grafana.
|
||||
|
||||
Cả hai đều hỗ trợ cài đặt trên Linux, Mac, Windows, Docker hoặc build từ nguồn.
|
||||
|
||||
Không còn nghi ngờ gì nữa, Grafana là một công cụ và tôi đã gặp trên cả các nền tảng ảo hoá, đám mây và các nền tảng cloud-native, chính vì vậy, tôi muốn đề cập tới nó trong phần này.
|
||||
|
||||
### Prometheus Operator + Grafana Deployment
|
||||
|
||||
Chúng ta đã đề cập tới Prometheus trong phần này nhưng vì muốn đảm bảo tính liên tục, tôi muốn tạo ra một môi trường cho phép chúng ta có thể xem được những metrics một cách trực quan. Chúng ta hiểu được tầm quan trọng của việc giám sát môi trường nhưng việc chỉ đọc các metrics đó trong Prometheus hoặc bất kỳ công cụ quản lý metrics nào sẽ trở nên cồng kềnh và không có tính mở rộng. Đây là lúc Grafana xuất hiện và cung cấp cho chúng ta hình ảnh trực quan có thể tương tác được về các metrics được thu thập và lưu trữ ở Prometheus database.
|
||||
|
||||
Với sự trực quan đó, chúng ta có thể tạo biểu đồ, đồ thị và cảnh báo tuỳ chỉnh cho môi trường của mình. Trong hướng dẫn này, chúng ta sẽ sử dụng minikube cluster của mình.
|
||||
|
||||
Chúng ta sẽ bắt đầu bằng cách sao chép nó vào hệ thống cục bộ của mình. Sử dụng lệnh `git clone https://github.com/prometheus-operator/kube-prometheus.git` và `cd kube-prometheus`
|
||||
|
||||
|
||||
|
||||
Việc đầu tiên là tạo namespace trong minikube cluster `kubectl create -f manifests/setup`. Nếu bạn chưa theo dõi các phần trước, chúng ta có thể sử dụng lệnh `minikube start` để tạo một cluster mới.
|
||||
|
||||
|
||||
|
||||
Tiếp theo, chúng ta sẽ triển khai mọi thứ chúng ta cần cho bản demo bằng lệnh `kubectl create -f manifests/`, bạn có thể thấy lệnh này sẽ triển khai rất nhiều tài nguyên khác trong cluster của chúng ta.
|
||||
|
||||
|
||||
|
||||
Sau đó, chúng ta cần đợi các pods của mình được khởi tạo và ở trạng thái sẵn sàng, chúng ta có thể sử dụng lệnh `kubectl get pods -n monitoring -w` để theo dõi các pods.
|
||||
|
||||
|
||||
|
||||
Khi mọi thứ đang chạy, chúng ta có thể kiểm tra tất cả các pods đang ở trạng thái hoạt động và hoạt động tốt bằng cách sử dụng lệnh `kubectl get pods -n monitoring`.
|
||||
|
||||
|
||||
|
||||
Chúng ta đã triển khai một số dịch vụ sẽ được sử dụng sau này trong demo, có thể kiểm tra bằng lệnh `kubectl get svc -n monitoring`.
|
||||
|
||||
|
||||
|
||||
Cuối cùng, hãy kiểm tra tất cả các tài nguyên được triển khai trong namespace monitoring mới dùng cho bằng câu lệnh `kubectl get all -n monitoring`.
|
||||
|
||||
|
||||
|
||||
Mở một terminal mới, chúng ta hiện đã sẵn sàng cho sử dụng công cụ Grafana của mình và bắt đầu thu thập, trực quan hoá một số metrics, câu lệnh cần sử dụng là `kubectl --namespace monitoring port-forward svc/grafana 3000`
|
||||
|
||||
|
||||
|
||||
Mở trình duyệt và đi tới http://localhost:3000, bạn sẽ cần nhập tên người dùng và mật khẩu.
|
||||
|
||||
|
||||
Tên người dùng và mật khẩu mặc định sẽ là
|
||||
|
||||
```
|
||||
Username: admin
|
||||
Password: admin
|
||||
```
|
||||
|
||||
Tuy nhiên, bạn sẽ được yêu cầu cung cấp mật khẩu mới ở lần đăng nhập đầu tiên. Màn hình hoặc trang chủ mà bạn thấy sẽ có một số phần để khám phá cũng như một số tài nguyên hữu ích để có thể sử dụng Grafana và các chức năng của nó. Hãy lưu ý phần "Add your first data source" và "create your first dashboard" widgets sẽ được sử dụng ở phần sau.
|
||||
|
||||
|
||||
|
||||
Bạn sẽ thấy rằng đã có nguồn dữ liệu Prometheus được thêm vào nguồn dữ liệu Grafana của chúng ta, tuy nhiên, vì chúng ta đang sử dụng minikube nên chúng ta cũng cần chuyển tiếp cổng cho Prometheus để nó có thể truy cập bằng localhost. Mở một terminal mới, chúng ta có thể chạy lệnh sau `kubectl --namespace monitoring port-forward svc/prometheus-k8s 9090` nếu trên trang chủ của Grafana, chúng ta bắt đầu sử dụng widget "Add your first data source" và tại đây, chúng ta chon Prometheus.
|
||||
|
||||
|
||||
|
||||
Đối với nguồn dữ liệu mới, chúng ta có thể sử dụng địa chỉ http://localhost:9090 và chúng ta cũng sẽ cần lựa chọn "Browser" như ảnh bên dưới.
|
||||
|
||||
|
||||
|
||||
Ở cuối trang, chúng ta có thể nhấn "Save & test". Nếu chuyển tiếp cổng của Prometheus hoạt động chính xác, bạn có thể thấy kết quả như dưới đây.
|
||||
|
||||
|
||||
|
||||
Quay lại trang chủ và tìm tuỳ chọn "Create your first dashboard" chọn mục "Add a new panel"
|
||||
|
||||
|
||||
|
||||
Bạn sẽ thấy
|
||||
You will see from below that we are already gathering from our Grafana data source, but we would like to gather metrics from our Prometheus data source, select the data source drop down and select our newly created "Prometheus-1"
|
||||
|
||||
|
||||
|
||||
If you then select the Metrics browser you will have a long list of metrics being gathered from Prometheus related to our minikube cluster.
|
||||
|
||||
|
||||
|
||||
For the demo I am going to find a metric that gives us some output around our system resources, `cluster:node_cpu:ratio{}` gives us some detail on the nodes in our cluster and proves that this integration is working.
|
||||
|
||||
|
||||
|
||||
Once you are happy with this as your visualisation then you can hit the apply button in the top right and you will then add this graph to your dashboard. You can go ahead and add additional graphs and other charts to give you the visuals that you need.
|
||||
|
||||
|
||||
|
||||
We can however take advantage of thousands of previously created dashboards that we can use so that we do not need to reinvent the wheel.
|
||||
|
||||
|
||||
|
||||
If we search Kubernetes we will see a long list of pre-built dashboards that we can choose from.
|
||||
|
||||
|
||||
|
||||
We have chosen the Kubernetes API Server dashboard and changed the data source to suit our newly added Prometheus-1 data source and we get to see some of the metrics displayed below.
|
||||
|
||||
|
||||
|
||||
### Cảnh báo - Alerting
|
||||
|
||||
Bạn cũng có thể tận dùng alertmanager mà chúng ta đã triển khai để gửi cảnh báo tới slack hoặc các tích hợp khác. Để thực hiện việc này, bạn cần port forward alertmanager bằng các sử dụng các thông tin bên dưới.
|
||||
|
||||
`kubectl --namespace monitoring port-forward svc/alertmanager-main 9093`
|
||||
`http://localhost:9093`
|
||||
|
||||
Điều này đã khép lại phần về khả năng quan sát - observability, cá nhân tôi nhận thấy rằng phần này đã nêu bật mức độ rộng của chủ đề này và tầm quan trọng của chúng với vai trò của chúng ta. Metrics, logging hay tracing là thứ chúng ta sẽ cần phải theo dõi và nắm chắc khi môi trường được mở rộng và thay đổi liên tục, đặc biệt là chúng có thể thay đổi đáng kể nhờ tất cả quá trình tự động hoá mà chúng ta đã đề cập trong các phần khác.
|
||||
|
||||
Tiếp theo, chúng ta sẽ xem xét quản lý dữ liệu và cách xem xét các nguyên tắc DevOps khi nói đến quản lý dữ liệu.
|
||||
|
||||
## Tài liệu tham khảo
|
||||
|
||||
- [Understanding Logging: Containers & Microservices](https://www.youtube.com/watch?v=MMVdkzeQ848)
|
||||
- [The Importance of Monitoring in DevOps](https://www.devopsonline.co.uk/the-importance-of-monitoring-in-devops/)
|
||||
- [Understanding Continuous Monitoring in DevOps?](https://medium.com/devopscurry/understanding-continuous-monitoring-in-devops-f6695b004e3b)
|
||||
- [DevOps Monitoring Tools](https://www.youtube.com/watch?v=Zu53QQuYqJ0)
|
||||
- [Top 5 - DevOps Monitoring Tools](https://www.youtube.com/watch?v=4t71iv_9t_4)
|
||||
- [How Prometheus Monitoring works](https://www.youtube.com/watch?v=h4Sl21AKiDg)
|
||||
- [Introduction to Prometheus monitoring](https://www.youtube.com/watch?v=5o37CGlNLr8)
|
||||
- [Promql cheat sheet with examples](https://www.containiq.com/post/promql-cheat-sheet-with-examples)
|
||||
- [Log Management for DevOps | Manage application, server, and cloud logs with Site24x7](https://www.youtube.com/watch?v=J0csO_Shsj0)
|
||||
- [Log Management what DevOps need to know](https://devops.com/log-management-what-devops-teams-need-to-know/)
|
||||
- [What is ELK Stack?](https://www.youtube.com/watch?v=4X0WLg05ASw)
|
||||
- [Fluentd simply explained](https://www.youtube.com/watch?v=5ofsNyHZwWE&t=14s)
|
||||
|
||||
Hẹn gặp lại vào [ngày 84](day84.md)
|
||||
Loading…
Reference in New Issue
Block a user