🤔 Как бы построили логирование только из определённых приложений с точки зрения EFK?

Можно настроить Filtre Fluentd/Fluent Bit или использовать labels в Kubernetes, чтобы:
- фильтровать только нужные логи по namespace, app label или по шаблону имени контейнера;
- настроить маршрутизацию в Elasticsearch через output-фильтры;
- исключить лишнее через конфиг на уровне сбора логов.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Как бы построить выделение ресурсов, балансировку, нагрузку и всю масштабированность?

Чтобы система работала стабильно и эффективно, нужно правильно распределять ресурсы, балансировать нагрузку и масштабировать сервисы.

🚩Основные компоненты

Выделение ресурсов - CPU, RAM, диски, сеть
Балансировка нагрузки равномерное распределение трафика
Горизонтальное и вертикальное масштабирование
Авто-масштабировани – динамическое добавление/удаление мощностей

🟠Выделение ресурсов (CPU, RAM, Диск, Сеть)
В виртуализированных средах (Kubernetes, Docker, AWS, KVM, ESXi) выделение ресурсов настраивается через лимиты и квоты.

yaml  
apiVersion: v1  
kind: Pod  
metadata:  
  name: my-app  
spec:  
  containers:  
  - name: app  
    image: my-app:latest  
    resources:  
      requests:  
        cpu: "500m"   # Минимально 0.5 CPU  
        memory: "256Mi" # Минимально 256MB RAM  
      limits:  
        cpu: "1000m"  # Максимально 1 CPU  
        memory: "512Mi" # Максимально 512MB RAM  

🟠Балансировка нагрузки
Балансировка уменьшает нагрузку на один сервер и равномерно распределяет запросы.

nginx  
upstream backend {  
  server app1:5000;  
  server app2:5000;  
}  
server {  
  listen 80;  
  location / {  
    proxy_pass http://backend;  
  }  
}  

Пример терраформа для AWS ALB

hcl  
resource "aws_lb" "example" {  
  name               = "my-load-balancer"  
  internal           = false  
  load_balancer_type = "application"  
  security_groups    = [aws_security_group.lb_sg.id]  
}  

🟠Масштабирование (Горизонтальное и Вертикальное)
Горизонтальное масштабирование (добавление новых инстансов)
Kubernetes Horizontal Pod Autoscaler (HPA)

yaml  
apiVersion: autoscaling/v2beta2  
kind: HorizontalPodAutoscaler  
metadata:  
  name: my-app-hpa  
spec:  
  scaleTargetRef:  
    apiVersion: apps/v1  
    kind: Deployment  
    name: my-app  
  minReplicas: 2  
  maxReplicas: 10  
  metrics:  
  - type: Resource  
    resource:  
      name: cpu  
      target:  
        type: Utilization  
        averageUtilization: 70  

🟠Авто-масштабирование (AWS/GCP/Kubernetes)
AWS Auto Scaling Group

hcl  
resource "aws_autoscaling_group" "example" {  
  min_size             = 2  
  max_size             = 10  
  desired_capacity     = 2  
  launch_configuration = aws_launch_configuration.example.name  
}

Ставь 👍 и забирай 📚 Базу знаний

🤔 Что значит ванильный Kubernetes?

Это чистая, стандартная установка Kubernetes без обёрток или специфичных дополнений от облачных провайдеров (таких как GKE, EKS, AKS). Ванильный кластер предоставляет полный контроль, но требует ручной настройки всех компонентов.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Какие есть метрики для измерения качества системы?

Для измерения качества системы (особенно в DevOps, SRE и разработке) используют различные метрики производительности, надежности и доступности.

🚩Основные метрики качества системы

🟠Метрики "Четырёх ключевых показателей" (DORA)
Эти метрики помогают оценить эффективность процессов DevOps:
Lead Time for Changes (Время доставки изменений) — время от написания кода до его выхода в прод.
Deployment Frequency (Частота развертываний) — как часто изменения попадают в прод.
Mean Time to Restore (MTTR) (Среднее время восстановления) — как быстро исправляются инциденты.
Change Failure Rate (Процент неудачных изменений) — доля развертываний, вызывающих сбои.

