MaxHousekeeperDelete에 대해서

MaxHousekeeperDelete에 관해서 설명드리겠습니다.

MaxHousekeeperDelete은 Default가 5000으로 설정되어 있습니다.
이 파라미터는 HousekeepingFrequency에 설정된 시간에 삭제하는 최대치라고 생각하시면 일부는 맞고, 일부는 틀립니다.
만약, HousekeepingFrequency의 설정을 24로 했다고 예를 들겠습니다. 그럼 쌓인 데이터를 지우는데 최대 5000까지 밖에 못지운다는 이야기입니다. 그럼, 하루에 10000데이터가 쌓인다면 언젠가는 DB에 데이터가 넘쳐 멈춘다는 이야기 입니다.
그럴까요?
그래서 MaxHousekeeperDelete은 Housekeeper와 관계는 있습니다만, 위에 설명드린 것과는 관계가 없는 것입니다. 이 파라메타는, ITEM을 삭제할때 사용되는 파라메타 입니다.
삭제할 ITEM에 지금 까지 데이터가 1000만건 있다고 하겠습니다. 그럼 ITEM을 삭제하니한번에 이걸 지울까요? 그럼, DB에 부하가 엄청 걸립니다.
그때 사용되는 파라메타가 MaxHousekeeperDelete입니다.
삭제한 ITEM의 데이터를 한번에 지우지 않기 위해서, 매시간 얼마만큼의 데이터를 기울지를 결정하는 파라메타입니다.

이 작업을 확인하기 위해서는, 하나의 ITEM을 삭제 해봅니다.
그럼 housekeeper라는 테이블에 삭제한 ITEM이 Insert되어진 것이 보일것입니다.
이 ITEM은 데이터가 전부 삭제되면 테이블로 부터 지워지게 됩니다.

제가 MaxHousekeeperDelete을 설명하는 이유는
Housekeeper가 무거워져서 MaxHousekeeperDelete을 조절하는 분들이 계십니다.삭제한 ITEM이 있다면 효과적이지만, 만약에 없고 계속 무겁다면 DB 튜닝을 추천드리기 위해 이글을 썻습니다.

많은 참조 바랍니다.

Zabbix의 Housekeeper에 대해서

Housekeeper라함은, Zabbix의 아이템에서 수집한 데이터를 일정 기간만큼 저장하다가 기간이 지나면 데이터를 삭제해야 합니다. 이 기능을 하는 것이 Housekeeper입니다.

본 설명은 Zabbix 3.0을 기준으로 하고 있습니다.

1. 아이템설정에 있는 보존 기간

보존기간은 아이템마다 설정하는 것이 가능합니다.

빨간 부분이 히스토리와 트랜드를 보존하는 기간을 설정하는 곳입니다.
각 아이템마다 설정하는 곳이 있어 중요도에 따라 기간을 다르게 설정합니다.

2. 데이터 이괄 보존 기간 설정

데이터의 보존 기간을 이괄적으로 관리합니다.

관리 →　일반 →　오른쪽 위에 있는 데이터 보존기간을 선택합니다.

데이터 삭제처리를 활성화에 체크를 하면, Zabbix의 Housekeeper가 실행됩니다.

위의 페이지에서는 보이지 않습니다만, 밑에 부분에 가면 이력과 트렌드가 있습니다.

이력은 아이템의 히스토리를 이야기하는 것입니다.

이력 또는 트랜드의 보존기간을 덮어 쓰기를 체크하면 각 아이템에 써있는 보존기간을 무시하고 위의 보존 기간을 사용하게 됩니다.

보존기간을 기존의 기간보다 짧게 변경하여도, 데이터의 양은 급격하게 변경되지 않습니다.

그이유는, Zabbix의 Housekeeper기능이 갑자기 많은 양의 데이터를 지우게 되면 DB에 부하를 주게 되는데 이것을 방지하위함 입니다. 

계산식은

rule->min_clock = MIN(keep_from, rule->min_clock +

HK_MAX_DELETE_PERIODS * CONFIG_HOUSEKEEPING_FREQUENCY * SEC_PER_HOUR);

계산식 해설：

zabbix_server.conf파일에 HousekeepingFrequency가 있습니다. 위의식 CONFIG_HOUSEKEEPING_FREQUENCY에 해당하는 값입니다.

HousekeepingFrequency은 Housekeeper의 주기를 말함니다. 단위는 시간입니다.

