Логи без боли: Как поднять централизованный сбор логов за 15 минут с Loki
Каждый админ знает эту рутину: ssh server1, grep /var/log/some.log, потом ssh server2, grep ... и так далее. Это медленно, неудобно, и почти невозможно сопоставить события с разных машин.
Многие слышали про стек ELK, но его сложность и ресурсоемкость отпугивают. Но есть современное решение — Grafana Loki.
▪️ Секретный соус Loki:
Главное отличие Loki от ELK: он не индексирует полное содержимое логов. Он индексирует только небольшой набор меток (labels), которые вы сами задаете (например: hostname="web01", app="nginx"). Сами строки логов сжимаются и хранятся как есть.
Аналогия: Представьте, что ELK — это поиск по содержанию всей книги, а Loki — это сверхбыстрый поиск по оглавлению и ярлыкам на полях.
▪️ Рецепт на 15 минут (с Docker Compose):
Этот docker-compose.yml поднимет весь необходимый стек: Loki для хранения, Promtail для сбора логов и Grafana для визуализации.
YAML
▪️ Что нужно сделать:
Сохраните текст выше в файл docker-compose.yml.
Рядом создайте файл promtail-config.yml (можно взять из нашего предыдущего поста про стек Observability).
Запустите: docker-compose up -d.
Откройте Grafana (http://localhost:3000), добавьте Loki как источник данных (http://loki:3100) и перейдите в раздел Explore.
Всё! Ваши логи с хост-машины уже там. Вы можете фильтровать их по меткам и искать нужные события со скоростью света. Это демократизация централизованного сбора логов, доступная каждому.
#Loki #Grafana #Observability #Logging #DevOps #Docker #SysAdmin
Каждый админ знает эту рутину: ssh server1, grep /var/log/some.log, потом ssh server2, grep ... и так далее. Это медленно, неудобно, и почти невозможно сопоставить события с разных машин.
Многие слышали про стек ELK, но его сложность и ресурсоемкость отпугивают. Но есть современное решение — Grafana Loki.
▪️ Секретный соус Loki:
Главное отличие Loki от ELK: он не индексирует полное содержимое логов. Он индексирует только небольшой набор меток (labels), которые вы сами задаете (например: hostname="web01", app="nginx"). Сами строки логов сжимаются и хранятся как есть.
Аналогия: Представьте, что ELK — это поиск по содержанию всей книги, а Loki — это сверхбыстрый поиск по оглавлению и ярлыкам на полях.
▪️ Рецепт на 15 минут (с Docker Compose):
Этот docker-compose.yml поднимет весь необходимый стек: Loki для хранения, Promtail для сбора логов и Grafana для визуализации.
YAML
version: "3"
networks:
loki:
services:
loki:
image: grafana/loki:latest
ports:
- "3100:3100"
command: -config.file=/etc/loki/local-config.yaml
networks:
- loki
promtail:
image: grafana/promtail:latest
volumes:
- /var/log:/var/log
- ./promtail-config.yml:/etc/promtail/config.yml
command: -config.file=/etc/promtail/config.yml
networks:
- loki
grafana:
image: grafana/grafana:latest
ports:
- "3000:3000"
networks:
- loki
▪️ Что нужно сделать:
Сохраните текст выше в файл docker-compose.yml.
Рядом создайте файл promtail-config.yml (можно взять из нашего предыдущего поста про стек Observability).
Запустите: docker-compose up -d.
Откройте Grafana (http://localhost:3000), добавьте Loki как источник данных (http://loki:3100) и перейдите в раздел Explore.
Всё! Ваши логи с хост-машины уже там. Вы можете фильтровать их по меткам и искать нужные события со скоростью света. Это демократизация централизованного сбора логов, доступная каждому.
#Loki #Grafana #Observability #Logging #DevOps #Docker #SysAdmin
Windows: Хватит кликать по Event Viewer! Фильтруем логи как профи с PowerShell
Журнал событий (Event Viewer) — мощный инструмент, но его графический интерфейс медленный и неудобный для поиска конкретных событий. Когда на сервере происходят тысячи событий в минуту, вам нужен скальпель, а не молоток.
Get-WinEvent — это ваш скальпель. Этот PowerShell-командлет позволяет мгновенно фильтровать и анализировать любые системные журналы.
Практические примеры:
Найти 10 последних ошибок в системном журнале:
PowerShell
Level=2 — это ошибки (Errors).
Найти все неудачные попытки входа (RDP/локальные) за последние 24 часа:
Это самый мощный способ — фильтрация через хеш-таблицу.
PowerShell
Проверить тот же лог на удалённом сервере:
Просто добавьте параметр -ComputerName.
PowerShell
Интерактивный поиск:
Для быстрой визуальной фильтрации отправьте результат в Out-GridView.
PowerShell
Откроется интерактивное окно, где можно сортировать и фильтровать события по любому полю.
Взгляд архитектора:
Умение быстро работать с логами из командной строки — это основа для создания систем автоматического реагирования. Скрипты на основе Get-WinEvent могут отправлять алерты в Telegram/Slack при появлении критических событий, собирать статистику для отчётов по безопасности и проводить аудит действий пользователей по всей инфраструктуре.
#windows #powershell #security #logging #audit #команды
Журнал событий (Event Viewer) — мощный инструмент, но его графический интерфейс медленный и неудобный для поиска конкретных событий. Когда на сервере происходят тысячи событий в минуту, вам нужен скальпель, а не молоток.
Get-WinEvent — это ваш скальпель. Этот PowerShell-командлет позволяет мгновенно фильтровать и анализировать любые системные журналы.
Практические примеры:
Найти 10 последних ошибок в системном журнале:
PowerShell
Get-WinEvent -LogName System -MaxEvents 10 -FilterXPath "*[System[Level=2]]"
Level=2 — это ошибки (Errors).
Найти все неудачные попытки входа (RDP/локальные) за последние 24 часа:
Это самый мощный способ — фильтрация через хеш-таблицу.
PowerShell
$StartTime = (Get-Date).AddDays(-1)
Get-WinEvent -FilterHashtable @{
LogName = 'Security'
Id = 4625 # ID события "An account failed to log on"
StartTime = $StartTime
} | Select-Object TimeCreated, Message
Проверить тот же лог на удалённом сервере:
Просто добавьте параметр -ComputerName.
PowerShell
Get-WinEvent -ComputerName DC01 -FilterHashtable @{LogName='Security'; Id=4625}
Интерактивный поиск:
Для быстрой визуальной фильтрации отправьте результат в Out-GridView.
PowerShell
Get-WinEvent -LogName Application | Out-GridView
Откроется интерактивное окно, где можно сортировать и фильтровать события по любому полю.
Взгляд архитектора:
Умение быстро работать с логами из командной строки — это основа для создания систем автоматического реагирования. Скрипты на основе Get-WinEvent могут отправлять алерты в Telegram/Slack при появлении критических событий, собирать статистику для отчётов по безопасности и проводить аудит действий пользователей по всей инфраструктуре.
#windows #powershell #security #logging #audit #команды
Linux: Вы всё ещё просто "листаете" логи? Раскрываем всю мощь less
Пятница, конец дня. Нужно быстро найти причину сбоя в лог-файле на несколько гигабайт. Все знают less, но большинство используют только стрелки и клавишу q. А ведь это мощнейший инструмент для анализа.
5 трюков, которые ускорят вашу работу:
F (Follow mode): Нажмите Shift + F в открытом файле. less перейдет в режим tail -f и будет показывать новые строки в реальном времени. Чтобы выйти из этого режима и вернуться к поиску, нажмите Ctrl + C.
/ и ? (Поиск): /слово — ищет "слово" от текущей позиции вниз. ?слово — ищет вверх. Клавиши n и N — переход к следующему/предыдущему совпадению.
& (Фильтрация): Введите & и паттерн (например, &ERROR). less скроет все строки, которые не содержат ERROR. Чтобы сбросить фильтр, введите & и нажмите Enter. Это как grep, но без выхода из файла.
m и ' (Метки): Находясь на важной строке (например, начало транзакции), нажмите m и любую букву (например, a). Вы создали метку "a". Теперь, промотав файл на тысячу строк вниз к ошибке, вы можете мгновенно вернуться к метке, нажав ' и ту же букву ('a).
-N (Номера строк): Запускайте less -N your_log_file.log, чтобы видеть номера строк. Незаменимо, когда обсуждаете лог с коллегой.
Взгляд архитектора:
Мастерство владения базовыми инструментами — признак профессионала. Способность быстро анализировать сырые данные напрямую на сервере, без тяжеловесных GUI, — это ключевой навык для эффективного траблшутинга и основа для построения более сложных систем observability.
#linux #less #cli #logging #команды #productivity
Пятница, конец дня. Нужно быстро найти причину сбоя в лог-файле на несколько гигабайт. Все знают less, но большинство используют только стрелки и клавишу q. А ведь это мощнейший инструмент для анализа.
5 трюков, которые ускорят вашу работу:
F (Follow mode): Нажмите Shift + F в открытом файле. less перейдет в режим tail -f и будет показывать новые строки в реальном времени. Чтобы выйти из этого режима и вернуться к поиску, нажмите Ctrl + C.
/ и ? (Поиск): /слово — ищет "слово" от текущей позиции вниз. ?слово — ищет вверх. Клавиши n и N — переход к следующему/предыдущему совпадению.
& (Фильтрация): Введите & и паттерн (например, &ERROR). less скроет все строки, которые не содержат ERROR. Чтобы сбросить фильтр, введите & и нажмите Enter. Это как grep, но без выхода из файла.
m и ' (Метки): Находясь на важной строке (например, начало транзакции), нажмите m и любую букву (например, a). Вы создали метку "a". Теперь, промотав файл на тысячу строк вниз к ошибке, вы можете мгновенно вернуться к метке, нажав ' и ту же букву ('a).
-N (Номера строк): Запускайте less -N your_log_file.log, чтобы видеть номера строк. Незаменимо, когда обсуждаете лог с коллегой.
Взгляд архитектора:
Мастерство владения базовыми инструментами — признак профессионала. Способность быстро анализировать сырые данные напрямую на сервере, без тяжеловесных GUI, — это ключевой навык для эффективного траблшутинга и основа для построения более сложных систем observability.
#linux #less #cli #logging #команды #productivity
👍2
Linux: Кто и когда заходил на сервер? Аудит сессий с last и lastlog
Расследование инцидентов и регулярный аудит безопасности начинаются с простого вопроса: кто получал доступ к системе? В Linux для этого есть два мощных, но часто недооцененных инструмента.
last — история успешных входов
Эта команда читает файл /var/log/wtmp и показывает, кто, когда и с какого IP-адреса заходил в систему.
Bash
Обращайте внимание на входы с незнакомых IP и сессии в нерабочее время.
lastlog — когда каждый пользователь логинился в последний раз
Эта команда проверяет файл /var/log/lastlog и показывает отчет по последнему входу для каждого пользователя в системе.
Bash
Это идеальный способ найти старые, заброшенные учетные записи, которые являются потенциальной угрозой безопасности.
Взгляд архитектора:
Логи доступа — это не просто текст, это данные для системы безопасности. Настоящий архитектор не смотрит их вручную. Он настраивает автоматический сбор этих логов в централизованную систему (SIEM, ELK Stack) и создает правила для алертов — например, "уведомить, если root залогинился не из консоли" или "уведомить о входе с IP-адреса, который не числится в белом списке".
#linux #security #audit #logging #lastlog #команды
Расследование инцидентов и регулярный аудит безопасности начинаются с простого вопроса: кто получал доступ к системе? В Linux для этого есть два мощных, но часто недооцененных инструмента.
last — история успешных входов
Эта команда читает файл /var/log/wtmp и показывает, кто, когда и с какого IP-адреса заходил в систему.
Bash
# Показать последние 15 логинов
last -n 15
# Показать полные IP-адреса и время
last -F -i
# Показать, кто был в системе в определенное время
last -t 2025-10-15T12:00:00
Обращайте внимание на входы с незнакомых IP и сессии в нерабочее время.
lastlog — когда каждый пользователь логинился в последний раз
Эта команда проверяет файл /var/log/lastlog и показывает отчет по последнему входу для каждого пользователя в системе.
Bash
# Показать отчет для всех пользователей
lastlog
# Найти пользователей, которые не логинились больше 90 дней
lastlog -b 90
Это идеальный способ найти старые, заброшенные учетные записи, которые являются потенциальной угрозой безопасности.
Взгляд архитектора:
Логи доступа — это не просто текст, это данные для системы безопасности. Настоящий архитектор не смотрит их вручную. Он настраивает автоматический сбор этих логов в централизованную систему (SIEM, ELK Stack) и создает правила для алертов — например, "уведомить, если root залогинился не из консоли" или "уведомить о входе с IP-адреса, который не числится в белом списке".
#linux #security #audit #logging #lastlog #команды
Journald Linux: Хватит grep-ать /var/log! Раскрываем мощь journalctl
Пятничный траблшутинг. Вы ищете ошибку, перебирая auth.log, syslog, messages и логи вашего приложения. Это долго и неудобно. В современных системах на systemd есть единый, структурированный журнал, и journalctl — ваш ключ к нему.
Почему journalctl лучше, чем tail и grep:
Централизация: Все логи (ядро, сервисы, система) в одном месте.
Структура: Логи хранятся не как текст, а как записи с метаданными (сервис, PID, приоритет).
Индексация: Поиск по времени или другим полям работает мгновенно.
Команды, которые сэкономят вам часы:
Фильтр по времени (самое важное при расследовании):
Bash
Фильтр по приоритету (отсекаем шум):
Bash
-b показывает логи с момента последней загрузки.
Логи конкретного сервиса в реальном времени:
Bash
Взгляд архитектора: journalctl — это не просто удобная утилита. Это локальный endpoint для системы Observability. Умение эффективно работать с ним — это базовый навык. Следующий шаг — настроить journald-forwarder (или аналог), который будет отправлять эти структурированные логи в централизованную систему вроде ELK Stack или Graylog для глобального анализа и корреляции событий.
#linux #systemd #journalctl #logging #sre #команды
Пятничный траблшутинг. Вы ищете ошибку, перебирая auth.log, syslog, messages и логи вашего приложения. Это долго и неудобно. В современных системах на systemd есть единый, структурированный журнал, и journalctl — ваш ключ к нему.
Почему journalctl лучше, чем tail и grep:
Централизация: Все логи (ядро, сервисы, система) в одном месте.
Структура: Логи хранятся не как текст, а как записи с метаданными (сервис, PID, приоритет).
Индексация: Поиск по времени или другим полям работает мгновенно.
Команды, которые сэкономят вам часы:
Фильтр по времени (самое важное при расследовании):
Bash
# Показать все логи за последние 10 минут
journalctl --since "10 min ago"
# Показать логи за конкретный промежуток времени
journalctl --since "2025-10-17 16:00:00" --until "2025-10-17 16:05:00"
Фильтр по приоритету (отсекаем шум):
Bash
# Показать только ошибки (err) и более критичные события
journalctl -p err -b
-b показывает логи с момента последней загрузки.
Логи конкретного сервиса в реальном времени:
Bash
# Следим за логами nginx
journalctl -f -u nginx.service
Взгляд архитектора: journalctl — это не просто удобная утилита. Это локальный endpoint для системы Observability. Умение эффективно работать с ним — это базовый навык. Следующий шаг — настроить journald-forwarder (или аналог), который будет отправлять эти структурированные логи в централизованную систему вроде ELK Stack или Graylog для глобального анализа и корреляции событий.
#linux #systemd #journalctl #logging #sre #команды
Windows: "Агент не нужен". Централизуем логи Windows с помощью WEF
У вас 50 серверов. На одном из них происходит инцидент. Вы подключаетесь по RDP и видите... пустой журнал событий. Злоумышленник всё почистил. Вы проиграли.
WEF (Windows Event Forwarding) — это "спящий гигант" безопасности в Windows. Это встроенный, агент-лесcный механизм, который позволяет собирать критические логи со всех машин в домене в одну точку (WEC - Windows Event Collector) в реальном времени.
Почему это уровень архитектора:
Безопасность: Атакующий не может почистить логи на сервере-коллекторе.
Надежность: Работает на уровне ОС. Никаких сторонних агентов, которые могут "упасть" или съесть ресурсы.
Гибкость: Вы можете подписаться только на то, что вам нужно (например, ID 4625 - неудачный вход, ID 4688 - создание процесса).
План внедрения "на пальцах":
На сервере-коллекторе (WEC): Запустите wecutil qc (Quick-Config).
На клиентах (GPO):
Включите службу WinRM (Windows Remote Management).
Настройте "Subscription Manager": [GPO] -> Policies -> Admin Templates -> Windows Components -> Event Forwarding.
Укажите адрес вашего сервера-коллектора.
На коллекторе: Создайте "Подписку" (Subscription), указав, с каких компьютеров и какие именно события вы хотите собирать.
Взгляд архитектора: WEF — это не просто сбор логов. Это фундамент для SIEM (Security Information and Event Management). Вы превращаете "слепые" серверы в прозрачную, наблюдаемую систему. Это первый и самый важный шаг к построению настоящего Security Operations Center (SOC).
#windows #security #wef #logging #activedirectory #architect #гайд
У вас 50 серверов. На одном из них происходит инцидент. Вы подключаетесь по RDP и видите... пустой журнал событий. Злоумышленник всё почистил. Вы проиграли.
WEF (Windows Event Forwarding) — это "спящий гигант" безопасности в Windows. Это встроенный, агент-лесcный механизм, который позволяет собирать критические логи со всех машин в домене в одну точку (WEC - Windows Event Collector) в реальном времени.
Почему это уровень архитектора:
Безопасность: Атакующий не может почистить логи на сервере-коллекторе.
Надежность: Работает на уровне ОС. Никаких сторонних агентов, которые могут "упасть" или съесть ресурсы.
Гибкость: Вы можете подписаться только на то, что вам нужно (например, ID 4625 - неудачный вход, ID 4688 - создание процесса).
План внедрения "на пальцах":
На сервере-коллекторе (WEC): Запустите wecutil qc (Quick-Config).
На клиентах (GPO):
Включите службу WinRM (Windows Remote Management).
Настройте "Subscription Manager": [GPO] -> Policies -> Admin Templates -> Windows Components -> Event Forwarding.
Укажите адрес вашего сервера-коллектора.
На коллекторе: Создайте "Подписку" (Subscription), указав, с каких компьютеров и какие именно события вы хотите собирать.
Взгляд архитектора: WEF — это не просто сбор логов. Это фундамент для SIEM (Security Information and Event Management). Вы превращаете "слепые" серверы в прозрачную, наблюдаемую систему. Это первый и самый важный шаг к построению настоящего Security Operations Center (SOC).
#windows #security #wef #logging #activedirectory #architect #гайд
👍2
Linux: grep — это не анализ. Считаем ошибки в логах как SRE с помощью awk
Ваш лог-файл access.log весит 5 ГБ. grep "ERROR" выдает 50 000 строк. Как понять, какая ошибка самая частая? Прокручивать less — это не работа.
awk — это не просто "еще один grep". Это полноценный язык обработки текста.
Задача: Найти ТОП-10 самых частых ошибок в error.log.
Решение в одну строку:
Bash
Эта команда — ваш персональный анализатор логов. Она мгновенно покажет, какая именно ошибка "флудит" в логах, позволяя вам сфокусироваться на причине, а не на поиске.
Взгляд архитектора: Админ ищет одну ошибку. Архитектор ищет паттерны. awk в связке с sort и uniq — это базовый инструмент SRE-инженера для агрегации данных. Он позволяет превратить гигабайты хаотичных логов в осмысленную статистику для принятия решений.
#linux #awk #logging #sre #bash #команды #cli
Ваш лог-файл access.log весит 5 ГБ. grep "ERROR" выдает 50 000 строк. Как понять, какая ошибка самая частая? Прокручивать less — это не работа.
awk — это не просто "еще один grep". Это полноценный язык обработки текста.
Задача: Найти ТОП-10 самых частых ошибок в error.log.
Решение в одну строку:
Bash
# Ищем строки со словом "error", вытаскиваем текст ошибки (предполагаем, что он после 5-го поля),
# считаем уникальные строки и сортируем по количеству.
grep -i "error" /var/log/nginx/error.log | \
awk -F' ' '{ $1=""; $2=""; $3=""; $4=""; $5=""; print $0 }' | \
sort | \
uniq -c | \
sort -nr | \
head -n 10
Эта команда — ваш персональный анализатор логов. Она мгновенно покажет, какая именно ошибка "флудит" в логах, позволяя вам сфокусироваться на причине, а не на поиске.
Взгляд архитектора: Админ ищет одну ошибку. Архитектор ищет паттерны. awk в связке с sort и uniq — это базовый инструмент SRE-инженера для агрегации данных. Он позволяет превратить гигабайты хаотичных логов в осмысленную статистику для принятия решений.
#linux #awk #logging #sre #bash #команды #cli
Windows: "Журнал переполнен!" Как управлять Event Log'ами на 100+ серверах
"На сервере SRV-APP01 переполнен журнал Application". Классический тикет в понедельник.
Реакция админа: Подключиться по RDP, открыть Event Viewer, нажать "Clear Log..." (и уничтожить все улики инцидента).
Реакция архитектора: Настроить централизованное управление журналами, чтобы они никогда не переполнялись и никогда не терялись.
Для этого не нужны агенты. Используем встроенный wevtutil (Windows Event Utility).
Команда, чтобы узнать текущий конфиг:
PowerShell
Команда, чтобы настроить "по-умному": Это "золотой стандарт" для серверов.
PowerShell
Теперь журнал Application никогда не "переполнится". Он будет автоматически бэкапиться в %SystemRoot%\System32\Winevt\Logs в формате .evtx, и логирование продолжится.
Взгляд архитектора: Вы не просто "исправили" проблему на одном сервере. Вы разработали стандарт. Этот стандарт "заворачивается" в GPO (через Preferences) или в Ansible/PowerShell DSC и применяется ко всему парку серверов, гарантируя, что у вас всегда будут логи для расследования (IR) и аудита.
#windows #logging #security #powershell #sysadmin #гайд
"На сервере SRV-APP01 переполнен журнал Application". Классический тикет в понедельник.
Реакция админа: Подключиться по RDP, открыть Event Viewer, нажать "Clear Log..." (и уничтожить все улики инцидента).
Реакция архитектора: Настроить централизованное управление журналами, чтобы они никогда не переполнялись и никогда не терялись.
Для этого не нужны агенты. Используем встроенный wevtutil (Windows Event Utility).
Команда, чтобы узнать текущий конфиг:
PowerShell
# Показывает размер, политику хранения
wevtutil get-log "Application"
Команда, чтобы настроить "по-умному": Это "золотой стандарт" для серверов.
PowerShell
# /rt:true - Включаем хранение (Retention).
# /ab:true - Включаем AutoBackup. Лог будет архивироваться при заполнении.
# /ms:1024m - Устанавливаем максимальный размер в 1ГБ.
wevtutil set-log "Application" /rt:true /ab:true /ms:1024m
Теперь журнал Application никогда не "переполнится". Он будет автоматически бэкапиться в %SystemRoot%\System32\Winevt\Logs в формате .evtx, и логирование продолжится.
Взгляд архитектора: Вы не просто "исправили" проблему на одном сервере. Вы разработали стандарт. Этот стандарт "заворачивается" в GPO (через Preferences) или в Ansible/PowerShell DSC и применяется ко всему парку серверов, гарантируя, что у вас всегда будут логи для расследования (IR) и аудита.
#windows #logging #security #powershell #sysadmin #гайд
👍2
🪟 Windows: PowerShell Transcription — включаем «Черный ящик» 🎙️
Кто-то зашел на сервер под общей админкой, что-то нажал, и всё сломалось?
Логи Windows (Event Viewer) часто не показывают, какую именно команду ввели.
В 2026 году мы включаем PowerShell Transcription.
Это функция, которая записывает весь ввод и вывод консоли в текстовый файл.
Как включить для текущей сессии (или добавить в $PROFILE):
Как включить глобально через Group Policy (GPO):
Computer Configuration -> Administrative Templates -> Windows Components -> Windows PowerShell -> Turn on PowerShell Transcription.
Ты получаешь полный текстовый лог: кто зашел, какую команду вбил и (главное!) какую ошибку получил в ответ.
Это лучший инструмент для разбора полетов. 🕵️♂️
#windows #powershell #security #auditing #sysadmin #logging #forensics
Кто-то зашел на сервер под общей админкой, что-то нажал, и всё сломалось?
Логи Windows (Event Viewer) часто не показывают, какую именно команду ввели.
В 2026 году мы включаем PowerShell Transcription.
Это функция, которая записывает весь ввод и вывод консоли в текстовый файл.
Как включить для текущей сессии (или добавить в $PROFILE):
Start-Transcript -Path "C:\AdminLogs\Session_$(get-date -f yyyyMMdd_HHmm).txt" -NoClobber
Как включить глобально через Group Policy (GPO):
Computer Configuration -> Administrative Templates -> Windows Components -> Windows PowerShell -> Turn on PowerShell Transcription.
Ты получаешь полный текстовый лог: кто зашел, какую команду вбил и (главное!) какую ошибку получил в ответ.
Это лучший инструмент для разбора полетов. 🕵️♂️
#windows #powershell #security #auditing #sysadmin #logging #forensics
🔥2👍1👏1
🔍 ELK vs Loki: Как не утонуть в логах и не разорить компанию на дисках
Логи — это «черный ящик» твоего сервера. Но когда серверов 50, а контейнеров 500, смотреть их по отдельности невозможно.
Нужно решение, которое соберет всё в одну кучу и даст удобный поиск.
🏛️ ELK Stack (Elasticsearch, Logstash, Kibana)
Это «золотой стандарт» индустрии.
Пример конфига Logstash (Input/Filter):
⚡ Grafana Loki
«Prometheus для логов». В 2026 году Loki стал выбором номер один для Kubernetes и облачных сред.
Пример конфига Promtail (агент Loki):
---
📊 Что выбрать сисадмину?
| Характеристика | ELK (Elasticsearch) | Loki |
| --- | --- | --- |
| Индексация | Полный текст (Full-text) | Только метки (Labels) |
| Потребление RAM | Очень высокое | Низкое |
| Стоимость хранения | Дорого (нужны быстрые диски) | Дешево (S3/MinIO) |
| Сложность настройки | Высокая | Средняя |
| Лучшее применение | Анализ бизнес-данных, аудит | Технический мониторинг, K8s |
Вердикт Admin Future: Если тебе нужно быстро грепать логи из контейнеров и ты не хочешь тратить на сервер мониторинга больше ресурсов, чем на сами сервисы — ставь Loki. Если же ты работаешь в банке или крупном e-commerce, где нужно строить сложные дашборды по каждой транзакции — твой выбор ELK.
#logging #elk #loki #grafana #devops #sysadmin #monitoring #admin_future
Логи — это «черный ящик» твоего сервера. Но когда серверов 50, а контейнеров 500, смотреть их по отдельности невозможно.
Нужно решение, которое соберет всё в одну кучу и даст удобный поиск.
🏛️ ELK Stack (Elasticsearch, Logstash, Kibana)
Это «золотой стандарт» индустрии.
* Философия: Индексируем абсолютно каждое слово в каждой строке лога.
* Плюсы: Мгновенный полнотекстовый поиск. Мощнейшая аналитика и визуализация. Ты можешь найти ошибку в конкретном запросе среди миллиарда записей за доли секунды.
* Минусы: Прожорливость. Elasticsearch обожает оперативную память (RAM) и «кушает» её гигабайтами. Индексы занимают много места на диске.
Пример конфига Logstash (Input/Filter):
input {
beats { port => 5044 }
}
filter {
grok { match => { "message" => "%{COMBINEDAPACHELOG}" } }
}
output {
elasticsearch { hosts => ["localhost:9200"] }
}
⚡ Grafana Loki
«Prometheus для логов». В 2026 году Loki стал выбором номер один для Kubernetes и облачных сред.
* Философия: Мы не индексируем текст. Мы индексируем только метаданные (метки: имя сервера, имя контейнера, уровень лога). Сами логи сжимаются и лежат в дешевом объектном хранилище (S3).
* Плюсы: Потребляет в 10 раз меньше ресурсов, чем Elasticsearch. Идеально интегрируется в Grafana рядом с метриками. Хранение стоит копейки.
* Минусы: Поиск по самому тексту лога (grep) медленнее, чем в ELK, так как системе приходится «на лету» распаковывать чанки данных.
Пример конфига Promtail (агент Loki):
scrape_configs:
- job_name: system
static_configs:
- targets: [localhost]
labels:
job: varlogs
__path__: /var/log/*.log
---
📊 Что выбрать сисадмину?
| Характеристика | ELK (Elasticsearch) | Loki |
| --- | --- | --- |
| Индексация | Полный текст (Full-text) | Только метки (Labels) |
| Потребление RAM | Очень высокое | Низкое |
| Стоимость хранения | Дорого (нужны быстрые диски) | Дешево (S3/MinIO) |
| Сложность настройки | Высокая | Средняя |
| Лучшее применение | Анализ бизнес-данных, аудит | Технический мониторинг, K8s |
Вердикт Admin Future: Если тебе нужно быстро грепать логи из контейнеров и ты не хочешь тратить на сервер мониторинга больше ресурсов, чем на сами сервисы — ставь Loki. Если же ты работаешь в банке или крупном e-commerce, где нужно строить сложные дашборды по каждой транзакции — твой выбор ELK.
#logging #elk #loki #grafana #devops #sysadmin #monitoring #admin_future
❤2