🟠Метрики надежности и доступности (SRE)
Эти метрики помогают измерять надежность системы:
SLA (Service Level Agreement) — договорное время доступности (например, 99.9%).
SLO (Service Level Objective) — целевое значение доступности (например, 99.95%).
SLI (Service Level Indicator) — фактические измеренные показатели (например, 99.93%).
Error Rate — процент ошибок в системе (HTTP 500, таймауты и т. д.).
Latency (Задержка) — время ответа системы на запросы.

🟠Метрики производительности
Они показывают, насколько быстро работает система:
CPU Utilization — загрузка процессора.
Memory Usage — использование оперативной памяти.
Disk I/O — скорость чтения/записи на диск.
Network Throughput — пропускная способность сети.
Response Time — время отклика системы.

🟠Метрики пользовательского опыта
Оценивают удобство работы пользователей с системой:
Apdex (Application Performance Index) — индекс удовлетворенности пользователей (0–1).
TTFB (Time to First Byte) — время до получения первого байта ответа от сервера.
Page Load Time — время полной загрузки страницы.
Bounce Rate — процент пользователей, покинувших сайт без взаимодействия.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Какие коды ответа мы получаем от веб-сервера?

Коды ответа (HTTP status codes) от веб-сервера представляют собой числовые коды, которые отправляются клиенту (обычно веб-браузеру) в ответ на его запрос. Эти коды помогают клиенту понять, что произошло с его запросом: был ли он успешен, произошла ли ошибка, требуется ли дополнительное действие и т.д.

🚩HTTP-коды ответа разделены на пять основных категорий:

🟠1xx (Информационные):
Запрос принят, продолжается обработка.
100 Continue: Сервер получил начальную часть запроса, и клиент должен продолжать.
101 Switching Protocols: Сервер принимает запрос на изменение протокола.

🟠2xx (Успех):
Запрос успешно обработан.
200 OK: Запрос успешно обработан, и сервер возвращает запрошенные данные.
201 Created: Запрос успешно выполнен, и в результате создан новый ресурс.
202 Accepted: Запрос принят для обработки, но обработка еще не завершена.
204 No Content: Запрос успешно выполнен, но сервер не возвращает никакого содержимого.

🟠3xx (Перенаправление):
Для завершения обработки запроса требуется дальнейшее действие со стороны клиента.
301 Moved Permanently: Запрашиваемый ресурс был перемещен на новый постоянный URL.
302 Found: Запрашиваемый ресурс временно доступен по другому URL.
304 Not Modified: Запрашиваемый ресурс не изменился со времени последнего доступа (кэширование).
307 Temporary Redirect: Запрашиваемый ресурс временно доступен по другому URL. Клиент должен использовать исходный метод для нового запроса.

🟠4xx (Ошибка клиента):
Ошибка в запросе клиента.
400 Bad Request: Сервер не может обработать запрос из-за неверного синтаксиса.
401 Unauthorized: Запрос требует аутентификации.
403 Forbidden: Сервер понял запрос, но отказывается его выполнять.
404 Not Found: Запрашиваемый ресурс не найден на сервере.
405 Method Not Allowed: Метод, указанный в запросе, не разрешен для запрашиваемого ресурса.
409 Conflict: Запрос не может быть выполнен из-за конфликта с текущим состоянием ресурса.

🟠5xx (Ошибка сервера):
Ошибка на стороне сервера при попытке обработки запроса.
500 Internal Server Error: Общая ошибка сервера. Сервер не может выполнить запрос.
501 Not Implemented: Сервер не поддерживает функциональность, необходимую для выполнения запроса.
502 Bad Gateway: Сервер, действуя как шлюз или прокси, получил неверный ответ от вышестоящего сервера.
503 Service Unavailable: Сервер временно недоступен, обычно из-за перегрузки или технического обслуживания.
504 Gateway Timeout: Сервер, действуя как шлюз или прокси, не дождался ответа от вышестоящего сервера.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Как в docker compose вместо yaml файла использовать json файл?

Docker Compose поддерживает использование JSON-файлов вместо стандартного YAML-файла. Формат JSON полностью совместим с YAML, так как YAML является надмножеством JSON. Для этого достаточно создать JSON-файл с описанием конфигурации контейнеров и передать его с помощью опции -f.

🚩Шаги по использованию

🟠Создайте JSON-файл конфигурации
Файл должен содержать описание сервисов в формате JSON. Например, вместо YAML

