{"id":33632,"date":"2019-10-31T21:53:52","date_gmt":"2019-10-31T18:53:52","guid":{"rendered":"https:\/\/prohoster.info\/blog\/eshhe-odna-sistema-monitoringa\/"},"modified":"2019-10-31T21:53:52","modified_gmt":"2019-10-31T18:53:52","slug":"eshhe-odna-sistema-monitoringa","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/eshhe-odna-sistema-monitoringa","title":{"rendered":"Mais um sistema de monitoramento","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Mais
\n16 modems, 4 operators de celular = Velocidade de upload 933,45 Mbit\/s<\/em> <\/p>\n

<\/p>\n

Introdu\u00e7\u00e3o<\/h2>\n

<\/p>\n

Ol\u00e1! Este \u00e9 um artigo sobre como escrevemos um novo sistema de monitoramento para n\u00f3s. Ele se diferencia dos existentes pela capacidade de obter m\u00e9tricas de forma s\u00edncrona e em alta frequ\u00eancia, com um consumo de recursos muito baixo. A frequ\u00eancia de consulta pode atingir 0,1 milissegundos com precis\u00e3o de sincroniza\u00e7\u00e3o entre as m\u00e9tricas de 10 nanossegundos. Todos os arquivos bin\u00e1rios ocupam 6 megabytes. <\/p>\n

<\/a><\/noindex><\/p>\n

Sobre o projeto<\/h2>\n

<\/p>\n

Temos um produto bastante espec\u00edfico. Produzimos uma solu\u00e7\u00e3o integrada para somar a capacidade e a resili\u00eancia de canais de transmiss\u00e3o de dados. Isso ocorre quando existem v\u00e1rios canais, digamos Operador1 (40Mbps) + Operador2 (30Mbps) + Algo mais (5Mbps), resultando em um \u00fanico canal est\u00e1vel e r\u00e1pido, cuja velocidade ser\u00e1 aproximadamente assim: (40+30+5)x0.92=75\u00d70.92=69 Mbps. <\/p>\n

<\/p>\n

Essas solu\u00e7\u00f5es s\u00e3o demandadas onde a capacidade de um \u00fanico canal \u00e9 insuficiente. Por exemplo, transporte, sistemas de videovigil\u00e2ncia e transmiss\u00e3o de v\u00eddeo em tempo real, transmiss\u00e3o ao vivo de programas de r\u00e1dio e TV, e em qualquer propriedade rural onde os provedores de servi\u00e7os s\u00e3o apenas as grandes operadoras e a velocidade em um modem\/canal \u00e9 inadequada.
\nPara cada uma dessas \u00e1reas, lan\u00e7amos uma linha exclusiva de dispositivos, no entanto, a parte de software deles \u00e9 quase id\u00eantica, e um sistema de monitoramento de qualidade \u00e9 um dos principais m\u00f3dulos, sem a implementa\u00e7\u00e3o correta da qual o produto n\u00e3o seria vi\u00e1vel.<\/p>\n

<\/p>\n

Em poucos anos, conseguimos criar um sistema de monitoramento multilayer, r\u00e1pido, multiplataforma e leve. \u00c9 isso que queremos compartilhar com a respeit\u00e1vel comunidade.<\/p>\n

<\/p>\n

Formula\u00e7\u00e3o do problema<\/h2>\n

<\/p>\n

O sistema de monitoramento fornece m\u00e9tricas de dois tipos fundamentalmente diferentes: m\u00e9tricas em tempo real e todas as outras. As seguintes exig\u00eancias foram estabelecidas para o sistema de monitoramento:<\/p>\n

<\/p>\n

    \n
  1. Obten\u00e7\u00e3o s\u00edncrona de m\u00e9tricas em tempo real e transmiss\u00e3o para o sistema de gerenciamento de comunica\u00e7\u00e3o sem atrasos.
    \nAlta frequ\u00eancia e sincroniza\u00e7\u00e3o de diferentes m\u00e9tricas n\u00e3o s\u00e3o apenas importantes, s\u00e3o vitalmente necess\u00e1rias para a an\u00e1lise da entropia dos canais de transmiss\u00e3o de dados. Se em um canal de transmiss\u00e3o de dados a lat\u00eancia m\u00e9dia \u00e9 de 30 milissegundos, um erro de sincroniza\u00e7\u00e3o entre as outras m\u00e9tricas de apenas um milissegundo levar\u00e1 \u00e0 degrada\u00e7\u00e3o da velocidade do canal resultante em cerca de 5%. Se errarmos na sincroniza\u00e7\u00e3o em 1 milissegundo em 4 canais, a degrada\u00e7\u00e3o da velocidade pode cair facilmente at\u00e9 30%. Al\u00e9m disso, a entropia nos canais muda muito rapidamente, ent\u00e3o, se medirmos com menos frequ\u00eancia do que uma vez a cada 0,5 milissegundos, em canais r\u00e1pidos com baixa lat\u00eancia, obteremos uma alta degrada\u00e7\u00e3o da velocidade. \u00c9 claro que tal precis\u00e3o n\u00e3o \u00e9 necess\u00e1ria para todas as m\u00e9tricas e em todas as condi\u00e7\u00f5es. Quando a lat\u00eancia no canal for de 500 milissegundos, e estamos lidando com tais casos, um erro de 1 milissegundo quase n\u00e3o ser\u00e1 percept\u00edvel. Al\u00e9m disso, para m\u00e9tricas de sistemas de suporte \u00e0 vida, precisamos de uma frequ\u00eancia de amostragem e sincroniza\u00e7\u00e3o de 2 segundos, contudo, o pr\u00f3prio sistema de monitoramento deve ser capaz de operar com frequ\u00eancias de amostragem extremamente altas e sincroniza\u00e7\u00e3o extremamente precisa de m\u00e9tricas.<\/li>\n
  2. M\u00ednimo consumo de recursos e uma \u00fanica pilha.
    \nO dispositivo final pode ser tanto um poderoso complexo embarcado, capaz de analisar a situa\u00e7\u00e3o na estrada ou realizar a captura biom\u00e9trica de pessoas, quanto um computador de placa \u00fanica do tamanho de uma palma, que um soldado de opera\u00e7\u00f5es especiais transporta sob o colete \u00e0 prova de balas para transmitir v\u00eddeo em tempo real em condi\u00e7\u00f5es de m\u00e1 conex\u00e3o. Apesar dessa diversidade de arquiteturas e capacidades computacionais, gostar\u00edamos de ter uma pilha de software uniforme.<\/li>\n
  3. Arquitetura em camadas
    \nAs m\u00e9tricas devem ser coletadas e agregadas no dispositivo final, ter um sistema local de armazenamento e visualiza\u00e7\u00e3o em tempo real e retrospectiva. Em caso de conex\u00e3o, os dados devem ser enviados para o sistema de monitoramento central. Quando n\u00e3o h\u00e1 conex\u00e3o, a fila de envio deve ser acumulada e n\u00e3o consumir mem\u00f3ria operacional. <\/li>\n
  4. API para integra\u00e7\u00e3o no sistema de monitoramento do cliente, pois ningu\u00e9m precisa de muitos sistemas de monitoramento. O cliente deve coletar dados de quaisquer dispositivos e redes em um \u00fanico monitoramento.<\/li>\n<\/ol>\n

    <\/p>\n

    O que foi produzido<\/h2>\n

    <\/p>\n

    Para n\u00e3o sobrecarregar este extenso artigo, n\u00e3o fornecerei exemplos e medi\u00e7\u00f5es de todos os sistemas de monitoramento. Isso requereria outro artigo. Apenas direi que n\u00e3o conseguimos encontrar um sistema de monitoramento que consiga capturar duas m\u00e9tricas simultaneamente com uma margem de erro inferior a 1 milissegundo e que funcione de forma igualmente eficaz tanto na arquitetura ARM com 64 MB de RAM quanto na arquitetura x86_64 com 32 GB de RAM. Portanto, decidimos escrever o nosso pr\u00f3prio, que faz tudo isso. Aqui est\u00e1 o que conseguimos:<\/p>\n

    <\/p>\n

    Soma da largura de banda de tr\u00eas canais para diferentes topologias de rede<\/h3>\n

    \n

    \r\n \"Por\r\n
    <\/div>\r\n <\/div><\/center>
    \n
    \r\n \"Por\r\n
    <\/div>\r\n <\/div><\/center><\/p>\n

    Visualiza\u00e7\u00e3o de algumas m\u00e9tricas-chave<\/h3>\n

    \n\"Mais
    \n\"Mais
    \n\"Mais
    \n\"Mais<\/p>\n

    Arquitetura<\/h2>\n

    <\/p>\n

    Como linguagem de programa\u00e7\u00e3o principal, tanto no dispositivo quanto no data center, usamos Golang. Isso simplificou bastante a vida com sua implementa\u00e7\u00e3o de multitarefa e a possibilidade de obter um \u00fanico arquivo bin\u00e1rio execut\u00e1vel estaticamente vinculado para cada servi\u00e7o. Como resultado, economizamos significativamente em recursos, m\u00e9todos e tr\u00e1fego de implanta\u00e7\u00e3o do servi\u00e7o em dispositivos finais, al\u00e9m de tempo de desenvolvimento e depura\u00e7\u00e3o de c\u00f3digo. <\/p>\n

    <\/p>\n

    O sistema \u00e9 implementado de acordo com o princ\u00edpio modular cl\u00e1ssico e cont\u00e9m v\u00e1rias subsistemas:<\/p>\n

    <\/p>\n

      \n
    1. Registro de m\u00e9tricas.
      \nCada m\u00e9trica \u00e9 gerenciada por sua pr\u00f3pria thread e sincronizada atrav\u00e9s de canais. Conseguimos alcan\u00e7ar uma precis\u00e3o de sincroniza\u00e7\u00e3o de at\u00e9 10 nanosegundos.<\/li>\n
    2. Armazenamento de m\u00e9tricas
      \nN\u00f3s est\u00e1vamos decidindo entre criar nosso pr\u00f3prio armazenamento para s\u00e9ries temporais ou usar algo existente. O banco de dados \u00e9 necess\u00e1rio para dados retrospectivos que ser\u00e3o utilizados posteriormente para visualiza\u00e7\u00e3o. Ou seja, n\u00e3o cont\u00e9m dados de lat\u00eancia no canal a cada 0,5 milissegundos ou leituras de erros na rede de transporte, mas sim a velocidade em cada interface a cada 500 milissegundos. Al\u00e9m dos altos requisitos de compatibilidade entre plataformas e baixo consumo de recursos, \u00e9 extremamente importante para n\u00f3s ter a capacidade de processar os dados onde eles s\u00e3o armazenados. Isso economiza drasticamente recursos computacionais. Desde 2016, usamos o SGBD Tarantool neste projeto e, por enquanto, n\u00e3o vemos uma substitui\u00e7\u00e3o \u00e0 vista. \u00c9 flex\u00edvel, com consumo otimizado de recursos e suporte t\u00e9cnico mais do que adequado. O Tarantool tamb\u00e9m implementou um m\u00f3dulo GIS. Claro, n\u00e3o \u00e9 t\u00e3o poderoso quanto o PostGIS, mas \u00e9 suficiente para nossas necessidades de armazenamento de algumas m\u00e9tricas relacionadas \u00e0 localiza\u00e7\u00e3o (relevante para transporte). <\/li>\n
    3. Visualiza\u00e7\u00e3o de m\u00e9tricas
      \nAqui tudo \u00e9 relativamente simples. Pegamos os dados do armazenamento e os exibimos em tempo real ou retrospectivamente. <\/li>\n
    4. Sincroniza\u00e7\u00e3o de dados com o sistema central de monitoramento.
      \nO sistema central de monitoramento coleta dados de todos os dispositivos, os armazena com uma retrospectiva definida e os entrega ao sistema de monitoramento do Cliente atrav\u00e9s de API. Diferente dos sistemas cl\u00e1ssicos de monitoramento, onde a 'cabe\u00e7a' vai e coleta os dados \u2014 n\u00f3s temos o esquema inverso. Os dispositivos enviam os dados por conta pr\u00f3pria quando h\u00e1 conex\u00e3o. Este \u00e9 um ponto muito importante, pois permite obter dados do dispositivo durante os per\u00edodos em que ele estava indispon\u00edvel, sem sobrecarregar canais e recursos quando o dispositivo n\u00e3o est\u00e1 acess\u00edvel. Como sistema central de monitoramento, utilizamos o servidor de monitoramento Influx. Ao contr\u00e1rio de seus semelhantes, ele consegue importar dados retrospectivos (ou seja, com um carimbo de tempo diferente do momento em que a m\u00e9trica \u00e9 recebida). As m\u00e9tricas coletadas s\u00e3o visualizadas pelo Grafana, que foi aprimorado. Este stack padr\u00e3o foi escolhido tamb\u00e9m porque possui APIs de integra\u00e7\u00e3o prontas para praticamente qualquer sistema de monitoramento do cliente.<\/li>\n
    5. Sincroniza\u00e7\u00e3o de dados com o sistema central de gest\u00e3o de dispositivos.
      \nO sistema de gerenciamento de dispositivos implementa o Zero Touch Provisioning (atualiza\u00e7\u00e3o de firmware, configura\u00e7\u00e3o, etc.) e, ao contr\u00e1rio do sistema de monitoramento, recebe apenas problemas relacionados aos dispositivos. Esses s\u00e3o os gatilhos para o funcionamento dos servi\u00e7os de vigil\u00e2ncia de hardware a bordo e todas as m\u00e9tricas dos sistemas de suporte \u00e0 vida: temperatura da CPU e SSD, carga da CPU, espa\u00e7o livre e a sa\u00fade S.M.A.R.T nos discos. O armazenamento da subsistema \u00e9 tamb\u00e9m baseado no Tarantool. Isso nos proporciona uma velocidade significativa na agrega\u00e7\u00e3o de s\u00e9ries temporais por milhares de dispositivos, al\u00e9m de resolver completamente a quest\u00e3o da sincroniza\u00e7\u00e3o de dados com esses dispositivos. O Tarantool possui um excelente sistema de filas e entrega garantida. Essa importante funcionalidade n\u00f3s recebemos pronta, excelente!<\/li>\n<\/ol>\n

      <\/p>\n

      Sistema de gerenciamento de rede<\/h3>\n

      \n\"Mais<\/p>\n

      O que vem a seguir<\/h2>\n

      <\/p>\n

      At\u00e9 agora, o elo mais fraco \u00e9 o sistema central de monitoramento. Ele \u00e9 implementado em 99,9% com um stack padr\u00e3o e tem uma s\u00e9rie de desvantagens:<\/p>\n

      <\/p>\n

        \n
      1. O InfluxDB perde dados em caso de desligamento. Normalmente, o cliente retira rapidamente tudo o que chega dos dispositivos e no pr\u00f3prio banco de dados n\u00e3o h\u00e1 dados com mais de 5 minutos, no entanto, isso pode se tornar um problema no futuro.<\/li>\n
      2. O Grafana tem uma s\u00e9rie de problemas com a agrega\u00e7\u00e3o de dados e a sincroniza\u00e7\u00e3o de sua exibi\u00e7\u00e3o. O problema mais comum \u00e9 quando h\u00e1 uma s\u00e9rie temporal na base com um intervalo de 2 segundos come\u00e7ando, digamos, \u00e0s 00:00:00, e o Grafana come\u00e7a a mostrar os dados na agrega\u00e7\u00e3o com +1 segundo. Como resultado, o usu\u00e1rio v\u00ea um gr\u00e1fico oscilante.<\/li>\n
      3. Uma quantidade excessiva de c\u00f3digo para a integra\u00e7\u00e3o da API com sistemas de monitoramento externos. Pode ser feito de forma muito mais compacta e, claro, reescrito em Go)<\/li>\n<\/ol>\n

        <\/p>\n

        Acredito que todos voc\u00eas j\u00e1 viram como o Grafana se parece e, sem mim, conhecem seus problemas, ent\u00e3o n\u00e3o irei sobrecarregar o post com imagens.<\/p>\n

        <\/p>\n

        Conclus\u00e3o<\/h2>\n

        <\/p>\n

        Decidi n\u00e3o descrever os detalhes t\u00e9cnicos, mas apenas comentar sobre o design de refer\u00eancia desse sistema. Primeiro, para descrever tecnicamente o sistema, seria necess\u00e1rio um artigo adicional. Em segundo lugar, nem todos estar\u00e3o interessados. Escrevam nos coment\u00e1rios quais detalhes t\u00e9cnicos voc\u00eas gostariam de saber. <\/p>\n

        <\/p>\n

        Se algu\u00e9m tiver perguntas al\u00e9m deste artigo, podem me escrever para o endere\u00e7o a.rodin @ qedr.com<\/p>\n

        Fonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

        16 \u043c\u043e\u0434\u0435\u043c\u043e\u0432, 4 \u0441\u043e\u0442\u043e\u0432\u044b\u0445 \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440\u0430= \u0418\u0441\u0445\u043e\u0434\u044f\u0449\u0430\u044f \u0441\u043a\u043e\u0440\u043e\u0441\u0442\u044c 933.45 \u041c\u0431\u0438\u0442\/\u0441 \u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u041f\u0440\u0438\u0432\u0435\u0442! \u042d\u0442\u043e \u0441\u0442\u0430\u0442\u044c\u044f \u043f\u0440\u043e \u0442\u043e, \u043a\u0430\u043a \u043c\u044b \u043d\u0430\u043f\u0438\u0441\u0430\u043b\u0438 \u0434\u043b\u044f \u0441\u0435\u0431\u044f \u043d\u043e\u0432\u0443\u044e \u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430. \u041e\u0442 \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445 \u043e\u043d\u0430 \u043e\u0442\u043b\u0438\u0447\u0430\u0435\u0442\u0441\u044f \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c\u044e \u0432\u044b\u0441\u043e\u043a\u043e\u0447\u0430\u0441\u0442\u043e\u0442\u043d\u043e\u0433\u043e \u0441\u0438\u043d\u0445\u0440\u043e\u043d\u043d\u043e\u0433\u043e \u043f\u043e\u043b\u0443\u0447\u0435\u043d\u0438\u044f \u043c\u0435\u0442\u0440\u0438\u043a \u0438 \u043e\u0447\u0435\u043d\u044c \u043c\u0430\u043b\u0435\u043d\u044c\u043a\u0438\u043c \u043f\u043e\u0442\u0440\u0435\u0431\u043b\u0435\u043d\u0438\u0435\u043c \u0440\u0435\u0441\u0443\u0440\u0441\u043e\u0432. \u0427\u0430\u0441\u0442\u043e\u0442\u0430 \u043e\u043f\u0440\u043e\u0441\u0430 \u043c\u043e\u0436\u0435\u0442 \u0434\u043e\u0441\u0442\u0438\u0433\u0430\u0442\u044c 0.1 \u043c\u0438\u043b\u043b\u0438\u0441\u0435\u043a\u0443\u043d\u0434\u044b \u0441 \u0442\u043e\u0447\u043d\u043e\u0441\u0442\u044c\u044e \u0441\u0438\u043d\u0445\u0440\u043e\u043d\u0438\u0437\u0430\u0446\u0438\u0438 \u043c\u0435\u0436\u0434\u0443 \u043c\u0435\u0442\u0440\u0438\u043a\u0430\u043c\u0438 \u0432 10 \u043d\u0430\u043d\u043e\u0441\u0435\u043a\u0443\u043d\u0434. \u0412\u0441\u0435 \u0431\u0438\u043d\u0430\u0440\u043d\u044b\u0435 \u0444\u0430\u0439\u043b\u044b \u0437\u0430\u043d\u0438\u043c\u0430\u044e\u0442 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":25323,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-33632","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47 Outro sistema de monitoramento | ProHoster","description":"16 modems, 4 operadores m\u00f3veis = Velocidade de sa\u00edda 933.45.","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/eshhe-odna-sistema-monitoringa","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\u0415\u0449\u0435 \u043e\u0434\u043d\u0430 \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 | ProHoster","og:description":"16 \u043c\u043e\u0434\u0435\u043c\u043e\u0432, 4 \u0441\u043e\u0442\u043e\u0432\u044b\u0445 \u043e\u043f\u0435\u0440\u0430\u0442\u043e\u0440\u0430= \u0418\u0441\u0445\u043e\u0434\u044f\u0449\u0430\u044f \u0441\u043a\u043e\u0440\u043e\u0441\u0442\u044c 933.45.","og:url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/eshhe-odna-sistema-monitoringa","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:53:52+00:00","article:modified_time":"2019-10-31T18:53:52+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"33632","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-01-21 16:05:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:19:51","updated":"2026-01-21 16:05:20","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\/33632","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=33632"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/33632\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/25323"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=33632"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=33632"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=33632"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}