TDP — не термометр і не ватметр

TDP (Thermal Design Power) звучить як вимір. Виглядає як вимір. Люди цитують його як вимір. У ноутбуках це часто не вимір тієї потужності, яку ви побачите на розетці, батареї або навіть у пакеті процесора під вашим навантаженням.

Насправді «TDP» у ноутбуках зазвичай — це ярлик для термального контуру процесора за певних визначених умов, які можуть не співпадати з вашими умовами, охолодженням ноутбука або вибором прошивки вендора. У CPU є внутрішня модель потужності та температури, прошивка встановлює ліміти, а ОС запитує продуктивність. Єдине, що гарантує «TDP», — це те, що хтось про це проводив нараду.

Що TDP має представляти

Історично TDP використовували системні дизайнери для підбору охолодження: радіаторів, вентиляторів, отворів та повітряного потоку корпусу. Мета була не «максимальна потужність», а «тепло, яке потрібно відвести під час тривалого навантаження, яке цікавить виробника». Ця тонка різниця важлива: тривале, визначене навантаження — правила визначає виробник.

Що покупці ноутбуків думають, що це означає

• Обіцянка стабільної тривалої продуктивності.
• Обіцянка максимального енергоспоживання.
• Замінник для «цей CPU швидший за той CPU».
• Гарантія, що два ноутбуки з однаковим CPU працюватимуть схоже.

Лише одне з цього інколи виявляється правдою, та й то випадково.

У що TDP часто перетворюється в ноутбуках

Він стає маркетинговою міткою для бінування сімейства CPU: «U-series — енергоефективні», «H-series — швидкі», «HX — як десктоп». Далі OEM встановлюють власні тривалі й імпульсні ліміти, щоб вміститися в корпус, цілі по батареї, шуму та продуктовій сегментації. Чіп може підтримувати 60–90W імпульси, але ноутбук може дозволяти це 10 секунд, 28 секунд або «поки користувач не відкриє Slack».

Жарт №1: TDP ноутбука — як прогноз погоди: технічно виведений моделями, але все ще не той параметр, на який варто ставити поїздку.

Як ми дійшли до цього: повільний дрейф TDP від інженерії до вражень

Ноутбучні CPU не стали оманливими за одну ніч. Індустрія еволюціонувала в напрямку, де CPU регулярно перевищують свої «базові» термальні контори, а OEM агресивно налаштовують під тонкість корпусу та тривалість роботи від батареї. Проблема в тому, що технічний лист не перетворився на щось, чим може користуватися споживач.

Цікаві факти та історичний контекст (коротко, по суті)

1. Turbo boost зробив «базову потужність» політично незручною. Коли CPU почали підвищувати частоти при можливості, «типова потужність» перестала бути стабільною.
2. Модель обмежень Intel (PL1/PL2/Tau) нормалізувала імпульсну потужність. Тривала потужність і короткочасна стали окремими ручками, а не одним числом.
3. Мобільні рішення просунули інтеграцію. Інтегровані GPU і контролери пам’яті означають, що пакетна потужність CPU — це не лише ядра, тому суміші навантажень дуже різняться.
4. Дизайн thin-and-light став пріоритетним. Багато ноутбуків розробляються з огляду на шум і товщину, а обмеження потужності підлаштовуються потім.
5. Продуктова сегментація OEM — реальна. Дві моделі з одним CPU можуть навмисно мати різні тривалі обмеження, щоб зберегти цінову ієрархію.
6. Батарея та VRM мають значення. Ноутбук може не бути в змозі подавати велику потужність від батареї без провалу напруги, нагріву або ризику зносу.
7. Температура поверхні і комфорт користувача стали обмеженнями. «Не обпекти користувача» — дизайн-ліміт; він часто важливіший за «взяти хороший бенчмарк».
8. Переключення Windows на «Найкращу продуктивність» змінило очікування користувачів. Профілі енергоспоживання ОС можуть перемикати поведінку PL1/PL2, не пояснюючи цього простими словами.
9. Платформні обмеження (адаптер, USB-C PD) стали звичними вузькими місцями. 65W адаптер USB-C може обмежувати «45W» CPU, коли інші компоненти теж відбирають свою частку.

Неприємна правда: виробник CPU може опублікувати одне число, але ваш ноутбук — це переговори між прошивкою, тепловими властивостями та корпоративним бажанням не робити канібалізацію «Pro» моделі.

Справжні регулятори: PL1, PL2, Tau, cTDP та інші

Якщо ви хочете реальності, ігноруйте TDP і вивчіть контрольну площину. Різні вендори називають речі по-різному, але структура схожа: тривале лімітування потужності, короткочасний імпульсний ліміт і теплові обмеження, що переважають усе інше.

PL1: бюджет тривалої потужності

PL1 зазвичай означає «довготривалу» потужність. Ноутбук може працювати в цьому режимі невизначено довго якщо охолодження це підтримує. OEM часто ставлять PL1 нижче заявленого «класу TDP», бо орієнтуються на акустику, батарею або температуру корпусу.

В реальному світі: PL1 — це число, яке керує вашим 10-хвилинним компілюванням, довгим рендером, тривалими симуляціями і вашими скаргами «чому після першої хвилини ноутбук повільніший?».

PL2: бюджет короткочасного бусту

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

PL2 може бути у 2–3× вищим за PL1 у деяких конструкціях. Це не шахрайство. Це суть. Брехня виникає, коли маркетинг натякає, що поведінка під імпульсом — це тривала поведінка.

Tau: часове вікно (те, про що всі забувають)

Tau — це фактично «наскільки довго ми можемо вдавати, що ми десктоп?» Воно визначає, як довго можна використовувати PL2 перед спадом до PL1. Деякі ноутбуки відвантажуються з довгим Tau для конкуренції в бенчмарках. Інші тримають його коротким, щоб уникнути перегріву та стрибків шуму.

cTDP / конфігуровані діапазони потужності

Багато мобільних CPU підтримують конфігуровані діапазони: 12–15W, 15–28W, 35–45W тощо. Цей діапазон не означає, що ви отримуєте «CPU на 28W». Це означає, що CPU здатний працювати в різних контурах залежно від налаштувань OEM.

Якщо ви бачите однаковий CPU в різних ноутбуках з дуже різною продуктивністю, це дев’ять разів з десяти — причина.

Теплове троттлінг проти обмежень потужності

Люди звинувачують «тепловий троттлінг» у всьому, але першим лімітером часто є обмеження потужності. CPU може ніколи не досягати свого жорсткого теплового максимуму; його можуть просто тримати на низькому PL1, бо OEM хоче тихішу роботу вентилятора.

Ця різниця важлива, бо виправлення відрізняються:

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

Погляд спеціаліста з надійності на керування живленням у ноутбуках

У виробничих системах ви припускаєте існування контуру керування. У ноутбуках їх кілька: DVFS CPU, логіка вентилятора вбудованого контролера, енергоплани ОС і інколи служби вендора, що конфліктують між собою. Ви не «встановлюєте TDP». Ви керуєте системою обмежень.

Одна цитата з операцій підходить сюди. Ось перефразована ідея від Werner Vogels (CTO Amazon): перефразована ідея: усе ламається, і ви повинні проектувати та експлуатувати так, ніби відмови нормальні.

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

Ноутбук — це продукт (CPU лише пасажир)

Два ноутбуки можуть мати один і той же модель CPU і при цьому поводитися як різні види. Бо CPU — не система. Система — це: пропускна здатність охолодження, маса радіатора, якість парової камери, конструкція вентилятора, геометрія впуску/випуску повітря, налаштування прошивки, дизайн VRM, потужність адаптера і чи OEM тихцем обмежив продуктивність на батареї.

Охолодження: стійкий стан важливіший за пікові графіки

Продуктивність охолодження — це про стійке відведення тепла. Тонкий ноутбук може поглинути імпульс (теплова маса), але не зможе підтримувати його без повітряного потоку та площі ребер. Коли рецензенти запускають короткий бенчмарк, перший прогін — «медовий місяць». Десятий прогін — «одруження».

Енергопостачання і обмеження адаптера

«45W CPU» в системі з 65W USB-C PD адаптером вже веде переговори з GPU, екраном, SSD і зарядкою. Під навантаженням система може:

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

Режим батареї — своя всесвіт

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

Програмне забезпечення вендора і «AI режими енергоспоживання»

Утиліти вендора можуть перевизначати політику ОС, притискати PL1 у «тихому режимі» або змінювати ліміти в залежності від активної програми. Іноді вони це роблять добре. Іноді — щоб вписатися у сертифікацію за шумом. У будь‑якому разі, ви маєте знати, хто керує.

Жарт №2: Криву вентилятора ноутбука спроектував хтось, хто вважає, що «тихо» означає «дати CPU страждати мовчки».

Режими відмов, які ви реально можете діагностувати

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

1) Короткий буст, потім провал

Схема: швидко 10–60 секунд, потім частоти падають і не повертаються.

Ймовірна причина: PL2 дозволений, але PL1 низький, або охолодження насичується і змушує низький тривалий стан.

Рішення: якщо потрібна тривала продуктивність, обирайте товстіший корпус або модель, відому вищою тривалою потужністю, а не вищим рекламним класом TDP.

2) Завжди повільно, навіть з початку

Схема: ніколи сильно не бустить.

Ймовірна причина: ОС у режимі енергозбереження, вендорський «тихий режим», обмеження на батареї, низька потужність адаптера або застряглий датчик температури / проблема вентилятора.

Рішення: перевірте джерело живлення та енергоплан у першу чергу; тільки потім шукайте проблеми з охолодженням.

3) Продуктивність дуже змінюється день у день

Схема: іноді чудово, іноді жахливо — без змін у навантаженні.

Ймовірна причина: фонове ПЗ, завдання оновлення Windows, служби вендора, що перемикають режими, накопичений пил, температура навколишнього середовища або нестабільне підключення/докування.

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

4) Підключено до мережі, але все одно сильний троттлінг

Схема: «режим AC», але потужність обмежена як на батареї.

Ймовірна причина: адаптер не розпізнано, USB-C PD погодив нижчу потужність, пошкоджений кабель або помилка прошивки, що примушує політику батареї.

Рішення: підтвердіть погоджену потужність та чи заряджається батарея під навантаженням.

5) CPU не є вузьким місцем

Схема: частоти в нормі, але завдання все одно повільні.

Ймовірна причина: тиск на пам’ять, обмеження по вводу/виводу диска, фонове шифрування диска або тепловий троттлінг SSD.

Рішення: доведіть, що CPU завантажений, перш ніж звинувачувати «TDP бреше».

Швидкий план діагностики

Коли хтось каже «цей ноутбук повільний», не починайте з перезапису термопасти. Не купуйте кулер. Не запускайте годинний набір бенчмарків. Вам потрібна 10‑хвилинна тріяж‑перевірка, яка ізолює домінантний лімітатор.

Перше: підтвердьте джерело живлення та політику

• Чи машина на батареї, від мережі чи на док-станції?
• Чи дійсно вона заряджається під навантаженням?
• Чи ОС у обмежувальному енергоплані?
• Чи ПЗ вендора примушує «тихий» або «еко» режим?

Друге: спостерігайте за лімітами під час тривалого навантаження

• Спостерігайте пакетну потужність CPU у часі (не лише піки).
• Слідкуйте за частотою і температурою разом.
• Шукайте індикатори «обмеження по потужності» проти «теплового троттлінгу».

Третє: перевірте решту системи на предмет реального вузького місця

• Тиск на пам’ять і активність swap.
• Пропускна здатність і затримки диска під навантаженням.
• Завантаження GPU, якщо навантаження делегується.
• Фонові процеси, що крадуть час CPU.

Четверте: вирішіть, чи це виправити або це невідповідність продукту

Якщо ноутбук поводиться так, як задумано (низький PL1 заради тихості), іноді можна підкоригувати налаштування. Але часто «виправлення» — це вибір ноутбука, спроєктованого для тривалої потужності. Це жорстко, але дешевше за тижні фрустрації.

Практичні завдання: команди, виводи та рішення

Це реальні, виконувані перевірки. Я використовую приклади з Linux, бо вони спостережувані і скриптуються. Метод важливіший за ОС.

Завдання 1: Ідентифікувати модель CPU та базові характеристики

cr0x@server:~$ lscpu | sed -n '1,25p'
Architecture:                         x86_64
CPU op-mode(s):                       32-bit, 64-bit
Model name:                           13th Gen Intel(R) Core(TM) i7-13700H
CPU(s):                               20
Thread(s) per core:                   2
Core(s) per socket:                   14
CPU max MHz:                          5000.0000
CPU min MHz:                          400.0000

Що це означає: Підтверджує CPU і заявлену максимальну частоту. Це нічого не говорить про тривалу продуктивність, але налаштовує очікування щодо поведінки бусту.

Рішення: Якщо це «U» частина в тонкому корпусі й ви очікуєте поведінку робочої станції, зупиніться і відкоригуйте очікування, перш ніж ганятися за примарами.

Завдання 2: Підтвердити драйвер і режим governor (Linux)

cr0x@server:~$ cpupower frequency-info | sed -n '1,40p'
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  hardware limits: 400 MHz - 5.00 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 400 MHz and 5.00 GHz.
                  The governor "powersave" may decide which speed to use

Що це означає: З intel_pstate «powersave» часто є нормальним режимом і все ще дозволяє турбо, але його можна впливати через EPP/energy bias.

Рішення: Якщо ви діагностуєте продуктивність, тимчасово примусьте «performance», щоб прибрати одну змінну.

Завдання 3: Тимчасово переключити governor на performance (діагностика)

cr0x@server:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3

Що це означає: Ви просите ОС віддавати пріоритет продуктивності. Це не обійде PL1/PL2 у прошивці, але допомагає показати, що платформа може зробити.

Рішення: Якщо продуктивність значно покращиться, ваша проблема — політика, а не охолодження. Потім вирішіть, чи ви готові терпіти вплив на батарею/шум.

Завдання 4: Слідкувати за частотою і температурою в реальному часі

cr0x@server:~$ sudo turbostat --quiet --interval 2
     CPU     Avg_MHz   Busy%   Bzy_MHz  TSC_MHz  CoreTmp  PkgTmp  PkgWatt
       -       3120    92.15     3385     1896     86.0    90.0    44.72
       -       2650    99.02     2675     1896     92.0    96.0    28.11
       -       2580    99.11     2600     1896     94.0    97.0    24.95

Що це означає: Ви бачите класичний малюнок: висока пакетна потужність спочатку, потім спад (часто до PL1), поки температура наближається до межі.

Рішення: Якщо PkgWatt падає при високих температурах, ви або термально обмежені, або прошивка примушує нижчу тривалу потужність, щоб уникнути нагріву корпусу.

Завдання 5: Запустити тривале навантаження CPU, щоб виявити поведінку PL1

cr0x@server:~$ stress-ng --cpu 0 --timeout 180s --metrics-brief
stress-ng: info:  [23110] dispatching hogs: 20 cpu
stress-ng: metrc: [23110] stressor       bogo ops real time  usr time  sys time   bogo ops/s
stress-ng: metrc: [23110] cpu            3154210    180.00   1790.22    12.11     17523.39

Що це означає: 3‑хвилинне тривале навантаження достатнє для багатьох ноутбуків, щоб вийти з PL2 і влаштуватися в стійкі межі.

Рішення: Поєднуйте з turbostat. Якщо ви бачите спад після 28–60 секунд, це ваша тривала реальність.

Завдання 6: Перевірити лічильники енергії Intel RAPL (телеметрія потужності)

cr0x@server:~$ sudo powercap-info -p intel-rapl
Zone 0
  Name: package-0
  Enabled: yes
  Energy: 879.23 J
  Max energy range: 262143.99 J
Zone 0 subzone 0
  Name: core
  Energy: 522.17 J
Zone 0 subzone 1
  Name: uncore
  Energy: 101.55 J
Zone 0 subzone 2
  Name: dram
  Energy: 87.49 J

Що це означає: Лічильники RAPL дозволяють оцінити середню потужність за інтервал часу, знімаючи енергію до/після.

Рішення: Якщо енергія пакета збільшується повільно під тривалим навантаженням, платформа нав’язує низький ліміт потужності незалежно від «TDP».

Завдання 7: Шукати повідомлення про теплові та енергетичні ліміти в логах ядра

cr0x@server:~$ sudo dmesg | egrep -i 'thrott|thermal|pstate|rapl|power limit' | tail -n 15
intel_rapl_common: Found RAPL domain package
thermal thermal_zone7: critical temperature reached (105 C), shutting down
intel_pstate: turbo disabled by BIOS or unavailable on processor

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

Рішення: Якщо бачите «turbo disabled by BIOS», припиніть налагодження на рівні ОС — ваш лімітатор — політика прошивки.

Завдання 8: Перевірити теплові зони та температури

cr0x@server:~$ for z in /sys/class/thermal/thermal_zone*/type; do echo -n "$(basename $(dirname $z)) "; cat $z; done | head
thermal_zone0 x86_pkg_temp
thermal_zone1 acpitz
thermal_zone2 INT3400 Thermal

cr0x@server:~$ cat /sys/class/thermal/thermal_zone0/temp
94000

Що це означає: Температури часто в міліградусах Цельсія. 94000 означає 94°C.

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

Завдання 9: Перевірити, чи є свап (тиск на пам’ять, що маскується як повільність CPU)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            32Gi        29Gi       1.1Gi       1.2Gi       2.3Gi       1.9Gi
Swap:            8Gi       6.5Gi       1.5Gi

Що це означає: Інтенсивне використання свапу може робити «операції CPU» повільними, бо все чекає на диск.

Рішення: Якщо свап активний під час збірок, VM або контейнерів, ваша «TDP-проблема» може бути фактично «недостатньо ОЗП».

Завдання 10: Переконатись, що сховище не є вузьким місцем (NVMe)

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0 (laptop) 	01/12/2026 	_x86_64_	(20 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          35.12    0.00    6.21   22.18    0.00   36.49

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await wareq-sz  aqu-sz  %util
nvme0n1          92.0   8120.0     0.0    0.00   12.10    88.26    41.0   6240.0    18.33   152.20    1.22  96.00

Що це означає: Високе %iowait і майже насичена %util означають, що диск зайнятий; CPU може чекати.

Рішення: Якщо ввід/вивід — лімітатор, підвищення лімітів потужності CPU не допоможе. Виправте сховище (швидший SSD, уникати теплового троттлінгу, знизити write amplification) або зменшіть I/O‑навантаження.

Завдання 11: Перевірити температуру NVMe диска (троттлінг SSD може виглядати як троттлінг CPU)

cr0x@server:~$ sudo nvme smart-log /dev/nvme0 | egrep -i 'temperature|warning'
temperature                             : 72 C
warning_temp_time                       : 3
critical_temp_time                      : 0

Що це означає: SSD при 72°C з time warning натякає на можливі періодичні троттлінги, особливо в тонких ноутбуках з поганим охолодженням над SSD.

Рішення: Якщо warning time зростає під час збірок, додайте теплопровідну прокладку/радіатор або зменшіть тривалі записи (наприклад, перенесіть каталог збірки в tmpfs, якщо ОЗП дозволяє).

Завдання 12: Перевірити, чи є CPU‑throttling у cgroup (контейнери ускладнюють усе)

cr0x@server:~$ cat /sys/fs/cgroup/user.slice/user-1000.slice/cpu.stat 2>/dev/null | head
usage_usec 928381223
user_usec  812332110
system_usec 116049113
nr_periods  22990
nr_throttled 1420
throttled_usec 91822111

Що це означає: Якщо nr_throttled високе, планувальник обмежує використання CPU через квоти cgroup, а не через енергетичні ліміти CPU.

Рішення: Виправте ліміти контейнерів (Docker/Kubernetes CPU quota) перш ніж звинувачувати теплові обмеження ноутбука.

Завдання 13: Перевірити стан адаптера/батареї (у Linux через upower)

cr0x@server:~$ upower -i /org/freedesktop/UPower/devices/battery_BAT0 | egrep -i 'state|percentage|energy-rate|time to'
  state:               charging
  percentage:          83%
  energy-rate:         28.1 W
  time to full:        0.9 hours

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

Рішення: Якщо стан змінюється на «discharging» під навантаженням при підключеному адаптері, ваш адаптер/док — лімітатор. Підвищте потужність адаптера або уникайте цього дока для важких навантажень.

Завдання 14: Перевірити поведінку холостого ходу CPU (фонове навантаження краде буст)

cr0x@server:~$ top -b -n 1 | head -n 15
top - 12:18:02 up  2:41,  1 user,  load average: 6.21, 5.90, 4.40
Tasks: 412 total,   3 running, 409 sleeping,   0 stopped,   0 zombie
%Cpu(s): 26.2 us,  6.3 sy,  0.0 ni, 63.1 id,  4.1 wa,  0.0 hi,  0.3 si,  0.0 st
MiB Mem :  31890.8 total,   1220.4 free,  29401.1 used,   1269.3 buff/cache
MiB Swap:   8192.0 total,   1581.2 free,   6610.8 used.   1820.2 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 4121 cr0x      20   0 5429812 617148  82192 R  182.3   1.9   5:21.83 chrome
 8892 cr0x      20   0 2916420 501120  61444 S   78.1   1.5   2:11.20 docker

Що це означає: Фоновий CPU і тиск пам’яті можуть не давати процесору заходити в глибокі стани простою і зменшувати запас для бусту, особливо на теплово обмежених системах.

Рішення: Якщо «idle» не є справжнім простоєм, виправте фонові процеси перед тим, як звинувачувати обмеження CPU.

Три корпоративні міні-історії з передової обмежень потужності

Міні-історія 1: Інцидент через хибне припущення

Команда закупила флот «стандартних ноутбуків для розробників» для нового внутрішнього билд-сервісу, що запускав локальні компіляції, юніт‑тести і збірки контейнерів. Рішення про покупку було прийнято за простим рубриком: останнє покоління CPU, «клас 45W», 32GB RAM, хороша клавіатура. Машини на папері виглядали однаково. Закупівля була в захваті. Інженери — менш задоволені.

За тиждень часи збірки різко розійшлися. Дехто завершував повну збірку у прийнятний термін; інші потребували майже вдвічі більше часу. Повільні машини не були зламані. Вони не були заражені шкідливим ПЗ. Вони навіть не були особливо гарячі. Вони просто були зафіксовані на нижчому тривалому ліміті потужності, бо ті одиниці мали тонший корпус і тише спрямований акустичний профіль.

Хибне припущення було тонким: «однакова модель CPU = однакова продуктивність». Це працювало в десктопному світі. Воно провалилось у ноутбучному, бо тривала оболонка CPU — це фактично рішення OEM. Мітка «45W» не описувала те, що ноутбуки могли утримувати; вона описувала, що CPU теоретично можна налаштувати.

Виправлення було нудним і дорогим: стандартизувати конкретну модель ноутбука, а не CPU SKU, і кваліфікувати її тестом зі стабільною 10‑хвилинною завантаженістю як частину приймання. Також оновили внутрішню форму запиту обладнання, щоб включити «стабільну пакетну потужність під навантаженням», бо це складніше підробити, ніж «TDP».

Міні-історія 2: Оптимізація, що обернулась проти

Інженер, що стежив за продуктивністю, вирішив «полагодити» повільні CI‑подібні навантаження на ноутбуках, примусивши максимальні режими продуктивності по всьому флоту. Зміни були впроваджені як конфігурація: встановити governor на performance, відключити агресивні енергозбереження і зробити вентилятори більш активними. Короткі бенчмарки покращилися відразу, і інженер отримав кілька вдячних повідомлень.

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

Більшим сюрпризом став досвід розробників: ноутбуки стали голосні в відкритих просторах, і люди почали перемикати «тихі» режими вендора, щоб справлятися. Це тихо повернуло низькі PL1 і непослідовну продуктивність. Оптимізація створила двокласову систему: ті, хто терпіли шум — отримали швидкість, інші — непередбачуваність.

Урок: примусовий режим продуктивності по всьому флоту лікує симптом (короткочасну швидкість) і ігнорує цільову функцію системи (батарея, акустика, теплові режими, довговічність). Більш правильний підхід — надати документований профіль «важкого навантаження», в який інженери можуть добровільно ввімкнутися при підключенні до мережі, і вимірювати тривалу продуктивність замість гонитви за піковим турбо.

Міні-історія 3: Нудна, але правильна практика, що врятувала ситуацію

Платформна команда підтримувала внутрішній список «відомо‑добрих ноутбуків» для інженерів, які регулярно запускали локальні бази даних, VM і компіляції. Список жодного разу не згадував TDP. Він вказував моделі, версії BIOS, потужність адаптера і простий тест прийнятності: запустити 10‑хвилинне тривале навантаження CPU і зафіксувати стабілізовану пакетну потужність, частоту і температуру.

Коли настав цикл оновлення ноутбуків, вендор запропонував спокусливу нову модель: тонша, легша, та ж генерація CPU і глянцева позначка «high performance». Вона пройшла короткі демонстрації. Команда все одно провела тест прийнятності, бо так завжди робили.

Нова модель сильно бустила спочатку, а потім влаштовувалась на значно нижчій стійкій потужності, ніж попередня модель. Це не було катастрофою; просто не підходило для інженерів, що живуть у збірках і VM. Вендор пояснив очікувано: акустичні цілі, обмеження корпусу і інша крива вентилятора. Нічого «неправильного».

Оскільки команда інституціоналізувала нудний тест, вони помітили невідповідність до оформлення замовлень. Вони схвалили модель для загального офісного використання, але зберегли попередню товстішу лінійку (або альтернативу) для користувачів з високими потребами. Жодної драми. Жодних «чому збірки повільні» криз. Просто тихе уникнення болю.

Поширені помилки: симптом → корінна причина → виправлення

1) «Мій CPU 45W, але під навантаженням він споживає ~25W»

Симптом: Пакетна потужність стабілізується значно нижче заявленого класу.

Корінна причина: OEM встановив низький PL1, щоб відповідати цілям по шуму/температурі поверхні, або джерело живлення (адаптер/док) не дає достатнього запасу.

Виправлення: Перевірте з оригінальним адаптером; перевірте стан заряджання під навантаженням; якщо PL1 обмежений прошивкою, реальне виправлення — інша модель ноутбука або вендорський режим продуктивності, що піднімає PL1.

2) «Він швидкий 30 секунд, потім повільний назавжди»

Симптом: Високі початкові частоти, потім стабільна нижча платформа.

Корінна причина: Імпульс PL2 закінчується (вікно Tau), потім CPU падає до PL1; інколи теплове насичення призводить до ще нижчих лімітів.

Виправлення: Виміряйте тривалу потужність після 3–10 хвилин; обирайте обладнання, базуючись на цій платі, а не на першому проході бенчмарку.

3) «На батареї мій ноутбук перетворюється на іншу машину»

Симптом: Велике падіння продуктивності відключеним від мережі.

Корінна причина: Обмеження розряду батареї, консервативна прошивка на батареї або перемикання енергоплану ОС.

Виправлення: Якщо вам потрібна продуктивність на батареї, шукайте системи, відомі тим, що дозволяють вищу потужність на батареї. Інакше прийміть, що режим батареї для ефективності і плануйте робочі процеси відповідно.

4) «Підключено до мережі, але все одно повільно і не заряджається»

Симптом: Відсоток батареї повільно знижується при підключенні.

Корінна причина: Потужність адаптера занизька, USB-C PD узгодив нижчий рівень, або док не може забезпечити навантаження.

Виправлення: Використовуйте високопотужний адаптер OEM; замініть кабель; уникайте низькопотужних доків для тривалих навантажень.

5) «Температура CPU в нормі, але частоти все одно низькі»

Симптом: Температури нижче точки троттлінгу, але частота/потужність низькі.

Корінна причина: Обмеження потужності, EPP/energy bias, вендорський «тихий» режим або квота cgroup.

Виправлення: Перевірте політику живлення і обмеження cgroup; упевніться, що turbo не відключено в BIOS; потім розгляньте вендорські профілі продуктивності.

6) «Я перезаправив пасту і це ледь допомогло»

Симптом: Нижчі пікові температури, але та сама тривала продуктивність.

Корінна причина: Тривала продуктивність обмежується потужністю, а не температурою; PL1 OEM — це стеля.

Виправлення: Перестаньте вважати охолодження єдиним важелем. Виміряйте поведінку PL1; якщо він обмежений — прийміть це або змініть обладнання.

7) «Бенчмарки чудові, реальна робота — посередня»

Симптом: Високі бали в коротких тестах, повільні довгі компіляції/рендери.

Корінна причина: Бенчмарки сприятливі до імпульсів; ваше навантаження тривале і нагріває корпус.

Виправлення: Використовуйте тривалі бенчмарки (повторні прогони, 10‑хвилинні навантаження) і стежте за стабілізованою пакетною потужністю і частотами.

8) «Оновлення CPU мало допомогло моєму навантаженню»

Симптом: Новіший CPU відчувається схожим.