HousekeepingFrequency가 1이라는 것은 1시간 주기로 작업하는 것이고, 2라는 뜻은 2시간 주기로 작업하라는 의미 입니다.

HK_MAX_DELETE_PERIODS은 4로 고정값입니다.

SEC_PER_HOUR은 1을 의미 합니다.

min_clock은 가장 오래된 데이터의 작성 일시 입니다.

keep_from은 WEB화면에서 입력한 데이터 보존 기간입니다.

예) 지금까지 데이터 보존 기간이 30일이였는데, 이것을 20일로 변경할 경우 어떻게 되나?

HousekeepingFrequency=1로 설정

해설：이 계산식은 unit time을 이용합니다. unix time은 지금이 제일로 많은 시간이라는 것을 의미합니다.

결국, 보존 기간을 20일로 변경하여도, 가장 오래된 데이터는 30일전의 것이므로

가장 오래된 데이터(30일전) +(HousekeepingFrequency＊４)를 매시간 실시 하게 됩니다.

10일치를 해결하기 위해서는 60시간이 필요하게 됩니다.

20일 보다 오래된 데이터가 없어지면, 그때부터는 20일이 기준이 되어 1시간 분의 데이터가 삭제되게 됩니다.

3. 수동 작업

데이터 삭제처리를 활성화에 체크를 하지 않습니다.

또는 HousekeepingFrequency=0를 설정합니다.

그러면, Housekeeper은 자동 삭제를 하지 않습니다.

가장 부하가 없는 시간을 찾아 데이터를 저장하고 있는 데이블을 수동으로 삭제 합니다.

대상 테이블은

history,　history_str,　history_log,　history_uint,　history_text,　trends,　trends_uint,　service_alarms,　auditlog, events, sessions

입니다.

정기적으로 위의 테이블들을 삭제하면 Housekeepr와 같은 작업이 되는 것입니다.

작업 내용은

https://naiggy.blogspot.jp/2017/03/zabbix-housekeeper_69.html

을 참조해 주시길 바라겠습니다.

정기적으로 삭제하기 위해서 Job Arranger를 추천 드립니다.

개요는

https://naiggy.blogspot.jp/2017/03/job-arranger.html

인스톨 방법은

Mysql

https://naiggy.blogspot.jp/2017/03/job-arranger-install-centos-7-mariadb-kr.html

참조 바랍니다.

Zabbix Housekeeper 수동 실행

Zabbix Housekeeper에 대해서는
http://naiggy.blogspot.com/2017/03/zabbix-housekeeper_23.html
을 참조해 주십시요.

수동실행은
저의 경우는 60일 이전의 데이터는 삭제 하라는 스크립트 입니다.
60이라고 쓰여진 곳을 수정하여 원하시는 숫자를 넣어 주십시요.

Mysql

delete from history where clock < UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL 60 day));
delete from history_str where clock < UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL 60 day));
delete from history_log where clock < UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL 60 day));
delete from history_uint where clock < UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL 60 day));
delete from history_text where clock < UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL 60 day));
delete from trends where clock < UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL 60 day));
delete from trends_uint where clock < UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL 60 day));
delete from service_alarms where clock < UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL 60 day));
delete from auditlog where clock < UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL 60 day));
delete from events where clock < UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL 60 day));
delete from sessions where lastaccess < UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL 60 day));

PostgreSQL

delete from history where clock < extract('epoch' from current_timestamp - interval'60 days') ;
delete from history_str where clock < extract('epoch' from current_timestamp - interval'60 days') ;
delete from history_log where clock < extract('epoch' from current_timestamp - interval'60 days') ;
delete from history_uint where clock < extract('epoch' from current_timestamp - interval'60 days') ;
delete from history_text where clock < extract('epoch' from current_timestamp - interval'60 days') ;
delete from trends where clock < extract('epoch' from current_timestamp - interval'60 days') ;
delete from trends_uint where clock < extract('epoch' from current_timestamp - interval'60 days') ;
delete from service_alarms where clock < extract('epoch' from current_timestamp - interval'60 days') ;
delete from auditlog where clock < extract('epoch' from current_timestamp - interval'60 days') ;
delete from events where clock < extract('epoch' from current_timestamp - interval'60 days') ;
delete from sessions where lastaccess < extract('epoch' from current_timestamp - interval'60 days') ;