FEATURE: Add cmdlog optional filtering

[6unYoung]

🔗 Related Issue

• https://github.com/jam2in/arcus-works/issues/626

⌨️ What I did

• cmdlog filter 명령을 처리하는 process_cmdlog_filter() 함수를 추가했습니다.
• 필터링 검사를 수행하는 is_cmdlog_filter_match() 함수를 추가했습니다.
• cmdlog_write()가 기존과 동일한 동작을 하게끔 command에 대한 로직을 수정했습니다.
• cmdlog_add(), cmdlog_remove(), cmdlog_list() 함수를 추가했습니다.
• cmd_log_global의 멤버 변수로 필터 리스트 struct cmd_log_filter filters[CMDLOG_FILTER_MAXNUM]을 추가했습니다.

명세

1. 필터 추가 명령어
   cmdlog filter add [command <cmd>] [key <key>]로 필터를 등록한다. command, key 옵션 중 하나는 생략할 수 있다. 생략된 옵션은 필터링하지 않는다. 문자 유효성 검사는 수행하지만, 명령어와 키의 존재 여부를 검사하진 않는다. 필터 수에는 제한이 존재한다.

예시

$ cmdlog start
$ cmdlog filter add command add key 01
    0. Filter: command = add, key = 01
$ add 01 0 0 2  // 로깅
$ add 01:02 0 5 1  // 로깅x(키 불일치)

$ cmdlog filter add command bop_insert
    1. Filter: command = bop_insert, key =
$ bop insert  // 필터가 일치해 명령의 결과와 상관없이 로깅
    CLIENT_ERROR bad command line format

// 옵션 모두 생략 시 에러
$ cmdlog filter add
    CLIENT_ERROR bad command line format

// 파라미터가 유효한지 검사
$ cmdlog filter add key \t\n
    CLIENT_ERROR bad command line format
$ cmdlog filter add command add key
    CLIENT_ERROR bad command line format
$ cmdlog filter add key a:b:d!#-^
    2. Filter: command = , key = a:b:d!#-^

// 단 파라미터의 존재 여부를 검사하진 않음
$ cmdlog filter add command dumm1
    2. Filter: command = dumm1, key =

// 필터 최대 개수에 제한 존재
$ cmdlog filter add key a
    3. Filter: command = , key = a
...
$ cmdlog filter add key b
    CLIENT_ERROR filter list is full

2. 필터 삭제 명령어
   cmdlog filter remove (index)로 필터를 삭제한다. 인덱스를 입력하면 찾아 삭제하고, 생략 시 모든 필터를 삭제한다.

예시

$ cmdlog filter remove 99
    CLIENT_ERROR  invalid parameters
$ cmdlog filter remove 2
    1 filters removed
$ cmdlog filter remove
    9 filters removed

3. 필터 출력 명령어
   cmdlog filter list로 필터 목록을 출력한다. 현재 필터 수와 최대 필터 수를 같이 출력한다.

예시

$ cmdlog filter list
    (2/10)
    1. command=     key=01
    2. command=add  key=02:02

[6unYoung]

의견이 필요한 부분이 몇 개 있어 확인 부탁드립니다.

1. 필터 추가 시 키를 무시하거나 필요로 하지 않는 명령(mget, flush, help, ..)에 대해 임의로 키를 같이 넣은 경우, 명령어가 실제로 입력될 때 키를 필요로 하지 않는 명령에 대해 키를 nul로 처리하므로 해당 필터는 절대 매칭되지 않습니다. 이런 경우에 대해 키를 입력하지 못하도록 방어 코드가 필요할까요?

2. 필터를 동적으로 변경하는 기능은 없어도 된다고 하셨는데, 동적 변경을 막으려고 하면 코드가 다소 지저분해질 것 같습니다.
   기존 코드에서는 process_cmdlog_command()에서 cmdlog_start()등을 호출할 때 already_check 변수를 인자로 넘겨 cmdlog.c에 존재하는 cmdlog_in_use의 true/false 여부에 따라 에러 처리를 하고 있습니다. 그런데 filter 기능은 별도의 subcommand를 요구하므로 process_cmdlog_filter()를 만들어 cmdlog_filter_add()등을 호출하게 했습니다. 따라서 기존 코드와 같은 레벨에서 에러 핸들링도 안되고, 리턴 코드로 넘기기에도 좋진 않아 보입니다.
   그래서 일단 동적 변경을 허용하게 했는데, 기능적으로 문제가 될까요?

[ing-eoking]

개인 의견입니다.

필터 추가 시 키를 무시하거나 필요로 하지 않는 명령(mget, flush, help, ..)에 대해 임의로 키를 같이 넣은 경우, 명령어가 실제로 입력될 때 키를 필요로 하지 않는 명령에 대해 키를 nul로 처리하므로 해당 필터는 절대 매칭되지 않습니다. 이런 경우에 대해 키를 입력하지 못하도록 방어 코드가 필요할까요?

이 경우는 사용자가 잘못 넣은 경우에 해당하므로 별다른 처리를 할 필요가 없을 것 같습니다.
필터 조건에 명령어를 없는 명령어를 넣는 경우와 유사하지 않을까 생각됩니다. (ex. cmd=abcdef)

필터를 동적으로 변경하는 기능은 없어도 된다고 하셨는데, 동적 변경을 막으려고 하면 코드가 다소 지저분해질 것 같습니다.
기존 코드에서는 process_cmdlog_command()에서 cmdlog_start()등을 호출할 때 already_check 변수를 인자로 넘겨 cmdlog.c에 존재하는 cmdlog_in_use의 true/false 여부에 따라 에러 처리를 하고 있습니다. 그런데 filter 기능은 별도의 subcommand를 요구하므로 process_cmdlog_filter()를 만들어 cmdlog_filter_add()등을 호출하게 했습니다. 따라서 기존 코드와 같은 레벨에서 에러 핸들링도 안되고, 리턴 코드로 넘기기에도 좋진 않아 보입니다. 그래서 일단 동적 변경을 허용하게 했는데, 기능적으로 문제가 될까요?

동적으로 변경되어도 상관없을 것 같습니다.