Корінна причина: Навантаження прив’язане до I/O, пам’яті або GPU; або новий ноутбук має нижчі тривалі ліміти, незважаючи на новішу силікатну базу.

Виправлення: Вимірюйте вузькі місця (iowait, свап, завантаження GPU). Якщо тривала потужність нижча — ви купили тоншу казку, а не швидшу машину.

Чеклісти / покроковий план

Чекліст A: Покупка ноутбука для тривалої роботи CPU

1. Обирайте за моделлю, а не за SKU CPU. Той самий CPU в різних корпусах може поводитися по‑різному.
2. Вимагайте тривалі показники. Шукайте огляди/тести з багатомінутними циклами і стабілізованою потужністю.
3. Віддавайте перевагу товстішому охолодженню для довгих навантажень. Парова камера, подвійні вентилятори, правильний випуск. Вага — це характеристика продуктивності.
4. Перевірте потужність адаптера. Переконайтесь, що блок живлення покриває CPU+GPU+зарядку. USB-C PD зручний, але не магічний.
5. Підтвердіть очікування щодо продуктивності на батареї. Якщо вам це справді потрібно — протестуйте.
6. Слідкуйте за вендорськими режимами продуктивності. Деякі — чесні ручки, інші — лише оболонки для «зробити гучніше».
7. Плануйте охолодження SSD. Тривалі збірки і VM можуть нагріти NVMe у зону троттлінгу.
8. Не ставте надто багато ваги на одиночні бенчмарки. Запитайте: що відбувається на 8‑й хвилині?

Чекліст B: Діагностика існуючого ноутбука, який «має бути швидшим»

1. Нормалізуйте змінні: OEM адаптер, підключено, стабільна температура навколо, кришка відкрита, не лежить на ковдрі.
2. Встановіть відомий енергопрофіль (тимчасовий режим performance) і відключіть вендорський «тихий» режим.
3. Запустіть тривале навантаження CPU на 3–10 хвилин.
4. Спостерігайте: пакетну потужність, частоту, температуру, поведінку вентилятора.
5. Вирішіть: обмеження по потужності vs теплове обмеження vs інше вузьке місце (RAM/SSD/cgroups).
6. Якщо термально обмежено: почистіть повітрозабірники/вентилятори, перевірте обертання вентиляторів, перевірте пасту/прокладки, розгляньте кулер як тимчасовий захід.
7. Якщо обмеження по потужності у дизайні: оцініть опції прошивки; інакше припиніть витрачати час і прийміть конверт продукту.
8. Якщо «інше вузьке місце»: виправте тиск пам’яті, насичення I/O або квоти контейнерів.

Чекліст C: Встановлення очікувань для команд (версія для підприємства)

1. Стандартизуйте на конкретних моделях. Не «будь‑який i7». Модель, базовий BIOS, адаптер в комплекті.
2. Визначте тест прийнятності. Тривале навантаження + виміряна стабілізована пакетна потужність.
3. Документуйте режими живлення. «Тихий», «збалансований», «продуктивність» і коли їх використовувати.
4. Надайте рівень робочої станції. Деяким інженерам потрібна тривала продуктивність; удавання, що це не так, призводить до марних витрат.
5. Інструментуйте біль розробників. Відстежуйте часи збірки і тиск ресурсів; ставте це на один рівень з затримкою в продакшені.

FAQ

1) Чи є TDP максимальним споживанням?

Ні. У сучасних мобільних CPU короткі імпульси можуть перевищувати «TDP клас» суттєво. Тривала потужність також може бути нижчою за нього, залежно від обмежень OEM.

2) Чому два ноутбуки з одним CPU працюють по‑різному?

Тому що OEM встановлює тривалі та імпульсні обмеження потужності, криві вентиляторів і інколи різні термальні рішення. Модель CPU — лише один з вхідних параметрів продуктивності.

3) Що важливіше за TDP для тривалої роботи?

Стабілізована пакетна потужність і частота через кілька хвилин навантаження, а також чи система обмежена по потужності чи по теплу в цьому стійкому стані.

4) Якщо я підніму ліміти потужності, чи завжди отримаю більше продуктивності?

Тільки якщо є температурний запас і достатнє живлення. Інакше отримаєте вищі температури, гучніші вентилятори, а потім зворотний троттлінг до тієї ж точки.

5) Чому мій ноутбук троттлить, хоч температура CPU не максимальна?

Бо обмеження потужності можуть капати продуктивність до досягнення теплових лімітів. Також інші датчики (VRM, температура корпусу) можуть викликати платформні троттли.

6) Чи допомагає undervolting?

Іноді. Зниження напруги може зменшити потужність на заданій частоті, що покращує тривалі частоти в межах того ж теплового/енергетичного контуру. На багатьох сучасних платформах undervolting може бути обмеженим прошивкою з міркувань безпеки та стабільності.

7) Чи «15W» vs «28W» — це велика різниця?

Вона може бути величезною для тривалих навантажень, але лише якщо ноутбук дійсно дозволяє ті тривалі ліміти. Деякі «28W‑здатні» чіпи відвантажуються в ноутбуках, що тримають набагато менше під навантаженням.

8) Який найпростіший тест, щоб побачити реальну тривалу здатність CPU мого ноутбука?

Запустіть 3–10 хвилинне навантаження CPU (або ваше реальне навантаження) і стежте за пакетною потужністю та частотою в часі. Плато — ваша реальність.

9) Чому оглядачі й технічні листи досі фокусуються на TDP?

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

10) Чи варто купувати ігровий ноутбук для CPU‑роботи?

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

Висновок: подальші кроки, що не витрачають гроші даремно

Перестаньте купувати ноутбуки так, ніби це настільні CPU в різних коробках. TDP — не контракт. У ноутбуках це ближче до пропозиції, яку змінюють прошивка, охолодження та продуктова стратегія.

Що робити далі:

1. Виміряйте вашу реальність: запустіть тривале навантаження і стежте за пакетною потужністю, частотою і температурою, поки вони не стабілізуються.
2. Класифікуйте лімітатор: політика потужності, OEM‑PL1 кап, теплове насичення, адаптер/док або не‑CPU вузькі місця (RAM/SSD).
3. Налаштовуйте лише те, що варто налаштовувати: виправте фонове навантаження, підтвердіть потужність адаптера, очистіть шляхи охолодження. Не перезапроваджуйте пасту в ноутбуку, якщо він просто обмежений прошивкою.
4. При покупці: обирайте моделі, що довели, що можуть утримувати потрібну вам потужність, і ставтесь до «класу TDP» як до грубого сімейного ярлика, а не гарантії продуктивності.

CPU може бути чудовим. Ноутбук все одно може брехати. Ваше завдання — змусити його зізнатися вимірюваннями.

Неприємна істина: «краще» рідко перемагає

Інженери люблять чисті дизайни. Ринки люблять обсяги відвантаження. Це не одна і та ж справа.

FireWire була спроектована як серйозна шина: пристрої могли спілкуватися між собою без того, щоб хост контролював кожен байт. Вона мала сильну підтримку isochronous передавання (пам’ятаєте аудіо/відеопотоки, що потребують передбачуваного таймінгу), і вона не постійно переривала CPU, щоб просити дозволу на кожен рух. USB, особливо ранній USB, була спроектована як ввічлива черга в державній установі: всі чекають, хост викликає ваш номер, ви передаєте документи і сідаєте назад.

І все ж: USB перемогла, бо була простішою в реалізації, мала ширшу підтримку консорціуму, менше ліцензійних і вартісних перепон у ланцюгу постачання, і її інтегрували всюди. В термінах опсів: вона мала кращу «доступність» на рівні екосистеми. Найшвидший інтерфейс на папері не має значення, якщо ви не можете знайти кабель у конференц-залі або контролер на материнській платі.

Ось керівна ідея для решти матеріалу: FireWire програла не тому, що була поганою, а тому, що «достатньо добре + всюди» — це суперсила.

Що таке FireWire насправді (і чому інженери її любили)

IEEE 1394 простими оперативними словами

FireWire (IEEE 1394) — це серійна шина зі значною кількістю «реального bus» DNA: арбітраж, peer-to-peer передачі і можливість переміщення даних з меншим наглядом CPU. Вона підтримувала як асинхронні передачі (загальні дані), так і isochronous передачі (чутливі до часу потоки). Саме друга властивість зробила її улюбленою для DV-відеокамер, аудіоінтерфейсів і ранніх професійних робочих процесів медіа.

Ключові практичні ознаки, що мали значення:

• Peer-to-peer можливість: пристрої могли спілкуватися без маршрутизації всього через модель планування, керовану хостом.
• Isochronous режим: краще підходив для стабільних потоків, ніж ранній «перш за все bulk» світ USB.
• Нижче навантаження на CPU (часто): менше переривань і протокольного шуму для певних навантажень.
• Каскадне підключення (daisy chaining): кілька пристроїв в ланцюжку, менше захаращення концентраторами.

Атмосфера FireWire: передбачувана, «професійна», трохи зарозуміла

FireWire виглядала як обладнання зі стійки студії. Роз’єми були доволі надійні. Продуктивність була солідною для свого часу. Екосистема мала реальні перемоги: захоплення відео, зовнішнє зберігання, аудіо і навіть певне відчуття «воно просто працює» — коли все дійсно працювало.

Але виробнича реальність любить перетворювати естетику в електронні таблиці.

Що таке USB насправді (і чому закупівлі її любили)

Початкові обіцянки USB: один порт для столу

USB була спроектована, щоб замінити зоопарк старих портів на щось універсальне, дешеве й просте. Архітектура орієнтована на хост: контролер хоста планує передачі, пристрої відповідають. Це робить пристрої простішими й дешевшими — інженерний компроміс, що стає ринковою перевагою, коли потрібно ставити порти на кожен ПК, принтер, сканер і випадковий пластиковий гаджет.

Вбивчі функції USB не були гламурними, але вони були вирішальними:

• Дешеві контролери і широка інтеграція чіпсетів.
• Класові драйвери (HID, mass storage), що зменшували біль від специфічних драйверів.
• Plug-and-play, яке споживачі могли пережити без читання інструкцій.
• Зворотна сумісність, що створювала довгу «злітну смугу» — «воно все ще підключається».

Атмосфера USB: брудна, всюди, важко вбити

USB — тарган стандартів I/O у найпозитивнішому сенсі. Виживає. Пристосовується. З’являється там, де її не повинно бути. Ця всюдисущість робить її стандартною відповіддю, навіть якщо це не найкращий вибір.

Короткий жарт №1: найменування USB схоже на план міграції даних, написаний комітетом — технічно правильне, емоційно руйнівне.

Цікаві факти і історичний контекст (те, що забувають)

1. FireWire (IEEE 1394) розроблялась за значного внеску Apple і позиціонувалась на ранніх етапах як високошвидкісна мультимедійна шина.
2. FireWire 400 (1394a) мав 400 Mb/s і в реальному світі при тривалих передачах часто випереджав USB 2.0, незважаючи на заголовкові 480 Mb/s у USB 2.0.
3. USB 1.1 мав максимум 12 Mb/s (Full Speed). Раннє USB-зберігання не було тим, чим займалися для забави.
4. FireWire підтримував isochronous передачі як першокласну функцію, що є однією з причин стандартизації DV-камер на ньому для робочих процесів захоплення.
5. FireWire дозволяв каскадне підключення пристроїв без концентраторів у багатьох налаштуваннях; USB здебільшого спирався на хаби і строгий хост-центричний тополог.
6. Деякі екосистеми використовували FireWire для «Target Disk Mode» подібних робочих процесів, фактично перетворюючи машину на зовнішній диск для передачі та відновлення даних.
7. USB mass storage class (MSC) драйвери зменшили потребу у специфічних драйверах постачальників, що скоротило витрати на підтримку у великому масштабі.
8. Враження щодо ліцензування та роялті навколо FireWire створювали тертя для деяких виробників, тоді як USB отримав ширшу галузеву підтримку й комодитизацію.
9. На момент, коли FireWire 800 (800 Mb/s) дозрів, USB вже здобув «стан порту всюди» і перебував на швидшому циклі ітерацій і маркетингу.

Справжні технічні відмінності, що проявляються в продакшені

Ширина смуги vs пропускна здатність vs «чому мій CPU 30% при копіюванні диска?»

Специфікації — це маркетинг. Операції — це фізика плюс якість драйвера.

Заголовкова цифра USB 2.0 у 480 Mb/s виглядає як переможець над FireWire 400 з її 400 Mb/s. На практиці USB 2.0 часто забезпечував нижчу стійку пропускну здатність для задач зі зберігання, особливо на старих контролерах і драйверах, через:

• Протокольні накладні витрати і складність планування транзакцій.
• Хост-центричне опитування і участь CPU.
• Поведінка спільної шини за хабами і внутрішньою проводкою.
• Якість реалізації контролера і драйвера (що сильно змінювалася в різні епохи).

FireWire часто демонструвала кращу стійку продуктивність і нижче навантаження на CPU для певних задач. Але це також залежало від наявності відповідних портів, потрібних кабелів і правильних чіпсетів — речей, що стають «опцією», щойно ринок вирішує інакше.

Isochronous vs bulk: чому музиканти цим переймались

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

Рання історія USB орієнтувалася на bulk-перенесення для сховищ і контрольні передачі для пристроїв. Пізніші версії USB покращилися, і стек драйверів дозрів, але репутація закріпилась: FireWire — «про аудіо/відео професіоналів», USB — «периферія».

Топологія: шина vs дерево

Модель каскадного підключення FireWire зменшувала захаращення концентраторами, але збільшувала ризик «один ненадійний роз’єм ламає ланцюг». Модель USB «хаб-і-спиця» робила розширення простим, але перетворювала шину на спільну домену перетягування — особливо коли хтось підключає низькошвидкісний пристрій в той же хаб, що й ваш зовнішній SSD, і дивується, чому копії заїкаються.

Живлення і кабелі: непримітні вбивці

Відмови сховища не завжди про протоколи. Часто це про бюджет живлення, якість кабелю та роз’єми під шаром пилу під столом. Портативні диски, що живляться від USB, зробили зовнішнє зберігання дешевим і мобільним — що чудово, доки порт не може стабільно забезпечити струм і ваш «диск» не перетворюється на генератор випадкових відключень.

Короткий жарт №2: найшвидший інтерфейс зберігання — той, що підключений кабелем, який тримається не на надії й терті.

Чому USB переміг: нудна економіка поширення

1) Інтеграція перемагає елегантність

USB була інтегрована в чіпсети, BIOS/UEFI робочі процеси, операційні системи та очікування споживачів. FireWire часто вимагала додаткових контролерів, місця на платі і — що важливо — когось, кому це було потрібно.

Коли виробники материнських плат вирізають кілька центів і маркетингові пункти, «додатковий порт, яким користуються лише деякі» — легка ціль. USB ніколи не була «додатковою». Вона була планом.

2) Дешеві периферійні пристрої створюють маховик

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

3) Витрати на підтримку і історія драйверів

Класові драйвери USB мали значення. Для ІТ у великому масштабі «воно визначається і працює з вбудованим драйвером» — не зручність, а стаття витрат. FireWire мала хорошу підтримку, але дефолтність USB зменшувала тертя для принтерів, сканерів, клавіатур, накопичувачів і пізніше телефонів.

4) Сприйняття і доступність

Люди вибирають те, що можуть отримати сьогодні, а не теоретично краще. Зайдіть до будь-якого офісного магазину в 2000-х: кабелі і пристрої USB були на кожній полиці. FireWire — товар спеціального призначення, що поступово ставав таким.

5) Таймінг: USB продовжувала ітерації, поки FireWire втрачала увагу

Навіть коли FireWire 800 була сильним технічним рішенням, USB вже була стандартним роз’ємом у світі. Ринок не робить «пізніше, але кращо», якщо немає форсувального фактора. Його не було.

Одна операційна цитата для запам’ятовування

«Усе постійно ламається.» — Werner Vogels

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

Три корпоративні міні-історії з полі

Міні-історія №1: Інцидент через неправильне припущення

Середня медіакомпанія мала парк робочих станцій для нічного інгесту та транс-кодування. До робочих станцій підвозили зовнішні диски з зйомок. ІТ-команда стандартизувала «швидке зовнішнє» і припустила, що «USB 3 значить завжди достатньо швидко». Вони також припускали, що якщо порт синій — шина в порядку.

Одного тижня час інгесту подвоївся. Потім утраївся. Редакторі почали ставити завдання в чергу на ніч і приходили до напівготових рендерів. Моніторинг кластера транс-коду виглядав нормально; CPU і GPU були в нормі. Вузьке місце було вище в ланцюжку: робочі станції інгесту.

Виновником виявилося оновлення десктопів, ініційоване закупівлею, яке непомітно змінило внутрішню топологію USB. Декілька портів на передній панелі ділили хаб з внутрішньою вебкамерою та Bluetooth-модулем, і при певних комбінаціях пристроїв зовнішні диски знижували швидкість або відчували переривання. Логи ОС показували транзієнтні відключення й перевстановлення, але ніхто не дивився логи робочих станцій, бо «робочі станції — не сервери».

Виправлення не вимагало героїзму. Вони замапили порти на контролери, зобов’язали використовувати задні I/O порти для інгесту і заборонили хаби для зберігання в цьому робочому процесі. Також додали маленьку перевірку здоров’я: якщо диск перерахувався як High Speed (USB 2.0) замість SuperSpeed, скрипт інгесту відмовлявся стартувати і просив користувача перемістити порт.

Неправильне припущення було не в «USB повільний». Воно було в «позначки швидкості USB — це обіцянка». Вони не є. Це переговори.

Міні-історія №2: Оптимізація, яка вдарила по спині

Команда інженерів корпоративних десктопів повинна була робити образи сотень машин на тиждень. Вони використовували зовнішні SSD з «золотим образом», щоб уникнути насичення мережі. Хтось помітив, що процес створення образу виконує повну перевірку після запису. Щоб заощадити час, цю перевірку відключили.

Деякий час це виглядало блискуче. Пропускна здатність образування зросла. Черга зменшилась. Всі вітали зміну.

Потім почалася повільна теча: невеликий відсоток машин завантажувався з дивними проблемами файлової системи, пошкодженням драйверів або збоєм інсталяції додатків. Переустановка іноді вирішувала проблему, іноді — ні. Тікети накопичувалися. Люди почали звинувачувати образ ОС, агент безпеки кінцевих точок, навіть «погані партії оперативки».

Виявилось, причиною були поєднання маргінальних USB-кабелів, кількох ненадійних мостів у корпусах і періодичних скидань шини під час тривалих записів. З вимкненою перевіркою мовчазна корупція прослизала. «Оптимізація» прибрала єдиний крок, який би це виявив, поки машина ще на столі.

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

Міні-історія №3: Нудна, але правильна практика, що врятувала день

Мала дослідницька лабораторія використовувала контролери інструментів, які скидали дані на зовнішні диски під час польових робіт. Вони мали мікс ноутбуків з USB і кілька старих машин з FireWire для спадкового обладнання. Полевая команда ненавиділа «додаткові кроки», але ІТ вимагало простий ритуал: перед кожною сесією захоплення запускати маленьку перевірку пристрою і записувати швидкість шини та лічильники помилок.

Одного дня польовий блок почав випадково пропускати зразки — інтермітентно. Це не було катастрофічним, що робило проблему гіршою: дані виглядали правдоподібно, поки ви не порівняли часові мітки і не помітили прогалини. Постачальник інструменту звинувачував програмне забезпечення контролера. Дослідники звинувачували диск. ІТ мовчки звинувачувало всіх.

Оскільки команда мала записи передпольотних перевірок, вони могли корелювати збої з конкретною моделлю ноутбука і конкретним USB-портом. Логи показали повторювані повідомлення про скидання xHCI під навантаженням запису. Вставка підсиленого хаба (так, іноді «додаткова коробка» — це фікс) стабілізувала живлення. Вони також змінили шлях захоплення: записували локально спочатку, а потім копіювали на зовнішнє зберігання після сесії.

Було нудно: перевірити, записати, порівняти, ізолювати. Ніяких героїчних вчинків. Але це врятувало тиждень польових робіт, а такі відмови не відображаються на дашбордах, але руйнують бюджети.

План швидкої діагностики: що перевіряти першим/другим/третім

Мета: вирішити за 10 хвилин, чи це диск, корпус, кабель, порт/контролер чи файлова система

Перш за все: визначити переговорну швидкість лінку та топологію

• Чи фактично працює він на очікуваній швидкості (USB 2 vs USB 3)?
• Чи стоїть він за хабом або ланцюжком перехідників?
• Чи контролер ділиться з іншими високонавантаженими пристроями?

По-друге: перевірити скидання, відключення і помилки транспорту

• Логи ядра: скидання USB, відкат UAS (UAS fallbacks), SCSI помилки.
• SMART: CRC-помилки, помилки медіа, сплески лічильника циклів живлення.

По-третє: бенчмарктити те, що треба (і не обманювати себе)

• Послідовне читання/запис для очікувань масових копій.
• Латентність і IOPS, якщо навантаження — дрібні файли або бази даних.
• Використання CPU під час передачі (навантаження хоста має значення).

Точки прийняття рішень

• Якщо швидкість лінку неправильна: спочатку виправляйте кабелі/порт/перехідник; не налаштовуйте програмне забезпечення.
• Якщо логи показують скидання: підозрюйте живлення/кабель/міст корпусу/прошивку; міняйте компоненти.
• Якщо бенчмарки в порядку, але «реальні копії» повільні: підозрюйте файлову систему, шифрування, AV або накладні витрати на дрібні файли.

Практичні завдання: команди, виводи й рішення (12+)

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

Завдання 1: Перерахувати топологію USB і переговорну швидкість

cr0x@server:~$ lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M
    |__ Port 2: Dev 3, If 0, Class=Mass Storage, Driver=uas, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M
    |__ Port 4: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 480M

Що це означає: Один накопичувач на SuperSpeed (5000M) використовує UAS; інший застряг на 480M з старим драйвером usb-storage.

Рішення: Перемістіть повільний пристрій на справжній USB 3 порт, приберіть хаби/перехідники і перевірте, що кабель сумісний з USB 3. Якщо він все ще домовляється на 480M — підозрюйте мост корпусу або кабель.

Завдання 2: Ідентифікувати конкретний пристрій і vendor/product ID

cr0x@server:~$ lsusb
Bus 002 Device 003: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS578 SATA 6Gb/s bridge
Bus 001 Device 005: ID 0bc2:3320 Seagate RSS LLC Expansion Desk

Що це означає: Ви можете прив’язати поведінку до певного мостового чіпсету (тут, JMS578) або моделі корпусу.

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

Завдання 3: Спостерігати логи ядра на предмет скидань і помилок транспорту

cr0x@server:~$ sudo dmesg -T | tail -n 25
[Mon Jan 21 10:14:02 2026] usb 2-2: reset SuperSpeed USB device number 3 using xhci_hcd
[Mon Jan 21 10:14:03 2026] scsi host6: uas
[Mon Jan 21 10:14:03 2026] sd 6:0:0:0: [sdb] tag#23 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD OUT
[Mon Jan 21 10:14:03 2026] sd 6:0:0:0: [sdb] tag#23 CDB: Write(10) 2a 00 1a 2b 10 00 00 08 00 00
[Mon Jan 21 10:14:03 2026] blk_update_request: I/O error, dev sdb, sector 439037952 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0

Що це означає: Скидання шини + abort UAS + I/O помилки вказують на нестабільність транспорту (живлення, кабель, прошивка корпусу), а не на «повільну файлову систему».

Рішення: Замініть кабель, випробуйте інший порт/контролер і розгляньте примусове переключення на BOT (відключення UAS) як тест. Якщо помилки залишаються — виводьте корпус з експлуатації.

Завдання 4: Підтвердити, який драйвер зв’язаний (UAS vs usb-storage)

cr0x@server:~$ readlink -f /sys/bus/usb/devices/2-2:1.0/driver
/sys/bus/usb/drivers/uas

Що це означає: Пристрій використовує UAS, що зазвичай краще для продуктивності, але іноді виявляє баги прошивки.

Рішення: Якщо ви бачите скидання/таймаути з UAS, протестуйте з відключеним UAS (наступне завдання). Змінюйте тільки якщо надійність покращиться.

Завдання 5: Тимчасово відключити UAS для конкретного пристрою (тест на надійність)

cr0x@server:~$ echo 'options usb-storage quirks=152d:0578:u' | sudo tee /etc/modprobe.d/disable-uas.conf
options usb-storage quirks=152d:0578:u

Що це означає: Це встановлює підказку, щоб змусити пристрій використовувати usb-storage (BOT) замість UAS.

Рішення: Перезавантажте або перезавантажте модулі, потім повторно протестуйте пропускну здатність і частоту помилок. Якщо стабільність значно покращується, ви знайшли проблему з прошивкою/мостом; плануйте заміну обладнання.

Завдання 6: Перевірити ідентифікацію блочного пристрою і шлях

cr0x@server:~$ lsblk -o NAME,MODEL,SERIAL,SIZE,TRAN,ROTA,TYPE,MOUNTPOINTS
NAME   MODEL            SERIAL        SIZE TRAN ROTA TYPE MOUNTPOINTS
sda    Samsung_SSD      S5R...        1.8T sata    0 disk
sdb    USB_SSD_Encl     0123456789AB  932G usb     0 disk /mnt/ext

Що це означає: Підтверджує, що пристрій підключений через USB (TRAN=usb) і чи він роторний.

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

Завдання 7: Швидкий тест послідовного читання (без використання кешу файлової системи)

cr0x@server:~$ sudo dd if=/dev/sdb of=/dev/null bs=16M status=progress iflag=direct
2147483648 bytes (2.1 GB, 2.0 GiB) copied, 9 s, 238 MB/s

Що це означає: Орієнтовна швидкість читання з сирого блочного пристрою. Це уникає хитрощів з page cache.

Рішення: Якщо застрягли на ~35–40 MB/s, ви, ймовірно, на USB 2.0. Якщо в сотнях — шина, ймовірно, в порядку.

Завдання 8: Швидкий тест послідовного запису (може бути руйнівним, якщо вказувати на реальну файлову систему)

cr0x@server:~$ sudo dd if=/dev/zero of=/mnt/ext/testfile.bin bs=16M count=256 oflag=direct status=progress
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 20 s, 214 MB/s

Що це означає: Стійка швидкість запису у змонтовану файлову систему. Використання oflag=direct зменшує ефект кешу.

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

Завдання 9: Виміряти латентність і IOPS (біль болю від дрібних файлів)

cr0x@server:~$ sudo fio --name=randread --filename=/mnt/ext/fio.bin --size=2G --direct=1 --rw=randread --bs=4k --iodepth=32 --numjobs=1 --time_based --runtime=30
randread: (groupid=0, jobs=1): err= 0: pid=18422: Mon Jan 21 10:22:10 2026
  read: IOPS=5400, BW=21.1MiB/s (22.1MB/s)(633MiB/30001msec)
    slat (usec): min=8, max=210, avg=18.40, stdev=6.12
    clat (usec): min=120, max=9800, avg=590.22, stdev=410.55

Що це означає: Випробування випадкового читання: IOPS і латентність. Зовнішнє USB-зберігання може виглядати «швидким» для великих послідовних копій і жахливим для дрібного випадкового I/O.

Рішення: Якщо латентність висока і робоче навантаження — дрібні файли (встановлення пакетів, git-клони, диски VM), перестаньте використовувати цей зовнішній диск для таких задач. Використайте внутрішній NVMe або нормальний мережевий сховищний розв’язок.

Завдання 10: Перевірити SMART-стан (якщо доступно через USB-міст)

cr0x@server:~$ sudo smartctl -a /dev/sdb
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.5.0] (local build)
=== START OF INFORMATION SECTION ===
Device Model:     CT1000MX500SSD1
Serial Number:    1234ABCDE567
...
=== START OF SMART DATA SECTION ===
Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       12

Що це означає: CRC-помилки часто вказують на проблеми цілісності сигналу (кабель/корпус), а не на відмову NAND.

Рішення: Якщо CRC-помилки зростають, спочатку замініть кабель і корпус. Якщо зростають перераховані сектори — замініть диск.

Завдання 11: Підтвердити файлову систему і опції монтування

cr0x@server:~$ mount | grep /mnt/ext
/dev/sdb1 on /mnt/ext type ext4 (rw,nosuid,nodev,noatime,discard)

Що це означає: Опції як discard можуть шкодити продуктивності на деяких пристроях; noatime може допомогти для навантажень, що інтенсивно працюють з метаданими.

Рішення: Якщо продуктивність нестабільна, тестуйте без постійного discard (використовуйте періодичний fstrim). Залишайте noatime для навантажень з великою кількістю дрібних файлів.

Завдання 12: Перевірити проблеми керування живленням autosuspend

cr0x@server:~$ cat /sys/module/usbcore/parameters/autosuspend
2

Що це означає: Autosuspend увімкнено (в секундах). Агресивний autosuspend може спричиняти відключення на маргінальних пристроях.

