TICKScript никогда не сбрасывает уровень в OK - PullRequest
Новая
       19

TICKScript никогда не сбрасывает уровень в OK

0 голосов
/ 07 декабря 2018

Я пишу TickScript, который действует на серию точек, которые могут иметь ровно два результата.

Либо результат - «пропущен», либо «не пройден» (обычно это какой-то вариант выхода из NUM).

Сценарий, который у меня есть, выглядит примерно так: 

// RP: autogen
// Monitor the result of updates
// WARNING if the result is anything other than pass
batch
    |query('''SELECT * FROM "mydb"."autogen"."measurement"''')
        .period(25h)
        .every(24h)
        .groupBy('host')
    |alert()
        .id('kapacitor/{{ .TaskName }}/{{ .Group }}')
        .infoReset(lambda: TRUE)
        .warn(lambda: "result" != 'pass')
        .message(
            '{{ index .Tags "host" }}' +
            '{{ if eq .Level "OK" }} are updating again.' +
            '{{ else }}' +
            'are failing to update.' +
            '{{ end }}'
        )
        .idField('id')
        .levelField('level')
        .messageField('description')
        .stateChangesOnly()
    @alertFilterAdapter()
    @alertFilter()

Сценарий, похоже, делает свое дело, но имеет критическую проблему никогда не возвращать уровень обратно в OK.

Если я буду кормить приток этими 4 точками: 

time                host     name                   result
----                ----     ----                   ------
1544079584447374994 fakeS176 /usr/bin/yum update -y pass
1544079584447374994 fakeS177 /usr/bin/yum update -y exit 1
1544129084447375177 fakeS176 /usr/bin/yum update -y exit 1
1544129084447375177 fakeS177 /usr/bin/yum update -y pass

Я бы ожидал 1 предупреждение и 1 ОК.Где все перечисленные выше временные метки находятся в пределах 25-часового периода.

Однако на самом деле происходит то, что я получаю 2 предупреждения и никаких подтверждений.

Может ли кто-нибудь дать несколько советов о том, как двигаться вперед

1 Ответ

0 голосов
/ 16 декабря 2018

Обновление - коллега рассказал мне об узлах, о которых я понятия не имел.Добавление узла last () и добавление as (), а затем удаление узла infoReset (), казалось, сделали это.

// RP: autogen
// Monitor the result of updates
// WARNING if the result is anything other than pass
batch
    |query('''SELECT * FROM "mydb"."autogen"."measurement"''')
        .period(25h)
        .every(24h)
        .groupBy('host')
    |last('result')
         .as('result')
    |alert()
        .id('kapacitor/{{ .TaskName }}/{{ .Group }}')
        .warn(lambda: "result" != 'pass')
        .message(
            '{{ index .Tags "host" }}' +
            '{{ if eq .Level "OK" }} are updating again.' +
            '{{ else }}' +
            'are failing to update.' +
            '{{ end }}'
        )
        .idField('id')
        .levelField('level')
        .messageField('description')
        .stateChangesOnly()
    @alertFilterAdapter()
    @alertFilter()

Винт этот проклятый язык.

...