Overv?king av Web-applikasjoner

Versjon 2 av automatikken

Brukes n?r web-applikasjonen kj?res p? en vanlig Linux webserver.

Man m? opprette og oppdatere en status helsefil under /tmp/zabbix/webapps p? serveren som kj?rer applikasjonen.

Navnet p? helsefilen skal v?re <applikasjonsnavn>-health.json. Hvis man kj?rer mer enn en instans per applikasjon p? samme server m? <applikasjonsnavn> v?re unik, e.g. appname-instans-1-health.json og appname-instans-2-health.json

Formatet som m? brukes for ? definere status informasjon for versjon 2 er f?lgende:

{
  "metadata": {
    "instance": "<instance-ID>",
    "zabbix-name": "<application name>",
    "host-group": "<siteadmin hostgroup>",
    "updated": 1580893620857,
    "health-file-version": 2,
    "url": "https://<application.domain>/"
  },

  "component-1": {
    "status": true,
    "severity": "average"
  },

  "component-2": {
    "status": true,
    "severity": "average"
  },

  "component-N": {
    "status": true,
    "severity": "average"
}

Verdier som brukes i json dokumentet er:

• [ metadata ][ instance ]: Applikasjons "Instance ID" e.g. server-1-inst-1 (En applikasjon kan ha flere instanser)
• [ metadata ][ zabbix-name ]: Applikasjonsnavn som skal registreres i Zabbix.
• [ metadata ][ host-group ]: Siteadmin hostgruppe hvor applikasjonen skal registreres (kan v?re en komma separert liste)
• [ metadata ][ updated ]: Timestamp for siste helsefil oppdatering i milliseconds
• [ metadata ][ health-file-version ]: Json format versjon (2 i dette tilfellet)
• [ metadata ][ url ]: URL som skal overv?kes
• [ component-N ][ status ]: true (ok) | false (error)
• [ component-N ][ severity ]: info | warning | average | high

Kombinasjonen av [ metadata ][ instance ] og [ metadata ][zabbix-name ] m? v?re unik n?r man bruker mer enn 1 instans per applikasjon.

Antall komponenter i filen med status informasjon er avhengig av applikasjonen som eier filen.

Status p? disse komponenter er fra applikasjonssynspunktet, e.g. hvis en applikasjon trenger en database for ? fungere, kan det hende at databasen er oppe og fungerer uten problemer, men hvis applikasjonen ikke kan koble seg til databasen (e.g. problemer med nettet eller
autentisering) vil status p? database komponenten i status filen v?re 'false' (error).

Det er applikasjonen som m? teste intern og finne ut om den kan bruke eller ikke alle komponentene som trenges.

Man trenger ikke ? levere status informasjon for noen komponenter hvis applikasjonen ikke er avhengig av eksterne komponenter, eller ikke har funksjonalitet for ? finne ut om den har problemer med en eller flere komponenter. I dette tilfellet er det bare url'en til applikasjonen som overv?kes.

Hvis man ikke kan/vil levere status informasjon for noen komponenter, m? man levere kun json blokken med 'metadata' informasjon.

Versjon 3 av automatikken

Brukes n?r web-applikasjonen kj?res p? en av v?re Openshift clustere.

Man m? gj?re 2 ting for ? aktivere automatisk overv?king av en applikasjon:

1. Definere noen "annotation" parametere i Openshift som definerer metadataen som trenges for ? aktivere/konfigurere overv?king i zabbix.
2. Levere status informasjon for applikasjonen via HTTP protokollen under e.g. https://applikasjonsnavn.domene/health

"annotation" parametere i Openshift som m? defineres per applikasjon som skal overv?kes er:

• uio.no/monitor.with.zabbix : true
• uio.no/site.admin : siteadmin gruppe som eier applikasjonen e.g. Siteadmin-uav-web-wapp
• uio.no/zabbix.monitor.url : URL med status informasjon e.g. /health
• uio.no/zabbix.tag.value: Man har n? mulighet til ? tagge zabbix hoster som opprettes for openshift rutene. DIA ?nsker ? ha kontrol p? antall <tag_navn>:<tag_value> par i Zabbix og tenker at kun en Zabbix tagg er nok for disse hostene i f?rste omgang. Derfor bestemte vi tag navnet som okd_service. Verdien p? taggen kan dere styre med annotering. N?r verdien ikke blir definert p? openshift rute annotering, skal Zabbix bruke not_set som std verdi.   

I tillegg brukes det disse interne metadata parametere i openshift for en applikasjon:

• ['metadata']['namespace']
• ['metadata']['name']
• ['spec']['host']

Formatet som m? brukes for ? definere status informasjonen for versjon 3 er f?lgende:

{
  "metadata": {
    "updated": 1581397535091,
    "health-file-version": 3
  },

  "components": {

    "component-1": {
      "status": true,
      "severity": "warning"
    },

    "component-2": {
      "status": true,
      "severity": "warning"
    },

    "component-N": {
      "status": true,
      "severity": "warning"
    }
  }
}

Verdier som brukes i json dokumentet er:

• [ metadata ][ updated ]: Timestamp for siste status oppdatering i milliseconds
• [ metadata ][ health-file-version ]: Json format versjon (3 i dette tilfellet)
• [ components ][ component-N ][ status ]: true (ok) | false (error)
• [ components ][ component-N ][ severity ]: info | warning | average | high

Antall komponenter i ``uio.no/zabbix.monitor.url`` url'en er avhengig av applikasjonen som leverer status informasjon.

Status p? disse komponenter er fra applikasjonssynspunktet, e.g. hvis en applikasjon trenger en database for ? fungere, kan det hende at databasen er oppe og fungerer uten problemer, men hvis applikasjonen ikke kan koble seg til databasen (e.g. problemer med nettet eller autentisering) vil status p? database komponenten i status url'en v?re 'false' (error).

Det er applikasjonen som m? teste intern og finne ut om den kan bruke eller ikke alle komponentene som trenges.

Man trenger ikke ? levere status informasjon for noen komponenter hvis applikasjonen ikke er avhengig av eksterne komponenter, eller ikke har funksjonalitet for ? finne ut om den har problemer med en eller flere komponenter. I dette tilfellet er det bare url'en til applikasjonen som overv?kes.

Hvis man ikke kan/vil levere status informasjon for noen komponenter, m? man levere kun json blokken med 'metadata' informasjon.