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.