Рішення: Для нестабільних накопичувачів відключіть autosuspend для цього пристрою або глобально (обережно), потім повторно протестуйте стабільність.

Завдання 13: Ідентифікувати, на якому PCIe USB-контролері ви

cr0x@server:~$ lspci -nn | grep -i usb
00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller [8086:9d2f]

Що це означає: Прив’язує поведінку до сімейства контролерів. Деякі мають відомі особливості з певними мостами.

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

Завдання 14: Перевірити керування енергоспоживанням лінку і помилки під навантаженням

cr0x@server:~$ sudo journalctl -k -n 80 | grep -Ei 'usb|uas|xhci|reset|error'
Jan 21 10:24:11 server kernel: usb 2-2: reset SuperSpeed USB device number 3 using xhci_hcd
Jan 21 10:24:12 server kernel: sd 6:0:0:0: [sdb] Synchronizing SCSI cache
Jan 21 10:24:12 server kernel: sd 6:0:0:0: [sdb] tag#7 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK

Що це означає: Підтверджує повторювані помилки на рівні транспорту, корельовані з навантаженням.

Рішення: Припиніть налаштовувати параметри застосунку. Замініть фізичний шар: кабель, порт, хаб, корпус. Якщо треба тримати працездатність, перемістіть навантаження на безпечніший шлях (спочатку скопіюйте локально).

Завдання 15: Підтвердити переговорну швидкість на конкретному шляху пристрою

cr0x@server:~$ cat /sys/bus/usb/devices/2-2/speed
5000

Що це означає: 5000 Mb/s (USB 3.0 SuperSpeed). Якщо бачите 480 — ви фактично на USB 2.0.

Рішення: Якщо швидкість 480 і ви очікували 5000/10000 — змініть кабель/порт/перехідник. Не приймайте «все гаразд», поки це число не стане правильним.

Завдання 16: Підтвердити глибину ланцюжка хабів (перехідники можуть тихо підкосити вас)

cr0x@server:~$ usb-devices | sed -n '1,120p'
T:  Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=10000 MxCh= 4
D:  Ver= 3.20 Cls=09(hub) Sub=00 Prot=03 MxPS= 9 #Cfgs=  1
P:  Vendor=1d6b ProdID=0003 Rev=06.05
S:  Product=xHCI Host Controller
...
T:  Bus=02 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#=  3 Spd=5000  MxCh= 0
D:  Ver= 3.10 Cls=00(>ifc) Sub=00 Prot=00 MxPS= 9 #Cfgs=  1
P:  Vendor=152d ProdID=0578 Rev=02.10
S:  Product=JMS578

Що це означає: Показує, що пристрій на рівні 2 (за чимось). Чим більше перехідників/хабів — тим більше «сюрпризів».

Рішення: Для критичних передач зменште глибину ланцюжка: пряме підключення до порту хоста, бажано заднього I/O, бажано на виділений контролер.

Типові помилки: симптоми → корінь → виправлення

1) «USB 3 диск копіює зі 35 MB/s»

Симптоми: Швидкість копіювання близько 30–40 MB/s; CPU в нормі; все «працює», але повільно.

Корінь: Пристрій домовився на USB 2.0 (480M) через неправильний кабель, поганий порт, хаб/перехідник або обмеження корпусу.

Виправлення: Перевірте lsusb -t і /sys/bus/usb/devices/.../speed. Перемкніть на відомий USB 3 кабель, підключіть прямо до порту, уникайте хабів і підтвердіть, що воно показує 5000/10000.

2) Випадкові відключення під час великих записів

Симптоми: «device not accepting address», «reset SuperSpeed USB device», перехід файлової системи в режим read-only.

Корінь: Нестабільне живлення, маргінальний кабель, баг прошивки мосту корпусу або проблеми UAS.

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

3) Бенчмарки хороші, реальна робота жахлива

Симптоми: dd показує 300 MB/s, але розпакування tar займає вічність; операції git повзуть.

Корінь: Дрібні випадкові I/O і накладні витрати на метадані; вибір файлової системи/опції монтування; антивірус або індексація; накладні витрати шифрування.

Виправлення: Виміряйте fio 4k random; використовуйте внутрішній SSD для задач з великою кількістю метаданих; налаштуйте опції монтування (noatime), уникайте повільних файлових систем на повільних носіях і виключайте інтенсивне сканування, де потрібно.

4) «Ми відключили перевірку, щоб прискорити іміджування» і тепер все підозріле

Симптоми: Непослідовні проблеми завантаження, пошкоджені інсталяції, збої, що зникають після повторного образування.

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

Виправлення: Знову ввімкніть перевірку/контрольні суми, стандартизуйте обладнання і ставте якість кабелю як критичну залежність.

5) Один порт працює, інший — ні

Симптоми: Той самий диск поводиться інакше в залежності від порту.

Корінь: Різна внутрішня проводка хабів/контролерів; передні порти часто мають гіршу цілісність сигналу; спільна пропускна здатність з іншими внутрішніми пристроями.

Виправлення: Замапте порти на контролери (lsusb -t, usb-devices), стандартизуйте використання відомо хороших портів для високошвидкісного зберігання і документуйте це.

6) FireWire пристрій «раніше був надійним», а тепер музейний експонат

Симптоми: Повсюди перехідники; проблеми сумісності; складно знайти порти/кабелі; переривчаста підтримка драйверів у нових ОС.

Корінь: Колапс екосистеми: менше рідних контролерів, більше стеків адаптерів, менше тестування виробниками.

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

Чеклісти / покроковий план

Чекліст A: Стандартизація зовнішнього зберігання для команди

1. Виберіть одну модель корпусу і один модель диска; протестуйте їх на основних платформах хостів.
2. Вимагайте кабелів, що відповідають специфікації швидкості (позначайте їх; викидайте невідомі кабелі).
3. Визначте, чи дозволяєте хаби/перехідники. Для зберігання: за замовчуванням — «ні».
4. Визначте мінімальну перевірку переговорної швидкості (скриптується через sysfs на Linux).
5. Виберіть файлову систему і опції монтування залежно від навантаження (послідовне vs інтенсивне по метаданих).
6. Запишіть «відомо хороші порти» для кожної моделі хоста (задній I/O vs передній).
7. Включіть крок верифікації для образування/резервного копіювання (контрольна сума або зворотне читання).
8. Відстежуйте відмови за чіпсетом мосту і сімейством контролерів, а не лише за «брендом диска».

Чекліст B: Перед тим, як звинувачувати мережу або масив зберігання

1. Підтвердіть швидкість лінка і драйвер (UAS vs BOT).
2. Перевірте логи ядра на скидання і I/O помилки.
3. Запустіть сире читання пристрою і тест запису файлової системи.
4. Запустіть 4k random тест, якщо навантаження — «багато дрібних файлів».
5. Перевірте SMART і слідкуйте за лічильниками CRC-помилок.
6. Замініть кабель перед заміною диска. Потім міняйте корпус.

Чекліст C: План міграції від FireWire без драм

1. Інвентаризуйте, що ще вимагає FireWire (пристрої захоплення, спадкові диски, старі Mac).
2. Залиште одну присвячену спадкову машину для інгесту, що залишається стабільною і незмінною.
3. Перемістіть захоплення на локальне внутрішнє сховище спочатку; передавайте пізніше сучасними інтерфейсами.
4. За можливості замініть FireWire-пристрій на сучасний еквівалент замість нагромадження адаптерів.
5. Протестуйте повний робочий процес реальними розмірами даних і з ін’єкцією відмов (вимкнути/включити, цикли живлення).

FAQ

1) Чи був FireWire насправді швидшим за USB?

Часто так, у реальних стійких навантаженнях порівняно з USB 2.0, незважаючи на вищу заголовкову пропускну здатність USB 2.0. FireWire схильна забезпечувати стабільнішу пропускну здатність і нижче навантаження на CPU у багатьох конфігураціях.

2) Якщо FireWire була кращою, чому її не всі зберегли?

Бо перемагають екосистеми. USB була дешевшою у впровадженні, інтегрувалася всюди, отримала перевагу класових драйверів і здобула статус «порт за замовчуванням». Доступність перемагає елегантність.

3) Чи поганий USB для зовнішнього зберігання сьогодні?

Ні. Сучасний USB (і USB-C) можуть бути відмінними. Проблема — змінність: кабелі, корпуси, хаби, реалізації контролерів і живлення все ще можуть вам дошкуляти.

4) Чому деякі USB-диски випадково відключаються під навантаженням?

Поширені причини: недостатнє живлення (особливо для дисків із живленням від шини), маргінальні кабелі, баги прошивки мосту корпусу або нюанси UAS, що проявляються при тривалих I/O.

5) Який найшвидший спосіб дізнатися, чи я випадково на USB 2.0?

На Linux: cat /sys/bus/usb/devices/<dev>/speed або lsusb -t. Якщо ви бачите 480M — ви на USB 2.0.

6) Чи варто відключати UAS, щоб виправити проблеми?

Лише як діагностика або крайній тимчасовий обхід. Якщо відключення UAS робить пристрій стабільним, реальне рішення — замінити корпус/міст на той, що поводиться коректно.

7) Чому бенчмарки не збігаються з копіями файлів?

Бенчмарки часто вимірюють послідовну пропускну здатність; реальні навантаження можуть бути насичені метаданими або дрібними випадковими I/O. Також кеші можуть брехати. Використовуйте direct I/O тести і вимірюйте те навантаження, яке ви реально запускаєте.

8) Чи є Thunderbolt «новим FireWire»?

У сенсі того, що він більш «bus-like» і високопродуктивний — так. У сенсі того, що автоматично переможе всюди — ні. Вартість, інтеграція і «чи є він у кожної випадкової машини» все ще вирішують прийняття.

9) Якщо у мене ще є FireWire-обладнання, який найбезпечніший операційний підхід?

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

Висновок: що робити наступного тижня, а не за квартал

FireWire програла, бо USB з’явилася всюди першою, стала дешевшою швидше і знизила тертя для виробників і ІТ. Урок не в тому, що «ринок дурний». Урок у тому, що операційний важіль важливіший за чистоту протоколу.

Наступні кроки, що дають негайний ефект:

• Припиніть довіряти міткам. Кожного разу, коли важливий робочий процес зовнішнього зберігання, перевіряйте переговорну швидкість і драйвер.
• Стандартизуйте фізичний шар. Одна модель корпусу, один тип кабелю, відомо хороші порти, мінімум перехідників.
• Інструментуйте робочі процеси на робочих станціях. Логи ядра і перевірки швидкості потрібні не лише для серверів.
• Зробіть верифікацію обов’язковою для іміджування, бекапів і інгест-пайплайнів, де мовчазна корупція дорога.
• Плануйте вихід зі спадщини. Якщо FireWire усе ще у вашому критичному шляху — поставте це як технічний борг з графіком відключення.

Вам не потрібен «найкращий» інтерфейс. Вам потрібен інтерфейс, що ламається передбачувано, діагностується і замінюється о 16:30 у п’ятницю. USB переміг, бо оптимізував під світ таким, який він є. Працюйте відповідно.

Що насправді означає «error opening» у термінах Proxmox RBD

Коли Proxmox повідомляє «RBD: error opening», найчастіше ви бачите помилку, що піднялася з librbd (клієнтська бібліотека для доступу до образів RBD).
Бібліотека намагається:

1. Завантажити конфігурацію Ceph (монітори, налаштування автентифікації, fsid тощо).
2. Аутентифікуватися (cephx) за допомогою ключа для певного імені клієнта (client.admin, client.pve або кастомного користувача).
3. Поговорити з моніторами (MONs), отримати мапу кластера та знайти OSD.
4. Відкрити образ RBD (для цього потрібні права на пул і сам образ).

«Error opening» зазвичай виникає через:

• Неправильний або відсутній keyring/ключ у конфігурації сховища Proxmox.
• Несумісність імені клієнта: ключ правильний, але для іншого імені клієнта.
• Caps не дозволяють операцію (тільки читання, а ви створюєте образ; відсутній profile rbd; немає доступу до метаданих rbd_children тощо).
• Монітори недоступні з одного вузла (маршрутизація, фаєрвол, неправильний mon_host, плутанина IPv6/IPv4).
• Різниця в конфігурації Ceph між вузлами (на одному вузлі застарілий /etc/ceph/ceph.conf або неправильний fsid).
• Права доступу до файлу keyring на диску: root може читати, але процес запущений від іншого користувача (поширено у кастомних інструментах; рідше в стандартному Proxmox).

Найшвидший спосіб припинити здогадки — відтворити ті самі операції відкриття з проблемного вузла за допомогою CLI rbd з тією ж ідентичністю та keyring.
Якщо rbd ls працює, але rbd info pool/image падає — ви дивитесь на несумісність caps. Якщо нічого не працює — починайте з моніторів і keyring.

Жарт №1: «Error opening» — це те, що Ceph каже, коли йому занадто чемно сказати «ваш keyring — відстій».

Швидкий план діагностики (перевірки 1/2/3)

Це порядок дій, який найшвидше завершує інциденти. Не той, що надає емоційне задоволення.

1) Підтвердьте, що з проблемного вузла можна дістатися до моніторів і аутентифікуватися

• Якщо з’єднання з моніторами або cephx автентифікація не працює, нічого іншого не має значення. Виправляйте це спочатку.
• Використайте ceph -s та ceph auth get client.X, де це доречно.

2) Підтвердьте, що Proxmox використовує той keyring, який ви думаєте

• Перевірте /etc/pve/storage.cfg та шлях до keyring для кожного сховища (або вбудований ключ).
• Переконайтеся, що файл існує на кожному вузлі (конфіг Proxmox розподілений, але keyring-файли локальні, якщо ви їх не синхронізували).

3) Перевірте caps щодо пулу та операції

• Перелічіть caps: ceph auth get client.pve.
• Тестуйте командами rbd, що імітують невдалу дію: rbd ls, rbd info, rbd create, rbd snap ls.

4) Лише потім: гнатися за помилками в UI Proxmox, логами qemu та крайніми випадками

• Перегляньте логи завдань і journalctl для pvedaemon, pveproxy та qemu-server.
• Більшість інцидентів «error opening» — це автентифікація/caps/конфіг. Екзотика існує, але вона не перша підозра.

Цікаві факти та контекст (бо минуле досі працює в проді)

• Ceph cephx автентифікація створена, щоб уникати спільних глобальних секретів. Ключі можна обмежувати до пулів та операцій, тому caps мають велике значення.
• Початкова аудиторія RBD — хмарні платформи. Модель «образ + снапшот + клон» дуже орієнтована на ВМ, тому Proxmox і OpenStack швидко її підхопили.
• Proxmox зберігає конфіг кластера в розподіленій файловій системі. /etc/pve спільний між вузлами, але локальні файли як /etc/ceph/ceph.client.pve.keyring не реплікуються автомагічно.
• Історично багато розгортань використовували client.admin всюди. Це «працює», поки не стане головним болем для аудиту та збільшувачем серйозності інцидентів.
• Синтаксис caps еволюціонував. Старі дописи в блогах показують застарілі підходи; сучасний Ceph віддає перевагу profile rbd плюс явне обмеження пулом.
• Монітори Ceph — це шлюз консистентності. Можна мати здорові OSD і все одно провалити відкриття RBD, якщо квора моніторів або досяжність з одного вузла зламана.
• Відкриття RBD може вимагати метаданних операцій. Навіть читання може вимагати доступу до метаданих пулу (та залежно від функцій — до omap-ключів). «Я дав тільки читання» може виявитися надто суворим.
• Відкриття конфігурації Ceph має кілька шляхів. Змінні середовища, шляхи за замовчуванням і явні прапори можуть призвести до ситуації «в моєму шеллі працює», але в задачах Proxmox — ні.

Поширені симптоми: що ви побачите і де

Proxmox може показувати той самий корінний збій через кілька шарів. Вивчіть патерни:

• Лог завдання Proxmox: «rbd: error opening» під час створення диска, прикріплення, снапшоту, міграції або запуску ВМ.
• Не вдається стартувати QEMU: VM не стартує; логи qemu згадують неможливість відкрити образ RBD.
• Помилки CLI при мапінгу: rbd map повертає «permission denied» або «error connecting to the cluster».
• Підказки зі сторони Ceph: логи MON показують помилки автентифікації; логи OSD — відхилені операції; але часто Ceph мовчить, якщо не підняти рівні дебагу.
• Поводження залежно від вузла: Один вузол Proxmox має доступ до RBD; інший — ні. Це кричить «локальний keyring/конфіг різниться».

Практичні завдання: команди, виводи та рішення (12+)

Мета цих завдань — перетворити розпливчасті помилки UI на чіткі рішення. Виконуйте їх спочатку з проблемного вузла, потім з відомо робочого для порівняння.

Task 1: Підтвердьте, що Ceph кластер досяжний і ви не женетеся за привидами

cr0x@server:~$ ceph -s
  cluster:
    id:     2c3d1d5e-9a2e-4e2b-8a59-4f1c7c0c1c2f
    health: HEALTH_OK

  services:
    mon: 3 daemons, quorum mon1,mon2,mon3 (age 2h)
    mgr: mgr1(active, since 2h)
    osd: 12 osds: 12 up (since 3h), 12 in (since 3h)

  data:
    pools:   4 pools, 256 pgs
    objects: 3.2M objects, 12 TiB
    usage:   36 TiB used, 72 TiB / 108 TiB avail
    pgs:     256 active+clean

Що це означає: Це підтверджує, що CLI може говорити з моніторами і автентифікуватися, використовуючи ту конфігурацію/ключ, яку бере ваш шелл.

Рішення: Якщо це падає на проблемному вузлі, але працює в інших — виправте доступ до моніторів і локальну конфігурацію Ceph перед тим, як лізти в Proxmox.

Task 2: З’ясуйте, що Proxmox вважає вашим RBD-сховищем

cr0x@server:~$ grep -nE '^(rbd:|[[:space:]]*(pool|monhost|username|keyring|content))' /etc/pve/storage.cfg
12:rbd: ceph-rbd
13:        monhost 10.10.0.11 10.10.0.12 10.10.0.13
14:        pool vmdata
15:        username pve
16:        keyring /etc/ceph/ceph.client.pve.keyring
17:        content images,rootdir

Що це означає: Proxmox намагатиметься підключитися до цих IP моніторів, аутентифікуватися як client.pve, використовуючи той keyring-файл.

Рішення: Якщо keyring відсутній або вказує на файл, якого немає на деяких вузлах — ви знайшли корінь проблеми.

Task 3: Перевірте, що файл keyring існує на цьому вузлі і доступний для читання

cr0x@server:~$ ls -l /etc/ceph/ceph.client.pve.keyring
-rw------- 1 root root 151 Dec 26 10:41 /etc/ceph/ceph.client.pve.keyring

Що це означає: Файл існує і тільки root може його читати, що нормально для Proxmox.

Рішення: Якщо він відсутній на одному вузлі — скопіюйте його безпечно або відтворіть. Якщо права надто відкриті — виправте; неохайні секрети стають інцидентами.

Task 4: Підтвердьте, що keyring містить очікуване ім’я клієнта

cr0x@server:~$ sed -n '1,120p' /etc/ceph/ceph.client.pve.keyring
[client.pve]
	key = AQB7qMdnJg0aJRAA7i9fJvQW9x0o0Jr8mGmNqA==
	caps mon = "profile rbd"
	caps osd = "profile rbd pool=vmdata"

Що це означає: Заголовок секції має збігатися з ім’ям користувача, яке використовує Proxmox (без префіксу client. в storage.cfg).

Рішення: Якщо в файлі вказано [client.admin], а в storage.cfg — username pve, Proxmox не зможе автентифікуватися.

Task 5: Тестуйте доступ до RBD явно, використовуючи ту ж ідентичність, що й Proxmox

cr0x@server:~$ rbd -p vmdata ls --id pve --keyring /etc/ceph/ceph.client.pve.keyring
vm-101-disk-0
vm-102-disk-0
base-9000-disk-0

Що це означає: Аутентифікація працює і користувач може перерахувати образи в пулі.

Рішення: Якщо перелік працює, але Proxmox все ще падає при відкритті — проблема, ймовірно, в правах на рівні образу/функцій або ви використовуєте інший пул/ім’я образу, ніж думаєте.

Task 6: Відтворіть відкриття конкретного образу (найкорисніше для «error opening»)

cr0x@server:~$ rbd info vmdata/vm-101-disk-0 --id pve --keyring /etc/ceph/ceph.client.pve.keyring
rbd image 'vm-101-disk-0':
	size 100 GiB in 25600 objects
	order 22 (4 MiB objects)
	snapshot_count: 2
	id: 1a2b3c4d5e6f
	block_name_prefix: rbd_data.1a2b3c4d5e6f
	format: 2
	features: layering, exclusive-lock, object-map, fast-diff, deep-flatten
	op_features:
	flags:
	create_timestamp: Tue Dec 24 09:12:33 2025
	access_timestamp: Tue Dec 24 09:12:33 2025
	modify_timestamp: Thu Dec 26 10:01:07 2025

Що це означає: Якщо це вдається, «open» працює на рівні RBD. Proxmox має в змозі запустити VM, якщо не використовуються інші облікові дані/конфіг.

Рішення: Якщо це падає з «permission denied», ваші caps недостатні для метаоперацій або ви націлені на інший пул.

Task 7: Підтвердьте caps для користувача клієнта (не здогадуйтеся)

cr0x@server:~$ ceph auth get client.pve
[client.pve]
	key = AQB7qMdnJg0aJRAA7i9fJvQW9x0o0Jr8mGmNqA==
	caps mon = "profile rbd"
	caps osd = "profile rbd pool=vmdata"

Що це означає: Це авторитетна інформація всередині Ceph (не те, що може лежати в keyring-файлі на вузлі).

Рішення: Якщо caps не включають цільовий пул — виправте caps. Якщо ключ відрізняється від того, що в keyring-файлі — оновіть файл всюди.

Task 8: Перевірте конфіг Ceph, який Proxmox буде неявно використовувати

cr0x@server:~$ cat /etc/ceph/ceph.conf
[global]
fsid = 2c3d1d5e-9a2e-4e2b-8a59-4f1c7c0c1c2f
mon_host = 10.10.0.11 10.10.0.12 10.10.0.13
auth_client_required = cephx
auth_cluster_required = cephx
auth_service_required = cephx

Що це означає: Неправильний fsid або відсутній/неправильний mon_host можуть змусити вузол говорити з неправильним або жодним кластером.

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

Task 9: Підтвердьте досяжність моніторів з проблемного вузла (маршрутизація/фаєрвол)

