Procurar no vídeo

0:01
Bem-vindos ao Observabil.
0:04
É um curso especializado em
0:06
observabilidade. Aqui eu vou trazer para
0:08
vocês todos os conceitos primordiais
0:11
para se colocar ou se instrumentar uma
0:13
boa observabilidade na sua
0:15
infraestrutura, bem como ah mostrar
0:18
exemplos práticos disso, né? exemplos
0:20
que vocês vão conseguir entender mais ou
0:22
menos como é que se instrumenta isso no
0:25
ambiente de vocês. Mas antes de começar,
0:29
eh, é importante a gente salientar uma
0:31
coisa, o motivo de da gente com colocar
0:35
a observabilidade nos nossos ambientes,
0:38
tá? Eh, existe
0:41
toda uma lógica por trás disso, tá? E
0:44
hoje eu vou mostrar para vocês eh a
0:47
primeira aula do nosso curso. É
0:49
basicamente pra gente entender qual é o
0:51
motivo, por que que a gente faz isso. Eu
0:53
vou dar dois cenários. Um cenário em que
0:56
eh é uma empresa que não tá com log,
0:59
métrica, tracing instrumentado,
1:03
não tem observabilidade, não tem cultura
1:05
de observabilidade como que ela encara
1:07
os problemas, tá? E aí vou dar um
1:10
exemplo também de uma empresa que tem
1:13
observabilidade e consegue encarar os
1:16
problemas com dados. Vamos lá, pessoal.
1:19
Estamos aqui no velho scale draw. Não
1:23
sei se é assim que se fala, mas vamos
1:24
lá. Então, eh, primeiramente a gente tem
1:28
uma aplicação backend.
1:30
Vou botar aqui backend. Ohô, meu Deus,
1:35
tá um pouquinho pequenos aqui, tá? Back.
1:38
Vou só botar back que ela se comunica
1:41
com uma aplicação frontende.
1:47
Quer dizer, é inverto, né? Invertido
1:50
isso aqui.
1:52
Front change que se comunica com esse
1:53
back front.
1:56
Essa empresa aqui, pessoal, então ela
1:58
não tem observabilidade, tá? Ela não tem
2:01
observabilidade nenhuma, ela não
2:03
instrumentou nada, ela não tem nada
2:05
instrumentado, tá? E ela é bem simples,
2:08
uma empresa simples, tem, vamos dizer
2:10
que é essa aplicação que tá funcionando.
2:13
Ela tem uma infraestrutura aqui na WS.
2:16
Vou botar aqui, ó. Ela trabalha aqui na
2:18
WS.
2:21
Ah, deixa eu ver aqui. Ela trabalha aqui
2:23
na WS.
2:25
Botar aqui a WS. Isso aqui tá tudo na
2:28
nuvem WWS. OK. Tudo bem.
2:32
E ela não tem nada de um logo
2:35
instrumentado. Essa essa aplicação aqui
2:37
backend, ela se comunica com outras
2:42
outros fins aqui. Vamos botar que são
2:44
APIs externas.
2:47
Opa,
2:49
são APIs externas. OK.
2:54
APIs externas.
2:58
Geralmente um aplicação aí de grande uma
3:02
aplicação normal, ela tem um front que
3:04
se comunica com back e o back às vezes
3:06
faz algumas solicitações para fora
3:08
externamente. Isso vai depender muito da
3:10
arquitetura. Isso aqui é a mais
3:12
simplista possível que eu consegui
3:14
pensar aqui para vocês agora nesse exato
3:16
momento, tá? Vamos dizer que pessoal aí
3:20
dessa empresa, empresa que não tem,
3:22
vamos vamos criar um nome para essas
3:24
empresas aqui, né? Deixa eu pensar aqui.
3:27
Empresa Belelu.
3:30
Meu filho fala assim,
3:32
o filho gosta desse nome.
3:35
Belelu.
3:38
A empresa Belelu tá ali com seus pessoal
3:42
trabalhando lá. E aí, por algum motivo,
3:47
essa aplicação aqui não tem logo
3:49
instrumentado, não tem tracing, não tem
3:51
métrica. Então eles não conseguem
3:53
identificar se essa aplicação tá dando
3:56
algum problema. E aí alguns clientes
3:59
começaram a identificar que a ao fazer
4:02
alguma solicitação pro fronte, a a
4:06
alguma coisa estava dando errado. Então
4:07
a gente tinha um erro aqui no front end,
4:10
mas não a gente não sabe da onde que tá
4:12
vindo esse erro, tá? Então, a gente sabe
4:14
que o erro tá acontecendo aqui no front,
4:17
mas pode ser que seja proveniente do
4:19
back ou pode ser uma AP externa dando
4:23
problema, viu? Agora o problema aí é que
4:26
a gente não sabe aonde que isso tá
4:28
acontecendo, o por que isso tá
4:30
acontecendo. Então, vamos dizer que a
4:33
gente tem que resolver esse problema. a
4:35
gente tá administrando ali a
4:37
infraestrutura dessa dessa arquitetura
4:40
ou a gente é um desenvolvedor que
4:41
precisa resolver esse problema e a gente
4:43
precisa saber como a gente vai achar
4:47
isso sem logos instrumentados, sem
4:49
tracer, sem nada desse gênero. Beleza? O
4:52
que a gente pode fazer é entrar nos e n
4:55
na infra, na máquina, no podidar
4:58
se a gente consegue pegar algum tracing
5:01
do back end, alguma coisa do tipo. E aí
5:04
depois a gente consegue saber, vamos
5:06
dizer que a gente conseguiu descobrir
5:08
que na verdade o erro tá aqui, não
5:11
front. O front só tá repercutindo um
5:14
erro que o back tá devolvendo. Beleza, a
5:17
gente conseguiu descobrir isso depois de
5:19
sei lá, 30 minutos. ou 40 minutos a
5:22
gente se esforçando, eh, procurando,
5:26
vendo logs da até do sistema para ver se
5:30
a a gente consegue pegar alguma coisa,
5:32
né? E log de tracing da própria
5:35
biblioteca ali que ela tá que ela tá
5:37
mostrando. Fomos procurar em stack
5:40
overflow e perguntando por um monte de
5:43
coisa aí pra gente conseguir achar a
5:45
resposta. Conseguimos achar que o
5:47
problema é no back end. Agora a gente
5:49
vai ter que eh criar uma solução, tá
5:52
beleza? Ah, procuramos uma solução,
5:55
descobrimos que pode ser um método aqui
5:57
da nossa nosso back que tá quebrando.
6:00
Vamos tentar resolver. A gente sobe um
6:02
fix e a gente descobre que, na verdade,
6:05
a gente não tava com problema no nosso
6:07
backend. A gente tava com problema, a
6:11
gente tava com problema aqui na nossa P
6:14
externa. Então o problema tava aqui, o
6:17
erro tava aqui na P externa, ou seja, a
6:20
P externa começou a dar erro, o nosso
6:23
backend não conseguiu processar certas
6:25
métodos ou funções que dependiam dessa
6:28
AP externa e retornou um erro pro front
6:31
ali, tá? E aí a gente, como a gente não
6:34
sabia disso aí, a gente não tava
6:37
preparado para isso, a gente teve que
6:40
fazer um fix na hora ali para fazer um
6:42
circuit breaker algum do tipo. Caso essa
6:45
P externa aqui não esteja funcionando, a
6:48
gente só passa direto, dá uma exception
6:52
ou tenta fazer um fall com outro tipo de
6:55
API, né? Então, a gente gastou aqui no
7:00
mínimo do mínimo ali na na no melhor do
7:03
cenário umas duas a 3 horas aqui para
7:05
debugar uma situação que seria muito
7:08
simples da gente resolver se a gente
7:11
tivesse observabilidade ou até mesmo e
7:14
logs instrumentados, tá? Aqui eu quero
7:17
mostrar para vocês que a gente poderia
7:20
ter descoberto essas mesmo problema com
7:23
logs e métricas instrumentadas. Fica aí
7:26
e eu vou mostrar para vocês como que a
7:27
gente acharia esse problema com
7:29
métricas, logs e tracing. No próximo
7:33
vídeo eu vou explicar direitinho como é
7:34
que a gente encontrar essas coisas,
7:36
esses problemas mais rápido e mais
7:39
fácil.
0:01
E aí, pessoal, de volta aqui a
0:04
Observability and Drip. Vamos ver o
0:07
outro cenário com uma empresa que tem
0:09
observabilidade e vamos ver o que que
0:11
aconteceria, né? Vamos, vamos dar uma
0:13
olhada nisso. Vou mostrar para vocês o
0:16
cenário que seria num lugar que tem
0:19
observabilidade instrumentado.
0:22
Beleza? A mesma empresa, vamos dizer que
0:25
tem uma empresa igualzinha, que tem um
0:27
uma arquitetura bem parecida. E essa
0:30
aqui é a Balalau. Pera aí.
0:33
Em vez de ser a Beleléu, ela é a
0:35
Balalau.
0:37
Balalau. A empresa Balalau, ela tem uma
0:41
observabilidade instrumentada, ela tem
0:43
log, ela tem tracing das aplicações
0:46
dela. No caso, ela só tem uma, então ela
0:48
tem trace do que acontece nesse backend
0:50
aqui. Além disso, ela tem a
0:54
rastreabilidade das APIs externas dela.
0:56
Então, tipo, ela consegue saber quando
1:00
uma API externa está off. ou não, ela
1:04
vai ter uma um sistema de log, um
1:09
sistema de alertas que vão bater nessa
1:12
API por meio, pode ser por meio do back
1:15
end. Esse back end vai informar que essa
1:17
PI tá fora, vai gerar um log e vai gerar
1:20
um alerta para toda a empresa ou para o
1:24
a equipe responsável, né? Então aqui em
1:28
menos de 10 minutos a gente já
1:31
entenderia qual era o problema. né? A
1:33
gente ia receber esse alerta sabendo que
1:36
a API externa aqui ela tava fora, ou
1:41
seja, aqui ia gerar uma alerta pra
1:43
gente,
1:45
certo?
1:46
aqui ia gerar um alerta pra gente.
1:50
Esse alerta
1:52
vai criar uma ação. Mais na frente, no
1:55
curso eu vou explicar para vocês a
1:58
diferença de ticket, alerta, iso, todo
2:02
esse tipo de coisa, tá? aqui gera uma
2:04
ação e essa ação seria a gente fazer
2:07
alguma coisa em prol dessa P externa
2:10
aqui para ela pro nosso serviço voltar a
2:12
funcionar e o cliente aqui final não tá
2:15
recebendo esses erros. Então, ou seja,
2:18
conseguimos identificar o problema em 10
2:20
minutos. Em menos de uma hora, se a
2:22
gente for proativo ali com a solução do
2:25
problema, a gente consegue resolver.
2:27
Viram só o que acontece quando a gente
2:29
tem observabilidade implementada, a
2:31
cultura de observabilidade, não só a
2:34
cultura, como também todo essa stack de
2:37
logs, trace simétricas, tá? Então esse é
2:41
o principal ponto aqui que eu quero
2:43
mostrar para vocês, que a
2:45
observabilidade vem para ajudar a gente
2:48
melhorar nosso fluxo e ser mais proativo
2:52
e e mais rápido na solução dos
2:54
problemas, né? Porque no final das
2:56
contas a gente precisa resolver os
2:57
problemas antes que eles aconteçam, né?
3:01
Então vamos lá, gente, vamos pro próximo
3:03
vídeo que eu vou falar um pouquinho mais
3:05
sobre a metodologia do observability em,
3:10
né, que é o olho que tudo vê. Eu vou
3:12
explicar o que que é o olho que tudo vê
3:14
e qual é essa metodologia. A gente se vê
3:17
no próximo vídeo.
0:01
Dale, pessoal, eu aqui de volta. Vamos
0:04
falar um pouquinho sobre o olho que tudo
0:05
vê antes da gente começar com os
0:07
conteúdos do da metodologia em si, né?
0:10
Essa metodologia foi e eu inventei da
0:12
minha cabeça, mas basicamente é a forma
0:15
que a gente vai encontrar pra gente
0:17
conseguir concluir os o nosso objetivo
0:20
principal, que é o quê? A gente precisa
0:22
entregar valor pra empresa de alguma
0:24
forma. Entregando a observabilidade
0:26
ideal, a gente consegue entregar valores
0:28
muito bons, assim, valores entregáveis
0:32
muito gratificantes paraa empresa.
0:34
Então, ao final desse curso, quando você
0:36
implementar a metodologia do olho que
0:38
tudo vê, você vai ter um produto final
0:41
muito bom. Então, vamos lá, vou explicar
0:44
para vocês como que funciona esse
0:46
carinha. Ah, esse daqui é da aula
0:49
passada. Vamos lá.
0:51
O olho que tudo vê, ele tá englobado em
0:54
algumas partes, tá? A primeira delas é,
0:57
a gente precisa entender o que são os
0:59
indicativos. Então, o que que é um SLI,
1:02
o que que é um SLO, o que que é um SLA.
1:05
Isso daqui são coisas muito importantes
1:09
e sem essas informações a gente não
1:11
consegue trhar um caminho correto da
1:15
nossa observabilidade. São esses dados
1:17
aqui que vão fazer com que a gente vá
1:20
para algum canto. Inclusive a próxima
1:21
aula é sobre essas nomenclaturas aqui.
1:24
Então, depois da gente ter os
1:26
indicativos, a gente precisa entender o
1:29
que são alertas,
1:31
né? O que são alertas? Qual é o motivo
1:34
do alerta? Quando que deve ser alertado?
1:37
O que são tickets, que são
1:41
issues e etc. Além disso, a gente
1:43
precisa entender o que é um log.
1:47
O que é um log? Por que a gente precisa
1:50
de um log? Qual é o motivo do log?
1:54
A gente precisa entender também
1:56
métricas, as métricas, os dados,
2:01
certo? A gente precisa entender as
2:03
métricas,
2:05
o que que a gente pode pegar de métrica,
2:07
o o quais são as métricas mais
2:10
importantes para nossa aplicação e tudo
2:13
isso. Eu vou até colocar aí isso aqui
2:16
mais para cá, ó, para vocês entenderem
2:18
mais dentado.
2:22
Botar dentado para para cá.
2:25
Tudo isso a gente vai se basear nos
2:29
nossos indicativos de negócio, né?
2:32
E o que que quer quer dizer isso?
2:35
Além Ah, esqueci aqui do do tracing. Tem
2:39
tracing também.
2:42
E os erros, né, gente? Pelo amor de
2:44
Deus, como é que eu ia esquecer do erro?
2:49
Erros.
2:51
Bom, a gente tem, tá, a gente dentro
2:55
desses indicativos, a gente vai ter um
2:58
conceito de alerta, conceito de log,
3:01
conceito de métrica de saúde das
3:04
aplicações, das da nossa ínfa, da eh de
3:08
sistemas que são externos. a gente tem
3:11
tracing, em qual fluxo, em qual parte
3:14
nossa aplicação tá quebrando, em qual eh
3:18
em qual end point e em qual função a
3:21
gente consegue entender aqui com
3:22
tracing. E os erros, a gente precisa
3:25
saber a quantidade de erros que a gente
3:26
tá recebendo, o que que tá acontecendo e
3:29
se a gente tá logando erro, se a gente
3:31
tá imputando, se a gente tá dando output
3:34
de erro em certas situações. Caso
3:37
contrário, a gente nem tá sabendo que tá
3:39
acontecendo o erro. Então, o olho que
3:41
tudo vê,
3:45
olho que tudo vê,
3:47
o olho que tudo vê, não vou escrever
3:49
isso aqui. Será que tem alguma coisinha
3:52
de olho aqui? Não tem olho.
3:56
Nosso olho são isso, são nossas são
4:00
nossos indicativos combinados com todos
4:02
esses dados aqui, tá? Então ele vai ver
4:05
o quê? Ele vai ver a aplicação, que é
4:09
isso, que são os indicativos da nossa
4:12
aplicação, nosso negócio, nossas regras
4:14
de negócio, o que a gente precisa que
4:16
funcione, quanto tempo de de
4:20
indisponibilidade a gente tá disposto,
4:22
né, a a pagar. Então, o olho que tudo vê
4:27
é a implementação desses conceitos, o
4:31
entendimento deles e como que você vai
4:33
instrumentar isso para vários cenários.
4:35
Espero que vocês tenham entendido qual é
4:38
o intuito desse curso e e por que ele se
4:41
chama o olho que tudo vê. Essa
4:43
metodologia foi feita especialmente para
4:45
entregar valor, pra gente criar coisas
4:49
sem se preocupar em quebrá-las, porque a
4:52
gente tá monitorando, a gente tá vendo
4:53
tudo que pode dar de errado no negócio.
4:57
Então é isso aí, gente. Até o próximo
4:59
vídeo. Eu vou começar a explicar com
5:01
mais detalhes cada tópico desse e aí a
5:04
gente vai ter exemplos práticos aí nos
5:06
no próximo módulo, começando com os
5:08
logs. Até a próxima aula.
0 comentários
Alexandre Mulina
Adicione um comentário…
Observability in deep
Mario Valente
4 / 73

