По умолчанию в access.log не указывается location напрямую, но:
- Обычно можно различить по пути URL — если location /static/, location /cache/, location /backend/ — это отражается в строке запроса.
- Чтобы точно видеть, откуда был ответ, можно:
- Добавить пользовательский формат логов, где записывать $uri или специальные переменные ($request_uri, $upstream_addr и пр.).
- Логировать переменные, которые задаются внутри каждого location (например, set $source static → логируешь $source).
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
Визуализация логов — это процесс представления лог-файлов в удобном графическом виде для более легкого анализа, поиска аномалий и устранения проблем. Для этого используются различные инструменты, которые собирают, агрегируют и отображают логи в виде графиков, дашбордов и диаграмм.
вместо просмотра тысяч строк логов можно быстро увидеть тенденции и аномалии.
можно отслеживать изменения в режиме реального времени.
легче выявить причину ошибки, если видеть всплески или изменения в логах.
миллионы строк логов можно представить в виде сводных диаграмм.
Logstash – собирает и обрабатывает логи.
Elasticsearch – хранит и индексирует логи для быстрого поиска.
Kibana – визуализирует данные, строит графики и дашборды.
Пример: Можно создать график с количеством ошибок 500 за последние 24 часа.
Loki – хранит и обрабатывает логи.
Grafana – строит красивые дашборды с логами и метриками.
Пример: Можно создать панель с последними логами приложений, используя
tail-подобное обновление. Обрабатывает логи, хранит их в Elasticsearch, строит графики и отправляет алерты.
Пример: Можно отфильтровать логи по уровню
ERROR и вывести их в виде диаграммы. Коммерческие решения с мощными инструментами аналитики логов.
Пример: Автоматическая корреляция логов с метриками системы.
Logstash конфиг (сбор логов из файла)
input {
file {
path => "/var/log/app.log"
start_position => "beginning"
}
}
output {
elasticsearch {
hosts => ["https://localhost:9200"]
}
}Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
Чтобы система работала стабильно и эффективно, нужно правильно распределять ресурсы, балансировать нагрузку и масштабировать сервисы.
Выделение ресурсов - 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 https://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 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
}
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
Ограничения задаются в манифесте контейнера с помощью resources.limits и resources.requests.
requests — минимальные ресурсы, которые контейнеру гарантированы.
limits — максимум, который контейнер может использовать.
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
AWS предоставляет облачные сервисы для автоматизации CI/CD, управления инфраструктурой, мониторинга и безопасности.
AWS предлагает инструменты для автоматической сборки, тестирования и деплоя.
AWS CodePipeline – автоматизация CI/CD-процессов
AWS CodeBuild – сборка и тестирование кода
AWS CodeDeploy – автоматический деплой в EC2, ECS, Lambda
AWS CodeCommit – репозиторий Git в AWS
Пример CI/CD-пайплайна в AWS CodePipeline
1. CodeCommit получает новый коммит
2. CodeBuild собирает и тестирует код
3. CodeDeploy разворачивает приложение на EC2
В DevOps важно автоматически создавать и управлять ресурсами AWS.
Terraform – создает инфраструктуру по коду
AWS CloudFormation – аналог Terraform от AWS
AWS CDK (Cloud Development Kit) – IaC на Python/TypeScript
hcl
resource "aws_instance" "web" {
ami = "ami-123456"
instance_type = "t2.micro"
}
AWS поддерживает управление контейнерами и Kubernetes.
Amazon ECS (Elastic Container Service) – контейнеры без Kubernetes
Amazon EKS (Elastic Kubernetes Service) – управляемый Kubernetes
AWS Fargate – запуск контейнеров без управления серверами
Пример развертывания контейнера в AWS ECS:
1. Собираем Docker-образ
2. Загружаем его в Amazon ECR (Elastic Container Registry)
3. ECS автоматически масштабирует и управляет контейнерами
Amazon CloudWatch – сбор метрик и логов
AWS X-Ray – трассировка запросов в микросервисах
AWS CloudTrail – аудит действий в AWS
Пример мониторинга EC2
1. CloudWatch собирает метрики CPU, RAM
2. Настраиваем авто-масштабирование на основе этих метрик
3. CloudTrail записывает все изменения инфраструктуры
AWS IAM (Identity and Access Management) – контроль прав
AWS Secrets Manager – управление паролями и API-ключами
AWS KMS (Key Management Service) – шифрование данных
hcl
resource "aws_iam_role" "s3_read" {
name = "s3-read-only"
assume_role_policy = jsonencode({
Statement = [{
Effect = "Allow"
Action = "s3:GetObject"
Resource = "arn:aws:s3:::my-bucket/*"
}]
})
}
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
Она позволяет отслеживать изменения в базах данных (INSERT, UPDATE, DELETE) в реальном времени и передавать их в Kafka, Elasticsearch, MongoDB и другие системы.
Подключается к базе данных
(PostgreSQL, MySQL, MongoDB, Oracle и др.).
Слушает лог изменений (binlog, WAL, oplog и т. д.)
Формирует события в формате JSON
Передаёт их в Kafka или другую шину данных.
Синхронизация данных между базами
Репликация данных в реальном времени
Отправка изменений в аналитические системы (Elasticsearch, ClickHouse)
Аудит и логирование изменений
Запускаем Debezium Connector для PostgreSQL*
{
"name": "inventory-connector",
"config": {
"connector.class": "io.debezium.connector.postgresql.PostgresConnector",
"database.hostname": "localhost",
"database.port": "5432",
"database.user": "debezium",
"database.password": "dbz",
"database.dbname": "inventory",
"database.server.name": "dbserver1"
}
}При изменении данных в таблице, Kafka получит событие:
{
"schema": { ... },
"payload": {
"before": { "id": 1, "name": "Old Name" },
"after": { "id": 1, "name": "New Name" },
"op": "u" // Update
}
}Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
Worker-нода содержит:
- kubelet — агент, управляющий подами.
- kube-proxy — сетевое взаимодействие и балансировка.
- container runtime — Docker, containerd, CRI-O.
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2🔥2
Для настройки уведомлений в изолированной сети без доступа к интернету используйте локальные инструменты и системы. Основные методы включают локальные почтовые серверы, мессенджеры и системы управления инцидентами.
sudo apt update
sudo apt install postfix
Отредактируйте
/etc/postfix/main.cf myhostname = local.example.com
mydomain = example.com
myorigin = $mydomain
inet_interfaces = all
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
relay_domains = $mydestination
sudo systemctl restart postfix
echo "Test email" | mail -s "Test Subject" [email protected]
Следуйте [документации](https://docs.mattermost.com/install/self-managed-install.html).
Создайте каналы и пользователей.
Используйте веб-хуки Mattermost для уведомлений.
Следуйте [документации](https://www.zabbix.com/download).
Настройте хосты, триггеры и действия.
Медиатипы: Настройте Email и SMS. Пользователи: Создайте пользователей и уведомления.
wget https://github.com/prometheus/prometheus/releases/download/v2.26.0/prometheus-2.26.0.linux-amd64.tar.gz
tar xvf prometheus-2.26.0.linux-amd64.tar.gz
cd prometheus-2.26.0.linux-amd64
./prometheus --config.file=prometheus.yml
wget https://github.com/prometheus/alertmanager/releases/download/v0.21.0/alertmanager-0.21.0.linux-amd64.tar.gz
tar xvf alertmanager-0.21.0.linux-amd64.tar.gz
cd alertmanager-0.21.0.linux-amd64
./alertmanager --config.file=alertmanager.yml
groups:
- name: example-alerts
rules:
- alert: HighCPUUsage
expr: avg_over_time(node_cpu_seconds_total{mode="idle"}[5m]) < 20
for: 2m
labels:
severity: critical
annotations:
summary: "High CPU usage detected"
description: "CPU usage is above 80% for more than 2 minutes"
global:
smtp_smarthost: 'localhost:25'
smtp_from: '[email protected]'
route:
receiver: 'email-notifications'
receivers:
- name: 'email-notifications'
email_configs:
- to: '[email protected]'
send_resolved: true
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
Экспортёры собирают метрики из сервисов или ОС и предоставляют их по HTTP в формате, который Prometheus может опрашивать. Они работают по модели pull, где Prometheus забирает данные сам.
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1🔥1
Горизонтальное масштабирование – это добавление новых экземпляров (реплик) сервиса для увеличения производительности. Оно хорошо работает для статeless (без состояния) микросервисов, где нет привязки к конкретному серверу.
Примеры: Nginx, Traefik, Kong, API Gateway (AWS, GCP)
Почему можно масштабировать?
- Обрабатывают независимые запросы
- Не требуют сохранения состояния между запросами
- Легко распределяются через Load Balancer
yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-api
spec:
replicas: 5
selector:
matchLabels:
app: my-api
template:
metadata:
labels:
app: my-api
spec:
containers:
- name: api-container
image: my-api:latest
Примеры: REST API (FastAPI, Express, Spring Boot), gRPC-сервисы
Почему можно масштабировать?
Каждый запрос обрабатывается независимо
Нет привязки к конкретному серверу
Можно использовать Load Balancer (например, AWS ALB, Nginx)
nginx
upstream backend {
server backend1:5000;
server backend2:5000;
server backend3:5000;
}
server {
listen 80;
location / {
proxy_pass https://backend;
}
}
Примеры: RabbitMQ, Kafka, NATS, Redis Streams
Почему можно масштабировать?
Сообщения разбираются разными нодами
Можно увеличивать число консьюмеров
Поддерживают partitioning (разделение нагрузки)
python
from kafka import KafkaConsumer
consumer = KafkaConsumer('my_topic', group_id='workers', bootstrap_servers='kafka:9092')
for message in consumer:
process_message(message)
Примеры: Redis (в режиме Cluster), Memcached
Почему можно масштабировать?
Каждый узел хранит часть данных
Можно распределять кэш по нескольким инстансам
Redis поддерживает Sharding (разбиение данных на ноды)
sh
redis-cli --cluster create 192.168.1.1:6379 192.168.1.2:6379 192.168.1.3:6379 --cluster-replicas 1
Некоторые сервисы сохраняют состояние (stateful) и сложны в горизонтальном масштабировании:
Базы данных → MySQL, PostgreSQL (нужны реплики или шардирование)
Сервисы с сессиями → Например, если пользователь всегда должен попасть на тот же сервер
Хранилища файлов → Например, локальное хранение логов на сервере
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Когда под (Pod) не работает или ведёт себя странно, нужно уметь его дебажить.
Сначала смотрим, работает ли под вообще
kubectl get pods
Если под запустился, но работает странно, смотрим логи:
kubectl logs pod-name
Если в поде несколько контейнеров:
kubectl logs pod-name -c container-name
Если под перезапускается, а нам нужны старые логи:
kubectl logs pod-name --previous
Смотрим подробную информацию о поде:
kubectl describe pod pod-name
Если под запущен, можно подключиться внутрь и посмотреть файлы, процессы:
kubectl exec -it pod-name -- /bin/sh
Если в контейнере есть только
bash: kubectl exec -it pod-name -- /bin/bash
Полезные команды внутри контейнера:
ps aux # Смотрим запущенные процессы
netstat -tulnp # Проверяем открытые порты
env # Проверяем переменные окружения
cat /etc/resolv.conf # Проверяем DNS
Если под ведёт себя странно, можно посмотреть его полное описание:
kubectl get pod pod-name -o yaml
Иногда под не запускается из-за нехватки CPU или памяти. Проверяем узел (
node): kubectl describe node node-name
Если проблема с ресурсами, будет что-то вроде:
Warning FailedScheduling insufficient memory
Если под не может достучаться до сервиса, тестируем сеть:
kubectl exec -it pod-name -- nslookup service-name
kubectl exec -it pod-name -- ping 8.8.8.8
kubectl exec -it pod-name -- curl https://service-name:8080
Если под не стартует, можно запустить дебажный контейнер
kubectl debug pod-name -it --image=busybox
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Процедура траблшутинга проводится с помощью логов (journalctl, kubectl logs), мониторинга (Prometheus, Grafana), сетевых утилит (netstat, tcpdump, nmap), профилировщиков (htop, top, iotop) и инструментов трассировки (strace, lsof). Также полезны APM-системы и средства централизованного логирования (ELK, Loki).
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2👍1
Multi-stage (многоэтапная сборка) — это метод создания Docker-образов, позволяющий уменьшить их размер и повысить безопасность.
удаляем ненужные зависимости из финального образа.
не включаем инструменты сборки в рабочий контейнер.
меньший образ быстрее скачивается и запускается.
собираем приложение в одном окружении, а запускаем в другом.
Допустим, у нас есть приложение на Go. Мы сначала компилируем его в одном контейнере, а затем создаем минимальный образ для запуска.
# Этап 1: сборка
FROM golang:1.20 AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp
# Этап 2: минимальный образ для запуска
FROM alpine:latest
WORKDIR /root/
COPY --from=builder /app/myapp .
CMD ["./myapp"]
При сборке фронтенда мы можем сначала установить зависимости и собрать проект, а затем развернуть его на
nginx. # Этап 1: сборка приложения
FROM node:18 AS builder
WORKDIR /app
COPY package.json ./
RUN npm install
COPY . .
RUN npm run build
# Этап 2: деплой на nginx
FROM nginx:alpine
COPY --from=builder /app/dist /usr/share/nginx/html
CMD ["nginx", "-g", "daemon off;"]
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1🔥1
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
В Linux удаленный файл может оставаться в памяти, если он все еще используется запущенным процессом. Это происходит, потому что файл не удаляется физически, пока его дескриптор (file descriptor) открыт.
Файл все еще используется процессом
Файл удален, но все еще открыт (
deleted в /proc) Файл удален, но был записан в смонтированный том
Команда
lsof | grep deleted
Вывод
nginx 1234 www-data 4w REG 8,1 5G /var/log/nginx/access.log (deleted)
Решение: Перезапустить процесс:
systemctl restart nginx
или
kill -HUP 1234 # Закрыть процесс (PID = 1234)
Если процесс нельзя перезапустить, можно освободить занятую память без перезапуска.
ls -l /proc/*/fd/ | grep deleted
Вывод
lrwx------ 1 root root 64 Feb 21 14:23 /proc/5678/fd/4 -> /var/log/nginx/access.log (deleted)
Очистить файл, не перезапуская процесс
> /proc/5678/fd/4
Если файл хранился в смонтированном томе, он может не удалиться сразу.
Проверить монтированные диски:
df -h
mount | grep /var/log
Если файл был в Docker-контейнере, проверить объемы:
docker system df
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
2. Транспортный (Transport) — TCP, UDP.
3. Сетевой (Internet) — IP, ICMP, ARP.
4. Канальный (Link/Network Access) — Ethernet, Wi-Fi, драйверы устройств.
Ставь 👍 если знал ответ, 🔥 если нет
Забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
💊5🤔2👍1
Запуск контейнеров от имени пользователя root (рута) в Docker является обычной практикой, но это может привести к серьезным проблемам безопасности. Вот основные причины, почему это считается плохой практикой:
Эксплуатация уязвимостей: Если злоумышленник получает доступ к контейнеру, запущенному от имени root, он может легко использовать уязвимости контейнера для атаки на хост-систему.
Злоумышленники: Контейнеры могут содержать уязвимые или злонамеренные коды, которые при запуске с привилегиями root могут получить доступ к чувствительной информации или вызвать сбои.
Гостевая изоляция: Контейнеры должны быть изолированы от хост-системы. Запуск контейнера от имени root нарушает эту изоляцию, так как root внутри контейнера — это также root на хосте.
Повышенные привилегии: Контейнеры, запущенные от имени root, могут иметь доступ к системным ресурсам, что увеличивает риск нарушения безопасности.
Принцип наименьших привилегий: Этот принцип гласит, что процесс должен иметь только те привилегии, которые необходимы для выполнения его задач. Запуск контейнера от имени root нарушает этот принцип, предоставляя ему избыточные права.
Если в контейнере, запущенном от имени root, найдена уязвимость, злоумышленник может использовать ее для выполнения команд с привилегиями root на хосте, что может привести к серьезным нарушениям безопасности.
Контейнер, запущенный от имени root, может получить доступ к критически важным файлам хостовой системы, изменять их или удалять, что может привести к нарушению работы всей системы.
Использование непривилегированных пользователей:
В Dockerfile можно создать пользователя с ограниченными привилегиями и переключиться на него.
FROM ubuntu:20.04
RUN useradd -m myuser
USER myuser
CMD ["myapp"]
Использование флага --user:
При запуске контейнера можно использовать флаг
--user, чтобы указать непривилегированного пользователя.docker run --user 1000:1000 myapp
Использование механизмов безопасности Docker:
Использование профилей seccomp для ограничения системных вызовов.
Использование AppArmor или SELinux для ограничения доступа контейнеров к системным ресурсам.
Ставь 👍 и забирай 📚 Базу знаний
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2