Структуриране на неструктурирани данни с GROK
Ако използвате Elastic Stack (ELK) и се интересувате от картографиране на персонализирани журнали на Logstash към Elasticsearch, тогава тази публикация е за вас.
Стекът ELK е акроним за три проекта с отворен код: Elasticsearch, Logstash и Kibana. Заедно те образуват платформа за управление на регистрационни файлове.
- Elasticsearch е система за търсене и анализ.
- Logstash е тръбопровод за обработка на данни от страната на сървъра, който взема данни от множество източници едновременно, трансформира ги и след това ги изпраща в "скривалище", като Elasticsearch.
- Kibana позволява на потребителите да визуализират данни с помощта на диаграми и графики в Elasticsearch.
Beats се появи по-късно и е лесен за изпращане на данни. Въвеждането на Beats трансформира Elk Stack в Elastic Stack, но не това е важното.
Тази статия е за Grok, което е функция в Logstash, която може да трансформира вашите регистрационни файлове, преди да бъдат изпратени в скривалището. За нашите цели ще говоря само за обработка на данни от Logstash към Elasticsearch.
Grok е филтър в Logstash, който се използва за анализиране на неструктурирани данни в нещо структурирано и подлежащо на запитване. Той се намира върху регулярен израз (regex) и използва текстови шаблони за съпоставяне на низове в лог файлове.
Както ще видим в следващите раздели, използването на Grok е много важно, когато става въпрос за ефективно управление на регистрационни файлове.
Без Grok вашите регистрационни данни са неструктурирани
Без Grok, когато регистрационните файлове се изпращат от Logstash към Elasticsearch и се визуализират в Kibana, те се появяват само в стойността на съобщението.
Запитването на смислена информация в тази ситуация е трудно, тъй като всички регистрационни данни се съхраняват в един и същ ключ. Би било по-добре, ако съобщенията в журнала бяха по-добре организирани.
Неструктурирани данни от регистрационни файлове
localhost GET /v2/applink/5c2f4bb3e9fda1234edc64d 400 46ms 5bc6e716b5d6cb35fc9687c0Ако погледнете по-отблизо необработените данни, ще видите, че те всъщност се състоят от различни части, всяка разделена с интервал.
За по-опитни разработчици вероятно можете да познаете какво означава всяка от частите и какво е съобщението в журнала от извикването на API. Представянето на всеки артикул е посочено по-долу.
Структуриран изглед на нашите данни
- localhost == среда
- Метод GET ==
- /v2/applink/5c2f4bb3e9fda1234edc64d == url
- 400 == статус_на_отговора
- 46 ms == време за реакция
- 5bc6e716b5d6cb35fc9687c0 == user_id
Както виждаме в структурираните данни, има ред за неструктурирани журнали. Следващата стъпка е програмна обработка на необработените данни. Това е мястото, където Grock блести.
Grok шаблони
Вградени Grok шаблони
Logstash се предлага с над 100 вградени шаблона за структуриране на неструктурирани данни. Определено трябва да се възползвате от това, когато е възможно за общи системни журнали като apache, linux, haproxy, aws и т.н.
Но какво се случва, когато имате персонализирани журнали като в примера по-горе? Трябва да създадете свой собствен Grok шаблон.
Персонализирани шаблони на Grok
Трябва да се опитате да създадете свой собствен Grok шаблон. използвах и .
Имайте предвид, че синтаксисът за шаблоните на Grok е както следва: %{SYNTAX:SEMANTIC}
Първото нещо, което се опитах да направя, беше да отида в раздела ПОВЕЧЕ в програмата за отстраняване на грешки Grok. Мислех, че би било чудесно, ако този инструмент може автоматично да генерира шаблона Grok, но не беше много полезно, тъй като намери само две съвпадения.
Използвайки това откритие, започнах да изграждам свой собствен шаблон в дебъгера Grok, използвайки синтаксиса, намерен на страницата Elastic Github.
След като си поиграх с различни синтаксиси, най-накрая успях да структурирам регистрационните данни по начина, по който исках.
Връзка към програмата за отстраняване на грешки Grok
Оригинален текст:
localhost GET /v2/applink/5c2f4bb3e9fda1234edc64d 400 46ms 5bc6e716b5d6cb35fc9687c0Модел:
%{WORD:environment} %{WORD:method} %{URIPATH:url} %{NUMBER:response_status} %{WORD:response_time} %{USERNAME:user_id}Какво стана накрая
{
"environment": [
[
"localhost"
]
],
"method": [
[
"GET"
]
],
"url": [
[
"/v2/applink/5c2f4bb3e9fda1234edc64d"
]
],
"response_status": [
[
"400"
]
],
"BASE10NUM": [
[
"400"
]
],
"response_time": [
[
"46ms"
]
],
"user_id": [
[
"5bc6e716b5d6cb35fc9687c0"
]
]
}С шаблона Grok и картографирани данни в ръка, последната стъпка е да го добавите към Logstash.
Актуализирайте конфигурационния файл Logstash.conf
На сървъра, където сте инсталирали ELK стека, отидете на конфигурацията на Logstash:
sudo vi /etc/logstash/conf.d/logstash.confПоставете вашите промени.
input {
file {
path => "/your_logs/*.log"
}
}
filter{
grok {
match => { "message" => "%{WORD:environment} %{WORD:method} %{URIPATH:url} %{NUMBER:response_status} %{WORD:response_time} %{USERNAME:user_id}"}
}
}
output {
elasticsearch {
hosts => [ "localhost:9200" ]
}
}След като запазите промените, рестартирайте Logstash и проверете състоянието му, за да се уверите, че все още работи.
sudo service logstash restart
sudo service logstash statusИ накрая, за да се уверите, че промените са влезли в сила, не забравяйте да актуализирате индекса на Elasticsearch за Logstash в Kibana!
С Grok вашите регистрационни данни са структурирани!
Както можем да видим на изображението по-горе, Grok може автоматично да картографира регистрационни данни към Elasticsearch. Това улеснява управлението на регистрационните файлове и бързото търсене на информация. Вместо да се ровите в регистрационни файлове за отстраняване на грешки, можете просто да филтрирате това, което търсите, като например среда или url.
Опитайте да опитате Grok изрази! Ако имате друг начин да направите това или имате проблеми с примерите по-горе, просто пуснете коментар по-долу, за да ме уведомите.
Благодаря, че прочетохте - и моля, следвайте ме тук в Medium за още интересни статии за софтуерно инженерство!
Ресурсы
PS
Телеграм канал от
Източник: www.habr.com