7:40
Observabilidade do jeito errado (Curso observability in deep) #01
Mario Valente

3:19
Observabildade do jeito certo (observability in deep) #2
Mario Valente

5:11
Entendendo a metologia (Observability in deep) #3
Mario Valente

6:18
Indicadores primordiais (Observability In deep) #4
Mario Valente

9:27
Os três outputs da observabilidade(Observability In deep) #5
Mario Valente

8:15
Entendendo a importância da observabilidade(Observability In deep) #6
Mario Valente

3:26
Oque é um SLI (Observability In deep) #7
Mario Valente

6:14
Oque é um SLO (Observability In deep) #8
Mario Valente

9
2:26
Oque é um SLA(Observability In deep) #9
Mario Valente

10
Entendo oque é o Error budget (Observability In deep) #10
Mario Valente

11
Introdução aos logs (observability in deep) #11
Mario Valente

12
Oque é um log ? (observability in deep) #12
Mario Valente

13
Ferramentas necessárias (observability in deep) #13
Mario Valente

14
Criando nossa Infra (observability in deep) #14
Mario Valente

15
Instrumentando os logs (observability in deep) #15
Mario Valente

16
Explorando o Grafana Loki (Observability in deep) #16
Mario Valente

17
Finalizando o modulo de logs (observability in deep) #17
Mario Valente

18
Introdução The for golden signals (observability in deep) #18
Mario Valente

19
Oque é Latência na observabilidade ( Observability in deep) #19
Mario Valente

20
O que é o Tráfego na observabilidade (observability in deep) #20
Mario Valente

21
O que é Saturação na observabilidade ? (observability in deep) #21
Mario Valente

22
Oque são os erros na observabilidade ? (observability in deep) #22
Mario Valente

23
The for golden signals (observability in deep) #23
Mario Valente
24
Ferramentas necessárias para capturar as nossas métricas (Observability in deep)
#24
Mario Valente

25
Entendendo nosso Labs (observability in deep) #25
Mario Valente

26
O que é o prometheus operator (observability in deep) #26
Mario Valente

27
Criando nosso cluster kubernetes e instalando nossas ferramentas (observability in
deep) #27
Mario Valente

28
Config personalizadas (observability in deep) #28
Mario Valente

29
Instrumentando as métricas com prometheus(observability in deep) #29
Mario Valente

30
Explorando o Grafana(observability in deep) #30
Mario Valente

31
Criando dashboards no grafana (observability in deep) #31
Mario Valente

32
Métricas histogram no grafana(observability in deep) #32
Mario Valente

33
Criando dashboards de saturação (observability in deep) #33
Mario Valente

34
Finalizando modulo de métricas(Curso observability in deep)#34
Mario Valente

35
Introdução ao modulo de tracing(observability in deep)#35
Mario Valente

36
Entendendo o que é tracing(observability in deep) #36
Mario Valente

37
O que é um spam(observability in deep) #37
Mario Valente
38
Como vamos resgatar os tracing(observability in deep) #38
Mario Valente

39
Aviso importante(observability in deep) #39
Mario Valente

40
Explicando Grafana Tempo (observability in deep)#40
Mario Valente

41
OUTRO Aviso importante (observability in deep)#41
Mario Valente

42
Instalando o open telemetry(observability in deep)#42
Mario Valente

43
Aprofundando nas configs do Grafana Tempo(observability in deep) #43
Mario Valente

44
Open telemetry collector(observability in deep) #44
Mario Valente

45
Instalando as ferramentas(observability in deep)#45
Mario Valente

46
Testando conectividade(observability in deep)#46
Mario Valente

47
Instrumentando tracing na nossa app em go(observability in deep)#47
Mario Valente

48
instalando opentelemetry collector(observability in deep)#48
Mario Valente

49
Explorando grafana tempo(observability in deep) #49
Mario Valente

50
Explorando TraceQL (observability in deep)#50
Mario Valente

51
Finalizando modulo de tracing (observability in deep) #51
Mario Valente

52
Implementando a observabilidade end to end (observability in deep )
Mario Valente
53
Entendendo a arquitetura do projeto(observability in deep)
Mario Valente

54
Aprofundando na nossa api de teste em go(observability in deep)
Mario Valente

55
Criando nossos SLOs e SLIs (Observability in deep)
Mario Valente

56
Explicando como está o provisionamento das nossas ferramentas
Mario Valente

57
Executando o IaC das nossas ferramentas AULA 57
Mario Valente

58
Ajustes e testando conectividade das ferramentas instaladas AULA 58
Mario Valente

59
Instrumentando observabilidade na nossa app AULA 59
Mario Valente

60
Como vai funcionar nosso deploy AULA 60
Mario Valente

61
Criando nosso banco de dados AULA 61
Mario Valente

62
Validando nosso banco de dados AULA 62
Mario Valente

63
Criando nossos indicativos AULA 63
Mario Valente

64
Criando nossos indicativos parte 2 AULA 64
Mario Valente

65
Criando nossos indicativos parte 3 AULA 65
Mario Valente

66
Revisando oque fizemos ate aqui AULA 66
Mario Valente

67
Adicionando tracing e logs AULA 67
Mario Valente

68
Próximo passos AULA 68
Mario Valente

69
Configurando slack webhoock AULA 69
Mario Valente

70
Criando nosso primeiro alerta parte 1 AULA 70
Mario Valente

71
Criando nosso primeiro alerta parte 2 AULA 71
Mario Valente

72
Integrando loki tempo e prometheus com o explorer AULA 72
Mario Valente

73
Considerações finais (encerramento)
Mario Valente

Transcrição

Procurar no vídeo
0:01
Tá ali, galerinha do olho que tudo vê
0:04
essa aula. Hoje a gente vai entender o
0:07
os fundamentos, os pilares da
0:10
metodologia, o olho que tudo vê, essa
0:12
metodologia que vai te ensinar a aplicar
0:14
observabilidade em todos os contextos aí
0:17
da sua empresa, tá? O que a gente vai
0:20
entender agora são esses fundamentos
0:22
primordiais, que é o SLA, o SLI e o SLO.
0:26
essas três siglas aí, eh, muitas vezes
0:29
passa despercebido pelas pessoas, as
0:31
pessoas não conhecem isso e é como se
0:34
fosse primordial tu entender e isso é
0:37
super necessário pra gente continuar
0:39
aqui com o curso, tá? Então, vamos lá.
0:42
Primeira coisa que a gente tem que saber
0:43
é o SLA, é o acordo de nível de serviço,
0:48
tá gente? Ah, o SLA é um acordo formal
0:52
entre o provedor de serviço e o cliente,
0:54
tá? defini, tipo, as expectativas de
0:58
desempenho do serviço mesmo, tá? Tipo,
1:01
as penalidades, caso essas expectativas
1:03
não saiam de acordo, né? Por exemplo, eu
1:06
dei um exemplo aqui de uma pizzaria. O
1:10
SLA seria uma política de pizzaria,
1:12
tipo, a pizzaria tem que entregar em até
1:14
30 minutos ou senão você vai a pessoa
1:18
que pedir vai ganhar um desconto ou até
1:20
vai levar a pizza de graça. Então é uma
1:22
política, é um acordo de nível de
1:25
serviço. O SL está dizendo aqui, ó, eu
1:27
te garanto que eu vou entregar essa
1:29
pizza em até 30 minutos, senão eu vou
1:33
ter uma punição de alguma forma. É
1:35
basicamente isso. Voltando para o
1:38
contexto de tecnologia, o SLA pode
1:40
estipular que um serviço ele tem que tá
1:42
disponível 99,9
1:45
ou 99,8.
1:47
A gente nunca coloca 100%, que isso é
1:49
impossível, né? Mas eh 99%
1:54
do tempo ou 95% do tempo esteja
1:57
disponível. Aí já pensando no erro
1:59
budget aí na frente, tá bom? Esse é o
2:02
acordo de nível de serviço e ele tá
2:05
muito ligado com um próximo carinha aqui
2:07
que é o eh o SLO, que é o objetivo de
2:12
nível de serviço, tá? Esse aqui é o
2:14
acordo. Então tenho que te entregar a
2:16
pizza em até 30 minutos. Mas tá, como é
2:19
que eu chego nisso daí, né? Então o S, o
2:22
SLO seria um objetivo. Objetivo de nível
2:25
serviço é uma meta específica que o
2:28
serviço precisa atingir ali para manter
2:31
aquele nível acordado lá no SLA, lembra?
2:33
Então ele é geralmente uma parte do SLA,
2:36
então só que ele é uma métrica utilizada
2:39
ali para medir o serviço. Então ele tem
2:42
que tá dentro dos parâmetros esperados.
2:44
Aí, então, uma um exemplo aqui, uma
2:47
analogia lá da pizzaria, o Sia da
2:51
pizzaria. tem um pra gente conseguir
2:54
fazer as entregas em até 30 minutos ali,
2:58
todas as entregas, né, a gente tem que ã
3:02
ter uma porcentagem muito alta de
3:04
entregas que vão durar em até 20
3:06
minutos, 25 minutos, porque se a gente a
3:09
gente sabe que se elas demorarem mais a
3:11
gente vai desacordar ali nosso SLA.
3:14
Então, voltando pro contexto de
3:15
tecnologia, então se o SLA diz que a
3:18
gente tem que ter um uptime de 95, 99,8%
3:23
ali, o SLO vai ser o objetivo específico
3:26
de que, tipo, 99% dos pedidos tem que
3:30
ser concluídos com sucesso. Então, esse
3:33
seria mais ou menos os SLO, ele é o
3:36
objetivo do nível de serviço, né? E aí a
3:39
gente vai para um cara que vai medir
3:41
esse SLO, que é o SLI, que é um
3:44
indicador de nível de serviço. Ele tá
3:47
muito ligado à métrica, tá? Então é a
3:50
métrica que efetivamente mede a
3:53
performance do SLI, do SLO, desculpa. É
3:57
um número real que vai ser coletado ali
3:59
no monitoramento que informa se o
4:01
serviço está atingindo o seu SLO. Por
4:04
exemplo, eh, vou dar um exemplo aqui da
4:06
pizzaria, por exemplo. Então, o SL seria
4:09
o tempo médio que de entrega real medido
4:13
pela pizzaria. Então, ã, pode ser que
4:16
eles arrastreem o tempo de entrega ali,
4:18
tá demorando entre minutos, 25 minutos.
4:22
Esse é o a média de entrega, né? Ou a
4:25
gente pode ter uma uma métrica de
4:28
máximo, de mínimo. Isso aí, como eles se
4:30
relacionam? O SLI é a métrica medida. O
4:34
SLO ele é o objetivo que você define com
4:37
base no SLI. E o SLA é o acordo formal
4:42
que define as expectativas e, vamos
4:45
dizer, as consequências com base no SLO.
4:50
Então, basicamente é esse o o
4:54
cronograma. Esse é a parte mais
4:58
importante da observabilidade. A gente
5:00
tem que definir muito bem o que são
5:02
essas coisas, por que a gente precisa
5:04
delas, pra gente dar continuidade e
5:07
instrumentar nossas a nossas métricas, o
5:11
nosso monitoramento, a nossa
5:13
observabilidade, nossas alertas e etc.
5:16
Com base nesses três caras, né? A gente
5:18
precisa saber o que que a o nossa
5:21
aplicação garante entregar, qual é o
5:24
objetivo que a gente precisa entre H, o
5:27
SLA, que é o o que a gente garante, o
5:29
SLO, o objetivo pra gente garantir
5:32
aquilo que a gente tá prometendo. E o
5:34
SLI é a métrica de fato, o que que a
5:37
gente tá fazendo de fato ali o indicador
5:40
de nível de serviço que a gente consegue
5:42
medir o SLO, por exemplo, né? Então, é
5:46
esses caras que a gente precisa
5:48
entender. Esses caras precisam estar bem
5:52
trabalhados, bem produzidos e bem
5:55
pensados também de acordo com o seu
5:57
negócio. Vamos encerrando mais essa aula
5:59
aí de SLA, SLI, SLO. A gente vai tá
6:02
trabalhando com eles mais na frente,
6:04
vamos tá trabalhando, formulando eles,
6:07
criando eles. Então, a gente vai ter
6:08
mais exemplos ali na frente, mas essa é
6:10
a base, essa é a eh a introdução deles.
6:14
Então é isso aí, pessoal. Até a próxima.
6:17
Yeah.