cr0x@server:~$ for m in 10.10.0.11 10.10.0.12 10.10.0.13; do echo "== $m =="; nc -vz -w2 $m 3300; nc -vz -w2 $m 6789; done
== 10.10.0.11 ==
Connection to 10.10.0.11 3300 port [tcp/*] succeeded!
Connection to 10.10.0.11 6789 port [tcp/*] succeeded!
== 10.10.0.12 ==
Connection to 10.10.0.12 3300 port [tcp/*] succeeded!
Connection to 10.10.0.12 6789 port [tcp/*] succeeded!
== 10.10.0.13 ==
Connection to 10.10.0.13 3300 port [tcp/*] succeeded!
Connection to 10.10.0.13 6789 port [tcp/*] succeeded!

Що це означає: Ceph MON використовує 3300 (msgr2) і іноді 6789 (легасі). Ви маєте мати зв’язок хоча б з тим, що використовує ваш кластер.

Рішення: Якщо це падає тільки на одному вузлі — виправте фаєрвол/маршрутизацію/VLAN/MTU. Не «виправляйте» автентифікацію, щоб компенсувати мережеві проблеми.

Task 10: Дістаньте лог задачі Proxmox, де міститься помилка

cr0x@server:~$ journalctl -u pvedaemon -S -2h | tail -n 40
Dec 26 10:50:14 pve3 pvedaemon[2211]:  starting task UPID:pve3:00008A1B:0002A1C4:676D7F46:qmstart:101:root@pam:
Dec 26 10:50:15 pve3 pvedaemon[1032]: command '/usr/bin/kvm -id 101 -name vm101 ... -drive file=rbd:vmdata/vm-101-disk-0:conf=/etc/pve/ceph.conf:id=pve:keyring=/etc/ceph/ceph.client.pve.keyring,if=none ...' failed: exit code 1
Dec 26 10:50:15 pve3 pvedaemon[1032]: TASK ERROR: start failed: error opening 'rbd:vmdata/vm-101-disk-0': (13) Permission denied

Що це означає: Це підтверджує точні аргументи, які QEMU використав, включно з id=pve та шляхом до keyring. Це — золото.

Рішення: Виконайте еквівалентну команду RBD вручну з тими ж параметрами. Якщо вона падає — це не «проблема Proxmox».

Task 11: Переконайтеся, що Proxmox вказує QEMU правильний ceph.conf

cr0x@server:~$ ls -l /etc/pve/ceph.conf
-rw-r----- 1 root www-data 232 Dec 26 10:40 /etc/pve/ceph.conf

Що це означає: Proxmox може генерувати/використовувати /etc/pve/ceph.conf. Він може відрізнятися від /etc/ceph/ceph.conf.

Рішення: Якщо ваші CLI тести використовують /etc/ceph/ceph.conf, а QEMU — /etc/pve/ceph.conf, уніфікуйте їх або тестуйте з тим же --conf.

Task 12: Повторіть тест з тим же конфігом, який використовував QEMU

cr0x@server:~$ rbd --conf /etc/pve/ceph.conf -p vmdata ls --id pve --keyring /etc/ceph/ceph.client.pve.keyring
rbd: listing images failed: (13) Permission denied

Що це означає: Це звужує коло підозр. Ранній успіх міг бути через інший конфіг (інший кластер, інші монітори, інші налаштування автентифікації).

Рішення: Перегляньте /etc/pve/ceph.conf і виправте його або перестаньте його використовувати. Послідовність краща за витонченість.

Task 13: Підтвердьте, з яким кластером ви спілкуєтесь (саніті-чек fsid)

cr0x@server:~$ ceph --conf /etc/pve/ceph.conf fsid
2c3d1d5e-9a2e-4e2b-8a59-4f1c7c0c1c2f

Що це означає: Якщо fsid відрізняється від очікуваного — ви автентифікуєтесь проти іншого Ceph-кластера (або старого лабораторного залишку).

Рішення: Виправте конфіг і перезапустіть потрібні сервіси; не «додавайте ще монів» в обидва кластери й не надійтеся.

Task 14: Виправте caps для клієнта Proxmox RBD (типова безпечна схема)

cr0x@server:~$ ceph auth caps client.pve mon "profile rbd" osd "profile rbd pool=vmdata"
updated caps for client.pve

Що це означає: Ви даєте моніторам відповідні права для RBD і даєте доступ до пулу на OSD. Це здравий замисел для VM-дисків в одному пулі.

Рішення: Якщо у вас кілька пулів, які використовує Proxmox, додайте кожен пул явно. Уникайте широкого allow *, якщо не любите пояснювати це потім.

Task 15: Оновіть (або створіть) keyring-файл послідовно на всіх вузлах

cr0x@server:~$ ceph auth get client.pve -o /etc/ceph/ceph.client.pve.keyring
exported keyring for client.pve

Що це означає: Ви пишете авторитетний ключ/права на файлову систему вузла. Повторіть на кожному вузлі або розподіліть безпечно.

Рішення: Якщо лише один вузол мав застарілий keyring — це усуне вузлові «error opening».

Task 16: Перевірте, чи здорова дефініція сховища Proxmox

cr0x@server:~$ pvesm status
Name       Type     Status           Total       Used        Available        %
ceph-rbd   rbd      active            0           0           0               0.00
local      dir      active        1966080    1126400          839680         57.29

Що це означає: Для RBD ємність може показуватися як 0 залежно від налаштувань, але сховище має бути active.

Рішення: Якщо воно неактивне або показує помилки — ще раз перевірте mon_host, username і шлях до keyring у storage.cfg.

Модель автентифікації Ceph у Proxmox: клієнти, keyring, caps та де Proxmox ховає налаштування

Імена клієнтів: найпоширеніша «підніжка» — однословна невідповідність

Користувачі Ceph називаються як client.pve, client.admin, client.proxmox. У Proxmox у storage.cfg ви часто вказуєте
username pve, що Proxmox трактує як client.pve.

Шаблони невідповідностей:

• Невідповідність заголовка keyring: файл містить [client.proxmox], а Proxmox використовує pve. Автентифікація провалюється.
• Невідповідність ключа: заголовок правильний, але ключ від старої ротації. Автентифікація провалюється.
• Невідповідність caps: автентифікація вдається, але операції провалюються під час open/create/snapshot.

Розташування keyring: спільний конфіг, локальні секрети

Розподілена ФС Proxmox спокушає думати, що все у конфігурації реплікується. Ні.
/etc/pve/storage.cfg реплікується. Ваш keyring у /etc/ceph — звичайний файл.

Ось чому «працює на node1, падає на node3» відбувається так часто:

• Ви додали сховище через UI один раз — це оновило /etc/pve/storage.cfg по кластеру.
• Ви скопіювали keyring тільки на один вузол (або скопіювали іншу версію).
• Proxmox з радістю розміщує VM на вузлі, який не може автентифікуватися, і ви отримуєте «error opening».

Caps: «profile rbd» — базова норма, обмеження пулом — запобіжна рейка

Для використання RBD у Proxmox оптимальна схема така:

• mon = "profile rbd", щоб клієнт міг запитувати потрібні мапи й метадані, пов’язані з RBD.
• osd = "profile rbd pool=<poolname>", щоб клієнт мав доступ до образів у конкретному пулі.

Якщо ви використовуєте кілька пулів (наприклад, vmdata, fast-ssd, templates), ви або:

• Надаєте кілька рядків для пулів (окремі клієнти — чистіше), або
• Приймаєте ширші caps і миритеся з компромісами безпеки.

Proxmox і /etc/pve/ceph.conf: тонкий розрив конфігів

Proxmox може підтримувати Ceph-конфіг під /etc/pve/ceph.conf, і процеси QEMU, запущені Proxmox, можуть посилатися саме на нього.
Тим часом ваші shell-команди можуть брати /etc/ceph/ceph.conf за замовчуванням. Якщо вони різняться — ви витратите години на доведення протилежного.

Визначте одне джерело правди і робіть його послідовним. Якщо Proxmox використовує /etc/pve/ceph.conf, тримайте його в порядку і синхронізованим з реальним кластером.

Цитата про надійність, якій варто довіряти

Парафраз думки Джона Оллспо (операції/надійність): «Інциденти виникають через звичайну роботу й побутові рішення, а не лише через рідкісну некомпетентність.»

Типові помилки: симптом → корінь проблеми → виправлення

1) Симптом: Працює на одному вузлі, падає на іншому з «error opening»

Корінь: Файл keyring відсутній або відрізняється на проблемному вузлі (або різний ceph.conf).

Виправлення: Переконайтеся, що keyring і конфіг існують і співпадають на кожному вузлі.

cr0x@server:~$ sha256sum /etc/ceph/ceph.client.pve.keyring /etc/ceph/ceph.conf /etc/pve/ceph.conf
e1d0c0d2f0b8d66c3f2f5b7a20b3fcb0a1f6e42a2bfafbfcd1c4e2a8fcbcc3af  /etc/ceph/ceph.client.pve.keyring
9b1f0c3c4f74d5d5c22d5e4e2d0a2a77bff2f5bd3d92a0e7db6c2f4f122c8f10  /etc/ceph/ceph.conf
9b1f0c3c4f74d5d5c22d5e4e2d0a2a77bff2f5bd3d92a0e7db6c2f4f122c8f10  /etc/pve/ceph.conf

Рішення: Хеші не співпадають між вузлами? Стоп. Уніфікуйте. Не продовжуйте дебагувати вищі рівні.

2) Симптом: «(13) Permission denied» при старті ВМ або створенні диска

Корінь: Caps занадто вузькі для того, що робить Proxmox (створення, снапшот, клон), або неправильне обмеження пулом.

Виправлення: Оновіть caps, щоб включити потрібний пул і profile rbd. Перевірте за допомогою rbd create.

cr0x@server:~$ rbd create vmdata/caps-test --size 64M --id pve --keyring /etc/ceph/ceph.client.pve.keyring
rbd: create error: (13) Permission denied

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

3) Симптом: «no keyring found» або «failed to load keyring» у логах

Корінь: Неправильний шлях у storage.cfg, або файл існує, але неправильні права/контекст SELinux/AppArmor (рідко в дефолтному Proxmox).

Виправлення: Виправте шлях; використовуйте абсолютний шлях; встановіть 0600 root:root.

4) Симптом: «error connecting to the cluster» або таймаути підключення до MON

Корінь: Неправильні IP моніторів у storage.cfg/ceph.conf, фаєрвол блокує 3300/6789, або DNS/IPv6 несумісність.

Виправлення: Використовуйте стабільні адреси моніторів; валідуйте досяжність; уникайте імен хостів, якщо DNS ненадійний.

5) Симптом: RBD list працює, але open падає для деяких образів

Корінь: Образ у іншому пулі, або функції образу вимагають операцій, які блокує ваші caps, або ім’я образу помилкове (описка, застаріла посилання після перейменування).

Виправлення: Перевірте точний пул/образ; запустіть rbd info і rbd snap ls з тією ж ідентичністю, що й Proxmox.

6) Симптом: Після ротації ключів старі ВМ не стартують

Корінь: Один вузол досі має старий keyring; Proxmox запланував запуски там; ви отримуєте «error opening».

Виправлення: Катайте оновлення ключів атомарно по вузлах, потім перевірте на невеликій кількості стартів/міграцій.

Жарт №2: Ротація ключів схожа на користування зубною ниткою — всі погоджуються, що це корисно, і майже ніхто не робить це у запланований час.

Три корпоративні міні-історії з передової

Міні-історія 1: Інцидент через неправильне припущення

Середня компанія мала кластер Proxmox з Ceph RBD для дисків VM. Вони додали новий вузол, приєднали його до кластера Proxmox і вважали справу зробленою.
Наступного ранку планове обслуговування спричинило декілька міграцій ВМ на новий вузол.

Половина мігрованих ВМ не повернулась. Proxmox показував ту саму тупу помилку: «error opening».
Ceph був здоровий. Сховище було визначене в /etc/pve/storage.cfg, тож команда припустила: «конфіг сховища реплікувався, отже доступ реплікувався».

Це припущення стало причиною інциденту. Новий вузол не мав /etc/ceph/ceph.client.pve.keyring. Інші вузли мали.
Proxmox UI зробив ситуацію гіршою, бо був послідовним: однакова назва сховища, той самий пул, ті самі монітори, однакова помилка.

Виправлення було неефектним: роздати keyring на всі вузли, перевірити хеші, потім перезапустити старти.
Дія після розбору була навіть більш прозаїчною: чекліст при приєднанні вузла з пунктом «ключі Ceph присутні і перевірені».

Міні-історія 2: Оптимізація, що пішла не так

Інша організація хотіла зменшити площу ураження, тому створила окремі Ceph-користувачі для різних Proxmox-кластерів і агресивно мінімізувала caps.
Гарна ідея. Але вони зайшли занадто далеко: дали лише права читання користувачу, якого Proxmox також використовував для операцій зі снапшотами і клонуванням.

Все було нормально тижнями, бо повсякденні читання/записи VM зазвичай працювали — доки pipeline шаблонів не запустився на повну.
Раптом задачі провалювались з «error opening» і «permission denied», і команда ганялася за мережею, бо збої були періодичні.

Реальна причина була в тому, що деякі операції вимагали записів метаданих (створення снапшоту, клонування, flatten), які блокували їхні caps.
Збої були періодичними, бо ці операції запускались періодично.

Вони виправили це, розділивши обов’язки: один Ceph-клієнт для «runtime I/O VM» з чітко обмеженим доступом до пулу,
інший — для «керування образами» під автоматизацією, з додатковими правами і більш суворим контролем операцій.
Least privilege вижив. Просто його потрібно було підлаштувати під реальні робочі процеси, а не під побажання.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Команда фінансових послуг мала звичку, яка виглядала майже комічно: на кожному вузлі був невеликий локальний скрипт, що щодня перевіряв доступ клієнта Ceph.
Він запускав ceph -s, rbd ls і rbd info проти відомого образу, використовуючи точні креденшали, які використовував Proxmox.
Результати логувалися локально і також піднімався простий метрик «ok/fail».

В один день адміністратор Ceph провів ротацію ключів у вікні змін. Зміна була коректною, caps були в порядку, кластер Ceph лишився здоровим.
Але один вузол Proxmox пропустив оновлення ключа через тимчасовий збій менеджменту конфігурації.

Їхня щоденна перевірка виявила це за кілька годин — до того, як планове обслуговування перемістило навантаження на зламаний вузол.
Замість простою — у них був тикет: «Node pve7 fails RBD open using client.pve.» Ремедіація — синхронізація keyring і повторна перевірка.

Нічого героїчного не сталося. Ніхто не отримав виклик. Ось як виглядає «reliability engineering» у хороший день: менше історій, щоб їх розповідати.

Чеклісти / покроковий план

Чекліст A: Коли VM не стартує з «error opening»

1. З проблемного вузла візьміть точну помилку та параметри з логів (journalctl -u pvedaemon).
2. Витягніть id=, keyring=, пул, ім’я образу та шлях conf=.
3. Запустіть rbd --conf ... info pool/image --id ... --keyring ....
4. Якщо автентифікація падає: перевірте існування keyring, його коректність та заголовок імені клієнта.
5. Якщо «permission denied»: перевірте caps та обмеження пулом; виправте caps; повторіть тест.
6. Якщо з’єднання з моніторами падає: перевірте порти 3300/6789; підтвердьте mon_host та маршрутизацію/MTU.
7. Після виправлення повторіть старт VM і перевірте читання/запис.

Чекліст B: Додавання нового вузла Proxmox до Ceph-backed кластера

1. Встановіть пакети Ceph client відповідно до вашої версії Proxmox.
2. Скопіюйте /etc/ceph/ceph.conf (або переконайтеся, що /etc/pve/ceph.conf правильний і використовується послідовно).
3. Скопіюйте потрібні keyring-файли: зазвичай /etc/ceph/ceph.client.pve.keyring.
4. Перевірте права файлів: 0600 root:root для keyring.
5. Запустіть: ceph -s і rbd -p <pool> ls --id pve --keyring ....
6. Тільки після цього дозволяйте міграції/HA на цей вузол.

Чекліст C: Безпечніша ротація ключів для Proxmox RBD клієнтів

1. Створіть або оновіть Ceph auth запис (ceph auth get-or-create / ceph auth caps), зберігши обмеження пулом.
2. Експортуйте оновлений keyring-файл.
3. Розподіліть keyring на всі вузли Proxmox (атомарно, якщо можливо).
4. Перевірте, що хеші співпадають між вузлами.
5. Запустіть RBD open тести з кожного вузла, використовуючи той же --conf, що і QEMU.
6. Проведіть канарі: запустіть по одній VM на вузол, виконайте міграцію, створіть снапшот якщо це використовується.
7. Тільки після цього вважайте ротацію завершеною.

Команди, що допомагають автоматизувати перевірку чеклістів

cr0x@server:~$ rbd --conf /etc/pve/ceph.conf info vmdata/vm-101-disk-0 --id pve --keyring /etc/ceph/ceph.client.pve.keyring
rbd image 'vm-101-disk-0':
	size 100 GiB in 25600 objects
	order 22 (4 MiB objects)
	snapshot_count: 2
	id: 1a2b3c4d5e6f
	format: 2
	features: layering, exclusive-lock, object-map, fast-diff, deep-flatten
	op_features:
	flags:
	create_timestamp: Tue Dec 24 09:12:33 2025
	access_timestamp: Tue Dec 24 09:12:33 2025
	modify_timestamp: Thu Dec 26 10:01:07 2025

Рішення: Якщо це працює на кожному вузлі — ви виключили більшість причин «error opening», пов’язаних з автентифікацією/ключами.

Питання та відповіді (FAQ)

1) Чому Proxmox показує «error opening», а не справжню помилку Ceph?

Бо помилка пробивається через шари QEMU/librbd і підсумовується. Детальна причина часто є у рядках journalctl, де видно
«permission denied», «no such file» або помилки з’єднання. Завжди дивіться логи того вузла, що не вдався.

2) Я можу виконати ceph -s успішно — чому Proxmox падає?

Ваш шелл може використовувати інший конфіг-файл (/etc/ceph/ceph.conf) і інший ключ (client.admin через дефолтний keyring).
Proxmox може використовувати /etc/pve/ceph.conf і client.pve. Тестуйте з тим же --conf, --id та --keyring, які ви бачите в логах Proxmox.

3) Чи можу я просто використовувати client.admin, щоб «залагодити» проблему?

Можете, і це «працюватиме», але це погана практика. Це розширює площу ураження і ускладнює аудит. Використовуйте виділеного клієнта з обмеженням пулом та profile rbd.
Зберігайте client.admin для адміністративних задач, а не для рутинного I/O VM.

4) Які мінімальні caps для використання Proxmox RBD?

Зазвичай: mon "profile rbd" і osd "profile rbd pool=<pool>". Якщо ви використовуєте додаткові робочі процеси (снапшоти, клонування, flatten),
зазвичай достатньо profile rbd, але потрібно переконатися, що кластер і клієнти підтримують потрібні операції. Валідовуйте операцію тестом з тією ж ідентичністю.

5) Чому це падає лише під час міграції або створення снапшоту?

Бо міграції та снапшоти використовують інші виклики API. Перелік образів — не те саме, що відкриття образу з певними функціями, створення снапшоту або клонування.
Якщо помилка виникає під час цих операцій — спочатку підозрюйте несумісність caps.

6) Де Proxmox зберігає секрети Ceph?

Proxmox зберігає опис сховища в /etc/pve/storage.cfg. Сам ключ зазвичай у keyring-файлі під /etc/ceph, на який посилаються шляхом.
Деякі налаштування можуть вбудовувати секрети інакше, але патерн «локальний ключ на вузлі» — типовий і саме через нього відбуваються вузлові невідповідності.

7) Як відрізнити проблему з моніторами від проблеми з автентифікацією?

Якщо ви бачите таймаути і «error connecting to the cluster», перевірте мережеву досяжність до портів MON (3300/6789) і підтвердіть mon_host.
Якщо ви швидко бачите «permission denied», монітори доступні і ймовірно проблема в автентифікації/caps.

8) Чи потрібно перезапускати сервіси Proxmox після виправлення keyring або caps?

Часто ні; нові задачі підхоплюють оновлений keyring. Але якщо ви змінили якийсь конфіг, що використовується QEMU або оновили дефініцію сховища,
перезапуск pvedaemon і повтор виконання задачі може позбутися застарілих станів. Дійте цілеспрямовано; не перезавантажуйте вузли «лікувально».

9) Який найшвидший безпечний тест, щоб підтвердити виправлення?

Запустіть rbd info pool/image з тим же --conf, --id та --keyring, що й QEMU, з вузла, який падав.
Потім стартуйте одну VM, що використовує цей образ. Якщо ви залежать від снапшотів/клонів — також протестуйте одну з тих операцій.

10) Чи може це бути баг Ceph або пошкодження даних?

Може, але якщо кластер здоровий і помилка — «permission denied» або «keyring not found», то це не корупція даних.
Почніть з автентифікації/конфігурації; 95% інцидентів «error opening» — це самостійні паперові порізи.

Висновок: наступні кроки, які можна зробити сьогодні

Якщо ви хочете, щоб «error opening» перестав бути постійним гостем вашого on-call життя, зробіть три речі:

1. Уніфікуйте, який файл конфігурації використовує QEMU (/etc/pve/ceph.conf vs /etc/ceph/ceph.conf) і зробіть їх однаковими на всіх вузлах.
2. Використовуйте виділеного Ceph-клієнта (наприклад, client.pve) з обмеженими правами profile rbd по пулу. Припиніть використовувати client.admin для рутинного I/O VM.
3. Зробіть keyring першокласним артефактом розгортання: розповсюджуйте їх на всі вузли, перевіряйте хеші і валідовуйте доступ автоматизованим тестом rbd info.

Хороша новина: коли ви почнете ставитись до keyring і caps як до продакшен-конфігурації (а не як до племінного знання), Ceph стане передбачувано нудним. Оце й є мета.

Швидкий план діагностики (перевірте спочатку це)

Якщо у вас є лише п’ять хвилин до того, як хтось важливий запитає, чому не можна опублікувати допис гендиректора, робіть це в порядку. Ця послідовність швидко знаходить вузьке місце, бо слідує шляху автентифікації: браузер → edge-кеш → зворотний проксі → PHP → база даних.

1) Підтвердіть, чи встановлюються cookie і повертаються

• Перевірте: Чи отримує браузер Set-Cookie після POST з обліковими даними?
• Потім: Чи включає наступний запит до /wp-admin/ ті ж cookie?
• Чому: «Петля входу» часто означає, що WordPress каже «я не отримав дійсну auth cookie», тому повертає вас назад.

2) Переконайтеся, що канонічний URL і схема узгоджені

• Перевірте: Чи перескакуєте ви між http та https або між www та кореневим доменом?
• Чому: Cookie мають область дії, прив’язану до домену й схеми. Якщо POST для входу відбувається на одному хості/схемі, а адміністрування завантажується на іншому — cookie може не працювати.

3) Обійдіть кеші та рівні безпеки

• Перевірте: Чи кешує edge, WAF, «плагін продуктивності» або зворотний проксі wp-login.php або чи не змінюють вони заголовки?
• Чому: Ендпоїнти автентифікації динамічні. Кешувати їх — те саме, що написати на дверях «іноді відчинено».

4) Безпечно відключіть плагіни, потім — тему

• Перевірте: Чи зникає проблема після відключення плагінів?
• Чому: Один «захисний» або «cookie consent» плагін може поламати автентифікацію винахідливими способами.

5) Перевірте серверні сесії, PHP та запис у БД

• Перевірте: Чи PHP записує сесії? Чи БД доступна для запису? Є фатальні помилки?
• Чому: Якщо WordPress не може встановити стан, пов’язаний з автентифікацією (або є дивності з object cache), він не зможе утримувати вас у системі.

Як насправді працює потік входу WordPress (щоб не боротися із привидами)

Вхід у WordPress базується на cookie. Коли ви відправляєте облікові дані на wp-login.php, WordPress:

1. Перевіряє ім’я користувача/пароль (або SSO) та статус/права користувача.
2. Видає автентифікаційні cookie: зазвичай wordpress_logged_in_* та wordpress_sec_* (імена залежать від хешів/солей і налаштувань).
3. Перенаправляє вас (302) до /wp-admin/ або в цільову адресу.
4. У наступному запиті WordPress читає cookie, перевіряє їх щодо солей і запису користувача і або дозволяє доступ, або знову перенаправляє на вхід.

«Петля входу» означає одну з трьох речей:

• Cookie ніколи не були встановлені (блоковані, видалені, кешована відповідь, невірні заголовки).
• Cookie були встановлені, але не надсилаються назад (помилкова область домену, невідповідність secure-флагу, шлях, проблеми SameSite у певних потоках).
• Cookie надіслано, але відхилено (зламані солі після міграції, невідповідність DB/object cache, різниця часу, дивності в user meta, кастомний плагін автентифікації).

Практичне правило: ставтесь до цього як до налагодження розподілених систем. Є кілька шарів, і будь-який з них може «дружньо» переписати ваш запит у відмову.

Парафраз від авторитету надійності: надія — це не стратегія. — у дусі Gene Kranz (мислення місійних операцій).

Жарт №1: Петля входу WordPress — це єдиний кардіотренажер, який деякі з нас отримують за робочий день. Це не чудова програма добробуту.

Цікаві факти та історичний контекст (коротко, корисно)

• Факт 1: WordPress використовує автентифікацію на основі cookie з ранніх релізів; імена cookie включають хеші, що походять із налаштувань сайту та солей, тому після міграцій логіни можуть «випадково» зламатися.
• Факт 2: Ендпоїнт wp-login.php — один із найчастіше атакованих публічних URL в інтернеті; багато хостинг-стеків додають правила WAF або обмеження швидкості, які можуть тонко заважати легітимним входам.
• Факт 3: Адмін-панель сильно покладається на перенаправлення (канонічний хост, примусове SSL, місцезнаходження адмінки). Неправильна конфігурація перенаправлень породжує петлі швидше, ніж майже будь-який інший баг сайту.
• Факт 4: Браузери посилили політику обробки cookie з часом (зокрема щодо SameSite), що може зломити потоки входу, які включають крос-сайтові POST або зовнішні IdP, якщо cookie встановлені неправильно.
• Факт 5: Багато CDN з «кешуйте все» колись постачалися з наївними налаштуваннями; сучасні конфігурації зазвичай виключають wp-admin і wp-login.php, але це все одно постійно конфігурують неправильно.
• Факт 6: WordPress зберігає канонічні URL (home і siteurl) у базі, але дозволяє перекривати їх через wp-config.php. Конфлікти між цими значеннями — класичний генератор петлі.
• Факт 7: Зворотний проксі (балансувальник навантаження, CDN, ingress) змінює значення «чи це HTTPS?» якщо форвард-заголовки некоректні; WordPress використовує це, щоб вирішити secure-флаги cookie і цілі перенаправлення.
• Факт 8: Object cache (Redis/Memcached) може робити автентифікацію «моторошною», коли застарілі значення залишаються після розгортань або коли кілька серверів мають різні солі/конфігурації.

Реальні причини петлі входу (відсортовано за частотою)

1) Невідповідність URL, хоста або HTTPS (канонічна тредміл-перенаправлення)

WordPress прагне одного істинного URL для сайту. Якщо ваш стек обслуговує кілька варіантів — http, https, з/без www, можливо альтернативний домен — POST для входу може бути на одному варіанті, а перенаправлення до /wp-admin/ потрапляти на інший. Cookie не пересуваються так, як ви б цього хотіли.

Типові тригери:

• home та siteurl налаштовані по-різному (один http, інший https).
• Примусове HTTPS на балансувальнику, але WordPress вважає, що це plain HTTP.
• Правила перенаправлення в Nginx/Apache конкурують з канонічними перенаправленнями WordPress.

2) Cookie заблоковані, видалені або неправильно обмежені

Якщо cookie не встановлюються або не повертаються, WordPress не може утримати вас у системі. Причини включають:

• Проксі/CDN видаляє заголовки Set-Cookie для «кешованості».
• Несумісність домену/шляху cookie після зміни домену.
• Secure-cookie для HTTPS не працює, бо WordPress не виявляє HTTPS (тоді він встановлює не-secure cookie, а ви потім переходите на HTTPS і їх не приймають).
• Плагіни з управлінням cookie або безпеки, що неправильно переписують заголовки.

3) Кеш (edge, плагін, сервер) кешує неправильні речі

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

4) Конфлікти плагінів/тем, особливо безпеки та SSO

Плагіни безпеки, містки SSO, плагіни 2FA та пакети «відключити XML-RPC» часто підписуються на фільтри аутентифікації. Одне погане оновлення може ввести перенаправлення, яке ніколи не завершується.

5) Зламані солі/ключі після міграції або дріфт конфігурації між серверами

WordPress підписує auth-cookie солями й ключами в wp-config.php. Якщо ви їх зміните, існуючі cookie стануть недійсними (це нормально), але якщо у вас декілька апп-серверів із різними солями — користувачі втрачатимуть сесії або потраплятимуть у петлі залежно від того, до якого бекенду їх спрямовано.

6) Розбіжності часу або дивності TLS-термінації

Auth-cookie містять час життя. Якщо системний час неправильний (дрейф VM, проблеми в контейнері, NTP не працює), cookie можуть виглядати миттєво простроченими. Менш поширено, але вражає, коли відбувається.

7) Збої запису в БД або файловій системі та тонкі фатали

Автентифікація WordPress покладається на читання/запис у БД і на коректне виконання PHP. Якщо PHP завершується фатально після встановлення перенаправлення або БД тільки для читання, ви можете опинитися в петлі без очевидної помилки. Перевіряйте логи ретельно.

Практичні завдання: команди, вивід і рішення (12+)

Ось практичні завдання, які можна виконати на типовому Linux-хості. Налаштуйте шляхи, якщо у вас інша дистрибуція чи структура. Кожне завдання містить: команду, що означає вивід, і рішення для наступного кроку.

Завдання 1: Відтворіть ланцюжок перенаправлень з боку сервера

cr0x@server:~$ curl -I -L https://example.com/wp-admin/ | sed -n '1,40p'
HTTP/2 302
location: https://example.com/wp-login.php?redirect_to=https%3A%2F%2Fexample.com%2Fwp-admin%2F&reauth=1
set-cookie: wp-wpml_current_language=en; path=/
server: nginx

HTTP/2 200
content-type: text/html; charset=UTF-8
cache-control: no-store, no-cache, must-revalidate, max-age=0

Що це означає: Один 302 на логін — нормальна поведінка, якщо ви не авторизовані. Якщо ви бачите повторювані 302, що відскакують між wp-login.php і wp-admin, у вас є петля.

Рішення: Якщо петля з’являється тут без браузера — це серверна логіка перенаправлень або проблема канонічного URL, а не «мій браузер божевільний».

Завдання 2: Перевірте, чи кешує проксі/CDN сторінку входу

cr0x@server:~$ curl -I https://example.com/wp-login.php | egrep -i 'cache|age|cf-cache-status|x-cache|via|set-cookie'
cache-control: no-store, no-cache, must-revalidate, max-age=0
set-cookie: wordpress_test_cookie=WP%20Cookie%20check; path=/; secure; HttpOnly

Що це означає: Ви хочете бачити no-store або подібні обмежувальні директиви. Якщо бачите заголовки на кшталт x-cache: HIT або статус кешування CDN, це підозріло.

Рішення: Якщо кешується — налаштуйте CDN/зворотний проксі, щоб обходити кеш для /wp-login.php і /wp-admin/*, і ніколи не видаляти Set-Cookie.

Завдання 3: Підтвердіть канонічні URL WordPress (WP-CLI)

cr0x@server:~$ cd /var/www/html
cr0x@server:/var/www/html$ wp option get home
https://example.com
cr0x@server:/var/www/html$ wp option get siteurl
http://example.com

Що це означає: Ця невідповідність (https vs http) — класичний тригер петлі.

Рішення: Встановіть їх однаково (схема та хост). Виберіть один канонічний URL і дотримуйтесь його.

Завдання 4: Безпечно виправте home та siteurl

cr0x@server:/var/www/html$ wp option update home 'https://example.com'
Success: Updated 'home' option.
cr0x@server:/var/www/html$ wp option update siteurl 'https://example.com'
Success: Updated 'siteurl' option.

Що це означає: WordPress генеруватиме cookie/перенаправлення на основі цих значень.

Рішення: Повторіть спробу входу. Якщо петля лишається — переходьте до виявлення HTTPS і заголовків проксі.

Завдання 5: Перевірте, чи WordPress вважає запит HTTPS (за проксі)

cr0x@server:~$ grep -R "HTTPS" -n /var/www/html/wp-config.php | head
# (no output)

Що це означає: Немає явного примусу HTTPS на рівні програми. Це нормально, якщо форвард-заголовки коректні, але ризиковано, коли вони не вірні.

Рішення: Якщо TLS завершується на балансувальнику й трафік до PHP іде по HTTP, переконайтеся, що X-Forwarded-Proto встановлений і враховується, або додайте умовно $_SERVER['HTTPS']='on' у wp-config.php.

Завдання 6: Перевірте форвард-заголовки в Nginx (поширена причина)

cr0x@server:~$ sudo nginx -T 2>/dev/null | egrep -n "X-Forwarded-Proto|X-Forwarded-For|fastcgi_param"
112:    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
113:    proxy_set_header X-Forwarded-Proto $scheme;
210:    fastcgi_param HTTPS $https if_not_empty;

Що це означає: Якщо ви за проксі, $scheme може бути http між проксі та origin навіть коли клієнт використовував HTTPS. Це змушує WordPress думати, що він на HTTP.

Рішення: Налаштуйте форвард-прото від edge (LB → origin). Часто потрібно, щоб Nginx довіряв X-Forwarded-Proto від LB і передавав його в PHP.

Завдання 7: Перевірте заголовки відповіді на предмет відсутніх/переписаних cookie

cr0x@server:~$ curl -s -D - https://example.com/wp-login.php -o /dev/null | sed -n '1,40p'
HTTP/2 200
date: Fri, 27 Dec 2025 11:20:00 GMT
content-type: text/html; charset=UTF-8
set-cookie: wordpress_test_cookie=WP%20Cookie%20check; path=/; secure; HttpOnly

Що це означає: Ви отримуєте Set-Cookie хоча б для тестового cookie. Після POST з обліковими даними ви повинні бачити й автентифікаційні cookie.

Рішення: Якщо Set-Cookie зникає тільки на POST — підозрюйте правила WAF, кешування або плагін, що помирає під час відповіді.

Завдання 8: Зробіть POST на wp-login.php і перевірте auth-cookie (імітація з сервера)

cr0x@server:~$ curl -s -D - -o /dev/null -X POST https://example.com/wp-login.php \
  -d "log=admin&pwd=wrongpassword&wp-submit=Log+In&redirect_to=https%3A%2F%2Fexample.com%2Fwp-admin%2F&testcookie=1" | egrep -i 'HTTP/|set-cookie:|location:'
HTTP/2 200
set-cookie: wordpress_test_cookie=WP%20Cookie%20check; path=/; secure; HttpOnly

Що це означає: З неправильними обліковими даними ви не отримаєте auth-cookie; ви маєте бачити 200 із сторінкою помилки.

Рішення: Якщо навіть правильні облікові дані не породжують auth-cookie (ви б побачили додаткові рядки set-cookie), переходьте до логів PHP і ізоляції плагінів.

Завдання 9: Перевірте PHP-FPM і веб-логи на предмет фаталів, пов’язаних з автентифікацією

cr0x@server:~$ sudo tail -n 80 /var/log/php8.2-fpm.log
[27-Dec-2025 11:18:32] WARNING: [pool www] child 2147 said into stderr: "PHP Warning:  Cannot modify header information - headers already sent by (output started at /var/www/html/wp-content/plugins/foo/foo.php:12) in /var/www/html/wp-includes/pluggable.php on line 1428"

Що це означає: «Headers already sent» може перешкоджати встановленню cookie. Без cookie — немає входу. Якийсь плагін вивів щось (навіть пробіли) до того, як WordPress міг встановити заголовки.

Рішення: Вимкніть проблемний плагін. Потім виправте його (або замініть), бо проблема повертатиметься.

Завдання 10: Вимкніть плагіни, не заходячи в wp-admin

cr0x@server:~$ cd /var/www/html
cr0x@server:/var/www/html$ wp plugin deactivate --all
Success: Deactivated 14 of 14 plugins.

Що це означає: Ви прибрали вплив плагінів із рівня проблеми.

Рішення: Спробуйте знову увійти. Якщо виправилося — вмикайте плагіни по одному, щоб знайти винного.

Завдання 11: Переключіться на стандартну тему, щоб виключити тему як джерело проблем

cr0x@server:/var/www/html$ wp theme list
+----------------+----------+--------+---------+
| name           | status   | update | version |
+----------------+----------+--------+---------+
| twentytwentyfour | inactive | none   | 1.2     |
| corp-theme     | active   | none   | 4.8.1   |
+----------------+----------+--------+---------+
cr0x@server:/var/www/html$ wp theme activate twentytwentyfour
Success: Switched to 'Twenty Twenty-Four' theme.

Що це означає: Якщо тема має кастомні редиректи для входу, SSO-хуки або проблеми з буферизацією виводу, це ізолює тему.

Рішення: Якщо це вирішує петлю, ваша «гарна корпоративна тема» — тепер інцидент у продакшені. Поводьтеся відповідно.

Завдання 12: Перевірте дріфт солей/ключів у конфігурації між серверами (швидкий diff)

cr0x@server:~$ sudo egrep "AUTH_KEY|SECURE_AUTH_KEY|LOGGED_IN_KEY|NONCE_KEY" -n /var/www/html/wp-config.php
54:define('AUTH_KEY',         '...a...');
55:define('SECURE_AUTH_KEY',  '...b...');
56:define('LOGGED_IN_KEY',    '...c...');
57:define('NONCE_KEY',        '...d...');

Що це означає: Ці значення мають бути ідентичні на всіх апп-серверах за лоад-балансером.

Рішення: Якщо у вас кілька origin-ів, перевірте відповідність у всіх місцях. Якщо не збігаються — виправте деплой, щоби конфігурація була консистентною.

Завдання 13: Перевірте системний час і синхронізацію NTP (перевірка строків cookie)

cr0x@server:~$ timedatectl
               Local time: Fri 2025-12-27 11:20:44 UTC
           Universal time: Fri 2025-12-27 11:20:44 UTC
                 RTC time: Fri 2025-12-27 11:20:44
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Що це означає: Якщо годинники відстають або NTP неактивний — cookie можуть виглядати простроченими миттєво.

Рішення: Якщо синхронізація відсутня — виправте час спочатку. Не діагностуйте автентифікацію на сервері, який не погоджується щодо «тепер».

Завдання 14: Перевірте стан Redis object cache (якщо використовується)

cr0x@server:~$ redis-cli ping
PONG
cr0x@server:~$ redis-cli info | egrep "used_memory_human|maxmemory_human|evicted_keys"
used_memory_human:312.45M
maxmemory_human:512.00M
evicted_keys:18422

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

Рішення: Якщо евікшенів багато — збільште пам’ять кешу або зменшіть використання кешу. Переконайтеся, що плагін object cache підходить і налаштований коректно.

Завдання 15: Переконайтеся, що БД доступна для запису і не повертає помилок

cr0x@server:~$ mysql -N -e "SHOW GLOBAL VARIABLES LIKE 'read_only';"
read_only	OFF

Що це означає: Якщо БД у режимі read-only (або вона падає), WordPress може поводитися непередбачувано, особливо коли плагіни записують user meta чи сесії.

Рішення: Якщо read-only увімкнено несподівано — виправте стан реплікації/фейловеру або вкажіть WordPress на правильний primary.

Завдання 16: Перевірте, що wp-content не тільки для читання (оновлення й деякі автентифікаційні потоки)

cr0x@server:~$ sudo -u www-data test -w /var/www/html/wp-content && echo "wp-content writable" || echo "wp-content NOT writable"
wp-content writable

Що це означає: Не кожна петля входу пов’язана з записом у файли, але проблеми з правами часто супроводжують пошкоджені розгортання та «headers already sent» проблеми.

Рішення: Якщо не доступно для запису і ваш стек очікує можливість запису — виправте власника/права; якщо стек забороняє записи, переконайтеся, що плагіни/теми не намагаються робити запис під час виконання, що ламає відповіді.

Типові помилки: симптом → корінь → виправлення

Симптом: Правильний пароль, миттєве перенаправлення назад на wp-login.php, без повідомлень

Корінь проблеми: Cookie не зберігаються або не повертаються (несумісність домену, невідповідність secure-флагу, «headers already sent», проксі видаляє Set-Cookie).

Виправлення: Перевірте узгодженість home/siteurl, перевірте заголовки відповіді на Set-Cookie, усуньте попередження PHP «headers already sent», і відключіть кешування на сторінках входу/адміністрування.

Симптом: Працює в одному браузері/пристрої, не працює в іншому

Корінь проблеми: Різниця політик cookie (поведінка SameSite, блокування сторонніх cookie), застарілі cookie, або розширення браузера, що змінює запити.

Виправлення: Тестуйте у чистому профілі/інкогніто, очистіть cookie для сайту, забезпечте, щоб потік входу був first-party (без крос-сайтових POST), і підтвердіть HTTPS та канонічний хост.

Симптом: Працює через origin напряму, не працює через CDN/WAF

Корінь проблеми: Edge кешує login/admin, сторінки виклику WAF, видалення заголовків або захист від ботів помилково визначає людей як ботів.

Виправлення: Обходьте кеш для ендпоїнтів автентифікації, додайте allowlist для IP адмінів за потреби, і переконайтеся, що challenge-сторінки не застосовуються до POST на wp-login.php.

Симптом: Помилка лише при увімкненні «Примусового HTTPS» або HSTS

Корінь проблеми: WordPress не виявляє HTTPS за проксі; він встановлює cookie або робить перенаправлення неконсистентно.

Виправлення: Виправте форвард-заголовки і/або реалізуйте виявлення HTTPS у wp-config.php. Забезпечте, щоб лише один шар відповідав за канонічні перенаправлення.

Симптом: Випадкові виходи/петлі в середовищі з балансуванням навантаження

Корінь проблеми: Різні солі/ключі на апп-серверах, неконсистентний wp-config.php, або відсутні sticky sessions, якщо їх вимагає плагін.

Виправлення: Зробіть конфігурацію незмінною та ідентичною на всіх вузлах. Уникайте залежності від sticky sessions; якщо не можна — налаштуйте їх явно й задокументуйте причину.

Симптом: Вхід працює, але wp-admin відразу виводить після кількох кліків

Корінь проблеми: Плагін кешу кешує admin-ajax, агресивний плагін безпеки інвалідовує сесії, або зсув часу.

Виправлення: Виключіть admin-шляхи з кешу, налаштуйте правила безпеки і перевірте синхронізацію часу.

Симптом: Лише адміністратори не можуть увійти; редактори можуть

Корінь проблеми: Політики перенаправлення для адміністраторів, неправильне налаштування 2FA, перевірки прав або кастомний mu-плагін.

Виправлення: Перевірте must-use плагіни та налаштування безпеки; тестуйте з усіма плагінами відключеними; перегляньте серверні логи на предмет перенаправлень за ролями.

Чеклісти / покроковий план

Чекліст A: Однопрохідне «поверніть мене в wp-admin» відновлення

1. Очистіть cookie браузера для сайту (або використайте приватне вікно). Якщо й там не вдається увійти — це не «застарілі cookie».
2. Підтвердіть канонічний URL:
   • Зробіть home і siteurl ідентичними (схема + хост).
   • Виберіть або www, або кореневий домен і дотримуйтеся цього.
3. Тимчасово обійдіть CDN/WAF (файл hosts / прямий доступ до origin), щоб перевірити, чи edge — проблема.
4. Вимкніть усі плагіни через WP-CLI або перейменування wp-content/plugins.
5. Переключіться на стандартну тему, щоб виключити тему як джерело проблем.
6. Перевірте логи на предмет «headers already sent» та фаталів.
7. Виправте виявлення HTTPS за проксі (форвард-заголовки або умовне встановлення HTTPS у wp-config.php).
8. Повторно вмикайте плагіни по одному. Зупиніться, коли петля повернеться. Цей плагін — ваш винуватець, а не жертва.

Чекліст B: Загартування, щоб це не повернулося наступного вівторка

1. Виключіть ендпоїнти автентифікації з кешу: /wp-login.php, /wp-admin/*, та за потреби /wp-json/ для адмінських потків.
2. Стандартизувати деплой конфігурації: одне джерело істини для wp-config.php і солей, доставлене ідентично на всі вузли.
3. Моніторинг перенаправлень: відстежуйте рівень 302 для wp-login.php і wp-admin. Сплеск часто — ранній сигнал.
4. Логування на edge і origin: включайте ідентифікатори запитів, щоб відслідковувати одну спробу входу через стек.
5. Документуйте політику канонічного URL (хост, схема, HSTS). Недописана політика стає фольклором; фольклор — інцидентами.
6. Тестуйте після змін: коли змінюєте правила CDN, термінацію HTTPS або плагіни кешу — явно тестуйте потік входу.

Жарт №2: Найшвидший спосіб створити петлю входу WordPress — сказати: «Це лише невелика зміна редиректу». Петля це почує.

Три корпоративні історії з практики

Інцидент №1: Неправильне припущення (HTTPS — це HTTPS, так?)

Середня компанія запускала WordPress за балансувальником, який термінував TLS. Origin-сервери спілкувалися внутрішньо по plain HTTP. Команда вважала, що раз у браузері є замочок — додаток «знає», що це HTTPS.

Одного дня редактори почали скаржитися на петлю входу. Не всі — але достатньо, щоб викликати паніку й шквал повідомлень у Slack. Балансувальник було замінено в рамках оновлення мережі, і поведінка заголовків за замовчуванням змінилася.

На origin WordPress почав бачити запити як HTTP. Він відповідав перенаправленнями на HTTPS (бо home був https), але також встановлював cookie так, що це не відповідало очікуванням браузера. Історія auth-cookie стала неконсистентною між запитами. Користувачі входили, їх перенаправляло, а потім до них ставилися як до незнайомців і повертали назад.

Вирішення було банальним: забезпечити коректну установку X-Forwarded-Proto: https на edge і впевнитися, що origin йому довіряє. Коли WordPress отримав стабільне уявлення про схему, петля зникла.

Урок: у проксованому середовищі «HTTPS» — не факт, а твердження, передане заголовками. Якщо ви явно не керуєте цим твердженням, додаток вигадає свою реальність.

Інцидент №2: Оптимізація, що обернулася проти (кешувати все)

Інша організація мала ініціативу продуктивності. Хтось увімкнув агресивне правило CDN для кешування більшої кількості HTML, включно з «низькоризиковими» сторінками. wp-login.php виглядав як «ще одна сторінка» у наборі правил. Це була перша помилка.

За кілька годин коефіцієнт успішних логінів упав. Не до нуля — але достатньо, щоб заплутати. CDN видавав кешовані сторінки входу із застарілими nonce і невідповідними цільовими редиректами. Ще гірше — деякі кешовані відповіді не включали Set-Cookie коректно, залежно від того, як edge трактував «некешовані» заголовки.

Інцидент став питанням політики, бо зміни позиціонувалися як «робота над продуктивністю», а продуктивність має вигляд героя. Натомість вона перетворила автентифікацію на імовірнісний театр.

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

Урок: кеш — не хаммер, а скальпель. Якщо ви махаєте ним як молотом, ви рано чи пізно влучите у власну систему входу.

Інцидент №3: Нудна, але правильна практика, що врятувала день (імутований конфіг)

Компанія запускала WordPress на кількох апп-серверах. Вони мали сувору практику: конфігурація, включно з солями й ключами, керувалася централізовано й деплоїлась однаково з кожним релізом. Ніяких ручних правок. Ніяких «швидких фіксів» на окремих вузлах.

Вони все одно мали інцидент — інженер додав новий вузол у стані стресу. Вузол прийшов зі старішого образу і спочатку мав неузгоджений wp-config.php. У багатьох середовищах це спричинило б випадкові петлі входу залежно від того, до якого бекенду потрапляє користувач.

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

Вони виправили образ, пере-розгорнули і продовжили роботу. Жодної нічної «чому це лише у деяких користувачів» детективної сесії.

Урок: найнадійніше виправлення автентифікації — запобігти невідповідності. Друге за надійністю — не дозволяти невідповідним вузлам обслуговувати трафік.

Питання та відповіді

Чому WordPress продовжує перенаправляти мене на сторінку входу після входу?

Бо WordPress не отримує або не приймає дійсну auth-cookie у наступному запиті. Зазвичай це спричинено невідповідністю URL/схеми, проблемами з областю cookie, кешуванням, заголовками проксі або плагіном, що втручається в заголовки.

Чи очищення cookie — це справжнє вирішення?

Очищення cookie — це діагностичний крок. Якщо воно раз вирішило проблему, ймовірно ви нещодавно змінили солі/ключі або була тимчасова невідповідність cookie. Якщо не допомагає — проблема в стеку, а не в браузері.

Чи може CDN або WAF спричинити петлю входу?

Абсолютно. Якщо CDN кешує wp-login.php, видаляє Set-Cookie або виконує challenge на POST-запити — ви застрягнете в петлі. Обійдіть edge, щоб підтвердити, потім додайте явні правила обходу.

У чому різниця між home і siteurl, і чому це важливо?

siteurl — це місце, де живуть ядрові файли WordPress; home — це те, що сайт вважає своїм публічним URL. Якщо вони не узгоджуються (особливо схема/хост), перенаправлення і область cookie можуть зламати автентифікацію.

Я за балансувальником. Який заголовок має найбільше значення?

X-Forwarded-Proto. Якщо він неправильний або йому не довіряють, WordPress може вважати, що він працює по HTTP, навіть коли клієнт використовує HTTPS, що призведе до зламаних перенаправлень і флагів cookie.

Чи може це бути плагін, навіть якщо сайт працює для відвідувачів?

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

Чому це відбувається лише у деяких користувачів у балансованому середовищі?

Зазвичай через дріфт конфігурації (різні солі/ключі) або припущення про стейтфул-стан. Якщо один бекенд відкидає cookie, створені іншим, ви отримаєте «працює іноді» поведінку. Зробіть конфіг ідентичною і уникайте стейтфул-хитрощів.

Чи допоможе скидання солей WordPress виправити петлю входу?

Скидання солей анулює всі сесії, що може «вирішити» петлі, спричинені неконсистентними або скомпрометованими cookie. Але якщо корінь проблеми — заголовки проксі, кеш або невідповідність URL — це не допоможе — користувачі просто будуть викинуті і все одно лишаться в петлі.

Що робити, якщо я не можу отримати доступ до wp-admin або WP-CLI взагалі?

Перейменуйте директорію плагінів через SSH, щоб відключити їх усіх: wp-content/plugins → plugins.disabled. Якщо це вирішує вхід — повертайте плагіни поступово. Якщо ні — зосередьтеся на home/siteurl та виявленні HTTPS за проксі.

Висновок: наступні кроки, щоб уникнути повторення

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

Практичні наступні кроки:

1. Зробіть home і siteurl ідентичними (схема + хост).
2. Переконайтеся, що ваш проксі/CDN не кешує і не змінює wp-login.php і /wp-admin/, і ніколи не видаляє Set-Cookie.
3. Перевірте виявлення HTTPS за проксі через форвард-заголовки.
4. Вимкніть плагіни/теми, щоб ізолювати вивід заголовків і хуки автентифікації; вмикайте по одному.
5. Уніфікуйте wp-config.php (особливо солі/ключі) на всіх вузлах і тримайте час синхронізованим.

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

Що насправді робить ZED (і чого не робить)

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

На високому рівні ZED слухає події ZFS (які походять із ZFS ядра та утиліт у userland) і запускає невеликі обробні скрипти,
звані zedlet. Ці скрипти можуть надсилати листи, писати в syslog/journald, запускати гарячий spare, записувати історію
або інтегруватися з тією системою оповіщень, якій ви довіряєте о 3 ранку.

Лінія розмежування

• ZFS виявляє та записує: помилки, стан degraded, початок/завершення resilver, початок/завершення scrub, збої пристроїв тощо.
• ZED реагує й повідомляє: «щось сталося, ось деталі, зробіть це далі».
• Ваша система моніторингу корелює та ескалює: повідомляє людей, відкриває тикети, відстежує MTTR і робить це чиєюсь проблемою.

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

Один оперативний вислів, який варто тримати поруч із рукописами:
Надія — не стратегія. — Ген. Гордон Р. Салліван

Жарт №1: Відмови зберігання як стоматологи — якщо ви бачите їх тільки коли болить, ви вже переплачуєте.

Факти та історія, що важливі в опсах

ZED — це не просто «якийсь демон». Це операційна поверхня ZFS. Декілька фактів і контекст полегшать розуміння того,
що ви розгортаєте і чому воно поводиться так, як поводиться:

1. ZFS виник у Sun Microsystems в середині 2000-х з філософією «сховище як система»: контрольні суми, pooling, snapshots, самовідновлення.
2. ZFS спроектовано так, щоб не довіряти дискам за замовчуванням. end-to-end контрольні суми — це не фіча; це припущення.
3. OpenZFS з’явився як кросплатформена ініціатива після фрагментації оригінальної лінії Solaris ZFS; сьогодні Linux, FreeBSD та інші слідкують за OpenZFS.
4. ZED виник із потреби операціоналізувати події про збої. Виявити збій марно, якщо ніхто про це не дізнається.
5. ZFS має внутрішній потік подій (думайте: «зміни станів і звіти про збої»), і ZED — споживач, що перетворює події на дії.
6. Scrub — це первинний інструмент обслуговування у ZFS: періодичне повне читання для виявлення і виправлення прихованої корупції поки є надмірність.
7. «Degraded» не означає «впав» у ZFS, саме тому це небезпечно: сервіс працює, але ваш запас надійності вичерпано.
8. Resilver і scrub — різні речі: resilver — цільовий ремонт/реконструкція після заміни або приєднання пристрою; scrub — перевірка цілого пулу.
9. Багато «помилок» ZFS — це насправді попередження, а не інцидент: checksum-помилки часто означають, що система виявила погані дані і успішно їх відновила.

Операційний висновок: ZFS балакучий у потрібних місцях. ZED — як його слухати, не живучи в zpool status як у соціальній мережі.

Як ZED бачить світ: події, zedlet та стан

Завдання ZED просте: коли трапляється подія ZFS — запустити обробники. Складність — у деталях: які події, які обробники,
як обмежувати їх, і як передати достатньо контексту в оповіщення, щоб діяти не занурюючись у логі.

Джерела подій і форма даних

ZFS випромінює події про зміни стану пулу, помилки пристрою, активність scrub/resilver та дії з управління збоями. ZED отримує їх
і передає поля події в zedlet-скрипти як змінні середовища. Точний набір залежить від платформи й версії OpenZFS, але ви побачите
сталу структуру: ім’я пулу, GUID vdev, шлях пристрою, переходи станів і лічильники помилок.

Zedlet: маленькі скрипти з гострими лезами

Zedlet — це виконавчі скрипти, розміщені в директорії zedlet (звично під /usr/lib/zfs/zed.d на Linux-дистрибутивах,
з симлінками або увімкненими наборами під /etc/zfs/zed.d). Вони навмисно невеликі. У них має бути одне завдання:
сформувати лист, записати в syslog, ініціювати spare, записати рядок історії або викликати локальний інтеграційний скрипт.

Дисципліна: тримайте zedlet детермінованими і швидкими. Якщо потрібна «реальна логіка», хай zedlet поставляє роботу в чергу
(запише файл, відправить на локальний сокет, викличе легкий wrapper) і хай інший сервіс виконає важку роботу. ZED — частина вашого шляху відмов.
Не робіть його громіздким.

Стан і дедуплікація

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

• Тротлінг повідомлень (на пул/вдев і в межах вікна часу).
• Надсилання оповіщень про зміни стану (ONLINE→DEGRADED, DEGRADED→ONLINE), а не про кожне зростання лічильника.
• Надсилання scrub як підсумкових подій (початок, завершення, знайдені помилки) з контекстом.
• Збереження невеликого файлу стану, який відстежує, що вже було відправлено.

На що варто оповіщувати

Не оповіщайте про все. Оповіщення — це контракт із сонними людьми. Ось розумний мінімум:

• Зміни стану пулу: ONLINE→DEGRADED, DEGRADED→FAULTED, видалений пристрій.
• Результати scrub: завершився з помилками, відновлені байти або «занадто багато помилок».
• Checksum/read/write помилки понад поріг або при зростаючій швидкості.
• Події збоїв пристроїв: тайм-аути, I/O збої, «device removed», зміни шляху.
• Завершення resilver: успіх/помилка, тривалість, чи повернувся пул в ONLINE.

Оповіщення, які вам мають бути важливі (і що з ними робити)

Оповіщення ZED має відповідати на три питання: що сталося, що під загрозою і що робити далі.
Якщо ваші оповіщення не містять ім’я пулу, постраждалого vdev і копію zpool status -x або релевантний фрагмент,
ви пишете детективи, а не оповіщення.

DEGRADED пул

«DEGRADED» означає, що ви працюєте із зменшеною надмірністю. Сервіс ще працює, але ще одна відмова може призвести до втрати даних
(залежно від RAIDZ-рівня і розташування vdev). Правильна реакція має часові рамки: дослідіть негайно; замініть оперативно;
не чекайте наступного вікна обслуговування, якщо вам подобається азарт.

Checksum-помилки

Checksum-помилки — це ZFS, що каже «я спіймав погані дані». Це і хороша, і погана новина. Хороша: детекція працює. Погана:
щось ушкоджує дані в стеку — диск, кабель, HBA, прошивка, RAM (якщо немає ECC) або навіть нестабільність живлення.
Рішення залежить від того, чи є помилки ізольованими (один диск, один шлях) чи системними (по всіх vdev).

Read/write помилки

Read-помилки вказують, що пристрій не зміг повернути дані. ZFS може реконструювати з паритету/дзеркал; якщо ні — бачите постійні помилки.
Write-помилки часто вказують на проблеми зі зв’язком, скидання контролера або відмову записів диском. У будь-якому випадку,
зростаючі лічильники — це «замініть або виправте шлях».

Scrub завершився з помилками

Scrub, який відновив дані — це попередження, що надмірність вас врятувала цього разу. Якщо не вжити заходів, наступного разу може не пощастити.
Scrub, що знайшов невідновлені помилки — це інцидент цілісності даних; ваше завдання — оцінити збитки та побудувати стратегію відновлення.

Пристрій видалено / UNAVAIL

Часто це не «диск помер», а «шлях помер». Розхитаний SAS-кабель, негідний expander, баг прошивки HBA, ненадійна бекплейн-плата.
Найшвидший спосіб прожарити вихідні вихідні дні — замінити абсолютно справний диск, коли реальний злочинець — бекплейн.

Практичні завдання: команди, виводи та рішення (12+)

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

Завдання 1: Підтвердити, що сервіс ZED запущено (systemd)

cr0x@server:~$ systemctl status zfs-zed.service
● zfs-zed.service - ZFS Event Daemon (zed)
     Loaded: loaded (/lib/systemd/system/zfs-zed.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2025-12-22 09:14:31 UTC; 2 days ago
   Main PID: 1189 (zed)
      Tasks: 3 (limit: 18982)
     Memory: 7.4M
        CPU: 1min 12s
     CGroup: /system.slice/zfs-zed.service
             └─1189 /usr/sbin/zed -F

Що це означає: «active (running)» — це базова необхідність. Якщо він inactive, події ZFS все одно відбуваються; ви їх просто не чуєте.

Рішення: Якщо не працює, виправте ZED перш ніж довіряти будь-якому «моніторингу», який нібито стежить за ZFS.

Завдання 2: Перевірити останні логи ZED у journald

cr0x@server:~$ journalctl -u zfs-zed.service -n 50 --no-pager
Dec 24 08:03:11 server zed[1189]: ZED: eid=402 class=sysevent.fs.zfs.scrub_finish pool=tank
Dec 24 08:03:11 server zed[1189]: ZED: executing zedlet: /usr/lib/zfs/zed.d/scrub.finish
Dec 24 08:03:11 server zed[1189]: ZED: eid=403 class=sysevent.fs.zfs.vdev_check pool=tank

Що це означає: Ви хочете бачити події та рядки виконання zedlet. Тиша під час відомих подій вказує на помилкову конфігурацію або відсутність подій.

Рішення: Якщо ви бачите події, але немає сповіщень — зосередьтесь на конфігурації zedlet (пошта, дозволи, PATH), а не на самому ZFS.

Завдання 3: Перевірити файл конфігурації ZED

cr0x@server:~$ sudo egrep -v '^\s*(#|$)' /etc/zfs/zed.d/zed.rc
ZED_DEBUG_LOG="/var/log/zed.log"
ZED_EMAIL_ADDR="storage-alerts@example.com"
ZED_EMAIL_PROG="mail"
ZED_NOTIFY_INTERVAL_SECS=3600
ZED_NOTIFY_VERBOSE=1

Що це означає: ZED налаштовано логувати, надсилати пошту і тротлити оповіщення. Відсутність налаштувань пошти — поширена причина «ми думали, що маємо оповіщення».

Рішення: Якщо у вашій організації немає пошти, налаштуйте ZED на виклик wrapper-скрипта, який говорить з вашим alert-менеджером, але зберігайте тротлінг.

Завдання 4: Переконатися, що поштовик існує і працює з хоста

cr0x@server:~$ command -v mail
/usr/bin/mail

cr0x@server:~$ echo "zed test message" | mail -s "zed smoke test" storage-alerts@example.com
...output...

Що це означає: Перша команда доказує, що налаштована поштовая програма існує. Друга — що хост може фактично доставити пошту (через локальну чергу або relay).

Рішення: Якщо пошта не працює — виправте вихідну пошту перш ніж звинувачувати ZED. ZED не може повідомляти через неіснуючий канал.

Завдання 5: Перелічити увімкнені zedlet (які дії ви справді виконуєте)

cr0x@server:~$ ls -l /etc/zfs/zed.d
total 0
lrwxrwxrwx 1 root root 30 Dec 10 10:12 all-syslog.sh -> /usr/lib/zfs/zed.d/all-syslog.sh
lrwxrwxrwx 1 root root 31 Dec 10 10:12 checksum-email.sh -> /usr/lib/zfs/zed.d/checksum-email.sh
lrwxrwxrwx 1 root root 29 Dec 10 10:12 scrub.finish -> /usr/lib/zfs/zed.d/scrub.finish

Що це означає: Багато дистрибутивів розміщують zedlet у /usr/lib і вмикають підмножину через симлінки в /etc.

Рішення: Якщо нічого не увімкнено — ви нічого не отримаєте. Увімкніть лише те, на що зможете реагувати; відключіть шумні, поки не будете готові.

Завдання 6: Швидка перевірка здоров’я пулу (команда «на чи ми вогні»)

cr0x@server:~$ zpool status -x
all pools are healthy

Що це означає: ZFS милосердно лаконічний. Якщо він виводить щось інше — у вас є робота.

Рішення: «Healthy» не означає «без ризику», але означає, що ви наразі не в degraded/faulted стані.

Завдання 7: Глибинний статус коли щось не так

cr0x@server:~$ zpool status tank
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an unrecoverable error.
action: Replace the device using 'zpool replace'.
  scan: scrub repaired 0B in 03:21:18 with 0 errors on Tue Dec 24 08:03:11 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          raidz1-0                  DEGRADED     0     0     0
            ata-WDC_WD80EFAX-1      ONLINE       0     0     0
            ata-WDC_WD80EFAX-2      ONLINE       0     0     0
            ata-WDC_WD80EFAX-3      UNAVAIL      0     0     0  cannot open

errors: No known data errors

Що це означає: Пул degraded, бо один пристрій недоступний. «No known data errors» — добре; надмірність ще тримає.

Рішення: Розглядайте UNAVAIL як термінове. Дослідіть шлях проти диска, потім замініть або відновіть підключення перш ніж трапиться друга відмова.

Завдання 8: Скоординувати імена пристроїв ZFS з реальним обладнанням

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep WD80EFAX-3
lrwxrwxrwx 1 root root  9 Dec 25 01:12 ata-WDC_WD80EFAX-3 -> ../../sde

Що це означає: Ви можете співвіднести стабільний шлях by-id від ZFS з вузлом ядра (/dev/sde), що допомагає зі SMART і мапінгом фізичного слоту.

Рішення: Використовуйте /dev/disk/by-id у пулах, коли можливо; це зменшить випадки «замінили неправильний диск».

Завдання 9: Перевірити SMART-стан підозрілого диска

cr0x@server:~$ sudo smartctl -a /dev/sde | egrep 'SMART overall-health|Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable'
SMART overall-health self-assessment test result: PASSED
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       8
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       2

Що це означає: «PASSED» — не картка «звільнення від відповідальності». Pending та uncorrectable сектори — поганий знак, навіть якщо диск впевнено стверджує про себе.

Рішення: Якщо pending/uncorrectable не нуль і ростуть — замініть диск. Якщо ZFS уже помітив UNAVAIL, дискусії закінчено.

Завдання 10: Переглянути останні повідомлення ядра на предмет скидань лінку або помилок транспорту

cr0x@server:~$ dmesg -T | tail -n 20
[Wed Dec 25 01:10:22 2025] ata9.00: exception Emask 0x10 SAct 0x0 SErr 0x4050000 action 0x6 frozen
[Wed Dec 25 01:10:22 2025] ata9.00: irq_stat 0x08000000, interface fatal error
[Wed Dec 25 01:10:23 2025] ata9: hard resetting link
[Wed Dec 25 01:10:28 2025] ata9: link is slow to respond, please be patient (ready=0)
[Wed Dec 25 01:10:31 2025] ata9: COMRESET failed (errno=-16)
[Wed Dec 25 01:10:31 2025] ata9.00: disabled

Що це означає: Це кричить «проблема шляху». Може бути диск, а може кабель/бекплейн/контролер.

Рішення: Перед масовою заміною дисків пересадіть кабель/змініть слот, якщо можете. Якщо помилки йдуть за слотом — ви знайшли справжню домену відмови.

Завдання 11: Показати лічильники помилок ZFS і спостерігати за зростанням

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: DEGRADED
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          raidz1-0                  DEGRADED     0     0     0
            ata-WDC_WD80EFAX-1      ONLINE       0     0     0
            ata-WDC_WD80EFAX-2      ONLINE       0     0     0
            ata-WDC_WD80EFAX-3      UNAVAIL      3     1     0  cannot open

errors: No known data errors

Що це означає: Лічильники (READ/WRITE/CKSUM) — це докази. Кілька історичних помилок не завжди катастрофа, але зростаючі значення — тренд.

Рішення: Якщо лічильники зростають після переміщення кабелів або перезавантаження — припиніть «пробувати все» і замініть компонент у домені збоїв.

Завдання 12: Правильно замінити відмовлений диск

cr0x@server:~$ sudo zpool replace tank ata-WDC_WD80EFAX-3 /dev/disk/by-id/ata-WDC_WD80EFAX-NEW
...output...

Що це означає: ZFS починає resilver на новий диск, таргетований на виділені блоки (зазвичай швидше, ніж класичні RAID-перебудови).

Рішення: Моніторьте прогрес resilver. Якщо пул залишається degraded після завершення, маються додаткові проблеми (неправильний пристрій, множинні відмови або нестабільність шляху).

Завдання 13: Стежити за прогресом resilver/scrub

cr0x@server:~$ zpool status tank
  pool: tank
 state: DEGRADED
status: One or more devices is currently being resilvered.
  scan: resilver in progress since Wed Dec 25 01:22:10 2025
        312G scanned at 1.12G/s, 44.8G issued at 164M/s, 3.21T total
        44.8G resilvered, 1.36% done, 05:20:11 to go
config:

        NAME                             STATE     READ WRITE CKSUM
        tank                             DEGRADED     0     0     0
          raidz1-0                       DEGRADED     0     0     0
            ata-WDC_WD80EFAX-1           ONLINE       0     0     0
            ata-WDC_WD80EFAX-2           ONLINE       0     0     0
            ata-WDC_WD80EFAX-NEW         ONLINE       0     0     0  (resilvering)

Що це означає: «issued at» відображає фактичну швидкість запису. «scanned at» може бути вищим через метадані та read-ahead.

Рішення: Якщо resilver повзає, не вгадуйте. Перевірте I/O-банки, помилки на інших дисках або проблеми контролера.

Завдання 14: Перевірити розклад scrub і останні результати

cr0x@server:~$ zpool status -s tank
  pool: tank
 state: ONLINE
scan: scrub repaired 0B in 03:21:18 with 0 errors on Tue Dec 24 08:03:11 2025

Що це означає: Ви маєте запис про останнє завершення scrub. Якщо цього не було місяцями, ви їдете без фар.

Рішення: Якщо у вас немає періодичних scrub — заплануйте їх. Якщо вони є, але ви не оповіщаєте про помилки, підключіть ZED зараз.

Завдання 15: Підтвердити доставку подій ZFS до ZED (перевірка)

cr0x@server:~$ sudo zpool scrub tank
...output...

cr0x@server:~$ journalctl -u zfs-zed.service -n 20 --no-pager
Dec 25 01:30:02 server zed[1189]: ZED: eid=510 class=sysevent.fs.zfs.scrub_start pool=tank
Dec 25 01:30:02 server zed[1189]: ZED: executing zedlet: /usr/lib/zfs/zed.d/scrub.start

Що це означає: Запуск scrub породжує подію. Побачити її в логах ZED означає, що потік подій працює.

Рішення: Якщо не бачите подію — усувайте неполадки ZED-сервісу, дозволів або інфраструктури подій ZFS на тій платформі.

Завдання 16: Перевірити, що ZED не блокується через дозволи або відсутні директорії

cr0x@server:~$ sudo -u root test -w /var/log && echo "log dir writable"
log dir writable

cr0x@server:~$ sudo -u root test -x /usr/lib/zfs/zed.d/scrub.finish && echo "zedlet executable"
zedlet executable

Що це означає: Неможливість ZED писати логи або виконувати zedlet — нудна, поширена і руйнівна проблема для оповіщень.

Рішення: Виправте дозволи та цілісність пакунків. Не вирішуйте «chmod 777»; тримайте мінімальні та аудитуємні права.

Жарт №2: ZED як пожежна сигналізація — люди скаржаться, що вона голосна, поки одного дня не збереже їх вихідні.

Плейбук швидкої діагностики

Це послідовність «вибратися швидко». Не ідеально. Не елегантно. Оптимізовано для: що перевірити першим, другим, третім, щоб знайти вузьке місце
і вирішити, чи це диск, шлях, проблема на рівні пулу чи неправильна настройка оповіщень.

Перше: це справжня проблема пулу чи просто відсутні оповіщення?

1. Перевірте стан пулу: zpool status -x. Якщо він healthy, можливо, ви налагоджуєте ZED, а не ZFS.
2. Перевірте, що ZED живий: systemctl status zfs-zed.service і journalctl -u zfs-zed.service.
3. Спровокуйте нешкідливу подію: запустіть scrub на тестовому пулі або зробіть цикл start/stop scrub (якщо можете це терпіти). Підтвердіть, що ZED записав подію.

Друге: якщо пул degraded/faulted — локалізуйте домен відмов

1. Визначіть vdev і пристрій: zpool status POOL і зафіксуйте READ/WRITE/CKSUM лічильники.
2. Знесіть by-id до реального пристрою: ls -l /dev/disk/by-id/ щоб отримати вузол ядра.
3. Перегляньте логи ядра: dmesg -T на предмет скидань, тайм-аутів, помилок транспорту. Проблеми шляху часто видно тут першими.
4. Перевірте SMART: smartctl -a на предмет pending/uncorrectable секторів і логів помилок.

Третє: вирішіть, чи можна стабілізувати без заміни

1. Якщо це схоже на проблему шляху: пересадіть/замініть кабель, переставте диск в інший відсік, оновіть прошивку HBA (ретельно), перевірте живлення.
2. Якщо це проблема медіа диска: замініть диск. Не домовляйтесь із pending секторами.
3. Після зміни: слідкуйте за resilver і знову перевірте лічильники. Якщо лічильники продовжують рости — зупиніться і розширте діагностику до контролера/бекплейну.

Четверте: перевірте якість оповіщень

1. Переконайтесь, що оповіщення дієві: включайте ім’я пулу, ідентифікатор пристрою, поточний zpool status і останні результати scrub.
2. Тротлінг і дедуплікація: повідомляйте при переходах стану; надсилайте email/тикет при повторюваних м’яких помилках.
3. Проводьте щоквартальні відпрацювання: симулюйте подію (scrub start/finish, тестовий zedlet) і підтвердіть, що потрібна команда її отримує.

Три корпоративні міні-історії зі сховищ

Міні-історія 1: Інцидент через невірне припущення

Середня SaaS-компанія запускала ZFS на Linux для кількох «дружніх до даних» нод. Вони перейшли з старого RAID-контролера і
відчували впевненість: контрольні суми, scrub, snapshots — все як треба. Також у них було моніторинг. А принаймні так вважали.

Неправильне припущення було тонким: «оповіщення ZFS — частина пакунка ZFS». Хтось встановив OpenZFS, створив пули, запланував scrub
і забув. ZED був встановлений, але не увімкнений. Ніхто не помітив, бо в буденності ZFS тихий, коли все добре.

Через кілька місяців диск почав логувати інтермітентні тайм-аути. ZFS повторно запитував, відновлював з паритету і продовжував сервіс.
Пул коротко перейшов у DEGRADED, потім повернувся в ONLINE, коли диск повернувся. Немає оповіщення, немає тикета, ніхто не замінив.
Лічильники помилок повзли, як повільна течія за стіною.

Реальний інцидент настав при другій відмові диска під час інтенсивного читання. Пул пішов у жорсткий DEGRADED і додаток побачив латентність.
Користувачі повідомляли «повільні завантаження». Оператори почали з неправильного кінця (налаштування додатка, балансування навантаження),
бо не мали раннього сигналу.

Постмортем попункти були нудні і правильні: увімкнути ZED, підключити оповіщення до ротації on-call, надсилати page при деградації пулу,
і включити by-id імена пристроїв, щоб хтось міг витягти правильний диск без сеансів.

Міні-історія 2: Оптимізація, що відвернула

Команда інженерії даних хотіла менше листів. Вони втомилися від «scrub started» і «scrub finished», що засмічували пошту, і мали рацію:
оповіщення не були пріоритизовані й ніхто їх не читав уважно.

«Оптимізація» полягала у повному відключенні zedlet, пов’язаних зі scrub. Їхня логіка: «ми вже запускаємо scrubs щомісяця; якщо щось не так, пул перейде в degraded».
Остання частина — мінне поле. Результати scrub можуть виявити корупцію, яку ZFS відновив тихо. Це не degraded пул. Це попереджувальний постріл.

Через кілька місяців scrub міг би виявити і відновити checksum-помилки на одному vdev, вказуючи на поганий SAS-кабель. Замість цього ніхто не побачив сигнал.
Кабель погіршився. Згодом диск впав під час resilver, спричиненого іншим обслуговуванням, і resilver затягнувся, підвищивши ризики.
Команда «замовчала систему», яка врешті провалилася голосно.

Вони виправили це, знову увімкнувши оповіщення scrub, але змінили політику: події scrub start йшли у логи низького пріоритету; scrub finish з відновленнями або помилками
створював тикет і вимагав людської перевірки. Шум зменшився. Сигнал відновлено. Це правильний компроміс.

Міні-історія 3: Нудна практика, що врятувала день

Корпоративна IT-група керувала флотом VM-хостів на ZFS. Їхня платформа зберігання не була захопливою; вона була навмисно прісною.
Вони мали суворий стандарт: by-id іменування пристроїв, щоквартальна перевірка scrub і on-call runbook з заміни диска на одній сторінці.

Одного четверга ZED прислав page «pool DEGRADED» з вказаним vdev і фізичним мапінгом слоту. Хост все ще обслуговував VM.
Спокуса в корпоративному середовищі — відкласти роботу, бо «нема відмови». Вони не стали цього робити.

On-call дотримався runbook: підтвердив статус, перевірив SMART, логи ядра і замінив диск. Resilver завершився, пул повернувся в ONLINE,
і вони закрили цикл, перевіривши наступний scrub. Ніяких ескалацій керівництва, ніякого впливу на клієнтів, ніякої драматичної war room.

Через два дні ще один хост у тому ж стояку мав подію живлення, що спричинила скидання контролера. Якби перший хост залишався degraded,
друга подія могла б перетворити рутинну заміну апаратури на складне відновлення. Нудна практика дала їм маневр.

Поширені помилки: симптом → корінь → виправлення

1) Симптом: «Ми ніколи не отримуємо оповіщення ZFS»

Корінь: Сервіс ZED не увімкнений/не запущений, або zedlet не ввімкнені через /etc/zfs/zed.d.

Виправлення: Увімкніть і запустіть ZED; перевірте потік подій командою scrub start і дивіться journald на рядки виконання.

2) Симптом: «ZED логуює події, але листи не доходять»

Корінь: Відсутня поштовая програма, заблокований вихідний SMTP або неправильно налаштовані ZED_EMAIL_ADDR/ZED_EMAIL_PROG.

Виправлення: Запустіть ту саму поштову команду вручну з хоста; виправте relay/firewall/DNS; потім повторно протестуйте ZED.

3) Симптом: «Шторм пейджів під час флапінгу диска»

Корінь: Відсутність тротлінгу/дедуплікації; оповіщення при кожному інкременті помилок замість переходу стану.

Виправлення: Налаштуйте інтервал повідомлень; пейджіть при переходах стану пулу; відкривайте тикети при повторюваних м’яких помилках з порогами за швидкістю.

4) Симптом: «Пул показує checksum-помилки на кількох дисках одночасно»

Корінь: Спільна домена відмови (HBA, бекплейн, expander, кабель, живлення) або корупція пам’яті на системах без ECC.

Виправлення: Припиніть безладну заміну дисків. Перегляньте dmesg на предмет скидань транспорту, перевірте прошивку/драйвер HBA, поміняйте кабелі і оцініть стан пам’яті/ECC.

5) Симптом: «Scrub завершився, відновлено байти, але всі проігнорували це»

Корінь: Політика оповіщень трактує результати scrub як шум; немає робочого процесу для розслідування відновленої корупції.

Виправлення: Направляйте «scrub finished з відновленнями/помилками» у тикет, який вимагає перегляду і подальших перевірок (SMART, кабелі, лічильники).

6) Симптом: «Resilver тягнеться вічно і пул залишається крихким»

Корінь: Підлеглий I/O-боттлнек, додаткові сумнівні диски або проблеми контролера, що викликають повторні спроби.

Виправлення: Перевірте лічильники помилок інших vdev, dmesg на предмет скидань, і SMART на предмет повільних секторів. Якщо кілька дисків хворі — стабілізуйте апарат перед інтенсивним resilver.

7) Симптом: «ZED запускає zedlet, але вони мовчки падають»

Корінь: Дозволи, відсутній біт виконуваності, відсутні залежності в PATH або скрипти, що чекають інтерактивної оболонки.

Виправлення: Робіть zedlet самодостатніми: абсолютні шляхи, явне середовище, суворе оброблення помилок, логування збоїв у journald/syslog.

8) Симптом: «Оператори замінили неправильний диск»

Корінь: Пули побудовано на іменах /dev/sdX; оповіщення не містить стабільних ідентифікаторів; немає процесу мапінгу слотів.

Виправлення: Використовуйте /dev/disk/by-id у пулах, включайте by-id у оповіщення і ведіть мапінг з bay/WWN до інвентарю хостів.

Чеклісти / покроковий план

Чекліст A: Мінімально життєздатні оповіщення ZED (зробіть цього тижня)

1. Підтвердьте, що ZED встановлено і працює: systemctl status zfs-zed.service.
2. Увімкніть ZED при завантаженні: systemctl enable zfs-zed.service.
3. Виберіть місце доставки повідомлень (пошта або локальний інтеграційний скрипт).
4. Встановіть ZED_EMAIL_ADDR (або wrapper) і ZED_NOTIFY_INTERVAL_SECS у /etc/zfs/zed.d/zed.rc.
5. Увімкніть лише ті zedlet, на які ви зможете реагувати (scrub finish, зміни стану пулу, checksum-помилки).
6. Запустіть scrub на некритичному пулі і перевірте, що бачите події ZED у journald.
7. Переконайтесь, що on-call отримує оповіщення і може ідентифікувати диск за стабільним іменем.

Чекліст B: Коли ви отримали оповіщення «pool DEGRADED»

1. Запустіть zpool status POOL. Зафіксуйте його в тикеті.
2. Визначте постраждалий vdev і пристрій by-id; зіставте з вузлом ядра.
3. Перегляньте dmesg -T на предмет transport-помилок і скидань.
4. Запустіть smartctl -a на пристрої; дивіться pending/uncorrectable сектори і лог помилок.
5. Прийміть рішення: виправлення шляху (кабель/бекплейн/HBA) чи заміна диска.
6. Виконайте зміну, потім слідкуйте за resilver і перевірте лічильники.
7. Після повернення в ONLINE, заплануйте/перевірте scrub і слідкуйте за новими відновленнями.

Чекліст C: Щоквартальне відпрацювання оповіщень (щоб довіряти їм)

1. Виберіть один хост на клас сховища (NVMe mirror, RAIDZ тощо).
2. Запустіть scrub і підтвердіть, що ZED бачить scrub_start.
3. Переконайтесь, що оповіщення про завершення scrub містять відновлені байти і підсумок помилок.
4. Перевірте, що політика пейджингу спрацьовує на симульованому degraded стані (якщо можливо — на тестовому пулі).
5. Перегляньте тротлінг: упевніться, що немає штормів пейджів для повторюваних м’яких помилок.
6. Оновіть runbook з новими полями подій, які видає ваша версія ZED.

FAQ

1) Що таке ZED?

ZED — це ZFS Event Daemon. Він слухає події ZFS і запускає обробники (zedlet), щоб повідомити людей або ініціювати автоматичні дії.

2) Чи потрібен ZED, щоб ZFS працював безпечно?

ZFS може виявляти і виправляти багато проблем без ZED. ZED потрібен для того, щоб ви працювали безпечно: він перетворює тихий ризик на видиме завдання.

3) Які події мають пейджити людей, а які створювати тикети?

Пейджте при переходах стану, що зменшують надмірність (DEGRADED/FAULTED, видалення пристрою, невідновлені помилки). Створюйте тикети для результатів scrub з відновленнями і повторюваних м’яких помилок.

4) Чому я бачу checksum-помилки, якщо ZFS «самовідновлюється»?

Тому що ZFS виявив погані дані і відновив їх з надмірності. Checksum-помилка — це слід, що щось у стеку поводиться неправильно.
Сприймайте це як попередження і розслідуйте, особливо якщо кількість помилок зростає.

5) Як часто слід запускати scrub?

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

6) Чи може ZED надсилати оповіщення напряму в Slack/PagerDuty?

Зазвичай це роблять через wrapper-скрипт, який викликає zedlet (або додають/змінюють zedlet) і шлють у ваш внутрішній pipeline оповіщень.
Зробіть логіку на боці ZED мінімальною і стійкою.

7) Чому мій пул перейшов у DEGRADED, а потім повернувся в ONLINE?

Пристрої можуть флапати: короткі відключення, скидання контролера або тайм-аут-шторм. ZFS може помітити пристрій як UNAVAIL, а потім реінтегрувати його.
Це не «гаразд». Це проблема надійності шляху або пристрою.

8) Чи можна покладатися на SMART «PASSED», щоб не замінювати диск?

Ні. SMART overall health — грубий евристичний показник. Pending сектори, uncorrectable і логи помилок важливіші. Лічильники помилок ZFS теж мають значення.

9) У чому різниця між scrub і resilver для оповіщень?

Scrub — це планове сканування цілісності; оповіщайте про завершення і про те, чи були відновлення/помилки. Resilver — це відновлення/реконструкція після змін пристрою;
оповіщайте про початок, аномалії прогресу і завершення.

10) Що робити, якщо ZED занадто шумний?

Не відключайте його глобально. Налаштуйте: тротлінг, пейджинг лише при переходах стану і направляйте інформаційні події в логи.
Шум — це проблема політики, а не причина сліпнути.

Практичні наступні кроки

Якщо ви зробите лише три речі після прочитання цього, зробіть ці:

1. Переконайтесь, що ZED працює скрізь, де ви використовуєте ZFS, запускається при завантаженні і логгує у місце, яке ви реально перевіряєте.
2. Зробіть результати scrub дієвими: оповіщайте про завершення scrub з відновленнями/помилками і створіть робочий процес для розслідування і закриття циклу.
3. Пейджте при втраті надмірності: DEGRADED/FAULTED — це не порада. Це ZFS, що каже вам, що ваш запас безпеки зник.

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

ZFS уже виконує роботу з детекції. ZED — це те, як ви не дозволите цій роботі тихо померти всередині машини.

Фізика, з якою не домовишся

Термопаста (TIM: thermal interface material) не «кращий провідник за метал». Навпаки — вона існує тому, що реальні металеві поверхні не пласкі.
Якщо притиснути ковпачок процесора до радіатора, ідеального контакту не буде. Торкаються лише мікроскопічні вершини, а в западинах залишається повітря.
Повітря — жахливий провідник. Паста «менш жахлива за повітря», тож заповнює ці порожнини.

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

Друга помилка — механічна: паста слизька. Надлишок пасти може змінити посадку радіатора. Охолоджувач, що трохи під нахилом або не затягнутий рівномірно,
створює контактну картину, яка здається нормальною на око, але створює гарячу пляму на одному кластері ядер під AVX-навантаженням. Сучасні CPU захищають себе тротлінгом,
але «захищені» означає «повільні», а в розподілених системах повільність заразна.

Третя помилка — контамінація. Більшість паст номінально електрично не провідні, але «непровідний» не означає «безпечний для мазання навколо дрібних компонентів».
Деякі пасти мають невелику ємність; деякі містять метали; деякі стають провідними при забрудненні або старінні. І навіть якщо сама паста електрично безпечна,
вона притягує пил та волокна, ускладнюючи інспекцію й доопрацювання.

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

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

Жарт №1: Термопаста як парфуми — якщо ви бачите її через всю кімнату, ви використали забагато.

Як виглядає правильно (і чому «горошина» не універсальна)

Інтернет любить «горошину». Це не помилка по суті, але не повна відповідь. Різні CPU мають різні розміри кристала під теплорозподільником.
Різні радіатори створюють різний розподіл тиску. Довгі прямокутні сокети (HEDT і серверні платформи) можуть залишати кути недозаповненими при «одній краплі».
Для великих IHS лінія або X можуть працювати краще.

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

Чому міф «більше пасти = краще охолодження» живе досі

Здається інтуїтивно: більше речовини між двома поверхнями — більше передачі. Це вірно, коли матеріал кращий за заповнюваний зазор. Зазор — це повітря (жах).
Перша невелика кількість пасти допомагає сильно. Після цього ви більше не замінюєте повітря — ви замінюєте металевий контакт шаром пасти. І тепер ви платите за це.

У термінах серверів: паста — як кеш. Трохи — корисно. Уся пам’ять, що видає себе за кеш — це просто… пам’ять.

Факти й історичний контекст (без міфів)

• Факт 1: Рані електронні пристрої з великими потужностями десятиліттями використовували змазки й олії як інтерфейсні матеріали задовго до того, як «перепастинг» став хобі у ПК.
• Факт 2: «Термічний компаунд» став масовим у ПК із підвищенням щільності потужності CPU та коли блискучі поверхні перестали означати пласкі щодо тепла.
• Факт 3: Навіть полірувані метали мають мікроскопічні шорсткості; оптична гладкість — не те саме, що теплова гладкість.
• Факт 4: Типова теплопровідність пасти значно нижча за мідь; її цінність — у витісненні повітря, а не в обгоні металу.
• Факт 5: Існують фазові інтерфейсні матеріали (пади, що трохи розм’якшуються при робочій температурі) для спрощення консистентності складання у виробництві.
• Факт 6: «Pump-out» — реальне явище: термокерування й механічні напруження можуть з часом перемістити пасту від найгарячішої зони.
• Факт 7: Деякі пасти електропровідні (зокрема рідкі метали) і вимагають ізоляції, маскування та вищого рівня майстерності при монтажі.
• Факт 8: Багато серверних радіаторів інженерно розраховані на певний тиск кріплення та потік повітря; заміна на «післяринковий» варіант може порушити теплову модель.
• Факт 9: Термальне тротлінг у сучасних CPU став агресивнішим і дрібнішим; ви можете втратити продуктивність без аварій, і це робить помилку легко пропускаємою.

Що справді ламає «термопаста всюди»

Режим відмови 1: Збільшений тепловий опір через товстий TIM

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

Режим відмови 2: Поганий контакт через нерівномірний монтаж

Надлишок пасти може «гідропланувати» радіатор під час встановлення, особливо якщо ви перетягуєте один кут занадто рано. Радіатор може захопити клин пасти
і ніколи повністю не встати на місце. Ви часто помітите одне-дві ядра або один CCD гарячішими за інші, а не рівномірне підвищення. Така картина важлива:
вона кричить «проблема контакту», а не «проблема потоку повітря».

Режим відмови 3: Паста в неправильних місцях

Паста, намазана на кромки сокета, SMD-компоненти або між контактами — подарунок, що продовжує дарувати. Навіть «непровідні» суміші можуть утворювати шляхи витоку,
якщо змішані з пилом. Це також ускладнює подальші огляди: важко зрозуміти, чи компонент тріснув, підгорів чи просто в модному сірому плащі.

Режим відмови 4: Неправильна паста для профілю роботи

Десктопи і сервери живуть по-різному. Сервер може працювати під тривалим навантаженням, при підвищених вхідних температурах і постійному температурному циклюванні.
Деякі побутові пасти висихають, розшаровуються або «pump-out» швидше під такими умовами. Навпаки, деякі високопродуктивні суміші примхливі й вимагають досконалого монтажу
та підготовки поверхні.

Режим відмови 5: Полювання за пастою замість усунення проблем з потоком повітря

Класична помилка діагностики: «CPU гарячий, значить паста погана». У стояку вхідна температура, заглушки, пучки кабелів, стан вентиляторів і криві BMC часто виявляються
справжнім злочинцем. Паста — найпростіша річ, до якої доторкнутися, тому її часто звинувачують. Тим часом сервер дихає чужим вихлопом, бо хтось зняв заглушку RU місяці тому
і ніхто не захотів створити тикет.

Жарт №2: Якщо ваше нанесення пасти виглядає як сучасне мистецтво, CPU відповість перформансом — в основному інтерпретативним тротлінгом.

План швидкої діагностики

Коли машина перегрівається після перепастингу — або починає тротлити під звичайними навантаженнями — не починайте знову відразу перепастувати.
Почніть з ізоляції вузького місця трьома проходами: (1) підтвердіть датчики і симптоми, (2) скореляйте з поведінкою живлення і частоти, (3) перевірте потік повітря і контакт.
Ви прагнете швидко відповісти на одне питання: обмежує чи фактор генерація тепла, передача тепла або видалення тепла?

Перший крок: підтвердіть, що симптом реальний і конкретний

• Перевірте температуру пакета CPU, дельти по ядрах/CCD і чи погоджується BMC з ОС.
• Шукайте прапорці термального тротлінгу і падіння частоти під навантаженням.
• Порівняйте з відомим робочим сусідом, якщо він у вас є.

Другий крок: скореляйте теплові показники з навантаженням і споживанням

• Чи викликано це навантаженням (тільки під AVX або стискуванням), часом (через 20 хвилин), чи навколишньою температурою (пік гарячого коридору)?
• Чи вентилятори розкручуються до максимуму? Якщо вентилятори низькі при гарячому CPU — підозрюйте політику управління вентиляторами/BMC.
• Чи є ви обмежені по потужності (пакетний power clamp), а не по теплу?

Третій крок: валідуйте потік повітря і механічний контакт

• Потік повітря: вхідна температура, RPM корпусних вентиляторів, заблоковані фільтри, відсутні заглушки, перешкоди з кабелями.
• Механічне: схема затягування радіатора, опори кріплення, вирівнювання бекплейта, деформована холодна плита, правильний спейсер для сокета.
• TIM: правильна кількість, без порожнин, без забруднень, відповідний тип пасти для діапазону температур.

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

Практичні завдання: команди, виходи та рішення

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

Завдання 1: Перевірка базових температур CPU і розкиду по ядрах

cr0x@server:~$ sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +86.0°C  (high = +90.0°C, crit = +100.0°C)
Core 0:        +85.0°C  (high = +90.0°C, crit = +100.0°C)
Core 1:        +86.0°C  (high = +90.0°C, crit = +100.0°C)
Core 2:        +68.0°C  (high = +90.0°C, crit = +100.0°C)
Core 3:        +69.0°C  (high = +90.0°C, crit = +100.0°C)

Значення: Два ядра приблизно на 17–18°C гарячіші за інші за схожих умов. Це не «потік корпусу»; це часто нерівномірний контакт або локальний гарячий
осередок.

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

Завдання 2: Спостерігати температуру і поведінку вентиляторів у реальному часі

cr0x@server:~$ watch -n 1 'sensors | egrep "Package id 0|Core 0|Core 2|fan"'
Every 1.0s: sensors | egrep Package id 0|Core 0|Core 2|fan

Package id 0:  +92.0°C
Core 0:        +91.0°C
Core 2:        +74.0°C
fan1:          8200 RPM
fan2:          8100 RPM

Значення: Вентилятори працюють на високих обертах; система намагається. Температури все ще високі з великим дельта. Видалення тепла працює;
підозра на передачу тепла (TIM/контакт).

Рішення: Перевірте прапорці тротлінгу; готуйтеся до переустановлення з правильним моментом затягування і кількістю пасти.

Завдання 3: Підтвердити частоту CPU і тротлінг під навантаженням

cr0x@server:~$ lscpu | egrep "Model name|CPU MHz|Thread|Socket"
Model name:                           Intel(R) Xeon(R) CPU
Thread(s) per core:                   2
Socket(s):                            2
CPU MHz:                              1199.992

Значення: Якщо під навантаженням ви бачите ~1.2 GHz на CPU, що має бути значно швидшим, ймовірно, відбувається тротлінг або обмеження по потужності.

Рішення: Перевірте журнали ядра на події термального тротлінгу і порівняйте з обмеженнями потужності.

Завдання 4: Шукати повідомлення про термальний тротлінг у логах ядра

cr0x@server:~$ sudo dmesg -T | egrep -i "thermal|throttl|PROCHOT|temperature" | tail -n 10
[Mon Jan 22 10:14:05 2026] CPU0: Package temperature above threshold, cpu clock throttled (total events = 37)
[Mon Jan 22 10:14:05 2026] CPU1: Package temperature above threshold, cpu clock throttled (total events = 37)

Значення: Це явний термальний тротлінг. Не «можливо». Не «користувач каже, що повільно».

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

Завдання 5: Зчитати дані сенсорів BMC/IPMI (температури, вентилятори, вхід)

cr0x@server:~$ sudo ipmitool sdr elist | egrep -i "inlet|ambient|cpu|fan" | head -n 12
Inlet Temp       | 24 degrees C      | ok
CPU1 Temp        | 91 degrees C      | ok
CPU2 Temp        | 89 degrees C      | ok
FAN1             | 8100 RPM          | ok
FAN2             | 8200 RPM          | ok
FAN3             | 7900 RPM          | ok

Значення: Вхідна температура нормальна; температури CPU високі; вентилятори працюють інтенсивно і здорові. Це вказує не на проблему гарячого коридору,
а на контакт радіатора/TIM.

Рішення: Заплануйте вікно обслуговування для переустановлення; не витрачайте час на переналаштування крів вентиляторів.

Завдання 6: Перевірити governor CPU і політику частоти (щоб уникнути самостійного тротлінгу)

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance

Значення: Ви не випадково працюєте у «powersave». Добре. Якби був «powersave», ви могли б неправильно інтерпретувати низькі такти як тротлінг.

Рішення: Продовжуйте перевірки лімітів потужності/тепла, а не налаштування політики CPU.

Завдання 7: Перевірити обмеження потужності (може маскуватися під теплові проблеми)

cr0x@server:~$ sudo ipmitool dcmi power reading
    Instantaneous power reading:                   412 Watts
    Minimum during sampling period:                380 Watts
    Maximum during sampling period:                430 Watts
    Average power reading over sample period:      405 Watts
    IPMI timestamp:                           Mon Jan 22 10:20:10 2026
    Sampling period:                          00000010 Seconds.

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

Рішення: Якщо температури високі і такти низькі — це термальне питання. Якщо температури помірні і такти низькі — підозрюйте кап по потужності або BIOS-обмеження.

Завдання 8: Виявити, чи певний процес викликає сплеск тепла

cr0x@server:~$ top -b -n 1 | head -n 15
top - 10:22:31 up 18 days,  3:12,  1 user,  load average: 63.12, 58.77, 41.09
Tasks: 412 total,   2 running, 410 sleeping,   0 stopped,   0 zombie
%Cpu(s):  2.1 us,  0.3 sy,  0.0 ni, 97.4 id,  0.0 wa,  0.0 hi,  0.2 si,  0.0 st
MiB Mem : 257843.1 total,  98212.7 free,  40117.2 used, 119513.2 buff/cache
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
28412 app       20   0  12.3g  2.1g  112m R  780.0   0.8  12:31.44 compressor

Значення: Одне навантаження (стиснення/крипто/AVX-важке) може нагнітати теплове навантаження сильніше, ніж звичайні тести.

Рішення: Використовуйте відтворюване навантаження (той самий бінарник) при верифікації переустановлення; інакше будете ганятися за шумом.

Завдання 9: Стресс-тест у контрольованому режимі, щоб відтворити проблему

cr0x@server:~$ sudo apt-get install -y stress-ng
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  stress-ng
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.

Значення: Тепер у вас є інструмент для формування стабільного навантаження.

Рішення: Запустіть короткий стрес і спостерігайте температуру; не запускайте у продукції без вікна обслуговування та меж безпеки.

cr0x@server:~$ sudo stress-ng --cpu 32 --timeout 60s --metrics-brief
stress-ng: info:  [31201] dispatching hogs: 32 cpu
stress-ng: metrc: [31201] cpu                60.00s  12345.67 bogo ops/s
stress-ng: info:  [31201] successful run completed in 60.02s

Значення: Відтворюване 60‑секундне навантаження дозволяє порівняння «до/після». Поєднуйте це з watch sensors.

Рішення: Якщо тротлінг відбувається швидко — ймовірно контакт/TIM. Якщо потрібно багато часу — підозрюйте потік повітря, забиті фільтри або навколишнє середовище.

Завдання 10: Перевірити виправлені апаратні помилки, що корелюють з теплом

cr0x@server:~$ sudo journalctl -k --since "1 hour ago" | egrep -i "mce|edac|hardware error" | tail -n 10
Jan 22 10:09:12 server kernel: mce: [Hardware Error]: Machine check events logged
Jan 22 10:09:12 server kernel: EDAC MC0: 1 CE memory read error on CPU_SrcID#0_Ha#0_Chan#1_DIMM#0

Значення: Тепло може посилювати маргінальні компоненти. Перепастинг, що підвищує температури, може перетворити «рідкі кориговані помилки» на інцидент.

Рішення: Розглядайте теплові проблеми як ризики надійності; плануйте усунення до того, як помилки перестануть бути коригованими.

Завдання 11: Перевірити затримки сховища під час термального тротлінгу (бо це проявиться)

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0 (server) 	01/22/2026 	_x86_64_	(64 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.31    0.00    3.22    0.85    0.00   83.62

Device            r/s     w/s   rkB/s   wkB/s  rrqm/s wrqm/s  %util  r_await  w_await
nvme0n1         12.0   220.0   512.0  8192.0     0.0    0.0   68.5    2.10    9.80

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

Рішення: Якщо латентність сховища зростає, а такти CPU падають і температури стрибають — виправляйте терміку перед налаштуванням I/O.

Завдання 12: Перевірити, чи ZFS scrub/resilver не перетворює терміку на самонавмисний простій

cr0x@server:~$ zpool status
  pool: tank
 state: ONLINE
status: One or more devices is currently being resilvered.
action: Wait for the resilver to complete.
  scan: resilver in progress since Mon Jan 22 09:41:03 2026
        1.20T scanned at 1.68G/s, 612G issued at 858M/s, 4.10T total
        612G resilvered, 14.58% done, 0 days 01:10:22 to go
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdc     ONLINE       0     0     0
            sdd     ONLINE       0     0     0

Значення: Resilvering навантажує CPU і пам’ять (контрольні суми, стиснення, парність). Якщо теплові умови CPU граничні, таке навантаження їх виявить.

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

Завдання 13: Перевірити журнал подій BMC на термальні або вентиляторні події

cr0x@server:~$ sudo ipmitool sel list | tail -n 8
 217 | 01/22/2026 | 10:14:06 | Temperature #0x01 | Upper Critical going high | Asserted
 218 | 01/22/2026 | 10:14:10 | Temperature #0x01 | Upper Critical going high | Deasserted
 219 | 01/22/2026 | 10:14:12 | Processor #0x01   | IERR | Asserted

Значення: BMC зафіксував перетин термального порога. Також процесорна помилка може вказувати на нестабільність під впливом тепла.

Рішення: Ескалувати. Термічне — це вже не косметика; це викликає апаратні збої.

Завдання 14: Перевірити, чи шасі вважає кришку присутньою (таке трапляється)

cr0x@server:~$ sudo ipmitool sdr elist | egrep -i "intrusion|chassis"
Chassis Intrusion | Not Available     | ok

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

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

Три корпоративні міні-історії з практики

1) Інцидент через неправильне припущення

Середня SaaS-компанія мала флот баз даних, стабільний роками. Потім пройшла рутинна заміна апаратури: та ж сім’ї CPU, трохи новіший степінг, ревізія кріплення радіатора від постачальника.
Нічого страшного. Технік перепастив кілька хостів під час встановлення в стійку, бо кілька радіаторів здавалися «трохи сухими». Здавалося відповідальним.

Неправильне припущення було простим: більше пасти покращує теплопередачу, і «вона розподілиться». Технік використав щедру кількість і зробив швидку установку — затягнув один кут,
потім протилежний, але не поетапно. Машини завантажилися. На холостому ходу температури здавалися нормальними. Усі пішли додому.

Наступного дня кластер баз даних почав показувати непередбачувані сплески латентності. Не велетенські. Достатньо, щоб викликати ретраї, які створили додаткове навантаження і тепло.
Під нічною аналітичною задачею два вузли почали тротлити, відставати в реплікації і були ізольовані менеджером кластера як «повільні та ненадійні».
Відкат спрацював, але було брудно: порушення доступності, купа алертів і довга RCA-зустріч.

Постмортем був менш про пасту, більше про дисципліну. Вони порівняли телеметрію тепла між «перепастеними» й «не чіпаними» вузлами і знайшли чіткий підпис:
вищі package temps під навантаженням і більші дельти по ядрах. Виправлення не вимагало героїки. Вони витягли машини у вікно обслуговування, ретельно очистили,
нанесли виміряну кількість, затягнули по діагоналі з однаковим моментом і верифікували тестом навантаження перед поверненням у пул.

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

2) Оптимізація, що дала протилежний ефект

Інша організація — велика, ощадлива й горда своєю «ефективністю» — вирішила зменшити шум вентиляторів і споживання енергії в лабораторії, яка тихо перетворилася на production staging.
Хтось вирішив «оптимізувати» терміку: повторно нанести преміум-пасту з високою теплопровідністю по всьому флоту і трохи знизити криву вентиляторів через BMC.
Аргумент: краща паста — ми можемо крутити вентилятори повільніше.

Паста була нормальна. Процес — ні. Вони використовували шпатель, щоб створити ідеальний шар, але не контролювали товщину. Деякі радіатори отримали шар пасти просто надто товстий.
Машини працювали холодніше на холостому ході — бо на холостому все працює тихіше — і зміна кривої вентиляторів зробила середовище тихішим і «стабільним». Слайд перемоги.

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

Врешті оптимізація дала зворотний ефект двічі: зміна кривої вентиляторів зменшила тепловий запас, а нерівномірна товщина TIM підвищила тепловий опір.
Вони відкотили політику вентиляторів, стандартизували метод нанесення і лише потім «преміум-паста» дала відчутне покращення. Вартість була в основному час і авторитет,
що в корпоративному житті не відновлюється просто так.

Операційне правило: ніколи не комбінуйте фізичні зміни з політичними, якщо не готові бісектувати. Якщо не можете бісектувати — ви не навчитесь.

3) Нудна, але правильна практика, що врятувала день

Команда сховища, що працювала на щільних вузлах з обчисленням і NVMe, мала одну звичку, що виглядала майже комічно: кожного разу, коли знімали радіатор, вони логували це як заміну диска.
Тікет, причина, тип пасти, метод, патерн затягування і «до/після» 60-секундний знімок стрес-тесту. Нікому це не подобалося робити. Усі дуже цінували мати це пізніше.

Під час квартального фризу змін один вузол почав періодично тротлити. Він не падав зовсім. Просто працював повільно. Сервіс мав суворі SLO для хвостової латентності, і цей вузол тягнув
увесь пул вниз. Через фриз команда потребувала доказів перед тим, як попросити виняток для фізичних робіт.

Вони витягли історичні дані хоста і побачили, що package temps під стандартним стрес-тестом виросли приблизно на 10°C з останнього обслуговування. Також вони побачили запис про зняття радіатора
два місяці тому для RMA материнської плати. Це дало правдоподібну гіпотезу: тонке проблемне прилягання або pump-out.

Вони отримали виняток, переустановили радіатор за стандартною процедурою, і після-тест зійшовся з базою. Без драм, без здогадок, без «спробувати іншу марку пасти».
Хост повернувся в пул, і кінець кварталу минув без інцидентів продуктивності.

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

Типові помилки: симптом → корінь → виправлення

1) Високі температури CPU відразу після перепастингу

Симптоми: Температури гірші, ніж до роботи; вентилятори швидко розганяються; тротлінг під помірним навантаженням.

Корінь: Забагато пасти (товстий шар), захоплені повітряні кишені, радіатор не сідає рівно.

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

2) Одне ядро/CCD значно гарячіше за інші

Симптоми: Велика дельта по ядрах під навантаженням; package temp виглядає «досить нормально», але точкове гаряче місце досягає порогів.

Корінь: Нерівномірний тиск монтажу, нахил, неправильний стандофф/спейсер, деформована основа радіатора, клин пасти.

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

3) Температури нормальні на холостому ході, погіршуються через 20–60 хвилин

Симптоми: Повільний підйом, потім тротлінг; часто корелюється з тривалими нагрузками (scrub, rebuild, пакетні роботи).

Корінь: Обмеження потоку повітря (фільтри, пучки кабелів), занадто консервативна крива вентиляторів, піки вхідної температури, pump-out пасти з часом.

Виправлення: Перевірити вхідну температуру й RPM вентиляторів через BMC; оглянути шлях потоку повітря; відновити рекомендовану політику вентиляторів; якщо історія вказує — переустановити пасту, яка стійкіша до pump-out.

4) Система перезавантажується під навантаженням, терміка «виглядає нормально»

Симптоми: Випадкові перезавантаження; іноді немає очевидного термального логу; іноді MCE/EDAC події.

Корінь: Локальний гарячий осередок, не зафіксований датчиком, перегрів VRM, неправильне вирівнювання радіатора або відсутність кришки/каналів, що призводить до нагріву компонентів.

Виправлення: Використати датчики BMC поза CPU (VRM, материнська плата, вхід). Підтвердити наявність повітряних каналів і кожухів. Переперевірити посадку радіатора. Не ігноруйте скоректовані помилки.

5) Вентилятори застрягли на низьких обертах, а температури ростуть

Симптоми: CPU досягає 90°C, вентилятори залишаються на низьких RPM; очевидних збоїв вентиляторів немає.

Корінь: Некоректна політика вентиляторів BMC, сенсор вторгнення шасі спрацьований або баг у прошивці.

Виправлення: Порівняйте температури в ОС і BMC; перевірте SEL на події політики; відновіть профіль тепла за замовчуванням; оновіть прошивку BMC у контрольованому вікні.

6) Паста на сокеті/компонентах після робіт

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

Корінь: Надмірне нанесення і розмазування під час зняття/встановлення радіатора; погана методика очищення.

Виправлення: Повністю знеструмити, акуратно розібрати, очистити відповідним розчинником і безворсовими матеріалами, оглянути під яскравим світлом. Якщо була використана провідна паста — розглядати як інцидент і подумати про заміну плати.

7) «Ми перепастили і все одно гаряче»

Симптоми: Немає покращення після декількох перепастингів; всі втомлені; система залишається на межі.

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

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

Контрольні списки / покроковий план

Покроково: процедура «зробити один раз і забути» перепастингу (серверна)

1. Плануйте валідацію. Виберіть відтворюване навантаження (наприклад, stress-ng --cpu N --timeout 60s) і зафіксуйте базові температури та частоти до втручання.
2. Заплануйте вікно. Вам потрібен час для ретельного очищення і пост-робочого стрес-тесту. Поспіх — це шлях зробити пасту стилем життя.
3. Знеструмте і розрядьте. Вийміть кабелі живлення, зачекайте, дотримуйтеся сервіс-гіду платформи. Не «гаряче» змінюйте терпіння.
4. Акуратно зніміть радіатор. Послабляйте по діагоналі потроху. Уникайте крутіння, що розмазує пасту по компонентах.
5. Повністю очистіть обидві поверхні. Використовуйте безворсові серветки/тампони і відповідний розчинник. Видаліть стару пасту з кутів і щілин, де вона любить ховатися.
6. Огляньте поверхні. Шукайте подряпини, ямки, залишки і ознаки нерівного контакту. Підтвердіть правильний кронштейн/стендони для сокета.
7. Наносьте пасту економно. Використовуйте мінімум, який заповнить порожнини: маленька крапка для типової IHS, лінія/X для великої прямокутної серверної IHS за потреби.
8. Саджайте радіатор прямо вниз. Уникайте зміщення; невеликий зсув може створити порожнини або нерівномірне витиснення пасти.
9. Затягуйте поступово по діагоналі. По кілька обертів на гвинт, чергуючи кути, до повного сідання за специфікацією постачальника.
10. Встановіть кожухи і канали. Це не опціональна естетика. Це різниця між «системою охолодження» і «надією».
11. Запустіть і перевірте датчики. Підтвердіть вентилятори, вхідну температуру і температури CPU як у ОС, так і в BMC.
12. Запустіть валідаційне навантаження. Порівняйте з базою. Якщо температури гірші — зупиніться і перевірте монтаж і кількість пасти, а не хаотично міняйте патерни.
13. Задокументуйте зміну. Запишіть тип пасти, метод і метрики до/після. Майбутній ви буде нездоланно вдячний.

Контрольний список: здоровий стан потоку повітря і шасі (перед тим, як звинувачувати пасту)

• Всі модулі вентиляторів на місці, правильна модель, без помилок.
• Ребра радіатора чисті; немає пилу або пакувальної піни (так, таке буває).
• Повітряний кожух встановлений і сідає на місце.
• Заглушки RU на місці; немає відкритих отворів, що обводять потік повітря.
• Пучки кабелів не перекривають вхід вентиляторів або кожух CPU.
• Вхідні температури в очікуваному діапазоні; порівняйте з сусідами в стійці.
• Профіль тепла BMC встановлений у рекомендований режим для вашого навантаження.

Контрольний список: вибір пасти як доросла людина

• Віддавайте перевагу непровідному, неконденсативному складу для серверів, якщо немає вагомої причини і контролю якості робіт.
• Пріоритет — стійкість до температурних циклів (опір pump-out), а не пікові бенчмарк-стандарти теплопровідності.
• Стандартизуйте одну-дві затверджені сполуки і один метод нанесення на платформу.
• Уникайте змішування паст або нанесення поверх залишків; очищайте до голої поверхні щоразу.
• Якщо за дизайн використовують фазові пади, не замінюйте їх пастою поспіхом; ви змінюєте валідацію збірки.

Питання й відповіді

1) Чи може надто велика кількість термопасти справді підвищити температури?

Так. Паста — насамперед наповнювач повітряних зазорів. Товстий шар підвищує тепловий опір порівняно з метал-до-металу контактом, що підвищує температури і прискорює тротлінг.

2) Як дізнатися, що я використав забагато пасти, без розбирання?

Шукайте підпис після перепастингу: вищі package temps під тим же контрольованим навантаженням, більші дельти по ядрах, раніше розгін вентиляторів і нові повідомлення про тротлінг у логах.
Такі шаблони сильно вказують на поганий інтерфейс або посадку.

3) Чи завжди «метод горошини» правильний?

Ні. Це добрий дефолт для багатьох стандартних IHS, але великі прямокутні серверні IHS часто виграють від лінії або X, щоб забезпечити покриття кутів. Реальна вимога — тонке неперервне покриття,
а не відданість формі.

4) Чи варто розмазувати пасту карткою/лопаткою?

У флотних операціях розмазування зазвичай підвищує варіативність товщини і вводить бульбашки, якщо робити це несуворо. Контрольована крапка/лінія/X з правильним тиском монтажу зазвичай
більш послідовна. Якщо ви все ж розмазуєте — потрібен метод, що контролює товщину і уникає повітря.

5) Як часто слід перепастувати сервери?

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

6) Чи варто використовувати «метал» або рідкий метал у продакшні?

Зазвичай ні, якщо у вас немає контрольованого процесу й платформа це не підтримує. Провідний TIM підвищує ризики: замикання, корозія і складніший ремонт.
Надійність важливіша за кілька градусів.

7) Мій CPU гарячий; чи означає це автоматично, що паста погана?

Не автоматично. Перевірте вхідну температуру, RPM вентиляторів, кожухи й політику BMC перш ніж звинувачувати пасту. Проблеми з потоком повітря поширені і впливають на декілька компонентів.

8) Чому я бачу тротлінг, але немає очевидної температурної аварії?

Тротлінг може тригеритися локальними гарячими плямами або внутрішніми сенсорами, які не корелюють із тим одним значенням температури, за яким ви слідкуєте.
Також прошивка може попередньо тротлити нижче «критичних» порогів. Використовуйте журнали ОС і сенсори BMC для повнішої картини.

9) Який єдиний найважливіший механічний фактор крім кількості пасти?

Тиск монтажу і рівномірність. Ідеальна паста не компенсує радіатор, що стоїть під нахилом, нерівномірно затягнутий або з неправильним спейсером/бекплейтом.

10) Якщо я перепастив і температури покращилися — чи це кінець?

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

Висновок: наступні кроки, які можна зробити

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

Практичні наступні кроки:

• Виберіть стандартне валідаційне навантаження і зафіксуйте базові температури та частоти для кожної платформи.
• Коли терміка зсувається, пройдіть план швидкої діагностики перед тим, як торкатися апаратури.
• Якщо доводиться перепастувати — стандартизуйте тип пасти, метод нанесення і послідовність моментів затягування — і документуйте це як будь-яку іншу продукційну зміну.
• Після робіт валідуйте під тривалим реалістичним навантаженням, а не просто «воно завантажилось».
• Розглядайте термальні регресії як ризики надійності, особливо на вузлах сховища під час відновлень і scrub’ів.

Якщо запам’ятати одне: правильна кількість пасти — мінімум, який робить повітря нерелевантним. Все понад це — просто декорування проблеми теплопередачі.

Рішення: що варто запускати і чому

Якщо ви запускаєте Ubuntu 24.04 у продакшені і вам важливо не втрачати важливі події, зробіть так:

1. Залиште journald. На системах з systemd він не опціональний, і це ваш найкращий інструмент для першого огляду.
2. Зробіть журнал персистентним на будь‑яких хостах, які ви будете дебажити після перезавантаження.
3. Використовуйте rsyslog для надійного та контрольованого пересилання на центральну платформу логів (SIEM, ELK/OpenSearch, Splunk тощо), яку ваша організація вважає «джерелом правди».
4. Не використовуйте «переслати все двічі» як стратегію. Дублікати — це не надлишковість; це шум, який заважає помітити ту одну потрібну строку.

Іншими словами: journald — для локального захоплення, індексації та структурованих метаданих; rsyslog — для сумісності з екосистемою syslog, черг та свідомих правил пересилки. Ви можете пересилати з journald до rsyslog або налаштувати сервіси логувати безпосередньо в syslog. Правильна відповідь залежить від того, що вам потрібно довести під час інциденту або аудиту.

Суха правда: ви не обираєте систему логування за відчуттями. Обирайте її за режимом відмов. Запитайте: «що станеться, коли диск заповниться? Коли мережа відвалиться? Коли хост перезавантажиться? Коли час стрибне? Коли процес заллє логер повідомленнями?» і підберіть стек, який відмовляє так, як ви можете з цим жити.

Ментальна модель, яка не брешить під тиском

Що таке journald насправді

systemd-journald — це колектор і сховище подій логів з прикріпленими метаданими: cgroup, ім’я юніта, PID, UID, capabilities, контекст SELinux/AppArmor (де доступно), boot ID і монотонні часові мітки. Він зберігає записи у бінарних файлах журналу. «Бінарний» — це не моральна вада; це вибір на користь продуктивності та цілісності. Це дозволяє індексацію та відносно швидкі запити, наприклад «покажи все з sshd.service за останній бут».

За замовчуванням на багатьох системах journald використовує волатильне сховище (пам’ять під /run/log/journal), якщо не налаштовано персистентне сховище. Таке налаштування дружнє до малих дисків і ефермних машин, але жорстоке, коли треба розбиратися з тим, що сталося до перезавантаження.

Що таке rsyslog насправді

rsyslog — це демон syslog, який приймає повідомлення (з локальних сокетів, з мережі, з journald через модуль вводу) і маршрутизує їх за правилами. Він дуже добрий у чергах, обмеженні швидкості, буферизації на диску та відправці логів надійно, коли мережа поводиться як мережа (тобто іноді погано).

Виводи rsyslog зазвичай — текстові файли в /var/log або віддалені syslog‑приймачі. Текстові логи залишаються лінгва франка великої кількості інструментів. Це не ностальгія; це сумісність з тим, що досі парсить syslog як 2009 рік.

Пайплайн на Ubuntu 24.04 (типовий)

• Повідомлення ядра потрапляють у кільцевий буфер ядра, потім journald їх збирає; rsyslog теж може читати повідомлення ядра залежно від конфігурації.
• Служби systemd логують у stdout/stderr; journald автоматично їх захоплює.
• Багато традиційних додатків усе ще логують через /dev/log (syslog сокет). Це може надавати rsyslog або сумісний сокет від systemd‑journald.
• rsyslog може приймати дані з journald (через imjournal) або з syslog сокета, після чого писати файли і/або пересилати їх.

Якщо ви коли‑небудь дивувалися, чому у вашому /var/log/syslog бракує рядка, який ви бачили в journalctl, відповідь зазвичай: «це дві різні дороги захоплення». Логування — це ланцюг постачання. Ви не помічаєте ланцюга, поки не застрягне контейнерний корабель.

Цитата, яку варто прикріпити до монітора (перефразована думка): тема Gene Kim про операції говорить, що покращення приходить від скорочення циклів зворотного зв’язку. Логування — один з ваших найкоротших циклів; ставтеся до нього як до продакшн‑коду.

Жарт №1: Логування як зуби — ігноруєш, поки не заболіє, а тоді раптом готовий заплатити будь‑яку ціну, щоб біль припинився.

Цікаві факти та історичний контекст

1. syslog існує довше за Linux. Оригінальний syslog з’явився в BSD Unix у 1980‑х, створений для простого мережевого транспорту логів у часи, коли «модель безпеки» була здебільшого «не дозволяти Деві з бухгалтерії торкатися сервера».
2. rsyslog новіший, ніж думають багато хто. rsyslog з’явився на початку 2000‑х як сумісна заміна sysklogd з кращою продуктивністю і можливостями, такими як TCP, RELP і черги.
3. journald зберігає логи в бінарному форматі за задумом. Він оптимізований для індексованих запитів і подій, багатих на метадані; аргумент «бінарні логи погані» здебільшого про очікування інструментів, а не про реальну надійність.
4. systemd зробив stdout/stderr важливими для логування. Це змінило культуру логування додатків: службам більше не потрібно керувати лог‑файлами, якщо вони цього не хочуть. Платформа захоплює їх.
5. Традиційна ротація логів була винайдена для контролю використання диска для текстових логів. У journald збереження часто контролюється за розміром/часом, а не через ротацію файлів, що змінює підхід до питання «ми зберегли минулий тиждень?».
6. RELP існує тому, що TCP іноді недостатньо. TCP все ще може втратити дані при аварії відправника або скиданні з’єднання у невдалий момент; RELP (Reliable Event Logging Protocol) додає підтвердження на рівні застосунку.
7. Journald позначає логи boot ID. Це звучить як дрібниця, поки ви не дебажите переривчастий крах і не треба відокремити «цей бут» від «попереднього бута». Це дуже корисно.
8. Кільцевий буфер ядра обмежений. Якщо ви не прочищаєте його під час потоку, старі повідомлення ядра перезаписуються. Це не вина journald, але journald — типовий шлях їх спустошення.

Трейд‑офи, які дійсно важливі в 2025

Надійність збереження: що переживає перезавантаження, а що ні

journald може бути волатильним або персистентним. Волатильний journald підходить для «скотних» нод, де ви миттєво централізуєте все, і жахливий для випадків «чому він перезавантажився?», коли ваш форвардер не встиг відправити останні 30 секунд.

rsyslog, що пише на диск, за замовчуванням персистентний (якщо він пише в /var/log і ця файлову система переживає). Але персистентність на тому ж диску, що й робоче навантаження, не рятує, якщо диск заповнюється і ваш додаток падає. Надійність — це властивість системи, а не лише демон.

Зворотний тиск та обробка вибухів

Під час хвильлогів система логування стає частиною вашого профілю продуктивності. journald має обмеження швидкості і може відкидати повідомлення. rsyslog може чергувати в пам’яті або виливати на диск. Якщо вам важливо «ніколи не втратити логи автентифікації» або «захопити останні 60 секунд перед крашем», потрібні явні налаштування і зазвичай черги з підстраховкою на диск.

Метадані та зручність запитів

journald перемагає локально для швидкого розрізання: за юнітом, PID, cgroup, boot, пріоритетом, часом. Якщо ви робите інцидентний розбір на одній машині, journalctl часто швидший, ніж grep по файлах — особливо коли служби шлють структуровані дані або PID часто змінюються.

rsyslog перемагає, коли треба інтегруватися з всім, що очікує syslog — від мережевого обладнання до старих конвеєрів відповідності. Це «універсальний адаптер».

Безпека та захист від фальсифікацій

Жоден демон автоматично не зробить логи неможливими для підробки. Локальний root завжди може нашкодити. Ваш реальний контроль — швидко відправляти логи за межі хоста, зберігати їх незмінними в агрегаційній системі і контролювати доступ. journald підтримує функції запечатування, але не плутайте «важче випадково змінити» з «судово‑експертним рівнем захисту».

Складність і операційні витрати

Запуск лише journald простий, доки не знадобиться надійне пересилання з буферизацією, фільтрацією та вибором протоколів. Запуск journald + rsyslog — трохи більше рухомих частин, але дає вам явний контроль над пайплайном. У продакшені явне перемагає неявне.

Жарт №2: «Нам не потрібне централізоване логування» — смілива стратегія; це як відмовитися від ременів безпеки, бо ви плануєте їздити обережно.

Практичні завдання (команди, значення виводу, рішення)

Ось перевірки, які я виконую на Ubuntu 24.04, коли хтось каже «логи зникли», «диск заповнюється» або «пересилка не працює». Кожне завдання містить: команду, що означає вивід, і яке рішення прийняти.

Завдання 1: Підтвердити, що запущено (journald, rsyslog)

cr0x@server:~$ systemctl status systemd-journald rsyslog --no-pager
● systemd-journald.service - Journal Service
     Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service; static)
     Active: active (running) since Mon 2025-12-30 09:10:11 UTC; 2h 1min ago
...
● rsyslog.service - System Logging Service
     Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; preset: enabled)
     Active: active (running) since Mon 2025-12-30 09:10:13 UTC; 2h 1min ago
...

Значення: Обидва сервіси активні; ймовірно у вас подвійні шляхи захоплення. Якщо rsyslog неактивний, ви, ймовірно, покладаєтесь лише на journald.

Рішення: Якщо потрібна віддалена пересилка з буферизацією, увімкніть rsyslog (або виділений форвардер) і визначте шлях навмисно.

Завдання 2: Подивитися режим зберігання journald (volatile vs persistent)

cr0x@server:~$ journalctl --disk-usage
Archived and active journals take up 96.0M in the file system.

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

Рішення: Якщо вам важливі логи між перезавантаженнями, переконайтеся, що персистентне сховище ввімкнено і задані політики зберігання.

Завдання 3: Перевірити, чи journald використовує персистентне сховище

cr0x@server:~$ ls -ld /var/log/journal /run/log/journal
drwxr-sr-x 3 root systemd-journal 4096 Dec 30 09:10 /var/log/journal
drwxr-sr-x 2 root systemd-journal  120 Dec 30 09:10 /run/log/journal

Значення: /var/log/journal існує, отже персистентність увімкнена (або принаймні доступна). Якщо її немає, journald може бути волатильним.

Рішення: Якщо /var/log/journal відсутній, створіть його і встановіть Storage=persistent (деталі в розділі плану).

Завдання 4: Перевірити налаштування збереження та обмеження швидкості journald

cr0x@server:~$ systemd-analyze cat-config systemd/journald.conf
# /etc/systemd/journald.conf
[Journal]
Storage=persistent
SystemMaxUse=2G
SystemKeepFree=1G
RateLimitIntervalSec=30s
RateLimitBurst=10000

Значення: Це ефективні налаштування після drop‑in файлів. Малий SystemMaxUse означає швидше видалення старих записів. Агресивне обмеження швидкості може скидати сплески.

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

Завдання 5: Виявити відкинуті повідомлення в journald

cr0x@server:~$ journalctl -u systemd-journald --since "1 hour ago" | tail -n 8
Dec 30 10:44:02 server systemd-journald[412]: Suppressed 12845 messages from /system.slice/myapp.service
Dec 30 10:44:02 server systemd-journald[412]: Forwarding to syslog missed 0 messages

Значення: «Suppressed» вказує на відкидання через обмеження швидкості. Це не теоретично. Це відбувається тут і зараз.

Рішення: Якщо придушений юніт важливий (auth, kernel, ваш основний сервіс), підвищте ліміти і зменшіть спам у джерелі. Розгляньте rsyslog‑черги для надійності пересилки.

Завдання 6: Перевірити, чи rsyslog приймає з journald

cr0x@server:~$ grep -R "imjournal" /etc/rsyslog.d /etc/rsyslog.conf
/etc/rsyslog.conf:module(load="imjournal" StateFile="imjournal.state")

Значення: rsyslog читає системний журнал через imjournal. Якщо відсутній, rsyslog може читати замість цього з /dev/log.

Рішення: Виберіть одну стратегію прийому, щоб уникнути дублювання: або imjournal (журнал як джерело істини), або сокет (syslog як джерело). Не робіть обидва випадково.

Завдання 7: Виявити дублікати подій (класичний симптом подвійного прийому)

cr0x@server:~$ sudo awk 'NR<=20{print}' /var/log/syslog
Dec 30 11:01:10 server myapp[2211]: started worker=7
Dec 30 11:01:10 server myapp[2211]: started worker=7

Значення: Та сама повідомлення двічі в один і той же час сильно натякає на подвійний прийом (наприклад, додаток логував в syslog, а journald форвардив у rsyslog також).

Рішення: Вимкніть один шлях: або перестаньте форвардити з journald у rsyslog, або перестаньте читати rsyslog з /dev/log, залежно від архітектури.

Завдання 8: Перевірити черги rsyslog і чи заблокована пересилка

cr0x@server:~$ systemctl status rsyslog --no-pager | sed -n '1,14p'
● rsyslog.service - System Logging Service
     Active: active (running) since Mon 2025-12-30 09:10:13 UTC; 2h 9min ago
   Main PID: 621 (rsyslogd)
      Tasks: 4
     Memory: 8.5M
        CPU: 1.901s
     CGroup: /system.slice/rsyslog.service
             └─621 /usr/sbin/rsyslogd -n -iNONE

Значення: Сам статус не покаже глибину черги, але підтверджує здоров’я демона і виявляє очевидні цикли падіння.

Рішення: Якщо віддалена пересилка затримується, перевірте досяжність мережі та action‑черги rsyslog (див. нижче перевірки конфігурації).

Завдання 9: Валідувати конфіг rsyslog (синтаксис, модулі, include)

cr0x@server:~$ rsyslogd -N1
rsyslogd: version 8.2312.0, config validation run (level 1), master config /etc/rsyslog.conf
rsyslogd: End of config validation run. Bye.

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

Рішення: Ніколи не перезавантажуйте rsyslog в продакшені без перевірки. Спочатку валідуйте, потім перезавантажуйте, потім підтвердіть потік повідомлень.

Завдання 10: Визначити, чи пересилка UDP (втратна) або TCP/RELP (краще)

cr0x@server:~$ grep -R "@" /etc/rsyslog.d /etc/rsyslog.conf
/etc/rsyslog.d/60-forward.conf:*.* @@logrelay.internal:514

Значення: @ означає UDP, @@ — TCP. TCP все одно може втратити при аваріях; RELP міцніший.

Рішення: Якщо вимога — «не втратити логи автентифікації», не використовуйте UDP. Використовуйте TCP з диск‑чергами або RELP, якщо ваш релей це підтримує.

Завдання 11: Перевірити, чи journald форвардить у syslog (і чи це взагалі потрібно)

cr0x@server:~$ grep -R "^ForwardToSyslog" /etc/systemd/journald.conf /etc/systemd/journald.conf.d 2>/dev/null
/etc/systemd/journald.conf:ForwardToSyslog=yes

Значення: journald форвардить записи в syslog сокет. Якщо rsyslog також читає з журналу, це може створювати дублікати.

Рішення: Виберіть одну точку передачі: або ForwardToSyslog (journald → syslog сокет), або rsyslog imjournal (journald → rsyslog напряму).

Завдання 12: Визначити «чому він перезавантажився?» за розбитими по бутам журналами

cr0x@server:~$ journalctl --list-boots | tail -n 3
-2 2f1c1b2dd0e84fbb9a1f66b2ff0f8d1e Sun 2025-12-29 22:10:17 UTC—Sun 2025-12-29 23:52:01 UTC
-1 7d8c0e3fa0f44a3b8c0de74b8b9f41a2 Mon 2025-12-30 00:10:06 UTC—Mon 2025-12-30 09:09:55 UTC
 0 94f2b5d9f61e4f57b5f3c3c7a9c2a1d1 Mon 2025-12-30 09:10:06 UTC—Mon 2025-12-30 11:19:44 UTC

Значення: Видно кілька бутів, отже персистентність працює. Якщо ви бачите тільки «0», ймовірно, журнал волатильний або історію витіснено.

Рішення: Якщо перезавантаження трапляються загадково, увімкніть персистентний journald і збільшіть збереження, щоб «попередній бут» існував, коли він вам потрібен.

Завдання 13: Швидко зібрати наратив про вимкнення/крах

cr0x@server:~$ journalctl -b -1 -p warning..emerg --no-pager | tail -n 20
Dec 30 09:09:51 server kernel: Out of memory: Killed process 2211 (myapp) total-vm:...
Dec 30 09:09:52 server systemd[1]: myapp.service: Main process exited, code=killed, status=9/KILL
Dec 30 09:09:55 server systemd[1]: Reached target Reboot.

Значення: Останній бут показує OOM kill і падіння служби, що призвело до перезавантаження. Це той «один екран», де journald відмінно показує картину.

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

Завдання 14: Підтвердити тиск на файлову систему логів

cr0x@server:~$ df -h /var /run
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        40G   34G  4.2G  90% /
tmpfs           3.1G  180M  2.9G   6% /run

Значення: /var пучить. Якщо логи ділять кореневу файлову систему, сплеск логів може стати відмовою.

Рішення: Обмежте використання journald (SystemMaxUse), правильно настроїть ротацію текстових логів і відправляйте логи за межі хоста. Якщо потрібно, винесіть /var на окрему файлову систему в серйозних середовищах.

Завдання 15: Кількісно визначити важких споживачів журналу

cr0x@server:~$ journalctl --since "1 hour ago" -o json-pretty | head -n 20
{
        "_SYSTEMD_UNIT" : "myapp.service",
        "PRIORITY" : "6",
        "MESSAGE" : "processed batch id=9f1c...",
        "_PID" : "2211",
        "__REALTIME_TIMESTAMP" : "1735557650000000"
}

Значення: JSON‑вихід показує поля, за якими можна фільтрувати. Якщо ваш додаток спамить «processed batch …» на info рівні, це ваша проблема для диска і вашого майбутнього себе.

Рішення: Зменшіть обсяг логування на джерелі. Системи логування не заміняють метрики.

Завдання 16: Перевірити, хто має доступ до журналу (для дебагу прав)

cr0x@server:~$ id
uid=1000(cr0x) gid=1000(cr0x) groups=1000(cr0x),4(adm)

Значення: Користувачі в групі adm часто можуть читати багато логів; доступ до journald зазвичай надають через групу systemd-journal або через sudo.

Рішення: Надайте інженерам на чергуванні мінімальні групи, потрібні для читання логів, без надання повного root. Потім проводьте аудит цього рішення щоквартально, бо організаційні карти дрейфують.

Плейбук швидкої діагностики

Ви на чергуванні. Алерт каже «служба впала». Хтось каже «логи зникли». Не нишпорте без порядку. Робіть так у порядку.

Перше: з’ясувати, чи події взагалі існують локально

1. Перевірте журнал для служби і потрібного часового проміжку. Фільтруйте за юнітом і пріоритетом. Якщо журнал має подію, у вас є локальна істина для старту розслідування.
2. Перевірте попередній бут. Якщо хост перезавантажився, «зниклі логи» можуть бути просто «ви дивитеся не на той бут».

cr0x@server:~$ journalctl -u myapp.service --since "30 min ago" -p info..emerg --no-pager | tail -n 30
Dec 30 11:03:01 server myapp[2211]: healthcheck failed: upstream timeout
Dec 30 11:03:02 server systemd[1]: myapp.service: Main process exited, code=exited, status=1/FAILURE

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

Друге: визначити, чи дані відкидаються

1. Пошукайте повідомлення про пригнічення в journald.
2. Перевірте тиск на диск. Повні диски викликають дивну поведінку і відсутні записи.
3. Перевірте здоров’я rsyslog і валідність конфігу.

Третє: ізолювати вузьке місце — захоплення, зберігання або відправка

• Вузьке місце захоплення: додаток не логує, stdout не підключено, невідповідний syslog сокет, права доступу.
• Вузьке місце зберігання: journald волатильний, занадто мале збереження, диск повний, vacuuming, надмірна ротація.
• Вузьке місце відправки: rsyslog пересилає UDP, немає черг, мережеві втрати, проблеми з DNS для хоста логів, помилки TLS.

Четверте: доведіть це одним контрольованим тестовим повідомленням

cr0x@server:~$ logger -p authpriv.notice "LOGTEST authpriv notice from $(hostname) at $(date -Is)"
cr0x@server:~$ journalctl --since "1 min ago" | grep LOGTEST | tail -n 1
Dec 30 11:18:22 server cr0x: LOGTEST authpriv notice from server at 2025-12-30T11:18:22+00:00

Інтерпретація: Якщо воно в журналі, але не в /var/log/syslog (або не в вашому аггрегаторі), ви звузили помилку до шляху передачі/пересилки.

Типові помилки: симптом → причина → виправлення

1) «Логи зникають після перезавантаження»

Симптоми: journalctl --list-boots показує лише бут 0; після краху історія відсутня.

Корінь проблеми: journald використовує волатильне сховище (/run), бо персистентність не увімкнена або /var/log/journal не існує.

Виправлення: Створіть /var/log/journal, встановіть Storage=persistent, перезапустіть journald і підтвердіть, що з’являються кілька бутів. Також задайте обмеження зберігання, щоб персистентність не перетворилася на виснаження диска.

2) «У нас всілякі дублікати»

Симптоми: Та сама строка з’являється двічі в /var/log/syslog або двічі в агрегаторі, часто з ідентичними часами.

Корінь проблеми: Подвійний прийом: додаток логував у syslog сокет, journald форвардив у syslog, і rsyslog також читає журнал (або навпаки).

Виправлення: Виберіть один шлях: rsyslog читає через imjournal або journald форвардить у syslog сокет. Не комбінуйте без свідомої логіки дедуплікації.

3) «Логи автентифікації відсутні в центральній системі, але локальний syslog їх має»

Симптоми: /var/log/auth.log локально заповнений; SIEM пропускає записи під час мережевих перебоїв.

Корінь проблеми: UDP‑пересилка, або TCP без диск‑черг, або релей недоступний без буферизації.

Виправлення: Використовуйте TCP з чергами на диск або RELP до релея, що призначене для інжесту. Перевірте налаштування черг і протестуйте, тимчасово блокуючи мережу.

4) «Під час інциденту journalctl повільний або таймаутить»

Симптоми: journalctl запити займають багато часу, CPU стрибки, I/O‑wait.

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

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

5) «/var повний і тепер все горить»

Симптоми: Служби не стартують, оновлення пакетів падають, логи перестають писатися, випадкові демони падають.

Корінь проблеми: Невпорядковані текстові логи, неправильно налаштований retention journald або додаток, що пише у великих обсягах.

Виправлення: Встановіть обмеження journald (SystemMaxUse, SystemKeepFree), переконайтеся, що logrotate працює, і виправте шумний додаток. Якщо середовище важливе, винесіть /var на окрему файлову систему.

6) «Я бачу логи з sudo, але не як мій on‑call користувач»

Симптоми: journalctl показує «No journal files were found» або доступ заборонено без sudo.

Корінь проблеми: Користувач черговий не в потрібній групі (systemd-journal або adm залежно від політики), або застосовано загартовані права.

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

Три корпоративні міні‑історії з логувальних фронтів

Міні‑історія 1: Інцидент через хибне припущення

Середня компанія мігрувала флот з Ubuntu 20.04 на 24.04. У них був випробуваний ру‑бук: перевірити /var/log/syslog, перевірити /var/log/auth.log, відправити в центральний syslog. Міграція «працювала», сервіси піднялися, і команда пішла далі.

Дві тижні потому партія нод перезавантажилася через kernel panic, спричинений проблемною прошивкою NIC. На чергуванні відкрили /var/log/syslog і побачили… небагато. Схоже, машина просто акуратно перезавантажилася. Командир інциденту попросив «останні 60 секунд». Часу було 3 секунди і зростаюче відчуття жаху.

Хибне припущення було тонким: вони думали, що rsyslog все ще основний колектор для всього важливого. Але кілька сервісів були systemd‑нативними і логували в stdout; journald їх захоплював, і лише частина таких подій пересилалася в rsyslog. Відсутні події не «зникли». Вони сиділи в волатильному журналі, який зник після перезавантаження на деяких профілях нод.

Виправлення було нудним і ефективним: вмикнули персистентність journald на всіх не‑ефемерних нодах, задали розумні обмеження розміру і проклали журнал у rsyslog одним явним шляхом. Наступний інцидент після перезавантаження залишився неприємним, але принаймні логи розповіли історію замість того, щоб вводити в оману.

Міні‑історія 2: Оптимізація, що відвернулась

Велика внутрішня команда вирішила, що вони платять занадто багато за зберігання логів. Помітили, що журнал росте швидко на галасливих нодах. Тому вони агресивно зменшили збереження journald і загострили обмеження швидкості. Мета була розумною: захистити диски і зменшити шум.

Місяць все виглядало добре. Використання диска впало. Дашборди стали чистішими. Потім залежність почала поводитися некоректно: переривчасті помилки TLS між сервісами. Помилки тривали секунди, кілька разів на годину. Метрики показували спайки помилок, але логи, які могли пояснити «чому», часто були відсутні. Спайки були саме того типу, які пригнічуються лімітами і коротким збереженням, коли багато компонентів стають галасливими одночасно.

Вони нарешті виявили патерн, корелюючи декілька вцілілих логів з пакетними дампами: MTU mismatch після зміни мережі. Справжній урок був не в MTU. Вони «оптимізували» логування, видаливши саме ті дані, які потрібні для дебагу рідкісних подій, які неможливо відтворити на вимогу.

Виправлений підхід: зменшувати обсяг на джерелі (рівні логів, семплінг, структуровані події), зберігати достатній локальний журнал для триажу і покладатися на центральне сховище для довгострокового аналізу. Різак для збереження — це скальпель; вони користувалися ним як газонокосаркою.

Міні‑історія 3: Нудна, але правильна практика, що врятувала день

Команда, що працює з платіжними сервісами, запускала Ubuntu‑ноди для автентифікації. Нудна конфігурація: systemd служби, rsyslog‑форвардинг і центральний релей логів. У них була одна звичка, що здавалася надміру: щоквартально вони робили контрольований тест «збоїв пересилки логів» в робочий час на канарній ноді.

Тест був простий. Блокували egress до релея логів на кілька хвилин на канарі, генерували кілька logger тестових повідомлень різних фейсиліті і пріоритетів, потім знову відкривали egress. Очікування: повідомлення чергуються локально і з’являються в агрегаторі у правильному порядку без втрат.

Одного кварталу тест провалився. Повідомлення ніколи не з’явилися upstream. Локальні логи були, але пересилка не наздогнала. Оскільки це був тест, а не реальний збій, вони мали час розбиратися без адреналіну. Виявилося, що зміна конфігу тимчасово переключила пересилку на UDP і ніхто не повернув назад. «Тимчасово» — найпостійніше слово в корпоративній ІТ.

Вони відкотилися до TCP з диск‑чергами і написали маленький CI‑чек, що фіксує UDP‑форвардинг у продуктивних конфігах. Місяць потому справжній мережевий інцидент вдарив по сегменту дата‑центру. Черга поглинула відключення, SIEM пізніше синхронізувався, і звіт про інцидент містив незвичну фразу: «Втрата даних не виявлена». Нудне виграло. Знову.

Чеклісти / покроковий план

План A (рекомендовано): персистентний journald + пересилка через rsyslog з одним шляхом прийому

1. Зробіть journald персистентним.

   cr0x@server:~$ sudo mkdir -p /var/log/journal
   cr0x@server:~$ sudo systemd-tmpfiles --create --prefix /var/log/journal
   cr0x@server:~$ sudo sed -i 's/^#Storage=.*/Storage=persistent/' /etc/systemd/journald.conf
   cr0x@server:~$ sudo systemctl restart systemd-journald

   Що перевірити: journalctl --list-boots має показати більше ніж бут 0 після наступного перезавантаження, і /var/log/journal має наповнитися.

2. Встановіть обмеження зберігання, що не заповнять диск.

   cr0x@server:~$ sudo tee /etc/systemd/journald.conf.d/99-retention.conf >/dev/null <<'EOF'
   [Journal]
   SystemMaxUse=2G
   SystemKeepFree=1G
   MaxRetentionSec=14day
   EOF
   cr0x@server:~$ sudo systemctl restart systemd-journald

   Рішення: Обирайте ліміти відповідно до розміру диска і потреб інцидентів. На маленьких root‑файлових системах будьте консервативні і пересилайте логи за межі хоста.

3. Виберіть точку передачі в rsyslog: використовуйте imjournal АБО ForwardToSyslog, але не обидва.

   Опція 1 (поширена): rsyslog читає журнал через imjournal.

   cr0x@server:~$ sudo grep -R "module(load=\"imjournal" /etc/rsyslog.conf
   module(load="imjournal" StateFile="imjournal.state")

   Тоді відключіть пересилання journald у syslog, щоб уникнути дублювання, якщо ви не використовуєте його:

   cr0x@server:~$ sudo tee /etc/systemd/journald.conf.d/10-forwarding.conf >/dev/null <<'EOF'
   [Journal]
   ForwardToSyslog=no
   EOF
   cr0x@server:~$ sudo systemctl restart systemd-journald

4. Використовуйте надійну пересилку (TCP + черги; RELP якщо доступно).

   cr0x@server:~$ sudo tee /etc/rsyslog.d/60-forward.conf >/dev/null <<'EOF'
   # Forward everything to a relay over TCP with a disk-assisted queue.
   # Adjust rules so you don't forward noisy debug logs if you don't need them.
   
   action(
     type="omfwd"
     target="logrelay.internal"
     port="514"
     protocol="tcp"
     action.resumeRetryCount="-1"
     queue.type="LinkedList"
     queue.filename="fwdAll"
     queue.maxdiskspace="2g"
     queue.saveonshutdown="on"
     queue.dequeuebatchsize="500"
   )
   EOF
   cr0x@server:~$ sudo rsyslogd -N1
   cr0x@server:~$ sudo systemctl restart rsyslog

   Рішення: Якщо у вас є вимоги відповідності, поєднайте це з внутрішнім релеєм і розгляньте RELP/TLS. TCP — добрий мінімум, але не гарантія.

5. Доведіть кінець‑в‑кінець за допомогою контрольних повідомлень.

   cr0x@server:~$ logger -p user.notice "LOGPIPE e2e test id=$(uuidgen)"
   cr0x@server:~$ journalctl --since "2 min ago" -o short-iso | grep LOGPIPE | tail -n 1
   2025-12-30T11:20:41+00:00 server cr0x: LOGPIPE e2e test id=3e0c2aef-7e0f-4a43-a3c2-9c3e5c4f2f8b

   Рішення: Якщо воно локально, але не централізовано — лаг на шляху пересилки. Якщо воно й локально не з’являється — проблема захоплення.

План B: тільки journald (прийнятно для ефермних флотів з сильною централізацією)

• Використовуйте персистентний journald тільки якщо диски і політики зберігання дозволяють; інакше покладайтеся на миттєву пересилку через колектор, що розуміє journald.
• Акуратно встановлюйте жорсткі обмеження швидкості: ви можете захистити хост ціною втрати тієї однієї події, що вам була потрібна.
• Переконайтеся, що у вас є копія за межами хоста. «Локально‑тільки» — прелюдія до «ми не можемо довести, що сталося».

План C: rsyslog як основний (лише за спадщинними обмеженнями)

• Можливо, але у вас все одно буде journald, що захоплює stdout/stderr для systemd‑сервісів.
• Якщо наполягаєте на файлових workflow‑ах, переконайтеся, що служби логують у syslog або файли свідомо. Інакше ви будете шукати відсутні події в двох світах.
• Будьте явними щодо джерел логів ядра, щоб уникнути розривів.

Питання та відповіді

1) На Ubuntu 24.04, чи потрібен мені взагалі rsyslog?

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

