新しい投稿

検索

記事
· 2025年2月3日 3m read

Variáveis de host SQL ausentes ?

Variáveis de host são um recurso de programação bastante comum em muitas implementações de SQL.
Uma pergunta recente no DC me alertou para o fato de que, no IRIS, Caché, Ensemble, ... variáveis de host existem apenas dentro do SQL incorporado:

>  Você pode fornecer variáveis de host apenas para consultas SQL incorporadas.  <

Exemplos relacionados estão incluídos na documentação disponível.

Esta é uma descrição de uma solução alternativa caso você não use/não possa usar SQL incorporado.
A ideia básica é usar PPGs (Globais Privadas de Processo) para armazenar a imitação de uma variável de host.
Uma das principais razões para usar PPGs é o fato de serem excluídas automaticamente ao final do processo.
Outra ideia é evitar conflitos com arrays de variáveis locais e escopo de variáveis local versus global.Além disso, não há necessidade de uma atividade de limpeza.

Na verdade, trata-se de um conjunto de 3 métodos SQL:

  • HDEC para simular SQL DECLARE @var e SQL SET @var
  • HGETV e HGETI para retornar o valor da variável como VARCHAR ou INT.
    • Como um recurso adicional, NULL é retornado se a variável não foi definida ou declarada anteriormente.
    • Se necessário, retornar qualquer outro tipo de dado é bastante fácil.
  • HDEL é fornecido caso surja a improvável necessidade de excluir uma variável de host.
Class User.HostVar
{
ClassMethod GetV(name) As %String [ SqlName = HGETV, SqlProc ]
{
    quit $get(^||host($g(name,"%")))
}
ClassMethod GetI(name) As %Integer [ SqlName = HGETI, SqlProc ]
{
    quit $get(^||host($g(name,"%")))
}
ClassMethod Declare(name, val) As %Integer [ SqlName = HDEC, SqlProc ]
{
    set ^||host($g(name,"%"))=$g(val)
    quit $$$OK
}
ClassMethod Del(name) As %Integer [ SqlName = HDEL, SqlProc ]
{
    kill ^||host($g(name,"%"))
    quit $$$OK
}
}

Meu exemplo contém 2 variantes para implementação.

A primeira é em ObjectScript puro; essa variante também está disponível em IPM.

A segunda é baseada em SQL e pode ser implementada também sobre ODBC/JDBC.

CREATE or REPLACE
PROCEDURE HDEC(IN name VARCHAR(50), IN val VARCHAR(50)) RETURNS INT
  LANGUAGE OBJECTSCRIPT 
  { 	set ^||host($g(name,"%"))=$g(val)
	quit $$$OK
  } 
CREATE or REPLACE PROCEDURE
HGETV(IN name VARCHAR(50)) RETURNS VARCHAR(50)
  LANGUAGE OBJECTSCRIPT 
  {
 	quit $get(^||host($g(name,"%")))
  }
CREATE or REPLACE PROCEDURE
HGETI(IN name VARCHAR(50)) RETURNS INT
  LANGUAGE OBJECTSCRIPT 
  {
 	quit $get(^||host($g(name,"%")))
  }  
CREATE or REPLACE  
PROCEDURE HDEL(IN name VARCHAR(50)) RETURNS INT
  LANGUAGE OBJECTSCRIPT 
  { 	kill ^||host($g(name,"%"))
	quit $$$OK
  } 

Ambas as variantes são projetadas para serem utilizáveis sem um prefixo de pacote.

Portanto, o pacote User (o padrão) é usado, mapeando para o esquema padrão SQLUser em SQL.

Durante os testes, detectei que forçar uma sequência de Definição e Consumo dessas variáveis de host pode ser um exercício complicado se você quiser executá-lo dentro de uma única instrução SQL.

Eu consegui fornecer uma sequência previsível apenas usando uma construção CASE.

SELECT 
CASE
  WHEN HDEC('rcc',66) > 0  -- set host var 
   THEN HGETI('rcc')-5||' ** '||HGETV('rcc')
END  

Dentro de um stored procedure você não enfrenta esse problema.