0:01
Vamos lá, pessoal, falar sobre os três
0:04
tipos de outputs que podem ocorrer e
0:06
podem acontecer ah no na observabilidade
0:11
no monitoramento. Esses três outputs é
0:14
extremamente necessário a gente
0:15
entender, porque isso aí vai impactar
0:17
muito na sua produtividade, né? Como
0:20
todos sabem, a gente só tem dois olhos,
0:23
então a gente precisa desviar nossa
0:24
atenção pro que realmente importa. E é
0:27
muito necessário a gente entender, saber
0:29
quais são esses tipos de categoria, tipo
0:31
como a gente pode defini-los
0:34
bem organizados ali no seu workload
0:36
diário. Assim, como todos notaram aí
0:38
pelo título do vídeo, existem três tipos
0:41
de outputs de monitoramento válido. São
0:43
os alertas, os tickets e os logs. A
0:47
gente vai ver com mais profundidade nos
0:49
nos módulos seguintes sobre os tickets e
0:53
os logs, tá? a gente vai fazer um
0:55
aprofundamento em cada um deles, eh,
0:58
nessa aula, começando
1:01
com os alertas, tá? Ã, os alertas, o
1:04
conceito de alerta é muito distorcido
1:07
por aí, tá, gente? Ã, eu vejo muito
1:09
isso, ã, que é o seguinte, por aí muitas
1:13
pessoas usam de maneira errada aí, até
1:15
mesmo nem utiliza, né? Tem muita empresa
1:17
que nem utiliza alerta ou se utiliza são
1:19
alertas default. Já vem. Pronto. Pra
1:22
gente entender o que que ele é e como
1:24
ele pode ser utilizado ao nosso favor, a
1:27
gente vamos vamos ter que fazer uma
1:29
analoginha de maneira da maneira mais
1:31
errada possível utilizar o alerta, tá?
1:34
Então eu vou contar uma história para
1:37
vocês, uma história interessante que é o
1:40
seguinte, vamos lá. Era uma vez um
1:44
pastor, ele levava seu rebanha de
1:46
ovelhas para para um lugar, para uma
1:48
serra lá, para pastorar lá. Ele tava
1:51
sozinho durante todo o dia, tava, poxa,
1:54
eu tô aborrecido então ele pensou de uma
1:56
maneira de ter uma companhia com ele e
2:00
se divertir um pouco, ele voltou lá na
2:02
aldeia e gritou: "Gente, tem um lobo.
2:05
Olha um lobo aqui". Aí os camponeses
2:08
chegaram lá para ajudá-lo e quando
2:12
chegaram não tinha nada, não gostaram
2:14
daquilo. Falou: "Pô, ah, ficaram ali
2:18
alguns com o cara, então a ideia dele
2:20
deu certo ali do jovem pastor."
2:23
Então, outro dia ele fez a mesma coisa,
2:25
então porque ele ficou contente e ele
2:28
começou a repetir várias vezes a grande
2:30
façanha dele de ficar alertando as
2:33
pessoas, alertando as pessoas por nenhum
2:36
motivo, tá? Gritando ainda mais alto do
2:39
que costumava fazer. Então, algum dia
2:42
depois, um lobo, realmente um lobo, saiu
2:45
da floresta e atacou o rebanho. Então, o
2:48
jovem pastor pediu ajuda e aí ele
2:51
gritou, mas gritou de um jeito absurdo.
2:54
Ele, ele queria ajuda, ó o lobo, ó o
2:56
lobo. E aí a galera já, pô, já enganado
3:00
várias vezes, falaram: "Pô, é mais uma
3:03
brincadeira desse cara aí, pô, tá tá
3:05
sacaneando". Então o lobo encheu a pança
3:10
e o garoto ficou aí ã tido como
3:14
mentiroso. E aí uma frase muito
3:17
importante dessa dessa história, tá
3:19
gente? Eu acho que muita gente já ouviu
3:22
falar de uma história meio que parecida.
3:24
E a frase é super importante, tá? uma
3:26
frase, uma frase muito importante dessa
3:29
que é a moral da história. Na boca do
3:32
mentiroso, o certo é duvidoso. Então a
3:35
gente a gente não quer, né? A gente não
3:37
quer um mentiroso avisando a gente que
3:39
algo tá errado, né? Seguindo essa linha,
3:42
os alertas eles significam que algum
3:44
humano precisa tomar alguma ação
3:46
imediatamente.
3:48
Então o alerta vem muito nessa nessa
3:51
pegada, tá gente? Ele precisa ser algo
3:54
que a gente vai agir. Então, o alerta
3:57
aqui, ó, tá muito ligado à ação
3:59
imediata.
4:02
Ação imediata.
4:06
Ação imediata. Então, se eu tenho um
4:08
alerta, se eu tô recebendo um alerta, eu
4:10
preciso agir. Esse alerta é o lobo
4:13
chegando ali pr para pegar o rebanho ali
4:16
das ovelhas. Então, preciso tomar alguma
4:18
decisão aquele momento, senão o lobo vai
4:22
fazer. No nosso contexto de tecnologia,
4:25
é um alerta que olha, ã, mais um, se a
4:29
gente não agir nesse momento, estamos
4:32
atingindo 90 100% de utilização de CPU.
4:34
Se a gente não escalar nosso workload
4:37
aqui de de máquinas, de pods aqui, ã,
4:41
vou ter um problema, vai cair minha
4:43
aplicação, então eu preciso agir, eu
4:44
preciso aumentar manualmente ou ativar
4:47
um autoscape da vida, sabe? Então, a ah
4:52
eu entrei nessa analogia, nessa
4:54
historinha para para vocês entenderem. O
4:58
alerta ele tá muito ligado à ação
5:00
imediata. é uma ação imediata
5:03
para responder alguma coisa. Então, a
5:06
gente nunca pode ferir esse senso. Se
5:08
não precisamos tomar uma ação agora
5:11
imediata, então ele não é um alerta.
5:13
Então, o moral da história aqui é não
5:16
tem alertas de estimação, pois um dia os
5:20
lobos vão vi
5:23
acreditar. Então aquele alerta que você
5:25
tem de um dia ele vai disparar
5:29
e esse disparo pode acabar você não
5:31
ligando e vai acontecer um problema, tá?
5:35
Os tickets, tá gente? É já é um pouco
5:39
diferente.
5:41
Os tickets significa que a gente precisa
5:44
tomar uma ação, só que não
5:45
imediatamente, tá? Então vou colocar
5:48
aqui, tomaram ação,
5:53
mas não imediatamente,
5:57
porém,
6:00
porém
6:02
não imediatamente.
6:06
Porém, não imediatamente, tá gente?
6:08
Então, a gente precisa tomar uma ação,
6:11
mas a gente não precisa fazer aquilo
6:12
agora. Nesse nesse tipo de auto aqui da
6:16
da do monitoramento, ele é caracterizado
6:19
da seguinte forma. O sistema sozinho,
6:21
ele não vai conseguir se resolver a
6:24
situação, mas a solução, a resolução
6:27
desse problema pode ser tomada em alguns
6:30
dias e isso não vai trazer uma
6:33
consequência trágica. alguns dias,
6:36
algumas horas. Então esse é um ticket,
6:40
né? Então quando ele abre um ticket, a
6:43
observabilidade ali, teu monitoramento
6:45
tá mais para esse sentido. Abrir um
6:47
ticket para você tomar uma ação. Você
6:48
precisa fazer alguma coisa, tá?
6:51
E aí os logins logins
6:56
ninguém precisa consultar essas
6:58
informações,
6:59
mas elas são registradas, tá? Eu vou
7:02
botar aqui
7:04
para fins forenses
7:07
ou trouble shooting, né? famoso
7:11
troubleunt.
7:13
Então a expectativa é que ninguém lê os
7:15
logs toda hora, toda hora que fori
7:18
disparado, a gente não fique olhando
7:19
esse log o tempo todo, mas a menos que
7:22
algo o solicite fazê-lo. Então vamos ter
7:27
um, a gente vai ter um módulo especial
7:29
para logs, que aí eu vou me aprofundar
7:31
bastante na parte logs, que é um dos
7:34
pilares da observabilidade. Ele é super
7:37
importante. os logs estão ali ah como um
7:40
pilar fundamental na observabilidade.
7:42
Então a gente vai ter um módulo especial
7:44
para ele. Dentro desse módulo, eu vou
7:46
mostrar a importância de termos esses
7:48
tipos de registros. Então vamos vamos
7:52
recapitular aqui. Resumindo, alertas,
7:54
ação imediata. Lembra do lobo? Lembra da
7:57
história da ovelha? A gente não quer
7:59
alerta de estimação, tickets, tomar uma
8:02
ação. A gente precisa tomar uma ação
8:04
igual o alerta, mas a gente não precisa
8:07
fazer imediatamente. A gente não precisa
8:08
tomar uma ação agora. Pode ser daqui um
8:11
dia, dois dias, daqui umas horas, pode
8:14
ser feito. Eh, nesse sentido, o log a
8:18
gente sempre vai fazer para fins
8:20
forenses, é um troubo shooting. Esse é
8:22
um tipo de output que ele vai ajudar a
8:25
gente de muitas maneiras, mas ã em
8:29
relação à ação, o que que a gente
8:31
precisa fazer de acordo com esses
8:33
autoeputs? É essa ideia aqui que eu tô
8:35
passando para vocês. Se a gente fizer
8:37
dessa forma aqui, você vai otimizar seu
8:40
tempo, você vai guardar a sua mente para
8:42
o que realmente importa e focar o seu
8:44
olho para aquilo que você precisa fazer.
8:48
O olho que tudo vê não precisa olhar
8:49
para tudo, ele só precisa olhar para o
8:51
que realmente importa. Aí ele vê tudo.
8:56
Então até a próxima aula. Eu espero lá
8:59
vocês. A gente vai falar um pouco mais
9:01
sobre a coisas super importantes, que é
9:05
a o que a experiência do usuário tem a
9:08
ver com a observabilidade. Então é muito
9:10
importante a gente saber disso também,
9:12
que afinal das final das contas é para
9:15
isso que a gente tem todas essas metas,
9:17
todo esse monitoramento é o usuário que
9:20
a gente quer entregar um bom serviço
9:23
para ele, né? Então vamos lá, vamos pro
9:25
próximo vídeo.