2) Чи може journald втратити логи?

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

3) Чи є бінарні логи проблемою для комплаєнсу?

Зазвичай вимога комплаєнсу — «зберігання, цілісність, контроль доступу, аудит», а не «повинно бути plain text». Справжній крок для комплаєнсу — пересилання логів за межі хоста в незмінне сховище і контроль доступу. Бінарний чи текстовий формат — це перевага інструментів, а не гарантія.

4) Чому я бачу логи в journalctl, але не в /var/log/syslog?

Тому що journald за замовчуванням захоплює stdout/stderr для systemd‑сервісів. Якщо ви не форвардите ці записи в syslog, вони не з’являться в syslog‑файлах. Також фільтри або мапінги фейсиліті можуть направляти повідомлення інакше.

5) Чи форвардити з journald у rsyslog чи нехай rsyslog читає журнал?

Виберіть одне, щоб уникати дублювання. Я віддаю перевагу, щоб rsyslog читав журнал через imjournal як єдину точку прийому з явними чергами і діями пересилки.

6) Чи прийнятний UDP для пересилки syslog?

Для «низьких ставок» телеметрії і шумних debug‑стрімів, де втрата допустима — так. Для auth, безпеки або критичних інцидентів — ні. Використовуйте TCP з буферизацією або RELP, якщо можете.

