Thank you for reading this post, don't forget to subscribe!

Необ­хо­ди­мо создать отдель­ные кана­лы для backend, web, gaming, и их алер­ты выне­сти в раз­ные кана­лы Slack. Тогда бекенд-деве­ло­пе­ры будут знать, что если в их канал Сла­ка при­ле­тел алерт – то на него таки сто­ит обра­тить внимание.

Как реа­ли­зу­ем: исполь­зу­ем Prometheus Recording Rules для пра­вил, что бы создать отдель­ные алер­ты. Каж­дый алерт будет созда­вать­ся со сво­им набо­ром тегов, исполь­зуя кото­рые мы в Opsgenie будем раз­ру­ли­вать алер­ты через раз­ные Slack-интер­га­ции по раз­ным каналам.

Prometheus Recording Rules

Recording Rules поз­во­ля­ют фор­ми­ро­вать пра­ви­ла с expression, кото­рые потом мож­но исполь­зо­вать в алертах.

К при­ме­ру, у нас есть такой алерт:

Тут исполь­зуя общее пра­ви­ло blackbox_probe:http_probe мы созда­ём два алер­та – один сра­бо­та­ет с уров­нем P3/warning через 2 мину­ты, а вто­рой – с уров­нем P1/critical через 5 минут, если пер­вый не закрыли.

Prometheus Tags

Соб­ствен­но гово­ря, тут теги – это про­сто допол­ни­тель­ное поле в аннотациях.

В кон­фи­ге Alertmanager для reciever Opsgenie настро­е­на пере­да­ча этих тегов – tags: "{{ .CommonAnnotations.tags}}":

И затем эти теги доступ­ны в Opsgenie:

А зна­чит – мы их смо­жем исполь­зо­вать в филь­трах Slack-интеграций.

AWS CloudWatch Tags?

А что делать с CloudWatch? В Opsgenie есть отдель­ные инте­гра­ции с AWS CloudWatch, кото­рые триг­ге­рят свои алерты.

Увы – к CloudWatch Alarms теги при­кру­тить нель­зя (пока что? не нашёл как?), поэто­му дела­ем через теги в самой интеграции.

Напри­мер, для AWS Trusted Advisor зада­ны такие теги:

Поз­же мож­но будет раз­ру­ли­вать меж­ду кана­ла­ми типа #devops-alarms-aws и #devops-alarms-security.

Настройка Prometheus alerts

Настро­им общий Recording Rule, и исполь­зуя его – созда­дим два алер­та, кото­рые будут выби­рать мет­ри­ки, исполь­зуя label namespace:

Тут очень при­го­ди­лось то, что мы изна­чаль­но в име­на нейм­с­пей­сов Kubernetes вклю­ча­ем и кла­стер (dev, stage, prod), и коман­ду, кото­рая этот Namespace создавала.

Напри­мер, в име­ни namespace=prod-cn-1-18-backend-rabbitmq-ns мы видим, что это Prod-кла­стер в Китае (cn), вер­сия Kubernetes в нём – 1.18, коман­да, кото­рая исполь­зу­ет этот сер­вис – backend, ну и имя само­го сер­ви­са – rabbitmq.

А затем к каж­до­му алер­ту мы наве­сим свои теги – backend и web.

Итак, созда­ём Recording Rule с име­нем test:eks:pod_restarts:rate:

Само выра­же­ние нам сей­час не осо­бо важ­но, тут про­сто ско­пи­ро­вал пра­ви­ло из алер­та рестар­тов подов.

Далее, исполь­зуя этот rule опи­сы­ва­ем два алерта:

Тут в алер­те TestingAlertBackend исполь­зу­ем пра­ви­ло test:eks:pod_restarts:rate, и выби­ра­ем все нейм­с­пей­сы, кото­рые содер­жат имя backend:

А затем к это­му алер­ту добав­ля­ем два тега – backend и eks.

Ана­ло­гич­но – с алер­том для Web-team.

Alertmanager group_by

Кро­ме того, доба­вим в пара­метр group_by Алерт­ме­не­дже­ра груп­пи­ров­ку по тегам, что бы алер­ты Backend отде­ля­лись от алер­тов Web:

Ина­че, если груп­пи­ро­вать толь­ко по alertname, Alertmanager сге­не­ри­ру­ет один алерт, кото­рый упа­дёт в пер­вый попав­ший­ся канал.

Пере­хо­дим к Opsgenie.

Настройка Opsgenie и Slack

Созда­ём два кана­ла в Slack – #devops-alarms-backend и #devops-alarms-web – будем их исполь­зо­вать в двух инте­гра­ци­ях Slack.

Далее, добав­ля­ем саму первую инте­гра­цию Slack, для Backend-team, и в его Alert Filter выби­ра­ем алер­ты уров­ня P3 и с тегом backend:

А в ста­рой инте­гра­ции – #devops-alarms-warning – добав­ля­ем фильтр с NOT, что бы не дуб­ли­ро­вать алер­ты в ста­рый канал:

Про­ве­ря­ем – триг­ге­рим алерт, и полу­ча­ем пач­ку алер­тов в оба канала.

Бекенд:

Тут Tags: backend, eks.

И ана­ло­гич­ная пач­ка при­ле­те­ла от подов веб-команды:

Гото­во