{"id":31864,"date":"2019-10-31T21:43:33","date_gmt":"2019-10-31T18:43:33","guid":{"rendered":"https:\/\/prohoster.info\/blog\/monitoring-myortv-da-zdravstvuet-monitoring\/"},"modified":"2019-10-31T21:43:33","modified_gmt":"2019-10-31T18:43:33","slug":"monitoring-myortv-da-zdravstvuet-monitoring","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/monitoring-myortv-da-zdravstvuet-monitoring","title":{"rendered":"Monitoramento inativo? \u2014 Viva o monitoramento","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Monitoramento inativo? \u2014 Viva o monitoramento\" src=\"\/wp-content\/uploads\/2019\/04\/13453bb7025a6bf3d1c7a3dc6d038d16.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNossa empresa atua desde 2008, principalmente na gest\u00e3o de infraestruturas e no suporte t\u00e9cnico 24\/7 para projetos web: temos mais de 400 clientes, o que representa cerca de 15% do com\u00e9rcio eletr\u00f4nico da R\u00fassia. Portanto, na \u00e1rea de suporte, lidamos com uma arquitetura bastante diversificada. Se algo falha, somos obrigados a consert\u00e1-lo em at\u00e9 15 minutos. Mas para entender que um acidente ocorreu, \u00e9 preciso monitorar o projeto e reagir a incidentes. Mas como fazer isso? <\/p>\n<p>Acredito que, na organiza\u00e7\u00e3o de um sistema de monitoramento adequado, ocorra uma falha. Se n\u00e3o houvesse essa falha, meu discurso consistiria em um \u00fanico ponto: \"Por favor, instale Prometheus + Grafana e os plugins 1, 2, 3\". Infelizmente, agora isso n\u00e3o funciona assim. E o principal problema \u00e9 que todos continuam acreditando em algo que existia em 2008, no que diz respeito aos componentes de software. <\/p>\n<p>Em rela\u00e7\u00e3o \u00e0 organiza\u00e7\u00e3o do sistema de monitoramento, arrisco dizer que... projetos com monitoramento adequado n\u00e3o existem. E a situa\u00e7\u00e3o \u00e9 t\u00e3o ruim que, se algo falhar, h\u00e1 o risco de isso passar despercebido \u2014 afinal, todos acreditam que \"tudo est\u00e1 sendo monitorado\".<br \/>\nTalvez tudo esteja sendo monitorado. Mas como? <\/p>\n<p>Todos n\u00f3s j\u00e1 nos deparamos com uma hist\u00f3ria semelhante: um devops, um administrador, e eles s\u00e3o abordados pela equipe de desenvolvedores que diz \u2014 \"fizemos o release, agora monitore\". O que devemos monitorar? Como isso funciona?<\/p>\n<p>Ok. Estamos monitorando da velha maneira. Mas j\u00e1 mudou, e descobre-se que voc\u00ea estava monitorando o servi\u00e7o A, que se tornou o servi\u00e7o B, que interage com o servi\u00e7o C. Mas a equipe de desenvolvedores diz: \"Instale o software, ele deve monitorar tudo!\"<\/p>\n<p>Ent\u00e3o, o que mudou? \u2014 Tudo mudou!<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h4>2008. Tudo perfeito.<\/h4>\n<p>\nH\u00e1 alguns desenvolvedores, um servidor, um servidor de banco de dados. A partir da\u00ed tudo come\u00e7a. Temos algumas informa\u00e7\u00f5es, instalamos Zabbix, Nagios, Cacti. E ent\u00e3o configuramos alertas claros para CPU, funcionamento dos discos, espa\u00e7o em disco. Tamb\u00e9m fazemos alguns checagens manuais para verificar se o site est\u00e1 respondendo, se os pedidos est\u00e3o chegando ao banco de dados. E \u00e9 isso \u2013 estamos mais ou menos protegidos. <\/p>\n<p>Ao comparar o volume de trabalho que o administrador realizava para garantir a monitoriza\u00e7\u00e3o, 98% era autom\u00e1tico: a pessoa respons\u00e1vel pela monitoriza\u00e7\u00e3o precisava entender como instalar o Zabbix, como configur\u00e1-lo e ajustar os alertas. E 2% eram dedicados a verifica\u00e7\u00f5es externas: se o site respondia e fazia consultas ao banco, se novos pedidos chegavam.<\/p>\n<p><img decoding=\"async\" alt=\"Monitoramento inativo? \u2014 Viva o monitoramento\" src=\"\/wp-content\/uploads\/2019\/04\/3563dda4d025fd18200d6410d7d065ed.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n <\/p>\n<h4>Ano de 2010. A carga est\u00e1 aumentando.<\/h4>\n<p>\nCome\u00e7amos a escalar os sites, adicionando um mecanismo de busca. Queremos ter certeza de que o cat\u00e1logo de produtos cont\u00e9m todos os itens. E que a busca de produtos funciona. Que o banco de dados est\u00e1 operando, que os pedidos est\u00e3o sendo feitos, que o site responde externamente e responde com dois. <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/pt\/server\/\"   title=\"servidores\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"1314\">servidores<\/a> e o usu\u00e1rio n\u00e3o \u00e9 desconectado do site enquanto \u00e9 reequilibrado para outro servidor, etc. O n\u00famero de entidades est\u00e1 aumentando. <\/p>\n<p>Al\u00e9m disso, a entidade relacionada \u00e0 infraestrutura continua sendo a maior na mente do gerente. A ideia de que a pessoa respons\u00e1vel pela monitoriza\u00e7\u00e3o \u00e9 quem instala o Zabbix e consegue configur\u00e1-lo ainda persiste.<\/p>\n<p>Mas ao mesmo tempo surgem trabalhos para conduzir verifica\u00e7\u00f5es externas, para criar um conjunto de scripts de consulta para o indexador de busca, um conjunto de scripts para verificar se a busca muda durante a indexa\u00e7\u00e3o, um conjunto de scripts que conferem se os produtos est\u00e3o sendo enviados para o servi\u00e7o de entrega, etc.<\/p>\n<p><img decoding=\"async\" alt=\"Monitoramento inativo? \u2014 Viva o monitoramento\" src=\"\/wp-content\/uploads\/2019\/04\/afa94a3156a24a81ab359b430341f27d.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNote que eu escrevi \"conjunto de scripts\" tr\u00eas vezes. Ou seja, o respons\u00e1vel pela monitoriza\u00e7\u00e3o n\u00e3o \u00e9 mais apenas quem instala o Zabbix. \u00c9 algu\u00e9m que come\u00e7a a programar. Mas na cabe\u00e7a da equipe, nada ainda mudou. <\/p>\n<p>No entanto, o mundo est\u00e1 mudando, tornando-se cada vez mais complexo. Adiciona-se uma camada de virtualiza\u00e7\u00e3o, v\u00e1rios novos sistemas. Eles come\u00e7am a interagir entre si. Quem disse \"cheira a microsservi\u00e7os?\" Mas cada servi\u00e7o ainda parece, por si s\u00f3, um site separado. Podemos acess\u00e1-lo e entender que ele fornece as informa\u00e7\u00f5es necess\u00e1rias e funciona por conta pr\u00f3pria. E se voc\u00ea \u00e9 um administrador, lidando constantemente com um projeto que est\u00e1 se desenvolvendo por 5-7-10 anos, voc\u00ea acumula esses conhecimentos: um novo n\u00edvel surge - voc\u00ea o percebe, e outro n\u00edvel surge - voc\u00ea o percebe... <\/p>\n<p><img decoding=\"async\" alt=\"Monitoramento inativo? \u2014 Viva o monitoramento\" src=\"\/wp-content\/uploads\/2019\/04\/3578182594d012732afde7849b75322a.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMas raramente algu\u00e9m mant\u00e9m um projeto por 10 anos.<\/p>\n<h3>Resumo do monitoramento<\/h3>\n<p>\nSuponhamos que voc\u00ea entrou em uma nova startup que rapidamente reuniu 20 desenvolvedores, escreveu 15 microsservi\u00e7os, e voc\u00ea \u00e9 o administrador que diz: \"Construa CI\/CD. Por favor\". Voc\u00ea construiu o CI\/CD e de repente ouve: \"\u00c9 dif\u00edcil trabalharmos com produ\u00e7\u00e3o no 'kube', sem entender como a aplica\u00e7\u00e3o funcionar\u00e1 nele. Crie um sandbox nesse mesmo 'kube'.\"<br \/>\n Voc\u00ea cria um sandbox nesse kube. Eles imediatamente dizem: \"Queremos um banco de dados de stage que seja atualizado diariamente com a produ\u00e7\u00e3o, para entender se isso funciona no banco de dados, mas sem prejudicar o banco de dados de produ\u00e7\u00e3o.\"<\/p>\n<p>Voc\u00ea vive tudo isso. Faltam 2 semanas para o lan\u00e7amento e eles dizem: \"Agora precisamos monitorar tudo isso...\" Ou seja, monitorar a infraestrutura em cluster, monitorar a arquitetura de microsservi\u00e7os, monitorar a intera\u00e7\u00e3o com servi\u00e7os externos... <\/p>\n<p>E os colegas tiram de sua mente um esquema habitual e dizem: \"Aqui est\u00e1 tudo claro! Instale um programa que fa\u00e7a essa monitora\u00e7\u00e3o\". Sim, Sim: Prometheus + Grafana + plugins. <br \/>\nE acrescentam: \"Voc\u00ea tem duas semanas, fa\u00e7a com que tudo seja confi\u00e1vel\".<\/p>\n<p>Em muitos projetos que vemos, destaca-se uma pessoa apenas para a monitora\u00e7\u00e3o. Imagine que queremos contratar uma pessoa por 2 semanas para se dedicar \u00e0 monitora\u00e7\u00e3o e estamos elaborando seu curr\u00edculo. Quais habilidades essa pessoa deve ter, considerando tudo o que dissemos at\u00e9 agora?<\/p>\n<ul>\n<li>Ela deve entender a monitora\u00e7\u00e3o e a especificidade da opera\u00e7\u00e3o da infraestrutura f\u00edsica.<\/li>\n<li>Ela deve entender as especificidades da monitora\u00e7\u00e3o do Kubernetes (todos querem ir para o 'kube', porque pode-se abstrair tudo, esconder-se, j\u00e1 que o administrador resolver\u00e1 o resto) \u2014 e do Kubernetes em si, sua infraestrutura, e compreender como monitorar aplica\u00e7\u00f5es dentro dele.<\/li>\n<li>Ela deve entender que os servi\u00e7os se comunicam de maneiras espec\u00edficas, e conhecer as caracter\u00edsticas da intera\u00e7\u00e3o entre servi\u00e7os. \u00c9 comum ver um projeto onde parte dos servi\u00e7os se comunicam de forma s\u00edncrona, porque de outra forma n\u00e3o h\u00e1 como. Por exemplo, o backend usa REST, vai ao servi\u00e7o de cat\u00e1logo via gRPC, obt\u00e9m uma lista de produtos e retorna. Aqui n\u00e3o h\u00e1 como esperar. Com outros servi\u00e7os, ele trabalha de forma ass\u00edncrona. Enviar um pedido para o servi\u00e7o de entrega, enviar um e-mail, etc.<br \/>\nVoc\u00ea, provavelmente, j\u00e1 est\u00e1 perdido com tudo isso? E o administrador que precisa monitorar isso est\u00e1 ainda mais perdido. <\/li>\n<li>Ele deve saber planejar e planejar corretamente \u2014 \u00e0 medida que o trabalho vai aumentando. <\/li>\n<li>Portanto, ele precisa criar uma estrat\u00e9gia para o servi\u00e7o criado para entender como monitor\u00e1-lo especificamente. \u00c9 necess\u00e1rio um entendimento da arquitetura do projeto e seu desenvolvimento, al\u00e9m de compreender as tecnologias utilizadas no desenvolvimento. <\/li>\n<\/ul>\n<p>\nVamos lembrar de um caso absolutamente normal: parte dos servi\u00e7os em PHP, parte em Go, parte em JS. Eles trabalham juntos de alguma forma. Da\u00ed vem o termo 'microsservi\u00e7o': o n\u00famero de sistemas distintos se tornou t\u00e3o grande que os desenvolvedores n\u00e3o conseguem entender o projeto como um todo. Uma parte da equipe escreve servi\u00e7os em JS, que funcionam de forma independente e n\u00e3o sabem como o restante do sistema funciona. Outra parte escreve servi\u00e7os em Python e n\u00e3o se envolve em como os outros servi\u00e7os funcionam; eles est\u00e3o isolados em sua pr\u00f3pria \u00e1rea. A terceira parte escreve servi\u00e7os em PHP ou em outra linguagem. <br \/>\nTodas essas 20 pessoas est\u00e3o divididas em 15 servi\u00e7os, e h\u00e1 apenas um administrador que deve entender tudo isso. Espera a\u00ed! Acabamos de dividir o sistema em 15 microsservi\u00e7os, porque 20 pessoas n\u00e3o conseguem compreender o sistema inteiro. <\/p>\n<p>Mas isso precisa ser monitorado de alguma forma...<\/p>\n<p>E no final? No final, h\u00e1 uma \u00fanica pessoa que armazena tudo o que uma equipe inteira de desenvolvedores n\u00e3o consegue entender, e ainda assim, essa pessoa precisa saber e ser capaz do que mencionamos acima \u2014 infraestrutura de hardware, infraestrutura Kubernetes, etc.<\/p>\n<p>O que dizer... Houston, temos um problema.<\/p>\n<h3>O monitoramento de um projeto de software moderno \u00e9, por si s\u00f3, um projeto de software.<\/h3>\n<p>\nA partir da falsa confian\u00e7a de que monitoramento \u00e9 software, surge a cren\u00e7a em milagres. E milagres, infelizmente, n\u00e3o existem. N\u00e3o se pode instalar o Zabbix e esperar que tudo funcione. N\u00e3o faz sentido instalar o Grafana e esperar que tudo fique bem. A maior parte do tempo ser\u00e1 gasta organizando verifica\u00e7\u00f5es de como os servi\u00e7os funcionam e sua intera\u00e7\u00e3o entre si, al\u00e9m das verifica\u00e7\u00f5es de como os sistemas externos funcionam. Faticamente, 90% do tempo ser\u00e1 gasto n\u00e3o na escrita de scripts, mas no desenvolvimento de software. E essa tarefa deve ser realizada por uma equipe que compreenda o funcionamento do projeto. <br \/>\nSe nessa situa\u00e7\u00e3o uma \u00fanica pessoa for encarregada do monitoramento, ocorrer\u00e1 um desastre. E isso acontece em toda parte.<\/p>\n<p>Por exemplo, existem v\u00e1rios servi\u00e7os que se comunicam entre si atrav\u00e9s do Kafka. Um pedido chegou, enviamos a mensagem do pedido para o Kafka. H\u00e1 um servi\u00e7o que escuta as informa\u00e7\u00f5es sobre o pedido e realiza a entrega do produto. H\u00e1 um servi\u00e7o que escuta as informa\u00e7\u00f5es sobre o pedido e envia um e-mail ao usu\u00e1rio. E ent\u00e3o surgem muitos outros servi\u00e7os, e come\u00e7amos a nos confundir.<\/p>\n<p>E se voc\u00ea ainda entregar isso ao administrador e aos desenvolvedores na fase em que falta pouco para o lan\u00e7amento, a pessoa precisar\u00e1 entender todo esse protocolo. Ou seja, um projeto dessa magnitude leva um tempo consider\u00e1vel, e isso deve ser considerado no desenvolvimento do sistema. <br \/>\nMas muito frequentemente, especialmente no in\u00edcio, em startups, vemos como a monitora\u00e7\u00e3o \u00e9 adiada. \"Agora vamos fazer o Proof of Concept, lan\u00e7aremos com ele, que ele caia \u2013 estamos prontos para sacrificar. E depois, n\u00f3s monitoraremos tudo isso\". Quando (ou se) o projeto come\u00e7a a gerar receita, os neg\u00f3cios querem adicionar ainda mais recursos \u2014 porque come\u00e7ou a funcionar, ent\u00e3o \u00e9 preciso continuar desenvolvendo! E voc\u00ea est\u00e1 em um ponto em que primeiro precisa monitorar tudo o que foi feito anteriormente, o que leva muito mais do que 1% do tempo. E, a prop\u00f3sito, para a monitora\u00e7\u00e3o, ser\u00e3o necess\u00e1rios desenvolvedores, e \u00e9 mais f\u00e1cil direcion\u00e1-los para novos recursos. No final, novos recursos s\u00e3o desenvolvidos, tudo \u00e9 ampliado, e voc\u00ea se encontra em um deadlock infinito.<\/p>\n<p>Ent\u00e3o, como monitorar um projeto desde o in\u00edcio, e o que fazer se voc\u00ea recebeu um projeto que precisa ser monitorado, mas n\u00e3o sabe por onde come\u00e7ar?<\/p>\n<p>Em primeiro lugar, \u00e9 necess\u00e1rio planejar. <\/p>\n<p><i>Um desvio l\u00edrico: muito frequentemente, come\u00e7a-se pela monitora\u00e7\u00e3o da infraestrutura. Por exemplo, temos Kubernetes. Vamos come\u00e7ar instalando o Prometheus com o Grafana, instalaremos plugins para monitorar o 'cubinho'. N\u00e3o apenas os desenvolvedores, mas tamb\u00e9m os administradores t\u00eam a triste pr\u00e1tica de: 'Vamos instalar este plugin, e o plugin provavelmente sabe como fazer isso'. As pessoas gostam de come\u00e7ar com etapas simples e compreens\u00edveis, e n\u00e3o com a\u00e7\u00f5es importantes. E a monitora\u00e7\u00e3o da infraestrutura \u00e9 apenas isso.<\/i><\/p>\n<p>Para come\u00e7ar, decida o que e como deseja monitorar, e depois escolha a ferramenta, pois outras pessoas n\u00e3o podem pensar por voc\u00ea. E deveriam mesmo? Outras pessoas pensaram em si mesmas, em um sistema universal \u2014 ou n\u00e3o pensaram, quando escreveram este plugin. E o fato de que este plugin tem 5 mil usu\u00e1rios n\u00e3o significa que ele traz algum benef\u00edcio. Talvez voc\u00ea se torne o 5001\u00ba apenas porque j\u00e1 havia 5000 pessoas antes. <\/p>\n<p>Se voc\u00ea come\u00e7ou a monitorar a infraestrutura e o backend do seu aplicativo parou de responder, todos os usu\u00e1rios perder\u00e3o a conex\u00e3o com o aplicativo m\u00f3vel. Vai aparecer um erro. Eles v\u00e3o at\u00e9 voc\u00ea e dir\u00e3o \"O aplicativo n\u00e3o funciona, o que voc\u00ea est\u00e1 fazendo aqui?\" \u2014 \"Estamos monitorando.\" \u2014 \"Como voc\u00eas est\u00e3o monitorando se n\u00e3o veem que o aplicativo n\u00e3o est\u00e1 funcionando?!\" <\/p>\n<ol>\n<li>Eu acredito que o monitoramento deve come\u00e7ar exatamente no ponto de entrada do usu\u00e1rio. Se o usu\u00e1rio n\u00e3o v\u00ea que o aplicativo est\u00e1 funcionando \u2014 j\u00e1 era, isso \u00e9 um fracasso. E o sistema de monitoramento deve avisar sobre isso em primeiro lugar. <\/li>\n<li>E s\u00f3 depois podemos monitorar a infraestrutura. Ou fazer isso em paralelo. Com a infraestrutura \u00e9 mais simples \u2014 aqui finalmente podemos apenas instalar o zabbix. <\/li>\n<li>E agora precisamos ir \u00e0s ra\u00edzes do aplicativo para entender onde as coisas n\u00e3o est\u00e3o funcionando.<\/li>\n<\/ol>\n<p>\nMinha principal ideia \u00e9 que o monitoramento deve ocorrer em paralelo com o processo de desenvolvimento. Se voc\u00ea desviar a equipe de monitoramento para outras tarefas (como criar CI\/CD, um sandbox, reorganizar a infraestrutura), o monitoramento come\u00e7ar\u00e1 a ficar para tr\u00e1s e, possivelmente, voc\u00ea nunca conseguir\u00e1 acompanh\u00e1-lo com o desenvolvimento (ou cedo ou tarde ter\u00e1 que interromper o desenvolvimento).<\/p>\n<h3>Tudo por n\u00edveis<\/h3>\n<p>\nVeja como eu imagino a organiza\u00e7\u00e3o do sistema de monitoramento.<\/p>\n<p>1) N\u00edvel do aplicativo:<\/p>\n<ul>\n<li>monitoramento da l\u00f3gica de neg\u00f3cios do aplicativo;<\/li>\n<li>monitoramento das m\u00e9tricas de sa\u00fade dos servi\u00e7os;<\/li>\n<li>monitoramento de integra\u00e7\u00e3o.<\/li>\n<\/ul>\n<p>\n2) N\u00edvel da infraestrutura:<\/p>\n<ul>\n<li>monitoramento do n\u00edvel de orquestra\u00e7\u00e3o;<\/li>\n<li>monitoramento do software de sistema;<\/li>\n<li>monitoramento do n\u00edvel de hardware.<\/li>\n<\/ul>\n<p>\n3) Novamente o n\u00edvel do aplicativo \u2014 mas agora como um produto de engenharia:<\/p>\n<ul>\n<li>coleta e observa\u00e7\u00e3o de logs do aplicativo;<\/li>\n<li>APM;<\/li>\n<li>tracing.<\/li>\n<\/ul>\n<p>\n4) Alerta:<\/p>\n<ul>\n<li>organiza\u00e7\u00e3o do sistema de aviso;<\/li>\n<li>organiza\u00e7\u00e3o do sistema de plant\u00e3o;<\/li>\n<li>organiza\u00e7\u00e3o da \"base de conhecimento\" e do fluxo de trabalho para o tratamento de incidentes.<\/li>\n<\/ul>\n<p>\n<b>Importante<\/b>: chegamos \u00e0 alertagem n\u00e3o depois, mas imediatamente! N\u00e3o \u00e9 necess\u00e1rio iniciar o monitoramento e pensar em quem receber\u00e1 os alertas \u201cmais tarde\u201d. Afinal, qual \u00e9 a finalidade do monitoramento: entender onde algo n\u00e3o est\u00e1 funcionando bem no sistema e informar as pessoas certas sobre isso. Se deixarmos para o final, as pessoas certas s\u00f3 saber\u00e3o que algo est\u00e1 errado quando receberem a liga\u00e7\u00e3o \u201cnada est\u00e1 funcionando\u201d.<\/p>\n<h3>N\u00edvel de aplicativo \u2014 monitoramento da l\u00f3gica de neg\u00f3cios<\/h3>\n<p>\nAqui falamos sobre a verifica\u00e7\u00e3o do pr\u00f3prio fato de que o aplicativo est\u00e1 funcionando para o usu\u00e1rio.<\/p>\n<p>Esse n\u00edvel deve ser implementado na fase de desenvolvimento. Por exemplo, temos um Prometheus hipot\u00e9tico: ele acessa o servidor que realiza as verifica\u00e7\u00f5es, chama um endpoint, e esse endpoint verifica a API.<\/p>\n<p>Quando frequentemente pedem para monitorar a p\u00e1gina inicial para garantir que o site est\u00e1 funcionando, os programadores fornecem um endpoint que pode ser chamado sempre que \u00e9 necess\u00e1rio verificar se a API est\u00e1 funcionando. E os programadores naquele momento ainda criam \/api\/test\/helloworld. <br \/>\nA \u00fanica maneira de ter certeza de que tudo est\u00e1 funcionando? \u2014 N\u00e3o!<\/p>\n<ul>\n<li>Criar essas verifica\u00e7\u00f5es \u00e9, essencialmente, uma tarefa para os desenvolvedores. Testes unit\u00e1rios devem ser escritos por programadores que est\u00e3o criando o c\u00f3digo. Porque, se voc\u00ea passar isso para o administrador \u201cCara, aqui est\u00e1 a lista de protocolos da API de todas as 25 fun\u00e7\u00f5es, por favor, monitore tudo!\u201d \u2014 nada sair\u00e1 certo. <\/li>\n<li>Se voc\u00ea fizer print \u201chello world\u201d, ningu\u00e9m jamais saber\u00e1 que a API deveria e de fato est\u00e1 funcionando. Cada mudan\u00e7a na API deve levar \u00e0 modifica\u00e7\u00e3o das verifica\u00e7\u00f5es. <\/li>\n<li>Se voc\u00ea j\u00e1 est\u00e1 nessa situa\u00e7\u00e3o \u2013 pare as funcionalidades e aloque desenvolvedores para escrever essas verifica\u00e7\u00f5es, ou se conforma com as perdas, aceita que nada ser\u00e1 verificado e que cair\u00e1.<\/li>\n<\/ul>\n<p>\nDicas t\u00e9cnicas:<\/p>\n<ul>\n<li>Certifique-se de organizar um servidor externo para realizar as verifica\u00e7\u00f5es \u2014 voc\u00ea deve ter certeza de que seu projeto est\u00e1 acess\u00edvel para o mundo externo.<\/li>\n<li>Organize a verifica\u00e7\u00e3o em todo o protocolo da API, e n\u00e3o apenas em endpoints espec\u00edficos.<\/li>\n<li>Crie um endpoint prometheus com os resultados das verifica\u00e7\u00f5es.<\/li>\n<\/ul>\n<p><\/p>\n<h3>N\u00edvel de aplicativo \u2014 monitoramento de m\u00e9tricas de sa\u00fade<\/h3>\n<p>\nAgora falamos sobre m\u00e9tricas de sa\u00fade externas dos servi\u00e7os. <\/p>\n<p>Decidimos que todos os \u201cendpoints\u201d da aplica\u00e7\u00e3o devem ser monitorados com verifica\u00e7\u00f5es externas, que chamamos de um sistema de monitoramento externo. Mas s\u00e3o precisamente os \u201cendpoints\u201d que o usu\u00e1rio \u201cv\u00ea\u201d. Queremos ter certeza de que nossos servi\u00e7os est\u00e3o funcionando. Aqui a hist\u00f3ria \u00e9 um pouco melhor: no K8s existem verifica\u00e7\u00f5es de sa\u00fade para que pelo menos o pr\u00f3prio \u201ccubinho\u201d assegure que o servi\u00e7o est\u00e1 ativo. Mas metade das verifica\u00e7\u00f5es que vi \u00e9 a mesma impress\u00e3o de \u201chello world\u201d. Ou seja, ele chama uma vez ap\u00f3s a implanta\u00e7\u00e3o, recebe a confirma\u00e7\u00e3o de que est\u00e1 tudo bem \u2014 e \u00e9 isso. E um servi\u00e7o, se ele fornece sua API via REST, tem uma enorme quantidade de pontos de entrada dessa mesma API, que tamb\u00e9m precisam ser monitorados, porque queremos saber se est\u00e1 funcionando. E n\u00f3s o monitoramos internamente. <\/p>\n<p>Como implementar isso corretamente do ponto de vista t\u00e9cnico: cada servi\u00e7o deve expor um endpoint sobre seu estado atual, e nos gr\u00e1ficos do Grafana (ou de qualquer outra aplica\u00e7\u00e3o) vemos o status de todos os servi\u00e7os.<\/p>\n<ul>\n<li>Cada mudan\u00e7a na API deve resultar em uma mudan\u00e7a nas verifica\u00e7\u00f5es. <\/li>\n<li>Crie novos servi\u00e7os imediatamente com m\u00e9tricas de sa\u00fade.<\/li>\n<li>Um administrador pode se aproximar dos desenvolvedores e pedir \"adicionem algumas funcionalidades para que eu possa entender tudo e adicionar informa\u00e7\u00f5es sobre isso ao meu sistema de monitoramento\". Mas os desenvolvedores normalmente respondem: \"Duas semanas antes do lan\u00e7amento n\u00e3o vamos adicionar nada\".<br \/>\nDeixem os gerentes de desenvolvimento saberem que haver\u00e1 essas perdas, e que a ger\u00eancia dos gerentes de desenvolvimento tamb\u00e9m deve estar ciente. Porque, quando tudo falhar, algu\u00e9m vai ligar e exigir que monitoremos o \"servi\u00e7o que falha constantemente\" (c). <\/li>\n<li>A prop\u00f3sito, designem desenvolvedores para escrever plugins para o Grafana \u2014 isso ser\u00e1 uma grande ajuda para os administradores.<\/li>\n<\/ul>\n<p><\/p>\n<h3>N\u00edvel de aplica\u00e7\u00e3o \u2014 Monitoramento Integrado<\/h3>\n<p>\nO monitoramento integrado se concentra na fiscaliza\u00e7\u00e3o da comunica\u00e7\u00e3o entre sistemas cr\u00edticos para os neg\u00f3cios.<\/p>\n<p>Por exemplo, h\u00e1 15 servi\u00e7os que se comunicam entre si. Eles n\u00e3o s\u00e3o mais sites separados. Ou seja, n\u00e3o podemos apenas chamar um servi\u00e7o, obter \/helloworld e concluir que o servi\u00e7o est\u00e1 funcionando. Porque o servi\u00e7o de processamento de pedidos precisa enviar informa\u00e7\u00f5es do pedido para o barramento \u2014 ent\u00e3o, do barramento, o servi\u00e7o de gerenciamento de estoque deve receber essa mensagem e continuar a trabalhar com ela. E o servi\u00e7o de envio de e-mails deve processar isso de alguma forma, e assim por diante. <\/p>\n<p>Portanto, n\u00e3o conseguimos entender, clicando em cada servi\u00e7o individualmente, como tudo isso funciona. Porque temos um certo barramento, atrav\u00e9s do qual tudo se comunica e interage.<br \/>\nAssim, esta etapa deve representar o teste de servi\u00e7os em intera\u00e7\u00e3o com outros servi\u00e7os. N\u00e3o \u00e9 poss\u00edvel, ao monitorar um corretor de mensagens, estabelecer um monitoramento da comunica\u00e7\u00e3o. Se h\u00e1 um servi\u00e7o que fornece dados, e um servi\u00e7o que os recebe, ao monitorar o corretor, veremos apenas os dados que v\u00e3o de um lado para o outro. Mesmo que consigamos monitorar a intera\u00e7\u00e3o desses dados internamente \u2014 que um produtor publica dados, e algu\u00e9m os l\u00ea, esse fluxo continua indo para o Kafka \u2014 isso ainda n\u00e3o nos dar\u00e1 informa\u00e7\u00f5es, se um servi\u00e7o enviou uma mensagem em uma vers\u00e3o, e o outro servi\u00e7o n\u00e3o esperava essa vers\u00e3o e a perdeu. N\u00e3o saberemos disso, pois os servi\u00e7os nos dir\u00e3o que est\u00e1 tudo funcionando. <\/p>\n<p>Como eu recomendo fazer:<\/p>\n<ul>\n<li>Para comunica\u00e7\u00e3o s\u00edncrona: o endpoint executa solicita\u00e7\u00f5es a servi\u00e7os relacionados. Ou seja, pegamos este endpoint, executamos um script dentro do servi\u00e7o que percorre todos os pontos e diz 'posso chamar aqui, e posso chamar ali, posso chamar aqui...'<\/li>\n<li>Para comunica\u00e7\u00e3o ass\u00edncrona: mensagens de entrada \u2014 o endpoint verifica o barramento em busca de mensagens de teste e fornece o status do processamento. <\/li>\n<li>Para comunica\u00e7\u00e3o ass\u00edncrona: mensagens de sa\u00edda \u2014 o endpoint envia mensagens de teste para o barramento.<\/li>\n<\/ul>\n<p>\nComo geralmente acontece: temos um servi\u00e7o que envia dados para o barramento. Chegamos a esse servi\u00e7o e pedimos para ele nos contar sobre sua sa\u00fade de integra\u00e7\u00e3o. E se o servi\u00e7o deve produzir alguma mensagem para algum lugar (WebApp), ent\u00e3o ele produzir\u00e1 essa mensagem de teste. E se chamamos o servi\u00e7o do lado de OrderProcessing, ele primeiro publica o que pode publicar independente, e se h\u00e1 alguma coisa dependente \u2014 ele l\u00ea do barramento um conjunto de mensagens de teste, entende o que pode processar, informa sobre isso e, se necess\u00e1rio, publica adiante, e sobre isso ele diz \u2014 tudo ok, estou vivo. <\/p>\n<p>Muitas vezes ouvimos a pergunta \"como podemos testar isso com dados de produ\u00e7\u00e3o?\" Por exemplo, estamos falando do mesmo servi\u00e7o de pedidos. O pedido envia mensagens para o armaz\u00e9m, onde os produtos s\u00e3o removidos: n\u00e3o podemos testar isso com dados de produ\u00e7\u00e3o, porque \"os meus produtos ser\u00e3o removidos!\" A solu\u00e7\u00e3o: no in\u00edcio, planeje todo esse teste. Voc\u00ea j\u00e1 tem testes unit\u00e1rios que fazem mocks. Ent\u00e3o, fa\u00e7a isso em um n\u00edvel mais profundo, onde voc\u00ea ter\u00e1 um canal de comunica\u00e7\u00e3o que n\u00e3o prejudicar\u00e1 o funcionamento do neg\u00f3cio. <\/p>\n<h3>N\u00edvel de infraestrutura<\/h3>\n<p>\nO monitoramento da infraestrutura \u00e9 o que h\u00e1 muito \u00e9 considerado o pr\u00f3prio monitoramento. <\/p>\n<ul>\n<li>O monitoramento da infraestrutura pode e deve ser iniciado como um processo separado.<\/li>\n<li>N\u00e3o comece com o monitoramento da infraestrutura em um projeto em funcionamento, mesmo que voc\u00ea tenha muita vontade. \u00c9 uma dor de cabe\u00e7a para todos os DevOps. \"Primeiro vou monitorar o cluster, depois a infraestrutura\" - ou seja, ele vai monitorar o que est\u00e1 embaixo e n\u00e3o vai se preocupar com o aplicativo. Porque o aplicativo \u00e9 uma coisa confusa para o DevOps. Ele recebeu isso, mas n\u00e3o entende como funciona. E ele entende a infraestrutura e come\u00e7a por ela. Mas n\u00e3o \u2014 sempre \u00e9 preciso monitorar o aplicativo primeiro. <\/li>\n<li>N\u00e3o exagere na quantidade de alertas. Considerando a complexidade dos sistemas modernos, os alertas est\u00e3o constantemente chegando, e \u00e9 preciso conviver com essa avalanche. E a pessoa de plant\u00e3o, ao olhar para uma centena de alertas, decidir\u00e1 \"n\u00e3o quero pensar sobre isso\". Os alertas devem notificar apenas sobre coisas cr\u00edticas. <\/li>\n<\/ul>\n<p><\/p>\n<h3>N\u00edvel do aplicativo como unidade de neg\u00f3cio<\/h3>\n<p>\nPontos-chave:<\/p>\n<ul>\n<li>ELK. Este \u00e9 um padr\u00e3o da ind\u00fastria. Se, por algum motivo, voc\u00ea n\u00e3o est\u00e1 agregando logs, comece a faz\u00ea-lo urgentemente.<\/li>\n<li>APM. APM externos como uma forma de rapidamente cobrir o monitoramento do aplicativo (NewRelic, BlackFire, Datadog). Voc\u00ea pode instalar temporariamente essa ferramenta para entender o que est\u00e1 acontecendo. <\/li>\n<li>Tracing. Em dezenas de microsservi\u00e7os, voc\u00ea deve rastrear tudo, porque a solicita\u00e7\u00e3o j\u00e1 n\u00e3o vive sozinha. Adicionar depois \u00e9 muito dif\u00edcil, ent\u00e3o \u00e9 melhor planejar o tracing no desenvolvimento desde o in\u00edcio \u2014 isso \u00e9 um trabalho e uma ferramenta para os desenvolvedores. Se ainda n\u00e3o implantou, comece a implementar! Veja Jaeger\/Zipkin.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Alertando<\/h3>\n<p><\/p>\n<ul>\n<li>Organiza\u00e7\u00e3o do sistema de notifica\u00e7\u00f5es: em um ambiente de monitoramento de v\u00e1rias coisas, deve haver um sistema unificado de envio de alertas. Isso pode ser feito no Grafana. No Ocidente, todos usam o PagerDuty. Os avisos devem ser claros (por exemplo, de onde eles v\u00eam...). E \u00e9 desej\u00e1vel controlar se as notifica\u00e7\u00f5es est\u00e3o realmente chegando. <\/li>\n<li>Organiza\u00e7\u00e3o do sistema de plant\u00f5es: os alertas n\u00e3o devem ser enviados a todos (caso contr\u00e1rio, todos reagir\u00e3o em grupo ou ningu\u00e9m reagir\u00e1). Os desenvolvedores tamb\u00e9m precisam estar em plant\u00e3o: defina claramente as \u00e1reas de responsabilidade, elabore instru\u00e7\u00f5es claras e especifique a quem exatamente ligar na segunda e na quarta-feira, e a quem \u2014 na ter\u00e7a e na sexta (caso contr\u00e1rio, ningu\u00e9m far\u00e1 liga\u00e7\u00f5es, mesmo em caso de grande emerg\u00eancia \u2014 as pessoas t\u00eam medo de acordar ou incomodar os outros: elas realmente n\u00e3o gostam de ligar e acordar outras pessoas, especialmente \u00e0 noite). E explique que pedir ajuda n\u00e3o \u00e9 um sinal de incompet\u00eancia (\"eu estou pedindo ajuda \u2014 ent\u00e3o sou um mal trabalhador\"), incentive os pedidos de ajuda.<\/li>\n<li>Organiza\u00e7\u00e3o de uma \"base de conhecimento\" e fluxo de trabalho para tratamento de incidentes: para cada incidente s\u00e9rio, deve haver um post-mortem planejado. Como medida tempor\u00e1ria, as a\u00e7\u00f5es que resolvem o incidente devem ser documentadas. E crie a pr\u00e1tica de que alertas repetidos s\u00e3o um pecado; eles devem ser corrigidos no c\u00f3digo ou nas opera\u00e7\u00f5es de infraestrutura. <\/li>\n<\/ul>\n<p><\/p>\n<h3>Pilha tecnol\u00f3gica<\/h3>\n<p>\nVamos imaginar que nossa pilha \u00e9 a seguinte: <\/p>\n<ul>\n<li>coleta de dados \u2014 Prometheus + Grafana;<\/li>\n<li>an\u00e1lise de logs \u2014 ELK;<\/li>\n<li>para APM ou Tracing \u2014 Jaeger (Zipkin).<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"Monitoramento inativo? \u2014 Viva o monitoramento\" src=\"\/wp-content\/uploads\/2019\/04\/af26d3c0ba781cd856d220515788b5eb.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nA escolha das op\u00e7\u00f5es n\u00e3o \u00e9 cr\u00edtica. Porque, se voc\u00ea entendeu desde o in\u00edcio como monitorar o sistema e elaborou um plano, a partir da\u00ed voc\u00ea come\u00e7a a escolher as ferramentas de acordo com suas necessidades. A quest\u00e3o \u00e9 o que voc\u00ea escolheu monitorar inicialmente. Porque, talvez, a ferramenta que voc\u00ea escolheu no come\u00e7o n\u00e3o se encaixe nas suas necessidades. <\/p>\n<p>Alguns pontos t\u00e9cnicos que vejo em todo lugar ultimamente:<\/p>\n<p><i>Prometheus sendo inserido dentro do Kubernetes \u2014 quem teve essa ideia?!<\/i> Se o seu cluster cair, o que voc\u00ea far\u00e1? Se voc\u00ea tiver um cluster complexo por dentro, deve haver algum sistema de monitoramento dentro do cluster, e um outro \u2014 por fora, que colete dados do interior do cluster. <\/p>\n<p><i>Dentro do cluster, coletamos logs e todo o resto.<\/i> Mas o sistema de monitoramento deve estar externo. Muito frequentemente em um cluster onde h\u00e1 Prometheus instalado internamente, existem sistemas que realizam verifica\u00e7\u00f5es externas do funcionamento do site. E se suas conex\u00f5es com o mundo externo ca\u00edrem e o aplicativo n\u00e3o funcionar? Aparentemente, tudo est\u00e1 bem internamente, mas isso n\u00e3o ajuda os usu\u00e1rios.<\/p>\n<h3>Como resultado, obtemos um servi\u00e7o de \"monitoramento como servi\u00e7o\", automatizado na linha de produ\u00e7\u00e3o de integra\u00e7\u00e3o cont\u00ednua. O desenvolvedor ou testador precisa apenas definir a lista de m\u00e9tricas em um arquivo JSON, e tudo o mais acontece automaticamente. Obtemos um controle de qualidade transparente dos lan\u00e7amentos: todas as notifica\u00e7\u00f5es sobre desempenho, consumo de recursos ou regress\u00f5es arquitet\u00f4nicas.<\/h3>\n<p><\/p>\n<ul>\n<li>Desenvolver um monitoramento n\u00e3o \u00e9 apenas instalar utilit\u00e1rios, mas sim desenvolver um produto de software. 98% do monitoramento atual \u00e9 codifica\u00e7\u00e3o. Codifica\u00e7\u00e3o em servi\u00e7os, codifica\u00e7\u00e3o de verifica\u00e7\u00f5es externas, verifica\u00e7\u00f5es de servi\u00e7os externos, e tudo mais. <\/li>\n<li>N\u00e3o economize o tempo dos desenvolvedores em monitoramento: isso pode consumir at\u00e9 30% do trabalho deles, mas vale a pena.<\/li>\n<li>DevOps, n\u00e3o se preocupe se voc\u00eas n\u00e3o conseguem monitorar algumas coisas, porque certos aspectos exigem uma mentalidade completamente diferente. Voc\u00eas n\u00e3o foram programadores, e o trabalho de monitoramento \u00e9 exatamente deles.<\/li>\n<li>Se o projeto j\u00e1 estiver em funcionamento e n\u00e3o estiver monitorado (e voc\u00ea \u00e9 o gerente) \u2014 direcione recursos para o monitoramento.<\/li>\n<li>Se o produto j\u00e1 est\u00e1 em produ\u00e7\u00e3o e voc\u00ea \u00e9 um devops que recebeu a tarefa de \"configurar o monitoramento\" \u2014 tente explicar \u00e0 ger\u00eancia o que eu escrevi aqui.<\/li>\n<\/ul>\n<p>\n<i>Esta \u00e9 uma vers\u00e3o estendida da apresenta\u00e7\u00e3o na confer\u00eancia Saint Highload++.<\/i><\/p>\n<p>Se voc\u00ea est\u00e1 interessado nas minhas ideias e reflex\u00f5es sobre TI e temas relacionados, aqui voc\u00ea pode <noindex><a rel=\"nofollow\" href=\"https:\/\/t.me\/eapotapov_channel\">ler o canal <\/a><\/noindex>\ud83d\ude42<br \/>\n<br \/>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/itsumma\/blog\/448602\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041d\u0430\u0448\u0430 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f \u0441 2008 \u0433\u043e\u0434\u0430 \u0437\u0430\u043d\u0438\u043c\u0430\u0435\u0442\u0441\u044f \u043f\u0440\u0435\u0438\u043c\u0443\u0449\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u043e \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u0435\u043c \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0430\u043c\u0438 \u0438 \u043a\u0440\u0443\u0433\u043b\u043e\u0441\u0443\u0442\u043e\u0447\u043d\u043e\u0439 \u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u043e\u0439 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u043e\u0439 \u0432\u0435\u0431-\u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432: \u0443 \u043d\u0430\u0441 \u0431\u043e\u043b\u0435\u0435 400 \u043a\u043b\u0438\u0435\u043d\u0442\u043e\u0432, \u044d\u0442\u043e \u043f\u043e\u0440\u044f\u0434\u043a\u0430 15% \u044d\u043b\u0435\u043a\u0442\u0440\u043e\u043d\u043d\u043e\u0439 \u043a\u043e\u043c\u043c\u0435\u0440\u0446\u0438\u0438 \u0420\u043e\u0441\u0441\u0438\u0438. \u0421\u043e\u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0435\u043d\u043d\u043e, \u043d\u0430 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0435 \u043e\u0447\u0435\u043d\u044c \u0440\u0430\u0437\u043d\u043e\u043e\u0431\u0440\u0430\u0437\u043d\u0430\u044f \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0430. \u0415\u0441\u043b\u0438 \u0447\u0442\u043e-\u0442\u043e \u043f\u0430\u0434\u0430\u0435\u0442, \u043c\u044b \u043e\u0431\u044f\u0437\u0430\u043d\u044b \u0432 \u0442\u0435\u0447\u0435\u043d\u0438\u0435 15 \u043c\u0438\u043d\u0443\u0442 \u044d\u0442\u043e \u043f\u043e\u0447\u0438\u043d\u0438\u0442\u044c. \u041d\u043e \u0447\u0442\u043e\u0431\u044b \u043f\u043e\u043d\u044f\u0442\u044c, \u0447\u0442\u043e \u0430\u0432\u0430\u0440\u0438\u044f \u043f\u0440\u043e\u0438\u0437\u043e\u0448\u043b\u0430, \u043d\u0443\u0436\u043d\u043e \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u0442\u044c \u043f\u0440\u043e\u0435\u043a\u0442 \u0438 \u0440\u0435\u0430\u0433\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u043d\u0430 \u0438\u043d\u0446\u0438\u0434\u0435\u043d\u0442\u044b. [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":23731,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-31864","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/monitoring-myortv-da-zdravstvuet-monitoring\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"pt_PT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433 \u043c\u0451\u0440\u0442\u0432? \u2014 \u0414\u0430 \u0437\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0435\u0442 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433 | ProHoster\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/monitoring-myortv-da-zdravstvuet-monitoring\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:43:33+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:43:33+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Monitoramento morto? \u2014 Viva o monitoramento | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/monitoring-myortv-da-zdravstvuet-monitoring","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433 \u043c\u0451\u0440\u0442\u0432? \u2014 \u0414\u0430 \u0437\u0434\u0440\u0430\u0432\u0441\u0442\u0432\u0443\u0435\u0442 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433 | ProHoster","og:url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/monitoring-myortv-da-zdravstvuet-monitoring","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:43:33+00:00","article:modified_time":"2019-10-31T18:43:33+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"31864","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-02-09 17:01:09","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 03:09:27","updated":"2026-02-09 17:01:09","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/31864","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=31864"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/31864\/revisions"}],"predecessor-version":[{"id":158558,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/31864\/revisions\/158558"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/23731"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=31864"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=31864"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=31864"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}