Monitoramento é um processo de controle e gerenciamento de desempenho e disponibilidade de aplicações de software.
Em ambientes que utilizam InterSystems IRIS, os globals são a base física do armazenamento de dados. Apesar de existirem consultas de sistema e ferramentas administrativas para inspeção de métricas, a análise de crescimento de globals costuma ser reativa: o problema geralmente é percebido apenas quando há pressão de disco ou impacto de performance.
O APM normalmente se concentra na atividade da aplicação, mas coletar informações sobre o uso do sistema fornece dados de contexto importantes que ajudam a entender e gerenciar o desempenho da sua aplicação, portanto estou incluindo o Monitor de Histórico do IRIS nesta série.
Neste artigo, descreverei brevemente como iniciar o Monitor de Histórico do IRIS ou Caché para criar um registro da atividade em nível de sistema, complementando as informações de atividade e desempenho da aplicação que você coleta. Também apresentarei exemplos de SQL para acessar as informações.
Uma coisa que aprendi ao longo dos anos é que, não importa o quão aprimorada seja a lógica do seu aplicativo, o desempenho do banco de dados acabará por determinar o sucesso ou fracasso da experiência do usuário. Trabalhando com o InterSystems IRIS, recentemente vivenciei isso em primeira mão. Um de nossos clientes estava construindo um painel de relatórios que funcionava perfeitamente durante os testes, mas assim que o conjunto de dados de produção cresceu para milhões, os tempos de resposta ficaram extremamente lentos.
À primeira vista, parecia um problema de hardware.
O desempenho do banco de dados tornou-se um fator crítico de sucesso em um ambiente de aplicações moderno. Portanto, identificar e otimizar as consultas SQL que consomem mais recursos é essencial para garantir uma experiência de usuário fluida e manter a estabilidade da aplicação.
Este artigo explorará uma abordagem rápida para analisar as estatísticas de execução de consultas SQL em uma instância InterSystems IRIS para identificar áreas de otimização dentro de uma macro-aplicação.
Em vez de focar no monitoramento em tempo real, configuraremos um sistema que coleta e analisa estatísticas pré-calculadas pelo IRIS uma vez por hora. Essa abordagem, embora não permita o monitoramento instantâneo, oferece um excelente compromisso entre a riqueza de dados disponíveis e a simplicidade de implementação.
Usaremos o Grafana para visualização e análise de dados, o InfluxDB para armazenamento de séries temporais e o Telegraf para coleta de métricas. Essas ferramentas, reconhecidas por seu poder e flexibilidade, nos permitirão obter uma visão clara e explorável.
Mais especificamente, detalharemos a configuração do Telegraf para recuperar estatísticas. Também configuraremos a integração com o InfluxDB para armazenamento e análise de dados, e criaremos dashboards personalizados no Grafana. Isso nos ajudará a identificar rapidamente as consultas que exigem atenção especial.
Para facilitar a orquestração e o deploy desses vários componentes, empregaremos o Docker.
Em posts anteriores, mostrei como é possível coletar métricas de desempenho histórico usando pButtons. Recorro ao pButtons primeiro porque sei que ele é instalado com todas as instâncias de Plataformas de Dados (Ensemble, Caché, .).
Monitorar sua implantação do IRIS é crucial. Com a descontinuação do System Alert and Monitoring (SAM), uma solução moderna e escalável é necessária para obter insights em tempo real, detecção precoce de problemas e eficiência operacional. Este guia aborda a configuração do Prometheus e Grafana no Kubernetes para monitorar o InterSystems IRIS de forma eficaz.
Este guia pressupõe que você já tenha um cluster IRIS implantado usando o InterSystems Kubernetes Operator (IKO), que simplifica a implantação, integração e gerenciamento.
.png)
.png)
Então, se você está acompanhando do post anterior ou entrando agora, vamos passar para o mundo dos aplicativos eBPF e dar uma olhada no Parca, que se baseia em nossa breve investigação de gargalos de desempenho usando eBPF, mas coloca um aplicativo incrível no topo do seu cluster para monitorar todas as suas cargas de trabalho iris, continuamente, em todo o cluster!
.png)
Perfilamento Contínuo com Parca, Cargas de Trabalho IRIS em Todo o Cluster
.png)
Eu estive na Cloud Native Security Con em Seattle com total intenção de entrar no dia de OTEL, então lendo o assunto de segurança aplicada a fluxos de trabalho Cloud Native nos dias seguintes até CTF como um exercício profissional. Isso foi felizmente finalizado por um novo entendimento de eBPF, que tem minhas telas, carreira, fluxos de trabalho e atitude com muita necessidade de uma melhoria com novas abordagens para resolver problemas de fluxo de trabalho.
Então, consegui chegar à festa do eBPF e desde então tenho participado de clínica após clínica sobre o assunto. Aqui, gostaria de "desempacotar" o eBPF como uma solução técnica, mapeada diretamente para o que fazemos na prática (mesmo que esteja um pouco fora), e passar pelo eBPF através da minha experimentação em suporte a cargas de trabalho InterSystems IRIS, particularmente no Kubernetes, mas não necessariamente vazio em cargas de trabalho autônomas.
.png)
Olá,
Neste artigo vamos ver o uso do Prometheus (prometheus.io) para coletar métricas no Iris, de forma a monitorarmos o ambiente.
O link https://cloud.google.com/discover/what-is-prometheus?hl=pt-br apresenta uma descrição bem completa do Prometheus.
O Iris conta com uma api que disponibiliza uma série de informações do ambiente. A documentação completa da api pode ser encontrada no endereço https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=GCM_rest
Uma simples chamada a api já nos mostra as informações disponíveis:
Fig.
O Enterprise Monitor é um componente do Ensemble e pode ajudar as organizações a monitorar várias produções executadas em diferentes namespaces na mesma instância ou em namespaces executados em várias instâncias.
A documentação pode ser encontrada em:
No Ensemble 2016.1, foram realizadas mudanças para esse utilitário funcionar com ambientes do HealthShare.
Este artigo mostrará o seguinte:
Para este artigo, usei a seguinte versão do HealthShare:
Cache para Windows (x86-64) 2016.1 (Build 656U) Sex 11 Mar 2016 17:42:42 EST [Módulos do HealthShare:Core:14.02.2415 + Linkage Engine:14.02.2415 + Patient Index:14.02.2415 + Clinical Viewer:14.02.2415 + Active Analytics:14.02.2415] __
Olá, Desenvolvedores!
Hoje quero falar sobre um assunto que já me deu trabalho. Tenho certeza de que isso deve ter acontecido com muitos de vocês (o chamado "gargalo"). Como esse é um tema amplo, este artigo focará apenas em identificar solicitações HTTP recebidas que podem estar causando problemas de lentidão. Também disponibilizarei uma pequena ferramenta que desenvolvi para ajudar a identificá-las.
Nosso software está cada vez mais complexo, processando um grande número de solicitações de diferentes origens, seja aplicativos de front-end ou back-end de terceiros. Para garantir um desempenho ideal, é fundamental ter um sistema de registro capaz de obter algumas medições importantes, como tempo de resposta, número de referências globais e número de linhas de código executadas para cada resposta HTTP. Como parte do meu trabalho, participo do desenvolvimento de software EMR e da análise de incidentes. Como a carga do usuário vem principalmente de solicitações HTTP (API REST ou aplicativo CSP), a necessidade desse tipo de medição quando ocorrem problemas generalizados de lentidão se tornou óbvia.
Olá Desenvolvedores,
Nossa primeira Mesa Redonda da Comunidade de Desenvolvedores de 2024 irá acontecer no dia 5 de Março de 2024 às 11 horas (BR-SP).
Palestras sobre tecnologia:
>> RVSP no desafio do Global Masters <<
[se você ainda não é membro do Global Masters, é só logar usando a sua credencial SSO InterSystems e clique neste link novamente]
A InterSystems tem o prazer de anunciar o lançamento do System Alerting & Monitoring (SAM) versão 2.0
O que é o SAM?
O SAM se conecta aos padrões utilizados nas APIS de Monioramento e do Monitor de Logs do IRIS com ferramentas familiares padrão do setor, como Grafana e Prometheus, para criar uma solução básica de monitoramento e alerta para clusters IRIS.
Para saber mais sobre SAM, consulte o Guia de Alerta e Monitoramento do sistema.
O que há de novo no SAM 2.0?
As ferramentas padrão do setor nas quais o SAM se baseia foram todas atualizadas.
Olá Comunidade,
Após o teste beta do novo exame de Certificação de Especialista em Administração de Sistemas InterSystems IRIS, a equipe de certificação dos Serviços de Aprendizagem InterSystems realizou a calibração e os ajustes necessários para liberá-lo para nossa comunidade. Já está pronto para compra e agendamento no catálogo de exames de certificação da InterSystems. Os candidatos em potencial podem analisar os tópicos do exame e as questões práticas para ajudar a orientá-los quanto às abordagens e conteúdo das questões do exame. A aprovação no exame permite que você reivindique um selo de certificação eletrônico que pode ser incorporado a contas de mídia social, como o Linkedin..
Olá Comunidade,
A equipe de Certificações InterSystems está desenvolvendo um exame de certificação para administradores de sistemas IRIS e, se você se enquadrar na descrição de candidato para este exame detalhada abaixo, nós gostaríamos que você testasse nosso exame. O exame estará disponível para teste beta de 20 a 23 de Junho de 2022 no Global Summit InterSystems 2022, mas apenas para inscritos no Summit (visite esta página para saber mais sobre a Certificação no GS22) .
A InterSystems está grata em anunciar o lançamento da versão 1.1 do System Alerting & Monitoring (SAM) version 1.1.
O SAM adiciona à API de Monitoramento baseada em padrões e ao Monitor de Log ferramentas padrão de mercado como o Grafana e o Prometheus para criar uma solução básica de monitoramento e geração de alertas para clusters IRIS.
Para mai informações sobre o SAM, veja o Guia de Monitoramento e Alerta do Sistema.
De tempos em tempos recebemos a pergunta do título deste artigo no suporte, em situações onde algo ou alguém está utilizando mais licenças do que o esperado, e precisamos então identificar o quê.
Temos dois cenários.
Boa tarde pessoal.
Alguém já conseguiu fazer algum monitoramento em cima do cache?
Estamos fazendo um estudo para adequação do numero de licenças e queria fazer um gráfico com as licenças usadas. Pensei em fazer isso pelo zabbix.
Boa tarde pessoal.
Alguém já conseguiu fazer algum monitoramento em cima do cache?
Estamos fazendo um estudo para adequação do numero de licenças e queria fazer um gráfico com as licenças usadas. Pensei em fazer isso pelo zabbix.
Houve alguns artigos muito úteis na comunidade que mostram como usar o Grafana com IRIS (ou Cache/Ensemble) usando um banco de dados intermediário.
Mas eu queria chegar diretamente às estruturas IRIS. Em particular, eu queria acessar os dados do monitor de histórico do cache que podem ser acessados por SQL, conforme descrito aqui
https://community.intersystems.com/post/apm-using-cach%C3%A9-history-mo…
E não queria nada entre mim e os dados.
Eu já tinha consultas de classe que retornaram os dados que eu queria, então eu só precisava incorporá-los en uma classe REST que retornasse JSON.
Desde o Caché 2017, o mecanismo SQL inclui um novo conjunto de estatísticas. Ele registra o número de vezes que uma consulta é executada e o tempo que leva para executá-la.
Esta é uma mina de ouro para qualquer pessoa que está monitorando e tentando otimizar o desempenho de uma aplicação que inclui muitas instruções SQL, mas que não é tão fácil de acessar os dados como algumas pessoas desejam.
Caché: 2017.2.1.801.0
Fala pessoal, tenho uma dúvida relacionada um problema especifico que eu estou tentando entender, onde ainda não tenho muitas informações, porém estou tentando criar uma forma de levantar dados precisos para expor mais detalhes aqui na comunidade ou até mesmo consultar o suporte da IS, a questão é muito simples:
Precisava saber através de código/rotina a seletividade de uma propriedade de tabela, atualmente consigo realizar um SET utilizando o comando:
SYSTEM.SQL.Fala pessoal!
Quero dividir com vocês um projeto pessoal, que iniciou como um simples pedido no meu trabalho:
É possível saber quantas licenças Caché estamos utilizando?
Lendo outros artigos aqui na comunidade, eu encontrei este excelente artigo de David Loveluck
APM - Utilizando Caché History Monitor
https://community.intersystems.com/post/apm-using-cach%C3%A9-history-monitor
Então, utilizando o artigo de David como base, eu comecei a utilizar o Caché History Monitor e a exibir todas as informações.
Quando me deparei com o seguinte dilema: Qual a melhor tecnologia de frontend que eu posso usar?
Olá a todos,
Com este artigo eu gostaria de mostrar como o Sistema de Alerta e Monitoramento (ou SAM para abreviar) pode ser configurado de forma fácil e dinâmica. O caso de uso pode ser o de um pipeline de provisionamento de CI/CD, rápido e ágil, onde você deseja executar seus testes unitários mas também seus testes de estresse e, você gostaria de ver rapidamente se esses testes foram bem-sucedidos ou como eles estão estressando os sistemas e sua aplicação (a API SAM é extensível com backend do InterSystems IRIS possibilitando a sua implementação de APM).