текст перекладу

Вступ

У еру, коли домінують хмарні додатки, спостережуваність стала основою сучасних програмних систем. Вона виходить за межі традиційного моніторингу, зосереджуючись на розумінні та покращенні продуктивності додатків в реальному часі. Завдання Log Strata Infra Monitor Challenge від STGI дає можливість розробникам долучитися до цієї трансформації, створюючи власну платформу спостережуваності — поєднання творчості, технічного дотепу та вирішення проблем.

Це не просто про програмування; це про створення рішення, яке відповідає на постійно змінювані складнощі хмарної інфраструктури.
текст перекладу
Давайте розглянемо шлях створення платформи спостережуваності з нуля.

Місія

Завдання виглядає deceptively простим, але є глибоким: Створити інструмент моніторингу хмари, який збирає, обробляє і візуалізує журнали та метрики з Kubernetes кластера. Це вимагає поєднання кількох дисциплін — DevOps, бекенд-розробка та UI/UX дизайн.

Основні вимоги

Kubernetes кластер: Розгорнуто локально за допомогою Minikube.
Додатки: Два додатки на базі баз даних PostgreSQL та MySQL.
Збір журналів: Інструменти, як-от Fluent Bit, FluentD або Logstash.
Бекенд-сервіс: Обробка журналів та метрик з їх збереженням у базі даних часових рядів (InfluxDB).
5.
текст перекладу
Користувацька панель: Веб-інтерфейс для візуалізації даних з можливістю пошуку та фільтрації.

Чому це завдання важливе

Сучасні хмарні системи генерують величезну кількість даних, що робить надзвичайно важливим створення систем, які не просто моніторять, а й допомагають зрозуміти ці дані.
текст перекладу
Платформи спостережуваності є очима та вухами організацій, допомагаючи командам:

Виявляти аномалії в реальному часі.
Оптимізувати продуктивність за допомогою практичних інсайтів.
Підвищувати надійність завдяки швидшому виявленню корінних причин.

Завдання від STGI дає учасникам можливість вирішувати ці реальні проблеми в симульованому середовищі, закладаючи основу для створення впливових рішень у системах масштабного виробництва.

Як побудувати свій монітор інфраструктури

Крок 1: Закладання основ

Налаштування Docker, Kubectl і Minikube

Почніть з Docker, будівельного блоку контейнеризованих середовищ, і Minikube, який приносить Kubernetes на вашу локальну машину.
текст перекладу
Разом вони формують основу для вашої платформи.

Встановлення Docker:

Інструкцію з встановлення можна знайти тут:
https://medium.com/@sugam.arora23/docker-unboxed-your-complete-guide-to-installation-on-ubuntu-and-windows-5d367a554afe

Встановлення Kubectl:

Інструкцію з встановлення можна знайти тут:
https://medium.com/@sugam.arora23/effortlessly-install-kubectl-on-ubuntu-and-windows-your-ultimate-guide-to-kubernetes-mastery-14752b338dde

Встановлення Minikube:

Інструкцію з встановлення можна знайти тут:
https://medium.com/@sugam.arora23/minikube-setup-guide-a-seamless-experience-on-windows-and-linux-a37cec913e73

Крок 2: Розгортання додатків

Розгорніть два тестові додатки з бекендами PostgreSQL і MySQL.
текст перекладу
Кожен додаток представляє собою мікросервіс у межах екосистеми. Переконайтеся в правильності підключення до бази даних і перевірте логи додатків після розгортання.

Налаштування розгортання Kubernetes для app-1 та app-2

Передумови

Переконайтеся, що Minikube налаштовано та працює на вашій системі (Windows або Ubuntu).

Крок 1: Клонування тестових додатків

Створіть директорії проектів

mkdir ~/postgresql

mkdir ~/mysql

cd ~/postgresql

cd ~/mysql

2. Клонуйте додатки Замініть і на фактичні URL ваших додатків.

git clone https://github.com/tanishsummit/PyEditorial

git clone https://github.com/manjillama/docker-node-crud-mysql

Крок 2: Створення розгортань та сервісів для Kubernetes

1. Створення розгортання та сервісу для MySQL (app-1)

Створіть YAML файл для розгортання MySQL

touch mysql-deployment.yaml

2.
текст перекладу
Додайте наступний YAML

apiVersion: apps/v1  
kind: Deployment  
metadata:  
 name: mysql  
spec:  
 selector:  
 matchLabels:  
 app: mysql  
 strategy:  
 type: Recreate  
 template:  
 metadata:  
 labels:  
 app: mysql  
 spec:  
 containers:  
 - image: mysql:5.6  
 name: mysql  
 env:  
 - name: MYSQL_ROOT_PASSWORD  
 value: password  
 ports:  
 - containerPort: 3306  
 name: mysql  
---  
apiVersion: v1  
kind: Service  
metadata:  
 name: mysql  
spec:  
 ports:  
 - port: 3306  
 selector:  
 app: mysql

3. Застосуйте YAML файл

kubectl apply -f mysql-deployment.yaml

2. Створення розгортання та сервісу для PostgreSQL (app-2)

Створіть YAML файл для розгортання PostgreSQL

touch postgresql-deployment.yaml

2.
текст перекладу
Додайте наступний YAML

apiVersion: apps/v1  
kind: Deployment  
metadata:  
 name: postgres  
spec:  
 selector:  
 matchLabels:  
 app: postgres  
 strategy:  
 type: Recreate  
 template:  
 metadata:  
 labels:  
 app: postgres  
 spec:  
 containers:  
 - image: postgres:9.6  
 name: postgres  
 env:  
 - name: POSTGRES_PASSWORD  
 value: password  
 ports:  
 - containerPort: 5432  
 name: postgres  
---  
apiVersion: v1  
kind: Service  
metadata:  
 name: postgres  
spec:  
 ports:  
 - port: 5432  
 selector:  
 app: postgres

3. Застосуйте YAML файл

kubectl apply -f postgresql-deployment.yaml

3. Створення розгортань та сервісів для додатків

а. Для App-1 (підключено до MySQL)

Створіть YAML файл для розгортання App-1

touch app-1-deployment.yaml

2.
текст перекладу
Додайте наступний YAML

apiVersion: apps/v1  
kind: Deployment  
metadata:  
 name: app-1  
