Splunk 웹 액세스 로그 상태를 기준으로 통계표를 작성하면

차트면 손이 간지럽지 않아!

사이트의 안전성 주변 설정을 수정할 때 변경 후 이용자 통신의 오단이 증가했는지 확인해야 한다.
Splunk에서 차단 경향(=반환 상태 코드)을 볼 수 있습니다.
구체적으로 소스 IP 또는α의 정보, 목표는 열에 되돌아오는 상태 코드를 모으는 것이다.
이러한 시각화로 줄에서 사용하는 정보는 연결원 IP만 있고 한 필드만 있다면chart만 사용하면 됩니다
행에 사용하고 싶은 필드가 늘어나면chart에서 통계를 낼 수 없기 때문에 어떻게 해야 하나요?
그래서 나는 다양한 시도를 했다.

간단히 나타낼 수 있는 상황

연결원 IP 단위로만 합치면 됩니다.

<search>
| chart count by address, status

에서 다음과 같다.
address
200
301
302
192.168.1.1
100
0
0
192.168.1.2
0
100
0
※ 다음은 동작 확인을 위해 손으로 기록한 양식이 완전히 다른 데이터를 사용한 결과입니다. 손으로 기록했다면 죄송합니다.
행에서 사용하고 싶은 정보가 많으면 번거롭다.
나는 이런 결과를 원한다
address
useragent
200
301
302
192.168.1.1
Mozilla/5.0...
80
0
0
192.168.1.1
curl ...
20
0
0
192.168.1.2
Mozilla/5.0...
0
100
0
이것은 chart 명령으로 실현할 수 없습니다. (가능하다.)첫 번째 파라미터는 여러 필드를 포함할 수 없기 때문이다.
나는 이런 상황을 해결할 방법을 많이 생각해 보았다.

시행착오

1. concatenate 행 정보

이렇게

<search>
| eval accessname = addess."-".useragent
| chart count by accessname, status

이 되다.
accessname
200
301
302
192.168.1.1-Mozilla/5.0...
80
0
0
192.168.1.1-curl ...
20
0
0
192.168.1.2-Mozilla/5.0...
0
100
0
이 정도면 충분하죠?이렇게 말해도 충분하지만 본질적으로 아름답지 않다는 것도 아니다.
이 처리를 마치고 SPL의 용도까지 더해서 만나기 위해 조금 더 조사해보도록 하겠습니다.
(현재 떠오르는 유력한 상황은dashboard에서 Searchbase를 사용해 한 번 대처리한 결과를 유지하고 판넬마다 필터할 때쯤이다.)

2.(아름답지 않은 방법)concatenate 통계를 거친 후 분할한다.

이렇게

<search>
| eval accessname = addess "-" useragent
| chart count by accessname, status
| rex field=accessname "(?<address>.*)-(?<useragent>.*)"

...예,useragent는 매우 자유로운 문자열입니다. 만약 "-"가 필드 값에 들어간다면...
이 경우 순조롭게 진행될 수 있지만 UA-IP의 순서, 다른 요소가 들어간 날에는.
정규 표현에서 필드의 추출 방법을 상세히 지정할 수도 있지만 번거롭고 순조롭지 못한 경우도 많아 줄거리가 좋지 않다.

3. 다가치 영역에서 대체(damepo)concentence

안 될 것 같은데.

<search>
| eval accessinfo = mvappend(addess, useragent)
| chart count by accessname, status

결과는 다음과 같다.
addressinfo
200
301
302
192.168.1.1
80
0
0
192.168.1.1
20
0
0
192.168.1.2
0
100
0
Mozilla/5.0...
80
0
0
curl ...
20
0
0
Mozilla/5.0...
0
100
0
chart가 멀티value를 처리할 때 멀티value라는 고정된 단위로 통계하는 것이 아니라 멀티value에 포함된value를 개별적으로 분류하여 계산합니다.
통계가 잘 나와도 한 번에 멀티바우로 변하는 필드를 재분해할 수 있는 좋은 방법을 찾지 못해 논리에 맞지 않는 것 같다.

해금

Join은 무거운 인상을 주기 때문에 별로 사용하고 싶지 않아요.
한 번에 2Fields를 합쳐서 마지막에 Join이 열을 추가하는 방법을 사용합니다.

<search>
| eval accessname = addess."-".useragent
| chart count by accessname, status
| join accessname [<search> | eval accessname = address."-".useragent]

...이게 검색에 잘 안 들어가면 큰 비참한 사건이 될 것 같아서요.
그리고 같은 검색 처리를 두 번이나 실시했기 때문에 그다지 예쁘지 않다.

차트 이외의 걸로 하는 게 어때요?eval {FIELD}

아래 내용을 참고하게 해 주세요.
https://qiita.com/toshikawa/items/eeb99d25cb4f64f429a1

<search>
| eval S_{status} = 1
| fields address, useragent, S_*
| stats sum(*) as * by address, useragent
| foreach S_* [eval <<FIELD>> = if(isnull(<<FIELD>>), 0, <<FIELD>>)]
| eval taltal = 0 | foreach S_* [eval total = total + <<FIELD>>]

마지막 두 줄은 공백 칸에 '0' 을 입력하는 데 사용되는 처리와 S*의 합계입니다.
그렇다면 다음과 같은 것이어야 한다.
address
useragent
total
S_200
S_301
S_302
192.168.1.1
Mozilla/5.0...
80
80
0
0
192.168.1.1
curl ...
20
20
0
0
192.168.1.2
Mozilla/5.0...
100
0
100
0
Join을 사용하는 것보다 조리가 있어 보이지만 실행하기에는 좀 무거울 수 있습니다.

Foreach 및 FIELD 탈선

이번 조사의 용도를 조사할 때 한동안 나는 중간에'foreach'를 사용할 수 없다고 느꼈다.
결국 틀렸어요. 모처럼 필기를 했어요.
이 때 eval식의 왼쪽 FIELD는 대상 필드 이름(status)이고 오른쪽 FIELD는 대상 필드의 값(200 또는 302 등)으로 전개된다.
처음에는 오른쪽의 전개만 보고 왼쪽이든 값이든 수치를 펼칠 줄 알았어요.
(나는 줄곧 eval식이'200'=...'인 줄 알았다.)

총결산

eval{FIELD} =의 메서드입니다.
캐럿에게 의지하지 않는다면 스스로 하나씩 쫓아라.
그나저나 가장 큰 성과는 이 문법의 존재다.
다른 용도로 사용하는 경우도 있는 것 같은데 잘 기억해 주세요.