Meu exemplo e também o pacote fornecido no Open Exchange foram construídos e testados no IRIS. Embora a construção seja bastante básica, ela também roda sem nenhuma alteração no Caché, Ensemble, ... e seus derivados e, claro, em todos os derivados HEALTH* do IRIS.

Minha única dúvida é sobre um banco de dados fragmentado em combinação com Globais Privadas de Processo. Eu simplesmente não tinha uma configuração disponível para testar esse cenário.

Não presumo que esta proposta seja a solução definitiva. Situações específicas podem exigir uma abordagem mais sofisticada ou, de outra forma, construções mais simples.

Como mencionado anteriormente, vejo a grande vantagem de ter uma solução que possa ser usada sobre acesso ODBC ou JDBC e não requeira codificação com VSCode ou Studio.Video

GitHub

Implementação do Portal de Ideias

 
Esperando seus votos no concurso.

1 Comment
ディスカッション (1)1
続けるにはログインするか新規登録を行ってください
質問
· 2025年2月3日

HL7 To SDA3 mapping question

On Encounter container we want  to map some data from Z segments is that possible?  Presently the mapping from HL7to SDA3 is taking place from HL7 defines segments . is there a way to push the data from Z segment.

2 Comments
ディスカッション (2)1
続けるにはログインするか新規登録を行ってください
記事
· 2025年2月3日 6m read

Monitoring InterSystems IRIS with Prometheus and Grafana

Monitoring your IRIS deployment is crucial. With the deprecation of System Alert and Monitoring (SAM), a modern, scalable solution is necessary for real-time insights, early issue detection, and operational efficiency. This guide covers setting up Prometheus and Grafana in Kubernetes to monitor InterSystems IRIS effectively. 

This guide assumes you already have an IRIS cluster deployed using the InterSystems Kubernetes Operator (IKO), which simplifies deployment, integration and mangement.

 


Why Prometheus and Grafana?

Prometheus and Grafana are widely adopted tools for cloud-native monitoring and visualization. Here’s why they are a fit:

  • Scalability: Prometheus handles large-scale data ingestion efficiently.
  • Alerting: Customizable alerts via Prometheus Alertmanager.
  • Visualization: Grafana offers rich, customizable dashboards for Kubernetes metrics.
  • Ease of Integration: Seamlessly integrates with Kubernetes workloads.

Prerequisites

Before starting, ensure you have the following:

  • Basic knowledge of Kubernetes and Linux
  • kubectl and helm installed.
  • Familiarity with Prometheus concepts (refer to the Prometheus documantion for more information).
  • A deployed IRIS instance using the InterSystems Kubernetes Operator (IKO), refer to another article here.  

Step 1: Enable Metrics in InterSystems IRIS

InterSystems IRIS exposes metrics via /api/monitor/ in the Prometheus format. Ensure this endpoint is enabled:

  1. Open the Management Portal.
  2. Go to System Administration > Security > Applications > Web Applications.
  3. Ensure /api/monitor/ is enabled and accessible by Prometheus. You can check its status by navigating to the Management Portal, going to System Administration > Security > Applications > Web Applications, and verifying that the endpoint is listed and enabled.

Verify its availability by accessing:

http://<IRIS_HOST>:<PORT>/api/monitor/metrics


Step 2: Deploy Prometheus Using Helm

