Англійська для управління журналами Splunk

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

Ключовий словник

SPL (Search Processing Language) — Конвейєрна мова запиту Splunk, де результати пошуку передаються через послідовність команд, таких як stats, where, і timechart для фільтрування і перетворення даних.

• “Я перенаправив необроблені події через stats count by host в SPL, щоб побачити, який сервер генерує найбільше помилок.” *

Type Source — класифікація, яку Splunk присвоює вхідним даним, яка визначає, як вони розбираються в поля, наприклад, access_combined для журналів веб-сервера. “Журнали нової служби не обробляються належним чином, оскільки ми ще не присвоїли їм тип джерела, отже, всі поля показуються як сирий текст.”

** Збережений пошук ** — збережений запит SPL, який можна буде виконати знову вручну, за розкладом або використовувати як основу для попередження, отже, не потрібно буде відновлювати корисне дослідження з нуля. “Я перетворив цей запит на збережений пошук, щоб інженер на черзі міг просто натиснути кнопку “Запустити”, замість того, щоб переписувати його під час наступного інциденту.”

** Alert Action ** — відповідь, яку Splunk запускає, коли результати запланованого пошуку відповідають умові, наприклад, надіслання електронної пошти, публікація в Slack або запуск webhook. “Додамо дію попередження Slack до цього збереженого пошуку, щоб команда отримала повідомлення про помилку, як тільки кількість помилок перевищить поріг.”

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

Звичайні фрази

• Чи можете ви поділитися SPL, який ви використовували, щоб я міг адаптувати його для цього іншого індексу?»
• «Ця подія не розшифровується правильно — який тип джерела ви присвоїли їй?»
• «Я перетворю це на збережений пошук, щоб ми не перебудовували його щоразу»
• «Ми повинні приєднати до цього дію попередження, щоб нам не потрібно було перевіряти вручну»
• «Чи модель даних вже покриває цей формат журналу, або нам потрібно розширити його?»

Приклади висловлювань

Зневадження проблеми аналізу:

• “Жодне з полів не витягується правильно, оскільки цей тип джерела ніколи не був налаштований — зараз Splunk розглядає весь рядок як один необроблений рядок.” *

Пояснення попередження товаришу по команді: “Цей збережений пошук виконується кожні п’ ять хвилин і викликає дію попередження Slack, якщо кількість помилок перевищує п’ ятьдесят, отже, ви отримаєте ping- повідомлення, перш ніж клієнт помітить це.”

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

• “Все на цій панелі керування виводиться з однієї моделі даних, отже, як тільки ви зрозумієте поля однієї панелі, решта буде виглядати знайомо.” *

Професійні поради

• Посилайтеся на ваш запит як на SPL, а не « пошук Splunk », коли обговорюєте його з іншими користувачами Splunk — це точний термін і сигналізує про вільне володіння синтаксисом конвеєра.
• Завжди спочатку перевіряйте ** тип джерела **, якщо нове джерело журналу виглядає неправильно — неправильна класифікація є найпоширенішою причиною того, що поля не видобуваються так, як очікувалося.
• Перетворювати одноразові запити дослідження на ** збережені пошуки ** перед тим, як інциденти буде закрито — це перетворює знання племен на крок з циклу, який можна використовувати знову.
• Коли ви пропонуєте нове сповіщення, вказуйте точну дію ** сповіщення **, яку ви бажаєте виконати (ел. пошта, Slack, webhook), а не просто « сповіщати когось » — це уникає другого раунду роз’ яснення з тим, хто його налаштовує.

Практичні вправи

1. Напишіть одне речення, у якому поясните, що робить тип джерела і чому його неправильне налаштування призводить до пошкодження витягування полів.
2. Опишете вашими словами відмінність між пошуком ad hoc і збереженим пошуком.
3. Видає коротке повідомлення з пропозицією нової дії попередження для збереженого пошуку, яку слід виконати, якщо кількість невдалих спроб входу до системи перевищить певний порог.

Назва походить від англійського «navigating nuance» — спільні фрази в реакції на інцидент

Як розробник, що працює з управлінням журналами Splunk, ви швидко усвідомите, що просто знати * технічні * терміни - index, sourcetype, lookup - недостатньо. Ефективне спілкування є абсолютно критичним, особливо під час реагування на інцидент, де ясність і точність можуть зробити або пошкодити рішення. Для не-рідних носіїв англійської мови, це може бути особливо складним завдяки тонким відмінностям у фразування, які передають різні рівні невідкладності, відповідальності або деталей. Давайте розглянемо деякі звичайні фрази, з якими ви зіткнетеся, і як їх ефективно використовувати.

Одна з найчастіших ситуацій під час перегляду коду. Уявіть, що ви отримуєте коментар щодо складного пошуку SPL: « Цей пошук може бути більш ефективним; розгляньте використання stats замість циклічного перегляду всіх подій ». Хоча це технічно коректно, ця фраза може здатися тупою. Кращий підхід може бути, « Я помітив, що цей пошук ітерує всі події. Чи можемо ми дослідити використання stats для агрегування даних і потенційного скорочення часу обробки? Можливо, ми могли б порівняти обидва підходи, щоб порівняти їх ефективність. ” Це не тільки про ефективність; це про представлення пропозиції в конструктивний спосіб. Аналогічно, коли ви описуєте проблему, яку ви виявили під час дослідження, не вказуйте просто « Є помилки ». Замість цього, описуйте проблему чітко: « Я спостерігав значний стрибок у кількості помилок, пов’ язаних зі службою автентифікації, між 14: 00 і 14: 30 UTC, що збігається зі збільшенням кількості спроб користувачів увійти до системи. Це свідчить про потенційну атаку грубим способом». Додатковий контекст – час, зачеплена служба і підозрювана причина – робить виявлення набагато більш дієвим.

Іншою ключовою областю є створення чітких запитів на захоплення (PR), у яких описуються ваші зміни. Не просто скажіть «Відроджена помилка». Замість цього використовуйте такі фрази, як: « Впроваджено нове правило попередження, яке буде викликано, якщо використання процесора перевищить 90% протягом більше ніж п’ яти хвилин. » або « Оновлено таблицю пошуку, щоб включити додаткові назви вузлів на основі останньої документації з налаштуваннями. » Подробиці допоможуть переглядачеві зрозуміти, * чому * ви внесли зміну і як вона вирішує проблему. Нарешті, пам’ятайте, що активний голос майже завжди переважає над пасивним голосом в професійному спілкуванні - “Ми реалізували новий пошук” звучить більш прямо і відповідально, ніж “Був реалізований новий пошук”.

# Example: Retrieving CPU usage for a specific host
search index=main sourcetype=syslog host=*myhost* | stats avg(cpu_usage) by host

Сфокусування на цих нюансових техніках формулювання значно поліпшить вашу здатність ефективно співпрацювати в екосистемі Splunk і робити значний внесок під час розв’ язання інциденту. Це про те, щоб продемонструвати не тільки що ви зробили, але як ви зробили це і чому.