version: "3.9"
services:
  web:
    image: nginx
    ports:
      - "80:80"

В формате JSON будет так

{
    "version": "3.9",
    "services": {
        "web": {
            "image": "nginx",
            "ports": ["80:80"]
        }
    }
}

🟠Запустите Docker Compose с этим файлом
Используйте флаг -f, чтобы указать Docker Compose, какой файл использовать

docker-compose -f docker-compose.json up

🟠Проверка работы
Вы можете проверить статус контейнеров, как обычно:

docker-compose -f docker-compose.json ps

🚩Почему использовать JSON?

🟠Совместимость
JSON часто используется в API, CI/CD-пайплайнах и других инструментах, которые могут генерировать конфигурации автоматически.
🟠Простота обработки
JSON легко парсить программно, что может быть полезно в скриптах и интеграциях.
🟠Стандартизация
Некоторые команды и проекты могут предпочитать JSON как более строгий и распространенный формат.

🚩Пример использования

1⃣Создайте файл docker-compose.json

{
    "version": "3.8",
    "services": {
        "app": {
            "image": "python:3.9",
            "volumes": ["./app:/app"],
            "working_dir": "/app",
            "command": "python app.py"
        }
    }
}

2⃣Запустите

docker-compose -f docker-compose.json up

Ставь 👍 и забирай 📚 Базу знаний

🤔 Как диагностировать проблемы с локальным сервером который не отвечает на ping?

Если сервер не пингуется, это не значит, что он не работает – проблема может быть в сети, настройках брандмауэра или самом сервере.

🚩Пошаговая диагностика

1⃣Проверить, действительно ли сервер включен
Подойти к серверу и проверить:
Горят ли индикаторы сети (LAN) на сервере?
Реагирует ли на клавиатуру/монитор?
Не завис ли сервер? (Может помочь Hard Reboot).

2⃣Проверить, есть ли связь на L2-уровне (MAC-адреса)
Проверяем, видит ли наш компьютер MAC-адрес сервера через `arp`.
Запрос ARP

arp -a | grep 192.168.1.100

Если MAC-адрес есть → пакеты доходят до сервера, но он не отвечает.
Если MAC-адреса нет → возможны проблемы с сетью (кабель, порт, VLAN, DHCP, статика).
Дополнительно проверить соединение

ethtool eth0  # Проверить состояние сетевого адаптера
ip link show eth0  # Интерфейс должен быть UP

3⃣Проверить, отвечает ли сервер на другие запросы (SSH, HTTP, RDP)
Если ping отключен (ICMP заблокирован брандмауэром), но сервер работает, попробуем другие протоколы.
Пробуем зайти по SSH (если это Linux)

ssh user@192.168.1.100

Пробуем зайти по RDP (если это Windows)

rdesktop 192.168.1.100

Пробуем зайти через HTTP (если там веб-сервер)

curl -I http://192.168.1.100

4⃣Проверить сетевой интерфейс на сервере
Подключаемся к серверу (если возможно) и проверяем, есть ли у него сеть.
Проверяем IP-адрес сервера

ip a

или

ifconfig -a

Пробуем пропинговать шлюз с сервера

ping 192.168.1.1

5⃣Проверить брандмауэр и iptables на сервере
Если сервер не отвечает на ICMP, его может блокировать брандмауэр.
Linux (firewalld, iptables, ufw)

iptables -L -n | grep DROP  # Проверяем правила iptables
ufw status  # Проверяем UFW (если используется)
firewall-cmd --list-all  # Проверяем firewalld

Если ICMP запрещен → разрешаем его

iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

ufw allow proto icmp

firewall-cmd --add-icmp-block=echo-reply --permanent
firewall-cmd --reload

Windows (Проверить ICMP в брандмауэре Windows)

netsh advfirewall firewall show rule name="File and Printer Sharing (Echo Request - ICMPv4-In)"

Если правило отключено → включаем

netsh advfirewall firewall add rule name="ICMP Allow" protocol=icmpv4:8,any dir=in action=allow

6⃣Проверить маршрутизацию и сеть
Если сервер и клиент находятся в разных VLAN или подсетях, проверяем маршрут.
На клиенте

traceroute 192.168.1.100  # Linux
tracert 192.168.1.100  # Windows

Проверить маршруты на сервере