spec:  
 selector:  
 matchLabels:  
 app: app-1  
 template:  
 metadata:  
 labels:  
 app: app-1  
 spec:  
 containers:  
 - name: app-1  
 image:   
 ports:  
 - containerPort: 8080  
 env:  
 - name: MYSQL_HOST  
 value: mysql  
 - name: MYSQL_USER  
 value: root  
 - name: MYSQL_PASSWORD  
 value: password  
---  
apiVersion: v1  
kind: Service  
metadata:  
 name: app-1  
spec:  
 type: NodePort  
 selector:  
 app: app-1  
 ports:  
 - port: 8080  
 targetPort: 8080  
 nodePort: 30001

3. Застосуйте YAML файл

kubectl apply -f app-1-deployment.yaml

b. Для App-2 (підключено до PostgreSQL)

Створіть YAML файл для розгортання App-2

touch app-2-deployment.yaml

2.
текст перекладу
Додайте наступний YAML

apiVersion: apps/v1  
kind: Deployment  
metadata:  
 name: app-2  
spec:  
 selector:  
 matchLabels:  
 app: app-2  
 template:  
 metadata:  
 labels:  
 app: app-2  
 spec:  
 containers:  
 - name: app-2  
 image:   
 ports:  
 - containerPort: 8081  
 env:  
 - name: POSTGRES_HOST  
 value: postgres  
 - name: POSTGRES_USER  
 value: postgres  
 - name: POSTGRES_PASSWORD  
 value: password  
---  
apiVersion: v1  
kind: Service  
metadata:  
 name: app-2  
spec:  
 type: NodePort  
 selector:  
 app: app-2  
 ports:  
 - port: 8081  
 targetPort: 8081  
 nodePort: 30002

3. Застосуйте YAML файл

kubectl apply -f app-2-deployment.yaml

С 3: Для хакатону Logger