0:02
Ali, pessoal, mais uma aula do olho que
0:04
tudo vê. Nessa aula a gente vai entrar
0:07
um pouco no no o que que a experiência
0:11
do usuário tem a ver com a
0:12
observabilidade. O meu objetivo aqui é
0:14
que vocês saiam sempre com isso em
0:16
mente. Essa aula só tem um um único
0:19
objetivo, mostrar vocês que o que é mais
0:23
importante
0:24
para ter o sucesso ali no seu negócio,
0:27
na sua aplicação, seu app.
0:30
que é a experiência do usuário. É isso
0:31
que vai dar valor seu negócio. É isso
0:34
que te torna competitivo.
0:36
É por esse motivo que a observabilidade
0:40
ela existe, tá? É entregar valor, é
0:43
entregar disponibilidade, resiliência.
0:47
É para vou vou tentar ilustrar isso, mas
0:52
vamos pensar na seguinte situação, tá?
0:56
Imagina, imagina que você vai comprar
0:58
numa sorveteria, um sorvete,
1:02
uma sorveteria específica, tá? E quando
1:04
você entra na sorveteria, ninguém te
1:06
nota, ninguém olha para ti, ninguém. Aí
1:10
tu tem que chamar a atenção de alguém.
1:12
Aí tu chama alguém. Quando quando
1:14
finalmente tu consegue chamar alguém,
1:17
vem uma pessoa com a expressão assim
1:19
nada amigável, ela não quer falar
1:21
contigo, aí depois ela vem te atender.
1:25
Beleza? Depois disso você começa, começa
1:28
a duvidar daquele lugar assim. Mas como
1:32
tu enfrentou uma fila gigantesca para
1:35
entrar naquela sorveteria e demorou para
1:37
ser atendido, então, pô, vou dar um voto
1:40
de confiança, vou comprar o sorvete
1:42
assim mesmo, não quero ir para outro
1:43
lugar, vamos embora.
1:45
Depois que tu faz o pedido,
1:48
você vai notar alguma coisa estranha,
1:50
uma demora excessiva. Tá demorando muito
1:53
o sorvete ali para preparar o sorvete,
1:56
que seria simples. Tu pedi uma
1:58
casquinha, cara, e aí tu tu começa a
2:01
ficar ansioso porque tu tu não tem um
2:03
tempo todo o tempo do mundo por causa de
2:05
pedir um sorvete, né? Então, após alguns
2:08
minutos ali, uma hora, você pergunta aí
2:12
a funcionária aí, poxa, que que te
2:16
tratou de forma rude, falou com você de
2:18
forma desagradável
2:20
e aí se seu pedido tá sendo feito, né,
2:23
tá sendo preparado e ela volta e fala
2:26
com tom arrogante para ti ali que tá
2:29
feito, tá, tá fazendo bom, como você é
2:32
um cara do bem, você é um bom cidadão,
2:35
você espera Você espera mais um pouco,
2:37
mas quando chega o teu sorvete, quando é
2:40
o momento mais esperado, vai começ vai
2:42
acontecer. Você vai pegar o seu sorvete,
2:45
a máquina de sorvete quebra
2:49
inesperadamente e não tem nenhuma outra
2:51
para repor aquela máquina. Já era,
2:53
maluco. Então, o que te resta agora?
2:57
Esperar consertar a máquina
3:01
ou você vai embora com a sensação de
3:04
raiva, né? decepção. Já aconteceram isso
3:07
com vocês? Chegaram num lugar vocês
3:10
serem mal atendidos?
3:13
Não, não acontecer ali, se pegar até um
3:15
pedido errado, chegar em você,
3:18
aposto que dificilmente tu voltaria pro
3:21
seu lugar, né? Então é isso que eu falei
3:23
de competitividade,
3:25
de de agregar valor ao seu negócio.
3:28
Provavelmente essa sorveteria vai
3:29
sofrer, vai perder cliente, vai ter um
3:31
problema. Isso se aplica a grandes
3:34
aplicações, a apps. Você não tá
3:36
entregando uma qualidade boa pro teu
3:38
usuário, se tu não tá entregando
3:40
performance, tu não tá entregando,
3:42
aquele usuário tá tendo uma experiência
3:44
ruim. Então, se ele tá tendo uma
3:46
experiência ruim, como é que ele vai
3:48
voltar para teu pro teu app, pro teu
3:51
aplicação? É dessa forma que a gente
3:53
perde cliente
3:55
e e que nosso o nosso negócio começa a
3:58
perder valor, tá? Então, a
3:59
observabilidade ela ela vem ali para
4:02
mostrar pra gente que a gente tá errado,
4:05
onde que a gente tá errado, em qual
4:07
etapa a gente tá errando e como é que a
4:10
gente vai melhorar.
4:12
Como que a gente vai melhorar? Então, a
4:15
observabilidade é uma prática essencial
4:17
ali para qualquer negócio. É isso que eu
4:19
acho que que a gente tem que botar na
4:21
cabeça. A gente tem que entregar a
4:25
melhor experiência pro usuário final.
4:27
Então ela vai envolver o quê? Coleta,
4:30
análise, interpretação de várias fontes,
4:34
entender melhor como o sistema tá
4:37
funcionando,
4:38
como ele tá falhando, o por que ele tá
4:41
falhando. Quando a gente tem uma boa
4:44
observabilidade, assim no geral, tá
4:46
gente? A gente consegue identificar
4:48
problemas antes que eles vão acontecer,
4:51
antes de acontecer. Então, como a gente
4:53
falou nas aulas anteriores com aquelas
4:55
sketes que a gente fez, ã, a gente tem
4:59
ações proativas para corrigir aquelas
5:02
falhas antes de acontecer. Por exemplo,
5:05
nesse caso que eu dei da sorveteria,
5:07
nessa historinha que eu falei, se a
5:09
gente tivesse um sistema de
5:11
observabilidade em vigor, a o sistema de
5:13
observabilidade, tá gente? tá só fazendo
5:15
uma analogia aqui.
5:18
Os os proprietários, os donos daquela
5:20
sorveteria iam iam ter identificado
5:22
rapidamente aqui a a insatisfação
5:24
daquele cliente ali com o atendimento, a
5:27
demora,
5:29
a falha da máquina do sorvete. Então,
5:31
com essas informações, eles poderiam ter
5:34
treinado melhor os funcionários,
5:36
otimizados os processos de atendimento e
5:40
feito manutenção preventiva da máquina,
5:42
porque ela já estaria dando ah sinais e
5:46
que ela ia quebrar em algum momento. Os
5:48
proprietários iam garantir uma
5:50
experiência mais agradável pros
5:51
clientes. A observabilidade ela não ela
5:53
não tá limitada apenas identificar
5:55
problema também. Ela pode fornecer os
5:59
ensaies
6:01
valiosos assim sobre o comportamento dos
6:03
clientes. Então, dá para personalizar a
6:06
experiência, dá para criar estratégia
6:09
mais eficaz pros clientes ali para para
6:13
você ser competitivo no mercado. É isso
6:16
que hoje a gente precisa. O mercado é
6:18
muito forte, tem muita competição.
6:21
Então, quanto mais você entrega de
6:23
experiência pro usuário, mais
6:24
competitivo você tá. Então, pode ser seu
6:27
diferencial que que que te coloca teu
6:30
negócio na frente dos concorrentes. Às
6:32
vezes o teu concorrente tem um produto
6:34
bom, mas ele tem um peça péssimo uptime,
6:38
ele tem uma péssima entrega de serviço e
6:40
às vezes teu produto tá ali um pouco
6:43
abaixo da média assim de features, mas
6:45
teu é rápido, ele tá ali entregando e
6:48
tudo que tudo funcionando, 99% do tempo
6:52
tá funcionando. Então você vai conseguir
6:54
aquele cliente para ti, ele tu vai
6:56
trazer ele para dentro. Então é
6:58
importante a gente investir em
6:59
observabilidade, investir na satisfação
7:01
do cliente, no sucesso do teu negócio. É
7:04
o sucesso, é entender que cada
7:07
interação, cada coisa é para melhorar a
7:11
experiência do usuário. A gente tá
7:12
construindo um relacionamento de
7:15
confiança, de lealdade.
7:18
É, é honestidade que a gente tá passando
7:21
e uma lealdade com com o nosso usuário.
7:24
fala assim, ó, te garanto que eu vou
7:26
entregar esse serviço de qualidade e eu
7:28
tô trabalhando dia e noite para
7:30
identificar se existe algum problema,
7:33
tá? As coisas mais importante, né, da
7:36
observaridade é que você entenda isso.
7:38
Qual é o objetivo nosso aqui? Qual é o
7:41
objetivo do olho que tudo vê, da
7:42
metodologia? O que eu quero entregar
7:44
para vocês é essa visão. O usuário tem
7:49
tudo a ver com observabilidade. A
7:51
experiência dele tem tudo a ver com
7:53
observabilidade, tá?
7:54
Então é isso, pessoal. Até a próxima
7:56
aula. A gente vai falar um pouquinho
7:58
mais sobre eh SLI, SLO, SLA. A gente vai
8:03
cada aula, vamos se aprofundar um
8:05
pouquinho mais neles e como isso pode
8:07
ajudar a gente e e vamos vamos criar
8:11
exemplos mesmo na prática.
0:01
Dale, pessoal. Vamos para mais um vídeo
0:03
aqui pra gente entender melhor os
0:05
conceitos daqui do da metodologia do
0:07
olho do que tudo vê. Primeiro a gente
0:08
vai falar alguns conceitos que já são
0:10
bem conhecidos aí na área de
0:12
observabilidade. Um deles é o os
0:14
indicadores, eh, que são
0:16
importantíssimos aí pra gente conseguir
0:19
fazer alguma coisa, né? Pra gente
0:20
conseguir fazer as nossas métricas, né?
0:23
E a gente vai começar com um que é muito
0:26
importante, né? que é o level indicator,
0:30
que é um indicador de serviço. E esse
0:34
cara é o SLI, tá? Então, SLI ele vai
0:38
servir ali pra gente como indicador de
0:40
nível de serviço que vão estar embutidas
0:43
métricas dentro dele. Vamos lá ver como
0:46
que isso funciona na prática e como é
0:48
que a gente vai montar esse cara na
0:50
prática aqui, né? Beleza? Então,
0:52
pessoal, seguinte, o SLI ele vai tá como
0:56
se fosse, primeira coisa que a gente
0:58
precisa fazer com ele é a gente que
1:00
resgatar informações. Então, informações
1:03
importantes que a gente pode pegar é
1:05
tempo de resposta, né, que o uso são
1:08
informações que vão estar muito
1:09
atreladas à experiência do usuário, né?
1:12
A gente falou disso aqui no curso e a
1:16
experiência do usuário é muito
1:18
importante. Então a gente precisa fazer
1:19
essa pesquisa, precisa perguntar, falar
1:22
com as pessoas para saber se a o tempo
1:26
de resposta eh é bom, é suficiente. E aí
1:30
a gente consegue metrificar, porque isso
1:32
é importante pro usuário. Velocidade
1:34
navegação vai tá muito atrelada a ao
1:37
tempo de resposta, disponibilidade 100%.
1:41
A gente pode ver outros tipos de
1:43
métricas também que pode estar
1:45
atreladas, podem e devem estar atreladas
1:48
é o SLI, como outras coisas específicas
1:51
do teu negócio. Eu tô sendo bem genérico
1:53
aqui para ser uma coisa mais
1:56
exemplificável para vocês, tá? Então o
1:58
SLI,
2:00
ah, ele vai est lá pegando essas
2:03
informações do do usuário final e
2:06
transformando isso em indicadores, né?
2:08
Então, para eu conseguir saber o tempo
2:09
de resposta do usuário, eu preciso ter
2:11
uma métrica de latência. Então, uma
2:13
latência, o quanto que a gente consegue
2:16
entregar, qual o tempo médio a gente
2:17
consegue entregar pro nosso usuário e
2:20
quando isso pode sair um pouquinho do
2:22
que é esperado ou não, né? o up time,
2:25
quanto nossas aplicações ficam fora do A
2:28
determinado tempo, a disponibilidade
2:31
100%, isso vai est muito atralado up
2:34
time. Então aqui a gente consegue, né,
2:37
criar essas métricas
2:41
e fazer um indicador SLI. Então,
2:45
basicamente o SLI ele vai est nessa
2:48
linha de criar a métrica, né, como um
2:52
como um todo, vamos dizer assim. né?
2:54
Então, pra gente ir pro próximo nível,
2:56
que é o SLO, a gente vai tentar entender
3:00
essa parte do SLI pra gente conseguir
3:02
agregar eles dois. Eles dois trabalham
3:04
juntos. Um é o indicador, então ele vai
3:07
indicar pra gente a métrica que a gente
3:09
precisa monitorar, a métrica que a gente
3:12
precisa observar. E aí a gente vai
3:14
precisar do nosso objetivo de nível de
3:16
serviço, né, que é o SLO. E aí com ele a
3:21
gente vai validar se a gente tá saindo
3:23
do nosso objetivo.
0:01
E aí, pessoal? Vamos agora para o SLO,
0:05
que é o nosso objetivo de nível de
0:09
serviço. Então, a gente tem um
0:10
indicador, agora a gente vai pro
0:12
objetivo, tá? Então, o objetivo, ele tem
0:15
como principal objetivo pegar esses
0:19
indicadores e ver o que que é mais
0:21
importante para vocês. Então, vamos lá,
0:24
vamos botar isso na prática mesmo pra
0:26
gente tentar entender como que a gente
0:29
pode montar isso da melhor forma, tá
0:31
bom? Aqui a gente tem o SLI, a gente tem
0:33
as métricas baseado nas perguntas que a
0:36
gente fez do que é mais importante pro
0:38
nosso usuário, né? Então, o que que a
0:41
gente precisa fazer agora? a gente
0:42
precisa criar um SLO, que são os
0:45
objetivos, né?
0:48
São os objetivos nossos aqui pra gente
0:50
conseguir um serviço bom, de qualidade e
0:55
que tenha baixa latência e etc, que são
0:59
o que a gente pegou de métrica aqui, né?
1:02
Então aí primeiro a gente vai revisar os
1:04
nossos SL, nossos indicadores. Então
1:06
isso aqui, ó, tá muito, tá muito ligado
1:10
a métricas que a gente resgatou. Então,
1:14
de latência, de uptime. Aqui podia ser
1:17
uma taxa de resposta de sucesso de
1:21
login. Então, quantidade de erro que a
1:24
gente recebe no login, né? Isso aqui
1:27
podia ser uma métrica aqui também que a
1:29
gente podia colocar aqui, ó. taxa de
1:33
sucesso
1:35
no login.
1:39
Isso aqui é muito importante, beleza?
1:41
Que a gente viu que pro nosso negócio
1:43
faz sentido a gente eh observar isso
1:46
daqui. Ah, beleza. A gente definiu
1:49
nossos SLIs, então a gente precisa
1:52
depois da gente revisar, a gente vai
1:54
definir os nossos SL. Essa aqui é a
1:57
segunda etapa, tá? Então, o tempo de
1:59
resposta da página é um dos nossos
2:03
objetivos, tá aqui, que foi uma das
2:05
coisas que a gente pegou dos nossos
2:07
usuários. Então, nosso objetivo é que
2:10
95%
2:11
das requisições deve ter um tempo de
2:14
resposta inferior a 2 segundos. Ou seja,
2:17
um P95 da da do minha aplicação precisa
2:22
ser inferior a 2 segundos, né? Então, a
2:25
meta
2:26
é o objetivo é esse. Então, a meta
2:29
estendida, a gente pode colocar assim,
2:30
99% das requisições deve ter um tempo
2:35
inferior a 3 segundos. Isso daí é uma
2:37
meta que é baseada no objetivo, né? A
2:39
gente tá falando que o P99 tem que ser
2:41
inferior a 3 segundos, enquanto o P95
2:43
tem que ser inferior a 2.
2:46
Então, a gente já tem o nosso primeiro
2:47
objetivo aqui, ó.
2:49
Ó, nosso primeiro objetivo é esse. A
2:52
gente vai, não vamos focar na meta
2:54
estendida, mas a gente já tem o nosso
2:56
primeiro objetivo, que é esse daqui.
2:58
Então, objetivo 95% das requisições deve
3:02
ter um tempo de resposta inferior a 2
3:03
segundos. OK? Então, a gente também
3:06
falou sobre up time do sistema, então
3:09
que é o up time, o tempo de resposta,
3:12
disponibilidade 100%. Então a gente
3:15
vamos tentar chegar próximo disso. Então
3:17
o objetivo é que o serviço ele deve
3:19
estar disponível 99.9%
3:23
do tempo em um período de 30 dias.
3:26
Beleza? A gente já tem um o segundo
3:28
objetivo com base nas métricas que a
3:30
gente que a gente criou, né? Olhando pro
3:34
usuário. Então a meta estendida é o o
3:38
serviço tem que estar disponível 99.9
3:42
95 do tempo em um período de 30 dias,
3:46
tá? Isso aí o que a gente pode conseguir
3:48
fazer, né? E aí a gente vai fazer os
3:50
cálculos e ver quantos minutos a gente
3:53
consegue ficar disponível. E tem todo o
3:55
lance de erro budget e tal. Isso aí a
3:58
gente vai falar é em um outro vídeo, tá?
4:02
taxa de sucesso de login foi o que a
4:04
gente acabou de adicionar agora a pouco.
4:06
Então, o objetivo dele é que 90 95% das
4:11
tentativas de login devem ser
4:12
bem-sucedidas. Opa, pera lá. Aqui essa
4:16
métrica aqui a gente a gente não tem,
4:18
né? A gente tem métrica de latência, tem
4:21
métrica de uptime, mas essa daqui de
4:23
tentativa de login, hum, não temos. Como
4:27
é que a gente pode fazer aqui? a gente
4:29
tem que criar um indicador de nível de
4:31
serviço. Então, a gente precisa saber a
4:34
taxa de erros.
4:38
Taxa de erros barra
4:42
a taxa
4:44
de sucesso
4:47
no login.
4:52
Isso aqui é tráfego barra erro. Isso
4:57
aqui são duas eh são duas coisas que a
5:01
gente vai até abordar mais na frente,
5:02
que são parte do for golden sinals, né,
5:06
do SRE. Então a gente consegue ter duas
5:08
métricas em uma, que é a taxa de erro e
5:11
a taxa de de sucesso, que aí é tráfego,
5:14
né? O que a gente tá fazendo de
5:15
operações de sucesso. Então a gente
5:18
consegue, a meta estendida disso daqui é
5:20
98% das tentativas de login serem
5:23
bem-sucedidas. a gente tem tá muito
5:25
claro paraa gente os nossos objetivos, o
5:28
que a gente precisa para atender esses
5:31
objetivos e a gente tem as métricas.
5:33
Então o SLO é os objetivos de nível de
5:38
serviço e o SLI é os indicativos, é o o
5:42
que é real, o que é metrificável, o que
5:44
dá para se observar, né?
5:48
Então é isso, gente, para não fazer um
5:50
vídeo muito longo, vamos ficar aqui por
5:52
aqui nessa fase do SLO. E agora a gente
5:55
vai pro SLA. Pera lá, não, não fica
5:59
confuso que esse daí é um pouquinho
6:03
menos complexo. Os mais importantes é o
6:06
SL, o SLO, mas o SLA também é muito
6:09
importante. Vamos lá pro próximo vídeo
6:10
que eu vou explicar com mais detalhes.0:01
T pessoal, aqui mais um vídeo sobre os
0:04
termos muito importantes aí pra gente
0:07
concluir a nossa metodologia do olho que
0:09
tu vê. E aí estamos chegando aí no SLA,
0:12
que é o contrato formal com tudo isso
0:15
que a gente elaborou para criar os
0:18
nossos objetivos de nível de serviço e
0:21
os indicadores de nível de serviço.
0:24
Então esse contrato é basicamente quando
0:27
a gente ferir os nossos ah os nossos
0:32
objetivos, né, de nível de serviço, como
0:35
por exemplo, o que que vai acontecer se
0:37
a gente ah não ficar indisponível mais
0:42
tempo que o nosso objetivo acordado, né?
0:44
é um acordo formal entre a empresa e os
0:48
clientes, né, ou a aplicação e os
0:52
clientes.
0:53
Além disso, o SLA também pode ser um
0:55
contrato formal entre o que a gente
0:58
indica das nossas nossos indicadores de
1:01
SLI, com que a nossa ação deve
1:04
repercutir. Então, se a gente passar do
1:07
nosso real budget ou a gente ultrapassar
1:11
a nossa o nosso objetivo ali, a gente
1:15
extrapolar nosso limar, vamos dizer
1:17
assim, a gente vai ter que agir de
1:20
alguma forma ou pagar isso, né, de
1:24
alguma forma, né? são as consequências
1:27
de ultrapassar esses limares. Então o
1:30
SLA ele tá ali para fazer esse papel de
1:35
acordo de nível de serviço. Mas um
1:37
exemplo,
1:39
um exemplo assim bem resumido é tipo, a
1:43
gente garante 99% da disponibilidade do
1:47
mensal, caso contrário, a gente começa a
1:51
reembolsar os clientes que foram
1:52
afetados por essa indisponibilidade. Se
1:54
a gente quebrar esse contrato, a gente
1:56
vai ter que fazer alguma coisa em prol
1:58
disso, né? Então, o SLA é quando o SL
2:02
não foi atingido e aí a gente precisa
2:05
agir de alguma forma, entrar, fazer
2:07
alguma ação. É isso, pessoal. O próximo
2:10
vídeo eu vou falar um pouquinho sobre
2:12
erro budgets e como isso pode
2:14
influenciar nas métricas e o no
2:18
funcionamento de tomada de decisão
2:21
na no fluxo de operação, no fluxo de
2:24
desenvolvimento. Так.
0:04
vídeo vídeo sobre a metodologia olho que
0:07
tudo vê do curso Observability em Zip.
0:11
Bom, a gente vai falar de um de um
0:13
tópico muito importante que é o erro
0:16
budget. Eu vou explicar para vocês com
0:19
uma analogia de como que ele funciona e
0:23
por que ele é utilizado e porque que ele
0:25
faz total sentido quando a gente tá
0:27
falando de regra de negócio, de ah de
0:30
observabilidade no geral. Vamos lá, né,
0:33
para falar sobre o erro, o erro budget,
0:36
eh, e como é que isso aí vai lidar com
0:39
erros e incidentes. Vamos começar
0:41
falando sobre dinheiro. Sei que parece
0:43
um pouco estranho e tal falar sobre
0:46
dinheiro, mas vocês vão entender logo
0:47
logo. Ah, vamos conhecer aqui o João.
0:51
Vamos supor essa história. O João, um
0:53
jogador de poker que ele tá prestes a
0:55
aprender uma uma lição aí bem valiosa
0:59
sobre erro budget. Bom, ah, vamos supor
1:03
que ele tá num cassino. Ele é um jogador
1:05
de pôker muito bom, vamos dizer assim. E
1:08
ele tá sentado numa mesa de pôker,
1:10
cercado por uns amigos e tal. E aí, esse
1:15
é o João, ele ele adora jogar Pok e hoje
1:18
ele trouxe uns R$ 100 ali para jogar.
1:22
Mas é que ele talvez vai se dar mal aí
1:27
com esses R$ 100 e ele vai aprender uma
1:30
lição sobre erro budget. Bom, o Diller
1:33
começa a distribuir as cartas e eu e o
1:35
João sorrindo ali. Pô, hoje é meu dia de
1:37
sorte, pessoal. Vamos lá. Vou sair daqui
1:39
com uma fortuna. Vamos embora. Então ele
1:41
começa a jogar como qualquer outro
1:43
jogador de pouco, ele ganha algumas
1:45
mãos, perde outras, mas ele tem, ele tem
1:48
um plano na cabeça dele. Ele só pode
1:50
perder até R$ 10. Vamos lá, vamos pensar
1:54
aí. Esse é o seu erro budget.
1:59
Esse é o seu máximo de perda, a sua
2:02
máxima de perda.
2:05
Então o amigo vai falar com ele rindo
2:07
aí, João, você já perdeu cinco, melhor
2:10
você tomar cuidado. Então o João
2:12
confiante, ele vai falar assim: "Ó, pô,
2:14
relaxa aí, meu parceiro, ainda tenho
2:17
cinco no meu erro e budget, então eu
2:18
posso arriscar mais um pouco." Então aí
2:21
o João continua jogando, mas a sorte ali
2:24
não tá muito do lado do João. E aí?
2:27
Beleza, João. O amigo do João, você só
2:31
tem R$ 1 no seu erro budget. Talvez aí,
2:35
cara, talvez seja a hora de parar, né?
2:39
Daí o João pensativo e tal. E aí você
2:42
tem razão. Se eu perder mais R$ 1, eu
2:46
vou ter que parar de jogar e recuperar
2:48
meu dinheiro. Então o João decide jogar
2:52
mais uma mão, mas aí ele joga com mais
2:56
cautela. Ele sabe que se ele perder, ele
2:59
vai ter que reavaliar totalmente a
3:01
estratégia dele. Então, beleza. O
3:04
Dillaler coloca as cartas, dá uma boa
3:07
sorte pro João. O João é, vamos lá, é a
3:10
última tentativa. Então, o João joga com
3:12
cuidado. Pra surpresa dele, ele ganha a
3:15
mão. Ele recupera a parte do dinheiro
3:18
dele e decide parar que ainda tá no
3:21
jogo. Então, beleza. Foi por pouco, né,
3:24
Jo. Ainda bem que ele tinha o erro
3:27
budget para guiar ele. Então, o que que
3:30
que a gente tira dessa história? Tá,
3:32
gente? O João aprendeu a importância de
3:34
ter um erro budget. Ele entendeu que
3:37
saber lidar com os erros vai ajudar ele
3:40
tomar decisões com mais informação, mais
3:43
equilibrada, tanto no pôker quanto na
3:46
observabilidade. E a gente se apoia
3:48
muito disso. Então, brincadeiras à
3:50
parte, o erro budget é uma quantificação
3:55
do nível aceitável de falhas de erros de
3:59
um em um sistema no geral, né? Então ele
4:01
é derivado da ali, ó, do SLA e dos
4:05
objetivos de nível de serviço, que é o
4:06
SLO. Então, basicamente ele define
4:11
quanto erro ou tempo de inatividade é
4:14
aceitável ali dentro do do período
4:17
específico, tá? Então, como é que isso
4:21
funciona? A gente define o SLO, o SLA,
4:25
né? a gente faz o cálculo de do erro
4:29
budget. Se o SLO é de 99% de
4:33
disponibilidade, isso significa que o
4:35
serviço pode estar indisponível por 0.1%
4:40
do tempo. Em um mês de 30 dias, isso aí
4:43
vai equivaler a aproximadamente 43.2
4:48
minutos de inatividade permitido, tá?
4:52
Então, o que que o erro budget vai
4:55
aparecer ali? Então, o erro budget ele
4:57
vai monitorar todos os dias se o serviço
5:00
começar a falhar ou ficar indisponível e
5:03
o tempo de inatividade, ele vai ser
5:06
subtraído do erro budget. E aí a gente
5:09
vai ter que fazer uma tomada de decisão.
5:11
Se o erro budget
5:13
tá começando a esgotar, se esgotar
5:16
rapidamente, isso pode indicar que a
5:18
necessidade de priorizar ali a
5:20
estabilidade do sistema, né? Corrigir
5:23
bug em vez de em vez da gente lançar
5:26
mais funcionalidades. Então a gente tem
5:28
que entender isso pra gente ver para
5:32
onde os times têm que se colocar ali,
5:35
porque a gente tá extrapolando o nosso
5:36
erro budget. o equilíbrio entre a
5:40
inovação e a confiabilidade. Então, ele
5:42
vai trazer isso pra gente. O o erro
5:46
budget ele permite que as equipes de
5:49
desenvolvimento e operações encontre um
5:52
equilíbrio entre a implementação ali de
5:55
outras funcionalidades, manutenção,
5:58
confiabilidade do serviço e etc. Tá
6:01
gente? Bom, essa é a aula que eu vim
6:05
falar do erro budget. Por que ele é tão
6:07
importante, tá? Então, como é que a
6:09
gente vai fazer isso? É sempre se
6:12
apoiando no SLO ali nos nossos SL
6:16
também.
6:18
A parte prática desse curso, eu vou
6:20
mostrar para vocês na prática mesmo como
6:22
que a gente monta esses rubuts e até
6:25
formas da gente automatizar isso pra
6:27
gente saber se a gente tá passando ou
6:28
não esses erro budgets e e a gente
6:31
entrar em ação. A gente precisa entrar
6:32
em ação a partir do momento que a gente
6:34
descobre que alguma coisa tá fora ali do
6:37
esperado.
0:01
Dhe pessoal, começando o módulo três
0:04
aqui. Eu vou explicar para vocês o que
0:06
são os logs e o por que a gente precisa
0:09
deles. Essa, esse módulo vai ser um
0:12
módulo de muita prática. Então, se você
0:15
não tem o cub CTL instalado na sua
0:17
máquina ou se você não tem o miniube, ou
0:21
se você não tem a as environments
0:24
necessárias, eu vou est listando para
0:26
vocês tudo que vocês vão precisar para
0:29
tá conseguindo fazer o laboratório na
0:31
casa de vocês, na máquina local e etc.
0:34
Primeiramente, a gente vai explicar um
0:36
pouquinho como é que vai funcionar esse
0:37
laboratório. E aí, eh, a gente vai
0:40
partir paraa parte teórica ali
0:42
rapidinho, só para vocês entenderem
0:44
porque que a gente precisa dos logs e
0:46
logo em seguida a gente já faz a prática
0:49
para vocês, tá bom? Bom, primeira coisa
0:52
para vocês entenderem aqui, vamos botar
0:54
na outra tela aqui, é que a gente vai
0:57
fazer um laboratório que tem como
0:59
objetivo visualizar os logs. Então, a
1:01
gente vai ter uma aplicação, né, nesse
1:04
laboratório, uma aplicação
1:07
bem simples aqui.
1:12
Deixa eu botar aqui para ficar bem mais
1:15
visível.
1:17
Vamos dizer que isso aqui é uma uma app,
1:21
vai ser uma app, um deployment normal
1:23
aqui no Cuberns. E essa app, ela vai tá
1:26
instrumentada, tá? Eu vou mostrar para
1:28
vocês depois como é que tá a
1:30
instrumentação dela.
1:32
Ah, ela vai tá exportando logs
1:36
para o Promil.
1:39
Promtail. Promete é um agente que vai
1:43
est resgatando esses logs e jogando isso
1:46
para o lock
1:51
po, que é uma solução a open source aí e
1:56
na verdade não open source, mas uma
1:58
solução gratuita ali para você tá vendo
2:01
os logs, na verdade resgatando esses
2:03
logs e colocando em um data series, um
2:07
banco de data series, né? A gente coloca
2:10
isso e visualiza depois isso no grafana.
2:15
Grafana. Então, basicamente nosso nosso
2:18
laboratório vai ser isso aqui, tá?
2:22
Tá meio ruim o desenho aqui, mas
2:27
ã não é nessa ordem específica, né?
2:29
Porque eu prometei um agente que ele ele
2:32
vem resgatar esses logs do desse steder
2:36
e coloca ali e expota isso pro lock. E o
2:41
Grafana pega essas informações do lock
2:43
que é um data source dele, né? Bom, a
2:48
gente sabe que esses esses componentes
2:50
que a gente vai precisar, eu vou mostrar
2:52
para vocês como é que a gente vai
2:53
instalar eles também, mas vamos lá,
2:55
vamos pra parte teórica. Vou deixar isso
2:57
pro próximo vídeo, que é explicando o
3:00
motivo da gente usar log, por e o ruim é
3:04
quando você não tá usando log. Vamos lá.
3:06
M.0:01
Dale, pessoal. Mais uma aula sobre logs,
0:04
especificamente pra gente montar o nosso
0:06
olho que tudo vê do nossa metodologia.
0:10
Basicamente o log vai ser um carimbo de
0:12
tempo do que vai acontecer na sua
0:14
aplicação. São eventos que acontecem,
0:16
pode ser várias categorias de logs e aí
0:19
eu vou listar para vocês a estrutura de
0:21
um log e o motivo que a gente usa, né?
0:25
Vamos supor que a gente eh vamos colocar
0:28
uma analogia aqui, tá? Eh, vamos supor
0:30
que eh eu sou um piloto de avião e
0:34
pilotando aí nesses ares por aí, ã, eu
0:39
recebo informações da minha cabine que
0:42
temos um um possível problema
0:45
acontecendo ou no momento que a gente
0:47
sai do do aeroporto, eu preciso logar
0:52
essa informação para a central de
0:55
controle. Então isso é basicamente o que
0:58
a gente precisa nas nossas aplicações
0:59
também. Por que que ele precisa falar
1:01
isso? Olha, eu estou saindo aqui na
1:05
latitude tal e etc. Não sei muito bem
1:07
dos termos de aeronáutica, mas a pessoa
1:11
que está na central vai pegar essas
1:13
informações, vai bater com o radar dela
1:16
e vai registrar essa informação ali para
1:20
que não aconteça algum problema de
1:22
colisão e e ela controle eh melhor o
1:25
tráfego aéreo.
1:27
No nosso caso, a gente faz o seguinte,
1:30
pessoal, vamos dizer que isso aqui é,
1:33
vamos lá voltar pra aplicação de novo.
1:36
Vamos dizer que isso aqui é a aplicação
1:37
e ela ela faz o faz, como é que eu posso
1:42
explicar isso? Ela pode fazer
1:44
determinadas transações
1:47
e essas transações podem dar certo ou
1:49
não. Vamos dizer que é um um app aqui de
1:52
transações financeiras e ele faz o
1:56
pedido de ele faz uma ordens de pedido
2:03
e aí eu tenho outras rotas aqui para
2:07
esse mesmo serviço que registra isso no
2:09
banco.
2:12
Então vamos, eu não tô ligando muito
2:14
aqui pra pra arquitetura, tá gente? Mas
2:16
que isso aqui não funciona tão bem.
2:20
Ah, isso registra aqui no banco. Tá bom.
2:23
Deixa eu aumentar aqui a
2:28
Ah, beleza. Ã, OK. a gente tem essas
2:32
informações que e que essa app faz a as
2:35
notas de orders e também registra no
2:37
banco. Bom, eu preciso saber quantos
2:41
registros do banco está acontecendo e
2:43
basicamente eu preciso entender se cada
2:45
registro tá dando certo ou se ele tá
2:48
passando pelo fluxo que eu quero que ele
2:50
passe. Então, se algo acontecer nessas
2:54
nesses fluxos, eu preciso jogar uma
2:56
informação,
2:58
por exemplo, registrado no banco, é uma
3:01
info.
3:03
Então isso daqui já é uma informação, é
3:05
um log. Eu vou precisar do tempo que
3:07
isso aconteceu, quando que aconteceu e
3:10
sei lá, uma mensagem de que aconteceu
3:13
com sucesso, o ID do cliente e etc.
3:18
Outra informação que eu preciso é se deu
3:20
erro.
3:22
Se deu erro, eu vou logar isso também.
3:25
Então, se deu algum problema com o
3:27
banco, o banco tá fora do ar ou se a deu
3:31
algum problema na mensagem ali do
3:33
registro do banco, algum problema de
3:35
serialização. Então eu preciso saber
3:37
disso também.
3:40
Eu preciso saber também quando é um
3:43
teste. Às vezes o os desenvolvedores
3:46
estão estão testando alguma feature.
3:48
Então é um debug. Eu também preciso
3:52
saber quando é um problema crítico.
3:57
Critical.
3:59
O que que acontece quando for um
4:01
problema crítico? Quer dizer que ah,
4:05
a estrutura do meu sistema tá degradada,
4:07
ou seja, ele não consegue processar mais
4:09
nada e ele não consegue reagir, não
4:12
consegue voltar. É diferente do erro. Às
4:15
vezes pode ser um erro que é esperado ou
4:18
um erro que a gente tá entendendo o que
4:20
ele tá acontecendo, mas não tá
4:22
degradando o sistema, né? O fluxo tá
4:25
acontecendo, mas o erro tá acontecendo,
4:27
mas não tá degradando o sistema. O
4:29
critical geralmente a gente coloca
4:32
quando ou o banco não tá respondendo
4:34
mais, a gente vai precisar acionar um
4:36
circuit breaker ou tiver uma estratégia
4:39
de de fallback, mas ele é muito
4:42
importante para nos demonstrar que o
4:43
sistema tá falhando mesmo, ele não tem
4:46
como voltar. Então é por isso que o nome
4:48
é critical.
4:50
Bom, geralmente a gente tem mais eh
4:54
informações aí são é o título do log,
4:56
tá? Essa aqui é a estrutura mais ou
4:58
menos do log.
4:59
Mas o log tem vários campos, tá? Um
5:03
campo de um log, ele pode, para cada
5:05
informação dessa, ele pode ter vários
5:08
campos. Isso vai de acordo com as suas
5:10
necessidades, mas geralmente a gente
5:12
precisa de uma mensagem,
5:14
a mensagem do log.
5:18
Message do log. A gente, além disso, a
5:20
gente precisa não só de mensagem, a
5:23
gente precisa eh da URI que foi feito
5:27
essa essa transação, em qual máquina,
5:30
então qual node esse cara tava, qual
5:32
podras
5:36
informações que vão ser necessárias para
5:39
você, né? Por exemplo, o ID do desse
5:43
registro no banco,
5:45
o ID do registro. Então são fields, são
5:49
campos que você vai adicionar na
5:50
mensagem da do seu log que que vão fazer
5:54
total sentido para você debugar e agir
5:57
de alguma forma, né? Então esse é a
6:01
estrutura do log e por qual motivo ele é
6:04
importante. Eh, vamos dizer que você tá
6:06
tendo muitos eh erros no seu registra do
6:11
banco ali, na hora de você fazer um
6:13
registro no banco. Ah, você precisa agir
6:16
de alguma forma.
6:17
E às vezes você não sabe que isso não tá
6:19
acontecendo, certo? Então, se você não
6:22
sabe que isso tá acontecendo,
6:24
ã, coisas ruins podem acontecer, como
6:28
usuário, eh, ser impactado nesse
6:31
ambiente, né? Se você não tá logando
6:33
isso, então, por exemplo, nessa função
6:35
ali, nesse controlador de registro no
6:37
banco, eh se você não tiver logs, se
6:41
você não tiver eh retornando erros, por
6:44
exemplo, de certas situações, você vai
6:47
tá muito perdido, você não vai conseguir
6:49
achar o real problema com mais
6:51
facilidade. Então, por isso que a gente
6:53
precisa de logs. Ele é a base do nosso
6:57
olho que tudo vê. a base não, mas é o é
7:00
os braços do olho que tu do vê, é os
7:02
cílios dele, é a íris, vamos dizer
7:05
assim, né? Então vamos lá, gente, vamos
7:07
pro próximo vídeo. No próximo vídeo
7:09
vamos começar, é, vou listar para vocês
7:12
quais são as ferramentas que a gente vai
7:13
precisar e já vamos fazer a instalação
7:15
delas aqui na nossa máquina para vocês
7:18
entenderem como que a gente vai
7:21
provisionar esse ambiente. Č.0:01
Beleza, pessoal, mais uma aula
0:03
começando. Agora a gente vai colocar uma
0:05
situação de exemplo, né? A gente pegou
0:08
logs ali no no grafan, a gente conseguiu
0:11
pegar alguns logs de algumas aplicações
0:13
que são das próprias ferramentas que
0:15
estão rodando, mas vamos colocar de uma
0:17
aplicação real mesmo, né? Alguma
0:19
aplicação. Então vamos ver aqui. Eu vou
0:22
mostrar para vocês uma aplicação minha
0:24
aqui, pessoal. E aí vou estar
0:26
disponibilizando, claro, para vocês
0:28
testarem ela também. É, basicamente, vou
0:31
mostrar aqui, é uma aplicação que ela
0:34
roda eh comandos, né? uma comline também
0:37
pode ser um servidor e http rest ali
0:41
também que basicamente cria jobs no
0:44
cubernetes ou cria alguma coisa dentro
0:46
do contexto do Cubernes. Porém, pra
0:50
gente conseguir testar isso de maneira
0:51
mais eficiente, eu coloquei aqui no
0:55
nosso server,
0:58
que é a pasta server, aqui é onde eu eu
1:01
coloco o nosso servidor HTTP,
1:04
que para uma rota específica de logs,
1:08
que é um get, né? é um get de logs. E
1:11
essa função, esse logs, ele vai só pegar
1:14
o parâmetro aqui, qual é o type log, que
1:17
vai tá na vai tá na na requisição e vai
1:22
ã vai dar um switch case aqui. Bem
1:24
simples assim, gente. É só pra gente
1:27
simular mesmo o que a gente precisa
1:29
fazer numa situação real. Vamos dizer
1:32
que isso daqui seria o registro do
1:34
banco. Então você vai ter todo o
1:36
processo de registrar o banco aqui,
1:38
fazer o incest na tabela X e etc. E logo
1:43
em seguida, se você não conseguir fazer
1:45
isso, você vai logar algum erro, né?
1:47
Você vai logar uma
1:49
o ID ali do cliente que você tava
1:51
tentando e se tava mandando para algum
1:53
lugar e etc. que lugar que tava
1:55
mandando, se foi um uma exception de
1:58
conexão. E aí a gente consegue ver que
2:02
numa um teste de renda ou aqui a a gente
2:06
consegue, por exemplo, em qualquer
2:08
função dessa, por exemplo, get job, que
2:11
é uma função minha aqui da da API, eu
2:14
posso retornar um status OK ou um status
2:16
noting found,
2:18
né? Por exemplo, esse aqui é um get, ó,
2:20
um parâmetro get, onde eu vou pegar o
2:22
nome da job e o name space. Se eu não
2:25
encontrar nada, eu vou retornar um not
2:27
found. Então eu tenho midware aqui na
2:30
minha na minha no meu server que ele vai
2:34
pegar todas as requisições e vai
2:36
formatar com tempo, status, método e o
2:39
erro, né? E vai logar isso aqui no
2:42
stederout, tá? O que que é o stederout,
2:45
pessoal? SD out. SDER erro é uma saída
2:49
do eh sistema operacional, uma saída de
2:53
erro, uma saída de output pro qualquer
2:56
comando que é executado, qualquer
2:57
programa que é executado. Por exemplo,
3:00
tu dá um ls - la,
3:03
esse é o stederout do comando, tá? Se tu
3:07
dá um ls,
3:09
ls men, sei lá, qualquer coisa. Opa, deu
3:13
um erro. Isso daqui estender erro. tá?
3:16
Que eu consigo validar e eh o output do
3:20
comando. Então o output do comando
3:22
quando ele vai para algum lugar, ele vai
3:23
para pro ster outdin,
3:27
sei lá.
3:29
Inclusive eu posso dar um ls men la e
3:31
jogar o a saída do comando para algum
3:35
lugar, né?
3:38
Aqui seria o stdout.
3:40
Mas vamos lá. Eh, eu consigo pegar,
3:43
formato esses logs aqui no meu midware e
3:47
jogo tudo que for de requisição para
3:49
esse midware e ele vai formatar para
3:51
mim, tá? Então, tenho um formato de log
3:53
de Jzon também e eu consigo formatar
3:56
esses caras todos aí para mim. Tô usando
3:59
o framework do Eco, né, do Gol. Tô
4:03
usando a linguagem GO, não sei se deu
4:04
para perceber. E é isso, beleza? A gente
4:08
tem eu vou deixar disponível esse
4:10
repositório para vocês visualizarem. É o
4:13
Shinlong, é uma aplicação minha de
4:16
teste. Então, bom, esse repositório é é
4:21
o repositório do Shinlong. Vou
4:22
disponibilizar ele também para vocês,
4:24
mas para instalar ele no cluster, a
4:27
gente precisa criar um deployment para
4:29
ele, né?
4:30
Então vai tá aqui na pastinha K8S no
4:33
vales. É basicamente um deployment muito
4:36
simples, com uma réplica apontando pra
4:39
imagem que tem disponível também, tá
4:42
pública essa imagem, que é basicamente a
4:45
imagem que a gente tá rodando a nossa
4:46
aplicação. Por exemplo, se você der um
4:48
do run,
4:50
nessa imagem a gente vai est rodando o
4:53
servidor web, que é o Shinlong, no caso,
4:55
né? ele vai tá respondendo aquelas rotas
4:58
que eu acabei de mostrar para vocês.
5:00
Então, basicamente é isso. No caso, se
5:02
vocês rodarem esse comando docker 1 men
5:05
RM e o nome da imagem que o repositório,
5:08
que é o meu repositório Mar Valente e o
5:10
nome da imagem Shenlong latest, vocês
5:11
vão baixar a imagem primeiro e depois
5:14
vai rodar. No caso, vocês vão ter que
5:16
dar um docker docker push push na imagem
5:20
primeiro, né? Beleza? Sendo assim,
5:23
pessoal, a gente tem aqui a nossa a
5:26
nossa imagem declarada, o contêiner
5:28
porter que ele vai usar, que é a 3001,
5:30
que é o que eu tenho ah declarado lá no
5:33
repositório, se vocês quiserem ver
5:35
depois. Eu não vou me aprofundar muito
5:37
em Cubernetes porque não é o intuito do
5:40
curso, né? O intuito do curso é a gente
5:41
precisa olhar diretamente para os logs,
5:45
tá? E aqui é o service. O service é
5:48
basicamente pra gente bindar eh as
5:51
o roteamento para esse deployment aqui.
5:55
Beleza? Fechou? Para vocês deploiarem
5:59
esse cara é basicamente dar um cubtl
6:02
apply men- f a pasta car values.
6:09
Ele vai est instalando para vocês, tá
6:11
bom? que ele vai aplicar o Shinlong,
6:15
deployment do Shinlong e o CFS e o
6:17
Shinlong. Vocês podem estar visualizando
6:19
eles
6:21
aqui na na
6:24
CTL gets no caso, né? E você vai ver ele
6:27
aqui rodando, tá bom? Show de bola. Show
6:31
de bola. A gente já tem nosso carinha
6:34
rodando, né? Aqui. Bom, como que a gente
6:37
vai testar aquelas rotas que eu falei
6:40
para vocês?
6:42
que tava funcionando aqui, né, no nosso
6:45
server. A gente tem um server aqui,
6:47
handle server, que tá dando um get aqui
6:50
e tá chamando essa função. Ele pega o
6:53
parâmetro, valida o parâmetro com switch
6:55
case. Se for um erro, ele simula um
6:57
erro. Se for um info, ele simulou um
6:59
info. Se for um morning, ele simulou um
7:00
morning. Se for um debug, ele simula um
7:02
debug. Se for um critical e assim vai.
7:05
Bom, pra gente conseguir fazer isso
7:08
acontecer, a gente precisa ou a gente
7:11
precisa colocar o nosso serviço para
7:14
fora do cluster, né, e a gente conseguir
7:16
usar um postm da vida pra gente fazer
7:19
essa requisição, né, do da nossa máquina
7:22
ou para ser mais facilitado, para não
7:24
ter que criar objeto ingress e tal, pra
7:26
gente conseguir tirar essa requição para
7:28
fora do cluster. A gente pode fazer o
7:30
seguinte, tá gente? Ó, bem tranquilo
7:33
isso aqui, ó. É bem simples também, ó.
7:35
Eu deixei, vou deixar no redim também
7:37
pra gente fazer o debugando com curve. É
7:39
só dar um cubo ct room na imagem do cur
7:43
e a gente vai. Opa, já existe.
7:48
Tá, pera aí.
7:50
Cur debug on. Vamos lá. A gente faz
7:53
esse. Eh, eu, eu, eu deu o erro ali,
7:56
pessoal, porque já existia essa imagem.
7:59
Mas vamos lá. Ã, quando você rodar esse
8:02
cubo, você tem ali run. curl debug, você
8:05
vai estar rodando uma imagem de debug do
8:08
curl. Então você pode rodar simplesmente
8:12
um curve, né? Então você pode dar um cur
8:17
maiúsculo
8:19
get. E aí vai ser o shin long.
8:24
Vamos botar aqui a rota. HTTP
8:27
TTPS
8:30
S não, né? https shin long service e é o
8:34
nome do serve que a gente criou
8:38
na porta pode ser a porta 80, né? Ele tá
8:40
bindo pra porta 80. A gente só vai botar
8:43
aqui qual é eh logs, né, que a gente
8:46
colocou no nome da rota. E ele tem um
8:48
parâmetro que é o type erro. Vamos botar
8:51
o erro ou critical. Vamos botar um erro
8:55
aqui. Erro, né? Vamos fazer isso.
8:59
Simulou o erro. Então ele deu uma
9:01
resposta aqui que o erro foi simulado
9:03
com sucesso. Então a gente conseguiu
9:04
fazer isso daí. Vamos rodar de novo.
9:06
Rodar de novo. Vou rodar de novo. Vou
9:07
rodar de novo. Ok. Simulamos quatro
9:10
erros aí. Ok. Então vamos voltar lá pro
9:12
nosso querido e amado Grafana.
9:16
Ok. Beleza, gente, a gente tem aqui,
9:19
vamos voltar aqui pro Explorer.
9:22
Legalzinho. Só que, bom, a gente tem
9:25
várias filtros ali e a gente, pô, tá
9:28
vendo log que não tá muito, não tá
9:30
fazendo muito sentido pra gente ficar
9:32
olhando o log de aplicações que, OK, não
9:34
vai, não vai impactar a nossa aplicação,
9:37
certo? Então, vamos fazer um filtro, né?
9:40
Então, pra gente filtrar é só vir aqui,
9:42
a gente pode filtrar por aqui ou a gente
9:44
pode vir pela carry, né? A gente pode
9:47
codar a carry aqui com editor. Então, dá
9:49
para fazer aqui, ó, a carry. Bom, eu
9:52
prefiro buildar, que é muito mais
9:54
simples, né? Mas se vocês preferirem
9:57
fazer ali na manualmente, tem essa opção
10:01
também, tá? Mas a gente pode vir aqui
10:03
por aqui. A gente tem vários fields que
10:04
dá pra gente filtrar. Vamos filtrar por
10:07
eh app, né? E o que que ele pega? Ele
10:11
pega o nome da app, que é um filtro que
10:13
o Promil consegue filtrar por causa
10:16
daquelas RGs que a gente mostrou ali no
10:18
velhos ali do Promil. Aquilo é tudo
10:20
automático, ele consegue pegar isso de
10:22
forma automática. Então a gente tem
10:24
aqui, ó, o Shinlong, que é o nome da
10:26
nossa app. Ok, beleza.
10:29
Vamos fazer um run carry aqui. Opa, que
10:33
a gente tem 10 erros acontecidos aqui
10:38
nesse time stamp, ok? a gente conseguiu
10:41
filtrar, então a gente deu alguns erros
10:44
desconhecidos, possivelmente quando ele
10:46
inicializou o inicializou a a aplicação
10:51
e ele deu dois erros e mais 10 erros
10:55
aqui. Bora ver que que que erro é isso.
10:58
A gente pode selecionar esse time stamp
11:00
aqui do e colocamos em uma data
11:03
específica.
11:05
Bom, a gente pode também fazer com que a
11:08
gente coloque esse parcer de Jzon pra
11:10
gente conseguir passear a a mensagem,
11:13
colocar fields adicionais. E a gente
11:15
pode botar operações também, as
11:17
expressões da operações que a gente quer
11:19
tirar ou colocar.
11:22
Bom, vindo aqui para baixo, a gente já
11:24
dá para dar uma olhada nos nossos erros.
11:27
Ó, aqui, ó, o app deu erro. Shin long.
11:31
Container shin long. Detect lever erro.
11:35
File name. A gente consegue saber aonde
11:38
que foi logado esse erro. A gente tem a
11:41
job o namespace que foi feito esse esse
11:45
cara e miniub. OK. Esse foi um log de
11:49
erro na rota logs/er erro. foi indo pro
11:54
steder nesse time stamp aqui. Eu acho
11:58
que a gente consegue pegar a o log
12:01
certinho, eu acho. Deixa eu rodar a
12:03
carry de novo aqui, porque a gente não
12:05
passeou em Jzon certinho ali. Beleza.
12:07
Aqui a gente tem mais informações aqui.
12:10
Beleza. Aqui é o log. Então a gente tem
12:13
o time stamp, né? a gente tem o parse do
12:18
status code. Qual foi o a requisição, o
12:23
tipo de requisição? Foi um get e a gente
12:26
sabe qual é o PEF que foi logado isso
12:28
daí, qual é o a requisição, o PEF da
12:32
requisição que deu o problema, que é
12:35
exatamente o que a gente tinha falado
12:36
que a gente queria, lembra do nosso
12:38
midwer. Então vamos voltar lá pr pra
12:41
nossa aplicação aqui de Vamos voltar pro
12:45
handle. E é basicamente isso que a gente
12:47
colocou, ó. Time stamp, o status, o
12:51
método, a ri, que é o a ri, o pf, né,
12:56
que é do nosso nossa requisição e o
12:58
erro, né? A gente pegou tudo isso,
13:01
formatou e jogou isso no stterout, ok? E
13:04
isso foi o nosso log, cara. Muito bom. a
13:08
gente conseguiu pegar. Só que a gente
13:11
precisa de mais informações. Vai chegar
13:13
momento que a gente vai precisar de mais
13:14
informações. Essas informações todas
13:17
você consegue colocar no seu log. É aí
13:20
que tá a a maestria de de colocar logs
13:24
que são importantes para vocês. Então
13:26
aqui no logs a gente consegue ah aqui na
13:30
parte de erro, que foi o que a gente
13:31
logou, a gente poderia colocar mais
13:34
informações, como por exemplo algum
13:36
processo que você tava fazendo na sua
13:37
função que você queria saber qual era o
13:41
estado dele naquele momento, né? Então a
13:43
gente pode aqui nessa nossa
13:47
vamos voltar aqui pro nosso curve. A
13:49
gente pode logar agora eh info,
13:54
né? Simulamos o a info, po. Podemos
13:56
logar um critical
14:01
do tipo critical. Vamos logar de novo.
14:04
Vamos logar de novo. Ok. Beleza. Vamos
14:07
rodar nossa carry de novo. Acabamos de
14:09
disparar alguns erros ali, tá? Então a
14:12
gente tem erros aqui que aconteceram
14:14
aqui de novo, né? Ó, erro critical.
14:19
Então ele tá dizendo que é desconhecido,
14:21
né? Porque ele só tá conseguindo ver
14:24
esse tipo de coisa. A gente consegue
14:25
adicionar esses essas informações. Esse
14:29
carry inspector aqui na no promilio
14:32
também ele vai conseguir entender o que
14:33
que é um critical, o que que é outros
14:36
fields que são importantes também, né?
14:39
Ó, eu posso adicionar aqui, ele só sabe
14:41
de um no info erro, tá? Então dá para
14:44
fazer isso aí também. Então, como ele
14:46
não entende o que é o critical, ele ele
14:48
jogou isso aqui, essa informação pra
14:50
gente, mas já ah, já mostrou aqui ah
14:54
para para nós os erros que a gente tinha
14:57
acabado de colocar, né? Então, a gente
15:00
pode colocar alguns filtros aqui e aí eu
15:04
vou mostrar para vocês na próxima aula
15:05
quais são as formas da gente otimizar,
15:08
colocar esse dashboard e etc. Vamos lá.
15:11
Yeah.0:01
Tá, pessoal, eu aqui de novo. Bem-vindo
0:04
ao módulo 4 sobre métricas. Pessoal,
0:09
parabéns se você chegou até aqui. Sei
0:11
que a jornada não foi curta. Agora a
0:15
gente vai trabalhar com um assunto muito
0:17
importante, que são as métricas. E por
0:20
que, ah, as métricas vão te ajudar a
0:25
entender os problemas antes que eles
0:26
aconteçam. Eu vou dar uma ideia para
0:29
vocês de alguns termos, né? Vamos falar
0:32
sobre o Ford Golden Signals e ainda
0:35
também vou botar uma parte prática aqui,
0:38
a gente levantando Promitius, levantando
0:40
um cluster aqui e colocando métricas
0:43
reais de uma aplicação ali do nosso
0:46
nossa aplicação de teste que é o
0:47
Shelong. Vamos lá. Te espero na próxima
0:49
aula e a gente vai falar sobre o Four
0:51
Golden Signs, os quatro sinais de ouro
0:54
da observabilidade.0:01
Vamos começar então, pessoal, com uma
0:04
latência.
0:05
A latência é o tempo que a solicitação
0:09
vai demorar para responder da tua
0:11
aplicação. É, é, vamos dizer que é o
0:14
tempo de resposta de um programa, de um
0:18
sistema. Então, para ser concluído, ele
0:21
vai receber essa solicitação, pode ser
0:23
HTTP, não sei como que é o teu sistema,
0:27
mas é é a partir do momento que ele
0:29
recebe aquele cálculo, aquela request,
0:32
ele processa aquela request e te envia
0:35
de volta. Isso é latência. É a latência
0:39
para uma solicitação ser atendida.
0:41
Então, a gente tem a métrica chave,
0:43
geralmente é o P95, o P99, que é a
0:46
porcentagem que a gente tem de resposta
0:51
em determinado, por exemplo, 99% das
0:54
solicitações é atendido em média em, sei
0:58
lá, 20 msundos, 40 msundos, 100 msos,
1:02
enfim, eh, vai depender da situação
1:07
específica de cada aplicação. Então,
1:10
latência com erro inclui falhas no
1:13
cálculo. Por exemplo, se eu tenho uma
1:16
aplicação que deva responder em média
1:19
entre 40 a 100 ms e ela começa a
1:23
responder a 1 segundo a 700 msundos, eu
1:29
tenho um problema. o meu P95 tá caindo,
1:32
meu P99 tá caindo. Em consequência
1:35
disso, a gente viu nos modos passado que
1:38
nosso SLO vai ser ferido, que é o nosso
1:41
objetivo de negócio. Se a gente não tá
1:44
conseguindo atender a latência, os
1:46
clientes vão ser prejudicados, né? As
1:48
ferramentas que a gente utiliza para
1:49
capturar a latência vão ter que estar
1:51
instrumentado nas aplicações também, mas
1:54
a gente pode pegar com Promitos. Eh, tem
1:56
ferramentas de APM que também conseguem
1:58
pegar esse tipo de informação, né? Já é
2:01
autoestinrumentado na tua aplicação, né?
2:03
na telinguagem de programação ali que tá
2:04
rodando. A, o grafana vai ser vai ser
2:07
útil pra gente visualizar esses
2:09
dashboards, mas se tiver utilizando um
2:11
APM, geralmente o APM já disponibiliza
2:13
esses dashboards pra gente. A gente, eu
2:16
não coloquei ali, mas tem o openem, open
2:18
telemetry também ele faz esse tipo de
2:20
coisa, dependendo da tua linguagem, vai
2:22
est mais maduro para pegar esse tipo de
2:24
informação, né? Então, que são
2:26
informações de métrica, tá? Então, é
2:28
isso, pessoal. Essa é a latência. Na
2:31
próxima aula eu vou mostrar para vocês
2:32
um um outro sinal e aí vamos continuar
2:36
nessa saga aí dos quatro sinais de ouro
2:38
da observabilidade.
Boa, pessoal. Chegamos a esse
0:04
importantíssimo
0:05
sinal que é o tráfego, tá? Ele é a
0:09
quantidade
0:10
de solicitações,
0:12
de requisições de determinada
0:15
solicitação pro teu sistema, que são
0:18
processadas pelo teu sistema. Então, ele
0:20
mede a demanda de recursos. Essa
0:23
métrica, ela vai est muito por request
0:25
por segundo. É sempre uma métrica que
0:27
vai olhar por segundo os dados. Então a
0:29
gente pode validar também volume de
0:32
dados trafegados na rede, então esse
0:34
tipo de dados, request por segundo que a
0:37
gente tem, então quantas requests aí de
0:40
forma quantitativa por segundo a gente
0:42
tá tendo? Então por que que isso
0:44
importa, né? O tráfego é importante por
0:46
quê, né? Ele ajuda a prevenir esse tipo
0:50
de imprevisto em determinadas situações.
0:53
Se eu sei que a minha aplicação ela foi
0:55
testada para aguentar X requisições por
0:59
segundo, ou a gente tem um limite de
1:02
data transfer
1:05
ou até da minha ong
1:08
limite eu vou ter perda de dados, eu vou
1:10
começar a ter erro. Então é um problema.
1:13
Então, a gente precisa saber quando que
1:15
a gente vai chegar nesse limite e tem
1:17
que saber quais são os picos, quando não
1:20
tem pico, quando tem, sabe? Então, a
1:22
gente tem que entender esse esse tipo de
1:25
métrica porque é importante pra
1:27
prevenção de possíveis problemas, né? E
1:31
ela vai est muito ligada com uma outra
1:35
sinal que eu vou mostrar para vocês em
1:36
outra aula. Vejo você na próxima aula
1:38
sobre outro sinal de ouro muito
1:41
importante.0:20
próximo da carga máxima dele. Ou seja, a
0:23
que ponto eh de utilização a gente vai
0:27
ter uma degradação do sistema. Por
0:30
exemplo, se eu chegar a 95% de
0:33
utilização de CPU, eu sei que meu
0:35
sistema vai est degradado. Eu vou ter
0:37
clientes que vão tomar erro, eu vou ter
0:40
clientes ali, vão ter requestes que vão
0:42
ganhar mais latência. Mas vocês
0:45
conseguiram entender uma coisa que
0:47
acabei de falar, essa métrica às vezes
0:49
ela é o gatilho para outras, né? Então
0:52
se eu tiver uma utilização de CPU muito
0:55
grande, eu posso ter saturação. Então eu
0:57
sei que vai acontecer uma saturação do
0:59
meu serviço. Em consequência disso, eu
1:02
posso ter mais latência, né? Porque eh
1:05
eu vou ter throttle no meus eh nos meus
1:08
processos, porque eu tô utilizando muito
1:10
a CPU, a CPU tá ficando em em espera,
1:13
isso vai dar throttle num dos meus
1:15
processos ou que seja, eu vou ter
1:17
latência. Então o que que importa a
1:19
situação? O motivo dela é evitar
1:22
gargalo, né? a gente se planejar, ver
1:25
quais são as métricas chaves que fazem
1:27
sentido pra tua aplicação. Por exemplo,
1:29
utilização de CPU, utilização de
1:31
memória, eh picos de tráfego. A gente
1:35
sabe que tráfego tá muito ligado também
1:37
com saturação, bem como latência. A
1:40
gente sabe que quando a gente chega a
1:42
determinados request por segundo, a
1:44
gente vai ter saturação do sistema.
1:46
Então ele vai est muito ligado também
1:48
com esse outro tipo de métrica, tá bom?
1:50
Então, a gente vai paraa última, que é
1:53
uma das mais importantes de todas. Vamos
1:57
lá.0:01
Um dos sinais mais importantes aqui na
0:04
minha visão é o erro, né? A gente
0:07
trabalhou com erro no módulo passado que
0:09
foi trabalhando com logs. Então a
0:12
diferença da métrica de erro para gerar
0:15
logs é bem pouca, tá? Mas o que que eu
0:19
quero dizer com isso? A métrica chave de
0:21
erro, geralmente a gente pega
0:23
porcentagem, taxa das solicitações que
0:25
estão falhando no sistema. Então, a
0:28
gente se baseia muito pelo porcentil de
0:31
erros, por exemplo, 500, erros 402, 403,
0:36
não sei. São erros que na visão da
0:39
aplicação que podem ser um problema ou
0:42
não, né? Então a gente tem que entender
0:45
a que o erro aqui diferente do log, ele
0:49
não quer dizer um problema. Quer dizer,
0:52
ele vai ser um problema quando ele
0:53
passar do nosso erro budget, né? A gente
0:56
tem um budget de erro, a gente tem um
0:59
budget de incidente, mas a gente tem
1:02
essa taxa que vai olhar para isso. Vamos
1:04
dizer que eu tenho, eu sou capaz de
1:07
aguentar determinados erros 500. Se eu
1:10
passar de determinados erros 500 durante
1:12
o mês, eu vou tá ferindo o meu SLO, vou
1:16
tá ferindo ali o meu SLA, né? Porque eu
1:19
vou ter que vou ter que ter uma resposta
1:22
para isso, né? Se eu não tiver uma
1:23
resposta rápida, eu vou estar ferindo o
1:26
SLA com os meus clientes. Então, o erro
1:29
ele vem muito nessa linha de que eu
1:32
sempre falo muito para pr para várias
1:35
pessoas que que tem eh uma aplicação
1:39
rodando, é que se tua aplicação não tem
1:42
erro, é porque você não sabe que ela tem
1:45
erro, não quer dizer que ela não tenha
1:46
erro. Então, quando a gente tá
1:48
monitorando os erros, que a gente tá
1:50
instrumentando tudo que que é erro que
1:52
acontece e a gente coloca isso como
1:54
métrica, a gente sabe exatamente aonde a
1:58
gente pode errar, aonde a gente não pode
2:00
errar, o que está dando errado, o que
2:03
não está dando errado em determinada
2:05
situação, né? O que quando acontece um
2:07
deploy, eu tenho um pico alto de erro
2:09
500, a gente sabe exatamente o que
2:11
aconteceu. Foi o deploy, a gente
2:13
reverte, o erro vai cair, a gente vai
2:15
olhar isso no dashboard, o pico
2:16
descendo, tá? Então é isso, pessoal.
2:20
Esse são four golden signos, quatro
2:24
sinais de ouro da observabilidade. Vocês
2:26
aplicando esses quatro sinais, vocês vão
2:28
estar bem cobertos ali na
2:31
observabilidade ali do Google, segundo o
2:35
Google. Yeah.0:01
Então pessoal, para finalizar a parte
0:03
teórica, a gente vai ter uma uma linha
0:07
aqui, mas essa linha dos quatro sinais
0:10
pra gente chegar no Golden mesmo, não
0:12
quer dizer que ela vai ter uma uma parte
0:15
linear de acontecimentos. Então,
0:17
saturação
0:19
pode me gerar erro, pode me gerar
0:21
tráfego, mas não quer dizer que o
0:24
tráfego alto vai me gerar erro. Então,
0:28
uma vai tá alinhado com a outra, elas
0:31
têm que trabalhar juntos, elas precisam
0:34
existir em conjunto para que elas façam
0:36
sentido. Então, se eu começo a ter CPU a
0:41
90% e eu sei que eu tô começando a ter
0:43
latência, eu consigo juntar essas duas
0:45
métricas e consigo ter um trouble shoot
0:48
um pouco mais assertivo sobre o
0:50
problema, né? Eu sei que quando eu tô
0:52
com muita CPU, eu tenho mais latência e
0:55
eu vou atrás do problema da CPU. Por que
0:58
que eu estou tendo muita CPU? Estou
1:00
tendo muito tráfego? Não, não tô tendo
1:03
muito tráfego. Então não é request,
1:05
então é um processo interno. Algo está
1:07
acontecendo na minha aplicação que tá
1:09
demandando mais CPU. Agora, se eu tô
1:12
tendo mais latência,
1:15
tô tendo saturação de CPU e tô tendo
1:17
mais tráfego, bom, isso é outra coisa
1:21
que já me indica algo diferente. Então,
1:24
quer dizer que eu tô tendo uma demanda
1:26
maior, talvez a minha aplicação esteja
1:28
atendendo, OK? Só que a demanda tá tão
1:31
grande que vai aumentar a latência.
1:33
Talvez seja uma ação de escalar
1:35
horizontal, vertical, enfim, vai
1:38
depender de cada situação, tá? Então, o
1:41
sistema degradado, a gente vai olhar pra
1:43
saturação, erros variados, um contador
1:46
da linha do tempo, a gente vai olhar
1:48
para erro, requisição do sistema,
1:51
requisições que são solicitadas pro
1:53
sistema. banda de rede, tráfego,
1:56
latência, experiência do zoado sendo
1:59
prejudicado. Então, coloca isso na
2:01
cabeça. Eh, não, não quer dizer que a
2:05
gente tem que gravar aqui, ah, precisa
2:07
ser quantidade de tempo que o a
2:09
aplicação vai dar de resposta.
2:11
Experiência do usuário sendo
2:12
prejudicado, isso aí você vai gravar
2:14
bem, tá? Porque quando você clica ali
2:17
paraa página de login, por exemplo, e
2:19
ficar carregando, carregando,
2:20
carregando, carregando, carregando até
2:22
chegar a página em si, não é legal. A
2:25
experiência do usuário é prejudicada,
2:27
tá?
2:28
Então, erro também nesse mesma nessa
2:30
mesma exemplo que a gente que eu falei
2:33
aqui da página de login, eh, se a gente
2:35
tem uma, um monitoramento específico da
2:38
página de login nesse ciclo do usuário
2:40
criar o cadastro, do usuário se logar e
2:44
a gente e especificamente nessa rota de
2:46
login, a gente monitorar os erros, a
2:49
gente consegue ter basicamente um olhar
2:53
pra parte mais crítica da nossa
2:55
aplicação, que é o login. Se as pessoas
2:57
não conseguem logar, elas não conseguem
2:58
usar a nossa app, né? Então a gente
3:01
olha, começou a dar muito erro 500, a
3:03
gente vai ter que atuar de alguma forma
3:05
para tentar entender o problema. Então é
3:08
isso, pessoal. Agora vai começar a parte
3:11
prática.
3:12
Eu vou fazer um vídeo para para vocês
3:14
entenderem o que que a gente vai estar
3:15
trabalhando aqui no próxima aula e vou
3:18
mostrar quais são as nossas
3:20
environments, tá? Então é isso, te vejo
3:22
na próxima aula.