ip route show

Если маршрут отсутствует → добавляем вручную

ip route add 192.168.1.0/24 via 192.168.1.1

Ставь 👍 и забирай 📚 Базу знаний

🤔 Как сделать rebase на main branch?

Выполнить rebase на main в Git означает "перенести" ваши изменения поверх актуального состояния основной ветки (main).

🟠Переключаемся на вашу текущую ветку
Допустим, вы работаете в ветке feature-branch:

git checkout feature-branch

🟠Выполняем rebase на `main`
Сначала убедимся, что main обновлена:

git checkout main
git pull origin main

Теперь выполняем сам rebase:

git checkout feature-branch
git rebase main

🟠Разрешение конфликтов (если есть)
Если у вас есть конфликты, Git остановит процесс и попросит их решить.
Откройте файлы с конфликтами, исправьте их.
Добавьте исправленные файлы:

   git add <файл>
   

Продолжите rebase:

   git rebase --continue
   

🟠Обновление удалённого репозитория
Если rebase прошёл успешно, вам нужно форсированно обновить удалённую ветку (так как история изменилась):

git push origin feature-branch --force

Ставь 👍 и забирай 📚 Базу знаний

🤔 Как проверять, что запрошенные пару сервисов видят друг друга?

1. Ping – проверяет, доступен ли хост (ping <IP>).
2. Traceroute (traceroute/mtr) – показывает маршрут пакетов.
3. Nslookup/Dig – проверка DNS-резолвинга (nslookup domain.com).
4. Telnet/NC – проверка доступности порта (nc -zv <IP> <PORT>).
5. Curl/Wget – проверка HTTP-доступа (curl -I http://service).
6. Tcpdump/Wireshark – анализ сетевого трафика.
7. Kubernetes Debug (kubectl exec, logs, describe) – если сервисы в K8s.
Если сервисы не видят друг друга, проверяют маршрутизацию, iptables, firewall, DNS.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Какой командой можно показать все работающие процессы на Linux?

Для отображения всех работающих процессов в Linux можно использовать несколько команд. Самые популярные из них: ps, top, htop и pgrep. Каждая из них имеет свои особенности.

🚩Команда `ps`

ps выводит снимок (snapshot) текущих процессов в момент выполнения команды.
🟠`ps aux`
Показывает все процессы, запущенные в системе, включая пользователей и системные демоны.

ps aux

🟠`ps -ef`
Альтернативный стиль вывода всех процессов с более детальной информацией.

ps -ef

🚩Команда `top`

top — интерактивная утилита для отображения всех запущенных процессов в реальном времени. Вывод обновляется автоматически.

Запуск

top

🚩Команда `htop`

htop — более современная и удобная версия top. Требуется предварительная установка:

sudo apt install htop  # Для Ubuntu/Debian
sudo yum install htop  # Для CentOS/RHEL

Запуск

htop

🚩Команда `pgrep`

pgrep используется для поиска процессов по имени, но с дополнительными опциями можно вывести все процессы.

Пример

pgrep -a ""

🚩Команда `systemctl` (для сервисов)

Если вы хотите посмотреть системные службы

systemctl list-units --type=service

🚩Какую команду выбрать?

🟠Для быстрого снимка
ps aux.
🟠Для мониторинга в реальном времени
top или htop.
🟠Для поиска конкретного процесса
pgrep <имя процесса>.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Как решать проблему, если ваш коллега удалил /usr/bin/chmod, и нет ОС-донора?

- Если chmod удалён, изменить права файла невозможно стандартным способом.
- Возможные варианты:
- Найти бинарник chmod в другой директории (например, в /bin, /sbin, /usr/local/bin).
- Использовать busybox chmod, если busybox установлен.
- Если есть root-доступ — попробовать выполнить через python, perl или bash:
- python -c 'import os; os.chmod("file", 0o755)'
- Или через find с -exec (если chmod встроен туда).
- В крайнем случае — смонтировать диск на другой системе (если физически возможно).

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Какая компонента запускает под на ноде, какая отвечает за сеть?

В Kubernetes разные компоненты отвечают за запуск подов и сетевые настройки.

🚩Какая компонента запускает под на ноде? (`kubelet`)

Получает команды от kube-scheduler (назначение подов)
Запускает контейнеры через Container Runtime (Docker, containerd, CRI-O)
Следит за состоянием подов и перезапускает их при сбоях

systemctl status kubelet

Посмотреть логи kubelet

journalctl -u kubelet -f

🚩Какая компонента отвечает за сеть? (CNI)

Назначает IP-адреса подам
Организует маршрутизацию трафика между подами и нодами
Настраивает Network Policies (безопасность сети)
Проверить работающие сетевые плагины

kubectl get pods -n kube-system

Вывод (если CNI работает нормально)

NAME               READY   STATUS    RESTARTS   AGE
calico-node-xyz   1/1     Running   2          3d

Если CNI не работает, поды могут застрять в ContainerCreating

kubectl get pods

NAME          READY   STATUS              RESTARTS   AGE
web-server    0/1     ContainerCreating   0          10m

Ставь 👍 и забирай 📚 Базу знаний

🤔 Что такое SRE, чем отличается от DevOps?

- SRE (Site Reliability Engineering) — инженерная практика от Google.
- Фокус на доступности, стабильности, SLO, SLA.
- Работает с ошибками, алертами, инцидентами.
- DevOps — культурный подход, объединяющий разработку и эксплуатацию.
SRE — это инженерная реализация DevOps, с акцентом на метрики и надёжность.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Для чего используется clickhouse?

ClickHouse – это высокопроизводительная колоночная база данных для аналитики.

Она предназначена для быстрого выполнения аналитических запросов на больших объемах данных (миллиарды строк). Используется в BI-системах, логировании, мониторинге и обработке событий.

🚩Основные возможности

🟠Очень быстрые запросы
за счёт хранения данных по колонкам и сжатия.
🟠Отлично масштабируется
работает на одной машине или в кластере.
🟠Поддержка SQL
работает с привычными SQL-запросами.
🟠Хорош для real-time аналитики
обработка миллионов событий в секунду.
🟠Без индексов
использует Primary Key + MergeTree, что упрощает оптимизацию.
🟠Хорошее сжатие данных
благодаря специальным алгоритмам хранения.

🚩Где используется?

🟠Аналитика и отчёты
BI-системы (анализ продаж, маркетинга, поведения пользователей).
Агрегация данных по времени (финансы, реклама, ретеншн).

🟠Логирование и мониторинг
Хранение логов (NGINX, Kubernetes, Clickstream).
Аналитика событий в реальном времени.

🟠IoT и Big Data
Обработка телеметрии с датчиков.
Анализ поведения пользователей в приложениях.

🟠Пример работы с ClickHouse
1⃣Создание таблицы

CREATE TABLE visits (
    user_id UInt32,
    url String,
    duration UInt32,
    event_time DateTime
) ENGINE = MergeTree()
ORDER BY event_time;

2⃣Вставка данных

INSERT INTO visits VALUES (1, 'https://example.com', 30, now());

3⃣Аналитический запрос (например, среднее время посещения сайта)

SELECT url, AVG(duration) 
FROM visits 
GROUP BY url 
ORDER BY AVG(duration) DESC;

Ставь 👍 и забирай 📚 Базу знаний

🤔 Какие таблицы прописывал в iptables?

В iptables есть 5 таблиц, но чаще всего работают с тремя:

🟠`filter`
основная таблица для контроля трафика (используется по умолчанию)
🟠`nat`
для трансляции адресов (SNAT, DNAT, редиректы)
🟠`mangle`
для изменения пакетов (маркировка, TTL, QoS)
🟠`raw`
для исключения пакетов из обработки conntrack
🟠`security`
используется в SELinux для меток безопасности

🚩Таблица `filter` (фильтрация пакетов)

Используется для разрешения или блокировки трафика.

iptables -P INPUT DROP  
iptables -A INPUT -p tcp --dport 22 -j ACCEPT  

🚩Таблица `nat` (трансляция адресов)

Используется для NAT, порт-форвардинга, маскарадинга.

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE  

Пример: Проброс порта (DNAT) – входящие пакеты на 80 порт перенаправляем на 8080

iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080  

🚩Таблица `mangle` (изменение пакетов)

Используется для маркировки пакетов, изменения TTL, QoS.

iptables -t mangle -A POSTROUTING -j TTL --ttl-set 64  

Пример: Маркировка пакетов для использования в tc (QoS)

iptables -t mangle -A PREROUTING -p tcp --dport 22 -j MARK --set-mark 1

Ставь 👍 и забирай 📚 Базу знаний

🤔 Какой самый большой минус Ansible?

Ansible – мощный инструмент для автоматизации, но у него есть серьезные недостатки, особенно при масштабировании.

🚩Основной минус – Медленная работа на больших инфраструктурах

🟠Нет агентов
каждый раз Ansible подключается по SSH и выполняет задачи без предварительного кеширования
что замедляет процесс.

🟠Ограничения Python на удаленных хостах
если целевой сервер слабый или без Python, выполнение плейбуков будет медленным.

🟠Последовательное выполнение
по умолчанию Ansible выполняет задачи последовательно, что дольше, чем параллельные методы (например, в SaltStack).

yaml  
- name: Установка Nginx  
  hosts: all  
  tasks:  
    - name: Установить Nginx  
      apt:  
        name: nginx  
        state: present  

Запуск задач параллельно (-f 50)

sh  
ansible-playbook playbook.yml -f 50  

🚩Другие минусы Ansible

🟠Высокая нагрузка на управляющий узел
Если 1000+ серверов, главный Ansible-узел может быстро перегрузиться.

🟠Сложное управление зависимостями
Роли могут конфликтовать, если версии не совпадают. Ansible Galaxy не такой удобный, как Terraform Registry

🟠Ограниченная идемпотентность
Некоторые модули (особенно shell и command) не всегда понимают, применялась ли конфигурация раньше.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Сервис типа кластер P со значением nan, что это значит?

nan = Not a Number
В контексте метрик или мониторинга (например, Prometheus, Grafana), NaN указывает:
- Значение не было рассчитано.
- Источник данных не вернул метрику.
- В формуле деление на ноль или ошибка в агрегации.
- Сервис неактивен или отключен.
Если это в метриках по кластеру — возможно, сервис вообще не репортит нужную метрику.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний

🤔 Что такое data source в графане?

Это источник данных, с которым Grafana может взаимодействовать для построения графиков, панелей мониторинга (dashboards) и выполнения запросов. Data Source определяет, как Grafana подключается к внешним системам мониторинга, базам данных или API для получения метрик, логов или другой информации.

🚩Основные аспекты

🟠Типы Data Source
Grafana поддерживает множество типов источников данных, включая:
Системы мониторинга:
Prometheus
Zabbix
InfluxDB
Graphite
Лог-агрегаторы:
Loki
Elasticsearch
Splunk
Облачные сервисы:
AWS CloudWatch
Google Cloud Monitoring
Azure Monitor
Реляционные базы данных:
MySQL
PostgreSQL
API или внешние плагины:
JSON API
OpenTelemetry

🟠Функции Data Source
Подключение: Определяет параметры для соединения с внешним хранилищем данных, такие как URL, токены аутентификации, логин/пароль. Выполнение запросов: Обеспечивает интерфейс для написания запросов к данным через встроенный редактор запросов Grafana. Форматирование данных: Конвертирует данные из формата, предоставляемого источником, в формат, понятный Grafana.

🟠Добавление Data Source
Добавление источника данных выполняется через веб-интерфейс Grafana:
Зайдите в Settings → Data Sources.
Нажмите кнопку Add data source.
Выберите нужный тип источника (например, Prometheus).
Настройте параметры подключения (например, URL, токен, порт).
Нажмите Save & Test, чтобы проверить соединение.

🟠Примеры запросов
Для Prometheus:

rate(http_requests_total[5m])

Для MySQL

SELECT time, value FROM metrics WHERE time > NOW() - INTERVAL 1 HOUR;

🚩Особенности Data Source

🟠Кастомизация
Вы можете устанавливать плагины для подключения к нестандартным источникам данных. Grafana Marketplace предлагает плагины для расширения функциональности.

🟠Мульти-сорсинг
Один дашборд может использовать несколько источников данных, что позволяет объединять данные из разных систем.

🟠Глобальные переменные
Источники данных могут использовать глобальные параметры, такие как время ($__timeFilter), для унификации запросов.

🟠Безопасность
Поддержка различных методов аутентификации: токены, ключи API, OAuth.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Как мы можем с помощью cloudfront сохранить бюджет на использование сервисов?

Amazon CloudFront — это CDN (Content Delivery Network), которая помогает оптимизировать затраты на трафик и нагрузку на серверы. Использование CloudFront позволяет экономить бюджет на AWS-сервисах следующими способами:

🟠Кеширование контента (уменьшение нагрузки на бэкенд)
CloudFront кэширует статический и динамический контент, что снижает количество запросов к вашим основным серверам (например, EC2, S3, API Gateway, Lambda).
Меньше запросов к S3 (меньше операций GET, а они платные).
Меньше запросов к API Gateway и Lambda (так как CloudFront может кешировать ответы API).
Экономия на EC2 и RDS, так как нагрузка перераспределяется.

🟠Использование бесплатного трафика между CloudFront и S3
Когда CloudFront забирает файлы из S3 в том же регионе, за исходящий трафик из S3 не взимается плата. Исходящий трафик из S3 в интернет стоит ≈ $0.09 за ГБ. Исходящий трафик из CloudFront в интернет дешевле (например, первые 1 ТБ в месяц — бесплатно).

🟠Снижение стоимости глобального трафика
Если у вас клиенты в разных странах, CloudFront дешевле, чем стандартный AWS-трафик. Исходящий трафик из CloudFront в интернет в среднем на 30-50% дешевле, чем прямой выход из EC2 или S3. AWS часто снижает цены на CloudFront трафик в рамках программ оптимизации.

🟠Фильтрация ненужного трафика (ботов, DDoS, парсеров)
CloudFront позволяет использовать AWS WAF (Web Application Firewall) для блокировки вредоносных запросов. Меньше запросов к бэкенду (EC2, API Gateway, Lambda). Защита от DDoS (AWS Shield Standard бесплатен для CloudFront).

🟠Кеширование динамического контента
CloudFront поддерживает TTL (Time-to-Live) для кэширования даже динамических API-ответов. Вместо запроса к API Gateway/Lambda, CloudFront может вернуть кэшированный ответ. Можно настроить "Stale While Revalidate" — клиент получает устаревший контент, пока идет обновление.

🟠Гибкое управление ценой через региональные edge-локации
CloudFront позволяет управлять ценами, ограничивая определенные регионы. Можно исключить дорогие регионы (например, Южную Америку, где трафик дороже). Можно использовать AWS Origin Shield для дополнительного кеширования между регионами.

🟠Использование CloudFront Functions вместо AWS Lambda
CloudFront поддерживает CloudFront Functions, которые выполняются прямо на edge-узлах и дешевле, чем Lambda@Edge. CloudFront Functions работают быстрее и стоят $0.10 за миллион запросов. Lambda@Edge стоит $0.60 за миллион запросов + плата за выполнение.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Что такое SLA, SLO, SLI?

Эти три термина относятся к управлению надежностью и качеством IT-сервисов. Они помогают определить, измерить и гарантировать уровень обслуживания пользователей.

🚩SLI (Service Level Indicator) – Показатель уровня сервиса

SLI – это метрика, которая показывает, насколько хорошо работает сервис.
- Доступность (например, uptime 99.9%)
- Время ответа API (например, менее 200 мс)
- Ошибки запросов (например, не более 1% 5xx ошибок)

🚩SLO (Service Level Objective) – Целевой уровень сервиса

SLO – это цель, которую компания ставит для SLI.
Доступность 99.9% сервиса в месяц.
Среднее время ответа API ≤ 200 мс.

🚩SLA (Service Level Agreement) – Соглашение об уровне сервиса

SLA – это официальное соглашение между клиентом и провайдером сервиса, которое описывает обязательства и штрафы за их невыполнение.
- Если доступность меньше 99.9%, клиент получает возврат денег.
- Если среднее время ответа API больше 500 мс, клиент получает скидку.

🚩Как они связаны?

SLI (метрика) → измеряет, насколько хорош сервис.
SLO (цель) → устанавливает, каким должен быть сервис.
SLA (договор) → фиксирует обязательства и штрафы.

Ставь 👍 и забирай 📚 Базу знаний

🤔 Как ограничить видимость глобальной переменной между двумя функциями?

- Использовать (двойное подчеркивание) для индикации приватности (по соглашению).
- Не экспортировать в __all модуля.
- Или структурировать код так, чтобы переменные были внутри классов/замыканий.

Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний