.png)
InterSystems IRIS for Health™ es la primera y única plataforma de datos global diseñada específicamente para desarrollar aplicaciones que permitan a los servicios médicos administrar los datos más importantes del mundo. Incluye poderosas funciones listas para utilizarse: procesamiento y análisis de transacciones, un modelo flexible para la información de los servicios médicos, implementación de soluciones basadas en FHIR, soporte para las normas de compatibilidad operativa entre los servicios médicos, y mucho más. Todas estas funciones permiten que los desarrolladores realicen aplicaciones valiosas y novedosas rápidamente. Obtener más información.
Desarrollé la solucion IRIS-FHIR-Portal como parte del concurso InterSystems IRIS for Health FHIR.
El objetivo de la aplicación es mostrar cómo de fácil es crear un repositorio FHIR de pacientes y sus datos clínicos utilizando la solucion IRIS for Health.
En conjunto, con esta solucion también estamos empoderando al paciente con sus datos clínicos y ellos los podrán usar como quieran.
¡Hola desarrolladores!
Estamos en la semana de votar en el InterSystems IRIS for Health FHIR Contest!
Así que es hora de votar a la mejor solución FHIR construida con InterSystems IRIS for Health.
🔥 Tú decides: VOTA AQUÍ 🔥
¿Cómo se vota?
Es muy fácil: tienes un voto, y tu voto irá en la Nominación de los Expertos o en la Nominación de la Comunidad.
¡Hola desarrolladores!
¡Ya está listo el siguiente concurso para crear soluciones de código abierto utilizando InterSystems IRIS Data Platform!
El tema de este quinto concurso es FHIR.
El concurso estará activo durante tres semanas: del 10 al 30 de agosto de 2020.
En la última publicación programamos recogidas de métricas de rendimiento usando pButtons, a lo largo de 24 horas. En esta publicación, analizaremos algunas de esas métricas clave que se están recogiendo y cómo se relacionan con el hardware del sistema subyacente. También empezaremos a explorar la relación entre las métricas de Caché (o de cualquiera de las plataformas de datos de InterSystems) y las métricas del sistema. Veremos también cómo usar estas métricas para entender el pulso diario de tu sistema y diagnosticar problemas de rendimiento.
Editado en octubre de 2016...Añado un ejemplo de script para extraer datos de pButtons a un archivo .csvEditado en marzo de 2018... Las imágenes habían desaparecido, las volví a añadir.
Como verás a medida que avancemos por esta serie de artículos, los componentes del servidor que afectan al rendimiento pueden categorizarse como:
Si alguno de estos componentes está bajo una carga excesiva, el rendimiento del sistema y la experiencia de usuario seguramente se vean disminuidas. Estos componentes también están todos relacionados entre sí, los cambios en un componente pueden afectar a otro, a veces con consecuencias imprevistas. He visto un caso en el que corregir un cuello de botella de E/S en una matriz de almacenamiento causó que el uso de CPU saltara a 100%. Esto resultó en una experiencia de usuario aún peor, ya que el sistema de pronto quedó libre para hacer más trabajo, pero no tenía los recursos de CPU para atender el aumento en la actividad de usuario y el rendimiento.
También veremos como la actividad del sistema Caché tiene un impacto directo sobre los componentes del servidor. Si los recursos de E/S de almacenamiento son limitados, un cambio positivo que se puede hacer es aumentar la memoria del sistema y aumentar la memoria para búferes globales de Caché, lo que a su vez puede reducir la E/S de lectura de almacenamiento del sistema (¡pero quizás aumentar la CPU!).
Una de las métricas más obvias del sistema para monitorizar frecuentemente o para revisar cuándo reportan problemas los usuarios es el uso de CPU. Debemos mirar top o nmon en Linux o AIX, o Windows Performance Monitor. Como la mayoría de los administradores de sistemas revisan frecuentemente los datos de la CPU, especialmente si se presentan de forma gráfica, un rápido vistazo nos da una buena idea de la salud actual del sistema: qué es normal y qué es un pico repentino de actividad que podría ser anormal o indicativo de un problema. En este artículo revisaremos brevemente las métricas de CPU, y nos centraremos en las métricas de Caché. Comenzaremos por ver los datos de mgstat y entenderemos que mirar los datos de forma gráfica nos permite obtener, de un vistazo, una idea de la salud del sistema.
mgstat es uno de los comandos de Caché incluidos y ejecutados en pButtons. mgstat es una gran herramienta para recoger métricas básicas de rendimiento para ayudarte a entender la salud de tus sistemas. Observaremos los datos de mgstat recogidos de un pButtons de 24 horas, pero si quieres capturar datos fuera de mgstat de pButtons, también puede ejecutarse a demanda de forma interactiva o como tarea en segundo plano desde el terminal de Caché.
Para ejecutar mgstat a demanda desde el namespace %SYS, el formato general es.
do mgstat(sample_time,number_of_samples,"/file_path/file.csv",page_length)
Por ejemplo, para ejecutar una tarea en segundo plano para una ejecución de una hora con período de muestreo de 5 segundos y salida a un archivo csv.
job ^mgstat(5,720,"/data/mgstat_todays_date_and_time.csv")
Por ejemplo, para mostrar en pantalla pero omitiendo algunas columnas, usa la entrada dsp132. Te dejaré como tarea revisar la salida para entender la diferencia.
do dsp132^mgstat(5,720,"",60)
Puedes encontrar información detallada sobre las columnas de mgstat en la Guía de monitarización de Caché en la documentación de InterSystems: InterSystems online documentation
pButtons fue diseñado para compilarse en un único archivo HTML que se pueda navegar y empaquetar fácilmente para enviar a los especialistas del Centro de Soporte Internacional (WRC), que podrán diagnosticar problemas de rendimiento. Sin embargo, cuando ejecutas pButtons por tu cuenta y quieres mostrar los datos gráficamente, puedes volver a separarlos en un archivo csv para convertirlo en un gráfico, por ejemplo con Excel, usando un script de línea de comandos o simplemente cortando y pegando.
En este artículo, profundizaremos solo en algunas de las métricas de mgstat para mostrar como, incluso con un rápido vistazo, podemos hacernos una buena idea sobre si el sistema está funcionando bien, o si hay problemas reales o potenciales que afectarán a la experiencia del usuario.
El siguiente gráfico muestra el uso de CPU del servidor de la base de datos en un sitio donde se ejecuta una aplicación hospitalaria con una tasa muy elevada de transacciones. Presta atención al pico de actividad de la mañana, cuando hay muchos pacientes externos, con una caída a la hora del almuerzo y un descenso mantenido durante la tarde y labnoche. En este caso, los datos provienen de Windows Performance Monitor (_Total)% Processor Time - la forma del gráfico encaja con el perfil de un día laborable. No hay picos ni "valles" inusuales, lo que es normal para este sitio. Al hacer el mismo análisis para tu sitio, podrás empezar a tener una base de referencia de la actividad "normal". Un pico muy grande, especialmente si es prolongado, puede ser indicativo de un problema. En una publicación futura me enfocaré en el CPU.
Como referencia, este servidor de base de datos es un Dell R720 con dos procesadores E5-2670 de 8 núcleos, el servidor tiene 128 GB de memoria y 48 GB de búferes globales.
El siguiente gráfico muestra más datos de mgstat: Glorefs (referencias globales) o accesos a la base de datos para el mismo día que la gráfica de uso de CPU. Glorefs indica la cantidad de trabajo que se hace para procesar la carga de trabajo actual. Si bien las referencias globales consumen tiempo de CPU, no siempre consumen otros recursos del sistema, como lecturas físicas, por la forma en que Caché usa el recurso compartido de búfer de memoria global.
Como es típico en aplicaciones de Caché, hay una correlación muy fuerte entre Glorefs y uso de CPU.
Otra forma de analizar estos datos de CPU y gloref es decir que reducir las glorefs reducirá el uso de CPU, lo que permitirá el uso de servidores con menos núcleos o escalar más sobre los sistemas existentes. Puede haber formas de reducir las referencias globales si hacemos que la aplicación sea más eficiente. Volveremos a este concepto en otros artículo posteriores.
La forma del gráfico obtenido con los datos de mgstat PhyRds (Physical Reads, lecturas físicas) y Rdratio (Read ratio, tasa de lectura) también puede aportar información sobre qué esperar del rendimiento del sistema y ayudar con la planificación de capacidad. En futuras publicaciones hablaré con más detalle sobre el almacenamiento de entrada y salida para Caché.
PhyRds son simplemente IOPS de lectura física desde el disco a las bases de datos de Caché. Deberías ver los mismos valores reflejados en las métricas del sistema operativo para discos lógicos y físicos. Recuerda al mirar las IOPS del sistema operativo que también podrían estar mostrando IOPS provenientes de aplicaciones que no son de Caché. Dimensionar el almacenamiento y no tener en cuenta las IOPS esperadas es una receta para el desastre. Necesitas conocer las IOPS que tu sistema realiza en horas pico para realizar una adecuada planificación de capacidad. El siguiente gráfico muestra las PhyRds entre la media noche y las 15:30.
Observa el gran salto en lecturas entre las 05:30 y las 10:00. Hay otros picos menores a las 11:00 y justo antes de las 14:00. ¿Qué crees que los causa? ¿Ves este tipo de picos en tus servidores?
Rdratio es un poco más interesante: es la tasa de lectura de bloques lógicos por lectura de bloque físico. Así que es una tasa de cuántas lecturas son de búferes globales (lógicos) desde la memoria y cuántas son del disco, lo que es órdenes de magnitud más lento. Un Rdratio alto es algo bueno. Que caiga cerca de cero por largos períodos no es bueno.
Observa que al mismo tiempo que hay una alta cantidad de lecturas, Rdratio baja a cerca de cero. En este sitio me pidieron investigar cuando el departamento de TI comenzó a recibir llamadas de usuarios que se quejaban de que el sistema se volvía lento por largos períodos. Esto había estado sucediendo al parecer de forma aleatorio desde hacía semanas, y me pidieron analizar el sistema.
Como pButtons había sido programado para ejecutarse diariamente durante 24 horas, fue relativamente sencillo analizar varias semanas de datos para empezar a ver un patrón de PhyRds elevados y bajos Rdratio, correlacionados con las llamadas al soporte técnico.
Tras un mayor análisis, pude rastrear la causa hasta un trabajador por turnos nuevo, que estaba ejecutando varios informes metiendo parámetros "erróneos" junto con consultas mal redactadas, sin los índices adecuados, lo que causaba la elevada cantidad de lecturas a la base de datos. Este era el origen de las ralentizaciones aparentemente aleatorias. Como estos informes que abarcan mucho tiempo leen datos hacia los búferes globales, el resultado es que los datos de usuario interactivos se recuperan del almacenamiento físico en vez de hacerse desde la memoria. Esto ejerce una gran carga sobre el almacenamiento para atender las lecturas.
Supervisar PhyRds y Rdratio te dará una idea del estado de funcionamiento de tus sistemas y quizás te permita encontrar informes o consultas mal realizadas. Podría existir una razón válida para tener un PhyRds alto -- quizás sea necesario ejecutar un informe a cierta hora. Con los servidores y sistemas operativos modernos de 64 bits y su gran capacidad de memoria física, deberías poder minimizar el PhyRds en tus sistemas de producción.
Si observas un PhyRds alto en tu sistema, hay varias estrategias que puedes evaluar:
- Aumentar la cantidad de búferes (globales) de base de datos (y la memoria del sistema) para mejorar el desempeño.
- Mover fuera del horario de oficina la creación de informes o extractos que requieran un largo tiempo.
- Los informes de solo lectura que requieran mucho tiempo, las tareas por lotes y las extracciones de datos pueden ejecutarse en un servidor de shadowing independiente o mirror asíncrono, lo que minimizará el impacto sobre los usuarios interactivos y quitará parte de la carga sobre los recursos del sistema, como CPU e IOPS.
Un PhyRds que normalmente sea bajo es algo bueno, y debe ser nuestro objetivo al dimensionar sistemas. Sin embargo, si tienes un PhyRds bajo y los usuarios se quejan del rendimiento, hay otras cosas que se pueden revisar para asegurarse de que el almacenamiento no sea un cuello de botella - la cantidad de lecturas podría ser baja debido a que el sistema ya no puede dar más servicio. Analizaremos el almacenamiento con mayor profundidad en un artículo posterior.
En esta publicación hemos visto que mostrar con gráficos las métricas recogidas en pButtons puede darnos una idea del estado del sistema de un vistazo. En publicaciones futuras, analizaré en mayor profundidad la relación entre el sistema y las métricas de Caché, y cómo se pueden usar para planificar para el futuro.
Ya están disponibles las versiones de prueba 2020.3 de InterSystems IRIS, IRIS for Health e IRIS Studio.
El número de compilación de estas versiones es 2020.3.0.200.0.
Las imágenes del contenedor, los componentes y las licencias de evaluación están disponibles en la página de descargas para pruebas del Centro de Soporte Internacional (WRC).
Los contenedores de la edición Community también pueden obtenerse desde el Docker Store usando los siguientes comandos:
docker pull store/intersystems/iris-community:2020.3.0.200.0
docker pull store/intersystems/iris-community-arm64:2020.3.0.200.0
La versión 2020.2 de InterSystems IRIS, IRIS for Health e IRIS Studio ya ha sido lanzada.
Los contenedores para estos productos están disponibles en la página de distribución de software, del Centro de Soporte Internacional (WRC), incluyendo las ediciones "community" de InterSystems IRIS e IRIS for Health.
El número de compilación de estas versiones es 2020.2.0.211.0.
InterSystems IRIS Data Platform 2020.2 ofrece una importante actualización de seguridad con las siguientes mejoras:
¡Hola Comunidad!
Por si os lo perdisteis o queréis volver a verlo, ya está disponible la grabación del webinar "Comienza a trabajar con FHIR" que realizamos el pasado miércoles 17 de junio.
⏯ Comienza a trabajar con FHIR
¿Habéis entrado al Canal de YouTube de la Comunidad de Desarrolladores en español? En él podéis ver todos los webinars que estamos realizando, varios tutoriales y más vídeos. Y si os suscribís al canal, podréis ver nuestros vídeos directamente en vuestro muro de "Suscripciones" cuando entréis en YouTube 
¡Esperamos que os resulte útil!
¡Hola desarrolladores!
¿Os habéis encontrado con la necesidad de crear una base de datos, un namespace o una aplicación web de manera programática? Quiero compartir con vosotros un fragmento de código ObjectScript que permite crear una base de datos, un namespace y una aplicación web para InterSystems IRIS.
set currentNS = $namespace
zn "%SYS"
write "Create DB ...",!
set dbName="testDB"
set dbProperties("Directory") = "/InterSystems/IRIS/mgr/testDB"
set status=##Class(Config.Databases).Create(dbName,.dbProperties)
write:'status $system.Status.DisplayError(status)
write "DB """_dbName_""" was created!",!!
write "Create namespace ...",!
set nsName="testNS"
//DB for globals
set nsProperties("Globals") = dbName
//DB for routines
set nsProperties("Routines") = dbName
set status=##Class(Config.Namespaces).Create(nsName,.nsProperties)
write:'status $system.Status.DisplayError(status)
write "Namespace """_nsName_""" was created!",!!
write "Create web application ...",!
set webName = "/csp/testApplication"
set webProperties("NameSpace") = nsName
set webProperties("Enabled") = $$$YES
set webProperties("IsNameSpaceDefault") = $$$YES
set webProperties("CSPZENEnabled") = $$$YES
set webProperties("DeepSeeEnabled") = $$$YES
set webProperties("AutheEnabled") = $$$AutheCache
set status = ##class(Security.Applications).Create(webName, .webProperties)
write:'status $system.Status.DisplayError(status)
write "Web application """webName""" was created!",!
zn currentNS
También podéis consultar estos manuales:
¡Hola a tod@s!
Os invitamos a un nuevo webinar en español: "Comienza a trabajar con FHIR", el miércoles 17 de junio, a las 16:00 CEST.
Después de migrar varias HS in place a IRIS me he encontrado una que no es capaz de terminar, da un error que no es muy claro.
He mirado el log de instalación y pone lo mismo. Lo unico curioso de esta instancia es que tiene Sublevel Mappings en el CPF:
Ya están disponibles las versiones de prueba de InterSystems IRIS Advanced Analytics y de InterSystems IRIS for Health Advanced Analytics. El add-on Advanced Analytics para InterSystems IRIS introduce IntegratedML como una nueva funcionalidad.
El número de compilación de estas versiones es el: 2020.3.0AA.331.0
Los kits para la instalación, las imágenes del contenedor y las licencias de evaluación están disponibles en la página de descargas para pruebas del Centro de Soporte Internacional (WRC).
AWS ha liberado oficialmente su segunda generación de procesadores Graviton2 basados en ARM y asociados al tipo de instancia Amazon EC2 M6g, que presume de ser hasta un 40% mejor en precio-rendimiento sobre la actual generación de instancias M5 basadas en Xeon.
Hace pocos meses, Inthhis nos llevó a suportar arquitecturas ARM64 por primera vez.
¡Ahora puedes probar InterSystems IRIS e InterSystems IRIS for Health sobre instancias Amazon EC2 M6g basadas en Graviton2 accesibles a través del AWS Marketplace!
InterSystems ha corregido dos defectos que afectan al backup online de grandes bases de datos. Los backups realizados a través de métodos externos, como snapshots o copias directas de ficheros, no están afectados. Estos defectos existen en todas las versiones de los productos de InterSystems.
¡Hola Comunidad!
Os traemos un nuevo vídeo, disponible en el Canal de YouTube de la Comunidad de Desarrolladores en inglés:
Ya están disponibles las versiones de prueba 2020.2 de InterSystems IRIS, IRIS for Health e IRIS Studio.
El número de compilación de estas versiones es 2020.2.0.196.0.
Las imágenes del contenedor, los componentes y las licencias de evaluación están disponibles en la página de descargas para pruebas del Centro de Soporte Internacional (WRC).
Los contenedores de la edición Community también pueden obtenerse desde el Docker Store usando los siguientes comandos:
¡Hola desarrolladores!
Hemos creado una serie de Concursos de Programación en InterSystems IRIS para todo el año.
En marzo ya empezamos con ObjectScript CLI y los temas para los próximos meses son los siguientes:
Todas las aplicaciones deben ser ejecutables con InterSystems IRIS en un contenedor docker.
¡Hola Comunidad!
Os traemos un nuevo vídeo, disponible en el canal de YouTube de la Comunidad de Desarrolladores en inglés, grabado por @Patrick Jamieson
La versión 2020.1 de InterSystems IRIS, IRIS for Health e IRIS Studio ya ha sido lanzada.
Los kits para la instalación y los contenedores están disponibles en lapágina de distribución de software del Centro de Soporte Internacional (WRC), incluyendo las ediciones "community" de InterSystems IRIS e IRIS for Health.
El número de compilación de estas versiones es2020.1.0.215.0.
Hola
Estoy trabajando con un equipo de desarrolladores que quieren dar el salto a InterSystems 2019.4, actualmente utilizan Object Script para sus desarrollos, y no utilizan ningún tipo de sistema de control de versiones.
Yo desconozco como funciona todo este entorno, por lo que he creído que sería buena idea solicitar ayuda en la comunidad, ya que parece bastante activa, y así asegurarnos de seguir buenas prácticas.
¡Hola desarrolladores!
Este mes de marzo lanzamos nuestro primer Concurso de Programación con InterSystems IRIS! El objetivo del concurso es crear soluciones de código abierto utilizando InterSystems IRIS Data Platform.
El tema del primer concurso es InterSystems IRIS, Docker y ObjectScript.
El concurso estará activo durante tres semanas, del 9 al 31 de marzo de 2020.
Premios:
Habrá una Nominación de los Expertos, en la que los ganadores serán elegidos por un jurado especialmente formado para el concurso. Los premios serán:
🥇 1er puesto - $2,000
🥈 2º puesto - $1,000
🥉 3er puesto - $500
Además, habrá una Nominación de la Comunidad, en la que ganará la aplicación que obtenga el mayor número total de votos. El premio será:
🏆 1er puesto - $1,000
Los ganadores también recibirán las insignias de mayor nivel del programa de fidelización Global Masters.
Desde marzo de 2020, Microsoft planea lanzar una serie de actualizaciones de seguridad que harán que los servidores Active Directory (AD) de Windows rechacen vínculos de canales no cifrados. Para más detalles de los cambios en Active Directory, pueden consultar el aviso de seguridad de Microsoft: ADV190023.
Estaba buscando la forma mas simple de conectar desde el visual studio code a mi instancia local por el terminal sin tener que ir cambiando de ventana.
Soy consciente de que esto tambien se puede conseguir por telnet pero me parece complicar la cosa para conectarme a mi local.
La solución mas sencilla me ha parecido navegar a la carpeta /bin de la instalación (o añadirla al PATH), y ejecutar .\csession.exe NOMBREDEINSTANCIA.
De hecho si tienes añadidas instancias remotas como conexiones, también se puede acceder a ellas.
Eso es todo!
¡Hola Comunidad!
Tenemos un nuevo vídeo, disponible en el canal de YouTube de la Comunidad de Desarrolladores en inglés, grabado por @Patrick Jamieson:
¡Hola a tod@s!
Ya están disponibles las versiones de prueba de InterSystems IRIS e IRIS for Health 2020.1
Los kits para la instalación y las imágenes del contenedor están disponibles en la página de descargas para prueba del Centro de Soporte Internacional (WRC).
El número de compilación de estas versiones es 2020.1.0.199.0 (Nota: número actualizado de 197 a 199 el 12/2/20).
InterSystems IRIS Data Platform 2020.1 incluye muchas funcionalidades nuevas:
Actualización 30/01/2020
*** Las versiones afectadas de los productos han cambiado ***
*** Las versiones afectadas son Caché y Ensemble desde 2016.2.0. ***
*** Caché y Ensemble 2016.1.0 no está afectada por este defecto ***
InterSystems ha corregido un defecto que puede ocasionar degradación de la base de datos en circunstancias muy excepcionales. Puede incluir (y no limitarse a) problemas relacionados, como datos de la aplicación incorrectos o desaparecidos y sistemas bloqueados.
Este defecto afecta a:
¡Hola Comunidad!
Voy a empezar a traducir los artículos de mi compañero Murray sobre rendimiento, pues son muy interesantes y merece la pena echarles un vistazo. Aprovecho para comentar que si tenéis preguntas y /o problemas de rendimiento os animéis a escribir y entre todos trataremos de ayudaros. Empecemos...
Tu aplicación está implementada y todo funciona bien. ¡Genial, enhorabuena! Pero, de repente, el teléfono empieza a sonar sin parar: son usuarios que se quejan de que la aplicación a veces se vuelve "lenta". Pero... ¿qué quiere decir eso? ¿A veces? ¿De qué herramientas dispones y a qué estadísticas deberías prestar atención para encontrar y resolver la lentitud? ¿La infraestructura de tu sistema está a la altura de la carga de usuarios? ¿Qué preguntas de diseño de infraestructura deberías haber hecho antes de haber pasado a producción? ¿Cómo puedes hacer la planificación de capacidad para nuevo hardware con confianza y sin gastar en más hardware del necesario? ¿Cómo hacer que el teléfono deje de sonar? ¿Cómo podrías haber evitado que sonara desde un principio?
A continuación veremos cómo mostrar una lista de métricas de ejemplo disponibles a través del servicio /api/monitor.
En el artículo anterior, echamos un vistazo al servicio que expone las métricas de IRIS en formato Prometheus. Veamos cómo configurar y ejecutar IRIS preview release 2019.4 en un contenedor y listar las métricas disponibles.
Asumimos que tienes Docker instalado. Si no es así, descárgalo e instálalo para tu sistema operativo :)
Si ya te resulta familiar trabajar con IRIS y contenedores Docker, puedes saltar directamente al Paso 2. Mostrar métricas.
Sigue las instrucciones de Preview Distributions para descargar la Clave de Licencia Preview y una imagen Docker IRIS. Por ejemplo, yo he escogido InterSystems IRIS for Health 2019.4.
Sigue las instrucciones de First Look InterSystems Products in Docker Containers.
Este es el proceso que hemos seguido para cargar la imagen Docker. El comando docker load tardará algunos instantes en completarse.
$ pwd
/Users/myhome/Downloads/iris_2019.4
$ ls
InterSystems IRIS for Health (Container)_2019.4.0_Docker(Ubuntu)_12-31-2019.ISCkey irishealth-2019.4.0.379.0-docker.tar
$ docker load -i irishealth-2019.4.0.379.0-docker.tar
762d8e1a6054: Loading layer [==================================================>] 91.39MB/91.39MB
e45cfbc98a50: Loading layer [==================================================>] 15.87kB/15.87kB
d60e01b37e74: Loading layer [==================================================>] 12.29kB/12.29kB
b57c79f4a9f3: Loading layer [==================================================>] 3.072kB/3.072kB
b11f1f11664d: Loading layer [==================================================>] 73.73MB/73.73MB
22202f62822e: Loading layer [==================================================>] 2.656GB/2.656GB
50457c8fa41f: Loading layer [==================================================>] 14.5MB/14.5MB
bc4f7221d76a: Loading layer [==================================================>] 2.048kB/2.048kB
4db3eda3ff8f: Loading layer [==================================================>] 1.491MB/1.491MB
Loaded image: intersystems/irishealth:2019.4.0.379.0
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
intersystems/irishealth 2019.4.0.379.0 975a976ad1f4 3 weeks ago 2.83GB
Por simplicidad, copia la licencia al directorio que utilizaremos como almacenamiento persistente y renómbrala a iris.key;
$ mkdir -p /Users/myhome/iris/20194
$ cp 'InterSystems IRIS for Health (Container)_2019.4.0_Docker(Ubuntu)_12-31-2019.ISCkey' /Users/myhome/iris/20194/iris.key
$ cd /Users/myhome/iris/20194
$ ls
iris.key
Ejecuta IRIS utilizando el directorio que acabamos de crear para almacenamiento persistente;
$ docker run --name iris --init --detach --publish 52773:52773 --volume `pwd`:/external intersystems/irishealth:2019.4.0.379.0 --key /external/iris.key
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
009e52c121f0 intersystems/irishealth:2019.4.0.379.0 "/iris-main --key /e…" About a minute ago Up About a minute (healthy) 0.0.0.0:52773->52773/tcp iris
Genial! Ya puedes conectarte al Portal de Gestión del contenedor que tenemos en ejecución. Entraremos con login/password SuperUser/SYS; a continuación, el sistema te pedirá que cambies la contraseña por defecto.
Dirígete a la configuración de las Aplicaciones Web. System > Security Management > Web Applications
Verás una aplicación web llamada /api/monitor, éste es el servicio que expone las métricas de IRIS.
No tienes que hacer nada adicional para que el servicio retorne las métrica, simplemente funciona! :)
En artículos posteriores, emplearemos este endpoint desde Prometheus o SAM para recoger las métricas a intervalos específicos. Pero por ahora, vamos a mostrar la lista completa de métricas disponibles para la instancia. Una forma simple de hacerlo en Linux y OSX es lanzando un HTTP GET a través del comando curl;
$ curl localhost:52773/api/monitor/metrics
:
:
iris_cpu_usage 0
iris_csp_activity{id="127.0.0.1:52773"} 56
iris_csp_actual_connections{id="127.0.0.1:52773"} 8
iris_csp_gateway_latency{id="127.0.0.1:52773"} .588
iris_csp_in_use_connections{id="127.0.0.1:52773"} 1
iris_csp_private_connections{id="127.0.0.1:52773"} 0
iris_csp_sessions 1
iris_cache_efficiency 35.565
:
:
Y la lista continúa...
Otra forma muy útil de hacerlo es utilizar la aplicación Postman. Si tienes instalado Postman, puedes enviar un HTTP GET y examinar las métricas devueltas.
Esto es todo por ahora. En el próximo artículo, comenzaremos a recuperar los datos desde Prometheus y veremos un ejemplo de un cuadro de mando de Grafana.
Un sistema de producción tendrá muchas más métricas disponibles. Como podéis ver por algunas de las etiquetas, por ejemplo {id="IRISLOCALDATA"} hay métricas que son definidas por base de datos o por CPU por el tipo de proceso{id="CSPDMN"}.
iris_cpu_pct{id="CSPDMN"} 0
iris_cpu_pct{id="CSPSRV"} 0
iris_cpu_pct{id="ECPWorker"} 0
iris_cpu_pct{id="GARCOL"} 0
iris_cpu_pct{id="JRNDMN"} 0
iris_cpu_pct{id="LICENSESRV"} 0
iris_cpu_pct{id="WDSLAVE"} 0
iris_cpu_pct{id="WRTDMN"} 0
iris_cpu_usage 0
iris_csp_activity{id="127.0.0.1:52773"} 57
iris_csp_actual_connections{id="127.0.0.1:52773"} 8
iris_csp_gateway_latency{id="127.0.0.1:52773"} .574
iris_csp_in_use_connections{id="127.0.0.1:52773"} 1
iris_csp_private_connections{id="127.0.0.1:52773"} 0
iris_csp_sessions 1
iris_cache_efficiency 35.850
iris_db_expansion_size_mb{id="ENSLIB"} 0
iris_db_expansion_size_mb{id="HSCUSTOM"} 0
iris_db_expansion_size_mb{id="HSLIB"} 0
iris_db_expansion_size_mb{id="HSSYS"} 0
iris_db_expansion_size_mb{id="IRISAUDIT"} 0
iris_db_expansion_size_mb{id="IRISLOCALDATA"} 0
iris_db_expansion_size_mb{id="IRISSYS"} 0
iris_db_expansion_size_mb{id="IRISTEMP"} 0
iris_db_free_space{id="ENSLIB"} .055
iris_db_free_space{id="HSCUSTOM"} 2.3
iris_db_free_space{id="HSLIB"} 113
iris_db_free_space{id="HSSYS"} 9.2
iris_db_free_space{id="IRISAUDIT"} .094
iris_db_free_space{id="IRISLOCALDATA"} .34
iris_db_free_space{id="IRISSYS"} 6.2
iris_db_free_space{id="IRISTEMP"} 20
iris_db_latency{id="ENSLIB"} 0.030
iris_db_latency{id="HSCUSTOM"} 0.146
iris_db_latency{id="HSLIB"} 0.027
iris_db_latency{id="HSSYS"} 0.018
iris_db_latency{id="IRISAUDIT"} 0.017
iris_db_latency{id="IRISSYS"} 0.020
iris_db_latency{id="IRISTEMP"} 0.021
iris_db_max_size_mb{id="ENSLIB"} 0
iris_db_max_size_mb{id="HSCUSTOM"} 0
iris_db_max_size_mb{id="HSLIB"} 0
iris_db_max_size_mb{id="HSSYS"} 0
iris_db_max_size_mb{id="IRISAUDIT"} 0
iris_db_max_size_mb{id="IRISLOCALDATA"} 0
iris_db_max_size_mb{id="IRISSYS"} 0
iris_db_max_size_mb{id="IRISTEMP"} 0
iris_db_size_mb{id="HSLIB",dir="/usr/irissys/mgr/hslib/"} 1321
iris_db_size_mb{id="HSSYS",dir="/usr/irissys/mgr/hssys/"} 21
iris_db_size_mb{id="ENSLIB",dir="/usr/irissys/mgr/enslib/"} 209
iris_db_size_mb{id="IRISSYS",dir="/usr/irissys/mgr/"} 113
iris_db_size_mb{id="HSCUSTOM",dir="/usr/irissys/mgr/HSCUSTOM/"} 11
iris_db_size_mb{id="IRISTEMP",dir="/usr/irissys/mgr/iristemp/"} 21
iris_db_size_mb{id="IRISAUDIT",dir="/usr/irissys/mgr/irisaudit/"} 1
iris_db_size_mb{id="IRISLOCALDATA",dir="/usr/irissys/mgr/irislocaldata/"} 1
iris_directory_space{id="HSLIB",dir="/usr/irissys/mgr/hslib/"} 53818
iris_directory_space{id="HSSYS",dir="/usr/irissys/mgr/hssys/"} 53818
iris_directory_space{id="ENSLIB",dir="/usr/irissys/mgr/enslib/"} 53818
iris_directory_space{id="IRISSYS",dir="/usr/irissys/mgr/"} 53818
iris_directory_space{id="HSCUSTOM",dir="/usr/irissys/mgr/HSCUSTOM/"} 53818
iris_directory_space{id="IRISTEMP",dir="/usr/irissys/mgr/iristemp/"} 53818
iris_directory_space{id="IRISAUDIT",dir="/usr/irissys/mgr/irisaudit/"} 53818
iris_disk_percent_full{id="HSLIB",dir="/usr/irissys/mgr/hslib/"} 10.03
iris_disk_percent_full{id="HSSYS",dir="/usr/irissys/mgr/hssys/"} 10.03
iris_disk_percent_full{id="ENSLIB",dir="/usr/irissys/mgr/enslib/"} 10.03
iris_disk_percent_full{id="IRISSYS",dir="/usr/irissys/mgr/"} 10.03
iris_disk_percent_full{id="HSCUSTOM",dir="/usr/irissys/mgr/HSCUSTOM/"} 10.03
iris_disk_percent_full{id="IRISTEMP",dir="/usr/irissys/mgr/iristemp/"} 10.03
iris_disk_percent_full{id="IRISAUDIT",dir="/usr/irissys/mgr/irisaudit/"} 10.03
iris_ecp_conn 0
iris_ecp_conn_max 2
iris_ecp_connections 0
iris_ecp_latency 0
iris_ecps_conn 0
iris_ecps_conn_max 1
iris_glo_a_seize_per_sec 0
iris_glo_n_seize_per_sec 0
iris_glo_ref_per_sec 7
iris_glo_ref_rem_per_sec 0
iris_glo_seize_per_sec 0
iris_glo_update_per_sec 2
iris_glo_update_rem_per_sec 0
iris_journal_size 2496
iris_journal_space 50751.18
iris_jrn_block_per_sec 0
iris_jrn_entry_per_sec 0
iris_jrn_free_space{id="WIJ",dir="default"} 50751.18
iris_jrn_free_space{id="primary",dir="/usr/irissys/mgr/journal/"} 50751.18
iris_jrn_free_space{id="secondary",dir="/usr/irissys/mgr/journal/"} 50751.18
iris_jrn_size{id="WIJ"} 100
iris_jrn_size{id="primary"} 2
iris_jrn_size{id="secondary"} 0
iris_license_available 31
iris_license_consumed 1
iris_license_percent_used 3
iris_log_reads_per_sec 5
iris_obj_a_seize_per_sec 0
iris_obj_del_per_sec 0
iris_obj_hit_per_sec 2
iris_obj_load_per_sec 0
iris_obj_miss_per_sec 0
iris_obj_new_per_sec 0
iris_obj_seize_per_sec 0
iris_page_space_per_cent_used 0
iris_phys_mem_per_cent_used 95
iris_phys_reads_per_sec 0
iris_phys_writes_per_sec 0
iris_process_count 29
iris_rtn_a_seize_per_sec 0
iris_rtn_call_local_per_sec 10
iris_rtn_call_miss_per_sec 0
iris_rtn_call_remote_per_sec 0
iris_rtn_load_per_sec 0
iris_rtn_load_rem_per_sec 0
iris_rtn_seize_per_sec 0
iris_sam_get_db_sensors_seconds .000838
iris_sam_get_jrn_sensors_seconds .001024
iris_system_alerts 0
iris_system_alerts_new 0
iris_system_state 0
iris_trans_open_count 0
iris_trans_open_secs 0
iris_trans_open_secs_max 0
iris_wd_buffer_redirty 0
iris_wd_buffer_write 0
iris_wd_cycle_time 0
iris_wd_proc_in_global 0
iris_wd_size_write 0
iris_wd_sleep 10002
iris_wd_temp_queue 42
iris_wd_temp_write 0
iris_wdwij_time 0
iris_wd_write_time 0
iris_wij_writes_per_sec 0
En InterSystems IRIS 2019.1.4 se incluye ya el servicio /api/monitor, que permite acceder a métricas de IRIS en formato Prometheus.
Esto es una gran noticia para aquellos interesados en utilizar métricas de IRIS como parte de su solución de monitorización y alertas. Este servicio (API) es un componente del nuevo System Alerting and Monitoring (SAM) que se liberará en próximas versiones de InterSystems IRIS.
Sin embargo, no es necesario esperar a que se libere System Alerting and Monitoring (SAM) para empezar a planificar y probar esta API para monitorizar tus instancias de IRIS. En próximos artículos trataremos en profundidad las métricas disponibles, su significado y también construiremos cuadros de mando de ejemplo interactivos. Pero en primer lugar, vamos a comenzar con algunas cuestiones básicas.
IRIS (y Caché) está siempre capturando decenas de métricas sobre sí mismo y la plataforma en la que está ejecutándose. Siempre han existido diferentes maneras de capturar estas métricas para monitorizar IRIS o Caché. En la práctica no muchas instalaciones utilizan las soluciones incluidas en IRIS / Caché. Por ejemplo, el History Monitor ha estado disponible desde hace tiempo como base de datos histórica de rendimiento y utilización del sistema. Sin embargo, no había una manera demasiado obvia de aprovechar estas métricas en tiempo real.
Las soluciones construidas sobre la plataforma InterSystems IRIS están pasando de una sola aplicación monolítica ejecutándose en unas pocas instancias en las propias instalaciones de una organización a ser soluciones distribuidas desplegadas en cualquier parte. Para muchos casos de uso, las opciones de monitorización de IRIS existentes no se terminan de adaptar a estos nuevos paradigmas. Para solventar este problema, en lugar de reinventar la rueda, InterSystems utilizará soluciones conocidas y bien probadas del mundo open source para monitorización y alertas.
Prometheus es una solución open source de monitorización muy conocida y ampliamente adoptada. Dispone de una gran variedad de plugins. Está diseñada para poder trabajar en entornos de cloud pero también resulta igual de útil para aplicaciones desplegadas en nuestras propias instalaciones. Los plugins incluyen sistemas operativos, servidores web como Apache y otras muchas aplicaciones. Prometheus se utiliza generalmente junto con un cliente front-end o de presentación, como por ejemplo Grafana, que provee una interfaz gráfica que es extremadamente adaptable a nuestras necesidades.
Grafana es también open source. Conforme esta serie de artículos progrese, pasaremos ejemplos de plantillas de cuadros de mando para escenarios típicos. Podrás utilizar esos ejemplos como base para diseñar los cuadros de mando que te interesen.
El gran potencial de estas herramientas surge cuando combinas las métricas de IRIS en el contexto de las métricas de tu propia solución. Desde los componentes de la plataforma donde se ejecuta, el sistema operativo, IRIS y especialmente cuando además se añade instrumentación para monitorizar tus propias aplicaciones.
Monitorizar IRIS / Caché con Prometheus y Grafana no es algo nuevo. Se han utilizado estas aplicaciones durante años. Si buscas en la Comunidad de Desarrolladores el término "Prometheus" encontrarás otros artículos como por ejemplo estos excelentes artículos de Mikhail Khomenko que muestran cómo exponer métricas de Caché para utilizarlas con Prometheus.
La diferencia es que ahora la API
/api/monitorestá incluida y habilitada por defecto. No necesitas incluir código para exponer estas métricas.
A continuación vamos a hacer una primera orientación rápida a Prometheus y su terminología. Vamos a verlo a alto nivel y a preparar el trabajo de base que servirá para dejar la puerta abierta para que penséis cómo visualizar y consumir las métricas de IRIS o de otras fuentes.
Prometheus funciona obteniendo datos en formato de serie temporal expuestos por aplicaciones a través de una URL (por ejemplo la API de /api/monitor). Existen librerías de exportadores y clientes para muchos lenguajes, frameworks y aplicaciones open source — por ejemplo para servidores web como Apache, distintos sistemas operativos, docker, Kubernetes, bases de datos y ahora IRIS —.
Los exportadores se utilizan para instrumentalizar aplicaciones y servicios de manera que expongan (hagan accesible) las métricas en una URL. Los componentes estándar como los servidores web, bases de datos y demás se soportan por los exportadores core. Existen otros muchos exportadores open source disponibles en la comunidad Prometheus.
Estos son algunos términos que vamos a manejar:
** Spoiler Alert! Por razones de seguridad, escalabilidad, alta disponibilidad y eficiencia, en la nueva solución System Alerting and Monitoring (SAM) la base de datos utilizada para almacenar las series temporales de Prometheus será InterSytems IRIS! El acceso a la base de datos de Prometheus (IRIS) será transparente y no supondrá ninguna circunstancia especial para acceder desde otras aplicaciones como Grafana.
Las métricas que retorna la API /api/monitor están en formato Prometheus. Prometheus utiliza un formato simple basado en una métrica por línea:
[ (time n, value n), ....]
Estas métricas pueden etiquetarse como parejas clave-valor. Las etiquetas son una forma muy potente de filtrar métricas y dimensiones. Por ejemplo, vamos a examinar esta métrica del servicio/api/monitor que retorna la cantidad de espacio libre para journal:
iris_jrn_free_space{id="WIJ",dir=”/fast/wij/"} 401562.83
El identificador indica qué métrica es y de dónde viene:
iris_jrn_free_space
Se pueden utilizar diferentes etiquetas para decorar las métricas, y así utilizarlas a la hora de filtrar y consultar. En el ejemplo, podemos ver el WIJ y el directorio donde se guarda el propio WIJ:
id="WIJ",dir="/fast/wij/"
Y finalmente, observamos también un valor: 401562.83 (MB).
En la documentación aparece la lista de las métricas disponibles. Aunque también puedes simplemente consultar la API en el endpoint /api/monitor/metricspara que te devuelva la lista de las métricas.
Ten en cuenta los siguientes puntos a la hora de pensar cómo debes monitorizar tus sistemas y aplicaciones.
Cuando te sea posible, utiliza métricas que afecten a los usuarios:
Evita construir una pantalla llena de gráficas en tus cuadros de mando:
Piensa en términos de servicios, no de máquinas:
Documentación y descargas: Prometheus y Grafana.
@Murray Oldfield presentó una sesión sobre SAM (incluyendo Prometheus y Grafana) en el pasado InterSystems Global Summit 2019. Encontrarás más información en InterSystems Learning Services buscando el término "System Alerting and Monitoring Made Easy".
La versión 2019.4 de InterSystems IRIS, IRIS for Health e IRIS Studio ya ha sido lanzada.
Está disponible a través del Centro de Soporte Internacional, con número de compilación 2019.4.0.383.0.
InterSystems IRIS Data Platform 2019.4 incluye muchas funcionalidades nuevas:
Cuando impiezo una google cloud docker container la port es 52773 pero quiero tener port 9100 9101 tambien. Yo veo en documentos que no es posible cambiarlo ante que esta andado. Que hago? -- IV