Завантажте Docker-образ (необов'язково)

docker pull tjain598/logger-hackathon:latest

Перевірте наявність образу:

docker images

Створіть YAML файл для розгортання хакатону Logger

touch logger-hackathon-deployment.yaml

4.
текст перекладу
Додайте наступний YAML

apiVersion: apps/v1  
kind: Deployment  
metadata:  
 name: logger-hackathon  
spec:  
 selector:  
 matchLabels:  
 app: logger-hackathon  
 template:  
 metadata:  
 labels:  
 app: logger-hackathon  
 spec:  
 containers:  
 - name: logger-hackathon  
 image: tjain598/logger-hackathon:latest  
 ports:  
 - containerPort: 80  
---  
apiVersion: v1  
kind: Service  
metadata:  
 name: logger-hackathon  
spec:  
 type: NodePort  
 selector:  
 app: logger-hackathon  
 ports:  
 - port: 80  
 targetPort: 80  
 nodePort: 30003

5.
текст перекладу
Застосуйте YAML файл

kubectl apply -f logger-hackathon-deployment.yaml

Крок 4: Доступ до застосунків

Використовуйте наступні команди, щоб отримати доступ до застосунків через Minikube:

minikube service app-1  
minikube service app-2  
minikube service logger-hackathon

Тепер ви повинні мати змогу отримати доступ до app-1, app-2 та застосунку Logger Hackathon на вашому локальному Kubernetes кластері, підключених до їх відповідних сервісів.

Крок 5: Перевірка логів або виводу для Logger App

Перевірити логи Pod

kubectl logs

Замість `` вкажіть фактичну назву pod, яку можна отримати за допомогою:

kubectl get pods

2. Описати Deployment (необов'язково)

kubectl describe deployment logger-app

Увага: Під час деплойменту можуть виникнути численні проблеми, тому важливо розуміти процес усунення неполадок.
текст перекладу
Ви можете ознайомитися з деякими проблемами під час деплойменту, з якими ми зіткнулися, за наступним посиланням:

https://medium.com/@sugam.arora23/revolutionizing-django-deployment-and-debugging-a-practical-guide-for-developers-df16d4dcb099

Крок 3: Майстерність збору логів

Логи — це пульс будь-якої системи, який надає безцінні відомості про її здоров'я та поведінку. Використовуйте Fluent Bit, FluentD або Logstash для збору логів з Kubernetes pod і пересилання їх до вашого бекенд-сервісу. Оскільки у нас був монолітний сервіс, ми вирішили використовувати Fluent Bit, оскільки це найбільш ефективне, ресурсозберігаюче та масштабоване рішення для збору та обробки логів.

Основні компоненти Fluent Bit

1.

Плагіни вводу

Плагіни вводу визначають, звідки Fluent Bit збирає журнали.

Типові джерела: Файли, TCP, Syslog, Tail (файли), Kubernetes та Docker.
Приклад: Для збору журналів контейнерів:

[INPUT] Name tail Path /var/log/containers/*.log Tag kube.*

2. Фільтри

Фільтри перетворюють або доповнюють дані журналів перед їх передачею.

Приклад: Додавання метаданих Kubernetes до журналів.

[FILTER] Name kubernetes Match kube.* Merge_Log On

3. Плагіни виводу

Плагіни виводу визначають, куди відправляються журнали.

Типові напрямки: Elasticsearch, stdout, AWS S3 та Kafka.
Приклад: Надсилання журналів до stdout.

[OUTPUT] Name stdout Match *

Розгортання Fluent Bit в Kubernetes

Для ефективного збору журналів у кластері Kubernetes, Fluent Bit зазвичай розгортається як DaemonSet, що забезпечує запуск агента журналювання на кожному вузлі. Ось детальний опис необхідної конфігурації.

1. ConfigMap

ConfigMap зберігає конфігурацію Fluent Bit.
Нижче наведено приклад конфігурації для збору журналів контейнерів, системних журналів і доповнення журналів метаданими Kubernetes:

apiVersion: v1  
kind: ConfigMap  
metadata:  
 name: fluent-bit-config  
 namespace: default  
 labels:  
 app: fluent-bit  
data:  
 fluent-bit.conf: |  
 [SERVICE]  
 Flush 1  
 Log_Level info  
 Daemon off  
 Parsers_File parsers.conf  

 [INPUT]  
 Name tail  
 Path /var/log/pods/*/*/*.log  
 Exclude_Path /var/log/pods/*/*fluent-bit*.log, /var/log/pods/*/*coredns*.log, /var/log/pods/*/*kube-controller-manager*.log, /var/log/pods/*/*storage-provisioner*.log, /var/log/pods/*/*kube-scheduler*.log, /var/log/pods/*/*kube-proxy*.log, /var/log/pods/*/*kube-apiserver*.log, /var/log/pods/*/*etcd*.log   
 Parser docker  
 Tag kube.*  
 Refresh_Interval 5  
 Mem_Buf_Limit 5MB  
 Skip_Long_Lines On  
 DB /var/log/flb_kube.db  

 [FILTER]  
 Name kubernetes  
 Match kube.*  
 Merge_Log On  
 Keep_Log On  
 K8S-Logging.Parser On  
 K8S-Logging.Exclude On  

 [FILTER]  
 Name geoip  
 Match kube.*  
 Key ip_address   
 Add_Field true   
 Include city_name,country_code  

 [FILTER]  
 Name record_transformer  
 Match kube.*  
 Record new_time ${time}  
 Time_Format "%Y-%m-%d %H:%M:%S"  

 [FILTER]  
 Name grep  
 Match kube.*  
 Regex log "ERROR|WARN|INFO"  

 [FILTER]  
 Name lua  
 Match kube.*  
 script extract_fields.lua   
 call extract_fields  

 [FILTER]  
 Name grep  
 Match kube.*  
 Regex kubernetes.pod_name nginx.*  

 [FILTER]  
 Name grep  
 Match kube.*  
 Regex kubernetes.namespace_name production.*  

 [FILTER]  
 Name grep  
 Match kube.*  
 Regex kubernetes.labels.app webapp.*  

 [OUTPUT]  
 Name influxdb  
 Match *  
 Host influxdb  
 Port 8086  
 bucket SegFault  
 org STGI  
 sequence_tag _seq  
 http_token 7ETF8X3ZThuQrarZxNeHIsa4QmqjEjmgjJzDQY9PnqegvnM884YbpzDOUolunsn29LxX8FRW1sQPb822-25KrA==  

 parsers.conf: |  
 [PARSER]  
 Name docker  
 Format json  
 Time_Key time  
 Time_Format %Y-%m-%dT%H:%M:%S.%L  
 Time_Keep On  

 extract_fields.lua: |  
 function extract_fields(tag, timestamp, record)  
 -- Користувацька логіка для витягування додаткових полів з журналу  
 return 1, timestamp, record  
 end  

 -- Розрахунок використання CPU у відсотках  
 if total_time > 0 then  
 cpu_utilization = (active_time / total_time) * 100  
 else  
 cpu_utilization = 0  
 end  

 -- Додавання використання CPU до запису журналу  
 record["cpu_utilization"] = cpu_utilization  
 return 1, timestamp, record  
 end

2.

DaemonSet

DaemonSet забезпечує запуск Fluent Bit на всіх вузлах у кластері.

apiVersion: apps/v1  
kind: DaemonSet  
metadata:  
 name: fluent-bit  
 namespace: default  
 labels:  
 app: fluent-bit  
spec:  
 selector:  
 matchLabels:  
 name: fluent-bit  
 template:  
 metadata:  
 labels:  
 name: fluent-bit  
 spec:  
 serviceAccountName: fluent-bit  
 containers:  
 - name: fluent-bit  
 image: fluent/fluent-bit:latest  
 volumeMounts:  
 - name: varlog  
 mountPath: /var/log  
 - name: varlibdockercontainers  
 mountPath: /var/lib/docker/containers  
 readOnly: true  
 - name: config-volume  
 mountPath: /fluent-bit/etc/  
 terminationGracePeriodSeconds: 30  
 volumes:  
 - name: varlog  
 hostPath:  
 path: /var/log  
 - name: varlibdockercontainers  
 hostPath:  
 path: /var/lib/docker/containers  
 - name: config-volume  
 configMap:  
 name: fluent-bit-config

**3.

RBAC

RBAC (Role-Based Access Control) в Fluent Bit використовується для надання необхідних дозволів, щоб Fluent Bit міг безпечно отримувати доступ до ресурсів Kubernetes.
Fluent Bit використовує ці дозволи для доповнення даних журналів метаданими з Kubernetes, такими як імена подів, простори імен, мітки та анотації.

apiVersion: v1  
kind: ServiceAccount  
metadata:  
 name: fluent-bit  
 namespace: default  

---  
apiVersion: rbac.authorization.k8s.io/v1  
kind: ClusterRole  
metadata:  
 name: fluent-bit-read  
rules:  
- apiGroups: [""]  
 resources:  
 - namespaces  
 - pods  
 verbs:  
 - get  
 - list  
 - watch  

---  
apiVersion: rbac.authorization.k8s.io/v1  
kind: ClusterRoleBinding  
metadata:  
 name: fluent-bit-read  
roleRef:  
 apiGroup: rbac.authorization.k8s.io  
 kind: ClusterRole  
 name: fluent-bit-read  
subjects:  
- kind: ServiceAccount  
 name: fluent-bit  
 namespace: kube-logging

Доступ до журналів

Fluent Bit використовує наступні шляхи для доступу до журналів у середовищі Kubernetes:

Журнали контейнерів: /var/log/containers/*.log
Журнали Docker: /var/lib/docker/containers/*/*.log
Системні журнали: /var/log/*.log

Приклад конфігурації:

[INPUT]  
 Name tail  
 Path /var/log/containers/*.log  
 Tag kube.containers.*

Складніші варіанти використання

1.

Пер forwarding журналів до Elasticsearch

Для пересилання журналів до Elasticsearch:

[OUTPUT]  
 Name es  
 Match *  
 Host elasticsearch-host  
 Port 9200  
 Index fluent-bit

2. Використання кастомних парсерів

Fluent Bit підтримує парсери для власних форматів журналів. Приклад парсера для JSON журналів:

[PARSER]  
 Name json  
 Format json

3.

Безпека

Використовуйте ролі RBAC (Role-Based Access Control) для обмеження доступу до ресурсів Kubernetes.
Монтуючи чутливі директорії, надавайте їм доступ лише для читання.

Кращі практики

Вказуйте версії: Уникайте використання latest в Docker образах; використовуйте конкретну версію.
Використовуйте окремий простір імен: Розгорніть Fluent Bit в окремому просторі імен, наприклад, kube-logging.
Моніторинг продуктивності: Регулярно перевіряйте використання ресурсів і оптимізуйте конфігурації для високої пропускної здатності.
Тестування конфігурацій: Тестуйте Fluent Bit в середовищі для стажування перед розгортанням у продакшн.

Крок 4: Побудова мозку — Backend

У задачі було зазначено використання бази даних часових рядів, і немає кращого варіанту, ніж InfluxDB для backend (заднього плану) Fluent Bit. Вона служить базою даних часових рядів для зберігання даних журналів, метрик чи іншої телеметрії, зібраної Fluent Bit.
Налаштування Fluent Bit для використання InfluxDB включає забезпечення правильної конфігурації, безперебійної інтеграції та дотримання кращих практик для ефективного зберігання та запиту даних журналів. InfluxDB — це потужна база даних часових рядів для зберігання журналів та метрик. Причина використання InfluxDB полягає в її здатності обробляти дані з високою швидкістю, такі як журнали та метрики, при цьому полегшуючи їх запит і аналіз.

1. Розуміння InfluxDB

InfluxDB — це база даних часових рядів високої продуктивності, призначена для зберігання та запиту даних з мітками часу. Fluent Bit може передавати дані журналів та метрик до InfluxDB, які потім можна використовувати для аналізу, візуалізації або подальшої обробки.

Ключові особливості:

Зберігає дані у вигляді точок часових рядів з відповідними полями та тегами.
Оптимізовано для високих швидкостей вводу даних.
Інтегрується з інструментами візуалізації, такими як Grafana.

2.

Налаштування InfluxDB для Fluent Bit

Крок 1: Встановлення InfluxDB

Встановлення через Docker:

docker run -d --name influxdb -p 8086:8086 influxdb:2.0

Встановлення з бінарних файлів: Завантажте та встановіть InfluxDB з офіційної сторінки завантажень.

Крок 2: Створення бази даних і токену

InfluxDB v1.x: Створіть базу даних для журналів Fluent Bit:

influx > CREATE DATABASE fluentbit_logs

InfluxDB v2.x:
- Створіть bucket (контейнер) за допомогою UI або CLI InfluxDB:

influx bucket create -n fluentbit_logs -o your-org

3.

Налаштування Fluent Bit для використання InfluxDB

Для відправки даних в InfluxDB, Fluent Bit використовує плагін виведення InfluxDB (InfluxDB output plugin).

Крок 1: Додайте плагін виведення InfluxDB

Оновіть конфігураційний файл Fluent Bit (fluent-bit.conf):

[OUTPUT]  
 Name influxdb  
 Match *  
 Host   
 Port   
 Database fluentbit_logs  
 Org your-org # Для InfluxDB v2.x  
 Bucket fluentbit_logs # Для InfluxDB v2.x  
 Token  # Для InfluxDB v2.x  
 Sequence_Tag sequence_id # Необов'язково, використовується для порядку серій  
 TLS On # Увімкнути TLS для безпечних з'єднань  
 Verify Off # Пропустити перевірку TLS сертифікатів  
 Time_Precision ms # Використовувати мілісекундну точність для міток часу

Замініть Host, Port та Token на ваші деталі InfluxDB.

Крок 2: Налаштуйте плагін вводу

Переконайтесь, що у вас є плагін вводу для збору журналів або метрик.
Наприклад, якщо ви збираєте журнали з Kubernetes:

[INPUT]  
 Name tail  
 Path /var/log/containers/*.log  
 Tag kube.*  
 DB /var/log/fluentbit.db  
 Mem_Buf_Limit 5MB

4. Зберігання та запити до даних в InfluxDB

InfluxDB організовує дані за допомогою:

Вимірювання (Measurements): Таблиці в контексті реляційної бази даних.
Теги (Tags): Індексується метадані для ефективного запиту.
Поля (Fields): Справжні точки даних (не індексуються).
Мітки часу (Timestamps): Кожен запис має містити час.

5.

Найкращі практики

Оптимізація виведення Fluent Bit

Використовуйте Tag в Fluent Bit для організації журналів за простором імен, подом або іншими атрибутами.
Використовуйте стиснення для зменшення розміру журналів, які надсилаються в InfluxDB.

Поради щодо продуктивності InfluxDB

Обмежте кількість полів на одне вимірювання, щоб уникнути зниження продуктивності.
Використовуйте теги (Tags) для часто запитуваних даних.
Агрегуйте дані перед запитами або візуалізацією, щоб зменшити навантаження.

Інтеграція з інструментами візуалізації

Візуалізуйте дані InfluxDB за допомогою таких інструментів, як Grafana:

Додайте InfluxDB як джерело даних у Grafana.
Створіть інформаційні панелі для відображення журналів і метрик за допомогою графіків та таблиць.

Забезпечення безпеки інтеграції

Використовуйте API токени для автентифікації в InfluxDB v2.x.
Увімкніть TLS для безпечної передачі даних між Fluent Bit та InfluxDB.

6. Приклад кінцевого робочого процесу

Збір журналів: Fluent Bit збирає журнали з подів Kubernetes.
Збагачення журналів: Додається метадані з Kubernetes (наприклад, простір імен, мітки подів).
3.
Відправка в InfluxDB: Журнали надсилаються в InfluxDB з тегами для ефективного запиту.
Зберігання та запитування: Журнали зберігаються в InfluxDB і запитуються для налагодження чи моніторингу.
Візуалізація: Використовуйте Grafana для візуалізації журналів для отримання інсайтів.

7. Поради з усунення неполадок

Проблеми з підключенням:

Переконайтесь, що параметри Host та Port у Fluent Bit відповідають налаштуванням InfluxDB.

Перевірте мережевий доступ між Fluent Bit та InfluxDB.

Дані не відображаються:

Перевірте, чи співпадає директива Match у Fluent Bit з тегами вводу.

Перевірте журнали Fluent Bit на наявність помилок.

Високе навантаження на InfluxDB:

Використовуйте пакетування в Fluent Bit для зменшення кількості операцій запису:

Batch_Size 500 Flush_Interval 5

Для бекенду ми використовували Spring Boot. Spring Boot використовує SLF4J з Logback як стандартну систему логування. За замовчуванням, журнали записуються в консоль, але ви можете налаштувати Spring Boot для запису журналів у файли або на віддалені системи.
Fluent Bit може збирати журнали з цих файлів або зі стандартного виведення (stdout) та відправляти їх на бекенд, такий як InfluxDB, Elasticsearch або систему керування журналами.

Крок 5: Створення візуального інтерфейсу

Ваша панель інструментів — це місце, де відбувається магія, місце, де сирі дані перетворюються на корисні інсайти. Ми створили власну веб-панель на основі ReactJS. Інтерфейс повинен дозволяти користувачам:

Шукати журнали за ключовими словами або фільтрами часу.
Візуалізувати дані через графіки, діаграми та таблиці.
Відслідковувати тренди з відображенням показників в реальному часі.

Основні принципи дизайну:

Зберігати мінімалізм, але при цьому інформативність.
Забезпечити адаптивність для користувачів на мобільних пристроях і настільних комп'ютерах.
Пріоритетність інтерактивності з динамічними фільтрами та віджетами.
Ключові метрики, візуалізовані на панелі інструментів

1.1 Рівень помилок

Мета: Моніторинг рівня помилок дозволяє відстежувати кількість помилок, що виникають за визначений період, таких як HTTP відповіді 5xx, помилки додатків або невдалі запити.

Візуалізація:

Лінійний графік: Для відстеження рівня помилок з часом.
Стовпчиковий графік: Для порівняння рівня помилок по кожному кінцевому пункту або сервісу.
Теплова карта помилок: Для показу періодів високої кількості помилок, що підкреслює потенційні проблеми.

Джерела даних:

Журнали або метрики з бекенду, можливо інтегровані через Fluent Bit або інструмент для ведення журналів, наприклад, Sentry.
Метрики з API відповідей (коди статусу).

1.2 Продуктивність запитів до бази даних

Мета: Метрики продуктивності бази даних є важливими для розуміння того, як ефективно виконуються запити, час виконання та можливі вузькі місця.

Візуалізація:

Стовпчиковий графік або лінійний графік: Для відображення середнього часу виконання запитів за часом.
Кругова діаграма: Для візуалізації розподілу запитів за типом (SELECT, INSERT, UPDATE, DELETE).
Теплова карта: Для показу періодів пікових навантажень на базу даних.

Джерела даних:

Зібрані з бекенду через журнали бази даних або інструменти для оцінки продуктивності запитів, такі як New Relic або Prometheus.
Інструменти моніторингу бази даних можуть надавати ці дані через API.

1.3 Трафік і використання ресурсів

Мета: Моніторинг трафіку і використання ресурсів допомагає відстежувати, яку навантаження обробляє додаток і як ефективно використовуються ресурси (CPU, пам'ять, пропускна здатність).

Візуалізація:

Лінійні графіки: Для відображення трафіку в реальному часі та використання ресурсів (CPU, пам'ять, пропускна здатність).
Індикаторні графіки: Для індикації використання ресурсів в реальному часі, таких як навантаження на CPU або споживання пам'яті.
Площинний графік: Для показу кореляції між піковим трафіком і споживанням ресурсів.

Джерела даних:

Prometheus, Grafana або AWS CloudWatch можуть використовуватися для моніторингу інфраструктури в реальному часі.
Журнали веб-серверів (nginx, apache) та інструменти моніторингу продуктивності.
Будування панелі інструментів в ReactJS

Щоб побудувати складну та зручну панель інструментів в ReactJS, потрібно розбити її на компоненти, які відповідатимуть за рендеринг різних візуалізацій.
Ось як можна організувати структуру:

2.1 Структура проєкту

/src  
 /components  
 /Dashboard  
 Dashboard.js  
 /ErrorRateChart  
 ErrorRateChart.js  
 /DbPerformanceChart  
 DbPerformanceChart.js  
 /TrafficUsageChart  
 TrafficUsageChart.js  
 /services  
 metricsService.js // Обробляє API виклики для отримання даних  
 /utils  
 chartUtils.js // Містить утилітні функції для обробки даних та форматування графіків  
 /App.js  
 /index.js

2.2 Приклад коду для панелі інструментів (ReactJS)

Ось спрощений приклад того, як може виглядати структура панелі інструментів:

Dashboard.js

import React, { useState, useEffect } from 'react';  
import ErrorRateChart from './ErrorRateChart';  
import DbPerformanceChart from './DbPerformanceChart';  
import TrafficUsageChart from './TrafficUsageChart';  
import { getMetrics } from '../../services/metricsService';

const Dashboard = () => {  
 const [metricsData, setMetricsData] = useState({  
 errorRates: [],  
 dbPerformance: [],  
 trafficUsage: [],  
 }); useEffect(() => {  
 const fetchData = async () => {  
 const data = await getMetrics();  
 setMetricsData(data);  
 };  
 fetchData();  
 }, []); return (  

Панель інструментів з показниками проєкту
    );   };export default Dashboard; ```  

## 2.3 Приклад компонента графіка (ErrorRateChart.js)

import React from 'react';
import { Line } from 'react-chartjs-2';
```

const ErrorRateChart = ({ data }) => {  
    const chartData = {  
    labels: data.map(item => item.timestamp), // наприклад, часові інтервали  
    datasets: [  
    {  
    label: 'Кількість помилок',  
    data: data.map(item => item.errorCount), // Кількість помилок на кожному етапі  
    fill: false,  
    borderColor: 'rgba(255, 99, 132, 1)',  
    tension: 0.1,  
    },  
    ],  
    }; return (    
Кількість помилок  
    );  
};export default ErrorRateChart; ```  

## 2.4 Приклад сервісу для метрик (metricsService.js)

import axios from 'axios';
```

export const getMetrics = async () => {  
    try {  
    const response = await axios.get('http:///api/metrics');  
    return response.data;  
    } catch (error) {  
    console.error('Помилка при отриманні метрик:', error);  
    return {  
    errorRates: [],  
    dbPerformance: [],  
    trafficUsage: [],  
    };  
    }  
};

3.

Бібліотеки для візуалізації метрик на фронтенді

Ви можете використовувати бібліотеки для побудови графіків в ReactJS для візуалізації метрик, такі як:

Chart.js (використовувалась у наведеному прикладі)

Пропонує гнучкі та красиві візуалізації, такі як стовпчасті, лінійні та кругові графіки.

Recharts:

Бібліотека для побудови графіків, специфічна для React, з фокусом на простоту та адаптивність.

Victory:

Інша бібліотека для побудови інтерактивних візуалізацій, специфічна для React.

D3.js:

Для складних і кастомізованих візуалізацій, але може вимагати більше налаштувань та розуміння SVG.

Приклад використання Chart.js для лінійного графіка (для помилок або трафіку)

npm install react-chartjs-2 chart.js

У вашому компоненті React ви можете імпортувати react-chartjs-2 і використовувати його компонент графіка Line, як це продемонстровано в прикладі ErrorRateChart.js.

4. API на бекенді для метрик

Ваш API на бекенді (наприклад, побудований за допомогою Spring Boot) має надавати ендпоінти, які забезпечують необхідні дані для метрик.
Ось приклад контролера Spring Boot:

MetricsController.java

@RestController  
@RequestMapping("/api/metrics")  
public class MetricsController {

@Autowired  
 private MetricsService metricsService; @GetMapping  
 public ResponseEntity> getMetrics() {  
 Map metricsData = metricsService.getMetricsData();  
 return ResponseEntity.ok(metricsData);  
 }  
}

MetricsService.java

@Service  
public class MetricsService {

public Map getMetricsData() {  
 Map metricsData = new HashMap<>();  
 metricsData.put("errorRates", getErrorRates());  
 metricsData.put("dbPerformance", getDbPerformance());  
 metricsData.put("trafficUsage", getTrafficUsage());  
 return metricsData;  
 } private List getErrorRates() {  
 // Логіка для отримання даних про помилки з логів чи бази даних  
 } private List getDbPerformance() {  
 // Логіка для отримання метрик продуктивності бази даних  
 } private List getTrafficUsage() {  
 // Логіка для отримання даних про трафік/використання ресурсів  
 }  
}

Ці дані можна отримувати з бази даних, логів або інструментів моніторингу, таких як Prometheus або Grafana, і серіалізувати в формат JSON для надсилання на фронтенд.
Розгортання та врахування масштабованості

Дані в реальному часі: Якщо вам потрібно оновлення даних на панелі в реальному часі, розгляньте використання WebSocket для надсилання оновлень на фронтенд React або Server-Sent Events (SSE).
Кешування даних: Використовуйте механізми кешування (наприклад, Redis), щоб уникнути повторного отримання великих наборів даних.
Масштабованість: Переконайтесь, що ваші API на бекенді оптимізовані для обробки великої кількості трафіку, та використовуйте балансування навантаження за потреби.

Крок 6: Перехід до розширених можливостей

1. Інтеграція логів ресурсів AWS

Мета: Логи ресурсів AWS надають дані в реальному часі про стан і продуктивність вашої хмарної інфраструктури.
Інтеграція логів ресурсів AWS

Інтегруючи логи та метрики AWS CloudWatch, ви зможете збагачити вашу платформу важливими хмарними даними.

Кроки для інтеграції логів ресурсів AWS:

Налаштування AWS CloudWatch:

Увімкніть CloudWatch Logs для ваших AWS сервісів (EC2, Lambda, S3 тощо), щоб збирати логи та метрики.
Налаштуйте CloudWatch Alarms, щоб отримувати сповіщення про будь-які аномалії чи помилки в логах.

Отримання логів CloudWatch:

Використовуйте AWS SDK для Java (або відповідний SDK для вашого бекенду), щоб отримати логи CloudWatch.
Приклад виклику API для отримання логів:

import com.amazonaws.services.logs.AWSLogs;  
import com.amazonaws.services.logs.AWSLogsClientBuilder;  
import com.amazonaws.services.logs.model.*;  

public List fetchLogs(String logGroupName) {  
 AWSLogs client = AWSLogsClientBuilder.defaultClient();  
 FilterLogEventsRequest request = new FilterLogEventsRequest()  
 .withLogGroupName(logGroupName)  
 .withLimit(50);  
 FilterLogEventsResult result = client.filterLogEvents(request);  
 return result.getEvents();  
}

Відображення логів на панелі:

На фронтенді створіть компоненти для відображення логів в реальному часі.
Наприклад, використовуючи React та бібліотеку, як-от React Table, для відображення записів логів.

Приклад компонента для відображення логів:

import React, { useState, useEffect } from 'react';  
import { Table } from 'react-table';  
import { fetchCloudWatchLogs } from './services/awsLogsService';  

const AwsLogsDashboard = () => {  
 const [logs, setLogs] = useState([]);  

 useEffect(() => {  
 const fetchLogs = async () => {  
 const data = await fetchCloudWatchLogs();  
 setLogs(data);  
 };  
 fetchLogs();  
 }, []);  

 const columns = [  
 { Header: 'Часова мітка', accessor: 'timestamp' },  
 { Header: 'Повідомлення лога', accessor: 'message' },  
 // Додайте більше колонок за необхідності  
 ];  

 return (  

Логи ресурсів AWS
        );   };      export default AwsLogsDashboard; ```  ## 2.
Система сповіщень

**Мета**: Сповіщення інформують користувачів про критичні події (такі як помилки, погіршення продуктивності чи досягнення лімітів ресурсів) у реальному часі.

## Кроки для реалізації системи сповіщень:

**Backend**:

- Інтегруйте **AWS CloudWatch Alarms** для налаштування порогових значень для ваших ресурсів (наприклад, високе використання CPU, низька пам'ять, помилки в логах).
- Тригеріть ці сповіщення для сповіщення вашого бекенду, який потім може передавати інформацію на фронтенд.

**Налаштування сповіщення CloudWatch Alarm**:

import com.amazonaws.services.cloudwatch.AmazonCloudWatch;
import com.amazonaws.services.cloudwatch.AmazonCloudWatchClientBuilder;
import com.amazonaws.services.cloudwatch.model.*;

public void createAlarm() {
AmazonCloudWatch cloudWatch = AmazonCloudWatchClientBuilder.defaultClient();

PutMetricAlarmRequest alarmRequest = new PutMetricAlarmRequest()
.withAlarmName("HighCPUUsage")
.withComparisonOperator(ComparisonOperator.GreaterThanThreshold)
.withEvaluationPeriods(1)
.withMetricName("CPUUtilization")
.withNamespace("AWS/EC2")
.withPeriod(60)
.withStatistic(Statistic.Average)
.withThreshold(80.0)
.withActionsEnabled(true)
.withAlarmActions("arn:aws:sns:region:account-id:my-topic");

cloudWatch.putMetricAlarm(alarmRequest);
}
```

Frontend (React):

Налаштуйте з'єднання через WebSocket або Server-Sent Events (SSE) для отримання сповіщень у реальному часі.
Відображайте сповіщення в UI, коли відбувається критична подія (наприклад, високе використання CPU або сплеск помилок).
Приклад коду для сповіщення:

import React, { useState, useEffect } from 'react';  

const AlertComponent = () => {  
 const [alerts, setAlerts] = useState([]);  

 useEffect(() => {  
 const eventSource = new EventSource('http:///api/alerts');  

 eventSource.onmessage = (event) => {  
 const newAlert = JSON.parse(event.data);  
 setAlerts((prevAlerts) => [...prevAlerts, newAlert]);  
 };  

 return () => {  
 eventSource.close();  
 };  
 }, []);  

 return (  

Системні сповіщення
    {alerts.length > 0 ? (    
    {alerts.map((alert, index) => (    
    {alert.message}    
    ))}    
    ) : (    
Немає сповіщень на даний момент
    )}    
    );   };      export default AlertComponent; ```  ## 3.
Прогнозний аналіз з використанням машинного навчання

**Мета**: Прогнозний аналіз допомагає передбачати продуктивність системи, використання ресурсів та можливі збої, що дозволяє вживати проактивних заходів до виникнення проблем.

## Кроки для реалізації прогнозного аналізу:

**Збір даних**:

- Збирайте історичні метрики, такі як використання CPU, рівень помилок, обсяг трафіку тощо, протягом значного періоду.
- Зберігайте ці дані в базі даних або в базі даних для часового ряду, наприклад, **InfluxDB**.

**Навчання моделі машинного навчання**:

- Використовуйте фреймворк машинного навчання, такий як **TensorFlow**, **Scikit-learn** або **PyTorch**, для створення моделей, які можуть прогнозувати метрики.
- Приклад: **Лінійна регресія** або **Прогнозування за допомогою часових рядів** (наприклад, **ARIMA** або **LSTM** для послідовних даних).
- **Приклад на Python (за допомогою Scikit-learn)**:

from sklearn.linear_model import LinearRegression
import numpy as np

Приклад навчання простої моделі для прогнозування використання CPU

data = np.array([[1, 50], [2, 55], [3, 60], [4, 65]]) # [година, використання CPU]
X = data[:, 0].reshape(-1, 1) # Година
y = data[:, 1] # Використання CPU

model = LinearRegression()
model.fit(X, y)

Прогнозування використання CPU на годину 5

prediction = model.predict([[5]])
print(f"Прогнозоване використання CPU на годину 5: {prediction}")
```

Інтеграція з Backend:

Експонуйте модель машинного навчання через API-ендпоінт.
Використовуйте Flask або FastAPI на Python для обслуговування прогнозів моделі.
Приклад FastAPI-ендпоінту для прогнозів:

from fastapi import FastAPI  
from pydantic import BaseModel  

app = FastAPI()  

class PredictionRequest(BaseModel):  
 hour: int  

@app.post("/predict")  
def predict(request: PredictionRequest):  
 prediction = model.predict([[request.hour]])  
 return {"predicted_cpu_usage": prediction[0]}

Інтеграція з Frontend:

На фронтенді на React запитуйте прогнози від бекенду та візуалізуйте прогнозовані дані.
Приклад запиту та відображення прогнозів:

import React, { useState } from 'react';  

const PredictiveDashboard = () => {  
 const [prediction, setPrediction] = useState(null);  

 const fetchPrediction = async (hour) => {  
 const response = await fetch('http:///predict', {  
 method: 'POST',  
 headers: {  
 'Content-Type': 'application/json',  
 },  
 body: JSON.stringify({ hour }),  
 });  
 const data = await response.json();  
 setPrediction(data.predicted_cpu_usage);  
 };  

 return (  

Прогнозний аналіз продуктивності
 fetchPrediction(5)}>Прогноз для години 5    {prediction && 
Прогнозоване використання CPU: {prediction}%
}    
    );   };      export default PredictiveDashboard; ```  ##  The Impact of Innovation  
![pic](https://drive.javascript.org.ua/d762787ab01_ClKOfSAzz8ocbHv1ke2IeQ_png)  
В основі кожного успішного хакатону лежить прагнення до інновацій, і досвід нашої команди в проектуванні сучасної платформи спостереження є яскравим прикладом цього.
Добре продумане рішення для спостережуваності — це не просто технічне вирішення проблеми, а й потужний множник ефективності, що допомагає командам ефективно управляти складними системами. Під час хакатону ми прийняли виклик побудови цієї інноваційної платформи, і впродовж цього процесу ми не лише розширили межі технологій, а й покращили наші навички та здатність вирішувати проблеми. Ось більш детальний погляд на вплив цієї інновації на нас як учасників:

## Практичний досвід з Kubernetes, управління логами та full-stack розробкою

Під час хакатону ми заглибились у світ Kubernetes, управління логами та full-stack розробки, кожен з яких відіграв ключову роль у успіху нашої платформи для спостереження. Kubernetes, потужний інструмент для оркестрації контейнерів, дозволив нам оптимізувати процеси розгортання та масштабування нашої системи.
Ми навчилися використовувати можливості Kubernetes, щоб забезпечити ефективність та стійкість нашої платформи, що було критично важливо для роботи в складних середовищах, які ми планували моніторити.

Управління логами було ще одним критичним аспектом нашого рішення. Ми вирішували задачу збору, зберігання та аналізу логів в реальному часі, щоб швидко виявляти та вирішувати проблеми в системі. Цей аспект проєкту не лише покращив наші технічні навички, але й змусив нас зрозуміти важливість чіткої, структурованої реєстрації подій у виробничих середовищах, особливо коли йдеться про великомасштабні застосунки.

Крім того, ми займалися як frontend, так і backend розробкою, гарантуючи, що наша платформа для спостереження була не тільки функціональною, але й зручною для користувача. Ми здобули безцінний досвід у створенні інтуїтивно зрозумілих інтерфейсів, що дозволяють командам візуалізувати логи, моніторити метрики та ефективно відслідковувати транзакції.
Цей підхід full-stack допоміг нам зрозуміти повний процес створення надійних систем, підготувавши нас до майбутніх викликів у веб-розробці та розробці програмного забезпечення.

## Навички вирішення проблем для подолання реальних викликів

Сама середа хакатону створила швидко змінюване та високо напружене середовище, яке ставило наші навички вирішення проблем на межу. Ми зіткнулися з кількома викликами рівня production, що перевіряли нашу креативність, адаптивність та винахідливість. Від налагодження складних проблем до оптимізації продуктивності системи в умовах обмежених термінів — ми навчилися думати на ходу та знаходити рішення, які не лише відповідали, але й перевершували очікування від цього завдання.
Ці навички вирішення проблем тепер стали основною частиною нашого інструментарію, що дозволяє нам підходити до будь-яких майбутніх проєктів з почуттям впевненості та здатності.

Робота в умовах хакатону також змусила нас усвідомити важливість управління часом та пріоритетизації завдань, що дозволило нам зосередитись на найважливіших аспектах платформи, водночас доставивши високоякісне рішення в межах заданого часу.

## Проєкт для портфоліо, що демонструє глибину та ширину знань

До кінця хакатону ми отримали повністю завершену платформу для спостереження, яка не лише продемонструвала наші технічні навички, але й стала свідченням нашої здатності до інновацій та вирішення реальних проблем.
Цей проєкт став значущим доповненням до наших портфоліо, підкреслюючи як наше глибоке розуміння інструментів та технологій для спостереження, так і нашу здатність інтегрувати їх у єдину, функціональну систему.

Цей проєкт для портфоліо — більше ніж просто задача. Це відображення нашого розвитку як розробників, вирішувачів проблем та інноваторів. Він демонструє нашу здатність працювати в команді, братися за складні завдання та створювати робоче рішення, яке відповідає реальним потребам.

## Висновок: Стимулювання майбутніх інноваторів

![pic](https://drive.javascript.org.ua/c7b5f50fa01_fErC5VgbweutE6hTmOajuA_png)

Задача Log Strata Infra Monitor — це набагато більше, ніж просто хакатон. Це можливість переосмислити спостереження за системами на своїх умовах. Протягом цього шляху ми не лише зосереджувалися на вирішенні технічних проблем, але й працювали над формуванням майбутнього моніторингу в хмарі.
Збираючи, обробляючи та візуалізуючи дані новаторськими способами, ми змогли створити платформу, яка перетворює сирі дані на дієві висновки.

Цей хакатон став неймовірною можливістю для нас розширити межі того, що можливо в сфері спостереження. Справа не лише в опануванні інструментів і технологій; важливо розкрити творчий потенціал, досліджувати нові підходи та робити внесок у еволюцію хмарних систем. Ми не просто учасники виклику — ми активні творці наступного покоління платформ для спостереження.

Отже, підсумовуючи цей досвід, ми натхнені продовжувати працювати і рухатися вперед.
Робота, яку ми виконали тут, закладає основу для майбутніх інновацій, і ми з нетерпінням чекаємо, як розвиватиметься цей шлях, коли ми продовжимо будувати платформи, що генерують значущі інсайти та трансформації у світі хмарного моніторингу.

![pic](https://drive.javascript.org.ua/d709617a4c0_pQ0vNc_RRN6tLazq_jpg)

_Дякую за те, що знайшли час прочитати мій блог. Ваші відгуки надзвичайно важливі для мене. Будь ласка, поділіться своїми думками та пропозиціями._



Перекладено з: [Log Strata — Redefining Observability with Infra Monitor](https://medium.com/@sugam.arora23/log-strata-redefining-observability-with-infra-monitor-532ed79948b3?source=rss------cloud-5)

Вступ

Місія

Основні вимоги

Чому це завдання важливе

Як побудувати свій монітор інфраструктури

Крок 1: Закладання основ

Налаштування Docker, Kubectl і Minikube

Встановлення Docker:

Встановлення Kubectl:

Встановлення Minikube:

Крок 2: Розгортання додатків

Налаштування розгортання Kubernetes для app-1 та app-2

Передумови

Крок 1: Клонування тестових додатків

Крок 2: Створення розгортань та сервісів для Kubernetes

1. Створення розгортання та сервісу для MySQL (app-1)

2. Створення розгортання та сервісу для PostgreSQL (app-2)

3. Створення розгортань та сервісів для додатків

а. Для App-1 (підключено до MySQL)

b. Для App-2 (підключено до PostgreSQL)

С 3: Для хакатону Logger

Крок 4: Доступ до застосунків

Крок 5: Перевірка логів або виводу для Logger App

Крок 3: Майстерність збору логів

Основні компоненти Fluent Bit

1.

2. Фільтри

3. Плагіни виводу

Розгортання Fluent Bit в Kubernetes

1. ConfigMap

2.

**3.

Доступ до журналів

Складніші варіанти використання

1.

2. Використання кастомних парсерів

3.

Кращі практики

Крок 4: Побудова мозку — Backend

1. Розуміння InfluxDB

2.

Крок 1: Встановлення InfluxDB

Крок 2: Створення бази даних і токену

3.

Крок 1: Додайте плагін виведення InfluxDB

Крок 2: Налаштуйте плагін вводу

4. Зберігання та запити до даних в InfluxDB

5.

Поради щодо продуктивності InfluxDB

Інтеграція з інструментами візуалізації

Забезпечення безпеки інтеграції

6. Приклад кінцевого робочого процесу

7. Поради з усунення неполадок

Крок 5: Створення візуального інтерфейсу

1.1 Рівень помилок

1.2 Продуктивність запитів до бази даних

1.3 Трафік і використання ресурсів

2.1 Структура проєкту

2.2 Приклад коду для панелі інструментів (ReactJS)

3.

Приклад використання Chart.js для лінійного графіка (для помилок або трафіку)

4. API на бекенді для метрик

MetricsService.java

Крок 6: Перехід до розширених можливостей

1. Інтеграція логів ресурсів AWS

Кроки для інтеграції логів ресурсів AWS:

Приклад навчання простої моделі для прогнозування використання CPU

Прогнозування використання CPU на годину 5

Вам також може сподобатися

Leave a Reply