7) Скільки збереження в journald варто тримати?

Тримайте достатньо, щоб покрити ваш вікно реакції людини: щонайменше «попередній бут + кілька днів» на важливих хостах. Далі покладайтеся на центральне збереження для тижнів/місяців. Обмежте локальне використання, щоб воно не з’їло машину.

8) Чи можу я змусити journald писати традиційні текстові логи напряму?

Не як основний формат. journald може форвардити в syslog, а syslog‑демони можуть писати текстові файли. Це підтримуваний міст: journald захоплює, rsyslog пише/пересилає.

9) А як щодо логів контейнерів?

Якщо контейнери логують у stdout/stderr і рантайм інтегрується з systemd, journald може їх захоплювати з багатими метаданими. Якщо ви використовуєте інший шлях рантайму, переконайтеся, що ваш колектор явно знімає логи контейнера. Не припускайте.

10) Як запобігти тому, щоб логи не вбили вузол?

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

Висновок: наступні кроки, які вас не підведуть

Ubuntu 24.04 не змушує вас воювати релігійно між journald і rsyslog. Вона дає два інструменти з різними режимами відмов. В продакшені правильний патерн зазвичай такий: персистентний journald як локальна істина плюс rsyslog для свідомої, буферизованої, сумісної пересилки.

Наступні кроки:

1. Увімкніть персистентність journald на будь‑якому хості, який ви можете відлагоджувати після перезавантаження, і обмежте її так, щоб вона не змогла заповнити диск.
2. Визначте один шлях прийому в rsyslog, щоб уникнути дублювань.
3. Переключіть пересилку на TCP (або RELP) з диск‑чергами для всього, що ви не можете дозволити собі втратити.
4. Щоквартально проводьте тест «відмова пересилки логів» на канарі. Якщо це здається надмірним, зачекайте перший аудит або інцидент з безпекою.

Логування — це не просто спостережуваність. Це доказ. Будуйте його так, ніби він вам знадобиться в суді — бо колись, в межах організації, це станеться.