Deploying Prometheus using Helm provides an easy-to-manage monitoring setup. We will use the kube-prometheus-stack chart that includes Prometheus, Alertmanager, and Grafana.

  1. Prepare the configuration: Create a values.yaml file with the following settings:
    prometheus:
      prometheusSpec:
        additionalScrapeConfigs:
          - job_name: 'intersystems_iris_metrics'
            metrics_path: '/api/monitor/metrics'
            static_configs:
              - targets:
                  - 'iris-app-compute-0.iris-svc.commerce.svc.cluster.local:80' # Replace with your IRIS service
    
          # To scrape custom metrics from the REST API created in IRIS
          - job_name: 'custom_iris_metrics'
            metrics_path: '/web/metrics'
            static_configs:
              - targets:
                  - 'commerce-app-webgateway-0.iris-svc.commerce.svc.cluster.local:80'
            basic_auth:
              username: '_SYSTEM'
              password: 'SYS'
    • Explanation:
      • iris-app-compute-0.iris-svc.commerce.svc.cluster.local:80: The format of the target should follow this convention: <pod-name>-iris-svc.<namespace>.svc.cluster.local:80. Replace <pod-name> with your IRIS pod, specify whether you want to scrape compute or data pods, and adjust the namespace as needed.
      • basic_auth** section**: If authentication is required to access the IRIS metrics endpoint, provide the necessary credentials.
  2. Add the Helm repository:
    helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
    helm repo update
     
  3. Install Prometheus using Helm:
    helm install monitoring prometheus-community/kube-prometheus-stack -n monitoring --create-namespace -f values.yaml
  4. Verify the deployment:
    kubectl get pods -n monitoring
     

Step 3: Custom Metrics with REST API

You can create a custom metrics CSP page that serves your application metrics. In this guide, I provide an example of a simple CSP page that extracts system metrics from IRIS itself, but you can totally build your own CSP page with your own custom metrics—just make sure they are in the Prometheus format.

 
CustomMetrics.REST

Deploy this as a REST service under a new web application called metrics in IRIS, and add its path to Prometheus for scraping.


Step 4: Verify Prometheus Setup

  1. Open the Prometheus UI (http://<PROMETHEUS_HOST>:9090).
  2. Go to Status > Targets and confirm IRIS metrics are being scraped.

 


Step 5: Access Grafana

With Prometheus scraping IRIS metrics, the next step is to visualize the data using Grafana.

1. Retrieve the Grafana service details:

kubectl get svc -n monitoring

If you’re using an ingress controller, you can access Grafana using the configured hostname (e.g., http://grafana.example.com). Otherwise, you can use the following options:

  1. Port Forwarding: Use kubectl port-forward to access Grafana locally:
    kubectl port-forward svc/monitoring-grafana -n monitoring 3000:80
    Then, access Grafana at http://localhost:3000.
  2. NodePort or ClusterIP: Refer to the NodePort or ClusterIP service details from the command output to connect directly.

Step 6: Log In to Grafana

Use the default credentials to log in:

  • Username: admin
  • Password: prom-operator (or the password set during installation).

 


Step 7: Import a Custom Dashboard

I’ve created a custom dashboard specifically tailored for InterSystems IRIS metrics, which you can use as a starting point for your monitoring needs. The JSON file for this dashboard is hosted on GitHub for easy access and import: Download the Custom Dashboard JSON

To import the dashboard:

  1. Navigate to Dashboards > Import in Grafana.
  2. Paste the URL of the JSON file into the Import via panel JSON field or upload the file directly.
  3. Assign the dashboard to a folder and Prometheus data source when prompted.

 

Once imported, you can edit the panels to include additional metrics, customize the visualizations, or refine the layout for better insights into your IRIS environment.


Conclusion

By following this guide, we've successfully set up Prometheus to scrape InterSystems IRIS metrics and visualize them using Grafana. Additionally, you can explore other monitoring tools such as Loki to also monitor logs efficiently and configure alerts using Alertmanager or external services like PagerDuty and Slack. If you have any questions or feedback, feel free to reach out!

10 Comments
ディスカッション (10)4
続けるにはログインするか新規登録を行ってください
ディスカッション
· 2025年2月3日

How do community members manage their collections of functions?

Hey everyone.

As I have been working with IRIS (nee Caché) for some time now, I decided to take a look at how I manage things like functions and scripts that may not belong to a single namespace or environment, but should still have a home.

I have taken to creating a github repo where I can keep track of a single .cls of "general functions" that I can then drop into an environment when required. That said, I'm keen to know from others if they have built up a similar collection of useful functions (that I could contribute to via github instead) or if this has been approached in an entirely different way?

3 Comments
ディスカッション (3)2
続けるにはログインするか新規登録を行ってください
ダイジェスト
· 2025年2月3日